「HRMOSタレントマネジメント」目標・評価チームでは日々スクラムを実践し、アジャイル開発を目指しています。 私たちのチームは開発の中で、以下の課題に直面しました。
🚨 開発者にとって、他の開発者やプロジェクトへのサポートや連携に入りづらい
仕様や見積ドキュメントが標準化されておらず、開発案件の進め方や知識が属人化していました。
これにより、開発者がどう他の開発者やプロジェクトへのサポートや連携に入って良いのかわかりづらくなっていました。
🚨 PO・EMにとって、開発の計画が立てづらい
サポートへの入りづらさによるコミュニケーション工数の増加、および仕様見落としによる手戻り工数の増加により、ベロシティ見積の信頼性が低下していました。
これにより、プロダクトオーナー（以下、PO）・エンジニアリングマネージャー（以下、EM）は不測の事態に備えたバッファ工数込みで見積らざるを得ず、開発の計画が立てづらくなっていました。
🚨 チームにとって、開発速度と内部品質のバランスを保ちづらい
開発機能に関する知識が属人化していることで、その機能についての知識が個々人でムラがある状態となりました。
これにより、動作確認項目のレビュー精度が下がっていました。
また開発チームがQAまで広く担保していく方針を採用したことで、より詳細なレビューが必要となっていきました。
💡 アジャイル開発の見積プロセスの型化：スプリントゼロ
上記の課題に対し、私たちはアジャイル開発における見積プロセスの型化によって解決しようと考えました。
見積プロセスはエピックをスプリントとして開発する前に行う、いわば０（ゼロ）地点の取り組みです。
そこで型化したプロセスを「スプリントゼロ」と名付けました。
スプリントゼロでは、上記の課題に対して以下の状態の実現を目指します。
- より簡単に、チーム内でサポートや連携に入ることができること
- より簡単に、開発計画のコントロールができること
- より簡単に、開発速度と内部品質をバランスよく担保することができること
スプリントゼロとは
スプリントゼロとは、4つのフェーズで構成されます。
- ビジネスアナリシス
- 分析・設計
- 体験開発
- ストーリーポイント(以下、SP)見積
スプリントゼロのイメージ
🏃♀️ビジネスアナリシス
ビジネスアナリシスフェーズでは、リリースする機能の、仕様の大枠が固まります。 この仕様は適宜、チームを巻き込んで決定されます。 これにより、チームの納得が得られた状態で機能開発に臨むことができます。
1. POが叩き台を作る
POが顧客やステークホルダーのフィードバックや、利用状況を整理します。
それらを踏まえ、以下を仮説として定義します。
- お客様の目的
- 業務価値
- ドメインモデル
2. チームでレビューをする
POが定義したものを踏まえ、以下をエピック開発におけるプロジェクトマネージャー(エピック主管)をはじめとしてチームで定義していきます。
| 成果物 | 詳細 |
|---|---|
| 業務要求 | HRMOSのシステムに依存しない、お客様の要求 |
| ユースケース・ドメインモデル複合図 | お客様が実際にどう利用するか：「ユースケース」をドメインモデルと複合して図にしたもの |
| やらないこと | 本機能で提供しないこと |
工夫をしているところ
いずれの成果物もドキュメントにして、チームの開発者・POが相互レビューを行います。
そして、複数のOKをもらうことで成果物が出来上がったとします。
これにより、知識が属人化せず、チーム内で平準化されます。
🏃♀️分析・設計
分析・設計フェーズでは、開発者が機能開発時の不安点を挙げては実際に手を動かして解決を図ります。
このプロセスを通して技術的な解像度を上げていき、どうすれば機能が出来るかのイメージをチームに共有します。
これにより、後続のSP見積フェーズにてより詳細な見積を構築できたり、どのチームメンバーであっても開発に自信を持って取り組むことが可能となります。
1. 作り上げる機能をよりシステム向けに具体化していく
順番に以下の成果物を作っていきます。
| 成果物 | 詳細 |
|---|---|
| システム要求 | HRMOSのドメインモデルに即した要求を記述したもの |
| プロトタイピング | 開発者がタイムボックスを切って実装してみたもの。ユースケースの実現そのものに不安が多い場合に実施する。ドキュメントはソースコードで代用可能 |
| 課題リスト | 実現手段に不安が多い点をまとめたもの。「技術調査：TechSpikes」に供される |
| 概算見積 | 実現までにどれぐらいの工数を要するか、概算をまとめたもの |
2. 技術的に実現可能かを検証し、より機能を具体化する
概算見積を終えた後、開発者が「課題リスト」にあるものについて技術に実現可能かを検証します。
検証された結果はチームに共有され、各位がどうすれば良いかを把握できるようにします。
| 成果物 | 詳細 |
|---|---|
| 技術調査：TechSpikes | 課題リストを技術検証したもの。曳光弾やロバストネス図等を活用したり、性能検証を実施する。ドキュメントはソースコードで代用可能 |
工夫しているところ
いずれの成果物も、それぞれ特定の個人ではなく任意の開発者から担当をアサインして作成します。 また「ビジネスアナリシス」フェーズ同様、開発者の相互レビュー・複数人のOKをもらうことを必須としています。
🏃♀️体験開発
体験開発フェーズでは、プロダクトデザイナー（以下、PD）・開発者が画面仕様の検討を行い、MVPに足るナビゲーションの合意を得ます。 これにより、スクラムチームとして最初のインクリメントが「ちゃんと使える」状態で終わらせられると共に、最小コストで済むものに対して追加費用を発生させずに済むことができます。
1. 画面仕様が実用最小限（Minimum Viable Product:MVP）か確認する
PDが作ってくれた画面仕様（Figmaや、UIフロー図）を振り返ります。 ここで開発者とデザイナーで理想像の認識を共有しつつ、MVPであるかについて検証を行なっていきます。
工夫しているところ
弊チームはMVPを意識して開発しています。
実際のところ、画面仕様の初期案であるUIフローはビジネスアナリシスフェーズにてPDにより準備されています。
しかし、それに対するUI自体の検証は分析・設計フェーズでは為されません。そのため本フェーズで開発者とともに検証されます。
一方で無用な工数を省くためにも、エピック主管・PO・EMが問題ないと判断できれば敢えて開催しないこともあります。
🏃♀️SP見積
SP見積フェーズでは、エピックにかかるストーリーポイント(SP)を見積ります。 それを用いて、スクラムチームとして開発計画を構築します。 これにより、各位がどう仕事に取り組むかを調整したり、ステークホルダーにリリースの時期感を共有できるようになります。
1.仕様書を準備する
まずは技術仕様書(TechSpecs)とテストケース(QAの書)を準備します。
2.見積と計画を作成する
TechSpecsとQAの書が準備できたことで、実装・QAの見積が出来るようになります。 それを用いて、SP見積と今後の開発計画を準備します。
| 成果物 | 詳細 |
|---|---|
| TechSpecs | 技術仕様書。ユースケースごとのシステムの振る舞いや、制約（バリデーションなど）の認識を揃える |
| QAの書 | テスト条件とテストケースの記載があるドキュメント。実装前に観点をまとめ、QA内容の認識と工数感を揃える |
| SP見積 | スプリントゼロ後のSPを見積したもの。これとベロシティより、リリース予定を立てる |
| 開発計画 | スプリントゼロ後の開発計画を図示したもの。週次で進捗を把握できるようにする |
工夫しているところ
いずれの成果物も、これまでのフェーズと同様に、それぞれ特定の個人ではなく、任意の開発者から担当をアサインして作成します。 そして、開発者の相互レビュー、複数人のOKをもらうことを必須としています。
SP見積の成果物は以後の開発に非常に重要です。
それぞれ弊チームで使っている資料を一部図示し、メリットを解説します。
成果物について
| TechSpecs | QAの書 |
|---|---|
| ・仕様や制約をステークホルダーに説明できます ・開発者が実装中に悩んだ時に振り返られます ・仕様変更を追記し、チーム内で連携ができます |
・開発者が実装中に悩んだ時に振り返られます ・観点を追記し、チーム内で連携ができます |
|
|
| SP見積 | 開発計画 |
|---|---|
| ・2点見積より不安量が可視化され、チームが難所を把握できます | ・難所が来る時期を把握でき、計画を調節できます ・リリース時期が可視化され、ステークホルダーに説明しやすくなります |
|
|
🏃♀️開発
以上でスプリントゼロが完了し、本格的に開発に入ります。
スプリントゼロ以降の取り組み
スプリントにおいては以下を実施することでチーム内の状況を認識合わせしています。
- SprintPlanning 第1部・第2部: 開発する上でのTODOを、チームで把握する
- チーム内ガントチャートの作成: 進捗の概算を、チームで把握する
- 朝会、昼のミーティング: 進捗や同僚の様子を、チームで把握する
結果
見積に関わるプロセスを「スプリントゼロ」として型化したことで、以下の目的を実現できました。
- より簡単に、チーム内でサポートや連携に入ることができる
- より簡単に、開発計画のコントロールができる
- より簡単に、開発速度と内部品質をバランスよく担保することができる
それぞれの恩恵について、具体的な事例を共有します。
👍 チーム内でサポートや連携に入ることができる
リカバリしやすくなり、心理的に安全な状態で休暇が取りやすくなりました。
- 仕様や見積をドキュメントにすること、そして相互レビューが標準化されたことで、チーム内の互換性が高まりました
- 誰かが休んでもすぐにリカバリに入れる体制になり、各メンバーが、必要に応じて心置きなく休むことができています
👍 開発計画のコントロールができる
見積の信頼性が向上し、見通しが良くなりました。
- 業務要件やシステム仕様から開発者が相互にレビューをしているため、見落としがかなり減り、概算・詳細見積の信頼性が高まりました
- 大きなプロジェクトが3つ並行していた時は、それぞれの見積からPOや開発者が適切に優先順位を判断できるようになりました
👍 開発速度と内部品質をバランスよく担保することができる
内部品質が向上し、安定したリリースができるようになりました。
- 相互にレビューする文化が醸成され、品質が向上。安定したリリースが実現できています
- 導入後、リリースしてきた機能についてインシデント発生件数０を実現しています
スプリントゼロで意識していること
ここまでスプリントゼロについて解説してきましたが、改めて私たちが意識していることを紹介します。
🤝 チームみんなでドキュメントを作成、レビューする
各フェーズの成果物はドキュメント化されます。
ドキュメントのタスクは、それぞれ特定の個人ではなく任意の開発者から担当をアサインして作成します。※前述の「エピック主管」がオーナーシップを持ちます。
また、開発者の相互レビュー・複数人のOKをもらうことを必須としています。
このメリットとして、以下の2点があります。
- 担当していなくても皆がチームで作っている機能を自分事として把握できるようになる
- 見落としを防ぐことができる
🤝 気を利かせすぎず、MVPを実現するための仕様を考える
スプリントゼロでは、お客様の要求を叶える最小限の機能、つまりMVPをリリースすることが目的です。 アジャイルソフトウェア開発宣言でも言及されているように、弊チームでは動くソフトウェアやシンプルさに価値を置きます。
その上で、リリース後にはカスタマーサクセスより共有いただくお客様の声やGoogleAnalyticsから、活用状況を注視しています。 そのフィードバックを受けながら機能の強化・改善・撤廃まで検討をします。
このメリットとして、以下の2点があります。
- お客様に最速で機能を届けられる
- リリースされる機能が比較的シンプルな設計となり、機能のメンテナンスや撤廃がしやすくなる
まとめと展望
スプリントゼロにより、「より簡単に、開発計画のコントロールができる」「より簡単に、チーム内でサポートや連携に入ることができる」「より簡単に、開発速度と内部品質をバランスよく担保することができる」ようになりました。
引き続きスプリントゼロを活用しつつ、ブラッシュアップを進められたらと思います。
余談
記事内で「エピック主管」について触れました。
本ロールを導入したことで、PO・EMの業務負担の削減を実現しています。
こちらの記事で紹介していますので、ぜひ読んでみてください！
「メンバー全員が開発リードになれる、「エピック主管」という仕組み」
