翻訳者がいるから、共通言語は整備されない。
読み終えてから、この順序の逆転が頭から離れませんでした。そして、その「翻訳者」とは、戦略会議とコードレビューのあいだを10年走り回ってきた、ほかでもない私自身のことでした。胃のあたりは、いまも少し重い。
Susanne Kaiser 著『Architecture for Flow: Adaptive Systems with Domain-Driven Design, Wardley Mapping, and Team Topologies』（Addison-Wesley Professional, 2025）の読書感想文です。
この本を手に取ったきっかけは、Nick Tune 著『アーキテクチャモダナイゼーション 組織とビジネスの未来を設計する』の翻訳作業でした。同じ知的領域——ドメイン駆動設計、ウォードリーマッピング、Team Topologies という3本の柱——を扱う類書として、どうしても押さえておきたかったのです。
ウォードリーマッピング・ドメイン駆動設計・Team Topologies という独立した3つの道具箱を、「変化への高速フローに最適化された適応的な社会技術的システムを作る」という一本の動詞で編み直した本でした。戦略とコードと組織のあいだで板挟みになってきた人に、強く薦めたい一冊です。
はじめに
会議室とコードベースが別の言語だった日
ある日の夕方、大きめの戦略会議を終えて席に戻り、そのままプルリクエストのレビューを続けていた。会議室で交わされた言葉は「次の3年でこの市場のコアケイパビリティに投資する」「差別化は顧客体験だ」「スケールするプラットフォームを作りたい」。どれも抽象度の高い、未来の話。いっぽう目の前のコードは、名前の揺れたクラス、3つのサービスにまたがるトランザクション、フロントエンドチームのためだけに生えたエンドポイント。同じプロダクトを指しているはずなのに、使っている語彙がまるで違っていた。
戦略側の人は「なぜこんなに動きが遅いのか」と言った。設計側の人は「なぜ優先順位がころころ変わるのか」と言った。会議室とコードベースは、地続きのはずなのに断絶している。私はその断絶のあいだに立って、両側の言葉を訳す役を長いあいだ買って出てきた。たぶん、そこそこ上手くやっていた。
それでも、疲れていた。
疲れていたが、疲れていると言葉にするのは難しかった。「翻訳する役が疲れる」というのは、誰かを責めているように聞こえてしまう。誰が悪いわけでもない。ただ、会議室とコードベースのあいだに、誰かが立たなければならなかった。立てる人間が少なかった。だから立った。立てば立つほど疲れた。疲れたまま、それでも立ち続けた。
『Architecture for Flow』は、まさにその断絶を扱う本だった。サブタイトルにある3つのキーワード——Domain-Driven Design、Wardley Mapping、Team Topologies——のどれか1つに深い覚えがある読者は多いと思う。でも本書の価値は、それらを「独立した道具箱」としてではなく、「同じワークフローの中で順番に登場する装置」として結び直したところにある。いや、もっと正確に言えば、本書の価値は、3つを並べることそのものよりも、3つを並べる場のほうに問題があるのではないかと私に疑わせたことにあった。たぶん、この疑いのほうが、本書の一番の贈り物だった。
読む前に抱えていた3つの悩み
本書を読み始めるとき、私が抱えていた悩みは3つありました。どれも、長く胸に刺さっていた棘のようなものです。この3つが読後にどう変わったかは、最後のリフレクションで回収します。
戦略の言葉と設計の言葉が噛み合わない。経営や事業側の議論と、コードレベルの設計議論が、同じプロダクトについての話なのに別の言語で進んでいきます。あいだに立って翻訳する役を買って出ても、両側から「細部が違う」「大局が見えていない」と言われる板挟みが続いていました。
チーム構造の議論がコードの形に落ちない。コンウェイの法則は知っていますし、組織を変えればアーキテクチャが変わるという理屈も頭に入っています。それでも「では、この機能別サイロをどう再編して、どのチームがどのサービスを持つべきなのか」という具体の一歩が踏み出せません。組織図だけを書き換えても、ハンドオフの数は減りません。
レガシーシステムへの処方箋がいつも抽象的すぎる。「段階的に分割しましょう」「境界を設計しましょう」というアドバイスは正しいのですが、では目の前にある大きな泥だんご（Big Ball of Mud）のどこに最初のノミを入れればいいのか。この意思決定を支える共通言語が、自分にも組織にもありませんでした。
3つの悩みは独立して見えて、実は同じ根を持っています。「戦略・設計・組織を同じテーブルに載せる道具がない」。本書が差し出すのは、まさにその道具でした。ただ、読み終えて本当にこたえたのは、道具の話ではありません。共通言語の不在という状況を、自分自身が支えてしまっていたのではないかという疑いのほうでした。以下、全12章を順番に見ていきます。
Chapter 1: Business Strategy with Wardley Mapping
第1章はウォードリーマッピングの戦略サイクルから始まります。このサイクルは Purpose（目的）→ Landscape（ランドスケープ）→ Climate（気候）→ Doctrine（ドクトリン）→ Leadership（リーダーシップ）という5つのステップで構成され、孫子の「五事」に着想を得ていると紹介されます。それぞれのステップをやさしく言い換えると、こうなります。最初に「なぜ自分たちはこの仕事をしているのか」を決める（目的）。次に、自分たちが置かれている競争環境を地図の形で見えるようにする（ランドスケープ）。そのうえで、自分たちでは変えられない外部の変化——技術の進化、規制、市場の成熟——を読む（気候）。続いて、どんな組織にも通用する普遍的な原則を当てはめる（ドクトリン）。最後に、自分たちの文脈に合わせた具体的な打ち手を選ぶ（リーダーシップ）。この順番で考えること、これが本書の基礎文法になります。
中心概念として押さえておきたいのは次のあたりです。
- バリューチェーンはユーザーとそのニーズをアンカーに、価値を届けるコンポーネントを上から下へ並べたもの。y 軸は「ユーザーからの可視性」で、上ほど見えやすく価値が大きい。
- 進化段階は x 軸で、すべての要素は「創世記 → カスタムビルド → 製品（＋レンタル）→ コモディティ（＋ユーティリティ）」の4段階を左から右へ進む。
- ドクトリンは「小さく考える」「ユーザーニーズから出発する」「状況認識を優先する」など、どんなランドスケープでも通用する普遍原則の集合。
- ゲームプレイは逆に、文脈依存の競争行動。自社で生み出した機能を段階的にコモディティ化していくILC（Innovate-Leverage-Commoditize）、オープンアプローチ、ファストフォロワー、差別化など。
私にとって効いたのは「戦略サイクルは変化への平均対応時間（MTTR）を反映している」という一節でした。MTTR はもともと「インシデントが起きてから復旧するまでの平均時間」を表す運用指標です。本書はこの言葉を戦略に持ち込みます。つまり、戦略とは大きな青写真を一度だけ描くものではない。市場の変化に気づいてから、次の一手を打つまでの短いループのことだ、という定義です。サイクルを短く回せる組織ほど変化に強い、と言い換えてもよいでしょう。この観点を手に入れたとき、私が過去に「戦略会議」と呼んでいたものの多くは、戦略ではなく単なる予算配分の儀式だったと気づかされました。戦略サイクルの5ステップのうち、ランドスケープ（地図の共有）、気候（外部変化の読み取り）、ドクトリン（普遍原則の適用）をすべて飛ばして、目的から直接リーダーシップに飛ぶ、という飛び方です。「自分たちがどんな環境にいるか」を地図で共有しないまま、「次に何をするか」だけを決めてしまう。これでは結局、勘と精神論による意思決定にしかなりません。本書がこの章で繰り返し釘を刺すのはそこです。
かつて私がいた組織では、戦略のスライドは毎期新しくなるのに、コードベースの依存関係はまったく動きませんでした。今思えば、戦略とランドスケープがマップの形で共有されていなかったので、誰も「ドクトリンに反している」と指摘できなかったのです。マップは精度ではなく、対話のためにある。この章のいちばんの持ち帰りです。
もう1つ、この章から持ち帰りたい言葉が 慣性（イナーシャ, Inertia） です。過去の成功が、組織の中に目に見えない抵抗を生みます。「これまで上手くいってきたやり方」があるほど、新しい変化に対して身体が動かなくなる。本書は「過去の成功が慣性を育て、慣性は組織を殺しうる」と淡々と書きます。ここで怖いのは、慣性が悪意ではなく、正しさの記憶から生まれることです。過去に正しく振る舞った結果として、今の硬直が生まれている——こう言われると、過去を否定できない自分がいて、しかし今の硬直も否定できない自分もいる。どちらも切り捨てられないから動けない、という状態に名前がついた気がしました。
もう1つ、戦略サイクルを回す側に必要な感覚が 効率性ギャップ です。市場全体ではコモディティとして入手できるコンポーネントを、自社ではまだカスタムビルドで運用している——この「市場の進化段階」と「自組織の進化段階」のあいだのずれが、効率性ギャップです。ギャップを測れば、どこに投資し、どこから撤退すべきかの判断材料が手に入ります。慣性は、この効率性ギャップが開いていく速度を、組織に見えなくさせる装置です。
効率性ギャップも慣性も、最初に紹介した戦略サイクルの上で初めて見えるようになる概念です。いったんそのサイクルの全体像に戻って、図で確認しておきます。
戦略サイクルは、Purpose（目的）、Landscape（ランドスケープ）、Climate（気候）、Doctrine（ドクトリン）、Leadership（リーダーシップ）という5つの要素を、孫子の「五事」に着想を得た円環として配置している。この一枚の図に込められているのは、戦略は一度描いて終わる青写真ではなく、環境が動くたびに何度もなぞり直すべきサイクルだ、というメッセージだ。ランドスケープや気候の変化を観測するたびに、戦術だけではなく目的とリーダーシップまで遡って見直す。そういう種類の「戻りながら進む」動きを、この円環は前提にしている。
そして、サイクルを回そうとするときに必ず邪魔をしてくるのが、先ほど触れた慣性です。本書はそれを、この章でもう一枚の図として念を押してきます。
過去の成功が抱えるパラドックスを描いた図だ。ある戦略で勝ったチームは、その勝利の記憶を変化への障壁として持ち歩くことになる。障壁は悪意や無能から生まれるわけではない。かつて機能していたものの残り香だ。手を突き出して向かってくる球を押し返している棒人間は、変化を拒んでいるのではない。自分が既に知っているものを守っているだけだ。慣性と議論するのが難しいのは、それを生み出している人たちが、自分のなかでは責任を果たしているつもりだからでもある。
このように、第1章は「戦略を回すサイクル」と「サイクルを止めようとする慣性」を一枚ずつ図で押さえてくれました。次章は、このサイクルの中身——具体的に何を分類し、何にお金と時間を投じるのか——という問いに進みます。
Chapter 2: Exploring the Problem Space with Strategic DDD and Wardley Mapping
第1章でウォードリーマッピングの地図の描き方を学んだあと、第2章はその地図の上にドメイン駆動設計（DDD）の問題空間を重ねていきます。DDD は業務に詳しい人（ドメインエキスパート）と開発チームが協働してドメイン知識を獲得し、業務と実装の両方で同じ語彙を使う「ユビキタス言語」で会話することから始まります。ここで重要なのは、いきなり解決策の設計に飛び込まないという姿勢です。
本章の主役はサブドメインの分類です。問題ドメインを蒸留するとは、広くて抽象的なビジネスドメインを、コア・支援・汎用という3つのタイプのサブドメインに分けていく作業を指します。
- コアドメインはビジネスクリティカルで、競合他社との差別化を担う領域。複雑で、模倣されにくく、変更頻度が高い。創世記やカスタムビルドに位置することが多く、内製すべき候補。
- 支援サブドメインはコアを支えるが差別化要因ではない領域。ややシンプルで変更頻度も低い。既製品やオープンソースが合えば買い、どうしてもカスタムビルドが必要な場合でも投資レベルは抑える。
- 汎用サブドメインは認証や決済のように、どんな業界でも共通する領域。コモディティやユーティリティの段階にあり、基本的には購入・利用・アウトソースが合理的。
サブドメインの分類は「どこに人と時間を投入するか」の判断材料になります。第1章で描いたウォードリーマップに、このサブドメイン分類を重ねると、コアドメインは左寄り、汎用サブドメインは右寄り、支援サブドメインはその中間——という分布が自然に見えてきます。戦略と設計が同じ地図上で初めて会話を始める瞬間です。
印象的だったのは、「今日のコアドメインが永遠にコアであり続ける保証はない」という釘の刺し方でした。コアは固定されたものではなく、時間とともに進化段階を右へ——つまりカスタムビルドから製品へ、製品からコモディティへ——移動していきます。新しい技術や市場が成熟するにつれ、かつては自社の差別化要因だった機能が、いつの間にか「どの会社でも使えるもの」になっていく。本書の言葉を借りれば、差別化の価値は下がり、コストの勝負に変わっていくのです。最初は「他社には真似できない独自機能」だったものが、やがて「他社と同じ機能を、誰がより安く運用できるか」の勝負になる、ということです。永久にコアだと思い込んでカスタムビルドを続けていると、気づいたときには「世の中に既製品として出回っているもの」を、自社で高額に内製し続ける事態が起きます。
かつて「うちのコア」と呼ばれていた領域の半分は、3年後に AWS のマネージドサービスを叩く数十行のコードに置き換わりました。置き換わった日、その領域の専任だったエンジニアは何も言いませんでした。私もまた、かける言葉を持ちませんでした。足りなかったのは技術ではなく、コアを疑う定期的な儀式でした。もっと正直に言えば、儀式があっても、私たちはあの日まで疑わなかったかもしれません。コアは、疑うのが怖いものです。自分たちの存在価値の根拠を、半年に一度の会議室で解体するのは、思っているより勇気がいります。第2章は、その儀式をどう持つかを示します。
コア・支援・汎用という3つのサブドメインタイプを、Wardley の進化軸の上に重ねて見せてくれる図だ。コアドメインは創世記やカスタムビルドに寄る。なぜなら、そこが差別化の源泉であり、組織がまだ問題の形そのものを探している場所だからだ。汎用サブドメインは逆に右——コモディティやユーティリティの側——へ流れていく。自前で作るよりも借りてくるほうが、ほとんどの時は安くつくからだ。支援サブドメインは、だいたいその中間に落ちる。この図はルールではなく鏡で、「うちのコア」がすでに右にずり落ちているなら、それは来期の投資判断にとって非常に大事な情報になる。
「右にずり落ちる」という表現を使いましたが、なぜ左から右への移動が起きるのか。第1章の図をもう一枚だけ借りて、その背景を確認しておきます。
Wardley マップのうえで、コンポーネントが同じ位置にとどまり続けることはない。需要側の競争が市場に「もっと欲しい」という圧をかけ、供給側の競争が「もっと安く、もっと確実に」という圧をかける。両方の力がコンポーネントを進化段階のうえで右へ右へと押し出し、Past から Current、そして Future へと移動させていく。今日「安定したコア」に見えるものも、自分の組織の内側からは見えない競争によってすでに侵食されている。Wardley マップを静止画として眺めることが失敗する理由は、まさにここにある。サブドメイン分類もまた、この進化の潮流の上に浮かんでいるのだ、と引き受けた上で次の章に進みます。
Chapter 3: Designing the Solution Space with Strategic DDD
第2章で問題ドメインを3種類のサブドメインに分類したあと、第3章はついに、問題空間から解決空間（ソリューション空間）へと踏み出します。境界づけられたコンテキストという DDD 最大の武器が、ここで登場します。
Eric Evans 氏の有名な言葉が引かれます——「理想的な状況では、サブドメインと境界づけられたコンテキストは一致する」。しかし現実には、レガシーシステムほどこの整合が崩れています。本書はこの理想と現実のずれを素直に認めたうえで、どうやって境界を引き直すかを段階的に示します。
境界づけられたコンテキストが担うのは、次の4つの境界です。
- 言語的・意味的な境界——同じ「セッション」という言葉が、募集中・スケジュール済み・評価済みで意味が変わるとき、境界の内側では一貫した1つの意味を持てるようにする。
- 所有権の境界——1つの境界づけられたコンテキストは1つのチームが所有する。ただし1チームが複数コンテキストを持つことはできる。
- 物理的な境界——独立したコードリポジトリ、独立したデプロイパス、独立したアーキテクチャスタイルを持てる。
- 実装の境界——ビジネスロジックの実装方針すらコンテキストごとに別々でよい。
この章でいちばん気持ちよかったのは、カンファレンスイベントプランナーの例で「Session」という1つの名前が曖昧だと気づき、「Submitted Session」「Scheduled Session」「Evaluated Session」へ分岐していくくだりです。境界を引くとは、名前の分岐点を発見することなのだ、と腑に落ちました。
名前が分岐した瞬間、それぞれの名前が持つ不変条件（ビジネスルール）も分岐します。「セッションは二重にスケジュールできない」というルールは Scheduled Session のコンテキストの内側にしか存在しない。Submitted Session のコンテキストは、このルールを知る必要がない。これが「明確な境界が会話を軽くする」という感覚の正体でした。
私が過去に見てきた「名前衝突」の多くは、単にクラス名の問題ではなく、コンテキストが分離されていなかった問題でした。境界は防御線ではなく、会話の輪郭です。境界があるから、チームは内側で短い言葉で話せる。第3章はそれを繰り返し説きます。
もう1つ、この章を読んでから効きはじめたのがコンテキストマップです。境界を引くだけでは足りません。境界づけられたコンテキスト間の関係を、どういうパターンで結ぶかまで設計して、初めて境界は動き始めます。本章はこの関係を8つのパターンに整理します。
- 別々の道：独立して歩み、相互に統合しないパターン
- 公表された言語：共通の交換規約（スキーマ）を定めて会話するパターン
- 腐敗防止層（ACL）：外部モデルを変換で遮断し、内側の汚染を防ぐパターン
- 順応者：上流のモデルにそのまま従うパターン
- 公開ホストサービス（OHS）：複数の下流に公開 API を提供するパターン
- 顧客／供給者：下流チームが上流チームに影響力を持つパターン
- 共有カーネル：モデルの一部を共有成果物として持つパターン
- パートナーシップ：共通目標に向けて密に協調するパターン
本章の骨子は、この8パターンを「変更結合（change coupling）」という一本の軸で測り直すことにあります。変更結合とは、あるモジュールを変えたときに、別のモジュールをどれだけ変えざるを得ないかという指標です。結合が強いほど、1つの変更が広い範囲に波及してしまいます。
変更結合を「ある／ない」の二値ではなくグラデーションとして捉えるには、もう少し解像度の高い語彙が欲しくなります。Vlad Khononov 氏の『ソフトウェア設計の結合バランス 持続可能な成長を支えるモジュール化の原則』は、まさにその語彙を提供する本です。結合を次の4段階に整理しています。
- 侵入結合：互いの内部実装まで知ってしまっている状態。最も強い結合
- 機能結合：ビジネスルールを共有している状態
- モデル結合：相手のドメインモデルの概念を知っている状態
- コントラクト結合：公開されたインターフェースだけを知っている状態。最も弱い結合
そのうえで、結合によって発生するメンテナンスの手間を「強度 × 距離 × 変動性」の掛け算として数値化します。ここがこの本の面白いところです。変わらないモジュールへの強い結合は、意外と痛くありません。逆に、コアドメインのように頻繁に変わる部分への結合は、弱くても大きく効いてきます。この見方を手に入れて初めて、「どこの結合を優先して直すべきか」の判断に手触りが出てきます。先ごろ訳了した Nick Tune 氏の『アーキテクチャモダナイゼーション』第12章も、Khononov 氏のこの分類を引きながら疎結合の議論を組み立てていました。Kaiser 氏が第3章で提示した8つのコンテキストマップパターンを、この結合のグラデーションの上に置き直すと、「なぜ腐敗防止層が必要なのか」「なぜ順応者が危険なのか」の理由が変更結合の言葉で説明できるようになります。
正直に言えば、この4分類を知る前、私は「疎結合」という言葉を雑に使っていました。REST API で話しているから疎結合、メッセージキューで非同期にしているから疎結合。ところが、ある時「疎結合なマイクロサービス群」と名乗っていた3つのサービスを前に、上流のドメインイベントのフィールドを1つリネームしただけで、下流2サービスのデプロイ順序まで調整させられました。あれは契約の粒度の問題ではなく、ビジネスルールそのものを共有してしまっていた——Khononov の言葉を借りれば機能結合だった。通信スタイルが非同期でも、変更結合は強いままだったのです。
Kaiser 氏と Tune 氏の2人が共通してたどり着くのは、コアドメインと統合するときの処方箋です。上流は OHS で安定した公開 API を出し、下流では ACL（変換層）が外部モデルの汚染をせき止める。私は過去に、上流の内部モデルをそのまま JSON で吐き出す API を放置した結果、下流のサービスが勝手にコンフォーミストになり、コアの一フィールド名を変えるだけで3チームから悲鳴が上がる、というコンテキストマップを育てたことがあります。あのとき必要だったのは、新しいサービスではなく、変換層を一枚挟むことでした。名前の衝突は境界の問題だと思っていましたが、本当は変更結合の問題だったのです。境界は、名前の分岐点を見つけて終わりではありません。分岐させ続ける勇気の問題でもあります。たぶん。
結合の話をひとしきり追った後で、いったん境界の出発点——「同じ言葉を違う意味で使わないための線」——に戻っておきます。
境界づけられたコンテキストが、コードの周りに引かれた物理的な線ではなく、言語的な境界であることを見せてくれる図だ。境界の内側では「セッション」「注文」「顧客」といった用語がひとつの意味しか持たず、チームは短く曖昧さのない言葉で会話できる。境界の外側では、同じ言葉が別の意味を持っていて構わない。むしろ、そのずれが許されているからこそ、チーム同士が全てのニュアンスを共有しなくて済む。この図が思い出させてくれるのは、境界づけられたコンテキストの話題は図そのものではなく、図の内側で交わされる会話なのだ、ということだ。
そして本文で名前だけ列挙した8つのコンテキストマップパターンも、本書は1枚の図にきれいに並べて見せてくれます。
コンテキストマップの8パターンすべてを1本の軸の上に並べ、チーム間でどれだけのコミュニケーションを必要とするかの順で並べた図だ。いちばん左の「別々の道」はチーム間の調整をまったく必要としない——そもそも統合しないからだ。その右に「公表された言語」「腐敗防止層」「順応者」「公開ホストサービス」が並び、それぞれが「絡み合わずに統合する」ための異なる戦略を示している。さらに右の「顧客／供給者」「共有カーネル」「パートナーシップ」は、うまく動かすために段階的に多くの人的調整を必要としていく。右下に置かれた大きな泥だんごは、そもそも「選ぶ」パターンではない。何も選ばなかったときに、勝手にそうなっている状態のことだ。この図は「選択肢のメニュー」ではなく、「チーム間で境界をどう引き合うかの物差し」として読むと、他チームとの会話の仕方が変わってくる。
Chapter 4: Implementing the Domain Model with Tactical DDD
第3章で境界づけられたコンテキストとその間の関係を設計したあと、第4章は境界の内側でドメインモデルをどう実装するかに踏み込みます。DDD のいちばん有名な武器庫——戦術的設計です。ここで初めて、エンティティ、値オブジェクト、集約、ドメインサービス、ドメインイベントといった定番のビルディングブロックが出揃います。
- エンティティはライフサイクルと一意な識別子を持ち、時間とともに状態が変わる。
- 値オブジェクトは不変で、値全体が同一性を決める。値を変えたければ新しいインスタンスを作る。
- 集約は密接に関連するオブジェクトのグラフで、整合性境界とトランザクション境界を兼ねる。外からは集約ルートだけを触る。
- ドメインサービスは単一のエンティティや値オブジェクトに収まらないロジックを担う。
- ドメインイベントはドメインモデルで起きた出来事を表現し、複数の境界づけられたコンテキストが購読しうる。
これはどれも教科書的な定義です。本書が効いているのは、これらをポート＆アダプターアーキテクチャとセットで説明するところにあります。内側にアプリケーションとドメインモデルを置き、外側にアダプターを置く。入り口側では、REST API から入ってきたリクエストをアプリケーションサービス経由でドメインモデルに流す。出口側では、リポジトリ経由でデータベースに保存する。中心のドメインモデルは、HTTP も MongoDB も何も知らずに済むのです。
このアーキテクチャの嬉しさは「ビジネスロジックの純度」を守れることです。Cfp 集約は「募集を define する」「open する」「reschedule する」「close する」という動詞を持ち、そのどれもが不変条件を壊さない形で実装される。外側がどんなフレームワークでも、どんなデータベースでも、その内側の動詞は動じない。
集約の設計には、本書が静かに強調している3つのルールがあります。
- 整合性境界は集約の中だけで守る。集約の外側との整合性は、結果整合性に任せる
- 集約は小さく保つ。1つの集約に抱え込む情報を増やしすぎない
- 集約間の参照は、オブジェクトではなく ID で行う。直接参照は密結合を生むから
どれも知識としては知っていました。知っていて、過去にすべて破りました。ある決済系のシステムで、私は「注文」集約に請求先・配送先・支払い情報・在庫スナップショットまで全部抱えさせたことがあります。「1つの集約で注文のライフサイクルが完結する」という設計上の美しさに酔っていたのです。
結果、何が起きたか。1つの注文を更新するたびに、トランザクションの範囲が大きく広がりました。ロック競合が頻発し、画面側で「注文確定」を押してから3秒待たされるようになりました。整合性境界を集約の外側まで引きずり出していたのです。集約が大きくなったのではありません。境界の感覚を失っていました。
集約の設計だけではありません。同じ「境界の感覚を失う」失敗を、私はもう一段下のレイヤーでも繰り返していました。永続化の都合がドメインモデルに浸食して、気がついたら「ActiveRecord に業務ルールを散らかしただけ」のコードを育ててしまったのです。アプリケーションサービスにビジネスロジックを書くなという本書の注意書きは、あのときの自分に読ませたい一文でした。ドメインサービスはあくまで「単一のモデルに収まらないロジックの逃がし先」であり、便利な雑多収納ではない。ドメインモデルは動詞の集合です。名詞から設計を始めた日、私はすでに敗けていたのだと、今なら言える気がします。
ただし、戦術的設計は万能薬ではありません。疎結合を守るために必要なインターフェースやアダプター、翻訳の仕組みは、確実に実装コストを増やします。単純な CRUD アプリや短命なプロトタイプには見合わない。問われているのは「作れるか」ではなく「このコストを払い続けるべきか」です。本書がこの判断を正面から扱う誠実さが、第4章の信頼感につながっていました。
アプリケーションとドメインモデルを中心に置き、その境界にポートを、外側にアダプターを配置した図だ。プライマリ（駆動）アダプターは、Web UI や REST リクエスト、CLI といった外の世界から入ってくる要求を、ドメインへの操作に翻訳する。セカンダリ（被駆動）アダプターは、永続化やメッセージング、サードパーティ API といった外向きのやり取りを担う。中心のビジネスロジックは、HTTP も MongoDB も Kafka も知らない。この隔離こそが、同じドメインモデルを、インフラ全面書き換えを挟んでも手を入れずに生き延びさせる鍵になる。
抽象的な構造の図だけだと「で、実際のコードではどう並ぶの？」という疑問が残ります。次の図はその問いに、Cfp 集約の例で具体的に答えてくれます。
ポートとアダプターと戦術的 DDD の具体的な組み合わせを、カンファレンスイベントプランナーの論文募集（Cfp）の例で示した図だ。Web クライアントが駆動側の CfpRestAPI から入り、CfpManagement ポートを通って CfpApplicationService に流れ、最終的に Cfp ドメインモデルに到達する。被駆動側では CfpRepository ポートが MongoDB アダプターと対話している。この図の右半分こそが真に見るべき部分だ。Cfp 集約は define / open / reschedule / close という4つの動詞を公開インターフェースとして持ち、CfpId・Period・CfpStatus・Description を値オブジェクトとして内側に抱える。トランザクション境界が集約の周囲に明示的に描かれており、「整合性は集約の端で止める」というルールが視覚的に補強されている。
最後に、第4章に出てきたビルディングブロックがどう関係し合っているかを、地図として一枚にまとめておきます。
戦術的 DDD の語彙の地図だ。DDD は戦略的設計と戦術的設計に分かれ、戦術的設計はビルディングブロックを提供する。ビルディングブロックにはエンティティ、値オブジェクト、集約、集約ルート、ドメインサービス、ドメインイベント、リポジトリ、ファクトリが含まれ、アプリケーションサービスはそれらをまたいでユースケースを調整する。ポートとアダプターアーキテクチャはドメインモデルを外側から隔離する。この図が本当に提供しているのは、共有された語彙だ。チーム全員がこの1枚を指差しながら「いま話しているのはリポジトリではなく集約の話だ」と言えるようになった瞬間から、設計会議の時間は劇的に短くなる。
Chapter 5: Optimizing for Flow of Change with Team Topologies
ここまでの4章は、戦略から問題空間、解決空間、実装までをコードの側から見てきました。第5章からは視点が一度、組織の側へ移ります。起点はコンウェイの法則です。「システムを設計する組織は、その組織のコミュニケーション構造をコピーした設計を生み出す」——有名なこの一節を、本書は「アーキテクチャをいじるだけで組織を放置するのは、根本的に破綻したアプローチだ」と読み替えます。言い換えれば、組織図はアーキテクチャの下書きです。下書きを描き直さずにアーキテクチャだけを清書しようとしても、元の形はそのまま残ります。戦略・設計・組織の三点セットに組織が正面から組み込まれるのは、ここからです。
Team Topologies が提示する道具立てはシンプルですが、すみずみまで効きます。
- 4つのチームタイプ：顧客に価値を届ける流れをエンドツーエンドで所有するストリームアラインドチーム、その自律性を支えるセルフサービス基盤を提供するプラットフォームチーム、足りない能力を一時的に支援するコーチ役のイネーブリングチーム、特殊な専門知識が必要な領域を請け負うコンプリケイテッド・サブシステムチーム。
- 3つのインタラクションモード：短い期間だけ密に協力するコラボレーション、サービスとして提供・利用するX-as-a-Service、スキルアップを支援するファシリテーティング。
- 認知負荷：チームが同時に頭の中に抱えられる情報量には上限があるという考え方。本書はそれを3種類に分けます。タスクそのものの本質的な難しさである課題内在性負荷、レガシーコードや不便なツールなど環境に由来する回避可能な難しさである課題外在性負荷、そして新しい業務ドメインを学ぶときに必要になる学習関連負荷の3つです。
主役はストリームアラインドチームです。顧客に近い位置で、ある業務ドメインや能力の「流れ」をエンドツーエンドで所有する。その他の3タイプは、ストリームアラインドチームの自律性を下支えし、認知負荷を逃がすために存在します。プラットフォームチームは内部のセルフサービスを提供し、イネーブリングチームは一時的なコーチ役として不足しているケイパビリティを埋め、コンプリケイテッド・サブシステムチームは専門性の深い領域を請け負う。
本書は Accelerate の DORA メトリクス——デプロイ頻度、変更のリードタイム、MTTR、変更失敗率——もここで紹介します。チーム構造の話は柔らかくふわっと進みがちですが、こうして計測可能な4つの数字と接続されることで、組織設計の議論が一気に手触りのある話になります。
私が過去に見てきた「機能別サイロ組織」の多くは、善意の細分化の結果でした。UI に強い人を集めたチーム、バックエンドに強い人を集めたチーム、運用の専門家を集めたチーム。どれも個々は合理的で、しかし変更のフローから見るとハンドオフが積み重なり、何1つ速く届かない。本書はこの現象を「機能サイロは善人の集まりで出来ている」と言わないまでも、静かに解剖します。
認知負荷の話はとくに胸に刺さりました。チームに新しい責務を足すとき、私たちはたいてい「スキルで足りるか」だけを考え、「ワーキングメモリに入るか」を考えません。課題内在性負荷、課題外在性負荷、学習関連負荷という3分類は、会議で使える解像度の高い語彙を提供します。
過去に「境界は引いたはずなのに、なぜか速くならない」と悩んだチームがありました。サービス境界もリポジトリも分けた。それでも機能変更は週2日分くらい、別チームのレビュー待ちと環境リセット待ちで止まっていました。原因は境界の形ではなく、境界の内側で働く人たちのバックグラウンドがフロントエンド寄りと運用寄りに偏っていて、横断的な意思決定のたびに「詳しい人を呼んでくる」が発生していたことでした。コンウェイの法則を逆流させたつもりで、機能別サイロの名残がチームの内側に残っていたのです。
4つのチームタイプを一枚に並べた図だ。ストリームアラインドチーム、プラットフォームチーム、イネーブリングチーム、コンプリケイテッド・サブシステムチーム。ストリームアラインドチームが中心に置かれているのは、顧客に向けた変更の流れを直接所有する唯一のタイプだからだ。残りの3つは、そのストリームから障害物を取り除くために存在する。プラットフォームチームは横断的なインフラ関心事を引き受け、イネーブリングチームは不足しているケイパビリティに対して一時的にコーチングを行い、コンプリケイテッド・サブシステムチームは専門性の深い領域のオーナーシップを担う。4つを同時に眺めると、「どれかが劣位の二軍チーム」ではないことが一目で分かる。それぞれが、ストリームアラインドチームの集中を守るための固有の仕事を持っている。
チームタイプを整理するだけでは不十分で、チーム同士がどう関わるかもまた同じくらい重要だ、という主張を表した図だ。3つのインタラクションモードが描かれている。コラボレーションは2つのチームが短期間だけ密に協力して、新しい何かを発見したり生み出したりすること。X-as-a-Service は片方のチームが、もう片方のチームが維持するものを、明確なインターフェース越しに利用する関係。ファシリテーティングは片方のチームが一時的にコーチ役となり、もう片方のチームに不足するケイパビリティを身につけさせること。この図の強さは、インタラクションモードを「誰がたまたま隣の席に座っているか」という偶然ではなく、意図的な設計対象として扱う点にある。そして、モードは時間とともに進化させるべきものだ、ということも同時に思い出させてくれる。
Chapter 6: Connecting the Dots
第5章で Team Topologies の基礎を押さえたところで、第6章は本書の基礎編を一度締めくくります。ウォードリーマッピング、DDD、Team Topologies——ここまで別々に語られてきた3つの道具が、カンファレンスイベントプランナーという1つの題材の上で交差し始めます。章題のとおり、点と点をつなぐ章です。
中心になるのは「変更ストリーム」という概念です。組織内で最も重要な変更がどこで発生するのか。それを顧客駆動のユーザージャーニー（論文募集＝CfP 投稿、評価、スケジュール作成、コミュニケーション……）として洗い出し、ストリームに沿ってチームとシステムを編成する。ここでストリームアラインドチームの存在意義が、抽象論ではなく具体の業務の上に着地します。
依存関係の分析も本章の要点でした。Dominica DeGrandis 氏と Tonianne Demaria 氏の『Making Work Visible』を引いて、本書は依存関係を3つに分類します。1つ目はアーキテクチャ依存で、コードやシステム構成の都合で「あのサービスを触らないとこの機能が動かない」となる状態。2つ目は専門知識依存で、「この領域はあの人にしか分からないから、あの人が手すきになるまで待たなければならない」という状態。3つ目は活動依存で、「あのチームの作業が終わらないと、こちらの作業は始められない」という時間的な順序の依存です。どれもフローを詰まらせる原因であり、しかもどれもウォードリーマップと境界づけられたコンテキストの観点から見直すことで初めて正体が見えてきます。密結合なアーキテクチャでは、1つの変更が他チームにも波及し、調整コストが跳ね上がり、壊すリスクも増える。疎結合でモジュール化されたアーキテクチャは、チームが自律的に動けるようになるための前提条件なのです。
そして制約理論が差し込まれます。Eliyahu Goldratt 氏の言葉が引用されていました——「ボトルネック以外で行われた改善はすべて幻想である」。このフレーズは私にとって強烈でした。過去に自分がやった「改善」のうち、何割がボトルネックに手を入れていただろうか、と。ボトルネックの前を改善すれば作業は積み上がるだけで、後を改善しても上流から来るインプットが増えない。システム全体のスループットを決めるのは、いつも一箇所の制約です。
バリューストリームマッピングはこのボトルネック発見の強力な道具として紹介されます。サイクルタイム、待機時間、リードタイム、完全で正確な結果の割合——これらを測ると、「価値を付加している時間」と「ムダに待っている時間」のギャップが見える。開発現場の「なぜか遅い」という感覚は、測ると必ず数字で説明できる。この章を読んで、私は自分のチームの1つのフィーチャーを題材にバリューストリームマッピングを描いてみました。結果、コミットからデプロイまでの経過時間のうち、実作業の時間は10%未満でした。残り90%は、ほとんどがレビュー待ちと環境準備の待ち時間だったのです。数字を見てから最初に動かしたのは、コードの設計ではなくレビュー担当の割り当てルールでした。いちばん詰まっていた箇所の前後を少しだけ広げた。効いたかどうかは半分くらいしか確信がありません。たぶん効いていました。
本章で効いたもう1つの道具が、ウォードリーの進化段階と Dave Snowden 氏の Cynefin（クネビン） フレームワークの重ね合わせでした。Cynefin は、いま自分が置かれている状況を4つのタイプに分けて、それぞれにふさわしい動き方を当てはめる道具です。「Clear（明確）」は原因と結果がはっきりしていて、ベストプラクティス通りに動けば解ける領域。「Complicated（煩雑）」は分析と専門知識があれば解ける領域。「Complex（複雑）」は動いてみないと因果が見えない、探索と実験の領域。「Chaotic（カオス）」は因果関係そのものが崩れていて、まず行動してみるしかない領域です。Kaiser 氏は、この Cynefin の4つと Wardley の進化段階を暗黙のうちに1対1で対応させます。コモディティ → Clear、プロダクト → Complicated、カスタムビルド → Complex、創世記 → Chaotic。ここまでは綺麗な話です。
興味深いのは、この1対1が崩れる条件まで本書が素直に認めていることです。コモディティのクラウドサービスであっても、触ったことのない組織にとっては Complex ドメインになります。進化段階だけを見ると「ベストプラクティスを適用すれば終わり」に見えるコンポーネントが、自チームに経験がなければ、探索と発見から始めるしかない。Tune 氏の『アーキテクチャモダナイゼーション』第11章も、「認知負荷許容量はチームの規模や専門知識などの要因によって異なる」と釘を刺しています。進化段階は市場の話で、認知負荷はチームの話だ。同じコンポーネントでも、誰が所有するかで位置が動く。
進化段階だけでは Cynefin ドメインが決まらないとすれば、チーム内に「この段階に合った動き方ができる人」がいるかどうかが決定的に効いてきます。ここから派生するのが、ウォードリーの探索者（Explorer）／村人（Villager）／都市計画者（Town Planner）というマインドセット3分類の議論です。探索者は未知の市場で実験と発見を好み、村人は育ちつつある市場で改善と安定化を好み、都市計画者は成熟した市場で効率と標準化を好む。Kaiser 氏はあえて「チームを1種類のマインドセットで組むな」と書きます。ストリームアラインドチームは複数の進化段階を時間とともに渡っていくため、内部には異なる姿勢の組み合わせが要る。私は過去に、自分のチーム編成で「スキルの分布」は念入りに測り、「マインドセットの分布」はまったく測っていませんでした。探索が必要な局面で都市計画者ばかりが並んでいれば、スキルは足りていても、手は動きません。足りなかったのは人手ではなく、姿勢の組み合わせだったのかもしれません。
バリューストリームマップは、1つの作業アイテム——たとえばある機能や変更依頼——がアイデアから本番投入までたどるすべてのステップを追跡し、各ステップにサイクルタイム、待ち時間、完全で正確な結果の割合を書き込んだ図だ。結果として得られるのは、容赦のないほどの明快さだ。エンドツーエンドのリードタイムのうち、どれだけが本当に価値を生み出していて、どれだけが待ちに消えているかが、1枚の絵で見える。私自身、最初にこのマップを描いたときは、経過時間の10%未満しか実作業ではなく、残り90%がひたすら待ち時間であることが分かった。描くまで、それは見えていなかった。
本文で触れた Cynefin フレームワークも、文字だけだとピンと来ません。まずは Snowden 自身がどう4ドメインを並べているかを、本書の引用図で確認しておきます。
そして本文で触れた「進化段階だけでは Cynefin ドメインが決まらない」話を、本書はもう一枚の図で念入りに見せてきます。
Wardley の進化段階と Cynefin のドメインのあいだには、暗黙の1対1マッピング——コモディティは Clear、プロダクトは Complicated、カスタムビルドは Complex、創世記は Chaotic——があるように見える。しかしこの対応関係は、チームがそのコンポーネントの経験をすでに持っているときにしか成り立たない。クラウドホスト型のコモディティサービスに初めて触れるチームにとっては、同じコンポーネントが Complex ドメインに位置する。彼らは探索し、感知し、対応するしかない。この図が思い出させてくれるのは、Wardley マップが語っているのは「市場」であり、Cynefin が語っているのは「その仕事を抱えているチーム」である、ということだ。Wardley マップ上の同じ箱が、誰が所有するかによってまったく異なるプラクティスを要求する。
Chapter 7: Visualizing Team Perspectives with Wardley Maps
第6章でウォードリーマッピング・DDD・Team Topologies を1つの題材の上で交差させたあと、第7章は視点の転回にあてられます。ここまでは外部顧客をアンカーにしたウォードリーマップを描いてきましたが、本章では内部のチーム——特にプラットフォームチーム——の視点に立ったマップを描きます。
題材として選ばれるのはマイクロサービスです。マイクロサービスを採用した組織では、データの置き場所、実行基盤、サービス間の安全な通信、サービス発見、障害を遮断する仕組み、冪等性、イベント駆動、監視、CI/CD パイプライン、バックアップと復旧、スケーラビリティ——ざっと数えても10個以上の横断的な関心事が毎チームにのしかかります。この山をウォードリーマップに載せると、「小さなチームが全部抱えるのは無理だ」という結論が目で見てわかります。無理なのは分かっていました。分かっていて、抱えさせていました。
プラットフォームチームの役割は、この不可能を可能にすることです。本章ではプラットフォームチームから見たバリューチェーンが描かれます。アンカーに置かれるのは顧客ではなく、内部のストリームアラインドチーム。そのニーズは「サービスをビルドしてテストしたい」「リリースしてデプロイしたい」「モニタリングして運用したい」「インフラを管理したい」——この4つ。
それを満たすのが、デザインシステムプラットフォーム、ビルド＆リリースプラットフォーム、運用＆モニタリングプラットフォーム、インフラストラクチャプラットフォームといった内部プロダクトです。どれも「ストリームアラインドチームの自律性を高め、認知負荷を下げる」という1つの目的に向かって設計される。プラットフォームは技術の集合ではなく、内部顧客の体験設計なのだ、と本書は繰り返します。
私にとって効いたのは「プラットフォームは X-as-a-Service として提供される」という整理でした。チケットを切って依頼を出してからレスポンスが来るまで数日待たされるような仕組みは、もはやプラットフォームではない。セルフサービスで、標準・テンプレート・API・ドキュメントとして提供されてこそ、プラットフォームの名に値する。過去に私がいた組織の「インフラ部」は、この基準で言えばプラットフォームチームではなく、ただの専門部署でした。
ここで思い出したいのが、Ajay Chankramath 氏・Sean Alvarez 氏・Bryan Oliver 氏・Nic Cheneweth 氏の共著『Effective Platform Engineering』（Manning）です。あの本は冒頭で、多くの組織が陥りがちな退行のパターンを描いています。DevOps ツールを導入してインフラ管理を開発チームに移譲する。しばらくは速くなる。しかし、やがて社内のセキュリティやガバナンスの担当者がパイプラインに介入し始め、専任のパイプラインチームが生まれ、チームごとの独自実装が乱立する。最終的に、かつてと同じチケット方式のキューに戻ってしまう——そういう循環です。読みながら、私は自分が過去に関わった「DevOps 推進プロジェクト」のほとんどが、まさにこの軌跡をたどっていたことに気づきました。ツールを導入しただけでは、プラットフォームにはならない。プラットフォームとはプロダクトであって、ツールの集合ではないのです。
本書が出してくるもう1つの大事な言葉が、最小限の実用的なプラットフォーム（Thinnest Viable Platform, TVP） です。プラットフォームは、最初から巨大な基盤である必要はありません。ドキュメント、標準、チェックリスト、ベストプラクティス、テンプレートから始めていい。そこからセルフサービス API やツールを備えたデジタルプラットフォームへ、段階的に進化させていけばいい、という考え方です。
読みながら、私は過去に自分が作ろうとしたプラットフォームの設計書を思い出しました。Kubernetes を中心に据え、GitOps で運用を自動化し、サービスメッシュで通信を制御し、ポリシー管理でガバナンスを効かせ、コンプライアンス自動化で監査にも備える——初日から全部入りを目指していました。結果、半年経っても誰も使えない、立派なアーキテクチャ図だけが残りました。必要だったのは、その半年前に「デプロイ手順書のテンプレート1枚」をチームに配ることだったのです。
プラットフォームは道具の集合ではなく、最初の1枚の紙から始めるべきでした。たぶん、そう思います。
『Effective Platform Engineering』は、プラットフォームを成功させる7つの原則を挙げています。ソフトウェア定義、セルフサービス、進化的アーキテクチャ、指標駆動の成功、セキュアかつコンプライアント、自動化されたガバナンス、そしてオブザーバブルの7つです。どれも単独なら難しくありません。難しいのは、1つ欠けるだけで全体が崩れることです。たとえば、セルフサービス機能を作っても、使用状況のデータが取れなければ「指標駆動の成功」は測れません。コンプライアンスを自動化せず人海戦術で満たそうとすれば、「自動化されたガバナンス」は形だけになります。7つの原則はチェックリストではなく、お互いを支え合う網の目です。これら7つが描いている世界は、Kaiser 氏が第7章でプラットフォームチームに期待する役割——ストリームアラインドチームの自律性を支えるセルフサービス基盤——とほぼ重なります。
この重なりのなかで特に効いたのが、「変更時点でのコンプライアンス（compliance at the point of change）」 という考え方です。従来のやり方では、コンプライアンスチェックは開発の終盤に後付けの関門として差し込まれます。結果として、レビュー待ちの列ができ、リリースは遅れ、開発者には「あとから怒られる」印象だけが残ります。そうではなく、変更が起きる瞬間に、プラットフォーム側で自動的にチェックが走る仕組みに変える。開発者は意識せずにルールを満たし、監査側はその瞬間の記録を手に入れる。私は過去に、この逆を何度も経験してきました。リリース直前にセキュリティレビューが入り、2日の遅延が生まれ、次のリリースではチームが「早めに相談しよう」と話し合うが、同じことを繰り返す。仕組みで解けない問題を、個人の気合で解こうとしていたのです。
コンプライアンスを「あとから怒られる関門」から「変更時点の自動チェック」へ置き換える発想は、本書のプラットフォーム論と地続きで、ソフトウェアの外にもそのまま効きます。コンプライアンス、規制、法務、人事——ストリームアラインドチームの流れを詰まらせるものは、すべてプラットフォーム化の対象になりえます。たとえば「法務確認を依頼するたびにメールで数日待たされる」状況は、セルフサービスの契約レビュー基盤があれば大きく改善するはずです。プラットフォーム思考は、ソフトウェアを離れても通用する組織設計の考え方なのです。
ここで本書が描いた、プラットフォームチームから見たバリューチェーンの図に戻っておきます。「内部顧客のためのプロダクト」という発想が、1枚の絵にきれいに収まっています。
プラットフォームチームの視点から Wardley マップを描いたバリューチェーンの図だ。ここでアンカーに置かれているのは外部の顧客ではなく、内部のストリームアラインドチームになる。その上には「サービスをビルドしてテストしたい」「リリースしてデプロイしたい」「モニタリングして運用したい」「インフラを管理したい」という4つのユーザーニーズが並ぶ。マップの下側にはデザインシステムプラットフォーム、ビルド＆リリースプラットフォーム、運用＆モニタリングプラットフォーム、インフラストラクチャプラットフォームといった内部プロダクトが配置される。アンカーを外部顧客から内部チームへ置き換えるだけで、プラットフォームが「内部顧客体験を設計するプロダクト」として立ち上がる。この視点の転回こそが、この章の肝だ。
Chapter 8: The Architecture for Flow Canvas
第7章でプラットフォームチームの視点を獲得したあと、第8章はついに本書の要に到達します。タイトルにもなっている Architecture for Flow キャンバスが、ここで登場します。
キャンバスは厳格なフレームワークではなく、「役に立つ最小限の構造」として設計されています。やることは2つ——as-is（現状）の評価と to-be（将来像）の設計を、同じ一枚のテーブルの上で往復すること。通常は現在のチームの分析から始め、問題ドメインの理解を段階的に進め、最後に未来のチーム像の構想につなげます。
as-is の評価で扱うのは、次のような要素です。
- チーム構造・規模・責務・依存関係・インタラクションモード・プラクティス——今のチームはどう組まれていて、どこがどう繋がっていて、どう働いているのか。
- 現在の変更フローの阻害要因と促進要因——チームインタビューで赤い付箋（阻害要因）と緑の付箋（促進要因）を集める。
- 現在のビジネスランドスケープ——ウォードリーマップで可視化する。
- 問題空間のサブドメイン分類——コア・支援・汎用に振り分ける。
そして to-be の設計では、ソリューション空間を境界づけられたコンテキストでモジュール化し、将来のビジネスランドスケープを描き直し、そこに合わせてチームタイプとインタラクションモードを導出します。現状から将来像への橋を渡すのが、サブドメイン分類です。
このキャンバスが強烈なのは、「同じ1つの道具の上で、戦略会議と設計会議と組織会議が共通の言葉を手にする」という点です。私はこれまで、戦略はパワーポイント、設計は Miro とコード、組織は HR のスプレッドシート——と、話題ごとに別々の道具を使ってきました。3つが一枚のキャンバスに載る瞬間を想像するだけで、これまで切れていた会話がつながる気がします。
ここで少し立ち止まって考えたいのは、「共通言語」とは何を共有することなのか、です。私は長いあいだ、共通言語とは「共有された語彙」のことだと思っていました。「コアドメイン」という言葉の意味を全員が同じように理解していれば、それが共通言語だ、と。けれども、どうやらそれは半分しか合っていません。語彙だけなら辞書を配れば済みます。本当の共通言語とは、同じ絵を一緒に指差せる状態のことです。キャンバスの上に貼られた1枚の付箋を指して、戦略の人も設計の人も組織の人も、それぞれの言葉で語れる。指差す先が同じなら、語彙が多少違っても会話は噛み合います。逆に、どれだけ用語辞典を揃えても、指差す先が人によって違っていたら、会話は永遠にすれ違います。キャンバスが共通言語を生むのは、共通の語彙を配るからではなく、共通の「見えているもの」を置くからです。
実践上のポイントとして本書が強調するのは、キャンバスは一人で書くものではないということ。最適化プロセスに関わるチーム全員で作るコラボレーティブな場こそが本質で、付箋で阻害要因を洗い出し、ウォードリーマップを協働で描き、境界を議論する——そのプロセスそのものが共通理解を醸成します。成果物はキャンバスという物理的なアウトプットですが、本当の成果物はそこに集まった人たちの「見えているもの」の一致です。過去に私は一人で完成形を描いてから会議に持ち込んだことがあります。「これで話が早くなる」と思っていました。話は早くなりませんでした。持ち込んだ瞬間から、キャンバスは私の作品として評価対象になり、全員の共同制作物ではなくなっていたのです。
Wardley マップを実際にどう描き始めればよいかを手順として示した図だ。まずユーザーとユーザーニーズをアンカーとして特定し、そこから価値を届けるコンポーネントを縦に並べていく。各コンポーネントに進化段階を割り当て、依存関係で結び、最後に全体を眺めて不整合がないか確認する。この図の値打ちは、Wardley マップを「魔法のツール」ではなく、順序立てた作業として見せてくれるところにある。最初の1枚はいつでも不完全で、描きながら議論が進み、議論の過程で認識がそろっていく。手順を追えば誰でも最初の1枚は描ける、というメッセージでもある。
Chapter 9: Designing a Legacy System for Flow
ここまでの章は、基礎を組み立てる章でした。第9章はその基礎を、ついに現実の泥にぶつけます。題材は中学生向けオンラインスクール——すでに市場に出て数年が経ち、モノリスとして始まり、時間とともに大きな泥だんご（Big Ball of Mud）に育ってしまった既存システム。これは意図的にグリーンフィールド（新規構築）ではなく、ブラウンフィールド（既存システム改修）の題材として選ばれています。
本書が大きな泥だんごを描写するくだりは強烈でした。Brian Foote 氏と Joseph Yoder 氏はこの状態を「場当たり的に構造化された、無秩序に広がる、ずさんな、ガムテープと針金で繋ぎ合わせたスパゲッティコードのジャングル」と定義しています。情報がシステムの離れた要素間で無差別に共有され、ほぼすべての重要な情報がグローバルまたは重複している状態に至る。アーキテクチャへの感性を持つプログラマーはこの泥沼を避け、崩壊しつつある堤防の穴をふさぐ日々の作業に安住する者だけがそこに残る、というくだりは、私のキャリアの何年分かを言い当てられたようで、少し息が詰まりました。息が詰まったのは描写の正確さに対してではなく、「穴をふさぐ日々の作業に安住する者」の中に、自分の顔をはっきり見つけたからです。私は泥を避けなかった。避ける力がなかったのではなく、避けるほどには泥を泥だと思っていなかったのです。泥の中にいると、泥の色が普通に見えてくる。異常に慣れる速度は、想像より速かった。
第9章がやることは、第8章のキャンバスを「オンラインスクール」という具体の上でなぞっていく作業です。
- 現在のチームの検証——フロントエンド、バックエンド、インフラ/運用の機能サイロで編成されており、チーム間はチケットで引き継ぎが回っている。
- 現在の変更フローの評価——機能変更はレイヤーを越えて何度もハンドオフを起こし、調整と待ち時間が積み重なる。
- 現在のウォードリーマップの作成——オンラインスクールコンポーネントは現状では単一の大きな泥だんごとして、カスタムビルド段階に暫定的に置かれる。
- 問題ドメインの分類——教師と生徒のユーザーニーズを洗い出し、コア・支援・汎用に分ける。
- 将来の境界づけられたコンテキストの設計——大きな泥だんごをモジュラーモノリスに段階的に分解する道筋を引く。
- 将来のチーム構成の導出——ストリームアラインドチームとプラットフォームチームを基軸に据える。
一番効くのは、「機能サイロの現状をキャンバスに素直に貼り付けると、その痛みが共通言語で見えてくる」という体験の再現です。誰かの責任探しをするのではなく、「あなたのチームのフロー阻害要因はどこですか」とインタビューして赤い付箋を集める。境界が見えることと、責任が見えることは違う。本書はその違いにとても敏感です。
私は過去に、「レガシーを何とかしたい」とだけ叫ばれた現場にいたことがあります。何から手をつければいいのか誰にも分からず、結局はエッジのあたりで小さなリファクタリングを繰り返して終わりました。Chapter 9 が差し出すのは、「レガシーは戦略と組織と設計の三点セットで可視化されて初めて触ることができる」という態度です。
オンラインスクール事例の「現状」を一枚に描いた図だ。フロントエンドチーム、バックエンドチーム、インフラ／運用チームという3つの機能別サイロが並んでいて、それぞれが自分の層の責任範囲だけを見ている。チーム間はチケットで引き継ぎが回り、ハンドオフのたびに待ち時間が積み重なる。この図が効くのは、改善の出発点を描いているからだ。ここから将来像（to-be）へ向かう道筋を引くためには、まず現状を否定せずに受け入れる必要がある。描くことそのものが、最初の1歩になっている。
Chapter 10: Implementing Flow Optimization
第10章は、第9章で描いた将来像に向けて、どうやって組織を動かし始めるかという「実装の章」です。この章の姿勢を一行で言えば——ビッグバンではなく、インクリメンタル。大規模な一括再編成は痛みが大きく、リスクも高く、何より学習ができない。小さく動いて早く学ぶ方針が、一貫して貫かれます。
章の冒頭で強調されるのは、「変革の 理由 を共有する」ことの大切さです。フロー阻害要因、ウォードリーマップ、発見したコアドメイン、設計した境界づけられたコンテキスト、導き出した将来のチーム構成、効率性のギャップ——これらを率直に組織全体へ開示する。最適化の利点だけでなくリスクやデメリットも正直に伝えることで、現実的な期待値と信頼が生まれます。
続いて、Heidi Helfand 氏の『Dynamic Reteaming』から5つのリチーミングパターンが紹介されます。
- One by one：一人ずつチームに足したり離れたり。
- Grow and split：大きくなったチームを2つに分ける。
- Isolation：既存メンバーから新しいチームを隔離して、自由に探索させる。
- Merging：複数のチームを1つに統合する。
- Switching：個人がチームを変わる、ペアを組み替える。
オンラインスクール事例では、これらのパターンが具体的な移行ステップに割り当てられていきます。まず隔離パターンでディスカバリー用のプラットフォームチームを結成し、クラウド移行に全力を注がせる。リプラットフォーミングが進んだら、残りのインフラチームをそこに統合する（Merging）。モノリシックなバックエンドを段階的に分解する最初のストリームアラインドチームを結成し、境界づけられたコンテキストを1つずつ切り出していく。次々と新しいストリームアラインドチームを立ち上げ、インタラクションモードはコラボレーションから X-as-a-Service へと進化していく。
この章で印象的なのは、チーム間のインタラクションモードが時間とともに動くことを前提にしている点です。新しいプラットフォームを立ち上げる初期は、プラットフォームチームとストリームアラインドチームがコラボレーションで密着し、新しい技術スタックを一緒に探索する。やがてセルフサービス機能が整ってくると、そのインタラクションは X-as-a-Service に進化していく。チームトポロジーは静止画ではなく、動画なのです。
ただ、インタラクションモードを動かしていく前提として、コードの側でも同じ「動きやすさ」を確保する必要があります。第10章は「小さく動く」という原則を、システムの分解、アーキテクチャの中間形態、コミットの粒度、チームの働き方という4つの層で繰り返し語ります。
まずシステムの分解。Kaiser 氏が丁寧に解説しているのが Strangler Fig パターンです。「絞め殺し植物」を意味するこの呼び名の通り、旧システムの前段に Strangler Facade と呼ばれるルーターを置き、受信リクエストを旧実装と新実装に振り分けながら、機能を1つずつ並行稼働で置き換え、最後に旧システムを廃止していく。境界づけられたコンテキスト単位で、時間をかけて少しずつ置換していく手法です。
次にアーキテクチャの中間形態。興味深いのは、Kaiser 氏がマイクロサービスに飛ぶ前にモジュラーモノリス——単一のデプロイ単位の中で内部だけをモジュール化したアーキテクチャ——を中間ステップとして挟む点です。コンテキスト間の直接のオブジェクト参照を ID 参照に置き換え、コンテキスト間のトランザクション一貫性を排除する。ここで結合を解きほぐしてから、初めて分散アーキテクチャへの抽出を検討する。Tune 氏の『アーキテクチャモダナイゼーション』第12章も、Strangler Fig の段階的な性質そのものが「多くの理由でうまくいかない可能性のある一斉スイッチオーバーのリスクを軽減する」と書いています。中間ステップは美学ではない。リスク制御の設計です。
3つ目はコミットの粒度。この段階的な考え方は、Kent Beck 氏の『Tidy First?』が言う「小さな整頓（tidying）」の姿勢ともまっすぐ重なります。振る舞いの変更と構造の変更を同じコミットに混ぜないこと、そしていまの変更コストを下げるための小さな構造の変更を積み重ねること——この2つの原則は、Strangler Fig で旧システムを1機能ずつ剥がしていく作業そのものの理論的な背骨になります。正しいことは知っていました。知っていて、やらなかった時期があります。ある分解プロジェクトで、私は「ついでに」仕様変更を構造の変更と同じプルリクエストに混ぜました。レビューは紛糾し、切り戻しの範囲が読めなくなり、リリースは2週間延びました。あのとき Facade の位置を1ミリ動かす勇気がなかったのは、設計の問題ではなく、「ついでに」を我慢する規律の問題でした。正直に言えば、「レガシー分解 = Strangler Fig」という等式を覚えただけでは、現場ではほとんど動けません。難しいのはパターンの名前ではなく、どこに Facade を置くかとどのサイズで整頓するかの判断のほうです。境界を1本引き間違えると、Facade が腐敗防止層のような肥大化を起こし、移行そのものが止まります。小さなループを積み重ねるという章の思想は、ここでも効いてきます。たぶん。
最後に、チームの働き方。小さなループで進むとき、その1ループをチームがどう回すかという問題が残ります。ここで本章に差し込まれるのが、ソフトウェアチーミング（かつてのモブプログラミング）の話です。「個人のアウトプットではなく、作業のフローを最適化する」という Woody Zuill 氏の言葉は、シンプルですが強烈でした。私たちは長いあいだ、個人のアウトプットの最大化を前提に組織を設計してきました。けれども、フローの最適化という観点に立つと、全員が同じ問題に同じ時間で取り組むことのほうが正解になる場合がある。
過去に、半年かけて計画を立て、3ヶ月で実行し、4ヶ月目にロールバックを決めた刷新プロジェクトがありました。撤退を決めた最後の会議で、誰かが「最初の2週間で試せたことを、なぜ半年待ったんだろう」と静かに呟いたのを覚えています。その一言が、あの半年分の計画書を丸ごと捨ててもいい理由になりました。
ただ、正確に言うと、計画書を作っている最中、私たちは途中で何度も「このまま進めて大丈夫だろうか」と思っていました。思っていたのに、立ち止まりませんでした。大きな船は舵が重いから、という言い訳を互いに交換しながら進みました。欠けていたのは「小さく動いて早く学ぶ」という姿勢というより、小さく動くことを選ぶ勇気だったのかもしれません。小さく動くとは、計画の不完全さを早く晒すことでもあります。
Heidi Helfand が『Dynamic Reteaming』で整理した、チーム構成を状況に応じて動かすための5パターンを示した図だ。One by one（1人ずつ足したり離したり）、Grow and split（大きくなったチームを分割）、Isolation（既存メンバーから新しいチームを隔離して自由に探索させる）、Merging（複数のチームを1つに統合）、Switching（個人がチームを変わる／ペアを組み替える）。組織変更を「年に1回の大イベント」ではなく、日常の動的な再編として捉え直すための語彙の一覧だ。これらを持っていると、組織構造についての会話が「正解／不正解」ではなく「いまはどのパターンを使うべきか」という話になる。
組織側のリチーミングと並行して、コード側での段階的な置き換えがどう進むかを描いたのが、本章の Strangler Fig パターンの図です。
Strangler Fig パターンを2段で描いた図だ。上の段では、旧システムの中から置き換え対象の機能を Identify（特定） し、新システム側で Implement（実装） し、必要なら旧システムに API を Expose（公開） させ、ルーター層でトラフィックを Redirect（振り分け） する、という4ステップが示される。下の段では時間軸の流れが描かれていて、Strangler Facade の下で旧と新の比率が徐々に逆転していき、最終的に旧システムが消える。絞め殺し植物が宿主の木にゆっくり巻き付いて置き換えていく、という比喩が効くのはこの時間軸の段だ。一度に全部切り替えるのではなく、機能単位の細い筋を何本も通しながら、時間をかけて置換していく。
Chapter 11: Fostering Continuous Improvement and Driving Future Change
第10章で移行をどう動かし始めるかを見たあと、第11章は移行後にいちばん大事な問いに答えます——「このフロー最適化を、どうやって続けていくのか」。ここでテーマになるのは3つの理論です。組織の情報の流れ方を分類する Westrum の組織文化モデル、失敗だけでなく成功にも目を向ける Safety-I／Safety-II の対比、そして Peter Senge の学習する組織。技術書だと思って読んでいた本が、静かに人と組織の本に変わっていく瞬間でした。
最初は Westrum の組織文化モデルです。
- 病理的文化（権力志向）：情報は政治的な利益のために抱え込まれ、隠される。
- 官僚的文化（ルール志向）：情報はルールと手続きに従って部門の目標のために流れる。
- 生成的文化（パフォーマンス志向）：情報は組織全体のミッション達成のために効果的に流れる。
『Accelerate』の4年間の研究は、生成的文化がソフトウェアデリバリーパフォーマンスと組織パフォーマンスの両方に統計的に効くことを示しました。生成的文化では、失敗は調査とシステム改善の機会として扱われ、犯人探しが起きません。この一節を読んで、私は過去に参加したポストモーテムを次々と思い出しました。最良のポストモーテムは、誰も責めずに、システムの構造だけを問題にしていた。最悪のポストモーテムは、形だけ「ブレームレス」を掲げながら、空気で犯人を作っていました。
2つ目の理論は、Safety-I と Safety-II という2つの安全観の対比です。やさしく言い換えるなら、こういう話です。Safety-I は昔ながらの安全観で、「悪いことが起きていない状態」を安全と呼びます。インシデントや障害を後手で減らすために、ルール・手順・ポリシーを整える。この考え方の前提は、「システムはきれいに部品に分けられて、各部品は正常か異常かのどちらか」というものです。
それに対して Safety-II は、比較的新しい安全観です。こちらは「うまくいっているのは何のおかげか」に目を向けます。失敗の原因を潰すことだけを安全と呼ぶのではなく、ふだんうまく動いている理由や、予想外の出来事から立ち直る力までを安全に含める。ここでの安全は、「エラーがない状態」ではなく、「変化に合わせていける状態」です。
この対比は、いまのソフトウェアの運用感覚にとても深く刺さります。依存関係が多く、変化が速く、何が起きるか読めない環境では、「正常か異常か」という Safety-I の見方ではもう足りません。想定外の組み合わせが次々に起きるからです。しなやかさの工学——レジリエンスエンジニアリングとも呼ばれる——は、失敗ではなく成功の研究から始めるべきだ、という主張でした。これは私の中の「ポストモーテム観」を少しずらしました。思い返すと、私がそれまで書いてきたポストモーテムは、ほぼすべて「なぜ落ちたか」から始まっていました。「なぜ昨日まで落ちなかったのか」を書いた記憶はほとんどありません。成功の側にはメカニズムがないと、どこかで思い込んでいたのです。
3つ目の理論は、章の後半で登場する Peter Senge 氏の『学習する組織』の5つのディシプリン——自己マスタリー、メンタルモデル、共有ビジョン、チーム学習、システム思考——です。特にシステム思考は、本書全体を貫く思想と響き合います。バリューチェーンも境界づけられたコンテキストもチームトポロジーも、結局は「部分の総和ではなく、部分の相互作用」を見るための道具でした。第11章は、その思想を組織の学習という最深部まで引き伸ばします。
学習する組織を支えるためのプラクティスと原則を俯瞰的に並べた図だ。継続的な共有学習と実験は、それ単体で成立するものではなく、本書のここまでの章で紹介してきた多くのプラクティス——小さく動くこと、境界をきれいに引くこと、認知負荷を管理すること、生成的文化を育てること、Safety-II の姿勢を持つこと——の上に積み重ねられる。この図が示すのは、「学習する組織」とは特別な施策のことではなく、他の原則を全部実践した先に自然と立ち上がってくる状態だ、ということだ。学習は目的にするものではなく、結果として現れるものなのだ、という本書の姿勢がここに凝縮されている。
Chapter 12: Conclusion
第11章で学習する組織まで話が届いたあと、第12章は短いながら、本書の骨格を一枚の絵にして終わらせる章です。
ウォードリーマッピング、DDD、Team Topologies——この3つが「正しいものを、正しく作る」という1つの目的のもとに結び直されます。ウォードリーマッピングで競争環境を見て、変化を読む。DDD で問題を整理し、解決策をモジュールに分ける。Team Topologies でチームとやり取りの形を整える。3つの視点が補い合って、初めて「変化について行ける社会技術的なシステム」が立ち上がります。
第8章の Architecture for Flow キャンバスが、ここで改めて「3つを束ねるための統合ビュー」として位置づけ直されます。現状（as-is）の評価から始め、問題空間をサブドメインに分類し、ソリューション空間をモジュール化し、将来のランドスケープを描き、継続的なフローに最適化されたチーム構造とインタラクションモードを導出する。この一連のワークフローを、同じテーブルの上で走らせるための共通言語がキャンバスだ、というメッセージです。
本書が並走する他の技法にも敬意が払われます。バリューストリームマッピング、制約理論、Cynefin——どれも Architecture for Flow と矛盾せず、むしろ補完し合う道具として紹介されます。「このやり方だけが正しい」という押し付けは一切ありません。
そして最後に、本書は正直な断りを置いて終わります——銀の弾丸はない。方法論を売りたい本は、方法論の限界を語りません。本書は語る。小さく始めて、進みながら学び、分かったことをもとに軌道を直し、環境が動き続けるなかで進化させ続ける。それだけです。それだけ、というのが、いちばん難しいのですが。1冊で完結する方法論を売るのではなく、3つの強力な視点の合流点で、読者自身が自分の組織の地図を描き始めるための道具一式を手渡して去っていく。12章を読み終えた私の手に残ったのは、答えではなく、良い問いと良い道具でした。道具があれば動けるとは限りません。でも、道具がなかったあの頃よりは、動かない理由を1つ減らせました。
本書全体の骨格を一枚に畳み込んだ図だ。Wardley マッピング（戦略）、ドメイン駆動設計（問題空間と解決空間）、Team Topologies（組織とインタラクション）という3つの視点が、「変化への高速フローに最適化された適応的な社会技術的システム」という1つの目的のもとに結ばれる様子が描かれる。それぞれが独立した強力なフレームワークだが、3つを並べるだけでは効果は重ならない。この図は、3つを同じワークフローの中で順番に取り出す装置として配置し直している。12章の旅を終えて手元に残るのは、この1枚の俯瞰と、それぞれの視点を自分の組織で試し始めるための小さな勇気だ。
読後に変わった景色
3つを同じテーブルに載せる
12章を読み終えて、自分の中でもっとも大きく動いたのは「3つを別の会議でやるな」という感覚でした。戦略会議、設計レビュー、組織再編——これまで私はこの3つを別々の議題として、別々のスライドと別々の Miro ボードで扱ってきました。本書が差し出すのはその逆です。ウォードリーマップ、境界づけられたコンテキスト、チームトポロジーが同じ一枚のキャンバスの上で往復する光景を、第8章と第9章は見事に描いています。
このキャンバスの本当の価値は、アウトプットそのものではなく、「同じ言葉で議論できる場」を生むところにあります。戦略の人が「ここはコアドメインなので内製すべきだ」と言い、設計の人が「ならば境界づけられたコンテキストをこう切り直そう」と応え、組織の人が「そのコンテキストのオーナーシップはストリームアラインドチームに持たせよう」と繋ぐ。3つの役割が、同じ地図の上で会話できるようになる。
過去の私は、3つのレイヤーのあいだを走り回る翻訳者でした。本書が示すのは順序の逆転です。足りないのは翻訳者ではなく、共通言語のほうだ。これは個人の努力の話ではなく、組織の道具立ての話でした。
ただ、正直に言えば、翻訳者として走り回っていた過去の私は、優秀に振る舞えば振る舞うほど、組織が共通言語を整備する動機を奪っていたのかもしれません。ボトルネックは組織のほうではなく、翻訳者という立ち位置の中にありました。「共通言語がないから翻訳者が要る」ではなく、「翻訳者がいるから共通言語が整備されない」という順序だった可能性があります。これを書きながら、少しだけ胃のあたりが重くなります。
胃が重くなったついでに、自分がいつからこの席に座っていたのかを、少しだけ遡ってみたくなりました。思い返せば、私が翻訳者の席に座り始めたのは、キャリアの3年目ぐらいの頃です。はっきりした決断があったわけではなく、ある日「ちょっと両側の認識を合わせておいて」と頼まれ、引き受けた。翌週、別の場でまた頼まれた。その次の月には、頼まれる前に自分から両側の会議に顔を出すようになっていました。翻訳者になるという意思決定は、どこにもありません。便利な人を求める場があって、そこに座れる人間が自分しかいないように見えて、気がつくと座っていた。そういう種類の「気がつくと」です。
もっとも、因果の矢印は一方通行ではないのだと思います。「共通言語がないから翻訳者が要る」と「翻訳者がいるから共通言語が整備されない」は、鶏と卵のように互いを強化し合っている。どちらが先かを問うことに、たぶん大した意味はありません。大事なのは、この循環のどこかに一度だけ小さな切れ目を入れられるかどうかです。循環を全部断ち切る必要はない。最初の1箇所だけでいい。
若いエンジニアからすれば、翻訳者が居てくれることは、間違いなく助けです。経営の言葉と設計の言葉をまだ行き来できない段階で、両側の要求を整理してくれる人がいるのはありがたい。翻訳者を全員排除するのは、若手を早すぎる段階で丸投げすることでもあります。だからといって「翻訳者は必要だ」という結論に飛びつきたくもありません。翻訳者を固定化すれば、若手は永遠に翻訳者を頼り続けます。翻訳者は、若手が育つはずだった場所を、毎日少しずつ食べているのかもしれません。
排除も固定化もダメだとすれば、残る発想は「数で押す」ぐらいです。「それなら翻訳者を増やせばいいのでは」という発想も、一度は検討しました。組織ごとに翻訳者を5人に増やせば、待ち時間は1/5になる——計算上はそうです。ところが、翻訳者を増やすほど、翻訳の質を揃えるための会議が増え、翻訳者同士の認識合わせが必要になり、翻訳者チームが小さな縦割りを再生産し始めます。翻訳者の問題は数の問題ではなく、役の構造そのものの問題でした。人数を5倍にしても、問題が5倍になるだけです。
なぜ、それでも翻訳者を辞められなかったのか。正直に言えば、翻訳者でいることには報酬がありました。両側の会議室から「あの人がいれば話が通じる」と言われる安心感。自分がいなければ動かないという、静かな自己効力感。誰にも頼まれていないのに引き受けた役なのに、いつのまにかその役が自分の存在証明になっていました。共通言語が整備されてしまえば、私の翻訳技術は不要になります。そのとき自分に残るものは何か——この問いを、私はずっと避けてきた気がします。翻訳者を辞められない理由は、構造のせいではなく、少なくとも半分は、この問いから目をそらしていたからです。
では、翻訳者を辞めれば組織は動き出すのか。たぶん、そう単純ではありません。翻訳者を引き上げた瞬間に起きるのは、共通言語の整備ではなく、会議の沈黙です。両側の言葉が噛み合わなくなる。プロジェクトはしばらく止まる。辞めるべきだと頭では分かっていても、止まっている時間に耐える覚悟を誰かが持てないと、結局また誰かが翻訳者の席に戻る。構造の問題だと言い切って手を引くのは、正しいようで、少し卑怯です。辞めるかどうかよりも、辞めても組織が動く準備を少しずつ仕込めるかどうか——そちらのほうが、私にできる仕事だったのかもしれません。
辞めても組織が動く準備を仕込む——そう考えていた矢先に、もう1つの問いが重なってきました。辞めるかどうかを悩んでいるあいだに、その席ごと消えるかもしれない、という問いです。生成 AI やエージェントが普及していくなかで、翻訳者の役割は機械に置き換わるのでしょうか。たぶん、半分は置き換わります。議事録の要約、技術用語の言い換え、ドキュメントの相互翻訳——そうした「言葉の変換」は、いずれ十分に自動化されるでしょう。けれども、翻訳者の本当の仕事は、言葉の変換ではなく、場の設計だったと今は思います。誰と誰を同じテーブルに座らせ、どの順番で何を話させるか。どの沈黙を許容し、どの沈黙を破るか。それは言葉の問題ではなく、空気の問題です。AI にできるのは前者だけで、後者はしばらく人間が抱え続けることになる。そしてこの「後者」こそが、本書のキャンバスがやろうとしていることの正体だったのかもしれません。
胸に残った3つの命題
- 地図は、精度ではなく対話のためにある。ウォードリーマップも、境界づけられたコンテキストの図も、チームトポロジーの図も、すべて完璧な描写を目指すものではありません。みんなで一緒に描き、一緒に眺め、一緒に次の一手を決めるための共通の紙切れです。精度を求めすぎると、地図は永遠に完成せず、対話は永遠に始まりません。
- 境界は、防御線ではなく会話の輪郭である。境界づけられたコンテキストを引く目的は、他のチームを締め出すことではありません。内側で同じ言葉を使い、短く正確に会話するために、外側との会話様式を意識的に設計することです。境界があるから、チームは軽くなれる。境界がないとき、チームは全員に気を遣い続けて重くなる。
- 組織図は、アーキテクチャの下書きである。コンウェイの法則を裏返すと、組織図を書くことはそのままアーキテクチャを書くことになります。逆に言えば、アーキテクチャを変えたければ、組織図を先に書き直す必要がある。この関係性を認めた瞬間、組織再編の話は総務の仕事ではなく、エンジニアリングの仕事として立ち上がります。
読む前の3つの悩みへの答え
はじめにで書いた3つの悩みに、いま改めて向き合ってみます。
戦略の言葉と設計の言葉が噛み合わない——この悩みには、キャンバスという物理的な答えが手に入りました。ウォードリーマップでバリューチェーンを描き、その上にサブドメイン分類を重ね、それを境界づけられたコンテキストの設計へとつなげる。戦略の抽象と設計の具体は、同じ一枚のキャンバスの上で初めて出会います。翻訳する役を買って出る必要はありません。同じ道具を使って一緒に描けばいいのです。
チーム構造の議論がコードの形に落ちない——ストリームアラインドチーム／プラットフォームチーム／イネーブリングチーム／コンプリケイテッド・サブシステムチームという4分類と、コラボレーション／X-as-a-Service／ファシリテーティングという3モードが、ついに具体の一歩を用意しました。さらに言えば、チーム構成は「変更ストリーム」という軸で決めるべきで、「既存の技能分布」で決めるべきではありません。この優先順位の逆転が、自分の中では一番大きな変化でした。
レガシーシステムへの処方箋がいつも抽象的すぎる—— Chapter 9 と Chapter 10 が、この悩みに直接答えます。大きな泥だんごを相手にするとき、まず評価すべきはコードではなく、今のチームとフローの阻害要因です。そこから問題ドメインを分類し、境界を設計し、リチーミングパターンを選び、段階的に境界づけられたコンテキストを切り出す。ビッグバンではなく、小さなループの積み重ねで進む。この一連の手順が、「レガシーは怖い」から「レガシーは触れる」へと感覚を書き換えました。
試すこと
自チームのバリューチェーンを1枚描く。完璧は要りません。ユーザーとニーズを2つに絞り、見えている範囲でコンポーネントを縦に並べ、進化段階をざっくり横に振る。20分あれば描けます。足りなければ翌日描き直せばいい。
「何があなたの作業を遅くしているか」をチームに聞く。赤い付箋で阻害要因、緑の付箋で促進要因を集める。30分のインタビューで、次にやるべきことの優先順位が見えてきます。少なくとも、私が頭の中で想像していた優先順位とは違うものが出てくるはずです。
認知負荷を3種類に分けて棚卸しする。課題内在性（本質的な難しさ）、課題外在性（環境由来の余計な複雑さ）、学習関連（新しい領域を学ぶ負荷）。書き出してみると、課題外在性負荷が重い部分が見えてきます。それはプラットフォームに逃がすか、ツーリングで軽くする候補です。
失敗しても、失うのは半日だけです。
正直な留保
もちろん、12章を読んだだけで組織が変わるわけではありません。本書自身が結論で繰り返すとおり、Architecture for Flow は銀の弾丸ではなく、1回きりの大きなイベントでもありません。実際にキャンバスを自分の組織に持ち込もうとすれば、4つの条件がどれも必要になります——経営層が辛抱強く支え続けること、最初に動いてくれる少数の挑戦者がいること、影響を受けるチームを早い段階から巻き込むこと、そして「一気に完成させない」という継続的な覚悟。
そしてこの4つは、ほとんどの組織にとって最初から揃っていません。最初の1枚のキャンバスは、だいたい誰か1人の「これを試してみたい」という個人の衝動から始まります。本書は、その衝動を持った個人に、次の一歩を踏み出すための地図と言語を静かに置いていく本でした。
おわりに
正直に告白すると、12章を読み終えても、私はまだ翻訳者の席から立ち上がっていません。
明日も会議は2つあります。たぶん、戦略会議の言葉と設計会議の言葉は噛み合いません。私はそのあいだに立って、両側の言葉を訳し続けるでしょう。疲れるでしょう。疲れたまま、それでも立ち続けるでしょう。「翻訳者がいるから共通言語が整備されない」と書いたその同じ人間が、明日から翻訳者をやめるわけではないのです。矛盾しているように見えて、矛盾していません。書くことと、明日の自分を変えることは、別の作業です。
ただ、少しだけ、何かが動いた気がします。明日の戦略会議で、誰かが「コア」と言うとき、私は「それは半年後もコアですか」と心の中で問い返すでしょう。明日のレビューで、誰かが「境界」と言うとき、私は「その境界は、分岐させ続ける勇気の問題でもあるな」と思うでしょう。声に出すかは分かりません。たぶん、半分くらいは出します。半分は飲み込みます。
それだけでもいい気がします。気がしているだけかもしれません。
もしあなたが、戦略会議とコードレビューと組織再編の会議を別々のフォルダで管理してきたのなら——あるいは、3つのあいだを翻訳する役として走り回って疲れてきたのなら——本書はたぶん、あなたが次に読むべき1冊です。銀の弾丸は差し出しません。代わりに、良い問いと良い道具と、明日から試せる小さな一歩を、テーブルの上に静かに置いていきます。同じ知的領域を別の角度から描いた『アーキテクチャモダナイゼーション』の日本語版も、すでに書店に並んでいます。2冊を並べて読んだとき、それぞれの本が単独で持っていた輪郭が、少しずつ違って見えてくるはずです。
地図は、描き続けるものです。描き続ける人の手元には、少しずつ、動く組織が残っていきます——たぶん。私はまだ、その「たぶん」の中にいます。まだ、翻訳者の席に座っています。それを自覚しながら、少しずつ椅子を動かしているところです。動かしているつもりです。たぶん。
