認知的技術的負債：チーム間で「毎回すり合わせている」のは負債である

その協業、資産を残しているか

3か月間、チームAとBが密に共同開発してきた。週次で同期会議、Slackで毎日やり取り、互いのコードレビューにも参加。成果物はコードと機能、確かに前に進んでいる。

だが、こう問うてみてほしい。この3か月で、二つのチームの境界を記述する契約（Contract）は残ったか。設計判断を記録したADRはあるか。共通語彙の定義はあるか。

もし答えが「ない」なら、あなたのチームは負債を積んでいる。本稿ではこれを認知的技術的負債と呼ぶ。通常の技術的負債と同じく、複利の利子がつく負債だ。

チーム間のすり合わせはなぜ高コストなのか

まず、なぜチーム間の協業がこれほど疲れるのかを構造的に見る。原因は3つある。

第一に、すり合わせの機会が少ない。 チーム内なら毎日顔を合わせ、コードを共有し、PRを互いにレビューする。チーム間は定例が週次・月次に限られ、コードベースも分離され、日常的な接点が構造的に不足している。

第二に、理解の方向が違う。 チーム内のメンバーは同じドメインの枠組みを共有している。チーム間は異なるBounded Context——異なる「注文」の意味、異なる前提——を持つ。方向の違いは、単なる知識の深浅の違いより、すり合わせのコストが高い。

第三に、翻訳負荷が高い。 「この変更がそちらのサービスに影響する」——この一文を正確に理解するには、相手のサービスの構造をある程度頭に載せている必要がある。載せていなければ、影響の範囲も深刻度も推定できない。

この3つはすべて、人間の認知に容量の上限があることから派生する。だからチーム間協業の困難は、個人のコミュニケーション能力の問題ではなく、設計で対処すべき構造的な問題なのだ。

プロトコル変換器：すり合わせを装置に移す

対処の鍵がプロトコル変換器だ。二つのBounded Context間で、意味を機械的に変換する装置を指す。具体的には、API仕様、型定義、共有語彙、ADR。

これらの共通点は、チーム間の翻訳を人間のすり合わせに頼らずに処理することだ。API仕様は「このエンドポイントに何を送れば何が返るか」を記述し、翻訳を機械化する。型定義はコンパイル時に境界の整合性を検証する。ADRは「なぜこの境界がここに引かれたか」の推論指針を残す。

すり合わせという認知プロセスを、変換器という装置のフィードバック機能に移し替える。これがチーム間協業設計の本質だ。

Team Topologiesの3モードを「コスト負担設計」で読み直す

『Team Topologies』が示した3つのインタラクションモードを、この「すり合わせコストを誰がどれだけ負担するか」という観点で読み直すと、驚くほど整理される。

Collaboration：一時的にコストを引き上げる

Collaborationは二つのチームが密に連携するモードだ。すり合わせループを一時的にチーム内並みの頻度に引き上げる。

コスト負担は明快だ。双方のチームが、通常業務に加えて相手の枠組みを理解するコストを負う。 各メンバーは自分のBounded Contextに加えて、相手のContextの一部を頭に載せる。認知資源の大幅な消費だ。

そしてここが最重要の洞察だ。Collaborationは持続不可能である。 双方が相手の枠組みを保持し続けるコストは、認知の有限性の下では長続きしない。本来の業務に使える認知資源が減り続けるからだ。だからCollaborationは手段であって目的ではない。

では目的は何か。コードを書くことでも機能を出すことでもない。

Collaborationの成果物は、プロトコル変換器である。

Collaboration中に双方の理解をすり合わせ、境界がどこにあるかを認識共有し、それを契約・型・ADR・共有語彙として結晶化させる。変換器が機能し始めたら、Collaborationを解消する。だから、Collaborationに入るときの問いはこうだ。「どの変換器を作れば、この協業を不要にできるか」。 出口条件は、変換器が動き始めたときだ。

認知的技術的負債という失敗形態

ここで冒頭の話に戻る。出口のないCollaboration——変換器が蓄積しないまますり合わせを払い続ける状態——が、認知的技術的負債だ。

3か月のCollaborationの後、成果物がコードと機能だけで、契約もADRも共有語彙も残っていない。この状態でCollaborationを解消するとどうなるか。変換器がないので、チーム間のやり取りは再び人間のすり合わせ——「あのとき話した仕様どうだっけ」「この境界の挙動、誰が知ってる」——に戻る。3か月分の認知コストが、構造的な資産にならなかった。

そしてこの負債には利子がつく。変換器がないまま時間が経つと、Collaboration中に共有されていた理解が各人の記憶の中で劣化する。同じ境界の問題に再び直面したとき、すり合わせを一からやり直す。利子は複利的に増える。「毎回すり合わせている」という状態は、快適な協業ではなく、返済していない負債なのだ。

X-as-a-Service：すり合わせを回さない安定状態

X-as-a-Serviceは、一方がサービスを提供し、もう一方が契約を通じて利用するモードだ。すり合わせループを回さない前提で設計される。

なぜ回さずに済むか。契約というアーティファクトがフィードバック装置として機能するからだ。利用者は契約を読むだけで使い方を理解でき、契約に反する使い方をすればエラーが返る。人間の解釈に依存しないフィードバックだ。

ただし、これは契約の「推論可能性」——外部仕様から内部の構造や意図をどれだけ推し量れるか——に全面的に依存する。推論可能性の低い契約では、利用者は提供チームに直接問い合わせるしかなく、Collaborationに逆戻りする。

Facilitating：すり合わせ能力そのものを移転する

Facilitatingは、一方のチームがもう一方の能力を育てるモードだ。Enabling Teamが専門知識を共有し、Stream-aligned Teamが自律的にその技術を使えるようにする。

コスト負担は、Enabling Teamが一時的にコストの大半を負い、相手の自律的なすり合わせ能力を育てる。Collaborationとの違いは、方向が一方向であることと、成果物が変換器ではなく「受け手の能力」であることだ。

Facilitatingの利点はスケーラビリティだ。能力が移転されれば受け手は自律的にすり合わせられる。一つのEnabling Teamが複数チームに順次Facilitatingすることで、組織全体の能力が底上げされる。

どのモードを選ぶか

3モードは排他的な選択肢ではなく、同じ二チームの関係が時間とともに遷移する。そしてどのパターンでもX-as-a-Serviceが安定状態で、CollaborationとFacilitatingはそこに至る過渡的モードだ。X-as-a-Serviceが最も認知負荷が低いからだ。

選択は3つの問いで導ける。

1. 契約は存在するか。 なければCollaborationで構築する
2. 契約の推論可能性は十分か。 十分ならX-as-a-Serviceで運用する
3. 推論可能性が不十分なのは、知識不足か契約設計の問題か。 知識不足ならFacilitating、設計の問題ならCollaborationで再設計する

まとめ

チーム間協業で「毎回すり合わせている」状態は、快適さではなく負債のサインだ。較正コストを払い続けているのに、それを構造的に減らすアーティファクト——契約・ADR・共有語彙という変換器——が蓄積しないなら、それは認知的技術的負債であり、複利の利子がつく。

Collaborationの成果物はコードではなく変換器である。この一点を意識するだけで、協業の設計が変わる。協業に入るときは「どの変換器を作れば、この協業を不要にできるか」を問う。そしてX-as-a-Serviceという、すり合わせを回さずに済む安定状態を目指す。すり合わせを美徳にするのではなく、すり合わせを不要にする装置を残すこと——それがチーム間協業の設計だ。

---

本稿は、認知的な制約とフィードバック設計の観点からソフトウェア開発を再構成する書籍『認知フィードバックデザイン』の第9章をもとに再構成したものだ。プロトコル変換器やCollaborationの持続不可能性が、なぜ「保持負荷の有限性」という公理から導けるのか、その論証に興味があれば、ぜひ書籍を参照してほしい。