アジャイルと契約のはなし
端的に言えば、請負契約をするなら請け負う仕事が見積もれていることが前提になるから、見積もり時点での役務の仕様が発注者からも受注者からも明瞭会計なのです。現実の世界での請負契約の闇は一旦棚に上げて。
請負契約で「見積もる」ということは、納入する(納品ではない)成果物がどのような部品で構成され、どんな仕様かを見積もり時点で明確に見積もれないといけないんですよ。部品ひとつだってコストがかかるのですから、仕様が不明なままでは見積もりの精度が悪くなってしまい実際に見積もり価格で受注したとしてもプロジェクト途中で部品の不足が判明したらコストが見積もりより多くなってしまい、コストオーバーランしちゃいます。不足部品によってはそれだけで赤字になってしまうかもしれません。
例えば、下表の部品でできているソフトウェアがあったとします。それぞれの部品の工数を積算して、プロジェクト内のその他経費に対して、コンテンジェンシコストや利益を加算すれば見積もることができます。
名称 | 個数 |
部品1 | 2 |
部品2 | 10 |
部品3 | 30 |
このとき、上表の部品1−3の仕様が明確であることが必要なのは先に述べたとおりです。見積もりとして精度の高いケースは、パッケージ開発やソリューションテンプレートなど開発での標準パターンが進んでいるケースです。他のケースでも、過去実績が計測できており、定量的に比較できるならある程度の精度は確保できるでしょうし、もちろん、見積もりの前提となる仕様は明確に提示できるでしょう。
では、アジャイルの見積もりは何が違うかを同じ表を使ってみていきましょう。
アジャイル開発ではプロダクトマネージャと開発チームでスコープに相当するプロダクトバックログをリスト化し、開発期間で必須開発の項目とできるところまでつくりましょうと2段階で開発範囲を決めます。場合によっては、全部ができるところまで、としているケースもあるでしょう。
名称 | 個数 |
部品1 | 2つくらいつくれるかな。でも作れなくてもごめんね |
部品2 | 10つくらいつくれるかな。でも作れなくてもごめんね |
部品3 | 30つくらいつくれるかな。でも作れなくてもごめんね |
その上、プロジェクトを開始した後の仕様を詰めるのでプロダクトを作るプロジェクトの見積もり時点ではどんなプロダクトの仕様かさっぱりわかりません。ここが請負契約で見積もる時に大きな違いです。言い換えれば、見積もり時点で仕様が確定できない、ということです。
さらに、
名称 | 個数 |
部品1 | 2つくらいつくれるかな。でも作れなくてもごめんね。仕様はプロジェクトが始まってから決めるから |
部品2 | 10つくらいつくれるかな。でも作れなくてもごめんね。仕様はプロジェクトが始まってから決めるから |
部品3 | 30つくらいつくれるかな。でも作れなくてもごめんね。仕様はプロジェクトが始まってから決めるから |
となるわけです。これでは発注者側も受注者側としても請負で契約すること自体が成立しません。となれば、自然と準委任契約か、派遣契約しか契約の選択肢がなくなるのです。
アジャイルをどうしても双方が請負契約でやりたいと願う場合の1つのアイデアとしては、プロダクトバックログと仕様を決めるプレフェーズを準委任契約か派遣契約で行い、開発仕様を予め決めておくというやり方です。
ちょっと待って、それでは…と察した方は偉いです。そのとおり、これってスコープが明確になっているのでウォーターフォールでもできます。ただ、開発チームがどっちでやりたいかだけの話になってしまっているだけです。
もう1つの契約のやり方は、所謂、保守契約を結び、その契約で提供する工数の中で開発を行うものです。保守は通常、成果物を収める責任を負うような契約をしませんし、保守要員を計画して、実際にどのようなサービスを提供するかは保守契約の中で提供技術の仕様だけを決めておき、個別テーマは都度検討とすることが多いですから、その中でアジャイル開発の形態をとって開発するには向いています。
請負契約、準委任契約そして保守契約と提供する役務を並べるとこんな感じになりますね。
契約の種類 | 役務の提供方法 | |
請負契約 | 見積もり仕様に沿った成果物の提供 | 民法634条 瑕疵担保責任 |
準委任契約 | 専門性を持った役務を決めた工数または作成物で提供する | 民法656条 |
保守契約 | 専門性を持った役務を決めた工数または作成物で提供する | 民法上の条文はなく、委任契約で結ぶ |