『Architecture for Flow』第8章を読む：Architecture for Flow Canvasで全体を統合する
「アーキテクチャは設計書ではなく、対話のためのキャンバスである。」
Susanne Kaiser の『Architecture for Flow』第8章を読み、 Wardley Mapping × DDD × Team Topologies を統合するための実践ツール「Architecture for Flow Canvas」を整理しました。
🎯 本章の目的 ― 統合と可視化のためのキャンバス
第8章「The Architecture for Flow Canvas」では、これまでの章で扱ってきた3つのフレームワークを 1つのキャンバス上で結びつける方法 が解説されています。
| 観点 | 対応するフレームワーク | 目的 |
|---|---|---|
| 環境と戦略 | Wardley Mapping | ビジネスランドスケープと価値連鎖を把握する |
| 構造とモデル | Domain-Driven Design | サブドメインと境界コンテキストを定義する |
| チームとフロー | Team Topologies | チーム構造と相互作用の設計を導く |
このキャンバスは、現状（As-Is）の評価 と 将来（To-Be）の設計 の両方を支援し、組織が「どこで、どのように、誰が価値を流しているか」を視覚的に議論・検討するための ナビゲーションツール です。
🧭 1. 現状（As-Is）の評価 ― 現在地を把握する
まず、現在の組織とシステムがどのように動いているかを明らかにします。
● チーム構造と働き方を記述する
- 各チームの規模・責任範囲（所有境界）・依存関係を明確にする。
- 相互作用モード（コラボレーション／XaaS／ファシリテーション）を整理する。
- チームが採用している作業方法（Scrum、Kanbanなど）を可視化する。
● 変化のフローを評価する
- チームへのインタビューや観察を通じ、阻害要因（ブロッカー） と 促進要因（イネーブラー） を特定する。
- フローを止めている要素（待ち時間、承認プロセス、ツール制約など）を洗い出す。
● ビジネスランドスケープを描く
- Wardleyマップを使って、ユーザー（外部顧客または内部チーム） とその ニーズ を特定。
- それを支える コンポーネント（価値連鎖） と依存関係を整理。
- 各要素を「創生 → カスタムビルド → 製品 → コモディティ」の進化ステージにマッピングする。
引用元: https://architectureforflow.com/canvas/
🧩 2. 問題空間の分類 ― どこに集中すべきかを見極める
次に、見つけた課題や機会を サブドメイン に分類します。
● サブドメインの3分類
| 種類 | 意味 | 投資判断 |
|---|---|---|
| コアドメイン | 競争優位を生む領域 | 集中的に内製（Build）すべき |
| 支援サブドメイン | コアを支えるが差別化要因ではない領域 | 部分的に内製または再利用 |
| 汎用サブドメイン | 共通機能（認証、請求、監視など） | 外部サービスやツールを活用（Buy／Outsource） |
この分類によって、 戦略的な投資配分 が明確になります。
「どこを自社の強みに磨き、どこを効率化するか」という意思決定が、データに基づいて行えるようになります。
🚀 3. 将来（To-Be）の設計 ― フローを最適化する構造を描く
As-Isの理解をもとに、変化が自然に流れる構造（Flow Architecture） を設計します。
● ドメインのモジュール化と境界の定義
- DDDの 境界づけられたコンテキスト（Bounded Context） を用い、システムを小さな高凝集モジュールへと分割します。
- EventStorming などの共同モデリング手法で、自然な境界を特定します。
- これらの境界は、将来の チーム所有範囲 としても機能します。
● 将来のビジネスランドスケープを可視化する
- サブドメインとコンテキストをWardleyマップ上に重ね、進化ステージと価値連鎖を同時に可視化。
- コアドメインに集中投資し、汎用領域は外部化・標準化することで 効率性のギャップ を解消します。
引用元: https://architectureforflow.com/canvas/
● チーム構造を導出する
Team Topologiesの原則を適用し、ストリームアラインドチーム を顧客価値のストリームに沿って配置します。
認知的負荷を軽減するために：
- プラットフォームチーム が自己サービス（X-as-a-Service）を整備。
- イネーブリングチーム がスキル支援とプラクティス向上を担当。
- チーム間の 相互作用モード（コラボレーション／XaaS／ファシリテーション） を定義し、どのモードがどのフローを支えるかを明確化します。
引用元: https://architectureforflow.com/canvas/
🌱 Architecture for Flow Canvas の意義
Architecture for Flow Canvas は、単なるテンプレートではありません。
それは、チームが学びながら進化できる“生きた設計キャンバス” です。
| 特徴 | 内容 |
|---|---|
| 共同設計ツール | チームが対話しながら現状と将来像を一緒に描く。 |
| 統合ビュー | 戦略・設計・チーム・フローを1枚の図で整合させる。 |
| 進化的設計 | 学習のたびに更新し、変化に適応する。 |
🧩 シリーズの集約 ― “Flow”を描くということ
第1〜7章 で学んだ3つの視点（WM × DDD × TT）は、 第8章 でキャンバスとしてひとつに統合されます。
| フレームワーク | 主な問い | キャンバス上の役割 |
|---|---|---|
| Wardley Mapping | 「私たちはどこにいるのか？」 | 環境・進化・価値連鎖を描く |
| Domain-Driven Design | 「何をどう構造化するか？」 | 境界とサブドメインを定義 |
| Team Topologies | 「誰がどのように動くか？」 | チーム構造と相互作用を設計 |
この統合により、
戦略（Where）・設計（What）・チーム（Who） が同じフレーム上で整合します。
それこそが「Flow Architecture（フロー・アーキテクチャ）」の本質です。
🪶 まとめ
「Flowは設計書ではなく、対話を通して生まれる流れである。」
- Architecture for Flow Canvas は、組織を“地図で考える”ための道具。
- チームが共に描き、更新し、進化させること自体が、変化への適応力を高める。
- このキャンバスを通じて、組織は戦略・設計・チームを一体化した持続的な流れを実現できる。
📘 関連リソース
- Architecture for Flow Canvas Miro Template
- Wardley Mapping Community（公式）
- Domain-Driven Design Community
- Team Topologies 公式サイト
- Susanne Kaiser 『Architecture for Flow』 (Addison-Wesley, 2025)
🪶 “The canvas is not the map of the past, but the dialogue of the present and the direction of the future.”
— Susanne Kaiser, Architecture for Flow
Discussion