アジャイル開発における「ニーズの変化」への対応方法

DADのフェーズ

連載前半の方向付けのあたりを思い出してみましょう。システムの方向性を宣言するアウトプットとしてビジョンを説明しましたが、その記述内容はまさに図2に示した要求の構造の左側にある［投資テーマ］−［エピック］−［フィーチャー］を表していると思いませんか？

図4：フェーズ軸で見るスキーム

図4は、フェーズという軸でコミュニケーションの意味合いがどう変わるかを表したモノです。方向付けフェーズでは、投資テーマから主要なフィーチャーの導出と合意形成が活動の主軸になります。一方、構築フェーズに入ると、合意されたビジョンを実現するよりよい解（＝フィーチャーとストーリーの集合）を探索するという意味合いに変わります。変更と合意形成という意味では、「左向きのベクトル」の活動が重視されます。

また時間軸の観点で考えておくべきことは、どのタイミングでどの範囲でどの点についてデモ等を含めた「実証」を行うかです。イテレーション最後のデモで主要な利害関係者を毎回招集するのか、あるいは何回かに1回の割合で超偉い人も招集するのか、といった点もある程度決めておけば、より上位の利害関係者も参画しやすくなります。

優先順位付けと選択のロジック

今までも、そしておそらくこれからも、ずーっと悩ましいテーマが「どうやって優先順位を付けるか」と「どうやって発散をコントールするか」でしょう。
提供する機能の優先順位付けのやり方には、これまでもさまざまなものが提案されています。SAFe（そしてAgile Manager）の中では、「重み付けされた最短の作業から着手（WSJF：Weighted Shortest Job First）」という手法を提唱しています。従来の優先順位付けが開発労力に対する顧客価値という単純なROIモデルに基づくのに対し、時間軸にそったコストへの影響（遅延コスト）を加味してより経済合理性に沿った優先順位付けをしようとするアプローチ...　とだけ書くとなんだかわからなくなっちゃいそうですが、これについては書籍「アジャイルソフトウェア要求」に詳細な議論があるので、ぜひご覧になることをお奨めします。

それよりもここで紹介しておきたいのは、レンジドバーンダウン（Ranged Burndown）という見方です。その理由を挙げると以下となります。

• WSJFは経済性という意味では高い効果が期待できますが、その一方でちょっと「上級者向け」という気がします。本連載で想定している対象者を考えると、「従来の相対的なROIでもいいから、とりあえずエンタープライズ・アジャイルっぽく開発を廻せるようになってくれ」と、筆者が思っているから。
• とめどなくあふれ出てくる要求追加や変更を制御するには、開発者の努力だけではなく、要求を出す側の自制心も必要。その自制心を引き出すのに有効なテクニックだから。

では簡単に紹介しておきます。レンジドバーンダウンの目的は、プロジェクトの終了時期見積りの「範囲」、つまりベストケースとワーストケースを可視化することです。

図5：レンジドバーンダウンの基礎

図5がレンジドバーンダウンの基本的な考え方を表したモノです。レンジドバーンダウンでは2つのベロシティを考慮します。「グロスベロシティー」は、あるイテレーションで完了した作業量です。おなじみのバーンダウンチャートで使うベロシティです。しかし実際にはイテレーション中に作業が追加されることが珍しくなく、その分ベロシティは落ちるはずです。これを表現するのが「ネットベロシティー」です。
つまり納期という観点から見ると、グロスベロシティーがベストケース（最短納期）、ネットベロシティーがその時点で予測されるワーストケース（最長納期）となります。

図6：グロスベロシティーとネットベロシティー

（ディシプリンド・アジャイル・デリバリー　エンタープライズ・アジャイル実践ガイドより引用）

図6にレンジドバーンダウンの換算表を示しておきましょう（DAD本から引用しました）。この例では、第2イテレーションまではストーリー追加がないので、グロスもネットも同じです（つまり普通のバーンダウンと同じ状態です）。

しかし第3イテレーション以降では、追加が発生しています（おそらくデモを見て「ちょっとちがーーーう！」というフィードバックをもらったのでしょう）。そうなると、残りのイテレーション数の見積りに幅が出ます。グロスを使って計算した場合と、ネットを使って計算した場合の納期が異なるからです。このように、新規に追加した作業の量によって納期がどのような影響を受けるかを明示することで、要求を出す側も同じ問題認識（「期日までにリリースできないかも!?」）を共有しようというものです。

詳しくはDAD本に説明があるので、そちらもぜひご覧ください。

軽くまとめ

利害関係者との合意形成は方向付けで終わるわけではなく、むしろそこから始まります。利害関係者の特性に合わせた適切なコミュニケーションのスキームがなければプロジェクトはあっという間に泥沼化します。エンタープライズ・アジャイル関連の本が、要求の管理周りに多くのページを割り当てる傾向にあるのは、洋の東西を問わず「いずこも同じ」なのかもしれません。

次回は最終回なので、移行フェーズを紹介したうえで、全体のまとめに入りたいと思います。