ServiceDev所属、サーバサイドエンジニアの栗田です。 現在私は、ServiceDevのチームに所属し、ネットショップ作成サービス「BASE」及びショッピングアプリ「BASE」の機能開発を担当しています。
BASEでは主にQ毎にプロジェクトチームを編成し、チームで主体となって機能開発を行っていきます。
チームメンバー構成はプロジェクトの特性や規模により様々ですが、多くの場合、同じグループから1〜2名がプロジェクトにアサインされます。 今回はとある長期間プロジェクトで感じた事や・実際にこのように進めたよというところをサーバサイドエンジニアの視点から紹介したいと思います。
どんなプロジェクトだったか
今回紹介するプロジェクトは「BASE」の拡張機能である「BASE Apps」の1つである「商品オプション App」を開発するプロジェクトでした。 「商品オプション App」は商品にギフトラッピングやオーダーメイドで使えるオプションを設定できる拡張機能です。詳細は下記からご覧いただければと思います。
プロジェクトメンバー構成
- プロジェクトマネージャ(PM) & ディレクター 1人
- フロントエンドエンジニア 1人
- サーバサイドエンジニア 3人 (開始 1人, 最終的に3人)
- ネイティブアプリエンジニア 2人
- デザイナー 1人
キックオフからリリースまでの期間
10ヶ月ぐらいほど
私の立ち位置
サーバサイドエンジニアのまとめ役的な立ち位置でした。 初めはサーバサイドエンジニアは1人でしたが、最終的に3人に増員し 私は開発ディレクションをやりつつ、他のメンバーと共に開発をしていきました。 エンジニアリングマネージャ(EM)から私へ期待されていた事は 「とにかく不確実性を下げて、プロジェクトをコントロールできる状態にして欲しい」でした。 具体的には
- 日々の開発の進捗を把握して、プロジェクトメンバーやEMに共有すること
- 不確実な領域をどんどん触っていき想定外なことを少なくしていくこと
- 不安要素を取り除くため、部分的な本番化をしていき、また各フェーズのリリースの計画を建てること
- リリースに向けた現実的な進捗を把握して、EMと人員計画の相談をすること
などを行いながらプロジェクトを進めていきました。
どんな特色のあるプロジェクトだったか
商品オプションは、無料・有料の商品オプションを商品に複数個紐付けられるという仕様で、今まで「BASE」では注文の価格の演算の概念が増えるという事例はほぼなく、注文の価格はあらゆる箇所に影響するので、サーバサイドエンジニアの私からすると「システムの全体に関わりかなりの工数がかかりそうだな?どうしようかな?」というのがプロジェクトが始まった当初に思っていた事でした。 実際に影響があったアプリケーションは社内用の管理画面やバッチ処理なども含めて9つほどありました。
リリースについては複数のフェーズがある事が当初よりわかっており
- デザインテーマ向け(ネットショップ作成サービス「BASE」のデザインテーマを作成していただいているディベロッパー向け)
- ショッピングアプリ「BASE」向け
- ネットショップ作成サービス「BASE」向け
の3つのフェーズがある事が見えておりました。
それぞれにクリティカルパスが存在したので、タスクのボトルネックが発生しないようにプロジェクトを進める必要がありました。3つのフェーズの進行については プロジェクト内で週次で定例MTGを行い、PMが中心になって進捗確認をこまめに行い進めていきました。
見積もり・設計フェーズについて
以前からこの機能をリリースしたいという想いは社内にあり、要件はある程度固まっていました。 ので要件定義フェーズはあまりなく、見積もり・設計が始まりました。 今思えば、私はプロジェクト開始当初、入社して1年も経っていなかったので サーバーサイドのシステムの全体像は正直わからない所もありましたが、とりあえずやってみる事にしました。 見積もりの叩きを作成したのですが、規模も大きく、怪しい箇所も多いので自分1人で進めるのは危険だと判断して、EMに相談して1人のシニアエンジニアに見積もり・設計のサポート役としてアサインしてもらうことになりました。 そして、見積もり・設計がある程度進んだ所でチームレビュー・CTOレビューへの流れになりました。 設計レビューについては、同じチームの宮村が記載した記事がありますので、そちらをご覧いただければと想います。
余談ですがシニアエンジニアは予定していた育休のタイミングと被ってしまい、実装には一切関わらないこととなりました。ピンチ!w
開発初期フェーズについて
初期は1人で進めていましたが、少なく見積もっても6ヶ月以上かかりそうと見えており、1人でやるのは難しいとEMと共有認識があったので、EMに2人目のエンジニアをアサインしてもらうように動いてもらいました。 (BASEでは、以前はプロジェクトにサーバサイドエンジニアが1人でアサインされる事もあったのですが、最近はサービスの成長もあり、システムが複雑化していってるので、2人以上のアサインになることが多いです)
2人目のエンジニアのアサインを確保できた時は、ある程度プロジェクトも進んできたので、リリースターゲット月を決める必要がありました。特にどのQに収めるのかどうかは、BASEの開発組織として大きな関心事でした。 見積もりは終わっていたので、タスク一覧表はできていましたが正直、精度や抜け漏れがあるかどうか不安だったので、新しくアサインされたエンジニアと2人で時間をかけて全量確認する事にしました。
長期なプロジェクトだったので、ここで2人の目線を合わせる事が後々に響いていってとても大切だったと感じました。
開発フェーズに感じた事や・実際にこのように進めたこと
- 他のチームが動きやすいように、データの生成の流れに沿って開発を進める事が効率的だった。 一連の流れで開発できた方が開発の進捗も実感できるしフロントエンド・ネイティブアプリの開発がしやすくなります。
- 全部リファクタする訳にはいかないので、部分的に改修して先に改修とテストだけデプロイした。
- 嬉しい悲鳴で他のプロジェクトがリファクタとConflictする事もあった。逆に更に発生しないように積極的に本番化した。
- サーバサイドエンジニアチームで日時で相談会、MTGをして相談しやすい環境を作った。
- プロジェクト途中でコロナ期間へ入ったのでより頻度の高いコミュニケーションを取るようにした。
- 必要に応じてリモートではなく会社に集まった。
- リリースターゲットに開発を収める事が難しいとわかったので、ラスト3ヶ月はEMと連携して3人目のサーバサイドエンジニアをアサインしてもらった。
※ 前提:BASEでは並行して色々なプロジェクトが走っていていたり、負債が残っているコードも存在します。
QAテスト・リリースフェーズに感じた事や・実際にこのように進めたこと
- 品質が保てたものから、既存の不具合がでないようにガンガンデプロイしていった
- 全部で9つアプリケーションあったがコアとなるカートや決済の処理を除いて、ほぼ先出しでリリース前に本番化する事に成功した
- リリースによってデータが破壊的にならないようにして、いつでもリバートできるような計画をした
- QAテスト3つのフェーズがあったので、それぞれで必要な最小限を作成してQAテストを進めていった
- QAテストで必要なデータ一式をPMが用意してくれた為、開発でバタバタしていたが、効率に進める事ができた
- 3つのフェーズに分かれていたので、段階的に品質が上がっていき、不具合があった場合でも早期鎮火をする事ができた
- CTOとの本番化についての交渉をした
- BASEでは様々な事情があり、ステージング環境で複数日検証する事を許可しておりません
- 今回はリリースの規模と天秤にかけて特例をいただき、複数日検証をする事によって安全なリリースを可能にした
- リスクを分散させる為に各フェーズの機能の本番デプロイの日とユーザー公開日を分けた
まとめ
今回10ヶ月と長いスパンでしたが、上記でお伝えしたような事を考えながらチーム開発をしていきました。 BASEにおける長期プロジェクトのチーム開発の雰囲気は伝わりましたでしょうか? 最後に長期間プロジェクトとなり辛い時もありましたが この機能をリリースして、多くのショップオーナーさんから声をいただき、無事に機能を届ける事ができて本当に良かったと感じました。