2009/4/29 by peterstev


以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。


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

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

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

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

  1. 「スプリント契約」
  2. 固定価格・固定スコープ
  3. タイムアンドマテリアル
  4. タイムアンドマテリアル(固定スコープ、上限コスト付き)
  5. タイムアンドマテリアル(変動スコープ、上限コスト付き)
  6. フェーズ開発
  7. ボーナス/ペナルティ条項
  8. 固定利益
  9. 「早期中止、変更無料」
  10. ジョイントベンチャー

「スプリント契約」

Alt Text

  • 「品質」と「スケジュール」は相反する
  • 「スコープ」と「コスト」は相反する

「スプリント契約」というメタファを使えば、スクラムで仕事をしているときのプロダクトオーナーと開発チームとの関係が理解しやすい(時には理解が強化される!)。

構造
これは正式な契約書ではないが、スプリントにおけるプロダクトオーナーとチームとの合意がわかりやすく示されている。
スコープの変更
開発チームは、事前に約束した機能(スコープ)を、一定の品質基準で、スプリントの終了までに納品することに合意する(理想としては、事前に約束した以上の機能を納品する)。プロダクトオーナーは、スプリントの途中で指示を変更しないことに合意する。
リスク
スクラムプロジェクトは、以下の4つのパラメータが固定されたミニプロジェクトの連続と考えることができる。時間(スプリントの長さ)、スコープ(スプリントバックログ)、品質(Doneの定義)、コスト(チームの規模×スプリントの長さ)。ただし、スコープだけは変更可能で、スプリントの終了時に計測する。

ヒント

「スプリント契約」については、スプリントの開始時にEメールやプロジェクトWikiなどで確認するといいだろう。正式な契約形態とは関係なく、信頼関係を築くことができる。

ヒント

「スプリント契約」を正式な契約に反映することもできる。以前、数回のリリース後に、1ページのタイムアンドマテリアル契約に収まったことがある(次回の四半期リリースまたはメジャーリリースに向けた上限コスト付きタイムアンドマテリアル契約になることもある)。

固定価格・固定スコープ

Alt Text

  • 収益は工数や納期に関係なく一定である
構造
納品可能なものに合意して、それを納品する。そして、請求書を送付する。顧客は固定価格プロジェクトを好む。安心感があるからだ(少なくとも顧客はそう考えている)。
スコープの変更
「固定スコープ」という名が示すように、この変更要求ゲーム(訂正:変更要求プロセス)では、スコープの変更が制限されている。このプロセスはコストがかかる。また、スコープの変更は避けられないことがほとんどである。顧客がスコープの追加を要求するのは当然であり、それによってプロジェクトの終了が難しくなることが多い。この場合、顧客満足を達成したいがために、サプライヤが譲歩するのが常である。固定価格の要件では、仕様書に「等」などという言葉を使うのは非常に危険である。
リスク
明らかなリスクは、サプライヤ側にある。見積りが間違っていると、そのプロジェクトは赤字になるからだ。明らかではないリスクは、変更要求ゲームにある。変更要求ゲームでは、サプライヤはスコープの変更に対する追加収益について交渉する。工数やリスクを極端に少なく見積もっていたり、あり得ないほどの低価格を提示していたりすると、その損失はサプライヤの存続すら脅かしかねない。これもまた顧客にとっての問題となる。
関係
競合関係~無関心。顧客は通常、より多くのスコープを求め、サプライヤはスコープをできるだけ少なくしたい。顧客満足を達成したいがために、サプライヤが譲歩することが多い。

ヒント

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

タイムアンドマテリアル

Alt Text

構造
1か月作業した分を顧客に請求する。サプライヤはこのやり方を好む。顧客の考えが変わるリスクを顧客が負うからだ。
スコープの変更
事前に固定されていない。遅かれ早かれ、顧客は支払いを拒むようになるだろう。そして、プロジェクトは終焉を迎える。
リスク
すべて顧客持ち。サプライヤにはコストダウンに対するインセンティブがほとんどない。適切な工数と費用の請求を保証することが重要である。
関係
無関心。サプライヤは作業が増えると嬉しい。作業が増えるともらえるお金も増えるからである。

ヒント

顧客がサプライヤよりもリスク管理に長けているプロジェクトであればオススメ。上限コスト付きと組み合わせることが多い。どれだけうまくいくかは、スコープをどれだけうまく管理できるか次第である。

タイムアンドマテリアル(固定スコープ、上限コスト付き)

Alt Text

  • すべての要件が満たされたら作業ストップ
構造
固定価格・固定スコープと同じ。ベンダーが早期に完了したら、プロジェクトのコストは低下する。実作業に対して請求するからである。
スコープの変更
固定価格・固定スコープと同じ。
リスク
顧客からすると「両者にとってベスト」と思われる。予想よりも工数が少なければ、それだけコストが少なくて済むからだ。しかし、上限コストに達すれば、固定価格プロジェクトと同じである。
関係
従属関係。サプライヤからすると、ゴールは上限コストに達することである。サプライヤには当初の予算よりも少なくするインセンティブはない。顧客は、内部的には固定価格プロジェクトとして扱っているだろうから、コストを削減するためにスコープを削ることはない。

タイムアンドマテリアル(変動スコープ、上限コスト付き)

Alt Text

  • 利益が最大化する最遅点で作業ストップ
構造
タイムアンドマテリアルと同じだが、上限コストがあるため、顧客にとっては経済的リスクが軽減される。
スコープの変更
固定価格・固定スコープと同じ。
リスク
顧客にとって必要なビジネス価値が達成できないまま予算切れになることがある。顧客は求めたものすべてを手に入れられるわけではない。
関係
協力関係。限られた予算と変動スコープを組み合わせることで、顧客とベンダーは、求められるビジネス価値を利用できる予算内で達成しようとする。

ヒント

私の経験から言わせてもらえば、この契約形態はスクラムとよく馴染む。スプリントをコントロールするのは顧客である。協力関係とは、途中で何か問題が発生しても、お互いが納得できる解決策にたどり着けるということだ。

フェーズ開発

Alt Text

  • 四半期以内に機能を納品する。予算と優先度も四半期ごとに調整する。
構造
四半期のリリースごとに予算を作り、リリースが成功すれば、追加予算を認める。
スコープの変更
このモデルでは明確に定義されていない。ここで言うリリースとは、いわばタイムボックスである。四半期後に次のリリースが用意されているので、タイムボックスに入らない機能をあと回しにすることが容易に受け入れられる。
リスク
顧客のリスクは四半期ごとの開発コストに制限される。
関係
協力関係。顧客とサプライヤのどちらにも各リリースが成功することに対してインセンティブがある。リリースが成功すれば、追加予算が認められる。

ヒント

ベンチャーキャピタリストはこのやり方をしている。これは、タイムアンドマテリアル(変動スコープ、上限コスト付き)とうまく組み合わせることができる。私はこのモデルを適用して幸せに働いたことがある。両者でリリース目標、時間給、上限コストを簡単に決めてから、顧客がプロダクトオーナーを選出した。その他のことは、「スプリント契約」で決めた。

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

Alt Text

構造
サプライヤは、プロジェクトが早期に完了したらボーナスを受け取り、遅延したらペナルティを支払う。ボーナスとペナルティの金額は、遅延した機能分である。
スコープの変更
受け入れることは難しい。変更は遅延につながりかねない。遅延は絶対に許されない。
リスク
顧客には早期完了に対するインセンティブはあるだろうか?ROIを論拠にすれば、説得力があり、誰の目にも明らかである。さもなければ、顧客は安価だが時間のかかるソリューションを手に入れることになる。
関係
協力関係にもなりうるが、顧客が合意した日までに本当にそのソフトウェアが欲しいということでなければ、無関心へと悪化する。

ヒント

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

固定利益

Alt Text

  • 目標完了日を過ぎると、サプライヤは原価で作業する。
構造
あらゆるプロジェクト予算は、費用と利益によって成立している。たとえば、両者が事前に10万ドルの利益に合意したとする。いつプロジェクトが完了しても、請負人はかかった費用プラス合意した利益を受け取ることができる。
スコープの変更
固定。
リスク
は共有。プロジェクトが早期に完了したら、顧客の支払いは少なくて済む。しかし、サプライヤも利益を受け取れる。プロジェクトが予算を超過したら、顧客の支払いは多くなるが、サプライヤは追加の利益を得ることはできない。期日を過ぎると、サプライヤは追加の利益を請求できなくなるが、費用はカバーできる。
関係
協力関係。両者とも早期完了へのインセンティブが明確。顧客はコストを削減できる。サプライヤは利ざやが大きくなる。

早期中止、変更無料

Alt Text

構造
仕掛品がほどんどなくなるため、アジャイルソフトウェアプロジェクトとよく馴染む。スプリント終了後には、機能は「完成している」か「着手されていないか」のいずれかである。作業は基本的にはタイムアンドマテリアル(上限コスト付き)で行うが、プロジェクト予算を使い果たしてはいけないという暗黙の了解がある。一定の機能が納品されると、顧客は十分なビジネス価値があると見なして、これ以上の開発は必要ないと判断し、プロジェクトを中止する。キャンセル料は、支払われるべき利益と同額。
スコープの変更
変更できる。計画されていたが実装されていない機能は、同サイズのストーリーと入れ替えることができる。機能を追加するには追加費用がかかる。
リスク
共有。両者ともプロジェクトを早期に完了したい。顧客はコスト削減、サプライヤは大きな利ざや。

ヒント

予算が超過したら、固定利益や上限コストのルールを適用できる。固定利益のほうが協力関係を育てることができる。

ジョイントベンチャー

Alt Text

Photo courtesy of [email protected]

構造
両者が協同出資の形でプロダクトに出資する。開発フェーズでお金が飛び交うなんてことはないが、レベニューシェアやソフトウェアを利用することで得られる利益が基にしてROIを測ることになる。
スコープの変更
両者の必要なものに合わせて定義する。
リスク
なんでも半分ずつ。意志決定時間は長くなりがち。両者間にライバル心が芽生えるかも。プロダクトから価値を抜き出すモデルが違えば、優先度も違ってきて、出資の意欲も違ったものになってしまう。

ヒント

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

おすすめ

私はフェーズ開発契約で長年やってこれたのだが、これは非常に幸せなことだと思う。最初は固定スコープ(上限コスト付き)契約だったが、一緒に働いて、信頼のレベルを上げることで、契約書から余計な文言が消えていった。信頼、ほんのちょっとの決まり文句、スプリント契約、四半期ごとの経営陣の承認、これでうまくいった。

「早期中止、変更無料」契約は、スクラムやアジャイル開発プロセスの強みを競争力の高い強みへと変えてくれる。

  • 漸進的にビジネス価値を優先付けて納品していくことで、完全な失敗というのは劇的に減っていく。この強みは、顧客に還元される。
  • さらに、協力モデルによって、コストダウンに対する両者のインセンティブが高まる。
  • 早期中止条項によって、スクラムチームが成し遂げる高い生産性に報いることができる。マイナス面では、この条項が「ゴールデンパラシュート(高額の退職金)」のように受け止められてしまうことだ。今日のような経済危機の状況下では、政治的に受け入れにくいことかもしれない。

この契約は、上限コストと合わせるとうまくいくかもしれない。ただし、協力関係が崩れてしまうかもしれないことは警告しておこう。

契約形態は、成功プロジェクトの基礎を築くものだ。アジャイルマニフェストは正しかった。契約よりも顧客との協働が重要なのである。何をするにしても、顧客との関係は良好に!

さらに詳しく知るために

日本語訳について

Change Log

  • 2012/3/21: ちょっとだけ推敲。
  • 2009/5/9: 翻訳。