DDD（Domain Driven Development）でDDT（Dramatic Dream Team）を作る
本記事はドメイン駆動設計#1 Advent Calendar 2019の14日の記事です。 前回はryuseikurataさんの記事でした。
2019年もあとわずかになりました。今年は皇位継承や、多数の大物芸能人の婚約・結婚、個人的にも第一子が生まれるなど、とてもドラマティックな１年でした。
ちなみに、出産予定日だった3/29は会社を休んだのですが、その時、職場では会社を揺るがす大事件が起きていました。
／
— DDT ProWrestling (@ddtpro) 2019年3月29日
グループ企業にかこつけて #DDT路上プロレス 🙇
＼
／
引っ越し祝いにかこつけて #DDT路上プロレス 🙇
＼
／
真新しいオフィスにかこつけて #DDT路上プロレス 🙇
＼
ぜひ歴史の目撃者になってください👀@AbemaTV で18:00から生中継！
視聴予約▷https://t.co/MD1Hi8xmYK#ddtpro pic.twitter.com/Br9798aQoE
職場ビルの倒壊は免れましたが、女子レスラーが同僚の机の上でロメロ・スペシャルを決めてて、机上のディスプレイが倒れそうになってましたw（セコンドの人が押さえて無事でした）
本題に戻ります。この記事は、DDDとチームビルディングというテーマで記載します。
軽く自己紹介
TD;LD
スクラムにDDDの開発手法やプロセスを導入するといいチームを作れます
前提：なぜチームで開発するのか？
「早く行きたければ一人で行け、遠くに行きたければ仲間と行け」という格言があります。チーム開発の狙いはまさにこれだと思ってます。スキルセットや成功（または失敗）体験の違うメンバーが知見を出し合うことでより高機能、高品質なシステムを作れます。しかしながら、昨今の世の中の変化の速度を鑑みると、より速く到達することも求められます。
チーム開発は並列処理と同じだと考えています。すなわち、個人作業の時間とメンバー間で同期をとる頻度と時間のバランスによって、開発速度が決まります。著者の経験上、この同期にかかる時間がボトルネックになることが多いです1。そこで、DDDの開発プロセスや成果物を導入することで同期にかかる時間を減らすことができます。
おさらい：DDDとは？
ユビキタス言語を用いたモデルを使って会話することで、円滑なコミュニケーションを実現すること が一番の目的だと考えています。それは、ビジ職とエンジニア職の間のコミュニケーションだけでなく、エンジニア同士のコミュニケーションの効率化も含まれます。
設計思想としてドメイン層を隔離するのも、ひいてはコミュニケーションの効率化のためだと考えています。究極にはドメイン層を隔離してビジネスロジックをまとめれば、ドメイン層のコードが仕様書の代わりになる（しかも動く！！）ので、仕様書の更新漏れから生じる確認作業とか、メンバー間での仕様の認識違いから解放されます。
以下、もう少し具体的にDDDがどのようにチームのコミュニケーション効率化に貢献するかを記載します。
同じ絵をインプットすることによる効率化
全く会話が噛み合わないと思ってた人との間に、共通の趣味や知人、似たような体験をしていることが分かると急に会話が弾む、という経験はないでしょうか。著者は開発案件に取り組むとき、まずは要件定義や画面イメージなどからドメインモデル図2というのを作って全員でレビューします。このプロセスには前述のような効果があると考えています。つまり、全く性質の違うメンバーが、まずは同じ絵を脳内にインプットすることでその後のコミュニケーションの質を上げられます。
設計と実装を分離できてレビューの質があがる
まれに「実装したから設計と実装どっちも見てくれ〜」、というプルリクエスト（以下PR）をもらうことがあり3、その度に「PRで設計のレビューするの無理じゃね？」と思ってます。設計のアウトプットと実装のアウトプットは違いますし、設計なら前述のモデル図やシーケンス図で議論した方がよっぽど効率的です。著者が実践するDDDのプロセスでは、まずはモデル図などの設計資料を作ってレビュー会を開きます。これにより設計レビューが効率化されます。また、設計についての共通認識ができれば実装後のレビュー観点を減らせるので、PRをマージするまでのリードタイムが削減できます。
モデル図があるとチケットを分離しやすく、フォローしやすい
例えば、XXXエンティティの実装をする、といったように、モデル図があればチケットを細かく発行することができます。チケットを細かく出せると、手の空いた隙間時間などに他のメンバーのフォローをしやすくなります（さらに、「この作業、どこまでやったっけ？」という確認のコミュニケーションも減らせます）
また、チケットが細かいと進捗やベロシティも把握しやすくなり、チームのふりかえりもより有意義になります。
まとめ
まとめるとチーム開発のボトルネックは仕様や設計、作業進捗を把握するための「同期のコスト」であり、一方でドメイン駆動設計の本質はユビキタス言語やドメインモデルを使ったコミュニケーションの効率化なので、スクラムと相性がよく、開発を加速できます。また、コミュニケーションが効率化すれば、ふりかえりの質も上がってより成果の出せるいいチームにしていくことができます。
ぜひお試しください。
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者:エリック・エヴァンス
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
