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

統合ポイントの本質は、統合ポイントによってプロダクト開発が制御されることと、統合ポイントがシステムを改善するためのレバレッジポイントとなることである。統合ポイントのタイミングがずれこんだときには、プロジェクトに問題が生じている。

─Dantar P. Oosterwal

第4原則─素早い統合された学習サイクルでインクリメンタルに構築する

インクリメンタルなシステムの構築

従来のステージゲート開発では、投資コストはただちに発生し、ソリューションが納品されるまで積みあがる。確約されたフィーチャーがすべて提供されるまでの間や、プログラム用の時間や予算が尽きたときには、実際の価値が納品されることはまったくないかないに等しい。開発中に意味のあるフィードバックを得ることは、得られるようにプロセスが設計されていないため困難であり、システムは、インクリメンタルなシステム能力を顧客に評価してもらえるように設計/実装されていない。プログラム内のリスクは、締め切りまで、場合によっては配置して最初に使用するときまで、残ってしまう。このプロセスではエラーや問題が発生することが多く、大体は、システム構築者と顧客の間の信頼が失われる結果になる。この状況を改善しようとして、顧客とシステム構築者は、事前に要求を定義して「最善の」設計を選択しようと努力を重ねている。また、多くの場合は、ステージゲート開発をより厳密に実施している。しかし、これらの解決策は、実際には根本的な問題を悪化させている。これは開発プロセスのシステムレベルの問題であり、システムとして対処しなければならない。

統合ポイントで未確定事項から知識が作り出される

リーンなシステム構築では、この問題に対して異なるアプローチをする。早い段階で要求と設計の選択肢を1つ選ぶ(それが実現可能であり、かつ目的に適合していると想定して)のではなく、複数の要求と設計の選択肢の範囲で作業を進め(第3原則)、一連の短い時間枠の中でインクリメンタルにソリューションを構築する。それぞれの時間枠の成果として動くシステムのインクリメントが作成されるので、それをシステム構築者と顧客とで評価することができる。後に続く時間枠は前のインクリメントをベースとして実施され、ソリューションはリリースされるまで進化し続ける。統合ポイントで得られる知識は、技術的実現性を確立するためだけのものではない。多くの統合ポイントでは最低限実行可能なソリューションやプロトタイプが作成され、それを使って、市場をテストしたり、使いやすさを確保したり、顧客からの客観的なフィードバックを得たりすることができる。必要であれば、システム構築者は、この時点での素早いフィードバックをもとに、対象顧客のニーズにもっと合った別の行動方針へと「方向転換」することができる。

統合ポイントは意図的に作成される

リズムベースの統合ポイントは、システム構築者の主な焦点となる(開発プロセスとソリューションアーキテクチャーがまさにその目的も含めて設計されているため)。それぞれの統合ポイントは「プルイベント」となり、そこでさまざまなソリューション要素が、それ自体はシステムの意図のごく一部に対処するだけのものであっても、統合の済んだ全体の中にプルされる。統合ポイントでは、利害関係者も一緒にプルされる。これは、進化中のソリューションが、最初に決定した想定事項ではなく、現時点での実際のビジネスのニーズに対処できていることを確認するための、定期的な同期点である。それぞれの統合ポイントでは、未確定事項を知識に変換することで独自の価値が納品される。この知識とは、客観的な測定に基づいた(第5原則)、現在選択している設計の技術的な実現性や、ソリューションの潜在的実現性についての知識である。

速くサイクルを回して素早く学習する

統合ポイントは、シューハートの基本の計画-実行-評価-改善のサイクル[3]を具体化したものであり、ソリューション開発のバラツキを制御するための主要メカニズムとなる。

統合ポイント

ポイントが多いほど学習が速くなる。複雑なシステム開発では、ローカルの統合ポイントを用いて、システムのそれぞれの要素やシステム能力が自分の責任を果たし、全体としてのソリューションの意図に貢献していることを確認する。このローカルの統合ポイントは、その上のシステムレベルでさらに統合しなければならない。システムが大きいほど、統合のレベルは増える。システム構築者は、最上位のもっとも頻度の低い統合ポイントが、本当のシステムの進捗を測定できる唯一の点であることを理解し、そのポイントをできるだけ頻繁に設けられるよう常に努める。利害関係者は全員、統合ポイントのタイミングがずれこんだときには、プロジェクトに問題が生じているのだということを理解している。しかし、問題が生じた場合でも、その知識をタイミングよく得ることで、期待内容を見直してそこへ向かう軌道にプロジェクトを乗せるのに必要な、スコープや技術的手段やコストや納品時期を調整することができる。


さらに知りたい場合

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

[2] Ward, Allan C. and Durward Sobek.Lean Product and Process Development.Lean Enterprise Institute Inc., 2014.(邦訳:トヨタが実践する価値創造の確かな進め方 リーン製品開発方式、日刊工業新聞社、2014)

[3] Deming, W. Edwards.Out of the Crisis.MIT Press, 2000.

Last update:11 May 2014