はじめに
こんにちは。エーピーコミュニケーションズ ACS事業部 亀崎です。
先日の記事で、プラットフォームを「プロダクト」として捉え、顧客（開発者）のペルソナに寄り添うことの 重要性を説きました。
しかし、この「顧客中心主義」を愚直に実行しようとすると、Platform Teamはある深刻な問題に直面します。 それは、「開発者の負担を減らせば減らすほど、Platform Team側の認知負荷が爆発する」という パラドックスです。
多種多様な開発チームからの要望、複雑化するクラウドネイティブなツール群、そして止まらない技術進化。 これらすべてをチームが背負い込めば、プラットフォームは組織の「複雑さのブラックホール」となり、 いずれチームは燃え尽き、組織全体のボトルネックへと変貌してしまいます。
本記事では、Platform Teamが持続可能であるための「生存戦略」について、認知負荷理論、Team Topologies、 そしてInnerSourceの観点から深く掘り下げます。
なお、認知負荷については以下の記事にて説明しております。こちらもご覧ください。
複雑さは消えない、移動するだけである
まず、私たちが認めなければならない残酷な真実があります。それは 「システムの複雑さの総量は変わらない」 ということです。 Platform Engineeringが行っているのは、複雑さを消し去ることではなく、開発者が触れる場所から 「別の場所」へ移動させているに過ぎません。
認知負荷理論の観点で見れば、開発者が本来集中すべきビジネスロジックの開発（学習関連負荷：Germane Load）を 最大化するために、インフラ操作や環境構築といった「課題外在性負荷（Extraneous Load）」を プラットフォーム側が引き受けている状態です。
しかし、戦略なき抽象化は組織内のあらゆる外在性負荷をPlatform Team一点に凝縮させます。 もしあなたのチームが、全チームのTerraformコードを代筆し、 すべてのKubernetesのトラブルシューティングを肩代わりしているのなら、 それはプラットフォームを提供しているのではなく、単に「苦労を一人で背負っている」だけです。 この状態では、チームの脳内メモリはすぐに枯渇し、新しい価値を生むための余力は失われてしまいます。
Platform Engineeringの真の価値は「複雑さを整理・カプセル化することで、 組織全体の認知負荷の総量を下げる」ことにあります。単なる「移動（押し付け合い）」ではなく 複雑さを移動させ、かつ パターン化して閉じ込める（カプセル化する）ことで、 組織全体の無駄な試行錯誤を減らすことが重要です。
Team Topologies で 課題外在性負荷を「インターフェース」で隔離する
この認知負荷の爆発を防ぐための強力な武器が、「Team Topologies」の考え方です。 Team Topologiesでは、チーム間のInteraction（関わり方）を設計することで、不要なコミュニケーションコストを削減することを目指します。
Platform Teamが最も警戒すべきは、人間同士の「密な同期」という課題外在性負荷です。 「この設定はどうすればいいですか？」「権限を承認してください」「エラーが出たので見てください」――。 こうしたチャットやミーティングによる割り込みは、チームの集中力を細切れにし、認知負荷を劇的に高めます。
これを回避するための戦略が 「X-as-a-Service（サービスとしての提供）」への純化です。 Platform Teamは「人」ではなく「ドキュメントとAPI、セルフサービスポータル」を インターフェースとして提供する ことに集中すべきです。 開発者が誰かに質問することなく、提供されたインターフェースを通じて自己完結できる状態（セルフサービス化）を作ること。 それは単に便利なだけでなく、Platform Teamの脳を「他人からの割り込み」から守るための強力な防御策なのです。
また、特定のチームを直接支援する「Enablement」を行う際も、期間を限定し、 最終的には「プラットフォーム経由のセルフサービス」へ回帰させる出口戦略が不可欠です。
InnerSource で 実装の責任を「連邦制」で分散する
次に直面するのは、プラットフォームに対する「果てしない機能要望」です。 「特定のプロジェクトでしか使わない特殊なミドルウェアをサポートしてほしい」 「自チーム専用のデプロイフローを作ってほしい」 といった要望にすべてPlatform Teamが対応しようとすれば、コードベースは肥大化し、 チームの「課題内在性負荷（Intrinsic Load）」は限界を迎えます。
ここで取り入れるべきが、社内でのオープンソース的手法である 「InnerSource（インナーソース）」 です。 プラットフォームを「中央集権的な巨大な城」にするのではなく、「プラグイン可能な基盤」として設計します。 Platform Team自体の内在性負荷（基盤の巨大化による複雑さ）を抑えるためにInnerSourceが必要 なのです。
たとえば、プラットフォームのコア部分はチームが厳格に管理しますが、特定の言語向けのテンプレートや 特殊な監視ダッシュボードなどは、それを必要とする開発チーム自身が実装し、 プラットフォームにコントリビューション（貢献）する形をとります。 Platform Teamの役割は「すべてを作る人」から「コントリビューションの道筋を整え、 品質をガードレールで守る人（メンテナー）」へとシフトします。 これにより、実装の負荷を組織全体に分散しながら、プラットフォームの多様性を確保することが可能になります。
ここで注意していただきたいのは、「InnerSourceは短期的には認知負荷を上げるリスクがあるということです。 開発チームからのプルリクエスト（PR）をレビューし、プラットフォームの設計思想を説明し、 修正してもらうプロセスは、単純な「セルフサービス」よりもPlatform Teamの脳内メモリを 消費します。 InnerSourceは短期的には認知負荷を上げることがありますが、長期的には 『特定チームの要望をPlatform Teamが実装し続ける』という無限ループから脱却するための投資 である、と理解することが重要です。
知的資産の「負債化」を防ぐ、捨てる勇気
Platform Teamの認知負荷を管理する上で、最も見落とされがちなのが「既存機能の廃止」です。 機能が増えれば増えるほど、それを維持・把握するためのコストは累積していきます。 1年前に特定のチームのために作った「間に合わせの機能」が、 今では誰も詳細を知らない「謎の遺産」としてチームの認知負荷を圧迫している、といったこともあるのでは ないでしょうか。 生存戦略として重要なのは、定期的に以下に示すような「不要になった抽象化」を捨てることです。
- 利用率が低いテンプレートの廃止
- 古くなった技術スタックのサポート打ち切り
- 標準機能に統合された独自実装の削除
これらを「プロダクトの掃除」として定期的に行うことで、チームの脳内メモリを常にクリーンに保ち、 技術的負債が認知負荷のブラックホールになるのを防ぎます。
もちろん現実には「使っているチームがいるから捨てられない」というジレンマが発生します。 プロダクトとして『ライフサイクルポリシー（EOL）』を明示する」など、 感情や勇気に頼らない 仕組みとしての解決策 を決めておくことでこうしたジレンマも低減できます。
最後に : Platform Teamの「余裕」こそが組織の競争力である
Platform Engineeringの成功は、Platform Team自身の健全性に依存します。 チームが日々の運用や問い合わせ対応、肥大化したコードのメンテナンスで手一杯になれば、 将来に向けた技術投資や、真に開発体験を向上させる革新的な機能開発は止まってしまいます。
「Team Topologies」によるコミュニケーションの疎結合化、そして「InnerSource」による実装責任の分散。 これらは Platform Teamが「創造的な余力」を持ち続けるための戦略です。
チームに「余裕」があるからこそ、開発者の隣を歩き、一歩先の課題を解決する力が生まれます。 まずは、現在のチームの時間を奪っている「割り込み」や「個別対応」を可視化し、 それを「仕組み（プロダクト）」に置き換えるための第一歩を踏み出してみましょう。
