これまでの十四章
顧客/供給者の開発チーム
例えば、供給者(上流チーム)が作成するAPIを顧客側(下流チーム)が使用するようなパターン。
顧客側は同じ社内の別チームだったり、別々の企業で進められるプロジェクトであることもある。
よくあるのは、複数の全く別のコミュニティに対して適用されるパターン。
モデルもツールセットも異なるので、共有カーネルのようにコードを共有することができません。
このパターンを採用すると、顧客側は「顧客」という役割なので、供給者に要望（クレーム？）を出すことができるし、供給者はその要求を最優先で対応する必要があります。
顧客/供給者の開発チームのあるある
そうなると、政治的な力関係がある場合、こんな問題が起きます。
- 顧客側が変更に対する拒否権を持っている。
- 変更を要求するのに手続きが面倒。
- 下流のシステムを壊してしまうと不安になり、上流側が抑制されてしまう。
- 影響力のある顧客は上流のプロジェクトを成功させる上で重要な要求を出すこともあるが、同様に、その要求によって上流の開発が阻害されるかもしれない
- 上流が富者で下流が貧者の場合、下流チームが要求を実現してもらうために、上流チームに懇願しなければならない
最後の２つは力関係によってそうなるなということが凄くよくわかります。
解決策
イテレーションプランニングに下流のチームの代表を参加させて直接議論することが解決策になります。そうすることで、下流側が必要とする作業を上流がしてくれるか、延期するかその場で決定でき、下流側がそれに影響されて遅延することはなくなります。
手続きも不要。顧客側が強く言ってくることもないし、上流が不安に思うこともなくなります。
ただし、顧客が一つのチームだけとは限りません。その際に必要なのは、顧客の要求に対してバランスを取っていきながら、下流の要求を優先して対応していきます。
これによって、富者・貧者の関係や影響力のある顧客の関係を解消していきます。(それが難しいといえば、難しい)
もうひとつは、受け入れテストを共同で開発することです。
開発したテストは上流側のテストスイートに追加し、継続的な統合の一部として実行されるようにします。
Evansの経験
最後にEvansの経験談が載っていますね。
上流のメンバーが自分たちの役割は顧客に仕えることであると考え、こうした関係が非公式に組織され、２人のプロジェクトマネージャーが個人的仲が良い。こうしたケースは常にうまくいっていたとのことです。なるほど！
**逆に上流チームを動機づけるものが何もない場合は非常に難しい・・・**と。。。
NARUHODO・・・