新規事業で実践するディスカバリーとデリバリーをつなぐドメインモデリング駆動開発
「ディスカバリーとデリバリーの接続をスムーズにしたい」
プロダクトマネージャーやデザイナーからよく聞く話ではないでしょうか？
また、エンジニアからこんな話を聞いたことはありませんか？
「ディスカバリーで決まったものを開発するだけになっている。まるで社内受託のようだ。」
migi（@migii000）です。
カミナシでプロダクトマネージャー（ PdM ）をしています。
以前、デザイナーの satoami さんとの協働について社内でインタビューしてもらいました。
この note では「チームの中では境界線を曖昧にしてオーバーラップしながら開発をしている」的なことを書きました。チームが発足して半年ほどですが、開発プロセスがかなり機能している実感があります。
どんなプロセスで何をやっているのか、私たちのプラクティスをまとめるのがこの note の目的です。
はじめに：ディスカバリーとデリバリーの接続は難しい
冒頭の
「ディスカバリーとデリバリーの接続をスムーズにしたい」
「ディスカバリーで決まったものを開発するだけになっている。まるで社内受託のようだ。」
は、何を隠そう自分の実経験と身の周りで実際に聞いたことのある発言です。
プロダクト開発を円滑に進めたい PdM としては、世の中にあるいろいろなプロセスを試してきました。しかし、しっくりくるものに行き着けていなかったのが本音です。
過去には、デュアルトラックアジャイルでの開発や実例マッピング、ユーザーストーリーマッピングなどの「職種間で作るもののイメージを共有する」手法は試しました。
（前職の友人が実例マッピングの実践について、わかりやすい記事を書いているので併せてどうぞ）
それでも、先行して課題や価値のディスカバリーしているメンバーと、後からキャッチアップしながらデリバリーしていくメンバーとの間には情報量や解像度に差があり、認識のズレが生じていました。
結果的に、実装が進んだころに手戻りが発生したり、思ったより考慮できていないことが多くて開発規模が膨らんだり、認識を揃えるために何度も打ち合わせしたり… スタートアップらしく速度を出しながら、開発を進めるのは難しいのだなと思っていました。
そんな状況を克服したのが、今所属しているチームで実践している「ドメインモデリング駆動開発」です。
半年ほど実践していますが、自分が今まで経験した開発プロセスの中でもかなりうまくいっている実感があります。うまくいっている感は、チームで実施しているレトロの付箋をご覧いただけると伝わるのではないでしょうか。
ということで、この note では私たちの開発チームが実践している「ドメインモデリング駆動開発」のプロセスを紹介します。プロダクト開発の1つのプラクティスとして参考になれば幸いです！
「へー、使えそうだな〜」と思ったらいいね ❤️ やシェアをお願いします！
ちなみに、ドメイン駆動開発（ DDD ）とはコンテキストが異なります。
ディスカバリーとデリバリーの橋渡しに焦点を絞っていること
ドメインモデルの作成・活用に特化したプラクティスであること
つまり、DDD の概念の中からドメインモデルの部分に特化した手法です。
ドメインモデリングのプロセスを通じて、開発チーム内の共通言語をつくることが目的です。ディスカバリーはドメインモデリングの材料集めであり、ドメインモデリングによってデリバリーが始まります。
（ドメインモデリング is 何？は巻末の参考記事をご確認ください）
『ドメインモデリング駆動開発』の効果
書き出したらプロセスが長かったので、主な効果を先に紹介します。
チームが納得感を持って開発できるようになる
デリバリーしたものが顧客の価値につながっている
ユースケースの意識を揃えてモデリングしているので手戻りがない
PRDを書く必要・読む必要がない
ミニマムの開発ライン（ MVP ）をチームで見極められる
手前味噌ですが、かなり良さそうですね。
『ドメインモデリング駆動開発』のプロセス
この note では、以下のようなチームの開発について書いています。似たような状況な方が想定の読者です。
⚫︎BtoB SaaSを開発している開発チーム（私たちは、新規事業を立ち上げる0→1のタイミングです）
⚫︎チームには、PdM、デザイナー、エンジニアが在籍
・ディスカバリーはPdMとデザイナーが主導し、デリバリーはエンジニアが主導しています
・ディスカバリーは課題の探索、デリバリーは顧客への価値提供を指しています
また、ドメインモデリング駆動開発を進めるためには、以下のインプットが最低限必要です。
・作ろうとしている開発テーマで満たすユースケース
・チームが集中して話せるまとまった時間（オフラインが理想的です）
プロセスは以下のようなステップで進んでいきます。
1. 顧客の課題（大きな痛み）を見つける
2. ユースケースを洗い出す
3. オブジェクトモデル図を作る
4. ドメインモデル図を作る
5. UI と体験を詰める
6. 実装・リリース
7. 評価
ドメインモデリングの成果物は以下のようなものになります。それでは、各項目を詳しく紹介していきます！
1. 顧客の課題（大きな痛み）を見つける
このステップの目的は、チームがドメインモデリングを開始するのに必要な材料を集めることです。
対象とするテーマ（例えば権限管理や CSV エクスポートなど）について、顧客の既存業務フローやそのフローで現在発生している課題を発見します。
カミナシでは、課題の発見のためにお客様の現場に足を運んだり、インタビューさせてもらうことが多いです。インタビューの場では、簡易に画面を作成してスライドに貼り付けたり、モックを作成して挙動をイメージしてもらったり、いわゆる UX リサーチの手法を使っています。
（ちなみに自分たちのチームでは、”現場ドリブン”に収集した課題や気づきををインサイトマネジメントツールの「Centou」を使って管理しています）
発見した課題の中で、プロダクトで解くべき課題（大きな痛み）、プロダクトとして最低限満たすべきユースケースとあったらいいユースケースを仕分けして、顧客がプロダクトを使うくらいには価値が届くラインにアタリをつけておきます。
この仕分け作業は、事前に デザイナーと PdM でやっておき、共通認識をもっておくことをオススメします。
2. ユースケースを洗い出す
このステップでは、ユースケース図の作成を通して、発見した課題や最低限満たすべきユースケースを開発チームの共通認識にすることがゴールです。
このステップには明確なコツがあり、インプットはユースケースだけにするべきです。つまり、ヒアリングに使っていた Hi-Fi な画面やモックは不要です。迷わず、捨ててください。
誰が（どんな役割・責務の人が登場するか）、何をやるか、周辺にどんなシステムがあるかを記述していきます。
例えば、カミナシはマルチプロダクト化を進めており、例えば共通の認証基盤があるため、共通基盤との関係性・責務の切り分けを図に描いています。
また、あったらいいユースケースを書き出した上で「今はやらないもの」としてグレーアウトします。わざわざグレーアウトするものを書き出すのか？と疑問があるかもしれませんが、実装時に将来の拡張性を考慮するために「今はやらないもの」も書き出すようにしています。
3. オブジェクトモデル図を作る
ユースケースが持つオブジェクト（名詞）を括り出します。
各オブジェクトがどんな属性（ Column ）を持つか、具体例はどんなものか
各オブジェクト間のはどのような関係でつながるか
今必要なオブジェクトは何か / 今は必要ないオブジェクトは何か
このオブジェクトが書き出せた段階で、OOUI（オブジェクト指向UI）のオブジェクトが決まることになります。そのため、このタイミングで、デザイナーが扱うべきオブジェクトが洗い出さています。モデリングされたものが、開発チーム内で”作るもの”の共通言語になっています。
ユースケースを満たす全てのオブジェクトが書き出せたら一旦完了して、次のステップに進みましょう。この後のステップと行き来するので、完璧でなくて OK です！タイムボックスを決めてやるのもよいですね。
4. ドメインモデル図を作る
モデリングの最終ステップとして、オブジェクトとオブジェクトの持つ項目を命名します。エンジニアがコード上で表現するの名前です（例えば、CSV ファイル出力であれば『csv_export_jobs』）。
名付けをしている間に、「このオブジェクト、実は別の概念を表しているんじゃないかな？」と疑問が出てくることがあります。よい疑問なので、議論チャンスです。
議論の結果、前ステップに立ち戻り、オブジェクトモデルやユースケース図を修正することもあります。そうやって、自分たちのプロダクトが扱うドメインへの理解を、チームで深めていきます。
無事、名前が決まれば、項目のデータ型を決め、オブジェクト間のリレーションを定義していきます（1対1、1対多、多対多）。
ここまで来るとエンジニアはデータベース設計がほぼできており、PdM（元データアナリスト）もデータモデルが理解できているので、データさえあれば分析 ready になっています。
「このステップは、デザイナーや PdM の登場機会が少ないからエンジニアだけでやってもいいのでは？」そんな声が聞こえてきそうですが、個人的には No だと考えています。
モデリングの過程で、今満たすべきユースケースと将来的に満たす可能性があるユースケースを対話することこそが重要なので、チームで会話するべきだと考えます。
会話しながらモデリングを着地させた時点で、大枠で作りたい機能の認識が揃っている状態になります。
5. UIと体験を詰める
認識を揃えたドメインモデルをインプットにして、ユーザーが操作する画面を設計していきます。
主にデザイナーがラフスケッチをおこし、ラフの段階で早めにエンジニアへ共有し、チームで詰めていくことが多いです。
デザイナーと PdM が体験を決める過程で、実装上の難しさは正確には分からないケースがほとんどです。エンジニアに聞いてみたら想定よりも簡単あるいは難しいのはあるあるではないでしょうか（内部の構造を理解していないので、それはそうです…）。
容易に実装できること / 時間がかかることの見極めはエンジニアに聞いた方が早いので、ラフに相談開始しています。さすがに、0ベースで議論をすると発散して収集がつかないので、可能ならいくつか叩きになるもの・松竹梅の体験アイデアをもっていくのがベターですね。
ホワイトボードでお絵描きすると楽に議論ができる実感があります。
カミナシはリモートワーク前提なので、最近はオンラインで体験を詰めていくチャレンジをしている途中で、今のところは、画面数や依存関係の小さい機能であれば、オンライン & 1時間でパパッとできそうな感触があります。練度を上げていきたいですね。
5. 実装・リリース
MVP ライン（ MVP：Minimum Viable Product ）を柔軟に変えながら作っています。実装を始めてみてからわかることもある前提でスタートしています。
「本当にこれは必要でしょうか？」、「こうやるとよかったりしませんか？」とエンジニアから都度提案をもらい、デザイナー・ PdM と決めながら進んでいます。
エンジニアチーム内では T シャツサイズ（S / M / L / XL）のリファインメントはしているようですが、ざっくりとしたものとのこと。
PdM とデザイナーはリファインメントには関与しておらず、職種を跨いでのリファインメントは今のところしていません。この点は、前述の実例マッピングとの差分かなと思っています。
エンジニアが「実装が大変」と言えばそれは大変なので、エンジニアを信頼して預けています。今のところ、それで困ったことはありません。むしろ、毎スプリントで想像よりも数倍速いスピードで動くものを作っています。ありがたいことです。
機能ができて触れるようになったら、チームで同期的・短期集中的に機能を試し、不具合やデザイン修正点を洗い出しています。挙がってきたクリティカルな修正点に対応した上で、本番環境へリリースしています。
（チーム内ではこのプロセスをバグバッシュと呼んでいます）
6. 評価
リリースして終わりにしないように気をつけています。
BtoB SaaS かつ新規立ち上げのタイミングなので、十数社の顧客（β版ユーザー）しかおらず、ログはまだまだ限定的です。
データ量が少ないなら、データを見るより顧客に話を聞いた方が気づきが多いと考え、とにかく VoC を集めまくるようにしています。
現場を訪問する、オンラインで打ち合わせをする、電話する、メールする。とにかく顧客との接点を持ちつづけ、生の声を集め続けています。
主に Biz チームや PdM など顧客に対面しているメンバーが収集しますが、開発チームも積極的に現場へ行ったり、お客様との打ち合わせに同席して、お客様の発言のトーンを生のまま受け取るようにしています。
そして、もらったコメントやフィードバックなどの VoC はチームに見えるところで素早く共有します。以下のような観点から、自分たちがリリースしたものは価値が届けられているのかを確認します。
顧客が問題なく使えているか？
仮説通りの反応がもらえているか？
MVP ラインから外したもので、本来は必要だったものはないのか？
このプロセスでリリースした機能たちがお客様から好反応をいただけており、もしかして結構いいプロセスなのかも？！となった次第でした。（もちろん改善要望もたくさんありますが）
『ドメインモデリング駆動開発』の何が良いのか？
とにかくスムーズにディスカバリーとデリバリーが接続できる点は推しポイントです。
自分だけでなく、チームのみんなもスムーズさを感じているようで、レトロスペクティブではポジティブなコメントが出ています。
「デザイン検討時に考慮漏れを気にしていたが、意識したとて漏れる。1人で考える考慮の限界みたいなものがある。それをドメインモデリングやディスカションして潰せている」（デザイナー）
「開発が速い秘訣として、ある程度考えてから実装していて、作る時に手戻りがない。ストレートに開発できている。特にトレードオフがある感覚はない。」（エンジニア）
加えて、「チームが作るものに納得感を持てること」がこのプロセスの優れている点です。自分たちであるべきを考えて決めたものなら、全員にオーナーシップが宿ります。
また、やらないことも含めて、一度発散して考えるので、拡張性を考慮できる点も重要です。今のところ、大幅な / クリティカルな手戻りは経験していません。
「将来このユースケースを拾う可能性もありえますよね」とチームが認識できる
画面を作る時、ドメインモデリングをする時、実装する時に拡張性を考慮して作ることができる
あるいは作らない判断をすることができる
今のところメリットばかりですね。デメリットも特に感じていません。
『ドメインモデリング駆動開発』のコツ
最後に、何度かチームで実践してみて見えてきたコツをシェアします。
それは、ディスカバリーに使っていた画面やプロトタイプを捨てることです。
「なぜモデリングから始めるのがいいか？画面から作った方が早いのでは？」そんな声が聞こえてきそうです。
それでも、ディスカバリーのときに使っていた画面を捨てることを強くオススメします。一度画面を見てしまうと、Hi-Fi な画面に引っ張られ、些事に議論が及んでしまいます。
ディスカバリーに使っていた画面やモックは、フィードバックを得るために作られたものです。
高速で PDCA を回して改善されたもので、想定するユースケースを網羅したモデルをベースに作られたものではありません。（速度を優先しているので仕方がないケースが多いですし、それでいいとも思います）。
プロダクトに組み込む際には、SaaS として広いユースケースをとらえられるように、適切に抽象化されたモデルを作り、モデルをベースに画面を考える。この順番であることが肝要です。
顧客の業務フローやユースケースを見つけるための触媒だと割り切り、役目が終わったら遠慮なく忘れましょう。実際に、私たちのチームでは画面を見ずにワークを進めています。
ちなみに、弊チームではエンジニアがワークを先導してくれています。ユースケースを作りながら、「さあ今回の登場人物は？」とか「これができるってことは、こんな事もできそうですね？」と、場に疑問を出してくれています。これがとても良いと思っています。
PdM やデザイナーが一方的に「こんな事が分かったよ！」と伝えるだけではインタラクションは限定的になってしまい、どうしても聞いている側は浅い理解になってしまいます。
探索してきた内容を深く知らないからこそ、エンジニアが疑問を場に出しやすくなり、対話を通じてドメインの深い理解につながっています。
チームの全員が現場に足を運び、現場やお客様の業務解像度が高いカミナシの”現場ドリブン”な開発チームだからこそ、なせる技なのかもしれません🐐
We are hiring！
いかがだったでしょうか？
今回は、私たちの開発チームが実践している「ドメインモデリング駆動開発」のプロセスを紹介しました。
カミナシでは私たちと一緒に”現場ドリブン”でオーナーシップをもったプロダクト開発をすることに興味のあるエンジニアや PdM を募集しています！
まずはカジュアルにお話ししましょう！
ご連絡・ご応募お待ちしています！
おわり
（参考にさせていただいたドキュメント）
