意志を実装するアーキテクチャモダナイゼーション

Developers Summit 2026にて「意志を実装するアーキテクチャモダナイゼーション」というタイトルで登壇します。

https://event.shoeisha.jp/devsumi/20260218/session/6454

Transcript

1. 意志を実装する 意志を実装する アーキテクチャ アーキテクチャ モダナイゼーション モダナイゼーション レガシーを競争優位性へ転換する レガシーを競争優位性へ転換する ソシオテクニカルなアプローチ ソシオテクニカルなアプローチ 2026/02/19 Developers Summit 2026 @nwiizo 40min （12:40 〜13:20 ）
2. nwiizo 株式会社スリーシェイクでプロのソフトウェアエンジニアをやっているもので す。格闘技、読書、グラビアが趣味でよく本を紹介しています。 技術書翻訳を手がけるたび、わかることが1 つ増えるのと引き換えに、わからない ことが3 つ増えていく。 インターネット上では nwiizo を名乗り、ブログ「じゃあ、おうちで学べる」を運 営しています。X / GitHub もこのID でやっています。 2
3. about 3-shake 3
4. Sreake のお仕事 クラウドネイティブなアプローチで、お客様の事業をより安全に、競争力のあるサービスへ 提供サービス SRE/DevOps 支援 Kubernetes 構築・運用 クラウドネイティブ化推進 Observability 導入 アーキテクチャモダナイゼーション 現状分析・戦略策定 段階的な移行支援 内製化・伴走支援 データ活用支援 データ基盤構築 BigQuery/Snowflake 分析基盤最適化 ご依頼・ご相談お待ちしております https://sreake.com/ 4
5. We are Hiring!! 3-shake は一緒にSRE 界隈を盛り上げてくれる仲間を大募集中です！ Mobility 、FinTech 、通信など大規模SRE を存分に経験できます 是非、カジュアル面談しましょう！ 5
6. 本日のアジェンダ 1. AI 時代に私たちの仕事はどう変わるのか 2. ソフトウェアと組織を同時に設計する 3. ビジネスを可視化する協働的手法 4. ドメイン駆動設計とチーム設計の統合 5. レガシーを競争優位性へ転換する 6. 意志を実装するということ 6
7. この発表で解決できること こんな悩みを持っていませんか？ レガシーシステムの改善が進まない。技術的な改善と組織の 問題が絡み合っている。AI でコードは書けるが、設計の判断 ができない。 この発表で持ち帰れるもの アーキテクチャモダナイゼーションの全体像、ソシオテクニ カルな視点での設計アプローチ、そして協働的な設計手法 （イベントストーミング等） 。 目標： 「どんな未来を描くか」を考えるための武器を持ち帰る 7
8. この発表の限界 本日紹介する考え方は、すべての現場に当てはまるわけではありません。 文脈によって最適解は変わる スタートアップかエンタープライズか、B2C かB2B か、規制産 業かどうか—— これらによって正解は異なる。 「うちには当て はまらない」と思う部分が必ずある。それは正しい反応。 想定される反論に先に答えておく 「そんな余裕はない」→ 余裕がないからこそ構造を見直す価 値がある。 「うちは小さいから関係ない」→ 小さいうちに考え ておく方が楽。 「理想論だ」→ 理想を知った上で、現実とすり 合わせるのが意志の実装。 正解は存在しない。だが「考え方の型」は存在する。それを持ち帰ってほしい 8
9. 始める前に 事情でレガシーシステムと呼ばれ 敵にされる全てのシステムに敬意を表します。 それらのシステムは、かつて誰かが全力で作り、ビジネスを支え、価値を生み出してきた。 敬意の次に必要なのは責任。 今日書くコードも、いつかレガシーになる。その時に「あの時代の制約の中で、よくここ まで作った」と言われるか、 「なぜこんな設計にしたのか」と言われるか。それを決めるのは今日の選択。 9
10. 1. AI 時代に私たちの仕事は どう変わるのか
11. AI がコードを生成する時代 AI にできること ボイラープレートの生成、パターンに従った実装、既知 の問題の解決。再現可能な作業はAI が得意とする領域。 AI にできないこと（まだ） 「何を作るべきか」の判断、ビジネス固有の文脈理解、 組織や人の問題への対処。正解のない問いには人間が必 要。 Claude Code の登場から1 年。コード生成の精度は上がり続けており、この流れは不可逆で加速する一方だ。 実装力はコモディティ化した。差がつくのは「何をどう作るか」の判断力と、組織を動かす合意形成力になってきた。 参考: Anthropic Claude Code Birthday 11
12. なぜ「決める」ことが難しいのか 「人間が決めるべき」は正論。だが現場では決められていない。 組織構造の問題 プロダクトオーナーは「要件をまとめ る人」 、エンジニアは「言われたことを 作る人」 。 「なぜ作るか」を問う役割が 不在。 心理的な問題 決めると責任が発生する。 「正解がわか らない」から決められない。上位者の 承認を待つ癖がついている。 情報の問題 ビジネス側と技術側で情報が分断。 「何 が可能か」と「何が必要か」が噛み合 わない。判断材料が揃う頃には手遅 れ。 AI がコードを書いても、この構造的問題は解決しない。むしろ露わになる。 12
13. AI は責任を取ることができない（まだ） AI は問いを立てることもできる。答えを出すこともできる。 でも、その結果に責任を取ることはできない。少なくとも今は。 AI ができること 選択肢を提示し、トレードオフを分析し、過去の事例を 参照する。判断材料を揃えることはできる。この能力は 日々向上している。 人間にしかできないこと（まだ） 「これでいく」と決め、結果を引き受け、ステークホル ダーに説明する。最終的な責任を負うことは今のところ 人間だけの仕事。 AI は答えを出せる。だが責任は取れない—— まだ。 13
14. AI エージェントという新しい存在 AI は「対話相手」から「自律的な実行者」へ変わりつつある コード生成、テスト実行、デプロイ、障害対応——AI エージェントが自律的にタスクを遂行する時代が来ている。ただ、これは 新しい話ではない。CI/CD パイプラインも、自動スケーリングも、広い意味では「自律的な実行者」だった。 AI エージェントが変えること タスクの粒度が変わる。 「関数を書いて」から「この機能を実 装して」へ。委任の単位が大きくなるほど、委任する側に求 められる判断力も高くなる。 AI エージェントが変えないこと 「何を作るべきか」の判断、組織間の合意形成、ビジネスの 文脈理解、そして失敗したときに顧客の前に立つ覚悟。これ らは依然として人間の領域。 エージェントが賢くなるほど、委任する側の判断力が問われる 14
15. AI エージェントとの信頼関係を設計する AI エージェントは「わかったふりをする優秀な新人」に似ている 新人に「全権委任」はしない。小さなタスクから任せ、成果を確認し、徐々に委任範囲を広げる。AI エージェントも同じ。哲学 者キャサリン・ホーリーは信頼を「相手がコミットメントを果たすとあてにすること」と定義した。AI には「意図」がないが 「能力」は日々向上している。だからコミットメントを人間が定義し、AI が履行する構造を作る。 すぐに委ねてよいもの 定型的なコード生成、テストの実行と結果の解析、ドキュメ ントの下書き、既知パターンの適用。正解が検証可能な領 域。 いきなり委ねてはいけないもの ドメイン境界の決定、チーム構造の設計、技術的負債の許容 判断、ステークホルダーへの説明。正解が文脈に依存する領 域。ただし「永遠に委ねられない」ではない。 CLAUDE.md やrules ファイルは「暗黙知の形式知化」だ。人間同士なら空気で伝わるものを、AI に伝わる言葉に翻訳する作業。ホ ーリーは「不信に値する相手には不信を」とも説く。適切な不信の設計—— レビュー、テスト、段階的な権限委譲—— こそが鍵に なる。 信頼とは感情ではなく設計。コミットメントを明文化し、履行を検証する仕組みを作れ。 15
16. Harness Engineering 「適切な不信の設計」を技術的に実装するとどうなるか。Birgitta Böckeler （Thoughtworks ）は、AI エージェントが大規模コー ドベースを保守するために必要なツールと慣行の総体をHarness Engineering と呼ぶ。 Context Engineering CLAUDE.md やrules のようなコードベー ス内の知識ベースを継続的に拡充し、AI エージェントに正しい文脈を与える。 前スライドで言う「コミットメントの 明文化」そのもの。 Architectural Constraints カスタムリンター、構造テスト、 ArchUnit などの決定論的な制約でAI の出 力を監視する。LLM の判断だけに頼ら ない。 Garbage Collection ドキュメントの矛盾やアーキテクチャ 制約違反を定期的に検出するエージェ ント。放置すればエントロピーは増大 する。 AI に自由にコードを書かせるな。制約という「馬具（harness ） 」で方向を定めよ。 参考: Harness Engineering - martinfowler.com 16
17. AI が変えるもの、変えないもの 信頼の構造と制御の技術がわかったところで、一歩引いて考えたい。AI の進化で、本当に変わるものは何か。 変わるもの 実装の速度、コード生成のコスト、情報収集の効率、プロト タイピングの手軽さ。要するに「How 」のコストが劇的に下 がる。 変わらないもの コンウェイの法則、認知負荷の限界、組織の慣性、人間の感 情。そして信頼の構築には時間がかかるという事実。コミッ トメントの積み重ねに近道はない。要するに「人間の性質」 は変わらない。 だからこそ、ソシオテクニカルなアプローチの価値はAI が発達するほど高まる。技術側のコストが下がれば下がるほど、ボトルネ ックは「人間の調整コスト」に移動する。AI エージェントが100 倍速くコードを書いても、チーム間の合意形成が3 ヶ月かかるな ら、全体のリードタイムは3 ヶ月のまま。信頼の醸成も、組織の慣性の突破も、AI には代替できない。 AI は「How 」を加速する。だが「What 」と「Why 」は加速しない。ここが今日の出発点。 17
18. 歴史は繰り返す—— 「作れる」と「運用できる」 新しい技術が出るたびに、同じサイクルが回る 「魔法のような技術」に触れる → 「これなら自分たちで作れる」 → 内製する → 運用が回らなくなる → 結局外部に 移行する。クラウド黎明期にもコンテナブームでも、そして今のAI でも、同じことが起きている。 技術の進歩は「作る」コストを劇的に下げる。AI が書いたコードは動く。だが、そのコードを3 年間運用し、法改正に追 従し、セキュリティパッチを当て続け、担当者が退職しても回し続けるコストは下がらない。歴史的教訓を持たない世代 が新技術に触れるたびに同じ興奮を覚え、 「作れた」の興奮と「運用し続けられる」の地味な現実との落差に沈む。組 織・法制度・業務フローは常に変化するため、システムは「完成」しない。作った瞬間から陳腐化が始まる。 「作れること」と「運用できること」の間には、技術では埋まらない溝がある 18
19. エンジニアの仕事の質的シフト AI が「作る」コストを下げ、歴史が「運用は別物」だと教えている。ならばエンジニアの仕事はどこへ向かうのか。 以前 プログラミング言語の構文を理解し、フレームワークの使い 方を覚え、要件を動くコードに変換する。構文エラーを潰 し、ライブラリのAPI を調べ、デバッグに時間を費やす—— 言語と道具を扱えること自体が仕事だった。 これから—— 意志を実装する どんな価値を届けるか（ビジネスへの意志） 、どこに境界を 引くか（アーキテクチャへの意志） 、チームをどう分けるか （組織への意志） 。技術の選択、設計、プロダクトがもたら す価値への責任を負うこと。 「作れる人」は余る。 「何を作り、何を作らないか決められる人」が足りなくなる 19
20. 技術が楽になると、本題が見える 開発コストの低下がもたらす逆説 コーディングが楽になる → 開発のボトルネックが移動する → 「人間の問題」が前面に出てくる。制約理論の考え方 だ。ボトルネックを1 つ解消すると、次のボトルネックが見えてくる。 以前は隠れていた 「技術的負債のせいで遅い」 「レガシーが複雑すぎる」 「リソースが足りない」—— 技術的な言い訳ができた。 今は露わになる 「何を作るか合意できない」 「チーム間の調整が進まな い」 「誰も決められない」—— 人間の問題が見える。 これらは「面倒な雑務」ではない。合意形成、責任境界の設計、組織文化の変革、知識の共有と継承—— ソフトウェア開 発の本質的な難しさであり、AI が発達してもなくならない。 コードが楽に書ける時代、言い訳はもう使えない。これは「面倒」ではなく「本題」 。 20
21. では、どう向き合えばいいのか？ 「人間の問題に向き合う」とは、具体的に何をすることか？ 抽象的な理解だけでは動けない。私たちには実践的なフレームワークと手法が必要。 必要なもの ソフトウェアと組織を同時に設計する方法 ビジネスを協働で可視化する手法 チームの自律性を確保するパターン これから紹介する内容 ソシオテクニカルアーキテクチャ イベントストーミング DDD × Team Topologies 私がこれから紹介するのは、その「面倒な本題」に向き合うための道具。 21
22. 「Architecture Modernization 」という書籍 書籍の概要 著者: Nick Tune, Jean-Georges Perrin レガシーシステムを競争優位性に転換する包括的ガイド ソシオテクニカルな視点を中心に据えた実践書 本書のアプローチ 1. モダナイゼーションの「Why 」を理解する 2. モダンアーキテクチャを「Design 」する 3. 変革を「Execute 」する 22
23. 日本語版が出ました アーキテクチャモダナイゼーション 「何度書き直しても、また遅くなる。 」 — 本書冒頭より 翻訳: 株式会社スリーシェイク（5 名で翻訳しました） 翻訳作業は、扱う用語の範囲が広く、適切な日本語がまだ定まっていない用語も 多くて大変でしたが、やりがいのある仕事でした。 Developer Summit 2026 でサイン会があります！ 23
24. 書籍の構成（17 章） Part 1: Why （理解） Ch.1 アーキテクチャモダナイゼーションとは Ch.2 旅への準備 Ch.3 ビジネス目標 Part 2: Discovery （発見） Ch.4 リスニング＆マッピングツアー Ch.5 Wardley Mapping Ch.6 プロダクトタクソノミー Part 3: Design （設計） Ch.7 イベントストーミング Ch.8-9 ドメイン境界の特定 Part 4: Organization （組織） Ch.10 戦略的IT ポートフォリオ Ch.11 Team Topologies Part 5: Technical （技術） Ch.12-14 疎結合アーキテクチャ、IDP 、Data Mesh Part 6: Execute （実行） Ch.15-17 AMET 、戦略とロードマップ、学習 24
25. モダナイゼーション戦略セレクター Figure 1.10 Identifying the optimal modernization return on investment per subdomain with the Modernization Strategy Selector より引用 「全部作り直す」も「全部残す」も間違い。サブドメインごとにビジ ネス価値と複雑性を測り、どこに投資すれば最もリターンが大きいか を判断する。 この図が示すのは、モダナイゼーションとは技術の問題ではなく投資 判断の問題だということ。限られたリソースをどこに集中させるか —— その意思決定のフレームワークがStrategy Selector である。 25
26. 現代システムの「三体問題」 「技術」 「組織」 「戦略」の3 つが相互に影響し合う 3 つの要素が互いに引力を及ぼし合い、予測不可能な振る舞いをする。どれか1 つだけを変えても、残り2 つが引き戻 す。 技術 アーキテクチャ、コード インフラ、ツール 組織 チーム構造、文化 スキル、コミュニケーション 戦略 ビジネス目標、優先度 投資判断、ロードマップ 3 つの変数に解析解はない。正解を計算するな。小さく動いて観測せよ。 26
27. なぜモダナイゼーションが必要なのか Figure 1.1 Why modernize? より引用 問い：今のシステムを維持し続けて、5 年後も競争できるか？ 私がこの問いを突きつけられたのは、翻訳作業の途中だった。 「改善したい」という意志はある。だが改善の速度が競合に追い越される速 度に負けたら、意志は何の意味も持たない。 優秀なエンジニアは時間の42% を技術的負債に奪われている （Stripe 調査, 2018 ） 27
28. モダナイゼーションの4 つの動機 競争力の維持 市場の変化に追従できない = 淘汰される。競合が3 日で 出す機能を、3 ヶ月かけていては勝てない。 技術的負債の返済 負債は複利で増える。今日の「後で直す」は、来年の 「直せない」になる。 開発者体験の向上 優秀なエンジニアは「成長できない環境」から離れる。 レガシーと戦うだけの日々は、誰も望まない。 ビジネスアジリティ 新機能のリードタイムが長すぎると、市場機会を逃す。 「技術的に難しい」が口癖になっていないか。 あなたの組織の痛みはどれか。まず自社の入り口に名前をつけることから始めよ 28
29. ビジネス目標がすべての起点 Figure 3.2 Aligning architecture modernization with business goals より引用 「技術を新しくしたい」はビジネス目標ではない モダナイゼーションの正当化は、ビジネス目標との整合から始まる。経営層が 理解できる言葉で語れなければ、予算も人も集まらない。 3 つの問い: なぜ今やるのか？やらなかったら何が起きるか？成功したら何が 変わるか？ 29
30. 技術的負債とは何か Ward Cunningham が1992 年に提唱した比喩 将来の変更を困難にする、過去の技術的決定の蓄積。金融の負債と同様に「利子」がつく。ただし金融の負債と違 い、技術的負債は意図せず発生し、残高が不明確なことが多い。 技術的負債の種類 種類 説明 例 対処法 意図的 短期目標のため意識的に受け入れる MVP 優先、後でリファクタ 返済計画を立てて追跡 無意識 知識不足から生じる 設計ミス、ベストプラクティス無視 コードレビュー、学習投資 環境的 外部要因から生じる フレームワークの陳腐化 定期的な依存関係更新 30
31. 技術的負債の複利効果 負債が増える理由 「後で直す」が永遠に来ず、負債の上に負債を重ねる。 ドキュメントは陳腐化し、知識を持つ人は離職する。負 債は複利で増える。 しかも組織・法制度・業務フローは 常に変化するため、何もしなくても負債は増え続ける。 負債の影響 新機能開発が遅延し、バグ修正が困難になり、オンボー ディングコストが増加し、モチベーションが低下する。 全てが悪循環に入る。 AI で新規コードを高速に書いて も、既存の負債が消えるわけではない—— むしろ負債の 上に新しいコードが積み上がり、問題を深くする。 システムは作られた瞬間から老化が始まる。投資し続けなければ、新規開発すらレガシーになる。 31
32. モダナイゼーションの銀の弾丸はない 「でも、マイクロサービスにすれば解決するのでは？」—— この問いに正面から答えたい。 モダナイゼーションは成果が見えにくい。 「マイクロサービス」と言えば経営層にも伝わるし、予算が通る。だがそれ は「ダイエットしたい→ サプリを買う」と同じ構造。本当に必要なのは生活習慣の変革であり、サプリは補助にすぎな い。 失敗パターン 「マイクロサービスにすれば解決」 「クラウドに移行す れば解決」 「AI で全部自動化」—— 手段が目的化してい る。そもそも「レガシー」 「モダン」という主語が大き すぎる。決済システムのレガシーと社内ツールのレガシ ーでは、対処法がまったく違う。 成功のアプローチ ビジネス目標との整合、段階的な改善、組織と技術の同 時変革。目的から逆算する姿勢が必要。バズワード的な 二項対立（ 「〇〇 is Dead 」 「内製 vs 外注」 ）は、多様な 領域を一括りにすることで議論の粒度を下げ、本質を見 失わせる。 説明しやすい嘘より、説明しにくい真実を選べるか。それがリーダーの仕事。 32
33. 「説明しにくい真実」とは何か 経営層に通りにくいが、正しい判断 説明しやすい嘘 説明しにくい真実 「マイクロサービス化に2 年かかります」 「まず半年かけて現状を理解します」 「新しいフレームワークで生産性2 倍」 「今のコードを理解できる人を増やします」 「クラウド移行でコスト30% 削減」 「運用を見直さないと移行しても変わりません」 なぜ「説明しにくい真実」を通すのが難しいか 成果が出るまでに時間がかかり、その間「何をしているか」が外から見えにくい。さらに「やらなかった場合の損失」は証明で きず、競合が「銀の弾丸」で成功したように見えてしまう。 「半年後に失敗するプロジェクト」より「半年かけて基盤を作る」を選べるか 33
34. 見えないコストを見る力 人は「何ができるか」に注目し、 「何を防いでいるか」を軽視する 機能的価値（新機能、画面、API ）は目に見える。非機能要件（セキュリティ、コンプライアンス、可用性、属人化リスク）は 目に見えない。だが、システムの長期的な存続を決めるのは後者のほう。 外部ベンダーへの支払いの正体 「自分たちで作れるのに、なぜ外部に払うのか？」という問 いが出たとき、見落とされているものがある。外部への支払 いには機能だけでなく、リスクと責任の移転という対価が含 まれている。セキュリティアップデート、法令対応、24/365 の運用—— これらを自前で持つコストは、ライセンス費の何 倍にもなりうる。 属人化という静かな爆弾 内製システム最大のリスクは属人化。 「あの人がいないと動か ない」状態は、人の流動性がある組織では時限爆弾になる。 ドキュメントを書いても読まれない。知識が1 人の頭に閉じて いる限り、その人の退職はシステム障害と同義。持続可能性 の観点を欠いた内製は、最も高コストな選択になりうる。 「いくらかかるか」ではなく「何のリスクを誰が引き受けるか」で判断する 34
35. "Success breeds inertia, and the greater the past success, the greater the inertia" — Simon Wardley 成功は惰性を生む。過去の成功が大きいほど、惰性も大きくなる
36. では、判断はどんな情報に基づくべきか？ ここまでの話 AI 時代には「何を作るか」 「なぜ作るか」を決める力が重要になる。技術が楽になると人間の問題がボトルネックとして露わにな り、技術的負債は複利で増えるが銀の弾丸はない。 だが、問いが残る 「判断する」と言っても、判断には情報が要る。技術だけ見ていても全体像は見えない。組織を無視して技術を変えても、組織が 引き戻す。 答えは「技術と組織を同時に見ること」 。次のセクションでは、その視点—— ソシオテクニカル—— を紹介する。 36
37. 2. ソフトウェアと組織を 同時に設計する
38. ソシオテクニカルとは何か Figure 2.1 Sociotechnical architecture より引用 Socio （社会的・組織的）+ Technical （技術的）= ソシオテクニカル 1960 年代にタビストック研究所で生まれた概念。ソフトウェアアーキテクチャ と組織構造は切り離せない。どちらか片方だけを変えても、真のモダナイゼー ションは実現できない。 技術だけ変えても 組織の壁でデプロイが止まる 組織だけ変えても システムの依存関係でチームが自律 できない 38
39. なぜ同時設計ができないのか 「技術と組織を同時に設計すべき」は正しい。だが現実にはできていない。 縦割りの壁 技術はエンジニア、組織は人事・経営 の領域。予算も評価軸も会議体も別々 に動いている。アーキテクチャの議論 に人事を呼ぶ、チーム編成の議論にエ ンジニアが口を出す—— そういう越境 の発想自体がない。結果、技術と組織 がそれぞれ局所最適に走る。 時間軸の違い 技術変更は数週間〜数ヶ月、組織変更 は数ヶ月〜数年。McKinsey （2023 ）の 調査では、デジタル変革の70% が目標 未達であり、最大の原因は「技術と組 織の変革速度の不一致」と報告されて いる。同期が取れないため、どちらか が置いていかれる。 政治的コスト 組織変更は人の感情とキャリアが絡 む。 「あなたのチームを解体します」 「この権限を移譲してください」は、 正しくても言いにくい。提案者自身が 社内の関係性を消耗するリスクを負 う。だから技術だけ変える方が政治的 に安全に見える。 この壁を越える権限がないなら、その権限を獲りに行け 39
40. なぜソシオテクニカルが重要なのか レガシーの問題は、技術だけでなく組織・文化・プロセスに根ざしている。 関連する概念 概念 説明 コンウェイの法則 組織構造がシステム設計に反映される 逆コンウェイ戦略 望ましいアーキテクチャに合わせて組織を設計する 技術だけ変えても組織が追いつかない。組織だけ変えても技術が足を引っ張る 40
41. 翻訳で体験したソシオテクニカル この本を5 人で翻訳した経験は、まさにソシオテクニカルの実験場だった。 技術的な課題 翻訳ツール、用語集の管理、Git での原 稿管理。200 以上のコミットを重ねて品 質を磨いた。 組織的な課題 5 人の「解釈」の違い。同じ英語を違う 日本語に訳す。章をまたぐと整合性が 崩れる。暗黙の前提が異なっていた。 結果として起きたこと ツールだけ揃えても訳文は揃わない。 「同じ言葉を同じ意味で使う」という 組織的合意—— まさにユビキタス言語 —— が必要だった。 5 人のチームでも起きる。あなたのチームでも必ず起きている。見えていないだけだ 41
42. コンウェイの法則 Figure 2.1 Conway's Law より引用 "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations" — Melvin Conway (1968) システムを設計する組織は、その組織のコミュニケーション構造を コピーした設計を生み出すことを余儀なくされる。 疎結合なドメイン境界が、疎結合なアーキテクチャを可能にする チーム構造を変えずにアーキテクチャだけ変えても失敗する 「逆コンウェイ戦略」: 望むアーキテクチャに合わせてチームを編成 する 組織の形がシステムの形になる。これは好むと好まざるとに関わらず 起きる。ならば利用せよ。 42
43. コンウェイの法則が働く理由 「組織を変えずにアーキテクチャだけ変えればいい」—— これが最もよく聞く反論。だが、なぜそれが通用しないのか。 コミュニケーションコスト チーム内の会話は低コストだが、チー ム間は調整・承認・ドキュメントが必 要で高コスト。結果として、高コスト な境界でモジュールが切れる。 責任の分界点 「ここから先は別チームの責任」とい う境界がインターフェース境界にな る。責任が曖昧だと密結合の温床にな る。 暗黙知の共有範囲 チーム内では文脈が共有されるが、チ ーム外には明示的なAPI が必要。共有文 脈の境界がモジュール境界になる。 コンウェイの法則は「選択肢」ではなく「物理法則」 。抗うより利用せよ 43
44. コンウェイの法則を味方にした先に何がある？ 組織とアーキテクチャを揃えたとして、その成功をどう測るか？ 「デプロイ頻度が上がった」だけで満足していいのか。速度だけを追うと、品質・安全性・チームの持続可能性が犠 牲になりかねない。モダナイゼーションの成果には、多面的な物差しが必要。 → Jon Smart が提唱した BVSSH （Better Value Sooner Safer Happier ） フレームワークで、モダナイゼーションの 「本当の成功」を測る 44
45. BVSSH: モダナイゼーションの成果指標 Figure 1.3 Better Value Sooner Safer Happier (Source: Smart et al., Sooner Safer Happier [IT Revolution, 2020]) より引用 Jon Smart が提唱したBVSSH フレームワーク Better — 品質向上、手戻り削減 Value — ビジネス成果 Sooner — 時間短縮 Safer — セキュリティ Happier — 従業員とステークホルダーの満足度 45
46. BVSSH の5 つの指標 「速くなった」だけでは不十分。 Sooner だけ伸ばした結果、品質低下・インシデント3 倍・離職率上昇という事例がある。 指標 危険な兆候 Better 速くなったが品質が下がった Value 機能は増えたが使われない Sooner 頻度は上がったがバグも増えた Safer 速度優先でセキュリティ軽視 Happier 速くなったが燃え尽きた 5 つの指標は互いにトレードオフの関係になり得る。1 つだけ伸ばしても、他が崩れれば全体としては後退する。 46
47. 独立した価値ストリーム (IVS) Figure 1.5 The four key characteristics of an independent value stream より引用 モダンアーキテクチャの基本単位「Independent Value Stream 」 4 つの特性 1. ドメイン整合: 特定のビジネス領域に焦点 2. チーム自律: 製品・技術・デリバリーの決定権 3. 成果志向: 機能数ではなくビジネス成果で測定 4. 疎結合: 独立してデプロイ可能 "Teams aligned to domains become owners of their product's destiny" ドメインに整合したチームは、プロダクトの運命の所有者になる 47
48. IVS の4 つの特性を深掘り ドメイン整合 チームが担当する範囲がビジネスドメインと一致してい る。 「決済チーム」は決済のすべてを知っている。 → 認知負荷の軽減、専門性の深化 チーム自律 技術選定、リリース判断、優先順位付けをチームが決め られる。上位承認を待たない。 → "You build it, you run it" — 責任が信頼性を生む 成果志向 「機能を何個作ったか」ではなく「顧客にどんな価値を 届けたか」で測る。 → 正しいものを作る動機づけ 疎結合 他チームに依頼しなくてもデプロイできる。共有データ ベースや共有ライブラリへの依存が少ない。 → デリバリー速度の向上 48
49. IVS を実現するための条件 IVS は「宣言するだけ」では実現しない 4 つの特性を満たすには、技術的・組織的な前提条件がある。 前提条件のチェックリスト 特性 前提条件 よくある障害 対処法 ドメイン整合 ドメイン境界が明確 曖昧な責任分担 イベントストーミングで可視化 チーム自律 権限委譲の文化 マイクロマネジメント 段階的に権限を委譲、成功体験を積む 成果志向 ビジネス指標の可視化 技術指標だけで評価 OKR でビジネス成果に紐付け 疎結合 API ファースト、CI/CD 共有DB 、モノリス Strangler Fig で段階的に分離 「IVS にしたい」の前に「IVS にできる状態か」を確認する 49
50. リスニングツアー Figure 4.4 A visual summary from a listening tour より引用 組織全体からインサイトを収集する構造化されたアプローチ モダナイゼーションを始める前に、現状を深く理解することが重要。 実施内容 対象者: 開発者、PM 、ビジネスステークホルダー、運用チーム 質問例: 最も痛みを感じている部分は？なぜ変更が難しいのか？ 効果 問題の全体像を把握 組織全体のバイイン（賛同）を獲得 優先順位付けの材料を収集 50
51. リスニングツアーで役割別に質問する 開発者への質問 デプロイ頻度は？ブロッカーは何？ 最も触りたくないコードは？ チーム間の依存で困ることは？ PM への質問 機能リリースのリードタイムは？ 優先順位の変更にどう対応している？ ステークホルダーからの不満は？ ビジネス側への質問 競合に勝てないと感じる領域は？ 「もっと早くできないの？」と思うのは？ 技術チームへの期待と現実のギャップは？ 運用チームへの質問 最も障害が多いシステムは？ 夜間対応が必要になる原因は？ 「直したい」と思っても直せないものは？ 51
52. リスニングツアーで収集した情報を分析する 「聞くこと」自体が変化の始まり リスニングツアーは情報収集だけでなく、 「経営層が現場の声を聞いている」というメッセージになる。これがモダナ イゼーションへのバイイン（賛同）を生む。 収集した情報の整理 分類 内容 次のアクション 痛み 現場が困っていること 優先度の判断材料 願望 「こうなったらいい」 ビジョンの素材 政治 誰が何を守りたいか 障害の予測 知恵 現場ならではの知識 設計への反映 聞いた内容は必ず匿名化して共有する。 「誰が言ったか」ではなく「何が問題か」に焦点を当てる。 52
53. マッピングツアー システムとビジネスの関係を可視化 リスニングツアーで得た情報を整理し、マップとして表現する。 マッピングの対象 技術的マッピング システム間の依存関係 データフロー 技術スタック 組織的マッピング チーム構造 責任範囲 コミュニケーションパス これらのマップが、コンウェイの法則を可視化し、逆コンウェイ戦略の立案に使える。 53
54. マッピングツアーで依存関係を可視化する 「誰が誰に依存しているか」を明らかにする 依存関係を可視化すると、ボトルネックと変更の影響範囲が見えてくる。 描くべきマップ マップ 内容 発見できること システム依存図 どのシステムがどのAPI を呼んでいるか 変更の影響範囲 データフロー図 データがどこからどこへ流れるか ボトルネック、単一障害点 チーム責任マップ どのチームがどのシステムを担当するか オーナーシップの曖昧さ ポイント 完璧を目指さない。80% 正しければ十分 「これは誰に聞けばいいの？」という質問自体が価値ある発見 54
55. マッピングツアーでギャップを発見する 技術マップと組織マップを重ねると、ギャップが見える よくあるギャップ 1 つのシステムを複数チームが触る 1 つのチームが関連のない複数システムを担当 依存先チームとのコミュニケーションパスがない 「誰がオーナーかわからない」システム ギャップが示すこと コンウェイの法則が働いていない箇所 逆コンウェイ戦略で改善できる箇所 モダナイゼーションの優先度が高い領域 完璧なマップは要らない。来週、ホワイトボードに依存関係を1 つ描け。会話が始まる 55
56. プロダクトタクソノミー Figure 6.6 A product taxonomy より引用 製品とサービスを体系的に分類・整理する手法 モダナイゼーションの対象を明確にするために、組織が持つ製品・サービスを 整理。 分類の軸 ビジネス軸 顧客セグメント、収益モデル、市場 での位置づけ 技術軸 技術スタック、アーキテクチャパタ ーン、依存関係 56
57. 地味な仕事こそモダナイゼーションの土台 リスニングツアー、マッピングツアー、プロダクトタクソノミー これらはSNS でバズらない。カンファレンスのトレンドにもならない。 「うちもやってます」とは言いにくい地味な作 業。そして四半期の評価に書きにくい。 派手な施策 「マイクロサービス導入」 「Kubernetes 移行」 「新フレー ムワーク採用」—— 発表しやすい、評価されやすい。 地味だけど重要な作業 現場の声を丁寧に聞く、依存関係を可視化する、製品を 整理・分類する—— 発表しにくいが、土台になる。 派手な技術選定より、地味な現状把握。それがモダナイゼーションの第一歩。 57
58. 逆コンウェイ戦略の実践 望ましいアーキテクチャに合わせて組織を設計する コンウェイの法則を逆手に取る戦略。 ステップ 1. 目標アーキテクチャの定義: 疎結合で独立デプロイ可能な構造 2. 必要なチーム構造の設計: 目標に合わせたチーム境界 3. 段階的な移行: 一度にすべてを変えない 4. 継続的な調整: フィードバックに基づく改善 権限なき責任は拷問。チームに責任を求めるなら、権限もセットで渡せ。 責任だけ押し付けて権限を握り続けるリーダーは、無意識にモダナイゼーションを妨害している 58
59. 構造とプロセスの誤謬 出典: 日経BP 日本経済新聞出版 逆コンウェイ戦略は強力だが、落とし穴がある。組織図を書き換えるだけでは何も変わらない。 よくある失敗 組織図を変えただけ、新しいプロセスを導入し ただけ、ツールを変えただけ—— 形だけ変えて 満足する。 本当に必要なこと 文化の変革、スキルの向上、技術的な改善、継 続的な実践。構造と中身の両方を変える必要が ある。 箱を入れ替えても、中身が同じなら結果は同じ。形だけの変革は変革ではない 59
60. なぜ「構造を変えるだけ」では失敗するのか 宇田川元一著（2024 ） 「構造的無能化」 （宇田川元一） — 組織の断片化が進み、思考の幅と質が制約され、目先の問題解 決を繰り返して疲弊していく現象。成功した大企業ほど陥りやすい。 3 つの症状とモダナイゼーションへの影響 症状 説明 モダナイゼーションへの影響 断片化 分業化しすぎて縦割りに チーム間の壁、サイロ化 不全化 変化を察知して自ら動けない 「誰かが決めてくれる」待ち 表層化 場当たり的な対応しか取れない 銀の弾丸への期待 成功した組織ほどこの罠にはまる。だからこそ、構造を意識的に壊し続ける必要がある 60
61. "Well-designed domain boundaries reduce dependencies and maximize team autonomy" 適切に設計されたドメイン境界は 依存関係を減らし、チームの自律性を最大化する
62. 同時設計をどう実現するか？ ここまでの話でわかったこと 組織とアーキテクチャは同時に設計しなければ、片方が足を引っ張る。コンウェイの法則は物理法則のように避けら れず、独立した価値ストリーム（IVS ）が目指すべき姿である。 だが、暗黙の前提が邪魔をする 組織の中には「言語化されていない前提」が無数にある。アーキテクトが一人で設計書を書いても、現場の暗黙知は反 映されない。ビジネス側に聞いても技術的制約が見えない。 この暗黙知を可視化する手法がある。それがイベントストーミング。 62
63. 3. ビジネスを可視化する 協働的手法
64. イベントストーミングとは Figure 7.1 EventStorming timeline より引用 Alberto Brandolini が考案した、ビジネスドメインを探索するためのワ ークショップ手法。 「正確さより発見を優先する」 という哲学が特 徴。 基本的な要素 付箋の色 意味 オレンジ ドメインイベント（過去形） 青 コマンド（アクション） 黄色 アクター/ ユーザー ピンク 外部システム 濃いピンク ホットスポット（問題） 64
65. イベントストーミングの記法 Figure 7.3 People, systems and hotspots より引用 記法の意味 オレンジの付箋: 過去形で書く「〜された」 青の付箋: 命令形で書く「〜する」 矢印: イベントの流れ、因果関係 ピンクのホットスポット: 曖昧さや問題点をマーク ポイント 最初は「正しさ」を気にせず、とにかく貼り出す。発見は混乱 の中から生まれる。 65
66. イベントストーミングの進め方 Figure 7.1 Big Picture EventStorming より引用 Phase 1: カオス 参加者全員がドメインイベントをオレンジの付箋に書き、時系列 で壁に貼り出す。正しさは問わない。重複も歓迎。この段階では 議論せず、とにかく頭の中にあるものを可視化する。 "Chaos is a feature, not a bug" Phase 2: タイムライン 貼り出されたイベントを左から右へ時間軸で並べ替える。 「この 後に何が起きる？」 「この前に何が必要？」と問い直すことで、 矛盾や抜け漏れが自然に浮かび上がる。 Phase 3: 問題の発見 タイムライン上で「ここがよくわからない」 「ここで揉める」と いう箇所にホットスポット（赤い付箋）を貼る。曖昧さや対立が 集中する場所こそ、改善の最大のチャンス。 Phase 4: 境界の特定 イベントの流れに「切れ目」を探す。言葉遣いが変わる場所、担 当者が変わる場所、ルールが変わる場所—— それが自然なドメイ ン境界であり、サブドメインの輪郭になる。 66
67. イベントストーミングの価値 なぜトップダウンの設計より効果的なのか 多様な視点の統合: 開発者、ドメインエキスパート、UX デザイナーが同じ場に 暗黙知の可視化: ドキュメントには書かれていない知識が浮かび上がる 共通理解の形成: 認識のズレがその場で解消される 設計の民主化: 「アーキテクトだけが知っている」状態を脱却 従来の「アーキテクトが設計して渡す」モデルでは、現場の知識が設計に反映されにくい。イベントストーミングは、設 計プロセス自体を協働的にするという発想の転換。 67
68. 翻訳チームで起きたイベントストーミング 翻訳チームで起きた問題は、イベントストーミングで解決される典型的パターンだった。 暗黙の前提がズレていた 5 人が同じ英語を違う日本語に訳す。 「これはこういう意味だと思っていた」 —— その前提が暗黙のまま放置されて いた。 可視化で解決した 用語集を作り、各章担当者が集まって 認識合わせ。 「この文脈でのこの用語の 意味」を全員で可視化した。イベント ストーミングと同じ原理。 これはBounded Context の実践 「全体で統一」ではなく「境界内で一 貫」 。章ごとに文脈が違うことを認め、 境界を明示した。次のDDD セクション で詳しく説明する。 翻訳で最も難しかったのは英語ではない。著者の思考を追体験することだった。 68
69. 「行間」を翻訳する—— 暗黙知の発見 ドキュメントに書いてあることと、著者が言いたいことは違う。 原著の「行間」を読む必要があった。文脈を知らないと誤訳 する。 「なぜこの章がこの順番なのか」を理解して初めて訳せた。 翻訳の現場 著者Nick Tune が「なぜBounded Context の章をイベントスト ーミングの後に置いたのか」—— その意図を理解しないと、 章の繋ぎが訳せない。 ソフトウェア開発の現場 仕様書に書いてあることと、顧客が欲しいものは違う。既存 コードを読むだけでは設計意図がわからない。 「なぜ」が共有 できているかが品質を決める。 暗黙知を可視化する—— 翻訳でもソフトウェアでも、イベントストーミングの原理は同じ 69
70. イベントストーミングの成果を設計に活かす Figure 8.1 Domain discovery through EventStorming より引用 イベントストーミングで得られたもの ビジネスフローが可視化された ホットスポット（問題箇所）が特定された チーム間の暗黙知が共有された 次の問い: 「この可視化されたビジネスフローを、どうシステム設計に落とし 込むか？」 → DDD の概念（Bounded Context 、コンテキストマッピング）で整理する 70
71. ドメイン境界を発見する Figure 9.1 Well-designed domain boundaries reduce dependencies より引用 境界を定義する原則 「正しい」唯一の境界は存在しない。 境界は組織の目標に奉仕するために 存在する。 一緒に変わるものは、一緒に置く。 変更の波及範囲が境界の外に漏れるな ら、境界の引き方が間違っている。 依存関係のコスト評価 Pain = Strength × Volatility × Distance Strength: 依存の強さ Volatility: 変更頻度 Distance: チーム間の距離 強く依存し、よく変わり、遠いチームとの関係が最もコストが高い。 71
72. Bounded Context とは何か Figure 9.2 Bounded Context and its relationships より引用 問い：システム全体で「顧客」の定義を統一すべきか？ Bounded Context = 同じ言葉が同じ意味を持つ範囲 Eric Evans が2003 年のDDD で提唱した中核概念。この範囲内では、この言葉は この意味という明確な境界線。モデルの適用範囲を限定することで、矛盾なく ドメインを表現できる。 なぜ重要か？ → 同じ言葉でも、文脈によって意味が異なるから。 72
73. なぜ「統一」ではなく「境界」なのか 例： 「顧客」という言葉 コンテキスト 「顧客」の意味 営業 商談中の見込み客（連絡先、商談ステージ） サポート 問い合わせをしてきた人（チケット履歴） 請求 支払い義務のある法人/ 個人（請求先住所） マーケティング セグメント、ペルソナ（行動履歴） これを無視して「統一顧客マスタ」を作ると → あらゆる属性を持つ巨大テーブルになり、変更のたびに全部門に影響。 73
74. Bounded Context が解決する問題 統一モデルの問題 全員の要求を満たそうとして肥大化し、1 箇所の変更が 全体に波及。 「誰のためのモデルか」が曖昧になり、チ ーム間の調整コストが爆発する。 Bounded Context のアプローチ 各コンテキストは必要なモデルだけ持ち、変更が局所化 される。 「このコンテキストの責任者」が明確で、チー ムが自律的に動ける。 Bounded Context は「分断」ではなく「明確化」 。境界を認めることで、かえって連携しやすくなる。 74
75. 翻訳で証明されたBounded Context 翻訳チームで起きた用語論争は、Bounded Context の必要性を身をもって証明した。 例： 「Bounded Context 」の訳語 「境界づけられたコンテキスト」で統一するか、初出のみ日 本語を添えてあとは英語表記にするか。5 人の翻訳者で議論が 割れた。 解決策：用語集で「境界」を引いた 19 の中核用語について「この表記、この意味」を明文化し た。まさに翻訳チーム自体がBounded Context を実践してい た。 Bounded Context は理論ではない。翻訳者5 人の現場で必然的に生まれた解決策だった。 75
76. コンテキストマッピング Figure 9.12 A context map より引用 Bounded Context 同士の連携パターンを可視化する手法（Eric Evans, DDD ） Bounded Context は独立して存在するわけではない。他のコンテキストとど う連携するかを明示的に設計する必要がある。 Team Topologies のインタラクションモードと対応する概念であり、チーム 間の関係性を技術的に表現したもの。 76
77. コンテキストマッピングの代表的なパターン パートナーシップ（Partnership ） 両チームが対等な立場で協力し、互いの成功が相手の成功に依存する関 係。共同で開発計画を立て、API 変更は両者で合意する。 特徴: 調整コストは高いが柔軟性も高い。片方だけが恩恵を受ける関係では 機能しない。 例: 決済チームと注文チームが共同で新機能を開発 カスタマー・サプライヤー（Customer-Supplier ） 上流チーム（サプライヤー）が下流チーム（カスタマー）のニーズに対応す る。下流の要望が上流の優先度に影響を与える。 特徴: 上下関係が明確だが、下流の声が届く仕組みがある。上流が下流を無 視し始めると崩壊する。 例: 基盤チーム（上流）と機能チーム（下流） 順応者（Conformist ） 下流が上流のモデルをそのまま受け入れ、上流に影響を与える力がない場 合に採用。翻訳コストをかける余裕がない、または上流のモデルが十分に 良い場合。 特徴: 実装は簡単だが、上流の変更に振り回される。戦略的に選択すべき。 例: 外部決済API （Stripe 等）をそのまま使う 腐敗防止層（Anti-Corruption Layer ） 外部システムの影響から自チームを守る翻訳層。自分たちのドメインモデル を汚染させないための防御壁。 特徴: 実装コストはかかるが、自律性を確保できる。レガシーシステムとの 統合に有効。 例: 古い基幹システムのデータを変換するアダプター 77
78. コンテキストマッピングで関係性を設計する 「繋がり方」を設計しないと、最悪の形で繋がる Bounded Context を発見しただけでは不十分。コンテキスト間の関係性を意図的に設計しなければ、暗黙の依存関係が 蔓延する。 パターンの選択基準 パターン 採用する状況 避けるべき状況 パートナーシップ 両チームの成功が相互依存 片方だけが恩恵を受ける カスタマー・サプライヤー 明確な上流/ 下流がある 双方向の影響がある 腐敗防止層（ACL ） 外部システムから保護したい 自チームの負担が大きすぎる 境界は自然発生しない。アーキテクトが意志を持って「引く」ものだ 78
79. 境界を守る方法の一つ—— 型システム Scott Wlaschin （猪股健太郎 訳） 『関数型ドメインモデリング』 KADOKAWA, 2024 ここまでの話 イベントストーミングでドメインを発見し、Bounded Context で境界を定義し、コンテ キストマッピングで関係性を設計した。 余談：境界をコードでも守る方法がある ドキュメントに書いても破られる。コードレビューで指摘しても漏れる。そこでコンパ イラに守らせるという選択肢がある。関数型ドメインモデリング（Scott Wlaschin ）が 提唱する Make Illegal States Unrepresentable—— 不正な状態を型レベルで表現不可 能にするアプローチ。 境界は「約束」で守るな。 「型」で守れ。 79
80. "Loosely coupled domain boundaries are not optional—they are essential" 疎結合なドメイン境界はオプションではない。それは必須である
81. 境界をシステムとチームに実装する 境界が見えた。だが見えただけでは意味がない。 イベントストーミングで得られたもの—— ビジネスの全体像、ドメイン境界の候補（Bounded Context ） 、チーム間の 暗黙知、型で境界を守る選択肢。 問いが変わる 「境界に合わせてチームをどう設計するのか？」 Bounded Context とTeam Topologies を対応させ、コンテキストマッピングとインタラクションモードを揃える。DDD とTeam Topologies を統合的に活用する。 81
82. 4. ドメイン駆動設計と チーム設計の統合
83. DDD とTeam Topologies の対応関係 なぜ2 つを統合的に使うのか？ DDD はソフトウェアの境界を定義し、Team Topologies はチームの境界を定義する。両者を一致させることで、コンウ ェイの法則が味方になる。 DDD 概念 Team Topologies 対応 Bounded Context Stream-aligned Team の責任範囲 Core Domain 最も重要なStream-aligned Team Supporting Subdomain Enabling Team / Complicated Subsystem Team Generic Subdomain Platform Team / 外部調達 Context Mapping Team Interaction Modes 「きれいに分離できない」という反論が出る。完全な分離は幻想。依存の方向と強さを制御することが本質 83
84. 戦略的IT ポートフォリオ Figure 10.4 Strategic IT portfolio assessment より引用 すべてのシステムを一律に扱うのは戦略ではない ポートフォリオ全体を俯瞰し、どのシステムに投資し、どのシステムを置 き換え、どのシステムを退役させるかを判断する。Core Domain Chart と 組み合わせることで、投資の優先順位が明確になる。 84
85. Core Domain Chart Figure 10.5 The Core Domain Chart より引用 問い：すべてのドメインに同じリソースを投入すべきか？ 答え：No 。戦略的に投資先を選ぶ必要がある。 分類 差別化 複雑度 投資戦略 Core 高 高 重点投資、内製 Supporting 低 高 効率重視、外部委託も Generic 低 低 購入/SaaS X 軸: ビジネス差別化、Y 軸: モデル複雑度 85
86. Team Topologies とは Figure 11.3 The four team types in Team Topologies より 引用 Matthew Skelton とManuel Pais が提唱。 「高速なフローを持続可能に実現する」た めのチーム設計フレームワーク。 4 つのチームタイプ Stream-aligned — 価値ストリームを End-to-End で担当 Platform — 共通基盤を提供 Complicated Subsystem 高度な専門知識が必要な領域を担当 Enabling — 他チームのスキル向上を 支援 86
87. Stream-aligned チームの設計原則 Stream-aligned チームが「主役」 Team Topologies の核心は、Stream-aligned チームが価値を届けることに集中できるよう、他の3 タイプがサポートする 構造。 Stream-aligned チームに必要な条件 条件 説明 なぜ重要か End-to-End 責任 設計からデプロイまで 他チームへの依存を減らす ビジネス成果へのオーナーシップ 機能数ではなく価値 正しいものを作る動機 認知負荷の限界内 担当範囲が大きすぎない 持続可能なペース 来週、1 つの機能リリースに必要な調整先を数えてみろ。その数があなたの組織の現在地だ 87
88. 3 つのインタラクションモード Figure 11.5 The three interaction modes in Team Topologies より 引用 チーム間の関わり方を明確に定義する Collaboration 高帯域幅での協働。コスト高だが発 見多い。 X-as-a-Service セルフサービスAPI 経由での利用。 Facilitating — Enabling チームが他チームの能力向上を支援 88
89. インタラクションモードの進化 典型的な進化パターン [発見期] [移行期] [成熟期] Collaboration → Facilitating → X-as-a-Service 密な協働 スキル移転 セルフサービス 高コスト 中コスト 低コスト なぜ進化が重要か Collaboration は持続不可能——2 チームが常に密に連携すると両方の速度が落ちる。X-as-a-Service は最初から無理—— 境界が不明確な段階でAPI を固定すると後で苦しむ。Facilitating は橋渡し—— 知識を移転し、自律性を高める。 チーム間の関わり方に「卒業条件」を設定せよ。期限なきCollaboration は共依存になる 89
90. DDD とTeam Topologies の統合 ドメイン境界 = チーム境界 DDD で発見したサブドメインの境界と、Team Topologies で設計するチーム境界を一致させる。これが「逆コンウェイ 戦略」の実践。 統合の効果 認知負荷を最小化し、チームは自分のドメインに集中できる。コンテキストマップでチーム間関係が明確になり、ドメイ ン内の変更は同じチーム内で完結する。ビジネスの成長に合わせてスケーラブルにチームを増やせる。 90
91. 概念の関係性マップ 本日紹介した概念はすべて繋がっている イベントストーミング ──→ Bounded Context の発見 ↓ ┌──────────────┴──────────────┐ ↓ ↓ Core Domain Chart Team Topologies (どこに投資すべきか) (チーム境界の設計) ↓ ↓ Wardley Mapping IVS設計 (進化段階で投資判断) (独立した価値ストリーム) ↓ ↓ └───────────→ 逆コンウェイ戦略 ←───┘ (アーキテクチャ×組織の整合) イベントストーミングで発見し、DDD で分析し、Team Topologies で組織化する 91
92. なぜチーム境界を「小さく」保つのか？ ここまでの話の核心 ドメイン境界＝チーム境界にすることで、自律性と疎結合を実現する でも、チームが担当する範囲が広すぎたら？ 問い：1 チームでどこまでの範囲を担当できるか？ 答えは「認知負荷の限界内」まで。これを超えると、チームは機能しなくなる。 → Team Topologies が「認知負荷」を重視する理由を理解する 92
93. 認知負荷（Cognitive Load ）とは 人間の脳が同時に処理できる情報量には限界がある John Sweller が1988 年に提唱した認知負荷理論に基づく概念。Team Topologies では、チームが担当する範囲を「認知負荷 の限界内」に収めることを重視する。人間のワーキングメモリには限界があり、それを超えるとパフォーマンスが急激に低 下する。 "Cognitive load is the primary constraint" 認知負荷こそがチーム設計における最大の制約 認知負荷の3 種類 種類 説明 対策 Intrinsic （内在性） 問題固有の複雑さ 削減困難。受け入れる Extraneous （外因性） 環境・ツールの複雑さ 削減すべき Germane （関連性） 学習のための負荷 適度に維持 93
94. 認知負荷を管理する プラットフォームチームの役割 開発者体験を向上させ、 「舗装された道」を提供するこ とで、Stream-aligned チームの認知負荷を軽減する。 チーム設計の原則 1 チームが担当する範囲を限定し、依存関係を最小化。 自律的に動ける単位にする。 チームに「何が一番面倒？」と聞け。その答えがExtraneous Load であり、最初に潰すべき標的だ 94
95. 持続可能な高速フロー Team Topologies の核心目標 Team Topologies が追求するのは、短期的なスピードではない。チームが認知負荷に押し潰されず、品質を維持しながら価値を 届け続けられる持続可能なフロー。組織構造そのものを、フローを生む装置として設計する発想にある。 高速なフローを実現するには 組織を整える 承認プロセスを減らし、チーム間の依存を断ち切り、責任範囲を明 確にし、知識をチーム内に閉じる。意思決定の権限をチームに委譲 し、他チームへの問い合わせなしに動ける状態をつくる。フローの 速さは、組織の意思決定速度で決まる。人の流れを速くする。 技術を整える モジュラーなコードベース、チーム専用のデータストア、自動デプ ロイパイプライン、十分なテスト。変更が他チームに波及しない疎 結合な設計にし、コミットからプロダクションまでを1 チームで完結 させる。フローの速さは、技術的独立性で決まる。技術の流れを速 くする。 Accelerate （Forsgren et al., 2018 ）の研究が示した事実：チームの自律性とデリバリー性能は強く相関する 高速フローは組織の健全性を測る物差し—— スプリントで何ポイント消化したかではなく 95
96. なぜチームか 問い：優秀な個人を集めれば、優秀なチームになるか？ 答えは No 。個人のスキルの総和がチームの能力ではない。チームには独自のダイナミクスがあり、それが成果を左右す る。 従来のアプローチの問題 リソース思考 「この人をあのプロジェクトに」—— スキルセットだけで 編成し、個人の専門性に依存する。人を部品として扱う発 想。 なぜ問題か チームの文脈が失われ、暗黙知が継承されず、信頼関係を 毎回再構築。毎回ゼロからスタートになる。 人を「リソース」と呼ぶ組織は、チームを育てられない。名前で呼べ。 96
97. チームファーストの実践 松本成幸『チームの力で組織を動かす』技術評論社, 2025 チームを設計の基本単位として扱う システムを設計するとき、 「どのチームが担当するか」を最初に考える。個人ではなく、 チームの認知負荷・スキル・成長を考慮する。 設計時の考慮 チームの認知負荷を超えない範囲に留め、 依存関係を最小化し、自律的に意思決定で きる単位にする。 運用時の考慮 チームの学習と成長を支援し、長寿命チー ムを維持。チーム間コラボレーションも意 図的に設計する。 「意志を実装する」との関係 チームが自律的に動けなければ、意志は実装できない。チームの自律性を確保することが、 意志を実装する前提条件。 97
98. 疎結合アーキテクチャで自律性を実現する Figure 12.1 Loosely coupled architecture より引用 チームの自律性には、技術的な疎結合が前提 Team Topologies で定義したチーム境界も、システムが密結合のままでは 機能しない。あるチームの変更が別チームのデプロイを止める状況では、 自律性は絵に描いた餅。 疎結合の3 原則: 独立デプロイ可能、障害の伝搬を防ぐ、チーム間の調 整コストを最小化 98
99. チームの自律性を支える基盤 ここまでの話 Stream-aligned チームが価値を届けることに集中するには、認知負荷を軽減する必要がある。では、誰がその負荷を引 き受けるのか？ 答え：プラットフォームチームとIDP （Internal Developer Platform ） 各チームがインフラ、CI/CD 、監視をゼロから作る必要はない。共通基盤として「舗装された道」を提供すれば、チー ムはビジネスロジックに集中できる。 → これがTeam Topologies におけるPlatform Team の役割 99
100. Internal Developer Platform (IDP) Figure 13.1 Golden paths (paved roads) より引用 問い：各チームがインフラ、CI/CD 、監視を個別に作るべきか？ 答え：No 。共通基盤として「舗装された道（Paved Road ） 」を提供す る。 Netflix が提唱した概念で、強制ではなく「この道を通ると楽」という 設計思想。 セルフサービス機能 環境プロビジョニング、CI/CD パ イプライン、モニタリング・ロ グ。必要なものを自分で取得でき る。 ゴールデンパス 推奨されるやり方、テンプレート 提供、ガードレール。迷わず正解 にたどり着ける道。 開発者は「どうやるか」を考えずに「何を作るか」に集中できる。 100
101. "Stream-aligned teams can deliver independently when domains are properly decoupled" ドメインが適切に分離されていれば Stream-aligned チームは独立してデリバリーできる
102. 現実のレガシーとどう向き合うか 設計手法は揃った。しかし現実のレガシーシステムは理論通りにはいかない。 フェーズ 手法 得られるもの 現状理解 リスニング/ マッピングツアー 痛み・願望・政治 可視化 イベントストーミング ビジネスフロー、ホットスポット 境界定義 DDD （Bounded Context ） 責任範囲、連携パターン チーム設計 Team Topologies 自律的なチーム構造 境界の強制 型システム（関数型DDD ） AI が破れない壁 残る問い 道具は揃った。だが目の前には、10 年以上動き続けてきたレガシーシステムがある。これを理論通りにきれいに移行できる のか？ → 段階的・継続的な進化のアプローチへ 102
103. "Legacy architecture is a business liability, not merely a technical problem" レガシーアーキテクチャは単なる技術的問題ではない ビジネス上の負債である
104. 5. レガシーを 競争優位性へ転換する
105. レガシーの本当の問題は現場で起きている 「古いから問題」ではない。 「変化に対応できないから問題」 レガシーシステム自体は悪ではない。問題は、ビジネスが求める速度で変化できないこと。ソフトウェアの価値は初期構築 にではなく、変化への継続的適応にある。だからシステムは「完成」しない—— 作った瞬間から適応の旅が始まる。 あなたの現場で、こんなことが起きていないか？ 開発者が感じる痛み 小さな変更に数週間かかる 「ここを触ると何が壊れるかわからない」 テストがないので怖くて触れない 新しい技術を試す余裕がない ビジネスが感じる痛み 競合は3 日で出す機能が、うちは3 ヶ月 「技術的に難しい」と言われ続ける 見積もりが常に大きく外れる 優秀なエンジニアが辞めていく モグラ叩きをやめろ。構造を変えない限り、問題は永遠に湧き出る。 「構造を変える余裕がない」—— それは構造を変えないことのコストを見えていないだけ 105
106. レガシーの本当の問題は負のサイクルにある Figure 1.1 The negative cycle of declining architecture health より 引用 なぜ問題は悪化し続けるのか？ 1. 変更が困難 → デリバリーが遅れる 2. デリバリーが遅い → ビジネスからの信頼低下 3. 信頼低下 → 投資が減少（ 「どうせ遅いから」 ） 4. 投資減少 → 技術的負債がさらに蓄積 5. 負債の蓄積 → さらに変更が困難に（最初に戻る） このサイクルは自己強化する。放置すればするほど、抜け出すのが難しくな る。 サイクルを断ち切るには、どこかに「くさび」を打つ必要がある 106
107. 負のサイクルを断ち切る「くさび」 5 つのポイントのどこかに介入する サイクル全体を一度に変えることはできない。1 箇所に集中して「くさび」を打つ。 介入ポイントと戦略 介入点 具体的な戦略 難易度 変更の困難さ モジュール化、テスト追加 高（時間がかかる） デリバリー速度 CI/CD 、小さなリリース 中（ツールで支援可能） 信頼低下 可視化、小さな成功の積み重ね 中（コミュニケーション） 投資減少 ビジネス価値の可視化 高（経営層の理解が必要） 負債の蓄積 技術負債の定量化、優先順位付け 中 最初の1 勝が、組織を動かす。小さく勝て。 107
108. 小さな成功が次を呼ぶ 負のサイクルを「正のサイクル」に転換する [負のサイクル] [正のサイクル] 変更困難 → 遅延 → 不信 小さな成功 → 信頼回復 → 投資増加 ↑ ↓ ↑ ↓ 負債蓄積 ← 投資減少 能力向上 ←───── 改善加速 最初の「小さな成功」を選ぶ基準 1. ビジネスに見える成果: 技術者だけが喜ぶ改善は避ける 2. 3 ヶ月以内に達成可能: 長すぎると信頼を失う 3. 再現可能な方法: 一度きりの英雄的行為ではなく、プロセスとして 最初の成功は「証明」のため。2 回目以降は「拡大」のため。 108
109. AMET: モダナイゼーション実行フレームワーク Figure 15.1 AMET: Architecture Modernization Enabling Team より引用 AMET = Architecture Modernization Enabling Team モダナイゼーションを「誰かの片手間」にしない。専任のイネーブリング チームが、組織全体の変革を推進する。 AMET の役割: 技術的な移行計画の策定、チームへのコーチング、組織 横断的な障害の除去。Team Topologies におけるEnabling Team として機 能する。 109
110. 段階的な進化のアプローチ Figure 16.2 Parallel streams of work より引用 モダナイゼーションを「プロジェクト」と呼んだ瞬間、失敗が始ま る。 プロジェクトには終わりがある。だが組織の進化に終わりはな い。 Portfolio-Driven Evolution 発見 → 設計 → デリバリー → 学習 これらが並行して継続的に進む ビッグバンリプレースは失敗する 早期の価値提供 小さな改善を積み重ね、継続的に価値を届ける 学習をフィードバックして計画を調整 110
111. 並行ストリームの実践 4 つのストリームを同時に回す 発見・設計・デリバリー・学習—— これらは順番にやるものではなく、常に並行して走らせる。 各ストリームの活動 ストリーム 活動 成果物 Discovery リスニングツアー、マッピング 現状の可視化、問題の特定 Design イベントストーミング、境界設計 目標アーキテクチャ Delivery 段階的な移行、機能開発 動くソフトウェア Learning 振り返り、メトリクス分析 次のイテレーションへの入力 「設計が終わってから実装」ではない。学びながら設計し、設計しながら実装する。 111
112. Newman が語る「進化的アーキテクト」 Sam Newman, O'Reilly, 2021 Sam Newman は Building Microservices の最終章（Ch.16 "The Evolutionary Architect" ）で、アーキテク トの役割を再定義している。 アーキテクトは「完璧な設計図を描く人」ではなく「変化を可能にする構造を設計する人」 Newman の主張は明快。独立デプロイ可能性こそがマイクロサービスの唯一の本質的価値であり、それが 不要ならモノリスでいい。情報隠蔽と低結合を徹底し、 「知りすぎない」境界を引くことが設計者の最も 重要な仕事。そして最大のスケーリングコストは技術ではなくチーム間の調整コスト。 これは本書Architecture Modernization の「意志を実装する」と同じ構図。Newman 自身もConway's Law を 取り上げ、組織がアーキテクチャを形作ることを前提にチーム設計を語っている。 「進化的アーキテクト」とは「意志を持って構造を選ぶ人」のこと。 完璧な設計は存在しない。変化に耐える設計だけが生き残る。それを選ぶのがアーキテクトの意志。 112
113. 「作らない」の先に何を作るか 車輪の再発明をやめてリソースが浮いた。そのリソースをどこに向けるか？ 「現状維持でよい」は選択肢にない。 効率化には理論的上限があり、効率化だけを価値とするプロダクトは、より安い代替に置き 換えられる運命にある。次の問いは「何に進化させるか」 。 → 記録するだけの仕組みを、洞察を生む仕組みに進化させること。それがモダナイゼーションの真の目的地。 113
114. 記録のシステムから洞察のシステムへ 「代替されない」ことは「現状維持でよい」ことを意味しない 効率化には理論的上限がある。入力を受けて記録するだけの System of Record （記録のシステム）は、いずれコモディティ化 する。効率化だけを価値とするプロダクトは、より安いプロダクトに置き換えられる運命にある。 System of Record データを正確に記録・管理する。ERP や基幹システムの多く がここに位置する。必要不可欠だが、差別化にはならない。 System of Insight 蓄積されたデータから未来を予測し、意思決定を支援する。 「何が起きたか」ではなく「次に何をすべきか」を提示す る。ここに事業の持続的成長がある。 モダナイゼーションの真の目的地は、単にレガシーを新しくすることではない。記録するだけのシステムを、洞察を生むシステム に進化させること。それは技術の入れ替えでは達成できず、ドメイン理解の深さによって決まる。 事業の持続的成長は技術要素ではなく、提供価値の深さによって決まる 114
115. なぜ「意志」が必要なのか モダナイゼーションは「正解を実行する」作業ではない 最適なアーキテクチャ、最適なチーム構造、最適な技術選定—— そんなものは存在しない。あるのは「トレードオフ」と「制約」 と「不確実性」だけ。 誰かに決めてもらうことの危険 ベンダーの「ベストプラクティス」 、コンサルタントの「業界標 準」 、本に書いてある「推奨アプローチ」—— 自社の文脈を無 視した解は機能しない。 意志を持つとは 自社の強み・弱みを理解した上で選び、トレードオフを引き受 ける覚悟を持ち、選択の結果に責任を持つ。文脈を理解した者 だけが正しく選べる。そして「今のままで十分」は意志ではな い。現状維持は緩やかな後退に過ぎない。 「今のままでいい」は意志ではない。緩やかな後退に過ぎない。 115
116. 失敗パターンと成功パターン 失敗パターン 技術だけに注力し組織を無視、ビッグバンリプレース、現場 を巻き込まないトップダウン、銀の弾丸への期待、短期的な 成果を求めすぎる、学習投資の軽視。 成功パターン ソシオテクニカルなアプローチ、段階的・継続的な改善、協 働的な設計プロセス、ビジネス成果との明確な紐づけ、長期 的なコミットメント、学習文化の醸成。 "If leaders are still looking for quick fixes, they don't understand the problem" リーダーがまだ銀の弾丸を探しているなら、問題を理解していない 116
117. "Modularization is not just about code—it's about enabling business agility" モジュール化は単なるコードの話ではない ビジネスのアジリティを実現することだ
118. 旅を振り返る たどってきた道 — 「意志を実装する」ための5 つのステップ ステップ 内容 意志との関係 1. AI 時代 AI が「How 」を加速、人間は「What 」 「Why 」へ 意志の必要性を理解 2. ソシオテクニカル 技術と組織を同時に設計 意志の対象を理解 3. 協働的手法 イベントストーミングでドメインを発見 意志を言語化する 4. DDD × TT 境界を揃えて自律的チームへ 意志を構造化する 5. レガシー脱却 段階的・継続的に進化 意志を実行する 道具は揃っている。足りないのは「この組織をどうしたいか」という意志だけ。 118
119. 6. 意志を実装するということ
120. 翻訳者として伝えたいこと この本を訳しながら、私はずっと考えていました。なぜ同じ失敗が繰り返されるのか。なぜ「正しいこと」を知っている 人がたくさんいるのに、組織は変われないのか。 私の結論はこうです。モダナイゼーションの本質は、完成形を目指すことではない。変化し続ける能力を組織に埋め込む こと。 技術を一新しても、変化に対応し続ける文化がなければ、またレガシーに戻る。逆に、変化し続ける構造があれば、技術 は後からついてくる。問題は技術ではなく、組織が変化を受け入れる仕組みを持っているかどうか。 120
121. 本日のまとめ—— 意志を実装するとは AI がHow のコストを下げた結果、ボトルネックは人間の調整に移った。モダナイゼーションは「負債を返す」作業ではない。変 化し続ける能力を組織に埋め込む作業。冒頭で定義した「3 つの意志」に何が見えたか。 ビジネスへの意志 Core Domain に集中し、Generic Subdomain は外部に任せる。 → イベントストーミング、Core Domain Chart アーキテクチャへの意志 Bounded Context で境界を定義し、コ ンテキストマッピングで関係を設計す る。 → DDD 、Strangler Fig 、IDP 組織への意志 逆コンウェイ戦略でドメイン境界＝チ ーム境界にし、認知負荷の限界内で設 計する。 → Team Topologies 、IVS 持ち帰るべきは手法ではない。 「自分の組織をどうしたいか」という問いだ。 121
122. AI 時代に「意志」はどう変わるか 「AI がいずれWhat やWhy も判断するのでは？」—— 最もよく受ける質問に答えたい。 仮にそうなったとしても、その判断を採用する責任は人間にしかない。AI が「このドメインは内製を縮小すべき」と提案して も、その結果としてチームの仕事が減り、売上が伸びず、メンバーの給与が上がらなくなる—— その責任をAI は取らない。意志 とは判断することではなく、判断の結果を引き受ける覚悟のこと。 AI エージェントがいる世界の落とし穴 「作れるから作る」が加速する。コストが低いから、考えず に試す。結果、方向性なき大量生産に陥る。技術的負債も倍 速で溜まる。 だからこそ「意志」が要る 何を作らないかを決める力、どこに境界を引くかの判断、組 織の方向性を定める覚悟。AI が速く走れるからこそ、人間が ハンドルを握る意味がある。 速く走れるマシンほど、操縦者の判断が生死を分ける 122
123. 今日から始められること 来週やること（30 分で終わる） チームの定例で「最も変更が怖いコード」を1 つ挙げる。怖い 理由を付箋に書き出す。技術の問題（テストがない、依存が複 雑）か、組織の問題（担当者が不明、承認が必要）かを仕分け る。仕分け結果がモダナイゼーションの出発点になる。 来月やること（意思決定の棚卸し） 「誰かが決めてくれるのを待っている」案件を1 つ特定する。 「なぜ決まらないのか」を3 つの観点で書き出す—— 権限がな い、情報がない、合意できない。そのうち自分で動かせるもの から着手する。全部は無理でも、1 つ動かすだけで景色が変わ る。 123
124. 本日、夕方からイベントがあります 3-shake SRE Tech Talk 特別回 アーキテクチャモダナイゼーション レガシーシステムを競争優位性に転換するための包括的ガイド。ソシオテ クニカルな視点、イベントストーミング、DDD 、Team Topologies など、 本セッションで紹介した内容をより深く学べます。 https://3-shake.connpass.com/event/382086/ 124
125. 参考資料 Architecture Modernization - Nick Tune, Jean-Georges Perrin （Manning, 2024 ） アーキテクチャモダナイゼーション - 日本語版、株式会社スリーシェイク訳 Team Topologies - Matthew Skelton, Manuel Pais （IT Revolution, 2019 ） チームの力で組織を動かす - 松本成幸（技術評論社, 2025 ） 企業変革のジレンマ - 宇田川元一（日経BP, 2024 ） Building Microservices, 2nd Edition - Sam Newman （O'Reilly, 2021 ） Domain-Driven Design - Eric Evans （Addison-Wesley, 2003 ） 関数型ドメインモデリング - Scott Wlaschin （KADOKAWA, 2025 ） EventStorming - Alberto Brandolini Sooner Safer Happier - Jon Smart （IT Revolution, 2020 ） 現代システムの三体問題 - Architecture Modernization 読書感想文 関数型ドメインモデリング 読書感想文 信頼と不信の哲学入門 - キャサリン・ホーリー（岩波新書, 2024 ） 125
126. ありがとうございました ありがとうございました ご質問・ご相談はお気軽にお問い合わせください ご質問・ご相談はお気軽にお問い合わせください @nwiizo | https://3-shake.com