はじめに
こちらは バイセルテクノロジーズ Advent Calendar 2024 の19日目の記事です。 昨日は本田さんによる運用工数を抑えつつ安定稼働を実現するための工夫でした。
こんにちは。テクノロジー戦略本部開発1部でフロントエンドリードエンジニアをしている辻岡です。
私たちのチームは、もともとスクラムを用いて開発をしていました。しかし、プロジェクトのデリバリーを優先する必要が生じたため、開発体制を見直すことになりました。本記事では、開発スピードを向上させるための新しい体制への移行プロセスと、その過程での懸念、そしてそれらに対する対策について詳しく解説します。
スクラムを導入した目的・背景
当時、私たちのチームはメンバーの入れ替わりが激しく、新しいメンバーが多くを占めていました。そのため、ドメイン知識が不足しており、互いに知識を補完し合える体制が求められていました。また、メンバーが変わっても開発スピードが落ちない、属人化しない体制が理想でした。
このような背景から、私たちはスクラムを開発体制に取り入れました。
リソース効率が高い状態は、各メンバーが個々のタスクを効率的にこなすことです。一方でスクラムの目的は、数人が同じタスクを共同でこなしフロー効率を高めることです。
フロー効率を高めることで、チーム全員が同じ仕様を理解し協力して作業を進めることができます。その結果、仕様や技術に関するレビューがしやすくなり、手戻りやバグの防止が期待されます。
私たちのチームでは、スクラムガイドをベースにしつつ、自チーム向けにイベントをアレンジして構成しました。以下の図はそのスクラムイベント一覧を示しています。
スクラムガイドと少し異なる点もあります。私たちのチームでは、リファインメントやスプリントプランニングでタスクの詳細化や優先度の並び替えに時間をかけすぎて仕様や技術に関するレビューが疎かになってしまうという課題がありました。なので事前にタスクの詳細化や優先度の並び替えを行い、リファインメントでは仕様の把握やレビューに集中できる環境をつくっていました。
スクラムをやめるきっかけ
ある時から、チームを取り巻く状況が変化し、デリバリーを優先することが求められるようになりました。
プロジェクトを完遂するための工数を見積もった結果、想定していた納期から1.5ヶ月ほど遅延することが判明しました。
納期の変更を検討しましたが、私のプロジェクトの進捗は他の依存プロジェクトにも影響を及ぼす可能性がありました。さらにインフラの維持費などのコスト増大につながる可能性も考えられました。そのため、致命的な理由がない限り変更しないと判断をしました。
開発以外のQAの実施期間などの短縮や、スコープの変更なども検討しましたが、開発期間がボトルネックとなっておりそれをどうにかして短縮する必要がありました。
そこで、私たちは開発体制を抜本的に見直し、デリバリーを早くする方法を模索することにしました。
デリバリーを早くするための品質調整
プロジェクトのデリバリーを優先するために、私たちは品質を一定程度諦めることを決めました。しかし、可能な限り品質を高めるために何ができるか、チームで話し合いをしました。
話し合った結果、タスクの詳細化やそれに伴うスクラムイベントがボトルネックになっているのではないかという意見が出ました。これを削ることで得られるメリットとデメリットを比較しました。
メリット
- 一人あたり週4時間ほど作業時間を捻出できる
デメリット
- 属人化の進行やレビューの効果が失われる
- リリース時にバグや手戻りが発生しやすくなる
- 仕様の把握が不十分であることに起因して、障害時に迅速な原因特定が難しくなる
- リリース後の開発スピードの低下
両者を比較して、作業時間の捻出のほうが私たちのチームにはメリットが大きいと判断し、タスクの詳細化を廃止する方針に決めました。
しかし、デメリットについても対策を打たずに放置するわけではなく、後述の「短期的な懸念」や「中長期的な懸念」に記載の方法でカバーすることにしました。
一機能一チーム制
一定属人化は許容するうえで、私たちのプロジェクトに最適な開発体制を検討することにしました。
私たちのプロジェクトでは機能1つをリリースして価値があるのではなく、複数の機能が揃って初めて価値があるものでした。なのでリリースまでに必要な機能を確実に揃えることが重要でした。それゆえ従来のフロー効率を求めて一機能を早くリリースするのではなく、並列で開発してリリースするほうがプロジェクトにマッチしていると考えました。
そこで一機能ごとに担当のエンジニアを割り振る開発体制を取ることにしました。
こちらの体制には先述した通り、属人化してしまうというデメリットがありますが、従来の体制と比べて機能を作る際の関係者が少なく、その結果コミュニケーションコストが少なくすみます。それによって開発完了までの時間の短縮がさらに期待できると考えました。
上記の体制にともない、各機能のリリースが完了の基準となるため、スプリントという時間的な区切りをなくしました。
スクラムイベントの変更・廃止
一機能一チーム制に伴い、スクラムに沿わなくなったイベントがあるので見直すことにしました。さらに非同期でできる会議体がないか検討し、作業時間を捻出できないか考えました。
リファインメント
タスクの詳細化がなくなったことで、共有する場が必要なくなり、ポイントも見積もることができないため廃止することとしました。
プランニング
タスクのアサインに関しては機能ごとに担当が割り振っているので必要なく、スプリント自体無くなったので、廃止することとしました。
デイリー
スプリントがなくなったので、各自に割り振られた機能の進捗確認を行う場としました。 各機能の担当者は、PDMに共有している見積もりからのズレを確認することにしました。そうすることで計画に遅れそうな場合すぐ軌道修正できます。
エンジニアデイリー
エンジニアデイリーはデイリーと重複する内容がありました。さらに共有する事がない場合もあるので非同期でメッセージでのやり取りとしました。
スプリントレビュー
スプリントは廃止しましたが、成果物を共有して早めに軌道修正できることから、従来のスプリントレビューと同様に週次で共有会を行うこととしました。
さらにこのイベントの趣旨とは異なりますが、プロジェクト全体の進捗や追加の対応などを確認する場がなかったので、全体のタイムラインの確認もこの会議に含めて確認していました。
レトロスペクティブ
スプリントはやめましたが、開発体制変更による課題を定期的に洗い出し、改善を図るために継続して開催することとしました。
これらの結果としてタスクの詳細化に費やしている時間を合わせると、一人あたり週に6時間半ほど作業時間を捻出できました。
一機能一チーム体制による懸念と対策
一機能一チーム体制に移行したことで、いくつかの懸念点が浮上しました。これらの懸念を、プロダクトのリリースに影響を与える短期的なものと、運用上の問題として中長期的に影響を及ぼす可能性があるものに分けて対策を検討しました。 短期的なものは、リリース前に対応し、中長期のものはリリース後に対応することとしました。
短期的な懸念
仕様に関するレビューの漏れによるバグ・手戻り
リファインメントを行わないことによって仕様の理解不足やレビューの不備があり、バグや手戻りの発生するリスクがあります。 対策としては、仕様の漏れは一定あるとして、機能の規模が大きいものは２週間、小さいものは１週間とバッファを設けることにしました。
技術的な懸念点のレビュー漏れによるバグ・手戻り
リファインメントで行っていた技術的な懸念点の洗い出しができなくなったことで、バグや手戻りの発生する可能性があります。 対策としては、各機能でDesign Docの作成とチーム内でレビューを必須化しました。 運用方法としては、機能を作る前に、以下のテンプレートを用いてDesign Docを作成します。そして、非同期でレビューをチームに依頼します。承認をもらい開発に取り掛かります。
中長期的な懸念
障害対応の遅延
属人化が進むことで、仕様を把握していないことによる障害発生時の対応や開発スピードの低下のリスクがあります。 対策としては、ペアプロなどチーム内での知識共有を促進するような取り組みを実施予定です。
結果と成果
チームのミーティングの平均時間は開発体制の変更後から徐々に減少しています。
チームの活動量（マージ済みプルリク数の合計）は導入後に大幅に増加しています。
現在、最終調整段階ですが、手戻りやバグの報告件数に変化はほぼありません。
まとめ
プロジェクトの性質に合わせて柔軟に開発体制を変えることができました。事前に懸念点を洗い出して短期的な懸念を対策をしたことで、リリースまでデリバリーを優先しながら、品質もある程度担保できました。
品質については、完全に犠牲にすることなく、必要な部分での調整をすることで、プロジェクト全体のバランスを保つことができました。
チームメンバーも今の開発体制に納得感をもって開発を進められています。
中長期的な懸念はまだ残っているので、そちらは今後解決に向けて取り組み改善を進めていこうと思っております。
最後に
バイセルでは一緒に働くエンジニアを募集しています、興味がある方は、以下よりご応募ください。 herp.careers 明日の バイセルテクノロジーズ Advent Calendar 2024 は遠藤さんによる 「ジョブエクスプローラでBigQueryのボトルネックをリサーチする」です。 お楽しみに！
