アジャイル開発と契約
こんにちは、ライトパスの建守です。
今回は、アジャイル開発プロジェクトを行うときの契約形態について考えてみたいと思います。前提として、システム開発をしてほしいと思っている顧客企業（発注者）と、システム開発を引き受けるITベンダー（受注者）とが締結する契約を対象とします。そして、顧客企業とITベンダーが協力しあってアジャイルなやり方でシステム開発を進めていくプロジェクトを想定します。よって、顧客企業内ではアジャイルなプロジェクト運営をしているけれども、ITベンダーへは仕様を事前に確定させて作業を委託する、といったケースは除外します。顧客企業内部で開発をしているけれども、追加要員が必要なので一部メンバーを外部から調達するようなケースも今回は考慮の対象外としました。
日本のシステム開発で主に使われている契約形態
さて、日本のシステム開発の現場では、顧客企業とITベンダーの契約は以下いずれかとなることがほとんどです。
- 一括請負契約
- 準委任契約
この2つの契約の違いは、弊社ホームページにも書いておりますので、よければこちらもご覧ください。
改めて要点を整理すると、「一括請負契約」（以後、単に「請負契約」とします）ではあらかじめ決められた作業内容を、あらかじめ決められた期限までに受注者が実施し、その成果を発注者に対して納品、発注者が納品物をチェックして問題なしと判断したら受注者に対価が支払われる、という契約です。
一方の「準委任契約」は、契約に定められた作業を受注者が実施し、その作業の労力に対して発注者が対価を払うという契約です。こちらの場合、請負契約とは異なり、成果の納品が支払い条件とはなりません。指示された作業を受注者が誠意をもって（善管注意義務に従って）実施すればOK、という契約です。
請負契約と準委任契約の使い分け
では、この2つの契約形態はどのように使い分けられているでしょうか？ポイントは以下の2点にあります。
- 契約締結前に、作業内容と期限（仕様と納期）を確定できるかどうか
- 発注企業側に、自らが主体となって作業を進める力（リソースの空きやスキル）があるかどうか
まず1点目について。請負契約は前述の通り、契約で決められた作業を受注者が実施し、決められた期日までに作業を完了させて成果物を納品するというものです。したがって、作業内容と期限（仕様と納期）を確定させることができない場合、必然的に請負契約は締結できません（建前上は）。仕様と納期の確定が可能であれば、次に述べる発注者側のスタンスによって請負契約か準委任契約かが変わってきます。
次に2点目について。準委任契約でシステム開発を委託する場合、受注企業には成果物（＝完成したシステム）を納品する義務が発生しません。よって、システム完成までのコントロールを発注者側がしっかり行う必要があります。これを行うためのメンバーが発注企業内に確保できない場合、もしくはそのようなことに社内リソースを割きたくない場合、完成責任を受注者側に転嫁できる請負契約を選択することになります。逆に自社でしっかり音頭を取りたい発注者であれば、準委任契約が適切です。
アジャイル開発における契約形態
さて、それでは本題のアジャイル開発における契約についてです。以前の投稿（「アジャイルソフトウェア開発宣言」や「アジャイルソフトウェアの12の原則」）でも書きましたが、アジャイル開発では、変化を積極的に受け入れ、常に軌道修正をしながら顧客にとってのシステムの価値を最大化することを基本ルールとしています。したがって、アジャイル開発と請負契約とは本質的に相いれません。作業内容と期限（仕様と納期）をあらかじめ決めておくことができない（仮決めしてもいいけど、それに固執してはならない）のです。
よって、本来は準委任契約が望ましいといえます。契約の内容としては、特定のシステム開発業務への従事を対象とし、開発に従事するメンバーの数と従事する時間数に応じた費用が契約期間中に発生するという、一般的なものになります。
アジャイル契約における発注者側のリスク軽減方法
しかしこの契約、受注者側には特定期日までに決まったコストでシステムを完成させる責任がありません。よって、発注者側からすると「システム完成までに予算オーバーするんじゃないか」「いつシステムが完成するのかわからない」「いつまでもシステムが出来上がらないんじゃないか」といった不安が残りますよね。
これらの不安はアジャイル開発の進め方次第で無用にはなるのですが、それはまた別の機会に述べるとして、契約段階で多少なりともリスク対策をしておきたいところかと思います。それにはこうするといいですよ、と申し上げられればいいのですが、残念ながら私の知る限り、アジャイル開発の標準的な契約モデルというのは存在していません・・・。とはいえ、ここで記事を終わらせてしまったら、「ここまで読ませておいてそりゃないよ！」とお叱りを受けてしまいそうなので、いくつかのアイデアをご紹介いたします。
基本／個別契約モデル
情報処理推進機構（IPA）というところが提唱している契約モデルです（参考「非ウォーターフォール型開発に適したモデル契約書の改訂版を公開」）。IPAお勧めというより、IPA内で研究したモデルの一つというところでしょうか。
これは、プロジェクト全体を通しての決めごとを基本契約という形で締結し、実際の開発業務に関する内容を複数の個別契約に分割して締結する、というものです。個別契約をできる限り細かく、かつ内容の決まった機能から順次締結することで、アジャイル開発の利点である柔軟性の高さを活かしつつも、具体的な仕様とそれを実現するためのコスト・期間をある程度契約で縛れる、というのが利点だと理解しています。
組合モデル
これも上述のIPA版モデル契約書の一つです。特定のシステムを開発するプロジェクトのための組織（民法における任意組合）を作って、そこに顧客企業側は資金を出資、システム会社側はスキルを持った要員を出資するという形になります。実際の開発業務はこの組合から別途システム開発会社に発注、その際の契約は前述の「基本／個別契約モデル」で、という説明もなされていますが、これについてはその必要性が恥ずかしながら理解できておりません。。
Money for Nothing and Change for Free
これは、『PMI-ACP Exam Prep, Second Edition』（Mike Griffiths, RMC Publications）という書籍で紹介されている考え方です。「PMI」は「Project Management Institute」（プロジェクトマネジメント協会）の頭文字、「ACP」はPMIが実施している「Agile Certified Practiioner」という認定試験の頭文字で、この書籍は試験対策本です。
閑話休題。この考え方では、基本的には従来の開発と同様に、プロジェクト開始段階で見えている仕様について見積もりをして契約を締結し、仕様変更については追加工数とその成果物をあらためて見積もって追加契約を結ぶという形を取ります。
ここにアジャイル的な考え方を反映させたのが「Change for Free」の部分です。当初予定になかった機能を追加したいとき、その機能と同程度の工数を見込んでいたほかの機能を開発対象から除外するのであれば、それは無償で対応しますよ、ということです。もっともこれは、アジャイルではなくても日本の開発現場では普通にやっていますね。契約社会のアメリカでは特別なことなのかもしれませんが・・・。
もう一つアジャイル開発でありがちなこととして、優先順位の高い機能から順に作ってリリースしていったら、ある段階でシステム開発の目的を達することができたので、残りの機能は開発不要になった、ということがあります。こうした場合でも従来の契約では、発注者は当初決めた契約金額を受注者に対して支払わなければなりません。となるとお金がもったいないので、要らない機能であっても当初計画通り作ってしまえ、ということになります。
ですが、要らない機能を作りこんでシステムが肥大化した結果、システムのレスポンスが悪くなったり、後々の機能追加に余計な手間がかかるとなったらどうでしょう？無駄な作業をした挙句に、品質は下がるは運用コストは上がるは、踏んだり蹴ったりです。
このような事態に対応するため、プロジェクトを途中でやめる権利を発注者側に認めましょう、というのがこの契約のミソです。とはいえ、突然契約を打ち切られたら受注者側はたまったものじゃありません。だから、開発不要となった機能で見込んでいたコストの一部を発注者が受注者に支払う「Money for Nothing」という考え方を導入します。発注者は当初予定よりコストを削減することができ、受注者は早くプロジェクトを終えた上に作業していない分の開発費（の一部）がもらえて、お互いラッキーだね、というものです。
Graduated Fixed-Price Contract
これも『PMI-ACP Exam Prep, Second Edition』で紹介されている考え方の一つです。発注者と受注者は、標準月額単価（時間単価でもOK）と標準プロジェクト期間を定めて契約を締結します。プロジェクトが予定通りに終われば、もちろん契約通りの金額が発注者から受注者に支払われます。Fixed-Price Contractですからね。
肝は「Graduated」の部分です。もしプロジェクトが予定より早く終わったら、定めた単価よりも高い単価に基づいて金額が再計算され、受注者から発注者に支払われます。逆にプロジェクトが予定より長引いた場合、単価が割り引かれます。
例えば、時給10,000円、プロジェクト期間100時間という契約を締結したとします。スケジュール通りにプロジェクトが終わったら、10,000円×100時間＝100万円が契約金額ということになります。
このプロジェクトが80時間で終わった場合、単価を11,000円に上げて、11,000円×80時間＝88万円となります。発注側にとってはトータルコストが下がり、受注者側にとっては短時間に効率よく売り上げをあげることができたことになります。
プロジェクトが120時間かかったら、単価を0.9万円に下げて、9,000×120時間＝108万円です。発注側にとっては費用がかさみ、受注者にとっても長時間、低い単価で作業を続けなければならなかったという状況です。
つまり、発注者／受注者ともに、プロジェクトを早期に終わらせればメリットがあり、プロジェクトを長引かせるとデメリットが生じるわけです。この仕掛けによって、発注者は開発対象の絞り込みに真剣になり、受注者は開発効率を上げることに必死になるという構図が生まれます。
さいごに
日本でもアジャイル開発の適用事例は増えているとはいえ、発祥の地であるアメリカとは商習慣や業界の在り方が異なることもあり、どのような契約を締結すればよいのか、という点では、いまだに主流といえるべきモデルは出来上がっていないのが現状です。
今回の記事が、皆さまがアジャイル開発での契約内容を考えるうえで少しでもお役に立てたらと願っております。