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

軽くおさらい

早いモノで、この連載も残すところ2回。「そういえば初回で、『今後の予定』って紹介したなぁ。どんなんだったっけかな」と振り返ってみたところ（表1）......

表1：本連載2回目以降の計画と実績

...あれ？　...あれれれ？まぁその昔、当ThinkITで連載企画！　と華々しく立ち上げたものの、1回で終わった「黒歴史」を持つ筆者としては「連載という形になった」ことで、もう満足なのですよ、すでに（ザ・ヒラキナオリ）。

ディシプリンド・アジャイル・デリバリー（Disciplined Agile Delivery、以下DAD）の特徴であるゴール駆動について、前回は構築フェーズのゴールのうち「アーキテクチャを早期に実証する」を取り上げました。話を進める前に、ポイントを確認しておきましょう。

アーキテクチャへのアプローチ

DADにおけるアーキテクチャへのアプローチを、時間軸やチーム編成を絡めてご紹介しました。統一プロセスのように、アーキテクチャにフォーカスしたフェーズ（推敲フェーズ）を明示的には設けていませんが、だからといってアーキテクチャを軽視しているわけではありませんので、誤解のないように。構築フェーズのイテレーションの中で、アーキテクチャのリスクを解決するというのは早期に取り組むべき重要なアイテムとして扱われます。

リスクと価値のライフサイクル

DADでは、これまでの価値駆動（ビジネス上の高い価値を提供するモノから実装するアプローチ）から、技術的なリスクとビジネス上の価値とのバランスを取りながら各イテレーションでの開発内容を決めていくというアプローチを採ります。エンタープライズ・アジャイルの背景にある問題意識（例えば、いろんなシステムが関与しあう複合システムでの統合の複雑さ）を考えれば、このアプローチの重要性がご理解いただけるかと思います。

安定化とリズム

「3Cリズム」ってありましたね（「なにそれ？」って方は第4回へ戻りましょう）。「安定化ってCI（継続的インテグレーション）のこと？」って質問が...　いやいや、ちょっと違います。

「CIで日に何度も統合」というのは、アジャイル開発において決定的に重要な要素だと思いますし、Jenkinsあたりでブンブン廻していただきたいところです。しかし「統合できる」という話と、「実用に供せるレベルのプロダクトになった」という話は別物です。安定化とは、各時間軸（「プロジェクト期間」、「フェーズ」など）の中の、ある期間の役割であり位置づけです。安定化とは機能を作り込む時期ではなく、「磨き上げる時期」と言えばイメージが湧くでしょうか？

前回までの確認ができたところで、構築フェーズのもう一つのゴール「利害関係者のニーズの変化に応える」に話を進めていきましょう。そこは、魑魅魍魎...　もとい、多様な利害関係者が跋扈する世界なのです。

なぜ開発者はユーザを巻き込むことに「どんびき」なのか？

開発に携わる部門にお伺いして、いつもおもしろいと思うのは、「ユーザを巻き込む」話になると実際のシーンを想像して「どんびき」されるお客様が多いことです。これは、筆者がお邪魔している組織の多くが、ウォーターフォール文化だからでしょうか？　しかし「ニーズの変化に応えよう！」と言っているのに、いきなりどんびきされてしまっては話が先に進みません。

なぜ「どんびき」になってしまうのか、過去のトラウマをひも解いてみることも意味があると思います。どんびきしていた開発者に話を伺うと、ユーザ部門と開発部門との関係性について、程度の差こそあれ「対立の構図(図1）」ができているのがよく見られます（といいつつ、「筆者自身のトラウマ」も顔を出しているような･･･）。

図1：ありがちな対立の構図

もちろん、対立の原因がすべて開発技法に帰着するわけではありませんが、ウォーターフォール型の「早い段階で要件の詳細をすべてフィックスする」ことの無理が、負の効果をもたらしていることもまた否定できないと思います。これらの認識のギャップを埋めるために、アジャイルではプロダクトオーナーという役割を設定したり、なるべく同じ部屋でのユーザと開発者の密なコラボレーションを推奨したりしていますね。ここまでは教科書的にわかります。しかし、利害関係者が増えてくることを「想像」しただけで、次のような質問を受けます。

• こんなにいろいろ利害関係者がいたら、開発中のコラボレーションは無理でしょ
• イテレーションの最後にデモするってあるけど、そこに利害関係者をみんな呼ぶの？　取締役も？
• 優先順位を付けてというけど、あんまり差がないんだよね？　それでも付けるの？

つまり、利害関係者が多様化してきたなら、それに合わせたコミュニケーションのスキームを用意する必要があるということです。スケールド・アジャイル・フレームワーク（Scaled Agile Framework、以下SAFe)とDADは各々がコミュニケーションのスキームを形作るさまざまなテクニックを提案していますが、この両者はいい具合に補完関係を組むことができます。

• SAFeにおける要求の構造化→現場から経営層へと連なる利害関係者の関心を整理
• DADのフェーズ → プロジェクト時間軸上のタイミングとその時点で決められているべき要求の具体性

SAFeにおける要求の構造化

アジャイル開発におけるシステム要求の定義といえば、ストーリー（「ユーザ～」や「テクニカル～」などがありますね）です。システムをブラックボックスとして表現し、「（ユーザは）なにができるか」を記述することで、ユーザ視点でのアプリケーションの価値を明確に提示できるというメリットが、ストーリーにはあります。その一方、イテレーションでの（おそらく最小の）実装単位という性格上、規模に応じて単純に数が増えていきます。中にはテクニカルストーリーと呼ばれるビジネス色の薄いストーリーも含まれるので、ビジネスサイドの関係者からは、自分が関心を持っているものと、さっぱりわからないものが混在した、なんともわかりづらいバックログができあがりかねません。現場のメンバーから偉い人まで、関心のポイントやその抽象度は異なります。これを意識して適切に情報を共有しないと適切な判断を期待することはできません。

アジャイル開発における要求の表現には、ストーリー以外にもフィーチャーやエピック、テーマと以前からいろいろ提案されており、その違いについて開発者を悩ましてきました。SAFeでは、ややビジネスに寄せた視点で定義しています。紙数の関係もあるので、筆者なりに要約すると以下のようになります（図2）。

図2：アジャイルなのに（？）、要求の構造

• 投資テーマの価値を実現する大規模な取り組みを表現する「エピック」。機能と言うよりも戦略やアプローチといった言葉のイメージに近い
• エピックを実現するために、システムが満たすべき条件を記述する「フィーチャー」
• フィーチャーを実現するためのシステムの機能性である「ストーリー」

　この構造を利用することで、以下のような効果が期待できます。

• 経営者と現場のメンバーではそもそも関心が異なります。各々の関心に合った要求のレベルを適切に管理・提示することができ、各レベルで適切な情報にもとづく意志決定がよりスムーズに行われることが期待できます。
• よりビジネス寄りの要求からストーリーに繋がる関係性が定義できます。なにか変更が発生した場合、影響する範囲を調べる（たとえば、「フィーチャーが変更されたらどのストーリーが影響を受けるか」という右向きのベクトル）のと同時に、そもそもその変更がよりビジネス的な観点で合意された要求に沿うのか（たとえば、「フィーチャーに求められる変更は、エピックの意図に沿うのか」を検討する、左向きのベクトル）といった判断を助けます。

図3：HP Agile Managerのバックログ

図3はHP Agile Managerのバックログの画面例です。Agile Managerでは要求の構造としては、［テーマ］−［機能］−［ストーリー］という構造を採ります。図3にあるように、テーマや機能で必要なモノを取捨選択することで、総要求数がふくれあがっても、適切なものを照会することができます。

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本に説明があるので、そちらもぜひご覧ください。

軽くまとめ

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

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