多くの企業で支配的な計画単位はプロジェクトであり、それに続くのがシステムやアプリケーションです。いずれも、資金がどのように配分され、実行体制がどのように編成されるかにきれいに対応するため、都合がよいものです。しかしいずれも、戦略を考える単位としては貧弱です。どちらも安定しておらず、どちらも積み上がらないからです。プロジェクトはスコープが実現されれば解散する一時的な乗り物であり、その根拠も一緒に持ち去ってしまいます。システムは、いずれ置き換えられる実装上の選択にすぎません。計画の議論がこうした用語で行われると、ポートフォリオは項目同士を比較できない買い物リストと化します。支払いの近代化プログラムとCRMのアップグレードは、通約不可能な言語で記述され、通約不可能な便益によって正当化されるからです。

実務上の症状はおなじみのものです。同じ根本的な弱点が、三つの異なるプロジェクト名のもとで三度も資金を得ることになります。誰もそれを一つのものだと認識しなかったからです。投資は、事業が最もさらされている場所ではなく、最も声の大きいスポンサーがいる場所に集中します。二つの部門が、実のところ同じ顧客に奉仕する同じ能力を、それぞれに構築するため、重複が積み上がります。そして経営層が、ある支出が組織に対して実際に何を、いま何をより上手くできるようにするために買っているのかというもっともな問いを発すると、答えは成果ではなく成果物の語彙で返ってきます。

これが十年前よりも今いっそう重要である理由は二つあります。第一に、技術変化の速度とコストが高まったため、誤った場所への投資に対する代償がより速く累積します。第二に、資産構成がより分散し、レガシープラットフォーム、パッケージソフトウェア、cloudサービスが混在するようになったため、システムレベルの推論では事業レベルの問いにいっそう答えられなくなっています。ケイパビリティベースの計画が重要なのは、計画の拠り所とするに足るほど安定し、かつ企業全体にわたって比較できるほど抽象的な言語を、経営層に与えるからです。

ビジネスケイパビリティとは、組織が何を行うかの表現であり、それをどのように、どこで、誰が行うかとは意図的に切り離して保たれます。顧客のオンボーディングは一つのケイパビリティです。オンボーディングポータル、KYCチーム、本人確認サービスは、それを実現するものの一部です。何をを、どのようにから切り離して保つという規律こそが眼目です。まさにその分離によって、実装が下で入れ替わっても、ケイパビリティは安定して保たれるからです。適切に形成されたケイパビリティは、安定した名詞的な能力として命名され、企業全体に対して一度だけ定義され、現在のオペレーティングモデルや現在の技術を織り込むことはありません。

ケイパビリティはケイパビリティマップとして整理されます。これは企業を階層へと構造的に分解したものです。レベル一には、事業全体にまたがる少数の粗い分類、通常は十から二十のあいだが置かれます。それぞれがレベル二へ、そして有用な場合にはレベス三へと分解され、プロセスの詳細に踏み込むことなく、より細かくなっていきます。マップはプロセスモデルでも組織図でもありません。プロセスは時間に沿った一連のステップを記述します。組織単位は誰が誰に報告するかを記述します。ケイパビリティは、多くのプロセスが行使し、多くの単位が寄与する安定した能力を記述します。この三つを混同することが、ケイパビリティモデルが生まれた瞬間に台無しになる最も一般的な原因です。

マップがその価値を発揮するのは、二つの方向で接続されて初めてです。上方向には、各ケイパビリティが、それが奉仕する戦略的成果や目標に結びつけられ、意図を、それが依存する能力へと辿れるようになります。下方向には、各ケイパビリティが、それを実現するアプリケーション、データ、人、プロセスに結びつけられ、ある能力に関する意思決定を、それが触れるすべてのものへと辿れるようになります。両方のリンクが揃うと、ケイパビリティは接合点となります。戦略上の優先事項は、それが真に依拠する少数のケイパビリティへと解きほぐされ、そのそれぞれが、変わらなければならない具体的なシステムとチームへと解きほぐされます。これを実行可能にするのがヒートマップです。各ケイパビリティは、戦略的重要性、現在の成熟度、コスト、リスク、事業価値といった次元で採点され、視覚的に描き出されるため、重要性が高く、かつ十分に支えられていない少数のケイパビリティが即座に浮かび上がります。その交差点、すなわち高い重要性と低いパフォーマンスの交わるところこそが、投資の向かうべき場所です。

ケイパビリティのモデル化は新しいものではありませんが、いくつかの進展により、それは作図の作業から生きた計画の道具へと移りつつあります。第一は、エンタープライズアーキテクチャのリポジトリとポートフォリオツールが成熟し、ケイパビリティマップを第一級の対象として保持し、アプリケーションおよび技術のインベントリと結びつけるプラットフォームへと発展したことです。どのアプリケーションがどのケイパビリティを、どのコストで、どのような技術的健全性で支えているかという実データにマップが接続されると、ヒートマップはワークショップの意見であることをやめ、資産構成に関する擁護可能な読み解きになり始めます。採点は全面的に主張されるのではなく部分的に導出されうるものとなり、それが財務委員会の前でその権威を与えるものです。

第二は、ケイパビリティをバリューストリームおよびプロダクト志向のオペレーティングモデルと整合させることです。組織が資金配分をプロジェクトから長期存続するプロダクトチームへと再編するにつれ、各チームが何に対して責任を負うのかという問いには安定した答えが必要となり、ケイパビリティがそれを提供します。プロダクトやバリューストリームの各段階は、それが提供するケイパビリティに根ざしているため、プロジェクト資金から持続的なプロダクト資金への移行は、計画サイクルごとにスコープを再発明するのではなく、ケイパビリティマップをその背骨として受け継ぎます。

第三は、ソフトウェアがサブスクリプションとcloud提供へと移行するにつれ、自社開発か購入かの推論が鋭くなっていることです。ほとんどのケイパビリティがパッケージサービスで満たせるようになると、戦略上の問いは、どのケイパビリティが真に差別化を生み、したがって構築または形成する価値があるのか、そしてどのケイパビリティが必要ではあるが差別化を生まず、したがって購入して標準化するのが最善なのか、というものになります。ケイパビリティベースの計画は、その判断をベンダーごとにではなく意図的に下す自然な場です。第四の進展は、AIと自動化が実現手段の候補として登場したことです。ケイパビリティのレンズは、問いを規律あるものに保ちます。すなわち、どこにモデルを取り付けられるかではなく、どの具体的な能力が拡張されれば実質的に改善するのか、そしてその能力はそのリスクにさらされる価値があるほど重要なのか、という問いです。いずれの場合も、マップは、一般的な潮流が見境なく適用されることを食い止めるものです。

何年にもわたって投資を導くケイパビリティマップと、静かに放棄されるケイパビリティマップとの違いは、ほぼすべて設計の規律にあります。第一の原則は、ケイパビリティは組織ではなく成果を記述するということです。ケイパビリティが部門や現在のシステムにちなんで命名されていれば、そのいずれかが変わった瞬間に描き直され、このアプローチ全体を正当化していた安定性は失われます。マップは組織再編を無傷で生き延びなければなりません。これは守るのが最も難しい原則です。部屋にいる人々は、自らの機能を通じて経験するとおりに事業を記述するのが自然だからです。

第二の原則は、マップの各層の内部で、単一かつ一貫した抽象度を保つことです。同じ階層の兄弟項目は粒度がおおむね等しくあるべきで、一方の枝が細かい運用上の詳細まで分解される一方で、もう一方が粗いままにとどまることがあってはなりません。不均等な分解は比較可能性を破壊し、比較可能性こそがマップの存在理由です。第三の原則は、ケイパビリティは可能な限り重複せず、かつ網羅的であるべきだということです。すなわち、事業の意味あるすべての能力が一度だけ、ただ一度だけ現れます。重複はマップが解決するはずだった二重資金配分の問題を生み、空白はリスクを覆い隠します。

第四の原則は、ケイパビリティとその実現手段のあいだの意図的な一対多の関係です。単一のケイパビリティが複数のシステムによって提供されることもあれば、単一のシステムが複数のケイパビリティに寄与することもあります。その多対多のマッピングを、ケイパビリティごとに一つのシステムというきれいな作り話に押し込めるのではなく、正直に保つことが、マップに重複と分断を浮かび上がらせるのです。第五の原則はヒートマップそのものに関わります。その採点次元は明示的に定義され、一貫して適用されなければならず、重要性は、あるケイパビリティが現在どれだけの注目を集めているかではなく、戦略に照らして評価されなければなりません。ケイパビリティは、戦略的意図にほとんど寄与していないにもかかわらず、忙しく、費用がかかり、十分に人員を配されていることがあり、正直な重要性の軸だけがそれを明らかにします。最後に、マップは明確な所有者を持つ生きた資産として統治されなければなりません。維持されないケイパビリティモデルは、たった一度の計画サイクルのうちに歴史的な遺物へと朽ちていくからです。

壁紙マップ。最も一般的な失敗は、一度きりの成果物として作られ、しばし賞賛された後、二度と何にも接続されないケイパビリティマップです。上方向の戦略へのリンクと下方向のシステムへのリンクがなく、意思決定を駆動するヒートマップもなければ、それは一枚の絵です。判定基準は単純です。マップが存在するがゆえに異なる投資判断が下されたことが一度もなければ、そのマップは、どれほど洗練されて見えようとも失敗しています。

偽装された組織図。ケイパビリティが、自らの領域を説明する部門長からもっぱら引き出されると、マップは現在の組織構造を映し出すことになります。もっともらしく読めますが脆く、ケイパビリティが取り除くはずだった不安定性をまさに再導入してしまいます。その処方箋は、明日組織全体が再編されても依然として真であるような形で能力を命名することです。

偽装されたプロセスモデル。チームはしばしばケイパビリティからプロセスへと滑り落ち、能力をそのステップへと分解してしまいます。マップは動詞と手順で埋まり、巨大になり、計画にとって有用であった抽象性を失います。ケイパビリティは、事業が何を行えるかに答えます。それがどの順序でに答え始めた瞬間、それは別の成果物になってしまっています。

ヒートマップにおける偽りの精密さ。ワークショップの感情によって色付けされたヒートマップは、実質を伴わずにデータの視覚的な権威を帯びます。声の大きい利害関係者がいらだっているからケイパビリティが赤で印され、誰も苦情を言わなかったから緑で印されるとき、その色は誤解を招きます。採点には述べられた根拠が必要であり、理想的にはコスト、インシデント率、アプリケーションの健全性といった客観的な信号に部分的に基づいて定着させ、採点の論拠は、異議を唱えられるように記録されておく必要があります。

海を沸かそうとすること。マップで何かを行う前に、あらゆるケイパビリティを最も深いレベルまでモデル化しようとする試みは、価値を届けるはるか前にスポンサーを疲弊させます。資産構成は広大で、ワークショップへの意欲は有限であり、計画の窓口が閉じた後に到着する完全に分解されたマップは、誰の役にも立ちません。規律とは、意思決定が要求する深さまでモデル化し、それ以上は行わないことです。所有者なき朽ちゆきがこのパターンを完成させます。優れたマップでさえ、いったん誰も最新に保つ責任を負わなくなると、資産構成と歩調がずれていき、それが奉仕するために作られた人々の信頼を静かに失っていきます。

Nashuaはケイパビリティベースの計画を、それ自体が報酬であるモデル化プロジェクトとしてではなく、意思決定に至る手段として捉えます。私たちは戦略から始めます。ケイパビリティマップは、組織の意図する成果が明示されるまで重要性の軸を持たないからです。経営層とともに、事業が何を達成しようとしているのかを定め、そこから、それらの成果がどのケイパビリティに真に依存しているのかを見極めます。これにより、この取り組みは最初のワークショップから帰結に錨を下ろし、用途を探す包括的なマップを生み出すことを避けます。

次に私たちはケイパビリティマップそのものを構築し、現在の意思決定が要する深さまで分解します。私たちは設計原則に意図的です。すなわち、成果志向の命名、一貫した抽象度、そして組織再編を生き延びるマップです。私たちはプロセスの詳細へ、そして組織図へと向かう引力に抗います。そのいずれもが結果を静かに損なうさまを見てきたからです。使えるケイパビリティモデルがすでに存在する場合には、一から始めるのではなくそれを評価し洗練させます。語彙の連続性それ自体が価値だからです。

マップを計画へと変える段階は、ケイパビリティを資産構成に結びつけることです。私たちは各ケイパビリティを、それを実現するアプリケーション、データ、プロセスに結びつけ、アプリケーションポートフォリオを、そして情報が存在する場合にはコストと技術的健全性の実際の信号を活用します。そのマッピングは重複、分断、空白を直接あらわにし、ヒートマップを感情ではなく証拠の上に立たせます。私たちはケイパビリティを重要性、成熟度、コスト、リスクの観点で、明示され記録された論拠のもとに採点し、高い重要性と低いパフォーマンスの交差点を、投資候補の絞り込みリストとして描き出します。そこから私たちは組織とともに、その絞り込みリストをケイパビリティで表現された変革ロードマップへと翻訳し、各施策がどの能力を、どれだけ改善するのかを明確に述べるようにします。全体を通じて、私たちは深さとペースについて率直であり、意思決定が必要とする解像度までモデル化し、マップを、綴じ込まれる文書ではなく、名前を持つ所有者のいる生きた資産として扱います。

Nashuaを際立たせるのは、戦略からケイパビリティ、システム、投資へと至るループを閉じること、そしてそれを時とともに閉じたまま保つことへのこだわりです。多くの組織はケイパビリティマップを作ることができます。それを自らの実際のアプリケーション資産に結びつけ、擁護可能な証拠に基づいて採点し、資金が実際にどのように配分されるかに接続し、戦略上の優先順位の変化が投資先の変化へときれいに解きほぐされるようなマップを作れる組織はより少数です。その結びつけの作業、華やかさはなくとも精密なそれこそが、ケイパビリティベースの計画の価値が実現されるか失われるかの分かれ目であり、私たちの実務者が力を注ぐところです。

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

重要なのはこの組み合わせです。ケイパビリティマップだけでは一枚の図であり、ポートフォリオツールだけでは事業上の意味を持たないアプリケーションのデータベースにすぎません。Nashuaはこの二つを一つに束ねます。すなわち、事業が何を遂行できなければならないかという持続的な視点を、それを実現するシステム、データ、コストの生きた現実に照らして保持し、戦略と資産の双方が進化してもその全体像が真であり続けるよう統治するのです。私たちの顧客が保ち続けるのは、成果物ではなく能力です。経営層は、変革について推論するための安定した言語、投資を雑音ではなく真のリスクに向けさせるヒートマップ、そして投じられた一ユーロごとが、事業が意図的により上手くなろうと選んだ能力へと辿れるという確信を得ます。それこそが、事業が遂行できなければならないことへ投資するということの意味であり、Nashuaが存在して支え続ける規律なのです。