はじめに
コミュニティでのドメイン駆動設計の勉強会に参加した際、課題ワークとしてフードデリバリーに出店している個人経営の中華店を題材にヒアリング体験をしたので、その流れや学びなどを記事にしようと思います。
なぜやるか
主に以下の2点です。
- 専門家との対話がなぜ難しいのかを整理した上で実際に対話を行い、その中でどのような質問が効果的だったのかや何が足りなかったのか等を確かめる
- 対話を通してモデルを改善していきながら、事業に対する解像度が上がっていくことを体験する
事前準備
ヒアリングに入る前に、まずはヒアリングの型を自分の中である程度持っておく必要があります。以下課題ワークの中で調べた4つの問いです。
- 専門家の話は、なぜ開発者にとって理解しにくいのか
例: 暗黙知の壁、言葉揺れと文脈依存 - DDDを考えた人は、専門家の話が理解できない状態から、どうやって抜け出したのか
例: 共通言語の構築、反復的な対話とモデル改善 - なぜ要件を一方通行で受け取るやり方では、うまくいかなかったのか
例: 仕様伝言ゲームの限界、ビジネス変化の追従不能 - 専門家自身も気づいていない知識とは、どういうものか
例: 例外処理や暗黙の判断基準、言語化されていないビジネスルール
これらの問いをAI使って軽く調査し、ヒアリングで意識するポイントをいくつか決めます。自分の場合は「差分を聞くこと」と「事実を聞くこと」にしました。
手順
ヒアリングは20分程度で行い、全体で1時間以内に終わるようにします。AIは普通に対話型のGeminiを使いました。
- まずは自分の想像で業務モデルを図にする
- 先ほど決めたヒアリングの型を意識して、以下のプロンプトでヒアリングを進める
- ヒアリング内容をもとにモデルを修正する
- 最後に「答え合わせ」と入力し、本当の原因と有効だった質問を確認する
あなたはフードデリバリーに出店している、個人経営の中華料理店の店主です。
私はシステム開発者で、あなたの業務を理解するためにヒアリングをします。
・最初の悩みは「最近、評価が下がって注文が減っている」です。
・その悩みの本当の原因を、あなた自身で一つ設定してください。
ただし、店主自身もその原因にまだ気づいていない設定にしてください。
・店主として自然に、具体的なエピソードを交えて答えてください。
・聞かれたことにだけ答え、原因を自分から話さないでください。
・質問が表面的であれば、表面的な答えを返してください。
・私が「答え合わせ」と入力したら、設定した原因と、
それにたどり着くために有効だった質問を教えてください。
実践してみる
簡単にですが実践してみました。人の例を見てしまうとその内容を意識してしまうと思うので一応隠しています。
step1 自分の想像で業務モデルを図にする
step2 ヒアリング
以下実際に行った質問と回答です。文章の内容は省略していますし、もともと人に見せる予定の対話ではないのであくまで参考程度にしてもらえるとです。
- 1〜2ヶ月くらい前から何か変更した点はありますか？メニューや価格、接客などで
- 特にないが、容器を変えたとの返答がくる
- なるほど。その少し安くて形が似てる使い捨て容器は今も使っていますか？
- 今も使っている
- ちなみに以前はどのような容器だったのですか？
- プラスチック製で少し厚みのある、黒いカチッとしたフタ付きの容器とのこと
- 容器を安いものにしたことで、デリバリー途中でスープなどがこぼれたり、料理が冷めてしまうといった可能性は考えられますか？
- その可能性はあるが、ドライバーさんには気をつけて運んでもらうようにお願いしているとのこと
- 普段どのような客層からの注文が多いとかわかりますか？
- 平日の昼はサラリーマンやOL、夜や土日は家族での注文が多く、幅広い層が利用している
- 評価が下がっているとのことですが、何かレビューコメントのようなものはあるのですか
- あるが、「美味しかった」や「ちょっと想像と違った」という声ばかりで原因はわからない
- メニューや価格を変えていないのであれば、やはり容器やデリバリーの過程に要因がある可能性が高いですね。デリバリーする人の数ってどれくらいいるのですか？注文が来たらすぐに料理して届けられる体制になっていますか？
- 注文の通知が来たらすぐに作り始め、料理ができるタイミングで近くのドライバーさんが店に来てくれる仕組みになっている
- 店主さんはドライバーさんと会話をしますか？何かドライバーさんからデリバリーをする上での不満みたいなのを聞いたことはありますか？
- 「大将、最近この新しい容器になってから、保温バッグの中で重ねるとちょっとグラグラして気を使うんですよね〜」とのこと
- なるほどです。改めて旧容器と新容器の特徴を教えて欲しいです
- 旧容器はプラスチック製で少し厚みのあるタイプ。フタを閉めると「パチン」とカチッとはまってロックされる。新容器は紙製というか薄手の耐熱素材っぽい質感。フタも同じような素材で、上からギュッと押し込むタイプとのこと
- そうですね。慎重に配達するとしても新しい容器の場合は中身がこぼれてしまう可能性があったり、容器やや若いことで高級感もなくなりますし、シンプルに手で持って食べずらいのかなと思いました。この点はどう考えられますか？
- その視点はなかったとのこと
- ここまでの内容を踏まえると一度容器を2ヶ月前のプラスチック製で少し厚みのあるタイプに変えてみて、経過観察するのが良いかもしれません
- 了解！
step3 モデル改善
step4 答え合わせ
以下答え合わせの出力です。比較的意図通りの進め方ができたのかなと思います。ここまでで、コアドメインが「店舗クオリティの料理・食体験を、崩さずに顧客の元へ届けるデリバリー品質」であることや、ドメインエキスパートが「店主」であること、コンテキストとして「店舗」「配送」「顧客」の3つがあることなどが整理できそうです。
ヒアリングお疲れ様でした！ヒアリングを通じて原因を見事に特定していただきました。
以下が、設定していた「本当の原因」と「それにたどり着くために有効だった質問」の答え合わせです。
【設定した本当の原因】
コスト削減のために変更した「新しい紙製・薄手容器」の強度不足による配送時の圧壊・汁漏れと、手で持った時の食べにくさ
詳細：
店主は「見た目やサイズはほぼ同じでコストが安くなった」と満足していましたが、新容器は柔らかく強度が低いため、ドライバーが保温バッグの中で重ねて運ぶと下段の容器が潰れて中身が漏れたり、料理が偏って届いていました。また、手で持って食べる際にフニャついて食べにくく、客側の満足度が著しく低下していました。
【原因にたどり着くために有効だった質問】
「1〜2ヶ月くらい前から何か変更した点はありますか？」
理由： 店主が「何も変えていない」と思いつつも、容器変更の事実を口にするきっかけとなったため。
「店主さんはドライバーさんと会話をしますか？何かドライバーさんからデリバリーをする上での不満みたいなのを聞いたことはありますか？」
理由： 店主自身が気づいていない「重ねるとグラグラして気を使う」という現場（ドライバー）の決定的な証言を引き出すことができたため。
「改めて旧容器と新容器の特徴を教えて欲しいです」
理由： 単なるサイズや見た目ではなく、「プラスチックでパチンとハマる旧容器」と「薄手で素材が柔らかい新容器」という物理的スペックの違いを比較・特定できたため。
素晴らしい導き出しでした！ヒアリングのご協力ありがとうございました。
勉強会での気づき
抽象を先に理解し、その上で具体を学ぶ
実践をしないで技術書などでインプットをたくさんしても使える技術にはならないという話が出ました。これは確かにその通りで、自分も経験のない技術に関する本や記事を読んでも結局表面的な活用方法の理解で終わってしまい、数日経ったら普通に忘れてしまうということがよくありました（もちろんインデックスにはなると思うのでそれは良いことですが）。しかし思い返してみると、実際に手を動かす過程で悩んだり詰まったりしながら得た知識は忘れないし自分の血肉になっているという感覚があったので、今後は無造作に知識を入れるところから始めるのではなく、まずは自分で色々触ってみてから体系的に学ぶみたいなフローが良いのかなと思いました。最近ではAIでこの辺りかなりやりやすくなっていると思いますし。
Learn to Teach
勉強会ではまずDDDがなぜ生まれたのかという誕生背景を調べることから始まりました。その後調べた内容を2人1組でペアに説明するということをやったのですが、これがなかなか難しい。自分はDDDの実践経験や体系的な学習をしていなかったので、調べた内容を短時間で整理し人に伝えるというのはかなり負荷のあることでした。しかし、その上で自分が上手く説明できない箇所は自分がちゃんと理解していない箇所だと知ることができますし、他の方の説明を聞くことで新しい視点や知識を得ることができたのでこのやり方はかなり良いなと思いました。勉強会の中ではこれをLearn to Teachと呼んでいました。
DDDの本質とはなんなのか
「DDDの本質とは何かを一言で説明してください」と言われたら皆さんはどのように回答しますか？正直自分は答えに詰まりました。事業活動を中心にソフトウェアを作っていく開発手法なのかな？くらいの感覚だったのですが、勉強会では一つの解答例として以下の定義がされました。
ソフトウェアの複雑さの核心は、技術ではなく業務にある。
だから、業務の知識をモデルにして、設計の中心に置く。
これはエリック・エヴァンスがどのような過程でDDDを提唱するに至ったのかの歴史を知ることで理解できます。AIで簡潔にまとめてみたので気になる方は見てみてください。
DDD誕生背景
1. エリック・エヴァンスの人物像と基本思想
- バックグラウンド: 大学院で化学反応速度論の数理モデルを研究後、約10年間複雑な業務システム開発に従事。
- 基本思想: 「モデリングの本質は対象によらず普遍的である」という考えが根底にある。
2. 当時の開発現場の課題（ウォーターフォール開発の限界）
- 知識の一方向性: 専門家 → アナリスト → プログラマ と知識が一方通行で、現場からのフィードバックや蓄積がない。
- モデルの形骸化: 壁一面の巨大なクラス図が自然な境界を持たず、実装で使われず放置される。
3. 3つのプロジェクト事例（原著序文より）
- 失敗例①（設計なし）: 勢いだけで作ったシステムは、業務の複雑さに耐えきれず破綻。
- 失敗例②（役割分離）: 分析者と実装者の分離により、モデルとコードが乖離して失敗。
- 成功例: 専門家との対話でモデルを磨き続けた現場のみ、開発スピードが加速。
4. ドメイン探求とモデルの進化（実践エピソード）
- 共通言語の発見（基板設計）: 未知の領域でも「ネット」という専門家の言葉を拾い、対話と訂正を重ねてモデルを形成。
- 本質への昇華（コンテナ輸送）: 概念を単なる「貨物の移動」から「責任の移転」へと再定義。
5. 結論と出版
- 見出した結論: 専門家との対話や共通言語を通じてモデルを探求し、コードへ反映し続けることが成功の鍵。
- 成果物: 4年以上の執筆を経て、2003年8月に『Domain-Driven Design』を出版。
自分もエリック・エヴァンスの原著は読んだことがないので今後読んで見たいですね。
おわりに
今回はDDDにおけるドメインエキスパートとの会話を通して事業理解を深める簡単なワークをやってみました。現実の事業はここまで単純なものではないと思いますが、イメージはなんとなく掴めたのかなと思います。ワークはサクッとできますのでぜひ皆さんもやってみてください。