モジュラモノリス導入から4年間の総括：アーキテクチャと組織の相互作用について / Architecture and Organizational Interaction

アーキテクチャと組織の相互作用についてモジュラモノリス導入から4年間の総括 2026/3/21 PHPerKaigi 2026

自己紹介 BASE Inc. TechLead 川島慧(@nazonohito51) 2

前置き 3

前回の発表（４年前） 4 https://speakerdeck.com/nazonohito51/base-rearchitecturing

発表の目的 5 この発表の目的 • ４年間の実践を通して、4年前の意思決定の「答え合わせ」を行う • 設計論と現実の間で発生する摩擦の正体について、組織とアーキテクチャの間に働く「力学」の分析という形で、一個人の見解を述べるこの発表のアプローチ •
単一事例（BASE）を、一般化された書籍の概念というレンズを通して解釈し、1事例の中にある構造の一般化を試みる • ４年間の間に発生した問題から、そもそもアーキテクチャが解決しなきゃいけない課題はなんだったのかを抽出し、その上で答え合わせを行う ◦ ※ 「過度な一般化」と受け取られうることは自覚しています。　持ち帰ってほしいこと • 理論と現実の間にある差分の正体を正確に掴むことで、各自の所属する企業の組織図・アーキテクチャの助けにしてほしい

発表者の立場について発表者視点での発表です •BASEのアーキテクトとして、意思決定に関与している箇所と関与していない箇所がある •関与していない意思決定については、発表者視点の分析・解釈であり、当人の意図と食い違う部分があるかもしれない　ハイコンテキストな発表です •多くの書籍・概念（DDD・チームトポロジー・Accelerate等）を引用するが、それらについて深くは言及しない •そもそも量自体が多いスライドなので、アップロードされたものをAIに要約させることを
推奨 6

この発表でやること・やらないことやること •４年前の意思決定の答え合わせ •4年間の事実を根拠に「設計論と現実の間にある障壁」を分析する　やらないこと •モジュラモノリスの実装詳細や技術的tipsの紹介 •リアーキテクチャの具体的な実施方法 7

1. 4年前のリアーキテクチャ方針と想定 8

なぜリアーキテクチャを始めたか •成長するプロダクト・組織・システムの中で、生産性を継続的に維持するため 9

リアーキテクチャの方針 10

リアーキテクチャの方針 11

12 組織構造とアーキテクチャを一致させる

目指す組織の姿目指したのは「分散自律型の組織」組織全体の目的や戦略のもとで、各チームが自ら意思決定し、独立して学習と改善を継続できるように設計されたアーキテクチャ自律したチームを基本として、それが独立して作業可能なアーキテクチャを用意することで、組織全体の生産性に寄与しようとしていた 13

なぜモジュラモノリスを選んだか MSAは理想的だったが、リスクが大きかった •分散システムの複雑さ（ネットワーク障害・整合性・デプロイ複雑度） •境界線の定義が難しく、間違えたときの手戻りコストが高い •当時の組織・技術力に対して、飛躍が大きすぎた　モジュラモノリスを選んだ理由 •MSAと同様のモジュール分離メリットを持つ •境界線の手戻りが低コストでできる ◦
間違えても直しやすい。意思決定を遅らせられる。 •漸進的にMSAへ向かえる中間地点として機能する 14

クリーンアーキテクチャ＋モジュラモノリスの合わせ技 Infrastructure Interface Use Case Domain クリーンアーキテクチャ＋商品 Catalog
注文 Order 決済 Payment ユーザー User 配送 Shipping Shop 管理プロモ Promo 決算 Settlement … モジュラモノリス（モジュール群）各モジュールはクリーンアーキテクチャの構造を持つ。 15 ※図はイメージです

1モジュール＝1境界づけられたコンテキストモジュール（コード上の分割単位）＝境界づけられたコンテキスト（概念上の境界） Catalog モジュール＝商品カタログコンテキスト Order
モジュール＝注文コンテキスト Payment モジュール＝決済コンテキスト User モジュール＝ユーザーコンテキストモジュール境界＝ドメインモデルの境界。1モジュールが1つの境界づけられたコンテキストを持つ。 16 ※図はイメージです

当時の組織とモジュールの責任の紐づき当時は目的別組織と呼ばれる組織体制で、事業戦略単位でチームが分かれ、各チームが特定のモジュール群を占有する状態を目指していた。エンジニア人数はおおよそ１００人近く（サービス開発・基盤技術・品質保証など全部門含む） 17 ※図はイメージです

当時の前提前提①：目的別組織がある程度続く •組織図にある程度合わせてモジュールを設計した •チームとモジュールの対応関係がある程度の期間は安定する想定だった　前提②：チームがモジュールを占有すれば自走できる •技術的な意思決定者が自明であれば自律進化するであろう、という想定 •占有によって責任を自明にすれば、チームが自律的にPDCAを回せると考えた　この2つの前提は、すぐに大きく崩れていくことになる。
18

2. ４年間の変遷 19

組織の変遷——3つのフェーズ〜2024年目的別組織チームA Catalog/Order チームB Payment/User チームC Shipping/… 固定メンバー・固定ドメイン
モジュールを各チームが占有 2024年〜横断開発型組織＋コアドメインチーム横断チームA 横断チームB コアドメインチーム全チームが全ドメインを横断コアドメインのみ専門チームが守る 2026年〜セクション制組織セクションA 専門チームセクションB 専門チームセクションC 専門チーム各セクションに専門チーム 20 ※図はイメージです

目的別組織の廃止いくつかの問題が積み重なったため • サイロ化 ◦ 担当ドメインへの専門性が高まる反面、視野の狭まり・他ドメインへの無関心化・越境しづらさが生まれた •環境への固執 ◦ 固定メンバー・固定ドメインの開発は安定したベロシティには繋がったが、同一環境への固執やマンネリを招いた
　 •プロセス成熟度の上限 ◦ スクラム開発を取り入れ始めた時期でプロセスは一定成熟したが、進化への停滞が見えてきた（80点→100点が遠い）　 •負荷の偏り ◦ 特別忙しいチームとそこまで忙しくないチームが同時に存在している 21

２０２４年〜横断機能開発組織の開始 •全てのチームが全てのモジュールを触る、という組織設計 ◦ 全員が担当領域を持たない　 •開発PJへのエンジニアの割当を柔軟に行う ◦ 成長への期待も加味した形でのアサイン ◦ マンネリ感の打破
◦ 負荷が特定のチームに偏らないように分散 ◦ ただしチーム内部はある程度固定で、一緒に働く顔ぶれをあまり動かさない　 •→ デリバリーの速さに注力しつつ、これとは別にコアドメインと呼ばれるモジュールには占有チームを配置 22

コアドメインチームの新設なぜ作ったか •事業競争力の源泉となるコアドメインを守り育てる占有チーム •横断機能開発チームとは違い、コアドメインのみを扱い、継続改善（安定）を担う ◦ 「速さ（デリバリー）」と「安定（コアの継続改善）」の役割分担 ◦ 横断機能開発チームのコアドメイン改修時の負荷を減らせるようにサポートする •モジュラモノリスへの機能移行を継続的に行うため •
旧システムに残ったままの機能を移行することで、新システム（モジュラモノリス）上だけでの開発作業を実現するため 23

２０２６年セクション制へ—— 何が変わったか •コアドメインと呼ぶ範囲を広げて3つとし、それぞれに占有チームを配置 ◦ コアドメインを見る占有チームをそれぞれセクションと呼ぶ ◦ ただしセクションに配置されないチームは存在しないので、実質全チームが何かしらのモジュールを占有している状態 •軸足を「挑戦と機動力」から「専門性と持続性」へと移した　
各セクションの専門チームの役割 •アンコントローラブルな問い合わせ対応を定常的に減らす •それぞれのドメインでPDCAを回して科学する •「誰に聞けばいいかが自明な体制」の実現　ぱっと見はリアーキテクチャ開始当時に目指していた組織の姿　　　　　——が、実態は少し違う（後半で言及します） 24

２０２６年３月現在の開発現場 •ほとんどの開発PJは新アーキテクチャ上で行われるようになった ◦ 旧システムのうち重要なものは新システムへ移行完了した ◦ 開発者のオンボーディングはまだ途中だがある程度は達成された •リアーキテクチャ活動自体が縮小傾向で、おおむね完遂した扱い 25

４年間の中で取り上げたい事象組織図は高頻度に更新され続けた •少し変わる、ではなく、大幅に変わった •アーキテクチャが組織図に追従するのは困難だったコアドメインチームが運用改善を自律的にかなりやってくれた •担当しているモジュールの土地勘（メンタルモデル）があるため、障害対応も速くPDCAを回しやすかったほぼすべての開発PJで複数モジュールをまたいだ改修が行われた •1モジュールで作業が完結するケースはほぼ無かった 26

４年間の中で取り上げたい事象コアドメインチームへの依頼が積み重なり続けた •コアドメインを改修しないといけない開発PJが多発した •「そのモジュールを変えたいが、コアドメインチームに調整が必要」という状況がそれなりの頻度で繰り返された継続的なリファクタリングはほとんど実施されなかった •開発要求への対応が優先され、設計の改善は後回しになり続けた ◦ そのモジュール領域を「守る」ことに対するインセンティブが少なかった •コアドメインでも、土地勘があるからこそ逆にツギハギのパッチワークが出来てしまう、
という占有してるからこそ逆説的に改善しなくてもいい、という事象が発生したように見える 27

４年間の中で取り上げたい事象過剰なプラットフォームエンジニアリング •理由は後に触れるが、発表者の所属するプラットフォームチームが共通基盤技術を、個人的には過剰に供給していたように思える •「占有チームが独自に設計判断が出来る」という建付けのはずが、いつの間にか特定の作り方しか出来ない、みたいな矛盾した環境に少しずつ近づいていた 28

４年間の変遷を振り返って • 組織図の大胆な変更を含めて、現実的にリアーキテクチャ当初の自律分散的な組織からはは程遠い４年間だったように思える ◦ 今年のセクション制からは当初の想定に近しい状態になった • ただし先程取り上げた事象は、実は組織図の変更や各チームの意識とかインセンティブ構造とか、それ自体が原因ではなく、もっと奥にアーキテクチャと組織図の関係において決定的な力学を見逃していたように思える
◦ 世の中で良いとされる方法にはなるべく沿ろうとしていたが、それらの方法論を組み合わせた場合にのみ発生する摩擦のような何か ◦ 全ての震源地はそこにあるという予測 • ３章ではその仮説を提起する 29

3. 事象から読み取る仮説の提起 30

仮説の提起：顧客価値検証と分散自律改善は両立できないのではないか？ 31

この4年間で起きたことの根本にある「からくり」仮説を先に書くと、顧客価値検証を最大化するための組織と、分散自律改善を最大化するための組織は、両立できないのではないか？これが、4年間に起きたことの事象の震源地で、この２つの組織図の根源にあるバリューストリームと境界づけられたコンテキストは、噛み合わないのではないか？ 32

この4年間で起きたことの根本にある「からくり」弊社はリーン思考・アジャイル・DevOps・ドメイン駆動設計（以下DDD）・マイクロサービス・エンジニアリング組織論への招待・チームトポロジー・LeanとDevOpsの科学などの不確実性の高い市場環境に適応するための種々の考え方を（アーキテクト視点では）比較的誠実に参照していたように見える。しかし—— •バリューストリームが志向する組織の姿 •境界づけられたコンテキストが志向する組織の姿この2つは、突き詰めれば、矛盾するように見える。 33
※ただしプラットフォーム型ビジネスでかつ組織規模がある程度大きい場合に限られる

この4年間で起きたことの根本にある「からくり」先に訂正すると、バリューストリームと境界づけられたコンテキストはそもそもまったく別のレイヤーの概念なので混ぜるべきではないただしこれらは突き詰めると組織構造へ還元されていく概念であるため、今回同じ俎上に上げている 34

弊社での観察——仮説を支える事実 •組織図は高頻度で変更され続けた •ほとんどの開発PJは複数のモジュール境界をまたいでいた •コアドメインチームへの依頼が発生し続けた •コアドメインを改修しないといけない開発PJが多発した •継続的なリファクタリングはほとんど実施されなかった •過剰なプラットフォームエンジニアリングこれらはランダムな事象ではなく、同じ力学が繰り返し現れた結果ではないか？ 35

なぜズレるのか—— 原典に立ち返って整理する 36

バリューストリームとは原典はリーン思考（Lean Thinking）これ自体は顧客に価値を届けるための一連の活動を可視化したもの目的は価値提供速度を阻害するムダを発見し、無くすこと 37

バリューストリームが解決しようとしていたことリーン思考・アジャイル・DevOpsの文脈 •リーン思考で製造業の「流れ」のムダ（待ち・手戻り）を排除するために生まれた ◦ 後にソフトウェア開発の世界にこの概念が持ち込まれた　 •アジャイルがフォーカスしたのは「目的不確実性の解消速度」 ◦ 何を作るかが不確かな状況で、リリースを増やしてフィードバックを速く回す　
•DevOpsがフォーカスしたのは「デリバリーの流れの最適化」 ◦ 開発から本番投入までの流れを詰まらせない、待ちをなくす　共通する関心　顧客への価値の流れを速く・止めずに届けること。そのための組織・プロセスを設計すること。 38

境界づけられたコンテキストとは原典はドメイン駆動設計ドメインモデルの意味境界を表す単位であり、モデルの整合性を保証する範囲である基本的にはビジネス上の関心の違いから引かれる 39

境界づけられたコンテキストが解決しようとしていたこと DDD・マイクロサービスの文脈 •大規模なドメインモデルは、文脈によって同じ言葉が違う意味を持つ ◦ 「商品」はBuyerにとっては「欲しいもの」、Sellerにとっては「売りもの」、決済にとっては「金額のある何か」　 •境界づけられたコンテキストは「モデルが一貫して正しい範囲」を定義する ◦
その境界の中では、言葉の意味が統一され、モデルの整合性が保たれる　 •マイクロサービスはこの境界をサービス分割の単位として採用されがち ◦ チームがコンテキストを占有することで、自律的に設計改善できる 40

バリューストリームに最適化された組織と境界づけられたコンテキストに最適化された組織 41

組織図に少なくとも2つの最適化軸があるバリューストリーム最適 •「1チームが単独で1つのバリューストリームを完遂できる」が理想　境界づけられたコンテキスト最適 •「チームが境界づけられたコンテキストを占有して改善し続ける」が理想 42

バリューストリームに最適化された組織 •「1チームが単独で1つのバリューストリームを完遂できる」が理想 ◦ 何故ならばチーム間の調整は価値提供活動の上では「ムダ」だから •１チームが企画〜リリースまでに必要な能力と権限を有することで、チーム間の調整なく単独で完遂が可能になる ◦ 職能横断型チームであり、必要なスキルを全て持っている ◦ 改修対象のシステムに対して技術的な意思決定・実装・リリースを行う権限を持ってい
る 43

バリューストリームに最適化された組織 •※弊社の経験則ではあるが ◦ アクターごとにチームが分かれやすい ◦ カスタマージャーニーで定義される比較的広い範囲のシステムを都度改修しやすい 44

バリューストリームに最適化された組織 •何故ならばバリューストリームとカスタマージャーニーは「顧客の価値」という単位で接続されるため ◦ バリューストリーム：顧客に価値を届ける社内の活動 ◦ カスタマージャーニー：顧客が価値を得る一連のプロセス ▪ 例えばECプラットフォームでSellerは、商品を出品するだけでは価値を得られない •
商品を出品し、Buyerから受注し、注文を発送処理して、売上を獲得する、までが価値を得る最小のジャーニーである • １回の開発PJでこれより改修範囲が狭くなることはあまりない 45

バリューストリームに最適化された組織 • バリューストリームに最適化された組織≒カスタマージャーニーに沿った組織、とも言えるので、 ◦ 価値を提供しようとする相手＝アクター単位で分かれやすい ◦ カスタマージャーニーへの改修＝１回の開発PJで広いシステム範囲への改修 • となる
46

境界づけられたコンテキスト最適 • 「チームが境界づけられたコンテキストを占有して改善し続ける」が理想 ◦ 何故ならば自律改善の速度に最も有利なため ▪ 大きく分けてDDD文脈におけるメリットと、マイクロサービス文脈におけるメリットが有る 47 ※念のため訂正すると、
「境界づけられたコンテキスト」原典のDDDでは占有についてそれほど語っていない占有を主張しているのはどちらかといえばマイクロサービス・DevOps文脈である

境界づけられたコンテキスト最適 • DDD文脈でのメリット ◦ ドメインモデルの継続的な改善 ▪ ドメインモデルに完成はないので、次々発生する改修の中で一貫性を保ち続けるには継続的なモデルとコードの見直しが必要 ▪ ドメインモデル自体が占有チームにおけるドメインの「解釈」なので、共有資産化して
みんなで編集、とかは少し難しい側面もあるかもしれない • マイクロサービス文脈でのメリット ◦ 技術的な意思決定の高速化 ▪ 現場にいる人間が必要なものを一番理解しているはず、という前提の元、現場のチームが意思決定できる ◦ 運用責任の明確化 ▪ 開発と運用のインセンティブの違いを乗り越えるため、「作った人が運用する（You build it, you run it）」 48

境界づけられたコンテキスト最適 • 開発と運用はインセンティブが異なり、両者の溝を超えるには「作った人が運用する（You build it, you run it）」必要がある •
開発は現状を変更する活動であり、運用は現状を安定的に維持する活動であり、両者のインセンティブ構造は決して相容れない ◦ 開発と運用の人間が分かれると合意形成には凄まじいコストがかかるため、外部との調整を要さずに独自に意思決定し、その運用責任を本人が果たす、という組織的な枠組みが必要になる 49 開発（現状変更）運用（現状維持）「こうすれば早くリリースできる」「新しい技術を試したい」「問題起こったらどうするんだ」「俺はそんなのメンテナンスできない」

境界づけられたコンテキスト最適 • 根本的には「知識の蓄積先」としてチームに占有させる、という表現が近い ◦ ドメインモデルが表現しようとしているドメイン知識 ◦ 長期でしか結果がわからないような技術的な意思決定の経緯 • これらの知識のほとんどをチーム内の暗黙知として保持できてしまう ◦
形式知化のコストを払わずに高速で意思決定できる • 知識に基づく意思決定の結果責任は自分たちにしかないからチーム間調整も不要 ◦ だから継続的に改善・進化ができる、という建付け 50

• 似てはいる ◦ 「外部との調整をゼロにしたい」という願いが一致している ◦ オーナーシップによるパフォーマンス向上を信じている ◦ 境界線を引くことで複雑さを解決しようとしている • 要するに自律チーム中心的な組織を志している点において両者は一致している
２つの比較 51

２つの最適化は何故噛み合わないのか 52

最も理想的な組織図 •１バリューストリーム＝１境界づけられたコンテキスト＝１チームが最も理想的ではある ◦ １つのチームが複数担当してもいいので、少なくとも１：Nでマッピング可能なら良い ▪ 例：Sellerの販売バリューストリーム：出品・販売・注文・売上（合計４）コンテキスト：１チームなど • しかし少なくともプラットフォーム型ビジネスモデルにおいて、巨大・複雑化していくとこれは成立しなくなっていく、と考えている
53

単純な衝突例 •たとえばECプラットフォームにおける「注文」を例題に上げる　ドメインモデル上の整理 • 「注文」＝SellerとBuyerの間でかわされた取引、すなわち約束のこと • アクター両者のカスタマージャーニーに登場する。両チームの開発PJが交差する場所なので、どちらかが占有することはできない。 54

アクターごとに境界づけられたコンテキストを分けた場合 • Seller側の「受注」コンテキストと、Buyer側の「発注」コンテキストを分ける場合 • 運用上の課題 ◦ 片方は「キャンセル」したのに、もう片方で同時に「発送」してしまう、運用上のデータ不整合のリスク仮に無理やり一致させた場合 55

アクターごとに境界づけられたコンテキストを分けた場合 • 開発上の課題 ◦ ドメインモデル改修時に両コンテキストで矛盾した変更をしてしまうリスク ◦ 時間の経過による仕様の変化に対して極めて耐性が低い • 境界づけられたコンテキスト＝整合性を保証する範囲、という目的が果たせていない ◦
根本的に「注文」とはコインの裏と表であり、分割することは出来ない仮に無理やり一致させた場合 56

何故噛み合わないのか？ 57 • これだけで見ると「アクターが複数いれば衝突がおこりうる」といった内容に見えるが、もう少し正しく言語化するならば、 ◦ 1.多くのビジネスモデルは提供できる人と提供されたい人の価値交換システムであり、 ◦ 2.バリューストリームと境界づけられたコンテキストは世界の切り方が違うため •
だからだと思われる

多くのビジネスは「価値交換システム」 •多くのビジネスは「誰かが誰かのために価値を創り、受け渡す」という構造を持つ •特にプラットフォーム型ビジネスでは、複数のアクター（BuyerとSeller等）の間に立ち、双方に対して価値を提供する •例：ECプラットフォーム ◦ Buyerには「欲しいものが見つかり、安全に買える」価値を提供 ◦ Sellerには「販路が広がり、売上が立つ」価値を提供 ◦
事業者はその仲介によって収益を得る 58

世界の切り方 •バリューストリームはアクターのジャーニーに沿って世界を切る ◦ 価値を届ける相手に対する価値検証を基準に切るため ◦ 同じアクターでもジャーニーが広大な場合はより細かく分ける場合もあるので、アクターが複数いるかどうかというより、ジャーニー違いで衝突が発生する、と表現したほうが正確か　 • 境界づけられたコンテキストはアクターに対してサービスを提供する事業者に寄った視点
で世界を切る ◦ Buyerが商品を探して購入するまで、Sellerが出品して売れるまで、という軸 59

境界づけられたコンテキスト＝事業者視点？ EricEvansはそんなことは言ってないので、異論を唱えることは可能。原典では「特定のモデルが一貫した意味を持つ範囲」。しかし実務の上で事業者視点に寄った整理へ結果的に近づくと考えている。何故ならば一貫性を保つ責任が事業者側にあるから、ユビキタス言語の定義もそちらへ寄っていく。 •✕：Buyerにとっての「発注」を管理する •✕：Sellerにとっての「受注」を管理する •◯：BuyerとSellerの間の価値交換ビジネスを行っている仲介者（＝事業者）にとっての「注文」を管理する ◦
◯：事業会社の管理する「注文」からBuyerにとっての「発注」を投影する ◦ ◯：事業会社の管理する「注文」からSellerにとっての「受注」を投影する 60

噛み合わない理由 • 1.多くのビジネスモデルは提供できる人と提供されたい人の価値交換システムである ◦ ＝「注文」のように両者のコインの裏と表のような概念を扱う必要がある • 2.バリューストリームと境界づけられたコンテキストは世界の切り方が違う ◦ ＝「注文」のようなコインの裏と表を扱う領域において、アクターに寄った整理と、事業者に寄った整理で、両者の結果は異なる
• バリューストリームに寄せる：SellerチームとBuyerチームにシステムが分かれ、両チームは企画〜リリースまで単独で行えるが、モデル整合性は維持できない • 境界づけられたコンテキストに寄せる：注文コンテキストを占有するチームが発生するが、これは同時にSellerチームとBuyerチームのどちらか、あるいはどちらも単独でリリースを完遂できない • だから両方に同時に最適化された組織図は成立しない 61

3章のまとめ • 価値交換を行うビジネスモデルにおいて、バリューストリームに最適化された組織図と、境界づけられたコンテキストに最適化された組織は、部分的に噛み合わず衝突すると思われる、という仮説を提起した • 前者は顧客価値検証に最適化された組織の姿、後者は分散自律改善に最適化された組織の姿であると表現し、４章ではこの仮説と４年間の発生事象の比較と答え合わせを行う 62

4. ４年間の整理 63

発生事象の整理 64

発生した事象の整理 • ２０２４年目的別組織が廃止され、横断機能開発チーム中心の組織になった ◦ 前者は分散自律改善に寄りすぎた組織の姿で、顧客価値検証に向いておらず、ビジネスとしての最適化を行った必然的な結果だった • ほぼすべての開発PJで複数モジュールをまたいだ改修が行われた ◦ アクターにとっての価値のカスタマージャーニーは基本的に境界づけられたコンテキス
トを横断する • 過剰なプラットフォームエンジニアリング ◦ 顧客価値検証に寄って分散自律改善が弱まった時、占有チームのいなくなってしまったモジュールの設計をある程度守るために発生した副作用 65

発生した事象の整理 • 横断機能開発チームが開発PJのなかで都度コアドメインチームとの相談や調整 • コアドメインチームへの依頼が積み重なり続けた ◦ 顧客価値検証に向けられたチームと、分散自律改善に向けられたチームが、同時に組織図に存在する状況下における必然的な事象 ◦ コアドメインは２つのカスタマージャーニーが重なる、まさに「価値交換を行う」瞬間
を扱う場所だったため、一度に複数の開発PJから依頼が殺到した 66

発生した事象の整理 • ２０２６年セクション制への移行 ◦ 「分散自律改善の方が良い」と思ったわけではない。あくまで顧客価値検証活動を阻害しない程度に両立できるだけの文化が醸成されたからこちらに一時揺れ戻っただけ ◦ 大前提として「全チームが全モジュールをいじりうるし、それを実現できるだけのスキルや慣れがある」という、ある意味全チームが横断機能開発チームでもある、という建付けに近い
67

４年越しの答え合わせ 68

材料が揃ったので４年前の答え合わせを試みる • バリューストリームに最適化された組織 ◦ ビジネスの手数を最大化することを良しとする思想 ◦ つまり目的不確実性に対するPDCAに最適化された組織と言い換えられる • 境界づけられたコンテキストに最適化された組織 ◦
ビジネスの整合性の維持を最大化することを良しとする思想 ◦ つまり方法不確実性（の一部）に対するPDCAに最適化された組織と言い換えられる 69 つまりこの２つの対立は目的不確実性と方法不確実性のPDCAの衝突とも言い換えられる

４年前に目指していた方針 70

４年前に目指していた方針 71

４年越しの答え合わせ 72 モジュラモノリスとか以前に命題自体が構造的に破綻している

問の立て直し 73 どうすれば両立できるか ↓ どこで均衡点を取るか

課題の解像度があがった顧客価値検証最適・分散自律改善最適・社会性の間のトレードオフ構造であると課題の解像度が上がった。全てを同時に最大化出来ないが、時間の経過に応じた調整問題がこの課題の本質であると整理し直した。 74 顧客価値検証最適バリューストリーム志向分散自律改善最適境界づけられたコンテキスト志向一致しているのが望ましい
両者に差分がある場合のしわ寄せ社会性の消費不可視の有限リソース

３者のトレードオフ構造の整理 75

差分はある、その場合の影響の整理このあたりからは、弊社の、というより発表者個人の整理に近づいていく。顧客価値検証最適と分散自律改善最適を同時に最大化出来ないが、両者を部分的に取り入れようとすると社会性という不可視のリソースが消費されていく、というのが発表者の見解。 ※ １事例の「過度な一般化」と受け取られうることは自覚しています、異論は弊社ではなく発表者個人へお願いします 76 顧客価値検証最適バリューストリーム志向分散自律改善最適
境界づけられたコンテキスト志向一致しているのが望ましい両者に差分がある場合のしわ寄せ社会性の消費不可視の有限リソース

• （ビジネスモデル次第ではあるが）両方を同時に最大化はできないが、どちらかを完全に捨てることも難しい ◦ 一致しているのが望ましいことに変わりないし、ほとんどの書籍の主張も同じ ◦ しかしビジネスのコア領域であればあるほど、それはおそらく難しい、というのが本発表の立場 ▪ コア領域以外なら、案外簡単に一致する
▪ 会計SaaSなどの単一アクターにツールを提供するようなビジネスモデルや、コンテンツ配信・メディア系・SNSなどでも一致するのかもしれない • トレードオフを理解したうえで部分的に採用していく ◦ 顧客価値検証に重きを置かない会社はまず存在しないので、基本的に顧客価値検証をベースにしながら部分的に分散自律改善を取り入れていく、という考え方顧客価値検証と分散自律改善は両方を最大化出来ない 77

• CSチーム＝コンプリケイテッドサブシステムチーム • チームトポロジーの「高度な専門知識が必要な複雑なコンポーネントを開発・保守する専任チーム」 ◦ 弊社で言えばコアドメインチームのこと ◦ 複雑なドメイン知識をベースに、自律的な設計改善・運用改善の技術的意思決定を行う •
整合性の破綻がクリティカルな領域にのみ設置する複雑な領域にCSチームを配置する 78

• 単独での１バリューストリーム完遂を諦める ◦ チーム間調整の発生を許容する ▪ 事前に相談したり、作業の調整をしたり、そのコンテキストの一貫性を損なわないような調整作業が出てくる ▪ 予想以上に高コスト •
CSチームを配置しない境界づけられたコンテキストの自律改善を諦める ◦ モデル整合性・設計の一貫性の担保を諦める ▪ プラットフォームエンジニアリングで作り方を強制するのはある程度代替しうるが、時間の経過による自律改善はどのみち期待できない ◦ 運用課題の自律改善を諦める ▪ 定常的に発生する問い合わせなどの運用課題の恒久対応をやめて、都度対応する部分的に取り入れた場合の事象 79

• チーム間調整は仕方なく発生してしまうが「調整の質」を上げて摩擦係数を減らす工夫は必要 ◦ チーム間APIを定義する ▪ チームトポロジーで言う「インタラクションモード」を明示的に設計する ▪ 調整を非同期化する（決まった手順で依頼を投げれば、非同期で依頼が達成される） ◦
プラットフォームエンジニアリングで「舗装された道路（PavedRoad）」を用意する ▪ 調整不要の決まり事にしてしまう ▪ ただしあらゆる要件で使える「舗装された道路（PavedRoad）」の用意は不可能で、無理に使おうとすることで現場が疲弊する、という事象は発生する ◦ 文化を醸成する ▪ 依存を早めに表明する、越境を奨励する、調整に巻き込まれることをマイナスにしない、良き隣人としての振る舞いを奨励、など • これらがないと「社会性」がより大きく消費されてしまう「社会性の消費」 80

• ここでの「社会性」とは、会社という社会の中で立ち回る際の、有限の時間的・肉体的・精神的なリソースの表現として使っている ◦ チーム間の調整には非手続き的な調整のほうが圧倒的に多い ◦ チーム間APIやドキュメントで定義しきれない「隙間に落ちたボール」を解決する必要がある ▪ そのため「空気（文脈）を読む」や「社内の状況的に今はこう」や「全体最適の観点で
はこう」のような対人調整・対組織調整領域が発生する ▪ ここが苦手な人にとって弊社は少し過酷な開発現場だったと思う • 「チーム間調整」「コミュニケーションコスト」という言葉では汲み取れないような、目には見えない要素を捨象したくなかったため「社会性という不可視の有限リソース」と表現した • 「社会性の消費」は無ければ無いに越したことはない ◦ 本来生産性に向かうはずだった有限のリソースがただの調整事によって消失する ◦ が、本発表の仮説が当てはまるのであれば、残念ながら難しい「社会性の消費」 81

• 占有する/しないという、０か１かみたいな極端な定義が原因かと言うと、そうとも言い切れない • 仮に「占有」ではなく「主担当」くらいにすると、曖昧な責任範囲からさらに「空気を読む」必要があり、社会性がより消費される ◦ 「空気を読む」のは人に対しても、組織に対しても、何より既存のコードに対しても • 現実的には完全な占有は不可能で、主担当くらいの落とし所くらいにしか出来ないと思う
が、それによって目には見えない何かがさらに消費されている認識は必要だと思われる ◦ CSチームがいるモジュールへの変更時は「心理的障壁を感じる」という社内の声は実在する（仲が悪いわけではない ◦ そういう意味でも、この発表では「社会性の消費」という聞き慣れない日本語を使っている「占有」ではなく「主担当」くらいだとどうか 82

３者の動的均衡 83

時間の経過とともに均衡点も推移する厄介なことに、一度取った均衡点は維持することはできない。時間の経過ともに状況は変わるため、そのなかで動的な均衡を実現せざるを得ない。（ただし未解決 84 顧客価値検証最適バリューストリーム志向分散自律改善最適境界づけられたコンテキスト志向社会性の消費
不可視の有限リソース一致しているのが望ましい両者に差分がある場合のしわ寄せ

• リソースの再配分のため組織図は変わりつづける ◦ その時の事業上の注力領域に最適化した形に組織図は更新せざるを得ない ▪ 今年は〇〇領域の拡充を行う、という事業戦略に対して、組織図はNOとは言えない ▪ 先の整理で言えば、バリューストリームがたくさんある中で、どこにどれだけコストを割くかという組織の重心の置き方は変わり続ける ◦
そもそも顧客価値検証だとか分散自律改善だとか関係なく人は変わるし、同じ人でもスキルや興味が変わる • 組織図も組織図で、時間とともに変わりゆく大量の変数のなかから動的均衡を保とうと努力している時間の経過とともに変わる要素 85

• 占有する顔ぶれは変わる ◦ 組織図変わった場合の必然として占有する顔ぶれは変わる ◦ 分散自律改善はチーム内の暗黙知によってガンガン改善を回す方式なので、占有する人間が変わるときには暗黙知が逆に足かせになる ▪ CSチーム内の新メンバーへのオンボーディングが難しい、という声は実在する時間の経過とともに変わる要素
86

• アーキテクチャはこれに対応できなければならない ◦ 未解決だが、OwnershipTransferCostの最適化が求められる ▪ ADRなどの意思決定記録の蓄積 ▪ AIエージェントの作業時に何かしらのログが自動で残る共通基盤など ▪ コード（≒ドメインモデル）自体が形式知化された暗黙知であると捉える
時間の経過とともに変わる要素 87

5. まとめ 88

• 弊社の４年間から見えてきたものを分析し、解決すべき課題の解像度は上がった ◦ （ビジネスモデルにもよるが）顧客価値検証と分散自律改善は同時に最大化は出来ないというトレードオフ構造を理解して、時間の経過とともに動的な均衡を維持することまとめ 89

• 顧客価値検証と分散自律改善は二律背反のように見えるが、実際は遠い因果関係 • 前者は新しい価値提供をする現状変更の力学に、後者は現在の価値提供を安定的に行う現状維持の力学に近い • 両方があるから価値提供を最大化出来るので、どちらか一方を軽視するのは少し違う • 新しい課題定義に従って、今後も組織の生産性に寄与するチャレンジを続けるまとめ
90 現状変更現状維持新しい価値を生み出すから、維持する理由ができる維持できるから、新しい価値提供活動をする余剰が生まれる

• 発表の趣旨として、「モジュラモノリス以前の命題が破綻していた」、というものなので、モジュラモノリスがどのくらい効果的だったか、について言及できなかった • 今の知識を持ったまま４年前に戻れる（強くてニューゲーム）としても、同じ選択をしたくらいにはモジュラモノリスは実用的だったと考えている • 時間の許す範囲でモジュラモノリスや諸技術が機能した箇所を紹介する結局モジュラモノリスの話はどこにいった 91

• クリーンアーキテクチャ ◦ フレームワーク・ライブラリ・コンテナの最新バージョンに簡単に追従できた ◦ メンテナがいなくなったライブラリや、公式ライブラリがメンテナンスを諦める、みたいな事象が度々発生したが、柔軟に自家製ライブラリへ乗り換えられた • ドメイン駆動設計 ◦
ドメイン知識豊富な人の暗黙知が実行可能なPHPコードとして形式知化された ◦ ドメインモデルがアプリケーション層から独立しているため、クライアントアプリケーションの増加＝WebAPIエンドポイントの増設が簡単になった ▪ 最近で言えば海外販売クライアントやAIエージェント向けのエンドポイントなど • モジュラモノリス ◦ 技術的な意思決定の遅延を許してくれた ▪ モジュール間の移動がある程度出来たので、「一旦はこのモジュールに実装する（後で動かしたくなったら動かす）」という意思決定がカジュアルに行えた機能した要素（テクノロジーの変化に耐えた） 92

• 境界づけられたコンテキスト ◦ 組織図はよく変わったが、ビジネスモデルが大幅に変わらない限り境界づけられたコンテキストはびくともしなかった ◦ 「結果的には」逆コンウェイ戦略ぽくなったが、意図的ではない • モジュラモノリス ◦
プラットフォームエンジニアリングとして共通基盤を全モジュールに供給するのが容易だった ▪ 目的別組織が廃止され、占有チームがいなくなったモジュールに対して、共通基盤を供給してなんとか維持しようとする際に役立った（当時は死に物狂いだった・・機能した要素（組織の変化に耐えた） 93

• プラットフォームエンジニアリング ◦ トランザクション制御・例外制御・ログトレーシング・エラートラッキング・非同期処理基盤などの基盤技術が横断的な技術的関心事を巻き取ることで、ビジネス機能開発に使用できる時間を増やした ◦ 特に非同期処理基盤（誰でも少ないコードで非同期処理が作れる基盤）は圧倒的に利用された •
ただし、どちらかといえばビジネスニーズの変化には柔軟に応えることは出来なかったかもしれない・・ ◦ それは顧客価値検証に最適化された組織図によって賄っていたように記憶している ◦ アーキテクチャがビジネス整合性を維持しやすくすることで、新機能開発の余剰を生み出す・・・程度の遠い因果関係程度におさまる ◦ OwnershipTransferCostを最適化することで組織図に追従しやすくすることが課題か機能した要素（ビジネスの変化に耐えた） 94

• モジュラモノリス ◦ モジュールを往来すると社会性が消費されてしまうが、モジュールごとの作りが極端に大きくなければ、ゆうて同じリポジトリなので往来はしやすい ▪ 社会性消費の「単価」はモジュラモノリスだからこそ下げられていたように思える • モジュール占有 ▪
設計改善はあまり出来なかったチームもあったが、運用改善は相当やってくれた ▪ モジュール保守の責任を明確に与えることで、当人たちに意識にかなり変化があった、とのこと ▪ コアドメインチームの自走する姿を参考に、現在のセクション制へと横展開されたので、分散自律改善の作用を組織に広がる起爆剤としては大いに活躍した • クリーンアーキテクチャ ◦ SOLID原則などの設計原則がある程度強制される中で、ソフトウェア設計に関心を持つ人がわずかに出現 ◦ 「Webフレームワークとかどうでもよくなった」とのこと機能した要素（人・組織・文化的な影響） 95

• モジュール占有と継続的なリファクタリング ◦ 機能改修の都度ドメインモデルとコードを見直してリファクタリング、といった活動は限定的だった ◦ 課題にそもそも気づいていない、というチームも、本人たちに課題感はありつつもリリース圧力から逃げられない、というチームも両方ある ◦ 人や組織への価値観のアップデートが必要
◦ 自分の行った技術的意思決定が、長い時間をかけて自分に返ってくる、みたいな経験を積み上げないとコード品質の勘所はAI時代にも育たない気がしているので、今はまだ芽は小さいが、いずれ発芽してほしいという期待はある機能しなかった要素 96

• 暖簾分け効果 ◦ ※暖簾分け：新アーキテクチャの知見・設計思想・実装スタイルをじわじわ横展開し、組織全体に浸透させる草の根活動を社内では暖簾分け戦略と呼んでいた ◦ ゆっくりだが着実に効果はある、しかし４年経っても完遂しないあたり本当に遅い ◦ 「この人明らかに技術志向じゃないだろ」みたいな人が保守性の高いコードの興味を持ち始めたり、逆にいつまでも関心を持たない人もいたりする
◦ かつて目的別組織廃止の時、熱量の高かったチームも解散されたが、その時の残り火はわずかだがちゃんとまだ残っていて、じわじわ広がっている ▪ 第２世代、第３世代、みたいな広がり方をして初めて「機能した」と言えそう機能したかどうか半々な要素 97 ？

• 分散自律改善に全振りしてはいけない、ということにガッカリした人もいるかも知れない ◦ ただし顧客価値検証に全振りしてもいけない、という意味でもある • どちらにもやりすぎに注意・・・というより、時間の経過による変化に追従できるかどうかにコミットするほうが本質的かもしれない ◦ 境界づけられたコンテキストは移ろいやすい組織図よりも賞味期限が長いため、そういう意味でシステム構造を組織に反映しようとする逆コンウェイ戦略はある程度妥当だっ
たのかもしれない（４年前はむしろ嫌いなワードだったが） 4年間を経て思うこと 98

• 両者の溝を超えるには人と組織の質的変化が必要になってくる ◦ 「最終的には人」みたいな落とし所はよく聞くが、個人的にはそれとは言い方がちょっと違うと思う ◦ 人という資源を浪費しないように組織図とアーキテクチャを設計しているので、仮に全員が認知能力の上限がなく、ダンバー数も関係なく、システムの全貌を把握していて、十分な設計スキルがあるなら組織図もアーキテクチャもそもそもいらない ◦
要するに最終的に人にしわ寄せがいっている以上、それは単純に組織図とアーキテクチャの至らない部分である、という言い方のほうが自然 ▪ ただし、今回の仮説のように、両立はおそらくできない場合が多いので、最終的にはどうしてもしわ寄せはいってしまうのだが・・ • 溝を超えるための人と組織の変化には長い時間がかかるため、弊社も現在のセクション制のような体制には一足飛びにはいけなかったのだと思う 4年間を経て思うこと 99

• 仮に組織のスケール対策としてモジュラモノリスを採用しようとしているなら、そのモジュラモノリスは技術だけでは駆動しないはず、と考えています ◦ 分散自律改善が部分的にしか取り入れられない以上、溝の中で社会性が消費されていく環境になってしまいます ◦ そういう意味で、弊社のモジュラモノリスは人々の社会性を燃料に駆動しているのだと思います •
仮にモジュラモノリスを検討している方はトレードオフ構造が発生する前提で、人と組織の状態をどう更新していくかという観点を考慮することをおすすめいたします 4年間を経て思うこと 10 0

10 1 ご清聴ありがとうございました

モジュラモノリス導入から4年間の総括：アーキテクチャと組織の相互作用について / Archi...

モジュラモノリス導入から4年間の総括：アーキテクチャと組織の相互作用について / Architecture and Organizational Interaction

More Decks by Satoshi Kawashima

Other Decks in Technology

Featured

Transcript