DDDは今も“武器”になるのか？
ここ1年でプロダクト開発の環境は大きく変わりました。
AIエージェントが開発現場で“当たり前”のように使われる時代になりつつあります。
そんな中で、「DDD(ドメイン駆動設計)って今の時代にも必要なの？AI時代になったらもう使わなくなるのでは？」と疑問に思う方もいるかもしれません。
私はこう思います。
DDDは、AI時代にこそレバレッジを効かせることができる、価値を届けるための“武器”になる。
(少なくとも、あと数年はね。)
DDDの目的は「機能性」と「保守性」を両立させること
DDDは単なる設計理論ではなく、プロダクトを継続的に改善・成長させていくための戦略です。
その本質は、以下の2点に集約されます。
① 機能性を高めるためのモデリング
ユーザーや業務の課題を理解し、抽象的な図を使ってFBサイクルを小さく・速く回すことにより、役に立つものを作れる可能性を高めます
② 保守性を高めるための実装パターン
ドメインモデルを そのままコードに反映する実装パターンを適用します。
モデルの頻繁な更新にも耐えうる柔軟性を持ち、同時に高凝集・低結合で保守性の高い実装を実現します。
AI時代のDDD：モデリングと実装の再分担
AIがコードを書く時代において、DDDの価値はどう変わるのでしょうか？
モデリングは(相対的には)AIに代替されにくい領域
モデリング──つまり「問題をどう捉え、どう構造化するか」という思考は、現時点では人間の洞察力が必要な領域です。
ユーザーにヒアリングをしてPCの中にない情報を得ながら問題と向き合う、複雑な業務やユーザーの文脈に根ざした課題を整理する、というのはAIが手を出しにくい領域です。
むしろ、AIに実装を任せられる今だからこそ、人が“考えること”に集中できる余地が生まれているとも言えます。
実装パターンはAIと相性がいい
ある程度型がある設計パターンをAIに学習させることで、保守性の高いコードを自動で生成することができます
ただし、そのAIが出力するコードの意図や意味を理解し、必要に応じて修正・判断できる人間の力は必要になります。(少なくとも、もうしばらくは。。)
以上を踏まえると、モデリングと実装パターンの両面からDDDを正しく理解し、活用できることが、AI時代において大きな武器になると考えています
モデリングの価値とは何か？
DDDの中核にある「モデリング」は、単に図を描く作業ではありません。
それは、価値あるプロダクトを作るために、本質的な問題を理解し、構造化するプロセスそのものです。
では、モデリングで扱う「モデル」とは一体何なのでしょうか？
DDDの文脈では、モデルとは
“問題解決のために作られた抽象化物”
と定義されます。
良いモデルとは何か？
良いモデルとは、定義から考えると 問題を解決できるモデル であると言えます。
どれだけ綺麗な図が描けても、課題に対する具体的な解像度が低ければ、結果的にプロダクトに落としたときに“なんか使いにくい”ものになってしまいます。
だからこそ、モデリングは単なる設計工程ではなく、価値を届けるための思考の手順として捉える必要があります。
モデリングの活用シーン
モデリングは、以下のように様々な場面で活用できます。
-
開発時に業務を理解し、より役立つものを作るために
ユーザー課題の構造を捉え、抽象的なモデルとして整理することで、必要な仕様をクリアにする。 -
得た知識をチーム内で引き継ぐために
得られた知識をモデルとして可視化しておくことで、スムーズなナレッジ共有が可能になる。 -
開発済み機能を“再理解”するために（リバースエンジニアリング）
すでに動いている機能をモデル化することで、その設計意図や背景を後から捉え直すことができる。
特に①の観点は、新規事業や不確実性の高い開発フェーズで力を発揮します。
モデリングは「いかに早く・正しく課題を構造化できるか」が問われる状況でこそ、有効な思考の武器になります。
モデリングの具体的手法と「4つのモデル図」
モデリングには多くの手法があります。
UMLやクラス図、イベントストーミング、RDRAなど、ツールや考え方の選択肢はさまざまです。
ただ、いざ実践しようとすると「どれを使えばいいの？」「どう始めればいいの？」と悩むことも多いのではないでしょうか。
そこで今回は、「まずこれだけやっておくと良い」という最低限のスタート地点として、4つのモデル図があります。
これに関しては、以下の記事で詳細に解説しています。本記事での説明は割愛します。
モデリングで意識したいポイント
-
業務を理解するためには、具体例が不可欠
この点は次のセクションで詳しく解説します。 -
モデリングは“成果物”より“プロセス”が大事
図を描くこと自体ではなく、「わからないことを明らかにし、知識を補っていく」行為が重要です。
モデリングは、学び・対話・発見のツールでもあります。 -
意思決定は常に仮説である
ドメインには不確実性がつきものです。最初のモデルはあくまで仮説として捉え、いかにフィードバックループを速く回し、仮説の解像度を上げていけるかが重要です。 -
モデル図は“ホワイトボード”のように扱う
仕様書のように確定したことだけを書くのではなく、理解を深めるために議論の途中の内容も図にしていきます。ただし、メンテするものは明確に決めて最新化しましょう。
なぜ「具体例」が必要か？
ここまでモデリングの話をしてきましたが、特に重要なのが 「具体例を出すこと」です。
なぜなら、具体例が出せないというのは、業務理解の解像度が足りていないサインだからです。
抽象的な図を描くこと自体は難しくありませんが、そこに現実のユーザー行動や業務フローが裏打ちされていないと、価値のあるモデルにはなりません。
逆に言えば、「具体例を出そうとすると詰まる場所」が、まだチームで理解できていない領域＝課題の種だとも言えます。
複雑なドメインを扱うプロダクトでは、抽象図だけで「分かった気になる」ことが起きがちです。
だからこそ、“実際には何が起きているのか”を具体的に言語化するプロセスが不可欠です。
どの程度の具体性が必要か？を意識しよう
モデリングにおいては、以下のような抽象度の階層を意識することが重要です。
- 抽象的なモデル図（概念構造）
- 具体例（業務・操作ベースの実例）
- 社内の有識者の声（文脈・背景知識）
- 実際のデータやログ
- ユーザーが使っている姿（観察ベース）
モデリングをする際に、
今、自分たちはどこまで見えているのか？
役立つものを作るために、どこまでが必要か？
と言ったことを意識してみましょう。
PdM経験からの学び：「百聞は一見にしかず」
最後に、私が1年半の間プロダクトにAIを組み込むPdM(プロダクトマネージャー)をしていた時に得られた学びについてお話しします。
当時、会社のカスタマーサクセスメンバーが「この機能、本当に必要なんですよ〜」と何度も話してくれていました。
でも正直、「なるほど、必要なんですね！」参考にしていた…のですが、本質的には腹落ちしていなかったのです。
ある日、実際にお客様がそのプロダクトを使っているダッシュボードを見た瞬間に、
「これ、普通に絶対に必要じゃん」 と、一気に納得しました。
“言葉”ではなく、“目で見て実感した”ことで実感として腹落ちしたのです。
恥ずかしながら、ログラスでエンジニアとして3年以上開発していましたが、PdMの体験をしてようやく学べたことでした。
人づての情報と、自分で実感・理解することの間には大きな差がある
「⚪︎⚪︎というお客さんが不便だといってました」を実装するのと、
「これ、解消したら絶対良くなります！」と力説できるものを実装をするのでは、納得感や、ひいては価値仮説の精度が大きく異なります。
問題解決する領域に深く入り込むとすると、心から納得して、良いプロダクト開発ができます。
モデリングやDDDも突き詰めると、これがやりたいことなのだと思います。
まとめ
冒頭で、
DDDは、AI時代にこそレバレッジを効かせることができる、価値を届けるための“武器”になる。
と書きました。この記事を通して、どう感じていただけたでしょうか。
AI時代になっても、プロダクト開発の本質は課題と価値に向き合うことは変わりません。
課題と価値に向き合って、良いプロダクト開発を目指していきましょう。
Discussion