【歴史】ソフトウェアは会社の歴史である──ドメイン駆動設計から考える、本当に設計すべきものとアーキテクトの役割

この記事は「ドメイン駆動設計（Domain-Driven Design = DDD）」というソフトウェア設計の思想のお話です。

難しそうな名前に聞こえますが、本質は非常にシンプルです。 ここで言う「ドメイン」とは、技術のことではなく、「そのシステムが解決しようとしている、現実世界のビジネスや業務そのもの」を指します。

例えば、銀行のシステムを作るとき、最も重要なのはプログラミングの最新技術ではありません。「預金」「為替」「融資」といった、銀行独自のルールや業務の仕組み（＝ドメイン）を完璧に捉えることです。

従来の開発では、「データベースをどう作るか」「画面をどう繋ぐか」というシステム側の都合（技術）から設計を始めがちでした。ドメイン駆動設計では、「まず現実の業務ルールを深く理解し、その構造をドメインモデルとして整理した上で、ソフトウェアへ反映していく」というアプローチを取ります。

なぜこれが重要なのか。 それは、現実のビジネスの境界線を無視してシステムを作ってしまうと、組織の都合や過去のしわ寄せによって、ソフトウェアが内側からガタガタに崩れていくからです。

1. システム開発が難しい理由は、技術ではない。

仕様書をどれだけ読み込んでも、現実と実装が噛み合わない。そんな経験をしたことはないでしょうか。

原因は、仕様書にはありません。 仕様書は「結果の断面」であり、その裏には何年も積み重なった組織の事情、過去の失敗、契約、政治、物理制約があります。

ソフトウェアとは、それをつくった会社、あるいはチームの歴史そのものなのです。

真に理解すべきは仕様そのものではなく、その一見不条理に見える仕様を生み出すに至った背景、すなわち「文脈（コンテキスト）」です。過去の現場が直面した限界や力学を知らずに、ただ「美しくないから」という理由で綺麗事のリファクタリングを試みれば、必ず現場の物理現実に足元をすくわれることになります。

仕様書の文字面を「把握する」のは単なる作業です。その奥にある組織の歴史までをデバッグすることこそが、現場に立つアーキテクトに求められる真の役割です。

2. ピラミッド体制と「会話のできない会社間分担」

しかし、この歴史を紐解こうとするアーキテクトの前に、最大級の壁として立ちはだかるのが、ピラミッド型の開発体制です。

会社間の責務分担や多重下請け構造は、大人の事情（契約やガバナンス）という現実の力学であり、一エンジニアが綺麗事でひっくり返せるものではありません。

この体制がもたらす最悪の歪みは、「会社間に見えない壁が存在し、自由に質問ができない」という機能不全です。仕様の「なぜ」を確認したくても、何層ものマージンと伝言ゲームを経て返ってくるのは、「仕様書通りに作ってください」という冷徹な回答だけ。これでは文脈に辿り着くことなど不可能です。

ここで多くの開発現場が罠に陥ります。この「会話ができない組織の壁」をそのままソフトウェアの境界に適用し、チームの都合だけを優先したシステム分割を始めてしまうのです。

私自身、産業データインテグレーションや制御系の現場で、一つのチームの責務を閉じるためだけに一つの独立したプロセスを割り当て、結果としてシステム全体の性能を根底から破壊していくような設計を何度も目にしてきました。組織のコミュニケーション不全をソフトウェアの物理的な実行単位で解決しようとすれば、設計は瞬く間に破綻へと向かっていきます。

3. 主役は「組織」ではなく「ドメイン」である

なぜ、このような破綻が起きてしまうのでしょうか。理由は明確です。設計の「順番」を間違えているからです。

日本の現場では、阿吽の呼吸や暗黙知によって、明文化されていない問題を乗り越える文化があります。人間同士の社会において、これは間違いなく大きな強みであり、美しい美徳です。

しかし、そのグラデーションの曖昧さをそのままソフトウェアへ持ち込むと、機械はその曖昧さを理解できません。機械には、人間の温かい共鳴や空気感は一切通用せず、どこまでも冷徹に、1か0かの明確な境界線を要求してきます。

人間の曖昧な共鳴に甘えてドメインの境界設計をサボり、先に「組織の都合」でシステムを区切ってしまうと、機械はその歪みを冷徹にシステムへと反映します。結果として、次のような地獄絵図が完成するのです。

リソースは細切れになり、開発効率は最悪に落ち込み、群がっている人数の割にはまったく機能開発が進まない。これは、人間の「優しさ（曖昧さ）」のツケを、機械のリソースが冷徹に支払わされている状態に他なりません。

だからこそ、現場のアーキテクトが絶対に譲ってはならない一線がここにあります。

1. まず、ドメイン（責務境界）が先である ：人間の都合や組織の力学を一旦完全に脇に置き、ビジネスや物理現実が求める本来の「ドメインの境界線」を、機械に対してどこまでも冷徹に、美しく設計します。

2. チーム（体制）は後である：その冷徹に定義されたドメインの境界線に基づいて、初めてチームを編成し、各会社の責務をマッピングしていきます。

この順番を死守して初めて、会社間の「自由に質問できない」という歪みを、美しく堅牢なインターフェースの境界によってカプセル化（ブラックボックス化）できるようになります。冷徹な境界線を引くことこそが、結果として、現場の人間たちを不条理な破綻から守る唯一の手段なのです。

4. 技術の未来を矛盾なく接続するために

アーキテクトの仕事とは、全体仕様を把握したりすることだけが仕事ではありません。

仕様書の裏にある歴史を読み解き、 組織の歪みと技術の境界を切り分け、 未来まで壊れない構造を設計すること。

現場には、どうしても変えられない制約があります。
だからこそ、その制約を言い訳にせず、システムの本質だけは守り抜く。

 会社の歴史と、技術の未来を、矛盾なく接続すること。

それこそが、アーキテクトの「ドメイン（責務）」だと考えているのです。

さらに深堀りしたい方へ：

DDDの入門書でありながら、原典（エヴァンス本）以上に「ビジネス戦略」や「組織の境界」と「ソフトウェア構造」の接続にフォーカスした名著です。記事で触れた「業務領域（発見）と区切られた文脈（設計）の違い」や、コンウェイの法則をどうカプセル化するかという「戦略的設計」の視点が極めてクリアに言語化されています。

「コンウェイの法則（組織構造がシステム構造を形作る）」を逆手に取り、「ドメイン（境界）に基づいていかにチームを再編成するか（逆コンウェイ戦略）」を具体的に論じた一冊です。まさに記事の核心である「主役はドメインであり、チームは後」という思想を、組織論・マネジメントの側から補強してくれます。

日本の実際の開発現場における「曖昧な業務仕様」や「混乱したドメイン」を、どのように整理して堅牢なオブジェクト指向設計（コード・モデル）へと落とし込んでいくかを泥臭く解説したベストセラーです。記事冒頭の「仕様書は結果の断面に過ぎない」という問題意識を持った実務者が、手元で実践に移す際の架け橋となります。