マイルストーン

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

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

マイルストーンの概要

マイルストーンとは、開発スケジュール上の具体的な進捗ポイントを示すもので、プログラムの進捗とリスクを測定し監視するために非常に役に立つ。従来、多くのプロジェクトのマイルストーンは、フェーズゲートの作業を基に決められてきた。しかし、SAFeではそれとは異なり、反復とプログラムインクリメントの固定のリズムによって進捗がサポートされるため、チームはリズム感を得て結果のばらつきを管理できるようになる。そのため、SAFeのほとんどのマイルストーンは、従来型のプロジェクト/プログラム管理のマイルストーンとは異なる。動くシステムが基礎にあるため、技術/ビジネス上の仮説を客観的に評価することができる。

しかし、すべてがリズムに乗って行われるわけではない。今日のソフトウェアやシステムエンジニアリングが複雑なのは、外部のイベントや、サードパーティ、日付の固定された制約などに依存する複数の要因が絡むからであり、結果としてスケジュールのパターンが不規則になったり、開発のリズムと異なるものになったりする可能性がある。また、学習マイルストーンを使用すると、ビジネスチャンスやビジネス上の仮説を検証したり、市場に納品するシステム能力の新しいビジネス成績を測定するのに役立つ。

マイルストーンを適切に扱うと、作業に必要な焦点が得られ、ガバナンスがもたらされ、よりよいビジネス成果を手にすることができる。

詳細

今日の大規模システムを開発するには多額の投資が必要である。その投資額は、100万ドル、1000万ドル、ときには1億ドルに達することもある。システム構築者と顧客は、新しいソリューションに投資することによって必要な経済的利益を得られるようにするという受託者責任を共同で負う。得られないなら投資をする理由がないからである。もちろん、利害関係者も協力する必要があり、最後にはすべてうまくいくだろうという「希望的観測」に頼るだけでなく、期待する経済的利益を確保できるよう開発の過程全体を通して手助けする。

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

この課題に対処するため、業界はこれまで、フェーズゲート(ウォーターフォール)開発プロセスを使用してきた。このプロセスでは、一連の具体的な進捗マイルストーンを使って進捗を測定し、制御を行う。このマイルストーンは自由に作成していいものではないが、一般的にはドキュメントベースであり、一見論理的な、発見、要求、設計、実装、テスト、納品という逐次的プロセスに沿って作られる。

しかし、上述のOosterwalの言葉のように、実際にそれではうまくいかない。この問題の原因は、フェーズゲートによって本当の進捗が明らかになり、結果としてリスクを軽減できるという基本的な想定に含まれる、致命的な誤りを見逃したことである。たとえば次のようなものである。

  • ソリューションの進捗のかわりにドキュメントを使用すること。これは、ソリューションが進捗しているという間違った安心感を与えるだけでなく、作業分解図(WBS)やアーンドバリュー測定などのさまざまな測定基準やメトリックスが作られ、その結果、実際にフローや本当の価値納品が妨げられかねない。
  • 要求および設計の意思決定をなわばり意識の高いそれぞれの職務にまとめるが、その職務がソリューション構築に一体化して関与しない場合があること。
  • 早すぎる段階で無理に設計の意思決定をし、「間違った楽天的な実現可能性」を信じてしまうこと[1]。
  • 未確定事項が山積みのまま早すぎる段階で、「ぴったりの」ソリューションが存在し、一度で正しく構築できると想定すること。

こういったことすべてが影響して、フェーズゲートのマイルストーンは必ずしもリスクの軽減に役立ってこなかった。それどころか、未確定事項が山積みのまま早すぎる段階で1つのソリューションを選択してしまう。問題が発生するのは必然である(図1を参照)。

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

こういった背景から、異なるアプローチが必要であることが明らかになる。この後のセクションではそのアプローチについて説明する。

PIマイルストーン:動くシステムの客観的な証拠

SAFeでは、この問題に対処するためにいくつかの手段を用意している。具体的には、第4原則素早い統合された学習サイクルでインクリメンタルに構築する」が、特にセットベースの設計と組み合わせた場合に、解決の一助となる。

このアプローチでは、システムはインクリメントに分けて構築される。このインクリメントそれぞれが統合/知識ポイントとなり、そこで、現在作成中のソリューションを実現できるかどうかの証拠が示される。さらに、これは定期的にプログラムインクリメント(PI)リズムで行われるため、周期的にものを入手して評価するために必要な規律がもたらされるし、この既定の時間境界を使ってあまり好ましくない選択肢のフィールドを折りたたむことができる。このように、それぞれのPIにおいて進捗を客観的に測定することができる。その様子を図2に示す。

図2.  PIマイルストーンで客観的な証拠が得られる

これは、プログラム(システムの統合と検証)のレベルにも価値のストリーム(ソリューションの統合と検証)のレベルにも当てはまる。もちろん、この重要な統合ポイントで実際に何を測定するかは、構築対象のシステムの性質や種類によって異なる。しかし、システムの測定と評価が可能になるし、該当する利害関係者が開発全体を通じて頻繁にシステムを評価できる。もっとも重要なのは、まだ時間があるうちに変更を行えることである(図3を参照)。

図3.  PIマイルストーンによってシステム開発は最適なソリューションへと向かう

これは、投資を続けていくことで相応の利益が得られることを保証するのに必要な、財務、技術、目的適合性についてのガバナンスとなる。

SAFeにおいて、これらはもっとも重要な、ソリューション開発を制御する学習マイルストーンである。非常に重要なので、信用できる客観的なマイルストーンとして扱われる。言い換えると、すべてのPIがある意味での学習マイルストーンである。ただし、それ以外のマイルストーンもある。それについてこの後のセクションで説明する。

その他の学習マイルストーン

PIだけでなく他の学習マイルストーンを使って、「顧客のニーズを満たしビジネスの価値を作り上げるソリューションを構築する」という主要目的をサポートすることもできる。新しいソリューションの背後にある価値提案や既存のソリューションを拡張する大規模な取り組みを仮説として扱い、実際の市場の状況に照らして概念化し検証することが非常に重要である。仮説をビジネス要求に変換することは、リーン-アジャイルプロダクト開発の科学であり技である。これには、相当の中間的な組織的学習が必要である。その際に学習マイルストーンが役に立つ。たとえば次のようなものである。

  • プロダクトの新しいシステム能力に喜んでお金を払ってくれる市場があるか。
  • 対象としているユーザーの問題を解決できるか。
  • 実際の進捗を明示するのに必要な非金融資産の会計基準は使用できるか[2]。
  • 組織はどのような収益を期待できるか。
  • 新しいプロダクトまたはシステム能力の助けとなる実現可能なビジネスモデルはあるか。

これらをはじめとする多くのビジネス上の関心事によって、大きな取り組みの基本的な仮説が設定される。学習マイルストーンは、ソリューションの実現可能性を理解し、適切なシステム能力の骨組みを作るために必要な手段となる。フォーカスグループで新しいシステム能力の概念をテストする、実行可能な最低限のプロダクト(Minimum Viable Product:MVP)を構築してリリースする、新しい機能について想定しているユーザーエクスペリエンスを検証する(ユーザーエクスペリエンスを参照)などは、学習マイルストーンの例である。これらのマイルストーンは必ずしもPIの境界で発生するとは限らないし、プロダクト開発組織だけでなく、営業や、マーケティング、運用、財務など、企業内の他の部門でも大きな工数が必要になる可能性がある。

どの学習マイルストーンも、ある程度の未確定事項が存在することを想定している。これらは、知識へ、そして最終的には組織のビジネス利益へと変えていく必要がある。それには、セットベースの思考と、必要であればソリューションを異なるコンセプトへと方向転換する能力が必要になる。

学習マイルストーンの成果は意図の理解に影響するため、マイルストーンは図4に示すようにインクリメンタルに計画するとよい。

図4.  学習マイルストーンは目標へ向かう進捗を評価するのに役立つ

ソリューションのビジョンソリューションの意図経済的枠組みなど、他の要素も、学習するにしたがって進化する。

しかし、プロダクトの新しいシステム能力が市場に出されてビジネスに利益をもたらし始めても、学習は終わらない。新しいシステム能力やシステムの重要な非機能要求それぞれが事実となり、予想される価値についての想定に代わって使われるようになる。リーンな企業の環境では、成熟したプロダクトであっても、学習は開発と一体化していて切り離せない。有意義な学習マイルストーンは役に立つ。

固定日のマイルストーン

リーン-アジャイルな企業はどこも、制約は最低限で活動したいと考えている。アジャイルは、ひとつにはそこから発生している。しかし、現実の世界には考慮しなければならない事柄がさまざまにあり、固定日のマイルストーンは従来型とリーン-アジャイルのどちらの開発にも存在する。たとえば、次のような理由で日付が固定される。

  • トレードショー、顧客向けのデモ、ユーザーグループのミーティング、計画されたプロダクト発表などのイベント。
  • 社内外の他のビジネス関連事項が理由で決められたリリース日。
  • 契約上義務付けられた、価値納品、中間マイルストーン、支払い、デモなどの日付。
  • ハードウェア、ソフトウェア、サプライヤーとの統合、その他を含む大規模な統合関連のスケジュールのうち、固定日が資産をまとめて検証するための適切な強制関数となるもの。

例はまだまだ挙げられる。リーンにおいて、固定日の遅延コストは非線形である。つまり、その日が近づくと、必要なシステムフィーチャーの優先度はどんどん高くなる。そのマイルストーンをクリアできないと、経済的な損失となるからである。これは、WSJFによるプログラムと価値のストリームのバックログの優先順位付けに直接組み込まれている。つまり、固定日が近づくにつれて「緊急性」のパラメータの値が大きくなるため、その日に関連する要素のWSJF優先度が高くなる。いずれにしても、固定日のマイルストーンをプログラムや価値のストリームのロードマップに反映し、利害関係者全員が計画を立てて実施できるようにしなければならない。

その他のマイルストーン

これまで述べてきたほかにも、たいていは、特許の申請、システムの証明、規制要件の監査など、プロダクト開発を経済的に成功させるために必要な事柄が存在する。多くの場合、このようなマイルストーンは作業の内容や優先順位に影響するし、開発プロセス自体を変えてしまうことすらある。たとえば、ソリューションの認証を行う必要があれば新しいリリースを本番環境に受け入れるための処理コストが増加しかねないし、リリース前にフィードバックを得るための代替方法をシステム構築者が探さなければならないかもしれない。繰り返すが、このようなマイルストーンは関連するロードマップに記載するべきである。

計画と実行のマイルストーン

価値を作成するためにどのような種類のマイルストーンが必要かの情報は、さまざまなところから得られる。企業レベルからポートフォリオに伝えられたり、ポートフォリオ価値のストリームとプログラムのカンバンシステムの分析ステップで特定されたり、価値のストリームやアジャイルリリース列車の計画やロードマップ作成のプロセスで見つかることすらある。チームはいずれ、PI計画のプロセスで具体的な行動計画を作成し、マイルストーンを達成するための具体的なストーリーを構築し、マイルストーンをロードマップとPI目標に反映し、他のチームや列車との依存関係を理解してそれに対処し、プログラムの利害関係者とスコープや時間について協議しなければならない。

その後で、マイルストーンをインクリメンタルに実行していく。進捗は、PIごとにデモで示される。

成功かどうかの測定

マイルストーンの実行を成功させるには、「成功」とは何かという基準が必要である。そのため、具体的な測定基準やメトリックスをマイルストーンに関連付けることに価値がある場合がある。たとえば、「×%の市場シェアを得る」というマイルストーンでは、収益または使用状況の指標を知る必要がある。「検索エンジンでWebページ上の人の名前を確実に特定できる」という学習マイルストーンでは、Webデータの「ゴールドコレクション」のページ全体で誤検出が一定の割合以下になっている必要があるかもしれない。いずれにしても、よく考えて測定することで、マイルストーンをより有意義なものにすることができる。

 


さらに知りたい場合

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

[2] Ries, Eric.The Lean Startup:How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses.Crown Business, 2011. (邦訳:「リーン・スタートアップ」、日経BP社、2012)

Last update 25 October 2015