DDDを実践してみたら何を作るか明確になった話
この記事は、Showcase Gig Advent Calendar 2021 8日目の記事です。
こんにちは。Showcase Gigの中島です。
弊社では「O:der Platform」の開発をしています。
※ O:der Platformの詳細については 2日目の記事 をご参照ください。
O:der Platformの開発ではDDD(Domain-Driven Design)を実践しています。
モバイルオーダープロダクトにおいて飲食の複雑なドメイン知識と向き合うことは避けられません。
例えば飲食店のメニューには、
1つの商品に対して多くのカスタマイズパターン(トッピング、大盛り小盛り、辛さetc...)がある
同じ商品でも売り方によって税率が変わる
食べ飲み放題、コースといった様々なプランがある
と非常に複雑です。
O:der Platformでは様々なモバイルオーダープロダクトで利用できるようなマスターデータを持っています。 プラットフォームはたくさんのプロダクトに依存されるシステムであり、データをどう設計するかが肝になるためDDDを実践しています。
私のチームでは今年の2月ごろからO:der Platformのコア機能の新規開発を担当しており、約半年をかけてようやく本番で稼働するまでに至りました。
これまでいろいろありましたが、その中でも特にやってよかったなと感じる開発初期にユビキタス言語を定義した時のことを振り返ってみます。
開発初期
コロナ禍に伴い多様な飲食の提供方法のニーズが高まり、弊社としても本格的にプラットフォーム戦略を進めるための新たなコア機能が必要になりました。 今考えるとこの時の私たちはプラットフォームについてわかっているようでわかっていなかった状態でしたが、スケジュールが比較的タイトであり、ゆっくりする時間もなかったのでとりあえず開発を始めました。
開発を進めていたある日、PdMとプラットフォームについて雑談をしていたのですが何やら話が合わない。 対話を続けてみるとエンジニアが作ろうとしているプラットフォームとPdMが想い描いているプラットフォームがずれており、
エンジニア「複数の社内プロダクトが利用する共通基盤のようなもの」
PdM「社内外問わず様々なプロダクトにつながり、顧客のハイエンドな要求に答えられるもの」
といった感じで、エンジニアが思っているよりもはるかに広がりのあるものを求められていることに初めて気付きました。
プラットフォームをウィキペディアで調べても、「何らかのコンピュータシステムの基礎的な部分となるもの」としか出てこないですからね... 人によって認識齟齬が起きても仕方がない状況でした。
DDDには「戦略的設計」と「戦術的設計」がありますが、この時点では「戦術的設計」までにとどまっており「戦略的設計」は実践できていませんでした。 プラットフォームに対する認識ずれをなくすためにユビキタス言語などのアプローチが使えるのではと思い、本格的に「戦略的設計」に取り組み始めました。
「O:der Platformとは何か？」を考える
手始めにO:der Platformを構成する要素のネーミングとその説明を考えよう！としたのですが、、、これが思ったより難しい。 チーム内にDDD経験のあるメンバーがいないため、どこから手をつけてよいのかわからない。
とりあえずチームメンバー全員で一緒に連想ゲームをしてみようということで、「O:der Platformとは何か？ 」をマインドマップで広げてみるところから始めました。
- 問いに対する回答を書く
- 新たな問いが出てきたらさらに深掘り
- あいまいな単語があればその単語を深掘り明確化する
こういったやり方でとにかく言語化を繰り返しマインドマップ内を行ったり来たりしながら理解を深めていきました。 新たな言葉も発見でき、それをそのままユビキタス言語の定義につなげられたので良かったです。
PdMにもマインドマップを共有し、作成過程でインプットをもらいながら進めていきました。
これが実際に作ったマインドマップの一部です。
ここまでしてやっとO:der Platformが何かがわかりました。 (正直けっこうしんどかった、、、)
得られたもの
O:der Platformとは何かを理解できるまでに1週間くらいかかったのですが、以下の効果を得られ、やって良かったと感じる投資でした。
- 何を作るべきか明確になった
- チーム内で共通認識形成され同じ方向を見て開発ができるようになった
- 自分たちの作っているものの価値を見出せるようになった
また、何を作るべきかが明確になった結果、力の入れどころ抜きどころを決めやすくなり、タイトなスケジュールにも間に合わせることができました。
「開発速度を2倍にしたいならやることを1/2にすればいい。ただしやるべきことをきちんと見極めた上で」
以前の職場でこのような言葉を聞いてすごく刺さった覚えがあるのですが、今回経験したことがまさにこのことだなと感じています。
まとめ
皆さんは、何を作るかあいまいなまま走り出し、大きな手戻りを食らい時間を無駄にしたご経験はないでしょうか？ DDDの戦略的設計を実践するとそういったことを防げる可能性があります。
この記事はDDDの体系的な知識を説明するものではありませんでしたが、DDD的アプローチを始めたことがきっかけで何を作るのかが明確になり、開発効率も上がったし今後の開発のための基本的な考え方ができたという話でした。 何かのご参考になれば幸いです。
さて、明日は最近立ち上がったCREチームのお話です。 これまでのアドベントカレンダーとはまた違った話になるのでお楽しみに！
この記事が気に入ったらサポートをしてみませんか？