【DDDメモ】モデルの整合性を維持する:顧客/供給者の開発チーム

エリック・エヴァンスのドメイン駆動設計 P.365

 蒸溜チームが自由に開発の舵をとれなくなるのは、下流のチームが変更に対する拒否権を持っている場合や、変更を要求されるための手続きがあまりに面倒な場合である。下流のシステムを壊してしまうのではないかと心配するあまり、上流のチームが抑制されることさえある。その一方で、下流のチームは蒸溜のチームがつける優先順位の言いなりになって、自分たちではどうすることもできない。
 下流は上流からくるものを必要とするが、蒸溜は下流が作り出すものに対して責任を負わない。【中略】したがって、チーム間の関係を形式化すれば誰もが楽になる。このプロセスは。、2つのユーザコミュニティの間で要求のバランスを取り、下流で必要な機能に関する作業をスケジューリングするために構成される。
 エクストリームプログラミングを行なっているプロジェクトでは、まさにそのための仕組みが準備されている。それがイテレーションプランニングプロセスだ。やるべきなのは、プランニングプロセスの観点から、2チームの関係を定義することだけだ。下流チームの代表はユーザの代表と同じような役割を果たせるので、彼らをプランニングプロセスに参加させ、必要な作業に関するトレードオフについて、この「顧客」と直接議論すると良い。

 これはスクラムのプロセスでも基本になる。このコミュニケーションが、チームの課題意識から自発的に行われるとより良い。システムのデメリットは、チームで補うことができる。もちろん、同時にシステムのデメリットも解決するように努めれば、状況はより良くなる。

エリック・エヴァンスのドメイン駆動設計 P.366

 2つのチーム間に明確な顧客/供給者という関係を確立すること。計画時には、下流のチームが上流のチームに対して、顧客としての役割をはたすようにすること。下流の要件に必要となる作業について交渉し、顧客としての役割を果たすようにすること。下流の要件に必要となる作業について交渉し、予算を立てることで、提供の約束とスケジュールが全員に理解できるようにすること。
 期待されるインターフェースを検証する、自動化された受け入れテストを共同で開発すること。そのテストを上流チームのテストスイートに追加し、継続的な統合の一部として実行されるようにすること。このテストを実施することで、下流への副作用を心配せずに、上流チームは自由に変更を行えるようになる。

 もしかすると、日本では顧客/供給者ということを明示してしまうと上下関係が発生し、強制力が発生してあまりいい結果にはならないかもしれない。ただ、別の言い方として表現すれば良い。それは、それぞれのチームに関係性があり、考慮しなければならないということだ。
 ただし、これはシステムの制約でこうしたというのもあるが、チームの力やレガシーな状態を引っ張らなければならないなどの柵があるかもしれない。このようなやり方と同時に、その問題を解決することを努力することを同時に行う必要があるのではないだろうか。

エリック・エヴァンスのドメイン駆動設計 P.367

 顧客/供給者チームが成功するのは、2つのチームが同じ経営陣の下にいて、最終的な目標を共有しているか、実際に顧客と供給者の関係である別々の企業にいる場合であるようだ。上級チームを動機づけるものが何もない場合は非常に難しい…。