こんにちは！
クラウドワークスの新規事業開発チームでプロダクトマネージャー（以下、PdM）を担当している八尾です。
クラウドワークスでは、新規SaaSプロダクトを目下開発中です。
プロダクトの中身はまだ詳しく言えないのですが、新規事業の考え方などはこちらの記事をぜひご覧ください。
現在開発中のプロダクトでは初期からドメイン駆動設計（以下、DDD）の思想を取り入れて設計をしています。
DDDは、端的にいうと、ドメインモデルを中核に据えて設計しようということだと理解しています。
（参照：Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita）
この記事では、なぜ初期の小さな規模のプロダクトでDDDを取り入れる意思決定をしたか、取り入れてみてどういう効果が得られたかについて、非開発者のPdM視点で書いてみようと思います。 （開発者視点でどうだったかは後々また公開する予定です）
この記事を書く背景
DDDを取り入れることで、中長期的に開発生産性が落ちづらい状態を保てると、ビジネス目線の効果として解釈しています。
一方で、初期のドメインモデリングやそもそものプロセスのキャッチアップなど、初期に一定の時間を投資することも求められるなとやってみて感じました。
さらに、新規事業だと、とにかく雑に一旦作って、事業がのってきたら作り直すという判断も十分にあり得る選択肢で、クラウドワークスでも、自分が初期の立ち上げを担当した「クラウドリンクス」という新規事業ではそのようなプロセスを採用しました。
（参考：ドメイン駆動設計 × Spring Boot（Kotlin）で新規事業クラウドリンクスを運営している話 - クラウドワークス エンジニアブログ）
立ち上げの選択肢が様々ある中で初期にどこまで「ちゃんと作るか」というのは技術目線とビジネス目線のせめぎ合いで、常に悩ましい問題です。
今の取り組みをシェアすることで新規事業を立ち上げている、立ち上げたい、立ち上げ方で迷っている、PdMの方やエンジニアの方の何らかのヒントになればと思っています。
DDDを取り入れた背景
今回の新規事業では、スモールに「一旦作る」ではなく、最初から「ちゃんと作る」という判断をし、DDDを取り入れた開発をしました。
その背景は以下のように大きく3つありました。
観点１：プロダクトの特徴
まず１つ目の観点として大きいのが、プロダクト/ビジネスモデルの特徴です。
今回の新規事業は、SaaSプロダクトであり、かつ、大手企業への導入も将来的には視野に入れていたため、プロダクトがカバーする業務領域をどんどん増やしていくべきプロダクトでした。
SaaSは、単機能で尖ったUXを提供して多くのユーザーに利用してもらうというモデルではなく、あらゆる業務領域をカバーすることで市場が広がっていくという考え方が適しているケースが多く、自分たちのプロダクトもそうするつもりです。
BtoCは引き算でプロダクト思想していくが、BtoBは足し算でプロダクトを創っていく。その中でUXを実現する。BtoBのエンタープライズプロダクトはほぼ外資系なので、ジャパンリージョンでメソッドが発信されにくい。
— 橘大地🔖 (@d_ta2bana) 2021年1月29日
そのため、初期から機能を追加しやすい土台を作っておくことが重要だと判断しました。
観点２：開発に入る前の検証レベルの観点
次に、実際の開発に入る前にどれだけ事業の検証ができていたかという点です。
今回の新規事業では、エンジニアメンバーがジョインする前に、ある程度リッチなUIのデモを作成し、顧客ヒアリングや初期の事業検証をおこないました。
アニメーションなども含めたデモをベースに顧客ヒアリングを重ねたことで、どの機能がコアであり、どの機能が満たされればどんな業務課題が解決できるかという点をクリアにでき、アプローチする課題、作ろうとしているプロダクトが両方フィットしていることが一定確認できていました。
つまり、コアドメインがある程度明確にでき、かつ、それがブレるリスクも小さくできていました。
新規事業において一番のリスクと言っても良い、顧客に受け入れられるかどうかという点の不確実性を一定下げた状態で実際の開発に入れたことで、設計に時間を投資する意思決定がしやすい状態を作ることができました。
顧客ヒアリングを重ねたおかげで、設計上必要になるビジネスロジックへの理解度が高い状態で仕様を作ることができ、ドメインモデリングにおいてPdMである自分がドメインエキスパートとして振舞うことができたのも良かったです。
観点３：新規事業そのものに対する会社の考え方の観点
最後に、クラウドワークスには、会社としての新規事業開発ポリシーというものがあります。
詳細はまた機会があれば公開できればと思いますが、プロダクト中心の新規事業は数ヶ月などの短期業績だけで判断することはしないこととなっています。
そのため、初期から中長期の目線を持ってプロダクト開発に打ち込むことができ、じわじわ効果が出てくるようなことも取り入れやすい環境にありました。
DDDを取り入れた背景のまとめ
ここまでを一旦まとめると、
- 機能を増やしていくことが事業上の優位性につながるという、中長期的な開発生産性の担保がイシューとして大きい、つまりDDDを取り入れるべき理由があった
- 事業自体の不確実性を開発前に下げることができた
という2点がDDDを導入した理由でした。
逆に、明確な理由がない場合は、クラウドリンクスの経験からMVPをとにかく最速で作り、一度壊して作り直すくらいの考え方のほうがむしろ適しているのではとも思います。
具体的に何をやったか
実際にDDDを取り入れて自分も一緒にやっていたことは以下です。
- ユースケースの洗い出し（PdMが中心）
- ユースケースのグルーピング（コンテキストの整理）
- PdMをドメインエキスパートとして全体のドメインモデリングを実施
- ユースケースやドメインルールについて、PdMでも不明な点が発生すればすぐに顧客ヒアリングを実施
- 全体を一通りモデリングした後、実際の実装のタイミングで、ドメインモデル図の確認と細かい修正事項があれば修正を実施
- 追加機能や仕様変更があればドメインモデル図の修正をまずはタスク化してそこで認識合わせをおこなう
miroを使用して、最初は汚くとにかく手を動かして作り、ある程度完成してきたら運用しやすいよう清書し直しました。
DDDを取り入れたことによる効果（PdM目線）
DDDを取り入れてみて、当初の自分の理解では、グロースフェーズ（1年後とか）や開発チームが大きくなったタイミングで効果を実感してくるだろうと思っていたのですが、短期的なメリットもいくつも感じられたので紹介します。
1.仕様の認識合わせがしやすい、仕様の抜け漏れに気づきやすい
ドメインモデル図を見ながら概念の関係性を確認していくので、追加仕様など仕様変更が発生した際に、ありうるパターンの整理や、概念の関係性の齟齬を見つけやすいです。
チームの基本的な動きは、仕様書をガチガチに作らず、スモールなチームのメリットを生かして不明点があれば話して解決というスタイルでしたが、ドメインモデル図をベースに議論をするようにしたことで、ドキュメントを作らずとも細かい点まで確認できるようになりました。
2.エンジニアメンバーのドメイン理解が深まった
基幹業務系のSaaSだと自分がユーザーになりづらい一方、深い業務知識が必要です。
ドメイン理解はセールスやPdMだけでなく、エンジニア/デザイナーも一定度の理解がないと仕様の意図が理解できず、良いプロダクトが作れない課題感がありました。
とはいえ、開発に時間を割いて欲しいので顧客ヒアリングに参加することが本当にいい時間の使い方かと言われるとそうとも言えない、、という状態でした。
ドメインモデリングを全員でやったことでエンジニアメンバーのドメイン理解がかなり進み、間接的であっても顧客理解も同時に進めることができたと思っています。
ドメイン理解があるからこその指摘もエンジニアからもらえるようになり、議論のレベルが一段上がった感覚があります。
3.顧客ヒアリングの精度が上がる
最後に、これは自分にとってよかったことですが、
というサイクルができたことで、自分たちが何をわかっていないかがクリアになりました。
おかげで、顧客に何を聞くべきか、顧客が今どういう意図でどんな業務をしていて、本当はどうあるべきかのヒアリングの精度をどんどん細かいレベルに分解でき、一回あたりのヒアリングの精度が上がりました。
終わりに
今回は、クラウドワークス初期から「ちゃんと作る」意思決定をした背景と現時点で感じる効果について書きました。
新規事業の初期にどこまで「ちゃんと作るか」という点はなかなか難しい論点だと思っていて、会社の考え方、チームの特徴、事業の特徴など複数の変数の中の意思決定になると思いますが、何かの参考になれば嬉しいです！
参考になった！もっと聞きたい！全然違う！一緒にやりたい！などご意見あれば是非こちらからご連絡ください。
