🤖

『Architecture for Flow』第7章を読む：Wardleyマップでチーム構造を可視化する

に公開
architecture
teamtopologies
wardleymapping
idea

「顧客の地図から、チームの地図へ。」

Susanne Kaiser の『Architecture for Flow』第7章を読み、 Wardleyマップを内部組織の視点で描く方法と、プラットフォームチーム・イネーブリングチーム・ストリームアラインドチームがフローを支える構造に ついて整理しました。

🎯 本章の焦点 ― 「チームをユーザーとしてマップする」

これまでの章では、Wardleyマッピングは主に 外部顧客 のニーズをもとに描かれていました。
第7章では視点を反転し、組織内部（チーム）を“ユーザー”として描くことがテーマになります。

つまり：
チームがどのように価値を流し、どのような支援を必要としているか」を マップ上で可視化し、最適化する ことが目的です。

🧩 1. プラットフォームチームの視点から見るWardleyマップ

● 内部ユーザーとしてのストリームアラインドチーム

  • 従来の顧客＝外部ユーザーではなく、ここでは ストリームアラインドチーム がユーザー。
  • 彼らはプラットフォームチームが提供するサービス群の“利用者”になります。

● チームのユーザーニーズ

ストリームアラインドチームの「プラットフォームへのニーズ」は以下のような活動に現れます：

  • サービスの構築・テスト・リリース・デプロイ
  • 運用・監視・セキュリティ対応
  • インフラ管理や設定変更の自動化

● バリューチェーンの可視化

プラットフォームチームはこれらのニーズを満たすために、 ビルド／リリース基盤・インフラストラクチャプラットフォーム・デザインシステムなど、複数の内部プラットフォームを提供します。

それらを Wardleyマップ上に配置することで 、どの要素がカスタム開発（左側）で、どの部分が標準化（右側）できるかを可視化できます。

● X-as-a-Service と自己サービス（Self-Service）

プラットフォームチームが提供するサービスは、X-as-a-Service として提供されます。
例：CI/CDパイプライン、APIゲートウェイ、セキュリティ標準、テンプレート、ドキュメントなど。

これによりストリームアラインドチームは：

  • チーム間のハンドオフなしで 必要なリソースを利用でき、
  • 認知的負荷（Cognitive Load） を過度に増やすことなく開発・運用を進められます。

⚙️ 2. マイクロサービスの複雑性をマッピングする

● マイクロサービスの現実的な負荷

マイクロサービスアーキテクチャを採用すると、データ所有権、セキュリティ、サービスディスカバリ、オブザーバビリティなど、 多数の運用上の複雑性 が発生します。

● Wardleyマップで見た複雑性

これらの活動をマッピングすると、多くが「カスタムビルド（Custom-Built）」領域に集中しており、セルフホスト型運用ではチームの認知的負荷が高くなりやすいことが分かります。

● クラウドとプラットフォームの役割

クラウドマネージドサービスを活用することで、

  • バックアップ・スケーリング・監視などの責務を クラウドプロバイダーに移譲 でき、
  • プラットフォームチームは、セキュリティ／コスト管理／DX向上など、 組織固有の最適化 に集中できます。

🧠 3. イネーブリングチームの視点 ― 組織学習を加速させる

● イネーブリングチームの役割

イネーブリングチームはプラットフォームを“提供”するのではなく、 能力を育てる チームです。
彼らはコンポーネントを所有せず、 内部コーチ／ファシリテーター として機能します。

● 目的と関わり方

  • チーム間の スキルやプラクティスのギャップ を特定する。
  • そのギャップを埋めるための学習・実践を支援し、 自律性を高める 。
  • 支援は 一時的・オンデマンド で行い、継続的な依存関係を生まないようにする。

この活動は、Team Topologiesで定義される 「ファシリテーション（Facilitating）」モード に相当します。

🧭 4. 3チームの関係をマップで俯瞰する

Wardleyマップでこれらを重ねると、内部構造の「流れ」が見えてきます：


[ストリームアラインドチーム] → ユーザー（内部顧客）  
↓ 依存  
[プラットフォームチーム] → X-as-a-Service（自己サービス基盤）  
↓ 支援  
[イネーブリングチーム] → スキル強化・自律支援

この構造により：

  • プラットフォームチームは「提供者（Provider）」としてフローを加速し、
  • イネーブリングチームは「支援者（Facilitator）」として学習と適応を支える。
  • ストリームアラインドチームは「価値の生産者（Producer）」として変化を実装する。

3者の関係が明確になり、 「チーム間の依存」ではなく「チーム間の協働」が生まれる構造 へ進化します。

🌱 学びのまとめ

「チームもマップに描ける。」

  • Wardleyマップを内部チームに適用することで、組織内の価値連鎖と支援構造を可視化できる。
  • プラットフォームチームは認知的負荷を軽減し、自己サービスを促進する。
  • イネーブリングチームはスキルギャップを埋め、チームの自律性を高める。
  • この構造が、組織全体での フローの最適化（Flow Optimization） を支える。

🧩 次回予告 ― Architecture for Flow Canvas を描く

次章（最終章）では、これまでの学び（Wardley Mapping × DDD × Team Topologies）を統合し、 Architecture for Flow Canvas として、 戦略・設計・チーム構造・フローを一体的に可視化します。

📘 関連リソース

🪶 “Visualize teams like systems — map their flow to evolve your organization.”
— Susanne Kaiser, Architecture for Flow

Discussion