「いいシステムを作っているはずなのに、なぜか現場にフィットしない」
そんな声が現場から聞こえるとき、問題の多くは“設計の根っこ”にある。
ビジネスの構造を正しく理解し、それをシステムにどう落とし込むか――。この問いに答える手がかりとなるのが、データ駆動、ドメイン駆動設計、マイクロサービスという三つの考え方だ。
それぞれはバラバラの専門用語に見えるが、実は順番に理解していくことで、ビジネスとITをつなぐ一本の線が見えてくる。その線をたどりながら、具体的なイメージで読み進めていく。
データは「業務の姿を映す鏡」
まず出発点となるのが「データ」という存在。
顧客が商品を注文した
営業担当が見積もりを修正した
倉庫で在庫が動いた
こうした日々の業務のひとつひとつが、システムに記録として残る。つまり、データは業務の“ありのままの姿”を写し取った鏡だ。
この鏡を使って「今何が起きているのか」「どこに問題があるのか」を判断し、行動を決める。この流れを意識した考え方がデータ駆動（Data-Driven）だ。
データは単なる報告の材料ではない。業務の判断・改善・自動化の出発点になる。
このように、データを中心に業務を見ると、「どんな情報が、どこで生まれ、誰が使うのか」といった構造が見えてくる。
そこで次に必要になるのが、その構造をしっかりと「言葉」で整理することだ。
ドメイン駆動設計：ビジネスの言葉で設計する
ここで登場するのがドメイン駆動設計（DDD）。
難しく聞こえるかもしれないが、やっていることはシンプル。「ビジネスの動き」をそのまま設計に落とし込むための考え方だ。
たとえば「注文が入ると、在庫を確認して出荷する」という流れがあるなら、
- 注文（Order）
- 商品（Product）
- 出荷（Shipping）
といった言葉でそれぞれの役割を整理し、その意味のつながりを設計として表現する。
このとき使われるルールが、ドメイン駆動設計のキモになる。
- ユビキタス言語：開発者も業務担当者も、同じ言葉で会話する
- エンティティと値オブジェクト：ものの「性格」と「性質」を区別する
- 集約と境界：ひとまとまりの業務単位で切り分ける
この整理がうまくいくと、開発の現場でも「この画面は注文ドメインの一部だ」と判断しやすくなる。ここでようやく、設計図をもとにした「システムの組み立て」に入れる。
ただし、ここで一つ課題がある。すべてを一枚岩で作ろうとすると、どこか一部が変わっただけで全体に影響が出てしまう。
それを防ぐための仕組みが、次の「マイクロサービス」につながっていく。
マイクロサービス：ひとつずつ部屋を分けて作る
マイクロサービスとは、システム全体を小さなかたまりに分けて構築する方法。一軒家ではなく、部屋ごとに入口も電気も独立したシェアハウスのようなイメージだ。
たとえば次のように、業務ごとに分けて実装する。
- 注文処理サービス（Order Service）
- 顧客管理サービス（Customer Service）
- 在庫管理サービス（Inventory Service）
それぞれが独立して動き、必要なときだけ連携する。
こうしておくと、
- 在庫のロジックを変更したい
- 顧客情報の扱いを強化したい
という要望が出たとき、他の部分に影響を与えずに修正できる。
ビジネスの単位に合わせて、技術も小さく区切る。これがマイクロサービスの本質であり、ドメイン駆動設計と非常に相性が良い。
つまり、「業務の構造をデータで見える化し」「それを言葉で分け」「それぞれを小さな部屋として実装する」という流れが、一貫した設計思想になる。
すべてをつなぐ鍵は「設計の目線」
ここまでの話は、業務をアプリに落とし込む流れをわかりやすく表現したものだ。
- データ駆動：今を映す鏡から出発する
- ドメイン駆動：その鏡に映った意味を言葉で整理する
- マイクロサービス：意味のかたまりを部屋として分けて動かす
この流れに共通するのは、ビジネスの動きを構造としてとらえ、それに合わせて技術を設計するという視点だ。
Google CloudのアーキテクトであるGregory Mooreはこう語っている。
「アーキテクチャは、もはやITの問題ではない。ビジネスの形をどう作るかという“経営設計”の問題だ」
まとめ
ビジネスの動きをそのままシステムに落とし込むことは難しい。しかし、考える順番を整理すれば、そこに明確な道筋が見えてくる。
- データで業務の動きをとらえる
- ドメインで意味を言葉にする
- マイクロサービスで小さく分けて組み立てる
この三つを結びつけると、変化に強く、理解しやすく、継続的に改善できるシステムが見えてくる。
業務を支えるアーキテクチャを“自分の目で見える形”にする
その第一歩として、まず「言葉」と「構造」をそろえる設計の力が求められている。