この記事は、顧客との要件整理や認識合わせに関わるエンジニア・営業・PM向けに、ドメイン駆動開発（DDD）を「難しい設計論」ではなく、「顧客が本当に必要だったもの」を見失わないための実践として紹介します。
発注側・事業側の方にも、開発との会話を進めるうえでのヒントとして読んでいただければ嬉しいです。
DX化、だいぶ前から流行ってますよね。
でも未だに失敗例もよく聞きます。
「顧客が本当に必要だったもの」って、ITやっている人なら知らない人はそう多くないと思います。
知らない方は検索してみてください。画像1枚で「あるあるあるある」ってなれる、秀逸なやつです。
DX化がなぜ失敗するのか、あの画像にだいたい詰まってる気がします。
エンジニア的には「営業が〜」って言われがちなんですが、個人的には営業だけが悪いわけじゃないと思っています。
顧客・営業・エンジニアの間で言葉の意味がずれていると、誰かが「通訳」しない限り認識はすれ違いやすくなります。
しかし、毎回その役割を個人に頼るのは難しい。だからこそ、最初から共通言語を作っておく必要があります。
そこで「ドメイン駆動開発」を採用してみるのはいかがでしょう？
「ドメイン駆動開発」って聞いた瞬間に引くのは、いったんストップで！
ドメイン駆動開発（DDD）については調べればいくらでも出てきます。理論とか複雑なことも色々書いてあって、正直めんどくさく見えるかもしれません。
でも、 全部を理解する必要はない です。
とりあえず注目してほしいのは、この「ドメイン」の部分。
ドメインとは？
ここでいう「ドメイン」とは、その業務や現場において本当に重要な物事を指します。
そう、「顧客が本当に必要だったもの」です！
必要とされている「本質」だけを定義していきます。
ここで「ユビキタス言語」として書き出していくんですが、ざっくり言うと、
- 顧客
- 顧客現場
- 営業
- エンジニア
この全員の共通認識をすり合わせて、同じ単語・同じ文脈で話せるようにしようね、って話です。
例えば、現場で使われてる「申し込み完了」と、エンジニアが考える「申し込み完了」、これだけでも認識にズレが生じる事はなんとなくわかるかと思います。
（現場では支払い完了までを指しているが、エンジニアはデータが登録されたら、とか）
こういった些細なズレが開発が進むにつれ大きな歪みになり、（欲しかったものと違う…）となりやすいのです。
だから先に、関係者みんなで言葉の意味を揃える必要があります。DDDでいうユビキタス言語は、そのための道具です。
こういったズレを減らす為、箇条書きでいいので全体でつかう共通の「用語集」を作っておこうという事です。
みんなが同じ言葉を同じ意味で使えるなら、「通訳」はいらないですよね。
ここはコストをケチらず、些細な相違もちゃんとすり合わせましょう。顧客、顧客現場、営業、エンジニア、全員で、 です。
コストはかかるかもしれませんが、ここは妥協しないほうがいいです。
ここにコストをかける事で、「顧客が本当に必要だったもの」からズレてしまいにくくなります。
その時点で関係者が認識できている「本質」を、まず言葉にして揃える。
そして、開発や運用の中で見えてきたものは更新していく。
やってみないとわからない、もあるとは思いますが、開発しながらでも新しく出てきた用語はドメインに追加して更新していけばズレを減らせます。
上流で炎上する話、よく聞くけど
「上流での設計がきちんとしていれば炎上しなかったのに…」
「設計が突然変わって炎上した…」
みたいな話、よく聞きます。
しかし、ドメインを先に定義しておけば、少なくとも認識ずれによる手戻りや混乱は減らしやすくなります。
問題が起きたときにも、「どこで認識がずれたか」を見つけやすくなります。
追加要件が出てきたら、それもドメインに書き出していきましょう。
とりあえず走り出す開発の誘惑
とりあえず走り出す開発手法は、確かに初期コストが低いかもしれません。リリースも早いでしょう。
しかし、まず用語だけでもコストをかけてすり合わせをしたほうが、結果的にいいものを提供できます。
顧客にも「まずすり合わせから始めませんか？」って説得して、そこから始めてみませんか？
そのほうが最終的に、コストもリスクも下げられるし、ちゃんと“本当に必要なもの”が作れると思いませんか？
最初から全部を決める必要はありません、走り出してからやっと出てくる本質もあるでしょう。
ただ、少なくとも用語をある程度揃えてから進めたほうが手戻りも少なく、ゴールが明確になると思うのです。
走り出してから見つかったドメインは追加して更新していけばいいのです。
まとめると
開発がうまくいかない背景には、顧客・営業・開発の誰か一人ではなく、関係者のあいだで「本当に必要だったもの」の認識が揃いきっていないことがあります。
この「ドメイン」をすり合わせて作ることで、
- 本当に必要なもの
- 見えていなかったもの
- 本当は不必要なもの
いろいろ出てきます。
もし何から始めるか迷うなら、まずは次の3つだけでも十分です。
- 顧客・営業・開発で頻出する用語を10個書き出す
- その言葉の意味が人によってずれていないか確認する
- 新しく出てきた言葉は都度更新する
完璧な設計書を最初から作るのではなく、まず共通言語を作るところから始めるだけでも、開発のズレは減らせます。
「顧客が本当に必要だったもの」を正しく定義して、開発・運用して、
本当の「DX化」を実現しませんか？