ITプロジェクトに対する根強い不満は、それらが完全に失敗するということではありません。もっとも一部は失敗しますが。問題は、それらが予測可能でないという点にあります。6か月遅れ、予算を40パーセント超過して終わるプログラムは損害ですが、任意のプロジェクトが予定どおりに終わるかもしれず1年遅れるかもしれず、しかもどちらになるかを事前に確実に見分ける手立てがないポートフォリオは、別の意味で組織をむしばみます。それは事業レベルでの計画立案を不可能にします。それは経営層にあらゆる見積もりを水増しし、あらゆるコミットメントを割り引くことを教え、それが今度はデリバリーチームに、見積もりは芝居にすぎないと教えます。システム全体が、誰も計画を信じず、誰もが自分の身を守るという低信頼の均衡へと漂っていきます。

これが10年前よりも今いっそう重要であるのには、特定の理由があります。ITの変革は、もはや事業がときおり吸収する個別の出来事ではありません。それは継続的であり、収益、規制、顧客体験と、ほとんど余裕を残さない形で絡み合っています。基幹バンキングシステムの移行が遅れたり、ERP統合が停滞したりすれば、その帰結はIT予算の一項目にとどまりません。それは商業的なコミットメント、コンプライアンスの期限、そしてその作業を推進した経営陣の信頼性へと波及します。個々の失敗のコストが上がっていない場合でさえ、予測不可能性のコストは上昇しているのです。

居心地の悪い真実は、予測不可能性の多くが、一行のコードも書かれず、一台のサーバーも用意されないうちから、最初の段階で作り出されているということです。それは見積もりを交渉として扱うことによって、真に理解されたことのないスコープにコミットすることによって、そして実際の作業の性質ではなく文化的な心地よさのために選ばれたデリバリー手法を採用することによって、作り出されます。予測可能性は、プロジェクトがまだ安価に形づくれるうちに下される決定によって、その大部分が決まります。規律はそこから始めなければなりません。

あらゆるITプロジェクトにおける基礎的な決定は、どのフレームワークを採用するかではありません。それは不確実性がどこに存在するかの診断です。おおまかに言えば、デリバリーにおける不確実性は二つの形をとり、それらは正反対の対応を求めます。第一は実行の不確実性です。何を構築すべきかは正確にわかっているが、それを構築することが大規模で、複雑で、あるいはリスクが高い場合です。第二は要件の不確実性です。それが何であるかさえわかれば有能に構築できるが、正解は実際の利用からのフィードバックを通じてはじめて明らかになる場合です。この二つを混同することが、手法に関連する失敗の大半の起点です。

支配的な不確実性が実行のものであり、要件が真に安定している場合、計画駆動型のデリバリーは謝罪すべき遺物ではありません。それは正しい道具です。データセンターの移行、法的仕様が固定された規制報告の変更、あるいは十分に理解されたパッケージの新拠点への展開は、いずれも既知のスコープを持ち、詳細な事前の順序づけ、依存関係のマッピング、クリティカルパスの管理から絶大な恩恵を受けます。そうした作業を発見の航海であるかのように装うことは、それが提供する唯一の利点、すなわち適切に計画する能力を無駄にします。

支配的な不確実性が要件のものである場合、計画駆動型のアプローチは積極的に有害になります。なぜなら、それは未確定のままにしておくべき決定への早すぎるコミットを強いるからです。ここでこそ適応型のデリバリーがその真価を発揮します。短いサイクル、稼働するインクリメント、そして実際のユーザーとの頻繁な接触が、未知を既知へと持続可能な最速の速度で転換します。反復の目的は、速さそれ自体のためではありません。それは要件リスクの体系的な解消です。反復はするが、そのインクリメントを本物のユーザーフィードバックに一度も向き合わせないチームは、機構を伴わずに儀式だけを採用したのであり、何も得られません。

誠実な立場、そして本稿が主張する立場は、ほとんどの大規模なプログラムは、その構成要素ごとに異なる比率で両方の種類の不確実性を含んでいるというものです。成熟した判断とは、全体をアジャイルだとかウォーターフォールだと宣言することではなく、それを分解し、スコープが安定しているところには計画駆動型の厳格さを、そうでないところには適応型の発見を適用し、両者の継ぎ目を意図的に管理することです。その継ぎ目にこそ、真の技量が宿ります。

近年、ITプロジェクトマネジメントを作り替えたいくつかの展開があり、本質的なものと流行的なものを切り分ける価値があります。もっとも本質的なのは、ITの領域のうち長寿命の部分における、プロジェクト思考からプロダクト思考への転換です。決済プラットフォームや顧客ポータルは、終わるプロジェクトではありません。それらは持続するプロダクトであり、継続的に予算をつけられ、安定したチームによって所有されます。その種の作業にとって、固定された終了日を持ち、完了時にチームを解散させるプロジェクトという構成物は、積極的な負債になっています。なぜなら、それはソフトウェアを健全に保つ持続的なオーナーシップではなく、引き継ぎのために最適化するからです。

それと同時に、そしてプロダクトの潮流とはやや緊張関係にありながら、規模を伴う依存関係の管理という規律が形式化されてきました。組織が共有アーキテクチャに対して数十のチームを走らせるようになると、デリバリーを縛る制約は、単一のチームの生産性であることはめったにありません。それはチーム間の調整コストです。共有サービス、統合の順序づけ、複数のストリームが依存するプラットフォーム機能です。スケールドデリバリーのフレームワークは、その有用な核心において、こうしたチーム横断の依存関係を可視化し、それらが全員を停滞させる原因になる前にスケジュールしようとする試みです。

第三の変化は、継続的デリバリーの成熟と、本番への経路の自動化です。変更のデプロイがまれで、手作業で、リスクの高い出来事であるとき、経済的力学は大きなバッチと長いリリースサイクルへと押しやり、それが今度は重厚な事前計画へと押しやります。デプロイが自動化され、テストされ、日常的になると、小さなインクリメントを安価にリリースできるようになり、デリバリーのリズム全体が、適応型の作業が依拠する頻繁なフィードバックへと移行できます。手法に帰せられているものの多くは、実際にはこのエンジニアリング能力の下流にあります。壁にどのフレームワークが書かれていようとも、年に二回しかリリースできないチームは、価値へ向けて意味のある反復をすることはできません。

予測可能なデリバリーは、作業がどう管理されるかと同じくらい、作業がどう構造化されているかの性質です。もっとも強力なてこは、それぞれが実演可能な、そして理想的には利用可能な何かを届けるインクリメントへの分解です。これはプロジェクト管理上の些末な作法ではありません。稼働するソフトウェアを生み出すインクリメントは、統合とテストの問いを、最終フェーズで一斉に爆発するまで先送りするのではなく、早期に繰り返し答えさせます。ビッグバン統合という古典的な失敗、すなわち別々に構築された部品を数か月かけて最後に結合し、噛み合わないと発覚するという失敗は、管理の失敗である以前にインクリメント設計の失敗です。

依存関係のアーキテクチャが第二の原理です。チーム、システム、ベンダー間のあらゆる依存関係は、スケジュール上の制約でありリスクです。優れたデリバリー設計は、これらを意図的に最小化し順序づけるよう努めます。どの部品がクリティカルパス上にあるか、どの共有機能が依存作業を開始できる前に存在していなければならないか、そしてベンダーの成果物や規制当局の承認といった、どの外部コミットメントがチームの制御の外にあり、したがって最も早い注意と最も保守的なバッファリングを必要とするかを特定します。遅れて発見された依存関係は最も高くつく種類のものです。なぜなら、それが表面化するころには、それを解決する選択肢は狭まってしまっているからです。

第三の原理は、要件が不確実なところでは可逆性のために設計し、要件が確定しているところでは堅牢性のために設計することです。逆転が安価な決定は素早く下し、フィードバックに照らして改訂できます。逆転が高価な決定、たとえばシステムの中核をなすデータモデルや、他のすべてが依存することになるプラットフォームの選択は、固定される前に不釣り合いなほどの精査に値します。うまく運営されるプロジェクトは、逆転が高くつくところに慎重な分析を費やし、そうでないところでは速く動きます。あらゆる選択に一律の儀式を適用するのではありません。この二つを混同すること、すなわち些末なことに苦悩しながら不可逆なことを急ぐことは、よくある、そして静かなトラブルの原因です。

柔軟性を装ったスコープクリープ。適応型のデリバリーは、スコープを一切固定しないための免罪符としてしばしば誤用されます。真の反復は、安定した目標に向けて解決策を洗練させます。規律のない変更は、数週間ごとに一つの目標を別の目標に置き換え、それを応答性と呼びます。区別の基準は、変更が収束しているかどうかです。各サイクルが成果を一貫した目的へ近づけるプロジェクトは学習しています。各サイクルが新しい目的を追加するプロジェクトは、スコープを管理しているのではなく、放棄しているのであり、終わることはありません。

スイカ色のステータスレポート。外は緑、中は赤。これは、稼働するソフトウェアと実現された価値ではなく、通過したマイルストーンでプロジェクトを判断することの自然な産物です。指標が完了タスクの割合であるとき、チームは何か月も90パーセントと報告できる一方で、困難で、統合的で、価値を担う残りの10パーセントは手つかずのままです。処方箋は、より良い報告の規律ではありません。それは何を測るかを変えることであり、進捗が計画に対する活動ではなく、実演可能で、テストされ、利用可能なインクリメントを意味するようにすることです。

依存関係の否認。チームは自分たちの作業は注意深く計画するものの、自分の境界の外にあるものはすべて、予定どおりにひとりでに解決する他人の問題として扱います。それはめったに解決しません。プロジェクトが所有していない依存関係こそが、最も遅れやすく、そして遅れたときにチームが最も急がせにくいものです。外部の依存関係を明示化し、オーナーを割り当て、現実的にバッファを持たせることは、地味な作業ですが、期日を守るプログラムとそうでないものを分けるものです。

ステークホルダーの曖昧さ。多くのプロジェクトは、誰が実際に決定するのかという明確な答えのないまま何か月も走ります。スポンサー、ユーザー、資金提供者が微妙に異なるものを望み、単一の説明責任を負うオーナーがそれらを調整しないとき、プロジェクトはその対立を混乱として吸収し、決着済みの決定を蒸し返し、誰も満足させません。誰が成果を所有し、誰に相談しなければならず、誰には単に情報を伝えるだけかについての明確さは、官僚主義ではありません。それはプロジェクトが実際に決定を下し、それを維持するための機構です。

コミットメントとしての見積もり。見積もりは、不確実な未来についての確率的な言明です。それが約束として扱われた瞬間、それは誠実であることをやめます。なぜなら、約束するのに最も安全な見積もりは水増しされたものであり、水増しは見積もりが担うはずだった情報を破壊するからです。健全なデリバリーは、見積もりとコミットメントを分けて保ちます。見積もりは率直に計画に情報を与え、コミットメントは、不確実性を交渉で消し去るのではなく認めた上で、意図的に下されます。

NashuaのITプロジェクトマネジメントへのアプローチは、手法ではなく診断から始まります。いかなるデリバリーモデルを推奨するよりも前に、私たちは所与のプログラムにおいて不確実性が実際にどこに存在するかを、構成要素ごとに見極めようと努めます。なぜなら、その読み解きが下流のすべてを決定するからです。これは意図的に流行に逆らう作業です。それは領域全体に単一の方法論を宣言しようとする衝動に抵抗し、代わりに、プログラムがその安定した、依存関係の多い中核には計画駆動型の厳格さを、要件がまだ学習されている部分には適応型の発見を必要とするかもしれないことを受け入れます。私たちはそれらのモード間の継ぎ目を、後回しにするのではなく第一級の関心事として管理します。

実行においては、私たちは少数の譲れない規律を守ります。インクリメントは、統合リスクを先送りせず継続的に向き合えるよう、稼働しテストされたソフトウェアを早期に頻繁に生み出すよう設計されます。依存関係、とりわけチームの制御の外にあるものは、最初から明示化され、所有され、バッファを持たされます。スコープは一貫した目的に対して管理され、変更はその目的に収束するところでは歓迎され、単にそれを拡大するだけのところでは問い直されます。そして私たちは見積もりをコミットメントから分けることで誠実に保ち、計画が防衛的な水増しではなく本物の情報を担うようにします。とりわけ、私たちは進捗を、通過したマイルストーンの数ではなく、実演可能な稼働するソフトウェアと実現された価値の証拠によって判断します。なぜなら、後者は偽装しやすく、前者はそうではないからです。

私たちはまた、プロジェクトの人的アーキテクチャを真剣に受け止めます。誰が成果を所有し、誰が決定し、それらの決定がどう維持されるかを確立します。デリバリーの失敗に見えるものの多くは、実際には混乱として表出した未解決のステークホルダーの曖昧さであり、私たちは説明責任の明確化を、最小化すべきガバナンスのオーバーヘッドとしてではなく、第一級のデリバリー作業として扱います。

Nashuaがもたらす違いは、不確実性を消し去ると約束する独自の手法ではありません。そのような手法は存在せず、そう主張する企業は、デリバリーではなく安心を売っているのです。違いは、一貫して適用される判断にあります。すなわち、誠実に診断する意志、計画駆動型と適応型のデリバリーを流行によってではなくその利点によって選ぶ意志、依存関係と説明責任がいいわけになる前に可視化する意志、そして、プロジェクトの価値はユーザーの手に届けるものと価値として実現するものにあり、計画に対して報告するものにあるのではないと終始主張することです。その判断は、プログラムが実際にどこで道を誤るかを知るのに十分なだけ、それらを届けてきたことの産物です。

そして、作業が前提として許されることを変える実践的な帰結もあります。あるエンゲージメントが、まだ存在しない機能を必要とするとき、それは調達サイクルやベンダーのロードマップを待つ必要はありません。enterprise platformは、エージェンティック・エンジニアリングを通じて、ほぼあらゆる機能を迅速に受け入れられるよう構築されています。必要なものが平易な言葉で記述され素早く生成されますが、それは常に確固たるアーキテクチャ原則の内側で、厳格な品質保証のもとに行われ、速さが一貫性、セキュリティ、統制を犠牲にすることは決してありません。その効果は、単に便利であるにとどまらず戦略的です。それは内製か購入かの境界線を動かし、選択肢を安価に保ち、戦略が棚にたまたまあったものに屈するのではなく、アーキテクチャが戦略に従うことを可能にします。

これらを結びつけるのは、デリバリーを芝居にさせまいとする拒絶です。よく管理されているように見え、自信ある報告を生み、あらゆるガバナンスのチェックポイントを満たしながら、静かに何ら価値あるものを生み出さないプロジェクトを走らせることは、たやすいことです。自らの不確実性について誠実であり続け、リスクに早期に向き合い、スコープを収束させ続け、稼働する成果によって自らを測るプロジェクトを走らせることは、はるかに難しく、はるかにまれです。その難しい道こそ、Nashuaがコミットする道です。なぜなら、それがITの変革を、単によく文書化されただけではなく、真に予測可能なものにする唯一の道だからです。私たちが協働する組織は、何も問題が起こらないという約束にではなく、何かが起こったときに、それが早期に見出され、率直に名指しされ、まだ安価に修正できるうちに対処されるという確信に頼るようになります。