新規プロダクトのドメインモデリングを チーム全員 で40時間かけてやったら、一石三鳥🐓だった話
はじめに
こんにちは！カミナシでPMをしている、かもしー🦆です！
このnoteでは、サービスチーム全員（エンジニア・デザイナー・PM）でドメインモデリングを設計したら一石三鳥🐓の成果があったので、次回やる時に取り入れたいワーク設計のポイントを話します。
経緯
直近半年間、新規プロダクトの探索をしてきたのですが、先日正式版開発を始めるフェーズになったため、新たにエンジニアとPMがチームにjoinすることになりました！
オンボーディングの相談をした際、CTOトリさんから「開発者のオンボーディングには、ドメイン理解が一番大事だ」というアドバイスを受けたことがきっかけで、キャッチアップと設計を兼ねてドメインモデル図を作成するワークを合計40時間ほどかけて行いました。
その結果、new joinnerの知識のキャッチアップ、プロダクトの設計、チーミングが同時にでき、一石三鳥🐓でかなり良かったです。
そこで、次にやるとしたら最初からこう進めるぞ！という3つのポイントをまとめます。
🙋想定読者
開発メンバーのオンボーディングに悩んでいる方
ドメイン知識の共有方法に悩んでいる方
ドメインモデル図の作成をしたい方
どんなワークをしたの？
サービスチーム（PM・デザイナー・エンジニア）全員で、オフライン・オンラインで会話しながら合計40時間ほどかけて、ワークしました。
やり方自体は、すでにいろいろな記事が出ていると思うので割愛しますが、以下の流れで実施しました。
業務フロー図・ユーザーストーリーをインプット
ユースケース図を作成
具体例を交えてオブジェクトモデルを作成
ドメインモデルとして抽象化
なにがよかったの？
こんな一石三鳥🐓がありました。
🐓新メンバーが早くドメインをキャッチアップできた
🐓ドメインモデルが設計でき、サービスチームでドメインの共通理解を得た
🐓作成過程のコミュニケーションを通じてチーミングができた
アウトプットしたもの
プロダクトの設計に関わるためモザイクで申し訳ないですが、以下のようにユースケース図、オブジェクトモデル図、ドメインモデル図を作成しました。
フォーマットは以下などが参考になりました！
https://little-hands.hatenablog.com/entry/2022/06/01/ddd-modeling
https://zenn.dev/innoscouter/articles/b1973a7032ff8a
ユースケース図
該当のユーザーストーリーと結んでいます
オブジェクトモデル図
ドメインモデル図
オブジェクト同士の0-nで関係性を整理しています
次にやるとしたらこう進める！3つのポイント
ワークを振り返ってみて一番難しかったことは、元いたメンバーとnew jonnerの間のドメイン知識の差を埋めながらアウトプットすることでした。
そのため、進め方に関して、私とnew joinnerのエンジニアは けんか "健全な"コンフリクトもしました笑
そんな経験を元に？、次回またワークすることがあれば最初から意識したい3つのポイントをまとめました。
1. ドメインの理解は客観的で網羅的な情報だけでなく、むしろ主観を話す
みなさんだったら、新しく入ってきたメンバーにドメイン理解をしてもらうために、どのような情報をどう伝えますか？
今回のオンボーディングの設計は私がやったのですが、過去半年間で10社ほど現場訪問＆70件以上ヒアリングしてきた知見を余すことなく伝授しなきゃ！貴重な顧客の声やファクトをちゃんと伝えなきゃ！と気負い、最初は多くの情報を説明していました。
ユーザーの業務フローを写真付きで解説したり、競合プロダクトの概念を説明したり、ユーザーストーリーマップを使って説明したりと、さまざまな方法でドメイン知識を共有しようと試みましたが…
何を伝えてもnew joinnerのリアクションは「へえそうなんだ」という感じで手応えがありませんでした。あとから聞いたところ、「なぜその課題があるのか」「解くべき課題なのか」がわからなかったそうです。
いろいろ説明してみて一番new joinnerの理解が進んだやり方は、対象を絞って深く対話していく方法でした。
具体的には、対象の業務フロー図に、課題を書いた付箋を貼り、なぜそれが課題なのか、代替ソリューションはなにかなどの質疑応答をしました。
特に、当初これが課題だと思ったが実は違った話や、一見これが課題ではなさそうだが実は辛い業務だった話、など実際に思考してきたプロセスを話していくことで深い理解に繋がりました。
正しい事実を網羅的に伝えるのではなく、当時自分たちが考えていた仮説や疑問、感想など、自分たちの主観を交えながら説明したことで、「なぜその課題があるのか」「解くべき課題なのか」という思考の追体験ができたのが良かったようです。
2. おおらかな気持ちで具体と抽象を行き来する
ドメインモデル図を作成するには、具体と抽象を行き来する必要があります、というか、ドメインモデル図はまさに抽象化の作業そのものですね。
そして抽象化を進めるためには、まず具体的な理解が不可欠です。そのため、new joinerがどの程度の解像度で理解しているかを確認しながら、足りない具体を補っていくことが重要でした。
先ほど書いたように具体のインプット方法については、いろんな確度で情報を伝えようとしたので、非常に時間がかかりました（10時間以上）。
そのため最後にチームで振り返りを行い、最短でドメイン理解をする方法を考えてみたのですが、結論としては最短の方法は特になかったです！笑
というのも、競合のプロダクトを触る時間が理解促進になった人もいれば、業務フロー図が良かった人もいて、人によって理解度や認知しやすい説明の仕方や表現が異なったからです。
そのため、とにかく寄り道してもいいからおおらかな気持ちで、具体と抽象を行き来していくことが大事だと思いました。
こんなものを沢山用意しました
3. 初速が遅くても気にしない強い気持ちで、コミュニケーションに投資すると決める
これが一番大事だと思ったのですが、意識的にコミュニケーションに"投資"したことが良かったです。
初期からコミュニケーションに時間を割いていると、周りから見るとサービスチームの立ち上がりが遅いと思われるかもしれないですが、そこは気にせずにコミュニケーションを多くとることを、サービスチーム内で最初に目線を合わせました。
実際に、サービスチーム全員がオフライン・オンライン合わせてなんと40時間以上もワークしましたが、それによってキャッチアップ、ドメイン共通理解、チーミングができました。
というのも実際にやってみて感じたのは、ドメインモデル図の作成では、アウトプットだけではなく作成プロセスが極めて重要だということです。
ドメインモデル図は、単に数人の優秀なメンバーが作成すれば良いというわけではなく、サービスチーム全体でドメインを理解し、作成していくことが必要であり、しかも運用していくものなのです。そのため、アウトプットを早く良く作ることと同等かそれ以上に、納得感を持って作成できていることが重要でした。
そのため、時間をかけてでもチーム全員でドメインの共通理解を持つためにコミュニケーションに投資することは、大変有意義でした！
さいごに
読み返すと当たり前のことを書いているかも🦆ですが、もしなにか少しでも参考になれば幸いです！🐓
カミナシでは「ノンデスクワーカーの才能を解き放つ」というミッションのもとマルチプロダクト戦略をとっており、全方位で採用をしています！！
先日のプレスリリースでも、2024年度中に新製品として3製品を加え、計5製品をラインナップしたマルチプロダクト展開する旨を発表しました！
少しでも興味を持ってくださった方は、ぜひカジュアルにお話しましょう〜！！✨
この記事が気に入ったらサポートをしてみませんか？