なぜ企業システムは『顧客』の意味統一に失敗し続けるのかーー構造化設計・DOA・OOAD・DDDから考える意味論の連邦制あるいは「ゆるEA」

※本稿は同タイトルの記事として、Zennで2026年06月07日付けで公開されていたものを移行した。移行元は本稿のリンクのみ残し空になっている。

序文 — なぜ今、この文章を書くのか

本稿で論じる問題も、ある意味では同じである。

ぼくはこの問題について、おそらく20年以上考え続けてきた。

オブジェクト指向開発の流行の中、デマルコの著作群などでソフトウェア開発の基本を学んだ。

TOGAFなどのエンタープライズアーキテクチャ（EA）を実践しながら、SOAプロジェクトにも関わり、ドメイン駆動設計（DDD）も学んだ。

その間ずっと違和感があった。

なぜ企業は、何度も同じ問題に直面するのだろうか。

• 顧客とは何か。

• 契約とは何か。

• どのシステムを正とするのか。

• 誰が意味の変更を管理するのか。

その後も、マイクロサービス、Data Mesh、生成AI、AIエージェントと、新しい技術や方法論が次々に登場した。しかしぼくには、それらが全く新しい問題を扱っているようには見えなかった。

むしろ、過去に何度も議論されてきた問題が、別の言葉で再登場しているように見えた。

• Management Information Systems (MIS)。

• Information Resource Management (IRM)。

• 構造化分析設計。

• DOA。

• OOAD。

• ERP。

• SOA。

• DDD。

• EA。

• そして生成AI。

それぞれは確かに重要な進歩をもたらした。しかし同時に、それぞれが解決できなかった問題も残した。

AI時代になった今、ぼくはむしろ確信している。

ぼくたちが直面している問題の多くは、AIによって初めて生まれたものではない。

企業情報システムが半世紀以上にわたって向き合い続けてきた問題である。
本稿は、新しい方法論を提案するものではない。

また、特定の方法論の復権を主張するものでもない。

これは、ぼく自身が十年以上抱え続けてきた疑問に一区切りを付けるための試みであり、同時に、企業情報システムの歴史を意味統治（Semantic Governance）の歴史として読み直してみる試みでもある。

結論だけ先に述べれば、本稿の主張は単純である。

新しい技術や方法論が現れるたびに過去を捨てるのではなく、歴史から学ぶべきである。

なぜなら、技術は変わり続けるが、人間と組織は驚くほど変わらないからだ。

第1章　問題提起 — なぜ企業語彙は崩壊し続けるのか

企業情報システムの世界では、技術が変わっても繰り返し現れる問題がある。

営業部門では「顧客」と呼ばれているものが、会計システムでは別の意味を持っている。サポート部門ではさらに異なる定義で管理されている。商品、契約、在庫、売上、案件、組織といった企業活動の根幹を支える概念も同様である。

個々のシステムは動いている。個々の業務も回っている。しかし企業全体として見ると、同じ言葉が異なる意味で使われている。

結果として何が起きるのか。

MDMプロジェクトは難航する。BIレポートごとに売上が異なる。KPIの定義を巡る会議が終わらない。データレイクは巨大なデータの墓場になる。システム間連携のたびに変換ロジックが増殖する。

近年では生成AIやRAGの普及によって、この問題が再び注目されるようになった。AIは与えられた情報をもとに推論する。しかし入力データそのものの意味が組織内で統一されていなければ、どれほど高度なモデルを使っても結果は不安定になる。

Garbage In, Garbage Out (GIGO).

だが重要なのは、これはAI時代特有の問題ではないということである。

むしろ逆だ。

AIによって初めて問題が生まれたのではない。企業情報システムが誕生した時代から存在していた問題が、AIによって再び可視化されただけである。

本稿では、この問題を「意味統治（Semantic Governance）」の問題として捉える。

企業は「顧客」「契約」「商品」「勘定」といった比較的長寿命な状態を維持し続けなければならない。これらは一般にマスターデータと呼ばれる。一方で、受注、出荷、請求、承認といった業務処理は、その状態を絶えず変換し続ける。こちらはトランザクションデータと呼ばれることが多い。

企業活動とは、本質的には状態と変換の連続である。

情報システムの役割もまた、その状態と変換を正しく維持し続けることにある。

ところが現実のプロジェクトでは、変換ばかりが議論されることが少なくない。

どの画面を作るか。どのAPIを公開するか。どのサービスへ分割するか。どのイベントを発行するか。

それらはもちろん重要である。しかし、その処理の対象となる「顧客とは何か」「契約とは何か」という意味そのものの管理は後回しにされがちである。

その結果、処理は動いているのに、組織としての意味は崩壊していく。
興味深いことに、この問題を解決しようとする試みは過去にも何度も行われてきた。

ある時代には、業務プロセスを厳密に記述することで統治しようとした。ある時代には、企業全体のデータモデルを定義することで統治しようとした。ある時代には、標準化された業務モデルを企業へ適用することで統治しようとした。ある時代には、統一そのものを諦め、境界ごとの自律性を重視することで統治しようとした。

構造化分析設計、DOA、ERP、EA、SOA、DDD。

それらはしばしば互いを否定し合う技術史として語られる。しかし見方を変えれば、すべて同じ問題への異なる回答だったとも言える。

企業内で意味をどのように維持するのか。

その問いに対して、人々は何度も異なる解を試みてきたのである。

しかし振り返ってみると、どの方法論も万能ではなかった。

統一を強めれば柔軟性を失う。自由を与えれば意味が分裂する。中央集権は肥大化し、分権化は断片化する。

結局のところ、単一の方法論だけで企業語彙を永続的に維持することはできなかった。

それでもなお、企業はシステムを作り続けなければならない。

本稿の目的は、特定の方法論を礼賛することでも、過去の手法への回帰を主張することでもない。

むしろ、構造化分析設計、DOA、OOAD、DDD、ERP、EAといった方法論が、それぞれ何を解決し、何を解決できなかったのかを改めて検証したい。
そして、その歴史を踏まえた上で、現代の分散システム時代において必要となる「意味統治」のあり方を考察したい。

本稿の結論を先取りすれば、それは巨大な統一モデルでもなければ、完全な自律分散でもない。

企業語彙を維持するための最低限の契約を共有しながら、その差分を継続的に管理していく連邦的なガバナンスである。

その結論へ至るために、まずは企業情報システムが辿ってきた設計思想の歴史を振り返るところから始めたい。

第2章　構造化分析設計 ―― 「変換」の統治

企業システムの歴史を振り返ると、構造化分析設計はしばしば「オブジェクト指向以前の古い手法」として語られる。

しかし、この理解は正確ではない。

構造化分析設計が解決しようとしていた問題は、現在の業務システムでも依然として存在している。そしてその問題の多くは、今日でも構造化分析設計の道具によって最も明快に記述できる。

まず確認しておきたい。

企業業務システムの大部分は、状態変換システムである。

• 受注が登録される。

• 在庫が引き当てられる。

• 出荷が行われる。

• 請求が発行される。

• 入金が記録される。

こうした業務はすべて、
「ある状態を別の状態へ変換する」
という操作として理解できる。

構造化分析設計は、この変換を可視化し、管理し、統制するための方法論だった。

その代表的な成果物が DFD （Data Flow Diagram）である。

DFDは単なる業務フロー図ではない。

• どのデータが、

• どの処理を通過し、

• どのように変換され、

• どこへ渡されるのかを、

静的に記述するためのモデルである。

重要なのは、DFDがプログラムではなく業務そのものを対象としていた点である。

業務担当者が理解できる粒度で、

• 何が入力され、

• 何が処理され、

• 何が出力されるのか、

を表現する。

その意味でDFDは、人間が業務変換を理解するための認知ツールだった。

構造化分析設計ではDFDだけが使われたわけではない。

IPO（Input-Process-Output）、データ辞書（Data Dictionary）、構造化設計などの補助技法が組み合わされていた。

これらが目指したものは一貫している。

業務変換の可視化である。

• どこで。

• 何が。

• なぜ。

• いつ。

• どう変換されるのか。

それを人間が理解可能な形で記述しようとした。

今日の開発現場でも、この価値は失われていない。
むしろ失われているのは、その重要性への認識である。

実際、多くの業務システム開発では、画面仕様やAPI仕様は大量に存在する一方で、
「受注がどのような状態遷移を経て売上へ至るのか」
を全体として説明できる人間が存在しない。

個別機能は理解されている。

しかしシステム全体の変換構造は誰も把握していない。

この状況は、構造化分析設計が解決しようとした問題そのものである。

その意味で、構造化分析設計は過去の遺物ではない。

現在でも有効な統治技法である。

では、なぜ業界は構造化分析設計だけでは不十分だと考えるようになったのだろうか。

理由は単純である。

構造化分析設計は「変換」の統治には優れていたが、「状態」の統治には限界があった。

例えば顧客マスタを考えてみる。

顧客情報は多くの業務プロセスから参照される。

• 受注。

• 請求。

• 回収。

• サポート。

• マーケティング。

それぞれの処理はDFD上では整理できる。

しかし顧客という状態そのものを、システム全体でどう維持するかという問題は別である。

システム規模が小さいうちは問題にならない。

だが規模が拡大すると、複数の処理が同じ状態を共有し始める。

そこで登場するのが共通結合（Common Coupling）の問題である。

複数のプログラムが同じ共有データを更新する。

ある変更が予想外の場所へ波及する。

一箇所の修正が全体へ影響する。

いわゆる mutable shared state の問題である。

構造化分析設計は変換の流れを記述することは得意だった。

しかし共有状態そのものを統治するための強力な抽象化機構は持っていなかった。

その結果、大規模システムでは変更容易性が急速に低下していった。

1980年代から1990年代にかけてオブジェクト指向が支持を集めた背景には、この問題がある。

オブジェクト指向は状態と操作を同一の境界に閉じ込めることで、共有状態の暴走を抑制しようとした。

これは当時として合理的な解決策だった。

したがって、構造化分析設計とオブジェクト指向は単純な優劣関係ではない。

両者は解決しようとした問題が異なる。

構造化分析設計は変換を統治した。

オブジェクト指向は状態を局所化した。

問題は、その後の業界がこの違いを忘れたことである。

変換統治の重要性まで捨ててしまった。

業務システムの大部分は依然として状態変換システムである。

にもかかわらず、その変換構造を明示的に記述しないまま設計を進めることが常態化した。

結果として、多くの現場ではコードは存在するが業務モデルは存在しない。

処理は存在するが変換の全体像は存在しない。

構造化分析設計が残した最大の教訓はここにある。

企業システムにおいて、「何がどう変換されるのか」を理解せずに設計することはできない。

そしてその問題は、2026年の現在においてもなお解決されていない。

次章では、同じ時代に発展したDOA （Data Oriented Approach）が、この問題に対してどのように異なる方向から接近したのかを検討する。

構造化分析設計が変換を統治しようとしたのに対し、DOAが統治しようとしたのは状態そのものであった。

第3章　DOA ―― 「状態」の統治

構造化分析設計が「変換」の統治を目指したのに対し、DOA（Data Oriented Approach）は別の問題に向き合った。

企業は処理を維持しているのではない。

データを維持している。

• 受注処理は変わる。

• 販売チャネルも変わる。

• 組織も変わる。

• 法制度も変わる。

しかし企業は、その変化の中でも顧客、契約、商品、勘定といった中核的な情報を維持し続けなければならない。

DOAが注目したのはこの事実だった。

企業システムにおいて最も寿命が長いのはプログラムではない。
データである。

だから設計の中心に置くべきものもまたデータである。

これがDOAの出発点だった。

当時の議論ではERモデルが象徴的に語られることが多かった。

しかし、本質はER図という記法ではない。

さらにその上位にある概念データモデルである。

重要なのはテーブル設計ではなく、

• 「企業は何を顧客と呼ぶのか」

• 「契約とは何か」

• 「売上とは何か」

• 「商品とは何か」

という意味の定義だった。

つまりDOAが本来扱おうとしていたのはデータベース設計ではない。
企業語彙の統治である。

ここは後年かなり誤解された部分でもある。

日本ではDOAというとER図作成技法として理解されることが少なくない。

しかし本来のDOAはもっと上流を見ていた。

概念モデルのレベルで企業全体の意味体系を整理しようとしていたのである。

なぜそこまで必要だったのか。

理由は単純である。

変換は局所的に管理できる。

しかし意味は全社的に管理しなければならない。

• 営業システムの顧客。

• 会計システムの顧客。

• CRMの顧客。

• サポートシステムの顧客。

これらがすべて別の意味を持ち始めると企業全体が機能しなくなる。

BIで数字が合わなくなる。

システム間連携が破綻する。

マスタ統合プロジェクトが炎上する。

どのシステムを正とすべきか誰も分からなくなる。

今日で言えばData LakeがData Swampになる。

AIがシステムごとに異なる答えを返し始める。

しかしこの問題はAI時代に始まったものではない。

DOAが問題視していた時代から存在していた。

だからこそDOAは、個別システムの要件ではなく企業全体の概念モデルを重視した。

これは現代のDDDでいうBounded Contextを否定する話ではない。
むしろ逆である。

Bounded Contextが有効であるためには、その外側に何らかの共有された概念空間が必要になる。

境界を引くためには、まず何が境界を越えるのかを理解しなければならない。

その理解なしにコンテキストだけを分割すると、単なるサイロ化になる。

この点でDOAは重要な洞察を持っていた。

企業には局所最適だけでは済まない情報が存在する。

• 顧客。

• 契約。

• 商品。

• 組織。

• 勘定。

これらは部門を横断して利用される。

したがって完全なローカルモデルにはできない。

何らかの形で全社的な合意が必要になる。

もっとも、ここで注意が必要である。

DOAが常に成功したわけではない。

むしろ現実には数多くの失敗も生み出した。

特に1990年代から2000年代にかけて、日本ではDOAがしばしば教条主義的に運用された。

• 全社共通データモデルを事前に完全定義しようとする。

• あらゆる業務概念を中央集権的に管理しようとする。

• 全システムを単一モデルへ収束させようとする。

こうした試みはしばしば巨大な分析プロジェクトとなり、完成前に陳腐化した。

変化し続ける現実に対して、静的な完成形を作ろうとしたからである。

この問題は後のEAブームにも受け継がれる。

FEAFや経産省EAに代表される大規模エンタープライズアーキテクチャ構想は、多くの場合「あるべき全体像」を作るところまでは到達した。

しかし維持に失敗した。

• 完成図は存在する。

• だが誰も更新しない。

• 結果として図面だけが残る。

これはDOAの失敗というより、
「意味統治をプロジェクトとして扱った失敗」
だったと言える。

本来必要だったのは完成図ではない。

継続的な統治だった。

そしてこの問題は、後にOracle AIAや巨大SOAプロジェクトでも繰り返されることになる。

つまり第2章の構造化分析設計が変換統治の重要性を示したとすれば、第3章のDOAが示したのは状態統治の重要性である。

企業語彙を維持するためには、概念モデルが必要だった。

しかし概念モデルだけでは足りなかった。

問題はモデルを作ることではなく、変化し続ける企業の中で維持することだったのである。

そして、その維持問題こそが次章以降で扱うOOAD、SOA、DDD、EAへとつながっていく。

第4章　OOAD ―― 状態の局所化と構造の統治

1990年代以降、ソフトウェア業界はオブジェクト指向分析設計（OOAD) へ大きく舵を切った。

現在でも多くの開発者にとって、オブジェクト指向は事実上の標準的な設計思想である。

しかしここで改めて問わなければならない。

オブジェクト指向は何を解決しようとしていたのだろうか。

第2章で見たように、構造化分析設計は変換統治に優れていた。

しかし共有状態の管理には限界があった。

第3章で見たように、DOAは状態統治を目指した。

しかし変化する現実を静的モデルへ閉じ込める難しさを抱えていた。

オブジェクト指向は、この二つとは異なる問題に向き合った。
それはソフトウェア構造の複雑性である。

システムが巨大化すると、問題は業務モデルだけではなくなる。

• モジュール依存。

• ライブラリ管理。

• 再利用。

• 保守性。

• 変更容易性。

• 並行開発。

こうした技術的複雑性が急速に増大する。

オブジェクト指向は、状態と操作を同じ境界へ閉じ込めることで、その複雑性を管理しようとした。

• カプセル化。

• 継承。

• ポリモーフィズム。

• 後には依存性注入（DI）やIoCコンテナも加わる。

これらはすべて、
「システム内部の構造を管理するための技法」
として理解できる。

ここで重要なのは、オブジェクト指向が主として解決したのは企業意味論の問題ではないという点である。

例えば顧客クラスを定義したとしても、
「顧客とは何か」
は決まらない。

契約クラスを定義したとしても、
「契約とは何か」
は決まらない。

それらは依然として業務上の概念定義の問題である。

オブジェクト指向は、その概念をどう実装構造へ落とし込むかについては強力な道具を提供した。

しかし概念そのものを定義する理論ではなかった。

ところが1990年代後半から2000年代にかけて、特に日本ではオブジェクト指向がしばしば過大評価された。

• 「現実世界をそのままオブジェクトとしてモデリングする」

• 「クラス図が業務モデルになる」

• 「業務分析と設計を統一できる」

といった説明が広く流通した。

もちろん、それらには一定の真実が含まれている。
しかし現実には、企業業務は必ずしもオブジェクトとして綺麗に分解できるものではない。

• 企業は顧客を保持している。

• 契約を保持している。

• 商品を保持している。

• 勘定を保持している。

そして日々、それらを更新している。

本質的には状態と変換の世界である。

そのため多くの業務システムでは、クラス図よりも概念モデルや業務フローの方がはるかに重要になる。

実際、ERPや基幹業務システムの設計資料を見ると、経営者や業務担当者が理解するのはER図や業務フローであってクラス図ではない。

クラス図は実装者のための成果物である。

経営管理のための成果物ではない。

この点を見失うと、企業意味論の統治がコードの内部へ埋没していく。

そして後年、別の問題が発生する。

• システム間で顧客の意味が異なる。

• 商品コード体系が異なる。

• 契約概念が異なる。

• BIの数値が一致しない。

なぜか。

カプセル化が成功したからである。

各システムは独立して保守できる。

しかし独立して意味を変えてしまう。

つまりOOADは共有状態の問題を局所化した代わりに、企業全体の意味論を見えにくくした。

もちろん、これはオブジェクト指向の失敗ではない。

そもそも解こうとしていた問題が違うからである。

実際、現在のエンタープライズシステムはオブジェクト指向なしには成立しない。

• アプリケーションサーバ。

• フレームワーク。

• Webアプリケーション。

• DIコンテナ。

• ORM。

• クラウドミドルウェア。

これらの多くはオブジェクト指向的な抽象化の上に構築されている。

またSAP自身も、この問題をある程度理解していたように見える。

ECC時代のSAPは、業務意味論の中核部分をABAPベースの安定したモデルとして維持しながら、NetWeaverやWeb Dynproなどの技術基盤を追加していった。

つまり業務意味論と技術構造を異なるレイヤーとして扱ったのである。

評価すべきなのは技術選択そのものではない。

適用レイヤーを区別していたことである。

ここから得られる教訓は単純である。

オブジェクト指向は企業意味論を統治する道具ではない。

システム構造を統治する道具である。

企業意味論の統治をOOADへ丸投げすると失敗する。

しかしシステム構造の統治からOOADを排除しても失敗する。

必要なのは優劣ではなく役割分担である。

そして業界は、この役割分担を再び模索することになる。

一方ではSOAやEAが企業全体の意味統一を目指し、他方ではDDDが境界内部のモデルを洗練しようとする。

次章では、その二つの流れがどのように発展し、どこで成功し、どこで失敗したのかを検討する。

第5章　DDD — 分割統治の功績と限界

第4章で見たように、オブジェクト指向分析設計は、状態と振る舞いを局所化し、大規模ソフトウェアの構造を整理するための有効な手法だった。

しかし、企業システム全体という視点から見ると、別の問題が残った。

システムの構造は整理されても、企業全体の意味論は必ずしも整理されなかったのである。

例えば「顧客」という概念を考えてみよう。

• 営業支援システムにおける顧客。

• 受発注システムにおける顧客。

• 請求システムにおける顧客。

• サポートシステムにおける顧客。

それぞれは業務上の文脈に応じて異なる属性やルールを持つ。

この差異を無理に統一しようとすると、巨大で複雑なモデルが生まれる。

逆に各システムが独自に定義すれば意味の分裂が発生する。

ドメイン駆動設計（DDD）は、この問題に対する重要な回答だった。

DDDは、企業全体で唯一のモデルを目指さない。

代わりに、業務上の境界ごとにモデルを定義する。

これが Bounded Context である。

• 販売ドメインには販売ドメインの顧客がある。

• 請求ドメインには請求ドメインの顧客がある。

• 物流ドメインには物流ドメインの顧客がある。

それぞれの文脈の内部では、一貫した意味を維持できればよい。

この考え方は極めて現実的だった。

実際の企業では、同じ言葉が異なる意味で使われることは避けられない。

むしろ問題は、その差異を認識しないことにある。

DDDは「ユビキタス言語」という概念を通じて、各ドメイン内部の意味論を明確化した。

また Context Map によって、ドメイン同士の関係性を記述する方法も提示した。

この点でDDDは、それ以前の多くの手法が十分に扱えなかった「境界」を主題化したと言える。

これは大きな功績である。

しかし同時に、DDDだけでは解決できない問題も残った。

Bounded Context の内部を整理することと、企業全体を統治することは同じではない。

• 例えば経営指標を集計したい場合。

• あるいは監査や会計統制を行いたい場合。

• あるいは全社横断の分析基盤を構築したい場合。

Bounded Context の外側に立って複数のドメインを接続しなければならない。

そのとき必要になるのは、各コンテキスト内部の設計ではなく、コンテキスト間の関係性そのものである。

DDDは境界を発見することには成功した。
しかし境界間をどう統治するかについては、意図的に深く踏み込まなかった。

それはDDDの欠陥というより、守備範囲の問題である。

むしろ重要なのは、DDDを企業全体の設計理論へ拡張して解釈しないことだろう。

DDDは境界統治のための優れた道具である。

しかし企業全体の意味統治そのものではない。

この点を見失うと、

• 「全社統合モデルは不要」

• 「成果物は不要」

• 「コードだけが真実である」

といった極端な解釈に陥る。

だが企業システムは単一のアプリケーションではない。

長期間にわたり、多数のシステムと組織が協調しながら維持される社会的な構造物である。

Bounded Context は必要である。
しかしそれだけでは足りない。

次章では、実際のエンタープライズITがこの問題にどう向き合ってきたかを見ていく。

SAP、Oracle AIA、FEAF/経産省EA、そしてDDD。

これらは互いに競合する思想ではない。

むしろ同じ問題に対する異なる回答として理解できる。

第6章　SAPとOracle AIAが示したもの ― 人類は意味統治をどう試みてきたか

ここまで見てきたように、構造化分析設計、DOA、OOAD、DDDは、それぞれ異なる統治対象に焦点を当てた手法だった。

• 構造化分析設計は変換を統治した。

• DOAは状態を統治した。

• OOADは構造を統治した。

• DDDは境界を統治した。

しかし現実の企業システムは、単一の方法論だけで構築されるわけではない。

企業は常に、「全社として意味を維持する」という問題に直面する。

• 顧客とは何か。

• 契約とは何か。

• 商品とは何か。

• 売上とは何か。

こうした企業語彙をどのように維持するかという課題に対し、エンタープライズITは過去数十年にわたって様々な解答を試みてきた。

その代表例として、SAP、Oracle AIA、FEAF/経産省EA、そしてDDDを並べてみると興味深い。

これらはしばしば対立する思想として語られる。

しかし本質的には、すべて同じ問題への異なる回答だったと理解できる。

SAP ERP

まずSAPである。

SAP ERPが成功した理由について、「ベストプラクティスを提供したから」という説明がなされることがある。

しかし実態としては、必ずしもそれほど美しい話ではない。

SAPのモデルは、ある企業群の業務モデルを一般化し、パッケージとして提供したものである。

理論的に唯一正しい業務モデルが存在したわけではない。

むしろ重要だったのは、モデルの正しさではなく、モデルの一貫性だった。

SAPは顧客や商品や勘定科目の意味を全社的に統制した。

その代償として自由度は低下した。

ユーザーはしばしば「業務に合わない」「柔軟性がない」と不満を述べた。

しかしその不自由さこそが、意味統治のコストを前払いしていたとも言える。

SAPは意味の自由を制限することで、全体最適を実現しようとした。

ある意味で「統治による解決」である。

Oracle AIA（Application Integration Architecture）

一方、Oracle AIAは全く異なる道を選んだ。

OracleはSAP ERPのように単一アプリケーションで世界を統一しようとはしなかった。

既存の多数の業務システムを前提に、その上位に統合理論を構築しようとした。

その中心に置かれたのがEnterprise Business Object（EBO）だった。

• 販売システムにも顧客がいる。

• CRMにも顧客がいる。

• 請求システムにも顧客がいる。

ならば、それらを統合する共通の「顧客」モデルを定義すればよい。

発想そのものは合理的だった。

問題は、それを企業全体で実現することの難しさだった。

現実の業務は例外だらけである。

• 業種も違う。

• 地域も違う。

• 制度も違う。

結果としてEBOは巨大化し続ける。

すべてを包含しようとする共通モデルは、やがて誰も理解できないモデルへ変質する。

SAPが統治によって自由を制限したのに対し、AIAは統合理論によって自由を包含しようとした。
そしてその複雑さに敗れた。

FAEFと経産省EA

FEAFおよびその影響下で策定された経産省EAも、また別の回答だった。

ここで目指されたのは、アプリケーションや統合基盤よりさらに上位のレベルである。

企業全体の業務、情報、アプリケーション、技術を俯瞰し、全体構造を設計すること。

その思想自体は極めて妥当だった。

実際、本稿が主張している「意味統治を継続的に行う必要がある」という考え方は、本来のEAの思想と矛盾しない。

問題は、多くの現場でEAが巨大な完成図として扱われたことだった。

数年かけて全社モデルを描き、完成した瞬間に陳腐化する。

変化し続ける組織を静的な設計図で支配しようとした結果、EAはしばしば形骸化した。

理論が失敗したというより、運用モデルが失敗したのである。

そしてDDDは、その反動として登場した。

DDDは全社統一モデルを目指さない。

共通語彙の完成を目指さない。

各ドメインが自律的にモデルを管理することを認める。

この発想は、SAPやAIAやEAが抱えていた硬直性に対する有効な批判だった。

しかし同時に、境界の内側を重視するあまり、境界の外側の問題を残した。

• 分析基盤。

• 監査。

• MDM。

• 企業横断レポーティング。

• AI活用。

こうした領域では、依然としてコンテキスト間の意味統治が必要になる。

つまりDDDは境界問題を発見したが、境界間問題を消滅させたわけではなかった。

ここまで見てくると、一つの事実が浮かび上がる。

• SAPは意味を標準化した。

• Oracle AIAは意味を統合しようとした。

• FEAF/経産省EAは意味を全社的に設計しようとした。

• DDDは意味を分割管理しようとした。

どれも正しい。

そしてどれも単独では十分ではない。

重要なのは、どの手法が勝者だったかではない。

重要なのは、人類が長年にわたって繰り返し挑戦してきた問題が、実は同じ問題だったということである。

それは技術の問題ではない。

意味の問題である。

そして意味は、一度設計すれば終わるものではない。

継続的に維持されなければならない。

次章では、この歴史的な試行錯誤を踏まえ、本稿の結論である「意味論の連邦制」について述べる。

目指すのはSAPの再来でもなければ、Oracle AIAの復活でもない。

また、全社統合EAへの回帰でもなければ、DDD単独主義でもない。

必要なのは、企業語彙の差分を継続的に管理するための、より軽量で現実的な統治モデルである。

なお、Data Meshは分析基盤という特定レイヤー（いわゆるOLAP系）への適用例であり、本稿はそれを業務システム本体（OLTP系）まで含めた、より広い企業意味論の問題として扱うものだ。

第7章　意味論の連邦制 ― 「緩いEA」という現実解

ここまで見てきたように、企業情報システムの歴史は、意味統治の歴史でもあった。

• 構造化分析設計は変換を統治しようとした。

• DOAは状態を統治しようとした。

• OOADは構造を統治しようとした。

• DDDは境界を統治しようとした。

• SAPは標準化によって意味を維持しようとした。

• Oracle AIAは統合理論によって意味を接続しようとした。

• FEAF/経産省EAは全体設計によって意味を統治しようとした。

それぞれに成果があった。
そして、それぞれに限界もあった。

重要なのは、その失敗から「意味統治は不可能である」という結論を導くことではない。

むしろ逆である。

意味統治は必要である。

ただし、それは完成可能な設計物ではない。

継続的な活動なのである。

多くの議論では、統治の失敗はしばしば設計の失敗として語られる。

しかし現実には、最初の設計が間違っていたから問題が起きるのではない。

問題は、組織も業務もシステムも変化し続けることにある。

• 新商品が追加される。

• 法制度が変わる。

• 組織再編が起きる。

• 企業買収が行われる。

• 新しいシステムが導入される。

• クラウドサービスが追加される。

• AIエージェントが接続される。

こうした変化のたびに、「顧客とは何か」「契約とは何か」「売上とは何か」という定義は微妙に揺らぎ始める。

そして本当に危険なのは、その揺らぎそのものではない。

揺らぎがどこに存在するのか誰も分からなくなることだ。

企業システムの崩壊は、多くの場合、意味の差異そのものから始まるのではない。

意味の差異が不可視化されることから始まる。

だから本稿の結論は、「全社共通モデルを作れ」ではない。

また、「各ドメインに任せればよい」でもない。

必要なのは、その中間にある。

企業全体で厳密に統一すべきものは意外と少ない。

• 顧客。

• 契約。

• 商品。

• 勘定。

• 組織。

こうした企業の中核語彙については、最低限の共通理解が必要である。

しかしそれ以外の多くは、各ドメインが独自に定義してよい。

問題は統一することではなく、違いを管理することなのである。

この考え方は、ある意味ではDDDのContext Mapに近い。

しかし対象は単一システムではない。

企業全体である。

また、これは従来のEAにも近い。

しかし巨大な完成図を作ることを目的としない。

むしろ変化を前提とする。

言い換えれば、本稿が提案するのは「意味論の連邦制」である。

連邦国家では、各州が独自の自治権を持つ。

しかし通貨や外交や憲法のような基盤部分は共有される。

企業システムも同じである。
各ドメインは自律性を持つ。

• 販売は販売のモデルを持つ。

• 物流は物流のモデルを持つ。

• 会計は会計のモデルを持つ。

• 分析基盤は分析基盤のモデルを持つ。

• AIエージェントはAIエージェントのモデルを持つ。

それでよい。

重要なのは、その境界で何が起きているかを把握することである。

したがって、必要な成果物も意外なほど少ない。

第一に、企業語彙を表現する概念モデルである。
ここで重要なのは物理データベース設計ではない。
企業が何を管理し、何を識別し、何を共有するのかという概念レベルの記述である。

第二に、ドメイン間の責任境界を表現するコンテキストマップである。

• どのシステムがどの概念の責任を持つのか。

• どのシステムがどのデータの正本なのか。

• どの変換がどこで行われるのか。

これを可視化する。

第三に、高レベルのDFDである。
詳細設計レベルのDFDではない。
企業全体で見たときに、どの情報がどこからどこへ流れているのかを把握するためのものである。

重要なのは、これら三つを一度作ることではない。
変化のたびに更新し続けることである。

本来のTOGAF/ADMも、実はそのような思想だった。
EAは完成図ではない。
継続的なアーキテクチャ活動である。

しかし現実には、多くの組織でEAは巨大な文書作成プロジェクトへと変質した。

その結果、「重い」「役に立たない」「現場を知らない」という批判を受けることになった。

だが、それはEAという発想そのものの失敗を意味しない。
失敗したのは運用の仕方である。

本稿が提案する「緩いEA」とは、この原点への回帰である。

• 巨大な完成図は作らない。

• すべてを統一しようとしない。

• 中央集権的なモデルを押し付けない。

• しかし放置もしない。

• 最低限の企業語彙について責任を持ち、変化が発生したときには必ずレビューし、その影響を追跡する。

それだけである。
派手な話ではない。
革新的な理論でもない。
むしろ驚くほど地味な提案である。

しかし企業情報システムの歴史を振り返るならば、意味統治に特効薬は存在しなかった。

SAPも、Oracle AIAも、FEAFも、DDDも、それぞれ問題の一部を解決した。

しかし単独で問題全体を解決することはできなかった。

フレデリック・ブルックスが『人月の神話』や1986年の論文「No Silver Bullet」で既に述べたように、ソフトウェア開発には銀の弾丸は存在しない。

意味統治についても同じである。

SAPは標準化をもたらしたが自由度を失った。
Oracle AIAは統合理論を追求したが複雑性に敗れた。
FEAFや経産省EAは全体最適を目指したが静的計画へ傾きやすかった。
DDDは境界を明確にしたが、境界間の問題を消し去ることはできなかった。

必要なのは新しい銀の弾丸ではない。

• 状態を統治するための概念モデル。

• 変換を統治するためのDFD。

• 構造を統治するためのアーキテクチャ。

• 境界を統治するためのコンテキストマップ。

そして、それらの差分を継続的に管理するための緩いEAである。

企業システムとは、結局のところ「顧客とは何か」という問いに答え続ける営みなのかもしれない。

その答えは一度決めれば終わるものではない。

組織が存在し続ける限り、更新され続けなければならない。

※1

Zenn講評

しかし日本のエンタープライズITの問題は、この論考に「知的刺激」を受けるだけの感受性、理解力、歴史的知識、要するに知性のある者が殆ど居ないことだ。
知的刺激を受けたやつはコメントして行ってくれよな。

※2

「本来のTOGAF/ADM」という話をしているが、実はぼくの考えの元ネタはスコット・アンブラー Scott Ambler「エンタープライズ統一プロセス Enterprise Unified Process (EUP)」である、という種明かしをしておこう。「アジャイルモデリング」など彼の著作には多くを負っている。