Paul Rayner氏が語る，”DDDとアジャイルは共存できる"

Domain Driven Design Europe 2016で行なった講演の中で，Paul Rayner氏は，アジャイルのソフトウェアデリバリプロセスの一部としてDDD(domain-driven design, ドメイン駆動設計)を取り入れることを提唱した。作業の方法を規定するのではなく，作業を組織化する方法としてアジャイルを捉えている氏は，アジャイル実践者は多くの場合において，設計に対する配慮が不十分だと考えている。そのような問題に対処する手段として，アジャイル実践者にDDDの概念を広めるだけに留まらず，アジャイルとDDDを組み合わせることで製品のデリバリを速くできるのではないか，というのが氏の考えだ。

氏のコンサルタントとしての経験からは，アジャイルを実践するチームの多くが，設計を犠牲にする理由として，MVP(Minimum Viable Product)の重要性を強調している。しかしながら氏は，Douglas Martin氏のことばを引用して設計の必然性を主張する – “優れた設計(good design)の反対は悪い設計(bad design)であって，設計しない(no design)ではない”。ウォーターフォールのBDUF(Big Design Up Front)を避け，設計作業を最小限にしようとするあまり，結果的には悪い設計を行なっているのだ。アジャイルマニフェストには，“技術的卓越性と優れた設計に対する不断の注意が機敏さを高める”，とある。アジャイルの目的は速さではない。速さだけでなく，機敏さ(アジリティ)なのだ。アジリティを実現するのは優れた設計だ。設計の真の目的を示すために氏は，さらにVenkat Subramaniam氏のことばを紹介している – “優れた設計とは将来を正しく予測するものではなく，適切なコストで将来に適合できるものだ”。

設計は本質的に反復的な作業であるから，アジャイルに取り込むのは容易なはずだ，と氏は指摘する。設計とは，自分が知らないことを発見し，複雑なアイデアを単純化するプロセスである。すべての事実を事前に知ることが不可能である以上，設計が時間とともに変化するのは当然だ。新たな知識を発見し，それをコードに表現するために確保した時間は，コード自体がアジャイルになることにより，後作業の時間削減として回収することができる。これを実践するひとつの方法がモデル探査の渦巻きプロセス(whirlpool process)である。これは，新たなシナリオによるドメインの既存モデルへのチャレンジ，新モデルの提案，コード実装を繰り返すプロセスだ。

Rayner氏はさらに，自身が関係したアジャイルチームがDDDの観点から失敗した別の例をいくつも紹介した。ひとつの失敗例は，継続的リファクタリングを優れた設計に代わるものと解釈したことだった。リファクタリングでコードをクリーンアップすることは可能かも知れない。しかしDDDが重視するのは新たな概念の導入なのだ。新たな概念はコードからは生まれない。リファクタリングだけで作り出せるものではなく，ビジネスをモデル化したものが概念なのである。その定義上，ソフトウェア機能を変更することのないリファクタリングとは違い，新たなビジネス価値を追加するものなのだ。

スクラムでは“プロダクトオーナ”という役割が定義されているため，チームがその役割を，すべてのビジネスニーズや知識を伝える唯一の人物だと理解していることが少なくない，と氏は指摘する。DDDでは，全員がドメインを知るように提唱する。技術的側面ではない，問題の複雑さがここにある。つまり，優れた設計を実現し，アジリティとビジネス価値の向上を実現するには，提供チームの全員がドメインを知る必要があるのだ。