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

ディシプリンド・アジャイル(DA)フレームワークの中でデリバリーに特化した部分としての、ディシプリンド・アジャイル・デリバリー(DAD)の重要な側面の一つは、リスクと価値のライフサイクルを推奨していることである。この記事では、スクラム/アジャイルの「価値駆動のライフサイクル」を概観し、その長所と短所を確認し、その上でどうすればそこからリスクと価値のライフサイクルに素早く移行できるかを見ていく。

スクラムを始めとする複数のアジャイル手法では、価値駆動のライフサイクルと呼ばれている方法を推奨している。すなわち、基本的には、ビジネス価値によって行うべき作業を優先順位付けし、最初に最も価値の高い作業を行う。この方法には、明らかに長所がある。つまり、常に最も価値の高い機能についての作業が行われること、そのため、利害関係者にとって可能な限り最高の投資対効果(ROI)を提供できることである。ソリューションをインクリメンタルに構築し、利害関係者がその要求を発展させることで、彼らが望む最も価値の高い機能のみにお金を使い、 皆さんのチームは利害関係者に、投資に対して得られる価値を最大化できるようになる。さらには、利害関係者が彼らの要求を発展させることで、彼らが望む通りの構築ができるチャンスが高まる。このように価値駆動は明らかに良い考え方ではあるが、より良い方法も存在する。

本記事では、以下の3つのポイントに取り組む。

  1. ソフトウェア開発におけるよくあるリスク
  2. リスクと価値のライフサイクル
  3. デリバリーライフサイクルを通してよくあるリスクに対処する

ソフトウェア開発におけるよくあるリスク

ソフトウエアベースのソリューションを開発するチームが直面するリスクの中には、価値駆動のアプローチでは必ずしもうまく対処できないリスクがあると考えている。それは、

・足並みの揃わない利害関係者
ソフトウェアベースのソリューションを構築するにあたっては、エンドユーザー/顧客以外にもさまざまな利害関係者がいて、彼らの目標や要望が全く異なるということもあり得る。チームが成功するためには、これらの利害関係者(皆さん自身も含めて)の目指す方向をある程度同じにする必要がある。

・不適切なアーキテクチャー
もし皆さんがそれなりの年数をIT業界で過ごしているのであれば、こんなことを聞いた(最悪の場合、経験した)ことがあるだろう。すなわち、あるとき頭の切れる人たちの一群がやってきて良いアーキテクチャーと称するものを置いていき、また別の頭の切れる人たちがそれをレビューして承認したにもかかわらず、数ヶ月後にチームは重大な技術的課題(ソリューションがうまく統合できない、パフォーマンスが上がらない、信頼性がない、など)に直面したという事実である。問題は、アーキテクチャーが機能するかどうかは、実際に実装したソフトウェアを動作させるまでわからないという事実である。

・デリバリーチームが間違ったものを構築する
長いプロジェクトでは(それ自身にかなりの疑問があるが)、チームが脱線する可能性がある。チームが元のビジョンから逸脱(元のビジョンが間違っていたか、もしくはチームが脇道に逸れたか、もしくはその両方)するか、チームが作っていたものが市場の変化によって否定されるという状況である。

・不十分な機能
チームによっては、しばしば日程駆動のスケジュールのせいで、本番に供するには十分ではない機能のままデリバリーすることを強いられることがある。これは、”予定通り/予算通り”にもかかわらず利害関係者がデリバリーされたものを気に入らない、という現実を発見して終わる。

・ソリューションが出荷OKにならない
システムは時に、まだ準備が整っていないにも関わらず本番に供される。これには、技術的に完了していない(品質が不十分だ、サポート用の文書が十分ではない)場合もあるし、利害関係者の準備が整っていない(適切にトレーニングされていない、他のシステムのリリースに忙殺されている、単に今すぐに使いたいわけではない、など)場合もある。繰り返し強調しよう。この問題の第一原因は、日程駆動のスケジュールである。

・利害関係者が成果をよしとしない
時にチームは、”部分的に出荷可能なソフトウェア”構築にあたって、とても良い仕事をすることがある。しかしそれを出荷してみると、思ったより広範囲には使われないことに気づく。これは皆さんのチームが利害関係者と緊密に作業をしていない場合、もし利害関係者が近くにいたとしてもそれが正しい利害関係者ではない場合に、起こりうる。

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

では、リスクと価値のライフサイクルに取りかかろう。図1と図2は、DADがサポートする2つのプロジェクトベースのライフサイクル、つまりスクラムを基礎とするアジャイルの基本的なライフサイクルと、カンバンを基礎とするリーンのライフサイクルを示している。これらは、複数あるDADライフサイクルの中で、2つのみを選んだものである。これらのライフサイクルは、リスクと価値のライフサイクルの持つ戦略の重要な側面を示している。つまり、明確なフェーズ分け、洗練された作業の優先順位付け、明確なマイルストーンである。

【図1】スクラムベースのアジャイル基本ライフサイクル

3 - DAD Lifecycle agile scrum

【図2】カンバンベースのリーンライフサイクル

3 - DAD Lifecycle Advanced

より詳細にリスクベースのライフサイクルのこれらの面を見ていこう。

1. 明確でスリム化されたフェーズ
DADでサポートされているこの2つのプロジェクトライフサイクルは、方向付け構築移行という明確な3つのフェーズを規定している。スプリントゼロとも呼ばれる方向付けフェーズの必要性については、議論が盛んなところではあるが、現実問題として、95%のアジャイルチームが事前の計画、モデリング、チームや作業環境の全般的な設定を何かしら行っている。そのためDADではこれを明確にし、方向付けをどのように合理的に行うかを示す。同様に、いくつかの点で作業の結果を本番へ移行・デプロイすることも必要である。移行フェーズもまた可能な限り合理化され、一フェーズを設けるかわりに自動化による活動に進化していくべきである(ここには示されていないが、DADの継続的デリバリーライフサイクルではいくつかのポイントが示されている)。明確な、スリム化されたフェーズを持つことによって、先に示したソフトウェア開発のよくあるリスクのいくつかを軽減することができる。以下の表でより詳細を見ていく。

2. より洗練された作業の優先順位付け
DADにおいては、少なくともアジャイル初心者には、プロダクトオーナー(PO)の役割を採用することを推奨する。POは、作業の優先順付けを担当する。また、アーキテクチャーや技術的な課題への指導をチームに行う、アジャイルモデリングにおけるアーキテクチャーオーナー(AO)の役割を採用することをお勧めする。AOとチームメンバーは、チームが直面しているリスクについての情報をPOに提供し、どの要件がリスクがあるのかをその理由も含めて指摘しなければならない。リスクと価値のアプローチにおいては、POがリスクの高い要件の優先順位を上げ、チームが最初にそれを実装するようにすることがある。もっともリスクの高い要件を最初に実装することで、チームは動作するコードとともにアーキテクチャーを効果的に検証することができる。もしくは、自分たちのアーキテクチャー戦略がうまくいかないことに気づくかもしれない。言葉を変えれば、早いタイミングで失敗し、まだほとんどの時間と予算が残っているうちに問題に対処する(最悪の場合でもプロジェクトを中止し、損失を最小化する)ことができる。POのこれまでの経験によっては、ソフトウェア開発の現実を幾らか理解してもらう必要があるかもしれない。

3. 明確で軽量なマイルストーン
これはDAの全体的なリーンITガバナンス戦略の一つであり、特にデリバリーガバナンスの一部である。ライフサイクルで示されたマイルストーンは、ソリューションデリバリーの活動において、全体的なリスクを軽減することに役立つことを、図3は示している。以下のセクションでは、これがなぜなのかをより詳細に説明する。追加の情報は、ブログ内のReduce Project Risk with Light-Weight Milestonesをご覧いただきたい。

【図3】ディシプリンドアジャイルのプロジェクトにおけるリスクの低減と価値の上昇

risk-value

 

デリバリーライフサイクルを通してよくあるリスクに対処する

以下の表は、前述のよくあるリスクのそれぞれが、リスクと価値のライフサイクルにおいてどのように対処されるかをまとめたものである。

リスク DADがどのように対処しているか
足並みの揃わない利害関係者 これがまさしくディシプリンド・アジャイル・デリバリー(DAD)のライフサイクルに、軽量でも方向付けフェーズを入れた理由である。方向付けは「利害関係者のビジョン」マイルストーンで完了する。このマイルストーンは、利害関係者が現実的な戦略に沿っているかどうかを確認する。
不適切なアーキテクチャー DADでは、構築フェーズの初期に動作するコードでアーキテクチャーを検証するという考え方を推進している。これは統一プロセス(UP)で採用された戦略であり、エクストリーム・プログラミング(XP)の実践者にも採用された戦略である。これは、軽量なマイルストーン「検証されたアーキテクチャー」と、「アーキテクチャーを早期に実証する」というプロセス目標によって確認される。DADはまた、スパイク戦略をサポートしており、これによって新しい技術やその組み合わせのようなアーキテクチャーの一部分を検証することができる。
デリバリーチームが間違ったものを構築する アジャイルチームは、各イテレーションの終了時に、アジャイル/スクラムベースのライフサイクルに従って、定期的な進捗の決定を下し、どのように継続するかを決める必要がある。これは理論的には素晴らしいアイデアではあるが、現実には、プロダクトオーナーがこの決定の責任を負う必要があるため、しばしばチーム寄りになりすぎ、破綻することがある。このような状況になった場合、これまでの作業を中止したり、異なる方向に転換したりする決定をしづらくなる。この問題に対処するための最適な方法は、本番リリースを定期的に行うことである。なぜなら、実際に使ってみることで、自分たちの作業が本当に価値のあるものだったかどうかのフィードバックが得られるからである。頻繁にリリースをしない場合(これはプロジェクトの思想に基づいた結果のことが多いが)、軽量な「プロジェクト有効性」マイルストーンを検討することをお勧めする。これは、チームが軌道に乗っているかどうかを、数ヶ月ごとに確認するものである。
不十分な機能 構築フェーズを通して利害関係者が積極的にプロジェクトに参加することで、チームは利害関係者のニーズを理解し、適切な機能を実装できる。このようなプロジェクトへの参加が現実的でない場合は、チームはPOやビジネスアナリスト(BA)のような利害関係者の代理人と連携する必要がある。さらにDADのライフサイクルには、「十分な機能性」マイルストーンがあり、ここで利害関係者は、しばしばPOに主導される形で、チームが十分な機能を作っているかどうか、移行フェーズに向けて作業をしているかどうかを確認することができる。
ソリューションが出荷OKにならない 移行フェーズは、「本番準備完了」マイルストーンを含んでおり、ここで2つの本質的な問いかけをすべきである。ソリューションは出荷可能になっているか、と、利害関係者はソリューションを受け入れているかどうか、である。
利害関係者が成果をよしとしない ライフサイクルの価値駆動の側面によってこのリスクに対処する必要があり、特に積極的な利害関係者の参加によってこれに対処すべきである。しかし、もしすべての範囲の利害関係者と協業していない場合、その関係者の要求を見逃すリスクがある。DADはまた、単に出荷可能なソフトウェアというのではなく、使用可能なソリューションを作ることにチームがフォーカスすべきであるという考えを推進している。「満足した利害関係者」マイルストーンがあり、これによって利害関係者が納品されたものを本当に気に入っているかどうかを判断するための方法を見つけるように示唆している。利害関係者にとっては単に動作するソフトウエアを出荷するだけでは十分ではなく、実際に使用できる(使用可能でかつ望ましい)ソリューションを求めている。

リスクと価値のライフサイクルは新奇な考え方ではない。これは1990年代半ばにラショナル統一プロセス(RUP)により一般的になり、最近になってアジャイルコミュニテイに再発見された。スクラムの価値駆動ライフサイクル以上によい結果をもたらすと考え、DADではごく初期の頃からこの戦略を採用している。ディシプリンドアジャイルのようなハイブリッドなフレームワークの主な利点の一つは、単一手法の戦略に限定せず、幅広く様々な手法からのアイデアを活用できることである。リスクと価値のライフサイクルは、そのような様々なアイデアのひとつである。

関連記事:

オリジナル:Risk-Value Lifecycle

Risk-Value Lifecycle


(翻訳 中佐藤麻記子)

Pocket