本記事の3行まとめ
- チームトポロジーは「早く・安全に価値を届ける」組織設計のフレームワーク
- AI時代だからこそ、4つのチームタイプと認知負荷の考え方を理解する
- すべての事象は豚カツで説明できる
はじめに
2025年、生成AI（GitHub Copilot、ChatGPT、Claudeなど）が急速に普及し、開発現場はかつてないスピードで変化しています。
ツールは便利になった一方で、 「新しい認知負荷」 をチームに持ち込んでいるのではないか？という問いが浮かびます。
この記事では、ソフトウェア組織設計のフレームワーク 「チームトポロジー」 をベースに、AI時代に改めて考えるべき組織デザインについて整理します。あと豚カツの話をします。
チームトポロジーとは？
チームトポロジー（Team Topologies） は、2019年に出版されたソフトウェア開発組織の設計論です。2021年に日本語訳が出版されています。
ポイントは「認知負荷を適切に分散させ、価値を早く・安全に届ける」こと。
本記事で紹介する主なキーワードは以下です：
- 認知負荷：チームが処理できる情報量には限界がある
- 4つのチームタイプ：ストリームアラインド、プラットフォーム、コンプリケイテッド・サブシステム、イネイブリング
- 3つのインタラクションモード：コラボレーション、ファシリテーション、サービス提供
※書籍では、他にも逆コンウェイ戦略、チームAPI、組織的センシング、チームサイズ（ダンバー数） など、多くの重要な概念が紹介されています。
4つのチームタイプ
チームトポロジーでは、すべてのチームを次の4種類に分類します。
| チームタイプ | 役割 | 具体例 |
|---|---|---|
| ストリームアラインド | 顧客価値を直接届ける | ECサイト検索、決済機能 |
| プラットフォーム | 共通基盤を提供する | CI/CD、クラウド基盤 |
| コンプリケイテッド・サブシステム | 高度な専門領域を担う | 暗号化ライブラリ、レコメンド |
| イネイブリング | 学習・支援を行う | アジャイルコーチ、テスト自動化支援 |
豚カツ屋におけるチームトポロジー
概念をイメージしやすくするために「豚カツ屋」で例えてみましょう。
- ストリームアラインドチーム＝ホール・キッチンスタッフ（お客に直接価値を届ける）
- プラットフォームチーム＝POSシステム、調理器具、おいしい豚などの調達（基盤整備）
- コンプリケイテッド・サブシステムチーム＝先代から続く秘伝のタレ（専門性・複雑性）
- イネイブリングチーム＝接客トレーニングの開催、食材の品質管理研修（能力移転）
完成した「トンカツ＝顧客への価値」と考えると、組織設計のイメージが掴みやすいはずです。
生成AIにおける新たな認知負荷のリスク
生成AIは「導入すれば便利」という単純な話ではありません。
ストリームチームにとっては、AIそのものが新しいドメインとして立ち現れ、学習コストや運用ルールが増えることで認知負荷を高めるリスクがあります。
ありがちな落とし穴
- プロンプト作成やガイドライン学習に時間を取られる
- アップデートが早く覚えることが多すぎて疲れてしまう
- セキュリティやガバナンスのルールが増えて開発が重くなる
解決の糸口
チームトポロジーの観点を応用すれば、これらは制御可能です。
- プラットフォームチーム：安全に使えるAI基盤を整備する
- イネイブリングチーム：AIリテラシーやプラクティスを教育・支援する
- インタラクションモードを切り替え、状況に応じてコラボレーションやファシリテーションを実施する
まとめ：AI時代でも有効な組織デザイン
- チームトポロジーは技術論ではなく組織デザイン論
- 生成AI時代に重要なのは、便利さよりも認知負荷をどうコントロールするか
- 個人の努力に頼るのではなく、仕組みとしてチームを強くすることがカギ
行動提案
- 自分のチームを4タイプに当てはめてみる
- チームAPI（目的・責務・連携方法）を1文で書いてみる
- AIツール導入時に「認知負荷は増えていないか？」を問いかけてみる
参考文献
今回紹介した内容は、チームトポロジーの一部です。より深く学びたい方は、ぜひ書籍を手に取ってみてください。
おわりに
今回の記事は、福岡でのLT登壇をもとに再構成しました。
「チームトポロジーをAI時代にどう実践できるか？」という視点が、みなさんの現場にもヒントになれば幸いです。
楽天のエンジニアによる技術ブログです。このブログは公式ブログではなく有志で運営しています。 記事の内容は個人の見解であり、所属する企業や組織の立場、戦略、意見を代表するものではありません。
Discussion