（1）一括請負契約
ウォーターフォール型開発では開発に入る前に仕様を決め、完成させる内容を明確にするということは本連載でも何度か触れました。そのため、あらかじめ決まっている仕様に従って作成した成果物の対価として費用を払う「一括請負契約」が一般的なソフトウェア開発の契約モデルとして普及してきました。
この契約モデルには、発注者である顧客側に次のようなメリットがあります。
- ソフトウェアの仕様、納期、費用が決まっている
- リスクや瑕疵（かし）担保責任は受注者（ベンダー）が負ってくれる
しかし、柔軟な変化を受け入れることを特長とするアジャイル開発では、開発途中での仕様変更を許容するので、最初から仕様が定められている請負契約と相性が良いとはいえません。
【契約事例】
・最小限のスコープ（成果物）を約束する
契約事例はごく少数ですが、非常にユニークな契約モデルです。この契約では最小限のスコープのみを最初に約束します。つまり契約書に記載されるのは最小限必要な機能だけです。そしてこの機能が完成後、顧客と開発側が互いに相談しながら追加機能を開発していきます。原則、請負契約ですが「この機能だけはどうしても欲しい」という要求がはっきりしているが、他の機能については決め切れない場合に有効といえるでしょう。
この契約モデルで重要になるのは「顧客と開発側の信頼関係」です。契約上は契約書に記載されている機能以外を作成しなくても問題はありません。しかし契約期間内は追加機能の開発にもベストを尽くすということが、お互いの間で暗黙の了解として認識されているケースがほとんどです。双方の信頼関係、特に開発側が顧客からいかに信頼されているかがポイントになります。最小限の機能しか約束されていないからと言って、本当に最小限のものしか作らなかったのであれば、顧客はどんなにがっかりするか、想像に難くないでしょう。
・短期の契約を繰り返す
これも基本的に請負契約に属しますが、特徴は1～3カ月単位の契約を繰り返すことで、最終的に大きなソフトウェアを作ります。短い契約期間にすることで、その間に開発する分の仕様を定めることが可能となります。この間に生ずる変化への対応を次の期間にまわしても大きな問題とはなりません。更にこの短い契約期間の中でもイテレーションを繰り返して開発します。基本として、複数の契約案件が同時に走ることはありません。つまり、1チーム10名以内で開発する比較的小規模な案件に向いているといえます。
短期の請負契約
・機能ごとに契約する
システム全体を0.5～3人月で開発できる程度の機能に分割し、優先度の高い機能から順に契約していくというモデルです。こちらも、小さな機能なので、期間内に発生する分の仕様を定めることが可能となります。五月雨式に着手していくことになるので、複数の契約案件が同時に走ることがあるのも特徴です。このため、比較的規模が大きな案件にも適用できます。
機能ごとの請負契約
これらの事例は基本的にウォーターフォール型開発の請負契約と変わりません。また、機能ごとに契約を結ぶため、リスクヘッジがしやすいということもあり、顧客側にとっても受け入れやすいというメリットがあります。
