アーキテクチャガバナンスには評判上の問題があり、それは概ね当然のものです。二十年にわたって支配的だったイメージは、隔週で開催され、誰も読む時間のないテンプレートを要求し、デリバリーの圧力のもとですでに決定が下された数週間後に判定を返す審査委員会というものでした。そのモデルは、長いリリースサイクルと中央集権的な統制の時代のために作られていました。その時代には、資産における重要な選択は数が少なく、変化も緩やかであったため、アーキテクトがそれらを審査することがそれなりに現実的だったのです。

その時代は終わり、それが終わった理由こそが、まさに今ガバナンスがより重要になっている理由であって、重要でなくなっている理由ではありません。デリバリーは、継続的にリリースを行い、自らのスタックを所有するプロダクトチームへと分散しました。cloudはプロビジョニングをAPI呼び出しに変えました。つまりエンジニアは、調達の関門に足止めされることなく、一つの午後で組織を新しいデータベース、新しいリージョン、あるいは新しいライセンス方針へと縛り付けることができるのです。重大な帰結をもたらす意思決定の面積は増大した一方で、それらを審査する従来の仕組みは同じ大きさのままにとどまりました。その結果生じるのがドリフトです。劇的な失敗ではなく、あらゆるチームが局所的には合理的でありながら、資産全体としては一貫性を失い、変更に費用がかかり、把握することが不可能になっていく緩やかな乖離です。

それと並行して、賭け金も上がっています。DORAやNIS2といった規制枠組みは今や、アーキテクチャ上および運用上の意思決定が相当の注意義務をもって行われたことを組織に証明するよう求めています。これは技術的な問題である以前に、ガバナンスの問題です。要点は隔週の審査委員会を復活させることではありません。一貫性はもはやひとりでには生まれないこと、そしてそれを生み出す規律は、緩やかな時代の遺物として放棄されるのではなく、分散した高速に動く資産のために再設計されなければならないことを認識することにあります。

アーキテクチャガバナンスは単一の仕組みではありません。それは四つの手段からなるシステムであり、それらは組み合わさってはじめて機能します。そして機能不全の大半は、そのうちの一つか二つを孤立させて運用することから生じます。第一は原則です。すなわち、組織が何を、なぜ大切にするのかを表現する、持続的な論拠の言明です。良い原則は決まり文句ではありません。それは含意と根拠を備えており、二つの原則が衝突するとき、それは必ず起こるのですが、そのトレードオフを役職の上下ではなく明示された論拠に基づいて論じることができます。原則は個々の意思決定よりも長く存続し、他の手段に正当性を与えます。

第二の手段は標準です。すなわち原則を具体的で検証可能な形で表現したものです。原則が、組織は自己運用のインフラよりもマネージドサービスを選好すると述べるところで、標準は認可されたマネージドサービス、その利用条件を名指しし、理想的には準拠を検証するチェックを符号化します。標準は意図が実行可能になる場所です。標準がなければ原則は飾りにすぎず、上位に原則がなければ標準はチームが当然にも反発する恣意的な規則にすぎません。

第三の手段は意思決定権です。すなわち、誰が何を、どの高度で決定する権限を持つのかを明示した地図です。これは組織が最も暗黙のままに放置しがちな手段であり、その欠落は高くつきます。なぜならそれがないと、あらゆる意思決定は潜在的に全員の関心事となり、したがって誰の明確な責任でもなくなるからです。第四の手段は審査、すなわち真に重大でかつ真に論争のある少数の意思決定が審議される委員会あるいはフォーラムです。これら四つすべてを取り囲むのが例外の仕組みです。すなわち、文書化され擁護しうる理由によって標準に違反する選択に対し、規律をもって期限を区切って特例を認めることです。例外をきちんと認めることのできない組織は、そのチームが黙って例外を取っていくのを目にすることになります。それは名を変えたドリフトにほかなりません。

現代の実務における最も重要な転換は、ゲートからガードレールへの移行であり、この言葉はしばしば曖昧に使われるため、正確に述べる価値があります。ゲートは同期的な検問所です。作業が止まり、人間が精査し、デリバリーが進む前に判定が下されます。ガードレールは符号化された制約であり、継続的に、そしておおむね人間の介入なしに作用し、範囲内のものはすべて許可し、範囲外に落ちるものだけを警告あるいは遮断します。ガバナンスをうまく行っている組織は、できる限り多くのゲートをガードレールに変換し、人間による審査を、真に判断を要する残余のために取っておいています。

ここでpolicy as codeが中心的なものとなりました。ランディングゾーン、認可されたインフラモジュール、パイプラインのチェックは、標準をエンジニアがすでに使っている経路に直接符号化するため、準拠した選択が同時に最も速い選択にもなります。アーキテクチャ意思決定記録、すなわちADRは、あれば良いものから、分散ガバナンスの結合組織へと成熟しました。それは何が決定されたか、検討された選択肢、そしてその論拠を捉える軽量でバージョン管理された記録であり、誰も訪れない別のリポジトリではなくコードのそばに置かれます。ADRはガバナンスを、会議なしに非同期で判読可能なものにします。

さらに二つの潮流がこの分野を形づくっています。分散型あるいはチームトポロジーに沿ったガバナンスは、意思決定権を意図的に分配し、自律的なプロダクトチームを、薄い支援機能と舗装された道を担う共有プラットフォームと組み合わせます。そして変化の量の増大は、チームがはるかに多くをより速く生み出しプロビジョニングできるようにするAI支援開発によって今や増幅されており、各意思決定の人間による精査に依存するあらゆるモデルに負荷をかけています。進む方向は明白です。規模に耐えるガバナンスとは、おおむね符号化され、おおむね非同期で、真の境界に近づくまではおおむね不可視なガバナンスなのです。

ガバナンスそれ自体が設計されたシステムであり、技術アーキテクチャに適用されるのと同じ厳格さがそれにも適用されるべきです。第一の設計原則は補完性です。意思決定は、それをうまく下せる最も低い階層で行われるべきです。一つのチームにしか影響しない選択はそのチームが決めるべきであり、その帰結が境界を越える選択、組織を共有された未来に縛り付ける選択、あるいは元に戻すのに費用がかかる選択だけが、上位への引き上げに値します。この高度を正しく設定することが技芸の大半を占めます。低く設定しすぎれば委員会は溺れ、高く設定しすぎればチームは幼児扱いされ、プロセスを迂回します。

第二の原則は比例性です。プロセスの重さは、意思決定の重さと可逆性に見合っていなければなりません。ジェフ・ベゾスの一方向の扉と双方向の扉の区別は有用な視点です。可逆的な意思決定は委譲され迅速に下されるべきであり、不可逆あるいは不可逆に近いものだけが委員会という儀式に値します。第三の原則は、舗装された道が真に最も容易な経路でなければならないというものです。準拠した選択肢が、間に合わせのものよりも遅く、より苦痛で、あるいは文書化が乏しければ、どれほど方針を定めても持ちこたえません。なぜならエンジニアはリリースすることを最適化するのであり、それは正しいことだからです。ガバナンスは、代替案を取り締まることによってではなく、認可された道への投資によって準拠を勝ち取ります。

第四の原則は論拠の透明性です。根拠とともに記録された意思決定は、状況が変わったときに見直すことができます。むき出しの判定として下された意思決定はそれができず、硬直化します。第五は、審査は期限が区切られ、既定で許容的でなければならないというものです。定められた期間内に阻止されなかった意思決定は進行します。この単一の反転、すなわちオプトイン型の承認から、範囲を区切った異議申し立てへの反転こそが、ガバナンスがデリバリーの恐れる行列になるのを防ぐものです。これらの原則はまとまって、重要な少数の事柄を制約し、それ以外のすべての邪魔をしないガバナンスを描き出します。

象牙の塔の委員会。 デリバリーから切り離された上級アーキテクトの集団が、資産の現実ではなく理想化されたモデルに照らして意思決定を審査します。その判定は技術的には擁護可能ですが実務的には無視され、認可されたアーキテクチャと稼働しているアーキテクチャの隔たりは、スプリントごとに広がっていきます。治療法は委員会により多くの権限を与えることではなく、構築し運用する人々を含む構成と、真に横断的な関心事に範囲を絞った権限です。

ゴム印。 その正反対の病理です。委員会は開催されますが、デリバリーの圧力のもとであらゆるものを承認します。なぜなら、否と言うことには目に見える代償があり、諾と言うことには先送りされた代償があるからです。ガバナンスは芝居となり、時間を消費しながら何も変えません。これはたいてい、委員会が誤った高度で意思決定を審査していることを示しています。委譲されるべきだった選択に注意を費やし、その結果、本当に重要な意思決定に注意が残っていないのです。

例外の健忘。 特例は口頭で、あるいはチケットの中で認められ、そして忘れ去られます。それぞれは孤立して見れば合理的でしたが、その累積を誰も追跡せず、二年後には資産は恒久化した一時的例外の博物館になっています。有効期限と所有者のない特例は例外ではなく、静かな標準の変更です。管理者のいない標準は隣接する失敗です。規則が公表され、著者は去り、それを正当化した文脈は失われ、チームは今や誰も説明できず、また改訂する権限も持たない何かに準拠します。そしてボトルネック、これはこの規律全体が回避するために存在する失敗です。審査はデリバリーが並んで待たねばならない同期的な行列となり、組織の最も有能なエンジニアたちは、ガバナンスを通り抜けるのではなく迂回することに日々を費やし、委員会の見えないところで本当の意思決定を下すのです。これらのかたちの一つひとつがガバナンスを支援者から障害物へと変え、その一つひとつはガバナンスの対象となる人々の失敗ではなく、ガバナンスシステムにおける設計上の欠陥なのです。

Nashuaはアーキテクチャガバナンスを、発令されるべき方針としてではなく、設計され調整されるべきシステムとして扱います。私たちはまず、組織がすでに持っているガバナンスを地図化することから始めます。なぜなら、それは常に何かしら存在し、そしてたいてい文書化されていないからです。現在どの意思決定が引き上げられ、それは誰へと向かうのか。チームはどこで明示されたプロセスを静かに迂回しており、それはプロセスがどこで誤って較正されているかについて何を明らかにするのか。ドリフトはすでにどこで蓄積しているのか。この診断は意図的に体裁を取り繕いません。なぜなら、意思決定が実際にどう下されているかという正直な姿こそが、それを変えるための唯一健全な基盤だからです。

そこから私たちは四つの手段を協調させて取り組みます。私たちはスローガンではなく根拠を備えた原則を言語化する手助けをし、それらを検証できるほど具体的な標準へと翻訳します。私たちは意思決定権を明示し、高度の線を引くことで、大多数の意思決定が明確にチームに置かれ、重大な少数だけが委員会に届くようにします。私たちはその委員会を速度と正統性のために設計します。適切な構成、絞られた権限、期限を区切った既定で許容的な審査、そして論拠が生き残るようADRとして記録される意思決定です。決定的に重要なこととして、私たちは例外の仕組みを一級のものとして扱い、所有者と有効期限を備えた特例と、例外の累積を隠れた負債ではなく可視の信号へと変える登録簿を設けます。

標準を符号化できるところではどこでも、私たちはゲートよりもガードレールを選び、チェックをランディングゾーン、パイプライン、舗装された道に組み込むことで、準拠が善行ではなく最も抵抗の少ない道になるようにします。私たちは比例について率直です。より小さな組織は規制された企業よりも軽い仕掛けを必要とし、それを支えきれない文脈に重いガバナンスを課すことは、私たちが排除しようとしているまさにあの芝居を生み出します。私たちの一貫した狙いは、クライアントが私たちなしでも運用できるガバナンス機能です。なぜなら、そのコンサルタントに依存するガバナンスはガバナンスではなく、依存だからです。

Nashuaを際立たせるのは、ガバナンスを文書作成の作業として扱うことへの拒絶です。原則のカタログと委員会の憲章なら誰でも供給できます。違いは、その結果生じるシステムが意思決定の下され方を実際に変えるかどうか、そしてそれが誰もが予言したボトルネックになることなくドリフトを抑え続けるかどうかにあります。私たちはその成果によって自らの仕事を測ります。重大な意思決定はより速く、より一貫して下されているか。チームは舗装された道が最も容易だからそれを選んでいるか。そして例外登録簿は静かに膨らむのではなく縮んでいるか。これらの信号を改善するガバナンスは機能しています。文書に何と書かれていようと、成果物しか生み出さないガバナンスは機能していません。

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

私たちの第二の差別化要因は、調整するのに十分な期間とどまるということです。紙の上で立ち上げられ放置されたガバナンスシステムは、組織が変化するにつれて較正から外れていきます。昨年正しかった高度の線が、チームが成熟し資産が進化する今年には誤ったものになるのです。私たちはガバナンスを、運用の中で観察され調整されるべきものとして扱い、引き上げがどこに集中するか、例外がどこに累積するか、そしてチームがどこでプロセスを迂回するかを見守り、それらを準拠の失敗としてではなく設計上のフィードバックとして読み取ります。最後に、私たちは比例という実務者の規律をもたらします。私たちは、クライアントが必要とするガバナンスを構築するのと同じくらい進んで、クライアントが必要としないガバナンスを思いとどまらせます。なぜなら、この規律全体の信頼性は、それが一貫したデリバリーを妨げるのではなく可能にすることにかかっているからです。それが私たちが自らに課す試金石であり、そこでこそ違いが生まれるのです。