ID:35495さん

## プロジェクトの概要 BtoBのマッチングプラットフォームサイトを開発・保守運用するプロジェクトです。 サイトはリリースから6年程度が経過しており、会社の収益の柱となっている大規模なプロダクトです。 ## 担当領域について 開発チーム全体は10人程度所属しているなかで、4名程度で構成されたサブチームのリーダー兼エンジニアとして働いています。 リーダーとしてはメンバーの進捗管理やタスクのアサイン調整、業務委託メンバーの稼働調整が主な業務です。 エンジニアとして行っている主な業務は以下です。 - 新規機能の開発や既存機能の変更 - 他部署の要望対応 - マーケティング部からのクエリ作成依頼やLPの作成 - セールス部からの顧客リクエスト対応 - エンジニア採用（新卒・中途）におけるスカウトや技術面接 他にもスクレイピング用のクローラーを実装するなど、多岐に渡る業務を行っています。 ## 技術的なアピール点 前述した通りですが、サイトはリリースから6年程度経過しているため、一部技術スタックのレガシー化が起きていました。 サイトはRuby on Railsで作られたモノリシックなアプリケーションなのですが、jQueryやCoffeeScriptを使用しているリリース当時のままの技術スタックである部分が特に問題視されていました。これらをモダンなフロントエンドに置き換えることは開発効率を向上させたり、採用におけるブランディングに寄与したり、さらにはこれらの技術を触ったことがないエンジニアのオンボーディングコストをなくすことができるため、レバレッジの効く改善だと考え、着手しました。 具体的には、Vue.jsへの移行を段階的に進める施策を推進・実行しました。（現在も進めています） 厳密には、Vue.js自体は参画時に一部の画面で導入されていたのですが、日頃のタスクに奔走してなかなか拡大に着手できないような状況にありました。 特に複雑な状態管理を扱うフォームといった機能を開発する場面でVue.jsのようなモダンなフレームワークは真価を発揮するので、そういった際にVue.jsへの置き換えも込みでタスクとし、置き換えにかかるバッファも見積もり計上することでスクラムのスプリント中に無理なくこの改善に取り組めるような体制を整えました。 結果として、目的としていた要素に加え、jQueryやCoffeeScriptでは得られなかった高い再利用性も獲得することができました。

## プロジェクトの概要 見込み顧客を管理するSaaS型のプロダクトを企画開発・保守運用するプロジェクトです。 ベータリリースから契約社数が二桁台に増加するまでの 0.5 → 10 あたりのフェーズに携わりました。 また、開発手法にはスクラムを採用しており、1週間スプリントで企画や開発、改善を回していました。 ## 担当領域について 開発チームは2~6名規模で、そのなかで自分の役割はフロントエンド・バックエンド・AWSのインフラを横断して開発するフルスタックエンジニアでした。 少人数チームということもあり、開発以外にもプロダクトに関する業務には手広く関わっていました。具体的には以下です。 - 企画途中段階のアイテムを具体的な要件に落とし込んでいくリファインメントをFigmaやMiroを使いながらPO, デザイナ, 他エンジニアと行う - チームのエンジニア採用に参加し、求める候補者像の定義からスカウト、実際の面接に至るまでコミットする - （開発の周辺領域ですが、）機能を実現するために新たなアーキテクチャなどが必要になる場合は、設計をし、必要であればDesign Docを書き、他エンジニアと議論して仕様を固める - プロダクトを安定稼働させるために監視やバグ通知などの仕組みを導入・運用 ## 技術的なアピール点 大小様々な機能を開発しましたが、主要なものとしては、メール配信機能とそのメールのトラッキング状況（開封・本文中のURLクリックなど）を表示する機能を開発しました。 メール配信機能に関してはSendGridというメール配信SaaSを組み込んでSidekiqでジョブとしてSendGridのSDKを利用することである程度簡単に実現することが出来ましたが、トラッキング機能の開発に以下の懸念がありました。 - トラッキングはSendGrid側に登録したWebhook URLに都度通知としてリクエストが来る形 - プロダクトを使うエンドユーザーがこの機能を利用するため、事前に何通送信するか想定できない - 主にマーケティング目的で利用するというところで、一度の配信につき数千〜数万のメールを送信する（≒それに比例した量のWebhookリクエストが発生する） これらの懸念から、以下の課題が導出されました。 - シンプルにWebhook用の受け口をアプリケーションに用意すると、大量のWebhookリクエストがアプリケーションの負荷を急激に高めてしまう懸念 - 上記のためにオートスケーリングを施すことは出来るが、プロダクト本体ではなくWebhookを受けるためにオートスケーリングするいびつなアーキテクチャになる上に、シンプルにコストがかさむ - もしオートスケーリングが適用されきる前に大量のWebhookリクエストがアプリケーションに投げられると、コネクション待ちによるタイムアウト、もしくはエラーやメモリ不足によるプロセスの終了が考えられ、そうなった時に投げられていたリクエストの通知データを消失してしまう そこで、この解決策としてWebhookを受け止めるためのサーバーレスアーキテクチャを設計・構築しました。 このアーキテクチャの流れとしては、 - AWS APIGatewayでWebhookリクエストを受け止め、 - Lambdaにリクエストを渡し、 - LambdaがSQSにキューとしてリクエストのデータを流すことで、 - DynamoDBにデータをバックアップしながら、 - アプリケーションのDBとして用いているRDSにデータを追加していく ような形です。 これによって、高可用性、高信頼性、バックアップデータ、DBコネクションのリトライ処理、低コストによる実現など様々な恩恵を受けられ、無事にアプリケーションの主力機能のひとつとしてリリースすることができました。

## プロジェクト詳細 全国の医師・病院情報を掲載するWebサイトのコンテンツ管理モバイルアプリ開発プロジェクト。 特徴は以下の通り。 - コンテンツは医師自身が編集するためエンドユーザーは医師・医院関係者。 - これまでWebサイトでしか出来なかったコンテンツ管理をモバイルアプリでも提供することで医師がコンテンツを編集する心理的なハードルを下げ、編集の頻度を活性化することが狙い。 - iOS, Android両対応だが予算の都合からハイブリッドアプリの形で納品することが要件。 - プロジェクトメンバーはPM1名、PL1名、エンジニア2名、コーダー1名、デザイナー1名の体制で、エンジニアとして参画 ## 技術的なアピール点 上述した通りこのプロジェクトは予算が多くなかったため、私がアサインされた時点ではそれぞれのアプリ内データにHTML/CSS, JSなどWebViewに表示するためのファイルを埋め込む形で設計されていた。 これはハイブリッドアプリを実現するための手法としては一つの選択肢ではあったが、以下のような問題点が考えられた。 - アプリに埋め込む形で実装するので、簡単な文言修正が入るたびにアプリストアへアップデート申請が必要 - HTMLなどのリソースを直接アプリ内で呼び出すのでデバッグに時間がかかる - 今後の展開を見据えたとき、モバイル向けのWebブラウザ版が必要とされる可能性がある これらの問題を解決するために、リソースをアプリに直接埋め込むのではなく、Webアプリとして開発、サーバにデプロイし、アプリからはあくまでそのURLをWebViewに表示するのみに留め、アプリ内通知などネイティブアプリでしか出来ない機能はWebViewにUser-Agentを設定しWebアプリ側からそれを判別することでアプリ側の関数を適宜呼び出すような構成をPMに提案した。 この提案で自分の強みとしているWebアプリ開発のスキル（特にフロントエンドの複雑な状態管理の知見）をフルに発揮出来るような環境を整えた。 また、WebアプリとなったことでVue.jsのフレームワークであるNuxt.jsを採用することができた。 これらの施策によって、実際の開発ではNuxt.jsの強力な規約に支えられ、元々Vue.jsの開発実績を持っていた自分のスキルを発揮することでスピード感を持って開発することが出来た。 その結果、開発工数を3割程削減することに成功し、またプロジェクト自体も取り回しやすいアーキテクチャとなったことで今後のビジネス的な展開にもスムーズに対応することが可能となった。

## プロジェクトの詳細 マラソン大会運営サポートWebアプリ開発プロジェクト。 特徴は以下の通り。 - 大会運営会スタッフが利用する業務システム - マラソンのコースとコース上に配置するヒト・モノの配置図をブラウザで作成出来る - 作成したコース情報をPDF出力する機能を持ち、マニュアルとして配布したり警察・警備会社へ事前に提出することが出来る - PC・スマホ両対応 - チームメンバーはPM1名、エンジニア3名、デザイナー1名の構成 ## 技術的なアピール点 このプロジェクトには基礎的な機能をリリースした1次フェーズ終了のタイミングでアサインされた。 役割としてはフロントエンドがメインだったが、APIの実装・改修などバックエンドにも関わった。 しかし、アサイン当時は業務委託のエンジニアがバックエンドを一手に担っており、当社のエンジニアはフロントエンドのスキルしか持ち合わせていなかった。 そのため、以下のような問題やリスクが発生していた。 - バックエンドへの機能追加が発生するたびに業務委託エンジニアに依頼するしかなく、コミュニケーションコスト・金銭的コストの増加 - 業務委託しているエンジニアの離脱によるバックエンド側ソースコードのブラックボックス化 - クライアントから依頼された新機能の実装可否や工数感に当社の人間が答えられない このような問題を解決するために、当時始まろうとしていた次フェーズのタスク群の私へのアサインを、今までのフロントエンド/バックエンドの割り方ではなく機能単位としてはどうかとPMに提案した。 担当する技術の範囲が広がることから工数の増大を懸念されていたが、 - 元々フロントエンドに強みを持っていたこと、フロントエンドで採用されていたVue.jsは個人開発で使用した経験があり不自由なく読み書き出来るレベルに達していたこと - バックエンドはJavaを使用した案件(Servlet)の開発実績があったこと、同じくMVCフレームワークであるRuby on Railsを案件・個人開発で使用していたこと 上記2点のスキル・経験があったことと、業務委託のエンジニアにバックエンドの不明点を積極的に質問することで全体像をキャッチアップすることが出来た。 結果として納期に間に合わせる形でありつつ、社内にバックエンドがわかるエンジニアが存在する状況を作り上げ今後のメンテナンスリスクを最小限に抑えることが出来た。