BASE株式会社の技術ブログ

全590件

2020/10/12

ServiceDev所属、サーバサイドエンジニアの栗田です。現在私は、ServiceDevのチームに所属し、ネットショップ作成サービス「BASE」及びショッピングアプリ「BASE」の機能開発を担当しています。 BASEでは主にQ毎にプロジェクトチームを編成し、チームで主体となって機能開発を行っていきます。チームメンバー構成はプロジェクトの特性や規模により様々ですが、多くの場合、同じグループから1〜2名がプロジェクトにアサインされます。今回はとある長期間プロジェクトで感じた事や・実際にこのように進めたよというところをサーバサイドエンジニアの視点から紹介したいと思います。どんなプロジェクトだったか今回紹介するプロジェクトは「BASE」の拡張機能である「BASE Apps」の1つである「商品オプション App」を開発するプロジェクトでした。「商品オプション App」は商品にギフトラッピングやオーダーメイドで使えるオプションを設定できる拡張機能です。詳細は下記からご覧いただければと思います。 baseu.jp プロジェクトメンバー構成プロジェクトマネージャ(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レビューへの流れになりました。設計レビューについては、同じチームの宮村が記載した記事がありますので、そちらをご覧いただければと想います。 devblog.thebase.in 余談ですがシニアエンジニアは予定していた育休のタイミングと被ってしまい、実装には一切関わらないこととなりました。ピンチ！ｗ開発初期フェーズについて初期は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における長期プロジェクトのチーム開発の雰囲気は伝わりましたでしょうか？最後に長期間プロジェクトとなり辛い時もありましたがこの機能をリリースして、多くのショップオーナーさんから声をいただき、無事に機能を届ける事ができて本当に良かったと感じました。

サーバーサイド, フロントエンド, テスト, 設計

BASE株式会社 の技術ブログ

コンテンツ

BASE株式会社の技術ブログ