Agileプロジェクトの契約に関する私見

 2009/11/12
このエントリーをはてなブックマークに追加

Agileプロジェクトにおける契約についてちょっと私見を整理してみました。

  • 期間、費用が固定されていて、製造量が不定になる請負契約は行わない。
  • 特に上記のケースで、顧客側が開発側に対して強い力を持っている場合は、顧客の力による押し切り、社内の弱い管理者による承諾と開発チームへの強要といったことが発生しやすい。
  • Agileは基本的には準委任の方が良い。請負契約の場合、契約時点で成果物をお互いの齟齬がないように明確にせねばならず、往々にして、その認識の齟齬がプロジェクト混乱の原因になりやすい。
  • Agileプロジェクトでどうしても請負契約を締結する必要がある場合は、最低限プロダクトバックログの抽出と、以降の開発スプリントについては契約を分離しよう。
  • プロダクトバックログが出来上がればストーリーポイントや優先順位の算出が出来るし、スプリント計画も立てられるので、ブレは少なくなる。但し全部のスプリント分を一括して契約するのではなく、スプリント毎の契約に出来るとさらに安心だ。
  • 一方で顧客側の立場からすると、なんで開発側はそんなに守りに入っているの?と見えなくもない。
  • しかし開発側は「顧客の欲しいものは日々変わる」「最初にたてた計画はだいたいあっていない」ということを良く知っている。
  • だからこそ、契約なり提案の時点で、開発側は、「プロジェクトをAgileでやること」「Agileで行うメリット/デメリット」の説明をしておく必要がある。なんとなく不安だから請負契約がイヤだ、というのは筋が通りにくい。
  • また、契約の時点でチームの生産力の目安を顧客に伝える必要はあるだろう。請負でない形態にした場合、完成しないけれどもお金は使った、という状態になり得るわけで、その不安も解消する必要がある。
  • 個人的な意見としては、そのプロジェクトの前のプロジェクトのプロダクトバックログ(全部でなくても良いので、基準ストーリーポイントになったストーリーといくつか規模の違うストーリーが入っていれば良い)とチームのベロシティを提示してあげることだと思う。それによって顧客はチームの生産力をおおよそ把握できるのではないか。
  • 上記に書いたような話は提案書に書くこと。表面的な提案が顧客に通って契約交渉を始めてから揉めるよりも、最初から「Agileじゃなきゃやらない」という意思表示も必要。提案が通った後に契約方法で揉めたあげくに押し切られてAgileのつもりだったのに詳細設計書大量に書いたり、成果物保証させられたり、というのは絶対避けたい
 2009/11/12
このエントリーをはてなブックマークに追加

サイト内検索


著作

寄稿

Latest post: