🙌

『Architecture for Flow』第6章を読む：WM × DDD × TTをつなぎ、変化の流れをデザインする

に公開
DDD
architecture
teamtopologies
wardleymapping
idea

「アーキテクチャは、チームと戦略と技術の“つながり方”で決まる。」

Susanne Kaiser の『Architecture for Flow』第6章 Connecting the Dots を読み、 Wardley Mapping（WM）、Domain-Driven Design（DDD）、Team Topologies（TT）の3つをどのように統合して“変化の流れ（Flow）”を最適化するかを整理しました。

🧭 本章の目的 ― “点をつなぐ”とは何か

ここまでの章で扱った3つのフレームワークは、それぞれ異なる視点を提供していました：

フレームワーク 視点 主な目的
Wardley Mapping (WM) 市場・戦略・進化 「何に取り組むか」を明確にする
Domain-Driven Design (DDD) ビジネス構造・モデリング 「どのように設計するか」を整理する
Team Topologies (TT) 組織構造・チームの流れ 「誰が実装・運用するか」を整える

第6章はこれらを 一本の流れとして結びつける章 です。
つまり、「戦略 → 設計 → チーム」が一貫した フロー指向の社会技術システム（socio-technical systems） を形成します。

🌊 ステップ1：変化の流れ（Flow of Change）を可視化する

1. 変化のストリームを特定する

  • 組織における“変化の流れ”＝価値提供と変更が実際に流れるルート。
  • Wardley Map で特定した ユーザーニーズ は、顧客主導のストリーム（activity-based / task-based）の出発点になります。
  • 「どこで顧客価値が生まれ、どこでボトルネックが発生しているか」を地図で把握。

2. フローを評価する

  • バリューチェーン の依存関係をたどり、 「変更がどのチーム・システムを経由して伝播するか」を明らかにする。
  • フローを妨げる要素（手戻り、待機時間、承認プロセスなど）を洗い出す。

3. 依存関係と制約の管理

  • システムは要素の集合ではなく相互作用の産物。
  • コンテキストマップ（DDD） で、境界間の関係や変更結合（Change Coupling）を可視化。
  • 制約理論（Theory of Constraints） を使い、 ボトルネックを継続的に特定・除去することで全体最適化を図る。

🧠 ステップ2：チーム構造と認知負荷を最適化する

1. チーム所有境界の特定

  • DDDの 境界づけられたコンテキスト（Bounded Context） は、 ストリームアラインドチーム（Stream-aligned Team） の自然な所有境界になりやすい。
  • 原則：「1つの境界コンテキストは1つのチームが所有する。」

2. 小規模チームでのフロー

  • TTでは 5〜9人規模の小チーム を推奨（ダンバー数の観点から）。
  • 小さなチームは信頼関係を築きやすく、調整コストが低いため、 変更フローのスループットが向上 します。

3. チームの認知的負荷（Cognitive Load）

  • チームが同時に扱える情報・複雑さの限界。 超過すると品質とスピードが低下します。
  • 負荷を最適化するには：
    • チームの責任範囲を明確にする
    • 管理するシステムの数・サイズ・複雑さを制限する
  • Wardley Map上の 進化ステージ で見ると、
    左（Genesis, Custom-Built）は不確実性が高く、
    右（Product, Commodity）は安定して低負荷です。
ステージ 不確実性 認知負荷 適したチームの姿勢
Genesis / Custom-Built 高 高 探索的（Explorer）
Product 中 中 拡張的（Villager）
Commodity 低 低 運用的（Town Planner）

この考え方は Wardley Doctrine の「適性と態度を考える（Think Aptitude and Attitude）」
および Kent Beck の 3Xモデル（Explore–Expand–Extract） と整合します。

🧩 ステップ3：プラットフォームとチーム体制を導出する

1. フローを支えるサービスを特定

  • ストリームアラインドチームが自律的に動くためには、 プラットフォームチーム が自己サービス（X-as-a-Service）を提供することが不可欠。
  • プラットフォームは「Thinnest Viable Platform (TVP)」として最小限から始め、 利用率と開発者体験（DX）をKPIとして成長させる。

2. チーム体制を設計する

  • 分析結果（コンテキスト境界・認知負荷・プラットフォームの必要性）から、組織を以下のチームで構成する：
    • ストリームアラインドチーム
    • プラットフォームチーム
    • イネーブリングチーム（能力強化を支援）
    • （必要に応じて）複雑なサブシステムチーム

3. 能力ギャップを埋める

  • チームが不足しているスキルやプラクティスを特定。 それを一時的に支援し、自律性を回復させるのが イネーブリングチーム の役割です。

🔗 統合された“Flow Architecture”の全体像

フレームワーク 主な質問 役割
Wardley Mapping 「私たちはどこにいるか？」 環境と進化を可視化
Domain-Driven Design 「何をどう構造化するか？」 境界とモデルを定義
Team Topologies 「誰がどう動くか？」 チームとフローを設計

🌱 学びのまとめ

「戦略・設計・チームは、同じ地図上で考えるべきである。」

  • Wardley Map が環境と価値の流れを示し、
  • DDD が構造と責任境界を定義し、
  • Team Topologies がチームの形と相互作用を設計する。
  • 3つを統合することで、組織は 変化を“自然に流す”システム を構築できる。

🧩 次回予告 ― Flow Architectureを実践に落とす

次回は、これまでに統合した Wardley Mapping × DDD × Team Topologies の知見を、 実際のチーム運営・組織設計に適用していきます。

📘 関連リソース

🪶 “When strategy, design, and teams flow together, adaptability emerges.”
— Susanne Kaiser, Architecture for Flow

Discussion