SAFeのリーン-アジャイルの原則

フェーズゲートを時間どおりに通過することとプロジェクトが成功することとの間に、実際には相関関係はない…データは、その逆が正しい可能性を示唆していた。

─Dantar P. Oosterwal, The Lean Machine

第5原則─動くシステムの客観的な評価を基にマイルストーンを設定する

フェーズゲートマイルストーンの問題

今日の大規模システムを開発するには多額の投資が必要である。その投資額は、100万ドル、1000万ドル、ときには1億ドルに達することもある。システム構築者と顧客は、新しいソリューションへの投資により必要な経済的利益が得られることを保証するという受託者責任を、共同で負う。得られないなら投資をする理由がない。

もちろん、利害関係者は、最後にはすべてがうまくいくだろうという「希望的観測」を持つだけでなく、開発プロセス全体を通して期待する経済的利益を確保できるよう協力する必要がある。この課題に対処するため、業界はフェーズゲート(ウォーターフォール)開発プロセスへと進化してきた。このプロセスでは、一連の具体的なマイルストーンを使って進捗を測定し、制御を行う。

このマイルストーンは自由勝手に作成していいものではなく、一見論理的な、発見、要求、設計、実装、テスト、納品という逐次的プロセスに沿って作られる。もちろん、多くの人にとって、期待した結果にはならなかった。次の図に示すとおりである。

フェーズゲートの希望的観測

この問題の根本原因は、「フェーズゲートによって本当の進捗が明らかになり、結果としてリスクを軽減できる」という基本的な想定に含まれる、次の4つの致命的な誤りを見逃したことにある。

  1. 要求および設計の意思決定をなわばり意識の高いそれぞれの職務にまとめるが、その職務がソリューション構築に一体化して関与しない場合がある。
  2. 早すぎる段階で設計の意思決定をしなければならず、「実現可能であるという誤った判断」をしてしまう[1]。早い段階で、その時点でもっともよく分かっているものを選択する。すべてが順調であるという前提で開発が進む。選択した方針が実際には実現可能でなかったと判明するのは後になってからである。(第3原則)
  3. 「ぴったりの」ソリューションが存在し、一度で正しく構築できると想定する。プロセスにつきものの変動が無視され、その正式な表現方法が用意されていない。変動は勝手な方法で自己表現してしまう。
  4. 事前に意思決定をすると、大量の要求とコードとテストが作成され、待ち行列が長くなる。結果として、大量の引継ぎや、フィードバックの遅れが生じる。(第6原則)

客観的な証拠に基づいてマイルストーンを設定する

フェーズゲートモデルでは意図したとおりにリスクが軽減されず、異なるアプローチが必要なことは明らかである。第4原則「素早い統合された学習サイクルでインクリメンタルに構築する」が、このジレンマを解決する要素となる。

開発全体を通して、システムはインクリメントに分けて構築される。このインクリメントそれぞれが統合ポイントとなり、そこで、現在作成中のソリューションの実現性に関するいくらかの証拠が示される。さらに、これは定期的にリズムに合わせて(第7原則)行われるため、周期的に動くもので評価をするために必要な規律がもたらされるし、この既定の時間境界を使ってあまり好ましくない選択肢のフィールドを折りたたむことができる。

この重要な統合ポイントで実際に何を測定するかは、構築対象のシステムの性質や種類によって異なる。しかし、システムを測定し、該当する利害関係者によってソリューション開発のライフサイクルを通じて頻繁に評価することができる。これは、投資を続けていくことで相応の利益が得られることを保証するのに必要な、財務、技術、目的適合性についてのガバナンスとなる。


さらに知りたい場合

[1] Oosterwal, Dantar P. The Lean Machine:How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development.Amacom, 2010.

Last update:11 May 2015