翻訳 - 次のアジャイルソフトウェアプロジェクトに使える10の契約

以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。

Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。

次のアジャイルソフトウェアプロジェクトに使える10の契約

2009/4/29 by peterstev

ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。それでは、アジャイルプロジェクトに使える競技ルールにはどんなものがあるのだろうか？そして、最も適したルールとは何なのだろうか？

先週のことだが、我々は契約書の目的や内容を吟味し、 Scrumやアジャイルプロジェクトに適した契約書の評価基準を定めた。私は、契約の形態を比較するための4つのポイントを提示した。

契約の構造
スコープ（要件）の変更方法
顧客とサプライヤ間でのリスクや報酬の配分方法
奨励する顧客関係：競合関係（win-lose）、協力関係（win-win）、無関心（お互いのloseは気にしない）、従属関係（俺の物は俺の物、お前の物も俺の物）

今週、早速、見込みのありそうな契約書を取りそろえ、Scrumやアジャイルプロジェクトに適しているかどうかを調べてみた。

「スプリント契約」
固定価格・固定スコープ
実費精算契約
実費精算契約（固定スコープ、上限コスト付き）
実費精算契約（変動スコープ、上限コスト付き）
フェーズ開発
ボーナス／ペナルティ条項
固定利益
「早期中止、変更無料」
ジョイントベンチャー

スプリント契約

Scrumで作業をしているときに、「スプリント契約」というメタファを使えば、プロダクトオーナーと実装チームの関係が理解しやすい（時には理解が強化される！）ことに気づいた。

構造: これは正式な契約書ではないが、いちスプリントにおけるプロダクトオーナーとチームとの合意が分かりやすく示されている。

スコープ: 実装チームは、合意した機能（スコープ）群を、一定の品質基準で、スプリントの終了までに納品することに対して、全力を注ぐことに合意する（理想としては、事前に約束した以上のものを納品する）。プロダクトオーナーはスプリント終了前に指示を変更しないことに合意する。

リスク: Scrumプロジェクトは、次のような固定パラメータを持ったミニプロジェクトの連続だと見なされるかもしれない。時間（スプリントの長さ）、スコープ（スプリントバックログ）、品質（完了の定義）、コスト（チームの規模×スプリントの長さ）。スコープだけは変更することができ、各スプリントごとに計測される。

ヒント: スプリント契約について、各スプリントの初めにEメールやプロジェクトWikiなどで確認するとよいだろう。契約形態とは関係なしに、信頼関係を築くことができる。

ヒント: スプリント契約が正式な契約に反映されることもある。リリースを数回行ったあとで、正式な契約が1ページの実費精算契約に収まったこともある（3ヶ月リリースあるいは次のメジャリリースに対する上限コスト付きのこともあるが）。

固定価格・固定スコープ

図中：売上は工数や納期に関係なく一定である

構造: 納品可能なものに合意し、それを納品する。そして、請求書を送付する。顧客は固定価格プロジェクトを好む。安心感があるからだ（少なくとも顧客はそう考えている）。

スコープの変更: "固定スコープ"という名が示す通り。変更要求ゲーム（訂正：変更要求プロセス）は、スコープの変更が制限されていることを意味する。このプロセスはコストがかかり、通常、変更は避けられない。顧客がさらなるスコープを要求するのは当然のことであり、その結果、プロジェクトの終了が難しくなることが多い。こうなると、顧客満足を達成したいがために、サプライヤが譲歩するのが常である。固定価格の要件では、仕様書に「等」という言葉を使うのは非常に危険である。

リスク: 明らかなリスクはサプライヤ側にある。見積りが間違っていると、そのプロジェクトは赤字だ。見えないリスクは変更要求ゲームだ。そこでサプライヤは、スコープ変更に対する追加費用（売上）を交渉する。工数やリスクを極端に少なく見積もっていたり、あり得ないくらいの低価格を提示していたりすると、サプライヤの存続すら脅かしかねない。これもまた顧客にとっての問題となる。

関係: 競合関係から無関心。顧客は通常、より多くのスコープを求め、サプライヤはスコープをできるだけ少なくしたい。顧客満足を達成したいがために、サプライヤが譲歩することが多い。

ヒント: ユーザーストーリーを使って機能要件を定める。固定価格プロジェクトに対する戦略については、後ほど説明する。

実費精算契約

構造: 1ヶ月作業した分を顧客に請求する。サプライヤはこのやり方を好む。顧客の考えが変わるリスクを顧客が負うからだ。

スコープ: 事前に固定されていない。遅かれ早かれ、顧客は支払いをしたくなくなるだろう。そして、プロジェクトは終わりを迎える。

リスク: すべて顧客持ち。サプライヤにはコストダウンに対するインセンティブがほとんどない。適切な工数と費用を請求していることを保証することが重要である。

関係: 無関心。サプライヤは作業が増えると嬉しい。作業が増えるとお金も増えるからである。

ヒント: 顧客がサプライヤよりもリスク管理に長けているプロジェクトであればオススメ。上限コストと組み合わせることが多い。どれだけ作業がうまくいったかは、スコープへの対応次第である。

実費精算契約（固定スコープ、上限コスト付き）

図中：すべての要件が満たされたら作業ストップ

構造: 固定価格・固定スコープと同じ。ベンダーが早期に完了したら、プロジェクトのコストは低下する。なぜなら、実作業に対して請求するからである。

スコープ: 固定価格・固定スコープと同じ。

リスク: 顧客からすると「両者にとってベスト」と思われる。予想よりも工数が少なければ、それだけコストが少なくて済むからだ。しかし、上限コストに達すれば、固定価格プロジェクトと同じである。

関係: 従属関係。サプライヤからすると、ゴールは上限コストに達することである。サプライヤには当初の予算よりも少なくするインセンティブはない。顧客は、内部的には、固定価格プロジェクトとして扱っているだろうから、コストを削減するためにスコープを削ることはない。

実費精算契約（変動スコープ、上限コスト付き）

利益が最大化する最遅点で作業ストップ

構造: 実費精算契約と同じだが、上限コストがあるため、顧客にとっては経済的リスクが軽減される。

スコープ: 固定価格・固定スコープと同じ。

リスク: 顧客にとって必要なビジネス価値を達成できないまま予算切れとなることがある。顧客は求めたものすべてを手に入れられるわけではない。

関係: 協力関係。限られた予算と変動スコープを組み合わせることで、顧客とベンダーは、求められるビジネス価値を利用できる予算内で達成しようとする。

ヒント: 私の経験から言わせてもらえば、この契約形態はScrumとよく合う。顧客が各スプリントをコントロールする。

フェーズ開発

構造: 3ヶ月のリリースごとに予算を出し、リリースが成功すれば、追加予算を認める。

スコープの変更: このモデルでははっきりとは定義されていない。リリースが事実上タイムボックス化されている。3ヶ月後の次のリリースがあることで、タイムボックスを達成するために機能をあと回しにすることが容易に受け入れられる。

リスク: 顧客のリスクは3ヶ月間の開発コストに制限される。

関係: 協力関係。顧客とサプライヤのどちらにも各リリースが成功することに対してインセンティブがある。そのため、追加予算が認められる。

ヒント: ベンチャーキャピタリストはこのやり方で働いている。これは、実費精算契約（変動スコープ、上限コスト付き）とうまく組み合わせることができる。私はこのモデルを適用して幸せに働いたことがある。正式な契約においても、リリース目標、時間給、上限コストを簡単に定めることができた。顧客がプロダクトオーナーを定めた。その他のことは、スプリント契約で定めた。

ボーナス／ペナルティ条項

構造: サプライヤは、プロジェクトが早期に完了したらボーナスを受け取り、遅延したらペナルティを支払う。ボーナスとペナルティの金額は、遅延した機能分である。

スコープの変更: 受け入れることは難しい。変更は遅延につながりかねない。遅延は絶対に許されない。

リスク: 顧客には早期完了に対するインセンティブはあるだろうか？ROIを論拠にすれば、説得力があり、誰の目にも明らかである。さもなければ、顧客は安価だが時間のかかるソリューションを手に入れることになる。

関係: 協力関係にもなりうるが、顧客が合意した日までに本当にそのソフトウェアが欲しいということでなければ、無関心へと悪化する。

ヒント: 建設工事（道、トンネル、滑走路）に適しているため、よく利用される。スコープの変更は重要ではなく、純粋な経済コストによって顧客は期日を守ろうとする。

固定利益

図中：目標完了日を過ぎると、サプライヤは原価で作業する

構造: あらゆるプロジェクト予算は有効原価と利益によって成立している。たとえば、両者が事前に10万ドルの利益に合意する。いつプロジェクトが完了しても、請負人は被ったコストプラス合意した利益を受け取る。

スコープ: は固定。

リスク: は共有。プロジェクトが早期に完了したら、顧客の支払いは少なくて済む。しかし、サプライヤには利益がある。プロジェクトが予算を超過したら、顧客の支払いは多くなるが、サプライヤは追加利益を得ることはできない。期日を過ぎると、サプライヤはさらなる利益を請求できないかもしれないが、コストはカバーできる。

関係: 協力関係。両者とも早期完了へのインセンティブが明確。顧客はコストを削減でき、サプライヤは利ざやが大きくなる。

早期中止、変更無料

構造: 仕掛品がほどんどなくなるため、アジャイルソフトウェアプロジェクトと馴染む。各スプリント終了後では、機能は完成されているか、開始されていないかのいずれかである。作業は基本的には実費精算契約（上限コスト付き）で行うが、プロジェクト予算を使い尽くしてはいけないという暗黙の了解がある。一定の機能が納品されると、顧客は十分なビジネス価値に気づき、これ以上の開発は必要ないと考え、プロジェクトを中止する。キャンセル料は残った支払われるべき利益と同額。

スコープ: は変更できる。計画されていたが実装されていない機能は同サイズの他のストーリーと入れ替えることができる。機能を追加するには追加コストがかかる。

リスク: 共有。両者ともプロジェクトを早期に完了したい。顧客はコスト削減、サプライヤは大きな利ざや。

ヒント: 予算が超過したら、固定利益や上限コスト契約のルールを適用できる。固定利益のほうが協力関係を助長する目標と一致する。

ジョイントベンチャー

Photo courtesy of hydropeek@flickr

構造: 両者が協同出資の形でプロダクトに出資する。開発フェーズで両者間をお金が飛び交うなんてことはないが、両者ともROIを持たなければならない。レベニューシェアやソフトウェアを利用することで得られる利益が基になる。

スコープ: パートナーシップの必要性に合わせて定義される。

リスク: なんでも半分ずつ。意志決定時間は長くなりがち。両者間にライバル心が芽生えるかも。プロダクトから価値を抜き出すモデルが違えば、優先度も違ってきて、投資の意欲も違ったものになってしまう。

ヒント: プロジェクトを独立した企業だと考えてみる。1チームに、開発、プロダクトマーケティング、プロダクトオーナーの役割を入れる。現実的には、親しい者とそうでない者とを分けてもよい。

さらに詳しく知るために

固定価格プロジェクトとアジャイル開発は馴染まないと言われている。私の経験からすると、これは厳密には正しくない。とはいえ、他の契約形態のほうが良いと思う。
固定利益契約はコストプラス固定費契約とも言われる。コストプラス○○契約には、他にもいくつか種類がある。
『リーンソフトウェア開発』（Mary Poppendieck、Tom Poppendieck著）の契約の項には、今日の契約形態のまとめ、信頼についての議論、成功するには「鉄の三角形」を満たすよりもやることはたくさんあるだという喚起が記載されている。
Jeff Sutherlandの早期中止に関する記事。Agile Project GroupでGerry Kirkが中心となって契約の草案が作成されている。

日本語訳について

訳：kdmsnr

Change Log

2009/5/10: 一部修正
2009/5/9: 直訳アップ

TODO

図の翻訳