Share
Embed
Slide 1
Slide 1 text
アーキテクチャと組織の相互作用について
モジュラモノリス導入から4年間の総括
2026/3/21 PHPerKaigi 2026
Slide 2
Slide 2 text
自己紹介
BASE Inc.
TechLead
川島 慧(@nazonohito51)
2
Slide 3
Slide 3 text
前置き
3
Slide 4
Slide 4 text
前回の発表（４年前）
4
https://speakerdeck.com/nazonohito51/base-rearchitecturing
Slide 5
Slide 5 text
発表の目的
5
この発表の目的
● ４年間の実践を通して、4年前の意思決定の「答え合わせ」を行う
● 設計論と現実の間で発生する摩擦の正体について、組織とアーキテクチャの間に働く「力
学」の分析という形で、一個人の見解を述べる
この発表のアプローチ
● 単一事例（BASE）を、一般化された書籍の概念というレンズを通して解釈し、1事例の中
にある構造の一般化を試みる
● ４年間の間に発生した問題から、そもそもアーキテクチャが解決しなきゃいけない課題は
なんだったのかを抽出し、その上で答え合わせを行う
○ ※ 「過度な一般化」と受け取られうることは自覚しています。
持ち帰ってほしいこと
● 理論と現実の間にある差分の正体を正確に掴むことで、各自の所属する企業の組織図・
アーキテクチャの助けにしてほしい
Slide 6
Slide 6 text
発表者の立場について
発表者視点での発表です
●BASEのアーキテクトとして、意思決定に関与している箇所と関与していない箇所がある
●関与していない意思決定については、発表者視点の分析・解釈であり、当人の意図と食い
違う部分があるかもしれない
ハイコンテキストな発表です
●多くの書籍・概念（DDD・チームトポロジー・Accelerate等）を引用するが、それらにつ
いて深くは言及しない
●そもそも量自体が多いスライドなので、アップロードされたものをAIに要約させることを
推奨
6
Slide 7
Slide 7 text
この発表でやること・やらないこと
やること
●４年前の意思決定の答え合わせ
●4年間の事実を根拠に「設計論と現実の間にある障壁」を分析する
やらないこと
●モジュラモノリスの実装詳細や技術的tipsの紹介
●リアーキテクチャの具体的な実施方法
7
Slide 8
Slide 8 text
1. 4年前のリアーキテクチャ方針と想定
8
Slide 9
Slide 9 text
なぜリアーキテクチャを始めたか
●成長するプロダクト・組織・システムの中で、生産性を継続的に維持するため
9
Slide 10
Slide 10 text
リアーキテクチャの方針
10
Slide 11
Slide 11 text
リアーキテクチャの方針
11
Slide 12
Slide 12 text
12
組織構造とアーキテクチャを一致させる
Slide 13
Slide 13 text
目指す組織の姿
目指したのは「分散自律型の組織」
組織全体の目的や戦略のもとで、各チームが自ら意思決定し、独立して学習と改善を継続で
きるように設計されたアーキテクチャ
自律したチームを基本として、それが独立して作業可能なアーキテクチャを用意すること
で、組織全体の生産性に寄与しようとしていた
13
Slide 14
Slide 14 text
なぜモジュラモノリスを選んだか
MSAは理想的だったが、リスクが大きかった
●分散システムの複雑さ（ネットワーク障害・整合性・デプロイ複雑度）
●境界線の定義が難しく、間違えたときの手戻りコストが高い
●当時の組織・技術力に対して、飛躍が大きすぎた
モジュラモノリスを選んだ理由
●MSAと同様のモジュール分離メリットを持つ
●境界線の手戻りが低コストでできる
○ 間違えても直しやすい。意思決定を遅らせられる。
●漸進的にMSAへ向かえる中間地点として機能する
14
Slide 15
Slide 15 text
クリーンアーキテクチャ＋モジュラモノリスの合わせ技
Infrastructure
Interface
Use Case
Domain
クリーンアーキテクチャ
＋
商品
Catalog
注文
Order
決済
Payment
ユーザー
User
配送
Shipping
Shop
管理
プロモ
Promo
決算
Settlement
…
モジュラモノリス（モジュール群）
各モジュールはクリーンアーキテクチャの構造を持つ。
15
※図はイメージです
Slide 16
Slide 16 text
1モジュール＝1境界づけられたコンテキスト
モジュール（コード上の分割単位） ＝ 境界づけられたコンテキスト（概念上の境
界）
Catalog モジュール ＝ 商品カタログコンテキスト
Order モジュール ＝ 注文コンテキスト
Payment モジュール ＝ 決済コンテキスト
User モジュール ＝ ユーザーコンテキスト
モジュール境界 ＝ ドメインモデルの境界。1モジュールが1つの境界づけられたコンテキストを持つ。
16
※図はイメージです
Slide 17
Slide 17 text
当時の組織とモジュールの責任の紐づき
当時は目的別組織と呼ばれる組織体制で、
事業戦略単位でチームが分かれ、
各チームが特定のモジュール群を占有する状態を目指していた。
エンジニア人数はおおよそ１００人近く（サービス開発・基盤技術・品質保証など全部門含む）
17
※図はイメージです
Slide 18
Slide 18 text
当時の前提
前提①：目的別組織がある程度続く
●組織図にある程度合わせてモジュールを設計した
●チームとモジュールの対応関係がある程度の期間は安定する想定だった
前提②：チームがモジュールを占有すれば自走できる
●技術的な意思決定者が自明であれば自律進化するであろう、という想定
●占有によって責任を自明にすれば、チームが自律的にPDCAを回せると考えた
この2つの前提は、すぐに大きく崩れていくことになる。
18
Slide 19
Slide 19 text
2. ４年間の変遷
19
Slide 20
Slide 20 text
組織の変遷——3つのフェーズ
〜2024年
目的別組織
チームA
Catalog/Order
チームB
Payment/User
チームC
Shipping/…
固定メンバー・固定ドメイン
モジュールを各チームが占有
2024年〜
横断開発型組織
＋コアドメインチーム
横断チームA
横断チームB
コアドメインチーム
全チームが全ドメインを横断
コアドメインのみ専門チームが守る
2026年〜
セクション制組織
セクションA
専門チーム
セクションB
専門チーム
セクションC
専門チーム
各セクションに専門チーム
20
※図はイメージです
Slide 21
Slide 21 text
目的別組織の廃止
いくつかの問題が積み重なったため
● サイロ化
○ 担当ドメインへの専門性が高まる反面、視野の狭まり・他ドメインへの無関心化・越境しづらさが生まれた
●環境への固執
○ 固定メンバー・固定ドメインの開発は安定したベロシティには繋がったが、同一環境への固執やマンネリを招
いた
●プロセス成熟度の上限
○ スクラム開発を取り入れ始めた時期でプロセスは一定成熟したが、進化への停滞が見えてきた（80点→100点
が遠い）
●負荷の偏り
○ 特別忙しいチームとそこまで忙しくないチームが同時に存在している
21
Slide 22
Slide 22 text
２０２４年〜横断機能開発組織の開始
●全てのチームが全てのモジュールを触る、という組織設計
○ 全員が担当領域を持たない
●開発PJへのエンジニアの割当を柔軟に行う
○ 成長への期待も加味した形でのアサイン
○ マンネリ感の打破
○ 負荷が特定のチームに偏らないように分散
○ ただしチーム内部はある程度固定で、一緒に働く顔ぶれをあまり動かさない
●→ デリバリーの速さに注力しつつ、これとは別にコアドメインと呼ばれるモジュールには
占有チームを配置
22
Slide 23
Slide 23 text
コアドメインチームの新設
なぜ作ったか
●事業競争力の源泉となるコアドメインを守り育てる占有チーム
●横断機能開発チームとは違い、コアドメインのみを扱い、継続改善（安定）を担う
○ 「速さ（デリバリー）」と「安定（コアの継続改善）」の役割分担
○ 横断機能開発チームのコアドメイン改修時の負荷を減らせるようにサポートする
●モジュラモノリスへの機能移行を継続的に行うため
● 旧システムに残ったままの機能を移行することで、新システム（モジュラモノリス）上だけでの開発作業を実
現するため
23
Slide 24
Slide 24 text
２０２６年セクション制へ——
何が変わったか
●コアドメインと呼ぶ範囲を広げて3つとし、それぞれに占有チームを配置
○ コアドメインを見る占有チームをそれぞれセクションと呼ぶ
○ ただしセクションに配置されないチームは存在しないので、実質全チームが何かしらの
モジュールを占有している状態
●軸足を「挑戦と機動力」から「専門性と持続性」へと移した
各セクションの専門チームの役割
●アンコントローラブルな問い合わせ対応を定常的に減らす
●それぞれのドメインでPDCAを回して科学する
●「誰に聞けばいいかが自明な体制」の実現
ぱっと見はリアーキテクチャ開始当時に目指していた組織の姿
——が、実態は少し違う（後半で言及します）
24
Slide 25
Slide 25 text
２０２６年３月現在の開発現場
●ほとんどの開発PJは新アーキテクチャ上で行われるようになった
○ 旧システムのうち重要なものは新システムへ移行完了した
○ 開発者のオンボーディングはまだ途中だがある程度は達成された
●リアーキテクチャ活動自体が縮小傾向で、おおむね完遂した扱い
25
Slide 26
Slide 26 text
４年間の中で取り上げたい事象
組織図は高頻度に更新され続けた
●少し変わる、ではなく、大幅に変わった
●アーキテクチャが組織図に追従するのは困難だった
コアドメインチームが運用改善を自律的にかなりやってくれた
●担当しているモジュールの土地勘（メンタルモデル）があるため、障害対応も速くPDCAを
回しやすかった
ほぼすべての開発PJで複数モジュールをまたいだ改修が行われた
●1モジュールで作業が完結するケースはほぼ無かった
26
Slide 27
Slide 27 text
４年間の中で取り上げたい事象
コアドメインチームへの依頼が積み重なり続けた
●コアドメインを改修しないといけない開発PJが多発した
●「そのモジュールを変えたいが、コアドメインチームに調整が必要」という状況がそれな
りの頻度で繰り返された
継続的なリファクタリングはほとんど実施されなかった
●開発要求への対応が優先され、設計の改善は後回しになり続けた
○ そのモジュール領域を「守る」ことに対するインセンティブが少なかった
●コアドメインでも、土地勘があるからこそ逆にツギハギのパッチワークが出来てしまう、
という占有してるからこそ逆説的に改善しなくてもいい、という事象が発生したように見
える
27
Slide 28
Slide 28 text
４年間の中で取り上げたい事象
過剰なプラットフォームエンジニアリング
●理由は後に触れるが、発表者の所属するプラットフォームチームが共通基盤技術を、個人
的には過剰に供給していたように思える
●「占有チームが独自に設計判断が出来る」という建付けのはずが、いつの間にか特定の作
り方しか出来ない、みたいな矛盾した環境に少しずつ近づいていた
28
Slide 29
Slide 29 text
４年間の変遷を振り返って
● 組織図の大胆な変更を含めて、現実的にリアーキテクチャ当初の自律分散的な組織からは
は程遠い４年間だったように思える
○ 今年のセクション制からは当初の想定に近しい状態になった
● ただし先程取り上げた事象は、実は組織図の変更や各チームの意識とかインセンティブ構
造とか、それ自体が原因ではなく、もっと奥にアーキテクチャと組織図の関係において決
定的な力学を見逃していたように思える
○ 世の中で良いとされる方法にはなるべく沿ろうとしていたが、それらの方法論を組み合
わせた場合にのみ発生する摩擦のような何か
○ 全ての震源地はそこにあるという予測
● ３章ではその仮説を提起する
29
Slide 30
Slide 30 text
3. 事象から読み取る仮説の提起
30
Slide 31
Slide 31 text
仮説の提起：
顧客価値検証と分散自律改善は
両立できないのではないか？
31
Slide 32
Slide 32 text
この4年間で起きたことの根本にある「からくり」
仮説を先に書くと、
顧客価値検証を最大化するための組織と、
分散自律改善を最大化するための組織は、
両立できないのではないか？
これが、4年間に起きたことの事象の震源地で、
この２つの組織図の根源にある
バリューストリームと境界づけられたコンテキストは、
噛み合わないのではないか？
32
Slide 33
Slide 33 text
この4年間で起きたことの根本にある「からくり」
弊社はリーン思考・アジャイル・DevOps・ドメイン駆動設計（以下DDD）・マイクロサー
ビス・エンジニアリング組織論への招待・チームトポロジー・LeanとDevOpsの科学などの
不確実性の高い市場環境に適応するための種々の考え方を（アーキテクト視点では）比較的
誠実に参照していたように見える。
しかし——
●バリューストリームが志向する組織の姿
●境界づけられたコンテキストが志向する組織の姿
この2つは、突き詰めれば、矛盾するように見える。
33
※ただしプラットフォーム型ビジネスでかつ組織規模がある程度大きい場合に限られる
Slide 34
Slide 34 text
この4年間で起きたことの根本にある「からくり」
先に訂正すると、
バリューストリームと境界づけられたコンテキストは
そもそもまったく別のレイヤーの概念なので混ぜるべきではない
ただしこれらは突き詰めると組織構造へ還元されていく概念であるため、
今回同じ俎上に上げている
34
Slide 35
Slide 35 text
弊社での観察——仮説を支える事実
●組織図は高頻度で変更され続けた
●ほとんどの開発PJは複数のモジュール境界をまたいでいた
●コアドメインチームへの依頼が発生し続けた
●コアドメインを改修しないといけない開発PJが多発した
●継続的なリファクタリングはほとんど実施されなかった
●過剰なプラットフォームエンジニアリング
これらはランダムな事象ではなく、同じ力学が繰り返し現れた結果ではないか？
35
Slide 36
Slide 36 text
なぜズレるのか——
原典に立ち返って整理する
36
Slide 37
Slide 37 text
バリューストリームとは
原典はリーン思考（Lean Thinking）
これ自体は顧客に価値を届けるための一連の活動を可視化したもの
目的は価値提供速度を阻害するムダを発見し、無くすこと
37
Slide 38
Slide 38 text
バリューストリームが解決しようとしていたこと
リーン思考・アジャイル・DevOpsの文脈
●リーン思考で製造業の「流れ」のムダ（待ち・手戻り）を排除するために生まれた
○ 後にソフトウェア開発の世界にこの概念が持ち込まれた
●アジャイルがフォーカスしたのは「目的不確実性の解消速度」
○ 何を作るかが不確かな状況で、リリースを増やしてフィードバックを速く回す
●DevOpsがフォーカスしたのは「デリバリーの流れの最適化」
○ 開発から本番投入までの流れを詰まらせない、待ちをなくす
共通する関心
顧客への価値の流れを速く・止めずに届けること。そのための組織・プロセスを設計する
こと。
38
Slide 39
Slide 39 text
境界づけられたコンテキストとは
原典はドメイン駆動設計
ドメインモデルの意味境界を表す単位であり、モデルの整合性を保証する範囲である
基本的にはビジネス上の関心の違いから引かれる
39
Slide 40
Slide 40 text
境界づけられたコンテキストが解決しようとしていた
こと
DDD・マイクロサービスの文脈
●大規模なドメインモデルは、文脈によって同じ言葉が違う意味を持つ
○ 「商品」はBuyerにとっては「欲しいもの」、Sellerにとっては「売りもの」、決済にとっては「金額のある
何か」
●境界づけられたコンテキストは「モデルが一貫して正しい範囲」を定義する
○ その境界の中では、言葉の意味が統一され、モデルの整合性が保たれる
●マイクロサービスはこの境界をサービス分割の単位として採用されがち
○ チームがコンテキストを占有することで、自律的に設計改善できる
40
Slide 41
Slide 41 text
バリューストリームに最適化された組織と
境界づけられたコンテキストに最適化された組織
41
Slide 42
Slide 42 text
組織図に少なくとも2つの最適化軸がある
バリューストリーム最適
●「1チームが単独で1つのバリューストリームを完遂できる」が理想
境界づけられたコンテキスト最適
●「チームが境界づけられたコンテキストを占有して改善し続ける」が理想
42
Slide 43
Slide 43 text
バリューストリームに最適化された組織
●「1チームが単独で1つのバリューストリームを完遂できる」が理想
○ 何故ならばチーム間の調整は価値提供活動の上では「ムダ」だから
●１チームが企画〜リリースまでに必要な能力と権限を有することで、チーム間の調整なく
単独で完遂が可能になる
○ 職能横断型チームであり、必要なスキルを全て持っている
○ 改修対象のシステムに対して技術的な意思決定・実装・リリースを行う権限を持ってい
る
43
Slide 44
Slide 44 text
バリューストリームに最適化された組織
●※弊社の経験則ではあるが
○ アクターごとにチームが分かれやすい
○ カスタマージャーニーで定義される比較的広い範囲のシステムを都度改修しやすい
44
Slide 45
Slide 45 text
バリューストリームに最適化された組織
●何故ならばバリューストリームとカスタマージャーニーは「顧客の価値」という単位で接
続されるため
○ バリューストリーム：顧客に価値を届ける社内の活動
○ カスタマージャーニー：顧客が価値を得る一連のプロセス
■ 例えばECプラットフォームでSellerは、商品を出品するだけでは価値を得られない
● 商品を出品し、Buyerから受注し、注文を発送処理して、売上を獲得する、までが価
値を得る最小のジャーニーである
● １回の開発PJでこれより改修範囲が狭くなることはあまりない
45
Slide 46
Slide 46 text
バリューストリームに最適化された組織
● バリューストリームに最適化された組織≒カスタマージャーニーに沿った組織、とも言え
るので、
○ 価値を提供しようとする相手＝アクター単位で分かれやすい
○ カスタマージャーニーへの改修＝１回の開発PJで広いシステム範囲への改修
● となる
46
Slide 47
Slide 47 text
境界づけられたコンテキスト最適
● 「チームが境界づけられたコンテキストを占有して改善し続ける」が理想
○ 何故ならば自律改善の速度に最も有利なため
■ 大きく分けてDDD文脈におけるメリットと、マイクロサービス文脈におけるメリットが
有る
47
※念のため訂正すると、
「境界づけられたコンテキスト」原典のDDDでは占有についてそれほど語っていない
占有を主張しているのはどちらかといえばマイクロサービス・DevOps文脈である
Slide 48
Slide 48 text
境界づけられたコンテキスト最適
● DDD文脈でのメリット
○ ドメインモデルの継続的な改善
■ ドメインモデルに完成はないので、次々発生する改修の中で一貫性を保ち続けるには継
続的なモデルとコードの見直しが必要
■ ドメインモデル自体が占有チームにおけるドメインの「解釈」なので、共有資産化して
みんなで編集、とかは少し難しい側面もあるかもしれない
● マイクロサービス文脈でのメリット
○ 技術的な意思決定の高速化
■ 現場にいる人間が必要なものを一番理解しているはず、という前提の元、現場のチーム
が意思決定できる
○ 運用責任の明確化
■ 開発と運用のインセンティブの違いを乗り越えるため、「作った人が運用する（You
build it, you run it）」
48
Slide 49
Slide 49 text
境界づけられたコンテキスト最適
● 開発と運用はインセンティブが異なり、両者の溝を超えるには「作った人が運用する
（You build it, you run it）」必要がある
● 開発は現状を変更する活動であり、運用は現状を安定的に維持する活動であり、両者のイ
ンセンティブ構造は決して相容れない
○ 開発と運用の人間が分かれると合意形成には凄まじいコストがかかるため、外部との調
整を要さずに独自に意思決定し、その運用責任を本人が果たす、という組織的な枠組み
が必要になる
49
開発
（現状変更）
運用
（現状維持）
「こうすれば早くリリースできる」
「新しい技術を試したい」
「問題起こったらどうするんだ」
「俺はそんなのメンテナンスできない」
Slide 50
Slide 50 text
境界づけられたコンテキスト最適
● 根本的には「知識の蓄積先」としてチームに占有させる、という表現が近い
○ ドメインモデルが表現しようとしているドメイン知識
○ 長期でしか結果がわからないような技術的な意思決定の経緯
● これらの知識のほとんどをチーム内の暗黙知として保持できてしまう
○ 形式知化のコストを払わずに高速で意思決定できる
● 知識に基づく意思決定の結果責任は自分たちにしかないからチーム間調整も不要
○ だから継続的に改善・進化ができる、という建付け
50
Slide 51
Slide 51 text
● 似てはいる
○ 「外部との調整をゼロにしたい」という願いが一致している
○ オーナーシップによるパフォーマンス向上を信じている
○ 境界線を引くことで複雑さを解決しようとしている
● 要するに自律チーム中心的な組織を志している点において両者は一致している
２つの比較
51
Slide 52
Slide 52 text
２つの最適化は何故噛み合わないのか
52
Slide 53
Slide 53 text
最も理想的な組織図
●１バリューストリーム＝１境界づけられたコンテキスト＝１チームが最も理想的ではある
○ １つのチームが複数担当してもいいので、少なくとも１：Nでマッピング可能なら良い
■ 例：Sellerの販売バリューストリーム：出品・販売・注文・売上（合計４）コンテキス
ト：１チームなど
● しかし少なくともプラットフォーム型ビジネスモデルにおいて、巨大・複雑化していくと
これは成立しなくなっていく、と考えている
53
Slide 54
Slide 54 text
単純な衝突例
●たとえばECプラットフォームにおける「注文」を例題に上げる
ドメインモデル上の整理
● 「注文」＝SellerとBuyerの間でかわされた取引、すなわち約束のこと
● アクター両者のカスタマージャーニーに登場する。両チームの開発PJが交差する場所なの
で、どちらかが占有することはできない。
54
Slide 55
Slide 55 text
アクターごとに境界づけられたコンテキストを分けた場合
● Seller側の「受注」コンテキストと、Buyer側の「発注」コンテキストを分ける場合
● 運用上の課題
○ 片方は「キャンセル」したのに、もう片方で同時に「発送」してしまう、運用上のデー
タ不整合のリスク
仮に無理やり一致させた場合
55
Slide 56
Slide 56 text
アクターごとに境界づけられたコンテキストを分けた場合
● 開発上の課題
○ ドメインモデル改修時に両コンテキストで矛盾した変更をしてしまうリスク
○ 時間の経過による仕様の変化に対して極めて耐性が低い
● 境界づけられたコンテキスト＝整合性を保証する範囲、という目的が果たせていない
○ 根本的に「注文」とはコインの裏と表であり、分割することは出来ない
仮に無理やり一致させた場合
56
Slide 57
Slide 57 text
何故噛み合わないのか？
57
● これだけで見ると「アクターが複数いれば衝突がおこりうる」といった内容に見えるが、
もう少し正しく言語化するならば、
○ 1.多くのビジネスモデルは提供できる人と提供されたい人の価値交換システムであり、
○ 2.バリューストリームと境界づけられたコンテキストは世界の切り方が違うため
● だからだと思われる
Slide 58
Slide 58 text
多くのビジネスは「価値交換システム」
●多くのビジネスは「誰かが誰かのために価値を創り、受け渡す」という構造を持つ
●特にプラットフォーム型ビジネスでは、複数のアクター（BuyerとSeller等）の間に立ち、
双方に対して価値を提供する
●例：ECプラットフォーム
○ Buyerには「欲しいものが見つかり、安全に買える」価値を提供
○ Sellerには「販路が広がり、売上が立つ」価値を提供
○ 事業者はその仲介によって収益を得る
58
Slide 59
Slide 59 text
世界の切り方
●バリューストリームはアクターのジャーニーに沿って世界を切る
○ 価値を届ける相手に対する価値検証を基準に切るため
○ 同じアクターでもジャーニーが広大な場合はより細かく分ける場合もあるので、アクターが複数いるかどうか
というより、ジャーニー違いで衝突が発生する、と表現したほうが正確か
● 境界づけられたコンテキストはアクターに対してサービスを提供する事業者に寄った視点
で世界を切る
○ Buyerが商品を探して購入するまで、Sellerが出品して売れるまで、という軸
59
Slide 60
Slide 60 text
境界づけられたコンテキスト＝事業者視点？
EricEvansはそんなことは言ってないので、異論を唱えることは可能。原典では「特定のモデルが一
貫した意味を持つ範囲」。しかし実務の上で事業者視点に寄った整理へ結果的に近づくと考えてい
る。何故ならば一貫性を保つ責任が事業者側にあるから、ユビキタス言語の定義もそちらへ寄って
いく。
●✕：Buyerにとっての「発注」を管理する
●✕：Sellerにとっての「受注」を管理する
●◯：BuyerとSellerの間の価値交換ビジネスを行っている仲介者（＝事業者）にとっての「注文」を管
理する
○ ◯：事業会社の管理する「注文」からBuyerにとっての「発注」を投影する
○ ◯：事業会社の管理する「注文」からSellerにとっての「受注」を投影する
60
Slide 61
Slide 61 text
噛み合わない理由
● 1.多くのビジネスモデルは提供できる人と提供されたい人の価値交換システムである
○ ＝「注文」のように両者のコインの裏と表のような概念を扱う必要がある
● 2.バリューストリームと境界づけられたコンテキストは世界の切り方が違う
○ ＝「注文」のようなコインの裏と表を扱う領域において、アクターに寄った整理と、事
業者に寄った整理で、両者の結果は異なる
● バリューストリームに寄せる：SellerチームとBuyerチームにシステムが分かれ、両チーム
は企画〜リリースまで単独で行えるが、モデル整合性は維持できない
● 境界づけられたコンテキストに寄せる：注文コンテキストを占有するチームが発生する
が、これは同時にSellerチームとBuyerチームのどちらか、あるいはどちらも単独でリリー
スを完遂できない
● だから両方に同時に最適化された組織図は成立しない
61
Slide 62
Slide 62 text
3章のまとめ
● 価値交換を行うビジネスモデルにおいて、バリューストリームに最適化された組織図と、
境界づけられたコンテキストに最適化された組織は、部分的に噛み合わず衝突すると思わ
れる、という仮説を提起した
● 前者は顧客価値検証に最適化された組織の姿、後者は分散自律改善に最適化された組織の
姿であると表現し、４章ではこの仮説と４年間の発生事象の比較と答え合わせを行う
62
Slide 63
Slide 63 text
4. ４年間の整理
63
Slide 64
Slide 64 text
発生事象の整理
64
Slide 65
Slide 65 text
発生した事象の整理
● ２０２４年目的別組織が廃止され、横断機能開発チーム中心の組織になった
○ 前者は分散自律改善に寄りすぎた組織の姿で、顧客価値検証に向いておらず、ビジネス
としての最適化を行った必然的な結果だった
● ほぼすべての開発PJで複数モジュールをまたいだ改修が行われた
○ アクターにとっての価値のカスタマージャーニーは基本的に境界づけられたコンテキス
トを横断する
● 過剰なプラットフォームエンジニアリング
○ 顧客価値検証に寄って分散自律改善が弱まった時、占有チームのいなくなってしまった
モジュールの設計をある程度守るために発生した副作用
65
Slide 66
Slide 66 text
発生した事象の整理
● 横断機能開発チームが開発PJのなかで都度コアドメインチームとの相談や調整
● コアドメインチームへの依頼が積み重なり続けた
○ 顧客価値検証に向けられたチームと、分散自律改善に向けられたチームが、同時に組織
図に存在する状況下における必然的な事象
○ コアドメインは２つのカスタマージャーニーが重なる、まさに「価値交換を行う」瞬間
を扱う場所だったため、一度に複数の開発PJから依頼が殺到した
66
Slide 67
Slide 67 text
発生した事象の整理
● ２０２６年セクション制への移行
○ 「分散自律改善の方が良い」と思ったわけではない。あくまで顧客価値検証活動を阻害
しない程度に両立できるだけの文化が醸成されたからこちらに一時揺れ戻っただけ
○ 大前提として「全チームが全モジュールをいじりうるし、それを実現できるだけのスキ
ルや慣れがある」という、ある意味全チームが横断機能開発チームでもある、という建
付けに近い
67
Slide 68
Slide 68 text
４年越しの答え合わせ
68
Slide 69
Slide 69 text
材料が揃ったので４年前の答え合わせを試みる
● バリューストリームに最適化された組織
○ ビジネスの手数を最大化することを良しとする思想
○ つまり目的不確実性に対するPDCAに最適化された組織と言い換えられる
● 境界づけられたコンテキストに最適化された組織
○ ビジネスの整合性の維持を最大化することを良しとする思想
○ つまり方法不確実性（の一部）に対するPDCAに最適化された組織と言い換えられる
69
つまりこの２つの対立は
目的不確実性と方法不確実性のPDCAの衝突とも言い換えられる
Slide 70
Slide 70 text
４年前に目指していた方針
70
Slide 71
Slide 71 text
４年前に目指していた方針
71
Slide 72
Slide 72 text
４年越しの答え合わせ
72
モジュラモノリスとか以前に
命題自体が
構造的に破綻している
Slide 73
Slide 73 text
問の立て直し
73
どうすれば両立できるか
↓
どこで均衡点を取るか
Slide 74
Slide 74 text
課題の解像度があがった
顧客価値検証最適・分散自律改善最適・社会性の間のトレードオフ構造であると課題の解像
度が上がった。全てを同時に最大化出来ないが、時間の経過に応じた調整問題がこの課題の
本質であると整理し直した。
74
顧客価値検証最適
バリューストリーム志向
分散自律改善最適
境界づけられたコンテキスト志向
一致しているのが望ましい
両者に差分がある場合のしわ寄せ
社会性の消費
不可視の有限リソース
Slide 75
Slide 75 text
３者のトレードオフ構造の整理
75
Slide 76
Slide 76 text
差分はある、その場合の影響の整理
このあたりからは、弊社の、というより発表者個人の整理に近づいていく。
顧客価値検証最適と分散自律改善最適を同時に最大化出来ないが、両者を部分的に取り入れ
ようとすると社会性という不可視のリソースが消費されていく、というのが発表者の見解。
※ １事例の「過度な一般化」と受け取られうることは自覚しています、異論は弊社ではなく発表者個人へお願いします
76
顧客価値検証最適
バリューストリーム志向
分散自律改善最適
境界づけられたコンテキスト志向
一致しているのが望ましい
両者に差分がある場合のしわ寄せ
社会性の消費
不可視の有限リソース
Slide 77
Slide 77 text
● （ビジネスモデル次第ではあるが）両方を同時に最大化はできないが、どちらかを完全に
捨てることも難しい
○ 一致しているのが望ましいことに変わりないし、ほとんどの書籍の主張も同じ
○ しかしビジネスのコア領域であればあるほど、それはおそらく難しい、というのが本発
表の立場
■ コア領域以外なら、案外簡単に一致する
■ 会計SaaSなどの単一アクターにツールを提供するようなビジネスモデルや、コンテン
ツ配信・メディア系・SNSなどでも一致するのかもしれない
● トレードオフを理解したうえで部分的に採用していく
○ 顧客価値検証に重きを置かない会社はまず存在しないので、基本的に顧客価値検証を
ベースにしながら部分的に分散自律改善を取り入れていく、という考え方
顧客価値検証と分散自律改善は両方を最大化出来ない
77
Slide 78
Slide 78 text
● CSチーム＝コンプリケイテッドサブシステムチーム
● チームトポロジーの「高度な専門知識が必要な複雑なコンポーネントを開発・保守する専
任チーム」
○ 弊社で言えばコアドメインチームのこと
○ 複雑なドメイン知識をベースに、自律的な設計改善・運用改善の技術的意思決定を行う
● 整合性の破綻がクリティカルな領域にのみ設置する
複雑な領域にCSチームを配置する
78
Slide 79
Slide 79 text
● 単独での１バリューストリーム完遂を諦める
○ チーム間調整の発生を許容する
■ 事前に相談したり、作業の調整をしたり、そのコンテキストの一貫性を損なわないよう
な調整作業が出てくる
■ 予想以上に高コスト
● CSチームを配置しない境界づけられたコンテキストの自律改善を諦める
○ モデル整合性・設計の一貫性の担保を諦める
■ プラットフォームエンジニアリングで作り方を強制するのはある程度代替しうるが、時
間の経過による自律改善はどのみち期待できない
○ 運用課題の自律改善を諦める
■ 定常的に発生する問い合わせなどの運用課題の恒久対応をやめて、都度対応する
部分的に取り入れた場合の事象
79
Slide 80
Slide 80 text
● チーム間調整は仕方なく発生してしまうが「調整の質」を上げて摩擦係数を減らす工夫は
必要
○ チーム間APIを定義する
■ チームトポロジーで言う「インタラクションモード」を明示的に設計する
■ 調整を非同期化する（決まった手順で依頼を投げれば、非同期で依頼が達成される）
○ プラットフォームエンジニアリングで「舗装された道路（PavedRoad）」を用意する
■ 調整不要の決まり事にしてしまう
■ ただしあらゆる要件で使える「舗装された道路（PavedRoad）」の用意は不可能で、無
理に使おうとすることで現場が疲弊する、という事象は発生する
○ 文化を醸成する
■ 依存を早めに表明する、越境を奨励する、調整に巻き込まれることをマイナスにしな
い、良き隣人としての振る舞いを奨励、など
● これらがないと「社会性」がより大きく消費されてしまう
「社会性の消費」
80
Slide 81
Slide 81 text
● ここでの「社会性」とは、会社という社会の中で立ち回る際の、有限の時間的・肉体的・
精神的なリソースの表現として使っている
○ チーム間の調整には非手続き的な調整のほうが圧倒的に多い
○ チーム間APIやドキュメントで定義しきれない「隙間に落ちたボール」を解決する必要が
ある
■ そのため「空気（文脈）を読む」や「社内の状況的に今はこう」や「全体最適の観点で
はこう」のような対人調整・対組織調整領域が発生する
■ ここが苦手な人にとって弊社は少し過酷な開発現場だったと思う
● 「チーム間調整」「コミュニケーションコスト」という言葉では汲み取れないような、目
には見えない要素を捨象したくなかったため「社会性という不可視の有限リソース」と表
現した
● 「社会性の消費」は無ければ無いに越したことはない
○ 本来生産性に向かうはずだった有限のリソースがただの調整事によって消失する
○ が、本発表の仮説が当てはまるのであれば、残念ながら難しい
「社会性の消費」
81
Slide 82
Slide 82 text
● 占有する/しないという、０か１かみたいな極端な定義が原因かと言うと、そうとも言い切
れない
● 仮に「占有」ではなく「主担当」くらいにすると、曖昧な責任範囲からさらに「空気を読
む」必要があり、社会性がより消費される
○ 「空気を読む」のは人に対しても、組織に対しても、何より既存のコードに対しても
● 現実的には完全な占有は不可能で、主担当くらいの落とし所くらいにしか出来ないと思う
が、それによって目には見えない何かがさらに消費されている認識は必要だと思われる
○ CSチームがいるモジュールへの変更時は「心理的障壁を感じる」という社内の声は実在
する（仲が悪いわけではない
○ そういう意味でも、この発表では「社会性の消費」という聞き慣れない日本語を使って
いる
「占有」ではなく「主担当」くらいだとどうか
82
Slide 83
Slide 83 text
３者の動的均衡
83
Slide 84
Slide 84 text
時間の経過とともに均衡点も推移する
厄介なことに、一度取った均衡点は維持することはできない。
時間の経過ともに状況は変わるため、そのなかで動的な均衡を実現せざるを得ない。（ただ
し未解決
84
顧客価値検証最適
バリューストリーム志向
分散自律改善最適
境界づけられたコンテキスト志向
社会性の消費
不可視の有限リソース
一致しているのが望ましい
両者に差分がある場合のしわ寄せ
Slide 85
Slide 85 text
● リソースの再配分のため組織図は変わりつづける
○ その時の事業上の注力領域に最適化した形に組織図は更新せざるを得ない
■ 今年は〇〇領域の拡充を行う、という事業戦略に対して、組織図はNOとは言えない
■ 先の整理で言えば、バリューストリームがたくさんある中で、どこにどれだけコストを
割くかという組織の重心の置き方は変わり続ける
○ そもそも顧客価値検証だとか分散自律改善だとか関係なく人は変わるし、同じ人でもス
キルや興味が変わる
● 組織図も組織図で、時間とともに変わりゆく大量の変数のなかから動的均衡を保とうと努
力している
時間の経過とともに変わる要素
85
Slide 86
Slide 86 text
● 占有する顔ぶれは変わる
○ 組織図変わった場合の必然として占有する顔ぶれは変わる
○ 分散自律改善はチーム内の暗黙知によってガンガン改善を回す方式なので、占有する人
間が変わるときには暗黙知が逆に足かせになる
■ CSチーム内の新メンバーへのオンボーディングが難しい、という声は実在する
時間の経過とともに変わる要素
86
Slide 87
Slide 87 text
● アーキテクチャはこれに対応できなければならない
○ 未解決だが、OwnershipTransferCostの最適化が求められる
■ ADRなどの意思決定記録の蓄積
■ AIエージェントの作業時に何かしらのログが自動で残る共通基盤など
■ コード（≒ドメインモデル）自体が形式知化された暗黙知であると捉える
時間の経過とともに変わる要素
87
Slide 88
Slide 88 text
5. まとめ
88
Slide 89
Slide 89 text
● 弊社の４年間から見えてきたものを分析し、解決すべき課題の解像度は上がった
○ （ビジネスモデルにもよるが）顧客価値検証と分散自律改善は同時に最大化は出来ない
というトレードオフ構造を理解して、時間の経過とともに動的な均衡を維持すること
まとめ
89
Slide 90
Slide 90 text
● 顧客価値検証と分散自律改善は二律背反のように見えるが、実際は遠い因果関係
● 前者は新しい価値提供をする現状変更の力学に、後者は現在の価値提供を安定的に行う現
状維持の力学に近い
● 両方があるから価値提供を最大化出来るので、どちらか一方を軽視するのは少し違う
● 新しい課題定義に従って、今後も組織の生産性に寄与するチャレンジを続ける
まとめ
90
現状変更 現状維持
新しい価値を生み出すから、維持する理由ができる
維持できるから、新しい価値提供活動をする余剰が生まれる
Slide 91
Slide 91 text
● 発表の趣旨として、「モジュラモノリス以前の命題が破綻していた」、というものなの
で、モジュラモノリスがどのくらい効果的だったか、について言及できなかった
● 今の知識を持ったまま４年前に戻れる（強くてニューゲーム）としても、同じ選択をした
くらいにはモジュラモノリスは実用的だったと考えている
● 時間の許す範囲でモジュラモノリスや諸技術が機能した箇所を紹介する
結局モジュラモノリスの話はどこにいった
91
Slide 92
Slide 92 text
● クリーンアーキテクチャ
○ フレームワーク・ライブラリ・コンテナの最新バージョンに簡単に追従できた
○ メンテナがいなくなったライブラリや、公式ライブラリがメンテナンスを諦める、みた
いな事象が度々発生したが、柔軟に自家製ライブラリへ乗り換えられた
● ドメイン駆動設計
○ ドメイン知識豊富な人の暗黙知が実行可能なPHPコードとして形式知化された
○ ドメインモデルがアプリケーション層から独立しているため、クライアントアプリケー
ションの増加＝WebAPIエンドポイントの増設が簡単になった
■ 最近で言えば海外販売クライアントやAIエージェント向けのエンドポイントなど
● モジュラモノリス
○ 技術的な意思決定の遅延を許してくれた
■ モジュール間の移動がある程度出来たので、「一旦はこのモジュールに実装する（後で
動かしたくなったら動かす）」という意思決定がカジュアルに行えた
機能した要素（テクノロジーの変化に耐えた）
92
Slide 93
Slide 93 text
● 境界づけられたコンテキスト
○ 組織図はよく変わったが、ビジネスモデルが大幅に変わらない限り境界づけられたコン
テキストはびくともしなかった
○ 「結果的には」逆コンウェイ戦略ぽくなったが、意図的ではない
● モジュラモノリス
○ プラットフォームエンジニアリングとして共通基盤を全モジュールに供給するのが容易
だった
■ 目的別組織が廃止され、占有チームがいなくなったモジュ ールに対して、共通基盤を
供給してなんとか維持しようとする際に役立った（当時は死に物狂いだった・・
機能した要素（組織の変化に耐えた）
93
Slide 94
Slide 94 text
● プラットフォームエンジニアリング
○ トランザクション制御・例外制御・ログトレーシング・エラートラッキング・非同期処
理基盤などの基盤技術が横断的な技術的関心事を巻き取ることで、ビジネス機能開発に
使用できる時間を増やした
○ 特に非同期処理基盤（誰でも少ないコードで非同期処理が作れる基盤）は圧倒的に利用
された
● ただし、どちらかといえばビジネスニーズの変化には柔軟に応えることは出来なかったか
もしれない・・
○ それは顧客価値検証に最適化された組織図によって賄っていたように記憶している
○ アーキテクチャがビジネス整合性を維持しやすくすることで、新機能開発の余剰を生み
出す・・・程度の遠い因果関係程度におさまる
○ OwnershipTransferCostを最適化することで組織図に追従しやすくすることが課題か
機能した要素（ビジネスの変化に耐えた）
94
Slide 95
Slide 95 text
● モジュラモノリス
○ モジュールを往来すると社会性が消費されてしまうが、モジュールごとの作りが極端に
大きくなければ、ゆうて同じリポジトリなので往来はしやすい
■ 社会性消費の「単価」はモジュラモノリスだからこそ下げられていたように思える
● モジュール占有
■ 設計改善はあまり出来なかったチームもあったが、運用改善は相当やってくれた
■ モジュール保守の責任を明確に与えることで、当人たちに意識にかなり変化があった、
とのこと
■ コアドメインチームの自走する姿を参考に、現在のセクション制へと横展開されたの
で、分散自律改善の作用を組織に広がる起爆剤としては大いに活躍した
● クリーンアーキテクチャ
○ SOLID原則などの設計原則がある程度強制される中で、ソフトウェア設計に関心を持つ
人がわずかに出現
○ 「Webフレームワークとかどうでもよくなった」とのこと
機能した要素（人・組織・文化的な影響）
95
Slide 96
Slide 96 text
● モジュール占有と継続的なリファクタリング
○ 機能改修の都度ドメインモデルとコードを見直してリファクタリング、といった活動は
限定的だった
○ 課題にそもそも気づいていない、というチームも、本人たちに課題感はありつつもリ
リース圧力から逃げられない、というチームも両方ある
○ 人や組織への価値観のアップデートが必要
○ 自分の行った技術的意思決定が、長い時間をかけて自分に返ってくる、みたいな経験を
積み上げないとコード品質の勘所はAI時代にも育たない気がしているので、今はまだ芽
は小さいが、いずれ発芽してほしいという期待はある
機能しなかった要素
96
Slide 97
Slide 97 text
● 暖簾分け効果
○ ※暖簾分け：新アーキテクチャの知見・設計思想・実装スタイルをじわじわ横展開し、
組織全体に浸透させる草の根活動を社内では暖簾分け戦略と呼んでいた
○ ゆっくりだが着実に効果はある、しかし４年経っても完遂しないあたり本当に遅い
○ 「この人明らかに技術志向じゃないだろ」みたいな人が保守性の高いコードの興味を持
ち始めたり、逆にいつまでも関心を持たない人もいたりする
○ かつて目的別組織廃止の時、熱量の高かったチームも解散されたが、その時の残り火は
わずかだがちゃんとまだ残っていて、じわじわ広がっている
■ 第２世代、第３世代、みたいな広がり方をして初めて「機能した」と言えそう
機能したかどうか半々な要素
97
？
Slide 98
Slide 98 text
● 分散自律改善に全振りしてはいけない、ということにガッカリした人もいるかも知れない
○ ただし顧客価値検証に全振りしてもいけない、という意味でもある
● どちらにもやりすぎに注意・・・というより、時間の経過による変化に追従できるかどう
かにコミットするほうが本質的かもしれない
○ 境界づけられたコンテキストは移ろいやすい組織図よりも賞味期限が長いため、そうい
う意味でシステム構造を組織に反映しようとする逆コンウェイ戦略はある程度妥当だっ
たのかもしれない（４年前はむしろ嫌いなワードだったが）
4年間を経て思うこと
98
Slide 99
Slide 99 text
● 両者の溝を超えるには人と組織の質的変化が必要になってくる
○ 「最終的には人」みたいな落とし所はよく聞くが、個人的にはそれとは言い方がちょっ
と違うと思う
○ 人という資源を浪費しないように組織図とアーキテクチャを設計しているので、仮に全
員が認知能力の上限がなく、ダンバー数も関係なく、システムの全貌を把握していて、
十分な設計スキルがあるなら組織図もアーキテクチャもそもそもいらない
○ 要するに最終的に人にしわ寄せがいっている以上、それは単純に組織図とアーキテク
チャの至らない部分である、という言い方のほうが自然
■ ただし、今回の仮説のように、両立はおそらくできない場合が多いので、最終的にはど
うしてもしわ寄せはいってしまうのだが・・
● 溝を超えるための人と組織の変化には長い時間がかかるため、弊社も現在のセクション制
のような体制には一足飛びにはいけなかったのだと思う
4年間を経て思うこと
99
Slide 100
Slide 100 text
● 仮に組織のスケール対策としてモジュラモノリスを採用しようとしているなら、そのモ
ジュラモノリスは技術だけでは駆動しないはず、と考えています
○ 分散自律改善が部分的にしか取り入れられない以上、溝の中で社会性が消費されていく
環境になってしまいます
○ そういう意味で、弊社のモジュラモノリスは人々の社会性を燃料に駆動しているのだと
思います
● 仮にモジュラモノリスを検討している方はトレードオフ構造が発生する前提で、人と組織
の状態をどう更新していくかという観点を考慮することをおすすめいたします
4年間を経て思うこと
10
0
Slide 101
Slide 101 text
10
1
ご清聴ありがとうございました