把手付けたような開発ブログ

スクラムマスター/ソフトウェアエンジニアとしての学びをつらつらと

ドメイン駆動設計をスクラムで実践する方法について考えてみました

アジャイル スクラム アーキテクチャ

どうも皆さんこんにちは。
鞍馬ぽめると申します、よろしくお願いいたします。

はじめに

先日、実践ドメイン駆動設計（以下、 IDDD 本）を読了しました


幼い頃から読書が苦手なぼくにとって、 600 ページを超える鈍器のようなこの一冊を読み切るというのはひどく根気のいるものとなりましたが、これまで DDD に関する優しい書籍で積み重ねてきた知識の地盤を埋めてくれるような価値ある知識が得られたことは間違いありません

DDD を勉強する上でこの本を一読することは欠かせない なというのが素直な感想ではありますが、そんなぼくもまだ エヴァンス本 は読めていないですし、その価値を理解した上でも簡単に人に勧められるボリュームでもないなと思っています

もし需要があればぼくのように読書が苦手な人向けに、ぼくがどのようして IDDD 本を読み進め理解を深めたのかについてまとめてみようと思います

アジャイルを前提とする DDD

IDDD 本のだいぶ序盤にも書かれてますが、 DDD はアジャイル開発を前提 としています
たしかに、ドメインエキスパートと開発者の間で対話を重ねながら問題領域の分析を進め、解決領域を見つけ、ユビキタス言語の定義とモデル駆動で開発サイクルを回していく DDD の手法は、ウォーターフォール型の開発では無理が出てきてしまうと思います

普段ぼくは、スクラムをベースにアジャイルコーチとしてお仕事をさせていただいているので、今回はアジャイルを実践するフレームワークであるスクラムと DDD の親和性について考えてみることにしました

DDD は技術至上主義の考え方ではない

特にエンジニアの方は DDD と聞くと、「値オブジェクトとかを使ってコードの堅牢性を高めるためのデザインパターン」のようにイメージされる方がいるかと思います
ぼくも DDD をちゃんと勉強する前はそのように捉えており、いわゆる戦術的設計の武器を扱えるようになればエンジニアとしては DDD できていると言えると誤解していました

しかし IDDD 本を読んで理解した DDD の本質は戦術的設計の武器を使いこなすことではなく、 ドメインエキスパートと開発者がユビキタス言語とドメインモデル図を通じて言語の壁とドメインに対する認知差を減らし、共に手を取り合ってプロダクトを成長させていける ことにあるということでした

DDD においては、戦略的設計によって開発者もドメイン分析に加わることで戦術的設計がその真価を発揮します
ドメインエキスパートのメンタルモデルをプロダクトに反映できるという構造から戦略的設計こそが重要であり、故に技術至上主義の考えではないのです

スクラムにおけるプロダクトバックログアイテムの詳細化具体化

スクラムにはさまざまなイベントが定義されておりますが、プロダクトバックログアイテム（以降、 PBI ）をスプリントプランニングの俎上に乗せるためには Ready な状態になっている必要があります

チームによって Ready の定義は異なりますが基本的には詳細化具体化が済んでおり、開発者だけでタスク分割ができるようになっていることが求められます

2020 版のスクラムガイド では各項目の説明に内包されてしまいましたが、 PBI を Ready な状態にしていくイベントを プロダクトバックログリファインメント と呼びます

PBI はプロダクトバックログに追加された時点では「誰に、どんな価値を届けるか、それはなぜか」くらいの抽象的な記載しかされておらず、プロダクトバックログリファインメントにおいてプロダクトオーナーと開発者との会話により Ready な状態にしていきます

プロダクトバックログリファインメントと DDD の戦略的設計

Ready な状態にするためには、どのようにして会話を進めていけば良いでしょうか
ぼくはここに DDD の戦略的設計が使えるのではないかと考えました

前述した通り DDD ではモデル駆動で実装を進めていくのですが、 「モデルの初版ができていること」を Ready の定義のひとつとしておく 1 ことで、プロダクトバックログリファインメントではドメインモデル図とコンテキストマップ、ユビキタス言語の定義を成果物とする DDD の戦略的設計で用いられる手法を適用することができるようになります
もちろんそれらの成果物が整っている状態なので、スプリントプランニングやスプリント期間中の活動も、戦術的設計を駆使した開発に集中することができるようになります

スクラムと DDD の親和性

先述の通り DDD はアジャイルを前提としていることもありますが、前項のように当てはめられることからアジャイルのフレームワークであるスクラムとの親和性は高いと言えると思います

それどころか、ドメインエキスパートとしての プロダクトオーナーのメンタルモデルをよりプロダクトに強く反映できるようになり、逆に開発者のメンタルモデルもプロダクトオーナーに理解してもらえる繋がりが生まれる ため、プロダクト開発チームとしての力がさらに向上すると思います

ぼくの知る限りでは、「プロダクトバックログリファインメントをどのようにして進めるか」の手法はまだあまりスタンダードなものがないように感じてます
もし上手く回せていないと感じているチームがあれば DDD を導入してみるのはいかがでしょうか

ちなみにこの辺の内容を Miro を使ってまとめてみましたので、良ければこちらも目を通してみてください

これから

実は今支援先のチームで DDD の導入を試みております
現行サービスのリアーキテクチャに合わせて開発者だけで試験的に導入している状態なのですが、想像以上に馴染んできており驚いています

とは言えこれは、すでにサービスとして存在しているものだからこそなんとか開発者だけでもドメイン分析ができている状態にあるという実感もあります
新しい領域を攻めることになれば途端に多くの戸惑いが生まれるようになることでしょう

まずはこのリアーキテクチャで小さな成功を作り、ゆくゆくはチーム全体として DDD を実践していけるよう支援を続けていきたいと思います

  1. 初版としているのは実際に実装に入ってみるとドメインモデル図が無理を言っていることがわかってくることもあり、スプリント期間中にもドメインモデル図を直すことは当たり前に出てくるためです↩