この20年間、エンタープライズテクノロジーにおける制約要因はデリバリーでした。システムの構築は遅く、高価で、リスクを伴ったため、確実に実行できる組織が優位に立っていました。その制約は今やほぼ解消されています。cloudプラットフォーム、マネージドサービス、ローコードツール、そして成熟したsoftware-as-a-service市場によって、予算さえあればほぼどんなチームでも、ほぼどんなケイパビリティでも迅速に立ち上げられるようになりました。デリバリーはもはやボトルネックではありません。一貫性こそがボトルネックなのです。

その結果として生まれるのは、誰もが把握できる速度を超えて拡大するIT環境です。各事業部門が独自のプラットフォームを調達し、統合は多数のポイントツーポイント接続の網として積み重なり、同じ顧客データや製品データが、微妙に異なる四つの定義のもとで四か所にマスタ管理されます。個々の意思決定はそれぞれ妥当でした。しかし全体として見れば、自社が何を保有しているのか、それらのシステムの運用にいくらかかっているのか、あるいは全体として掲げた目標に向かっているのか遠ざかっているのかを、自信を持って言えない組織になってしまいます。

だからこそ、IT戦略とアーキテクチャは、バックオフィスの計画機能から取締役会レベルの関心事へと移行してきました。規制の枠組みは今や、機関がテクノロジー環境と業務のレジリエンスに対する統制を実証することを求めています。投資判断は、提案される変更が一貫した方向性に適合するのか、それともすでに絡み合った環境にさらなる例外を加えるだけなのかに、ますます左右されるようになっています。希少な資源はもはや構築する能力ではありません。何を構築し、何を廃止し、どの順序で進めるべきかという問いに対する、信頼できる共有された答えです。その方向性を定め、局所最適化の絶え間ない圧力に抗してそれを守り抜くこと、それがこの仕事です。

この分野における根幹的な一歩は、事業が何をするのかを、今それをどう行っているのかから切り離すことです。ビジネスケイパビリティとは、組織が備えていなければならない能力についての、安定した、テクノロジーに依存しない記述です。すなわち、保険金請求を決済する、顧客をオンボーディングする、需要を予測する、元帳を照合する、といったものです。ケイパビリティは企業の本質を記述するため、緩やかにしか変化しません。それを実現するアプリケーション、プロセス、インフラは絶えず変化します。計画をシステムではなくケイパビリティに根付かせることで、戦略には、組織再編やベンダーの変更、テクノロジーのサイクルを超えて生き残る座標系がもたらされます。

ケイパビリティモデルは、意図的に階層的であり、意図的に地味なものです。最上位には、同業のどの企業でも認識できる数十のレベル1ケイパビリティが位置します。その下には、投資とオーナーシップの意思決定が実際に行われる粒度に達するまで、さらに二、三段階の分解が続きます。このモデルの価値は分類体系そのものではなく、その上に何を重ねられるかにあります。各ケイパビリティは、事業上の重要度、それを支えるシステムの健全性とコスト、そしてそれに紐づく戦略的な野心について評価できます。その結果として生まれるのが、管理不能な環境を少数の優先順位付けされた対話へと変えるヒートマップです。

この捉え直しは、経営層が問う内容を変えます。特定のプラットフォームを更新すべきかどうかを議論する代わりに、どのケイパビリティが戦略的な差別化要因でありしたがって独自の投資に値するのか、どれが必要ではあるが差別化されておらしたがって標準パッケージの候補となるのか、どれが衰退しつつあり縮小させるべきなのか、という議論になります。内製か購買かは、調達上の反射的判断であることをやめ、そのケイパビリティがそのスペクトラム上のどこに位置するかの帰結となります。ロードマップは、プロジェクトの一覧であることをやめ、名前を持ったケイパビリティを現状から目標状態へと順序立てて移動させるものになります。ケイパビリティこそが、戦略とアーキテクチャに同じ言語を話させるものであり、両者をその時々のテクノロジーではなく事業につなぎとめておくものなのです。

この分野は、複数の力によって同時に再形成されつつあり、持続的な変化と一時的な流行とを見分けることが重要です。最も重大なのは、ドキュメントとしてのアーキテクチャから、生きたモデルとしてのアーキテクチャへの移行です。長年にわたり、目標アーキテクチャはスライド資料や静的なリポジトリの中に存在し、承認された日にはすでに陳腐化していました。現代の実務は、アーキテクチャをデータとして扱います。ケイパビリティ、アプリケーション、データフロー、テクノロジー、そしてそれらの関係性を、常に最新に保ち問い合わせ可能なモデルとして保持するのです。これによって、あるプラットフォームを廃止するとどのシステムが影響を受けるのか、あるいはどのケイパビリティがサポート終了を迎えるテクノロジーに依存しているのかを、四半期ではなく半日で答えることが可能になります。

第二の変化は、戦略と継続的デリバリーの境界の浸食です。テクノロジーが年に一度リリースされていた時代には、数か年計画と年次レビューで十分でした。チームが継続的にデプロイする時代には、静的な三か年計画は負債です。今日的な答えは、方向性を放棄することではなく、安定した目標を緩やかに保ちつつ、そこへ至る経路を頻繁に見直すことです。方向性は数年単位で定め、そこへ向かうロードマップは、実際に何がリリースされ、IT環境が今どのような姿になっているかに照らして、四半期ごとに見直します。

第三の力は、機械学習と生成系システムが計画にもたらす圧力です。ここには真に本質的なものがありますが、それは雑音に包まれて到来します。規律ある対応は、これらを他のものと同様にモデルの中に位置づけられるべきケイパビリティとして扱い、どれが差別化要因でどれがコモディティかを率直に評価することであり、すべてを再構築せよという指令として扱うことではありません。これと並行して、主権、データレジデンシー、レジリエンスの要件が、無条件のcloud移行の10年を経て、一部の組織を意図的なハイブリッドやオンプレミスの選択へと引き戻しつつあります。成熟した姿勢は、cloudファーストでもcloudオンリーでもなく、コスト、統制、規制上の制約に照らしてケイパビリティごとに配置を決めることです。これらのトレンドのいずれにおいても、変わらないものは同じです。対処できるのは、拠り所とするモデルを持つ組織であり、それを持たない組織は、ベンダーの売り込みから売り込みへとよろめき続けるのです。

目標アーキテクチャは、現実との接触を生き延びるように作られて初めて役に立ちます。第一の原則は、レイヤーをまたいだ関心の明示的な分離です。ビジネスケイパビリティ、それを実現するアプリケーション、それらのアプリケーションが管理するデータ、そしてそれらが稼働するテクノロジーは、それぞれ別個にモデル化され、明確な関係性によって結びつけられるべきです。これらのレイヤーが混同されると、一つのレイヤーの変更が予測不能な形で他のレイヤーへ波及し、意思決定の影響範囲を誰も追跡できなくなります。区別を保てば、アーキテクチャは辿れるものになります。戦略的なケイパビリティから、それを制約する特定のテクノロジーへと降りていくことができるのです。

第二の原則は、アーキテクチャ原則は少数で、具体的で、結果を伴うものでなければならないということです。差別化されないケイパビリティは購買し、差別化する領域でのみ内製するといった原則は、現実の案件を判断し、選択肢を排除するため有用です。我々はアジャイルで顧客中心であろうといった原則は、何も判断しません。良い原則は、その根拠とともに、そして決定的に重要なこととして、その含意を明示して書かれます。そうすることで、あるプロジェクトが例外を提案したとき、その例外のコストが可視化されます。侵し得ない原則は原則ではありません。それは願望です。規律は、各原則が課すトレードオフを名指しすることにあります。

第三の原則は、永続性ではなく交換可能性を前提に設計することです。IT環境の中に永遠に存在するコンポーネントは一つもありません。したがってアーキテクチャは、そのいずれかを取り除くコストを最小化すべきです。これは、深い統合よりも明確に定義されたインターフェースを、システム固有の定義よりも標準的なデータ定義を、そして組織やベンダーの境界が落ちる継ぎ目における疎結合を選好させます。参照モデルはここで存在意義を発揮します。統合、データ、あるいは共通ドメインのための共有された参照アーキテクチャは、チームに従うべき公認のパターンを与え、それによって個別の意思決定の数を、ひいては将来の負債の数を減らします。目指すのは、決して到来しない完璧な最終状態ではなく、各交換が発掘作業と化すことなく部品を取り替えられるIT環境です。

この分野における失敗の様式は、名指しできるほど一貫しています。象牙の塔。アーキテクチャ機能が引きこもり、デリバリーチームが理解も遵守もしない優美な目標状態モデルを生産します。それらの文書は内部的には整合していても、実務上は不活性です。処方箋はより良い図ではなく、アーキテクトを現実の意思決定の流れの中に組み込むことです。そこでは彼らのモデルは実際のプロジェクトに照らして検証され、その摩擦によって最新に保たれます。

戦略と環境が乖離する。方向性が確信を持って定められた後、組織はIT環境が実際にそこへ向かって動いているかを確認しなくなります。プロジェクトは成果を上げ、例外は積み重なり、三年後には、誰も見直さなかった目標に現実の環境はほとんど似ていません。これは最も一般的で最も腐食性の高い失敗です。なぜなら、個々の逸脱はそれぞれ合理的だったからです。これを防ぐには、意図と現実を一定の周期で比較し、その差分を第一義的な管理シグナルとして扱うガバナンスのリズムが必要です。

反射的な内製対購買。意思決定が、ケイパビリティが戦略的にどこに位置するかに照らして個別に判断するのではなく、組織が文化的に好むもの、すなわちできるからという理由ですべてを内製する、あるいはエンジニアリングを避けるためすべてを購買する、という方向に既定化されます。その結果、コモディティ機能に対する独自システムが生まれたり、まさに差別化すべきケイパビリティにパッケージの制約が課されたりします。プロジェクト一覧としてのロードマップ。順序立てられたケイパビリティの移動ではなく、資金の付いたプロジェクトを列挙するロードマップは、すでに承認されたものに最適化し、組織がどこへ到達しようとしているのかという筋道を見失います。大海を沸かそうとすること。何かを決める前に環境全体を一律の深さでモデル化しようとする試みは、膨大な成果物を生み出しながら何の意思決定も生みません。規律とは、意思決定が要求する深さまでモデル化し、それ以上は踏み込まず、そして前へ進むことです。これらの失敗はいずれも一つの根を共有しています。事業の意図と技術的現実とをつなぐ結合組織が、断ち切られるのを許してしまっているのです。

Nashuaは、IT戦略とアーキテクチャを、成果物とともに終わる一回限りの関与ではなく、継続的な実践として扱います。この仕事は通常、座標系を確立することから始まります。すなわち、この組織が実際にどう機能しているかを反映し、事業上の重要度、システムの健全性、コストの観点から評価されたケイパビリティモデルです。その評価は意図的にエビデンス主導です。理想化された組織図を受け入れるのではなく、Nashuaは現実のIT環境を精査します。どのアプリケーションが存在し、それらにいくらかかり、どう統合され、どのケイパビリティを実際に支えているのか。そこから浮かび上がるヒートマップは、たいてい居心地の悪いものであり、常に明晰化をもたらします。意図と現実のギャップを初めて可視化するからです。

そのベースラインから、方向性は同じケイパビリティ言語で表現された目標アーキテクチャとして定められ、トレードオフを明示して書かれた少数のアーキテクチャ原則が添えられます。Nashuaが好むのは、案件を判断する原則と、チームに公認のパターンを与える参照モデルです。それによってアーキテクチャは、レビューの層を加えるのではなく、未解決の問いの数を減らします。内製対購買、cloud対オンプレミスの意思決定は、一律の方針としてではなく、そのケイパビリティの戦略的な重み、そして規制上およびコスト上の制約に照らして、ケイパビリティごとに枠組みされます。

それに続くロードマップは、現状から目標状態へのケイパビリティの移動として順序立てられ、依存関係と廃止が新規投資と同じくらい可視化されます。組織が停止させるシステムは、構築するシステムと同じくらい重要だからです。決定的に重要なこととして、Nashuaは戦略と環境の乖離を防ぐガバナンスのリズムを制度化します。すなわち、IT環境が実際にどこにあるかを、目標が示すべき姿と定期的に比較し、その差分を次の意思決定を駆動するシグナルとして扱うのです。これは華やかさに欠け、最も頻繁に省略される部分ですが、まさにそれゆえに価値が積み上がる場所なのです。Nashuaの役割は、そこへ至る経路を組織が実際に達成してきたものに照らして見直しながら、方向性を安定して保つことにあります。

Nashuaがもたらす違いは、何か単一の成果物というよりも、意図と現実を時間をかけてつなぎ続ける規律にあります。多くの企業が目標アーキテクチャを生み出せますが、局所最適化の圧力が作用する時間を経た二年後にも、なおそれに照らしてガバナンスを続けている企業ははるかに少数です。Nashuaの実務者たちは、戦略を定める側と、その結果として生じるIT環境とともに生きる側の、両方の立場に座ってきました。その経験は、一般論ではなく具体的な助言に、そして最初の静かな一週間ではなく最初の困難なプロジェクトを生き延びる原則に、表れます。この仕事の尺度は、モデルの優美さではなく、数年後に組織が、自らがどこへ向かっているのか、どこまで進んでいるのかを、なお自信を持って言えるかどうかです。

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

これらを結びつけるのは、この分野を演劇にすることへの拒絶です。戦略とアーキテクチャは、何が構築され、何が購買され、何が停止されるかを変え、そして事業とそのテクノロジーが足元で動いていく中でもそれを変え続けたときにのみ、その価値を証明します。Nashuaの貢献は、そのつながりを持続的なものにすることです。すなわち、事業が認識するケイパビリティで表現された方向性についての共有された方針を、途切れることのない周期で現実のIT環境に照らして誠実に保ち続けることです。それこそが、テクノロジー環境が、それが支えるべき組織から乖離していくのを食い止めるものであり、そして熟慮された協力者が、いかなる図よりも価値を持つ場所なのです。