🌊

『Architecture for Flow』第1章を読む：Wardley Mappingで戦略と設計をつなぐ

に公開
DDD
architecture
teamtopologies
wardleymapping
idea

戦略とは、計画ではなく学習のプロセスである。
Susanne Kaiser の 『Architecture for Flow』第1章を読んで学んだ、
「正しいものを作る」ための地図づくりについてまとめました。

🎯 なぜWardley Mappingが重要なのか

『Architecture for Flow』 の第1章では、
ソフトウェアアーキテクチャを戦略的に捉えるためのフレームワークとして
Wardley Mapping（ウォードリーマッピング） が紹介されています。

著者 Susanne Kaiser は、次の2つの問いを区別することから議論を始めます。

  • 正しいものを作っているか？（Building the right thing）
  • ものを正しく作っているか？（Building the thing right）

多くのチームは「どう作るか（How）」ばかりに意識を向けがちです。
しかし本当に必要なのは、「なぜそれを作るのか（Why）」と
「いま自分たちはどんな状況にいるのか（Where）」を理解すること。

Wardley Mapping は、その「Where」を見える化し、
チーム全体での状況認識（Situational Awareness） を高めるためのツールです。

🗺️ Wardley Mapとは何か

Wardley Map は、組織やシステムの構成要素を
「価値の流れ」と「進化段階」で整理するための地図です。

マップを描くことで、
どの部分が差別化要因で、どの部分は標準化してよいか を明確にできます。

軸 意味 内容
Y軸：バリューチェーン（Value Chain） 「誰のために」「何を」提供するか 最上部にユーザーを置き、そのニーズを支える構成要素を依存関係で並べる。
X軸：進化（Evolution） 各構成要素の成熟度 「創生期（Genesis）」→「カスタムビルド」→「製品」→「コモディティ」と進化。

たとえば、クラウド基盤はすでに「コモディティ」ですが、
自社の業務に特化したアルゴリズムは「カスタムビルド」の領域にあります。
この区別が、どこにリソースを集中すべきかの判断材料になります。

🔍 Wardley Mappingで得られる3つの洞察

  1. 非効率な投資の発見
    すでにコモディティ化された領域を再実装していないかを確認できる。
    → “やらないこと”を決めるのに役立つ。

  2. 変化の予測
    市場や技術の進化パターンを踏まえて、
    どの要素が次に自動化・標準化されるかを見極める。

  3. 戦略的行動の決定
    どこに投資し、どこを外部化・抽象化すべきかを判断する。
    これは経営判断であると同時に、設計上の選択でもある。

🔁 戦略サイクル ― 変化に適応する5つの要素

Wardley Mapping の根底には、変化に対応し続けるための「戦略サイクル」があります。
これは技術アーキテクチャ設計にも直接応用できる考え方です。

1. Purpose（目的）

システムやプロダクトの「なぜ」を定義します。
例：「ユーザーが最適なカンファレンスを見つけられるよう支援する」。

2. Landscape（ランドスケープ）

競争環境や技術スタック、依存関係をマップとして可視化します。
チーム全体で “現在地” を共有し、判断の前提を揃えます。

3. Climate（外的要因）

制御不能な外部環境――技術の進化、標準化、法規制、ユーザー行動の変化など。
これらの“変化の力”を理解することで、次に何が成熟・陳腐化するかを見極められます。

💬 注:
本書で使われる “Climate” は「気候」の直訳ではなく、
自分ではコントロールできない外的な要因（Forces of Change） を指すものとして理解しました。
つまり、アーキテクチャ設計や技術選定に影響を与える“環境変化のドライバー”という意味で「外的要因」としています。

4. Doctrine（ドクトリン）

どんな状況でも有効な設計原則。
例：「ユーザー価値を基準に設計する」「小さく試して早く学ぶ」。

5. Leadership（リーダーシップ）

得られた洞察をもとに、どの技術を採用し、どの領域を抽象化・自動化するかを判断します。
これはまさに アーキテクチャの意思決定 です。

この5つの要素は静的なチェックリストではなく、
継続的に回す思考ループとして捉えるのがポイントです。

💬 チームで描く「共通言語としての地図」

Wardley Map の真価は、図そのものよりも チームで描くプロセス にあります。
マップを通じて、ビジネス側と技術側が同じ言葉で議論できるようになります。

たとえば、
「どこを内製すべきか」「どこを外部サービスに委ねるか」
といった議論を、抽象的な意見ではなくマップ上の位置関係として共有できます。

🗣️ 地図を描くことは、チームの会話をデザインすること。

🌱 学びのまとめ

第1章からの最大の学びは、
「戦略とは、計画ではなく学習のプロセスである」
という一文に凝縮されています。

マップを描くことは、未来を予測する行為ではなく、
**変化に気づき、適応するための“学習の仕組み”**を作ること。

これは、アーキテクチャ設計そのものと地続きの行為だと感じました。

🧩 次回予告 ― DDDとの接続点へ

次章では、Wardley Mappingで得た洞察を
Domain-Driven Design（DDD） の「境界づけられたコンテキスト（Bounded Context）」へとつなげていきます。

💡 戦略マップを、実際の設計に落とし込む方法へ。

🏷️ サマリー

  • Wardley Mappingは「正しいものを作る」ための状況認識ツール
  • 戦略サイクルは、アーキテクチャを継続的に学習させるための思考モデル
  • “Climate（外的要因）”を理解することで、技術選定や抽象化の判断を先取りできる

📘 関連リソース

🪶 “Strategy is not a plan; it’s a process of continuous learning.”
— Susanne Kaiser, Architecture for Flow

Discussion