アジャイル手法に関してよく質問されることのひとつに，"アジャイル開発の契約はどのようにすればよいのか"，というものがあります。
従来のウォーターフォールモデル手法，すなわち要件を定義し，サプライヤが (自身の要求解釈とコスト見積に基づいて) 価格を提示して，両者が法的拘束力を伴う契約書にサインする，というやり方は，企業が何かを購入する場合にはとても都合のよいものです。
サインが完了すれば，次は開発期間です。開発のスコープ内に実際にあるものは何か，何が範囲外なのか，契約変更を要するものは何か，などについて全員で議論します。そうこうしているうちに開発作業が完了します。白熱した議論を繰り返した後，顧客がソフトウェアを正式に受け入れれば支払いが行われます。そして顧客は 200kg のソフトウェアを，サプライヤはお金を手にいれて，全員が – あるいはほぼ全員が – 満足するのです。
従来の方法で契約を行った上で，プロジェクト作業にアジャイル技法を用いても，もちろん構いません。しかしそのようなやり方は，アジャイルの本質を損なうことにもなります。アジャイルチームにとって，変更要求は大した問題ではありません。それは当初から想定されたものであるだけでなく，変更要求がまったくないことが逆に問題と見なされる場合さえあります。極端な場合，アジャイルチームは要件資料が何もない状態でも作業を始められるのです。対照的に，ソフトウエアの納入は漸次に行うことができますから，早期の検収を期待することも可能でしょう。
顧客とサプライヤがともにアジャイル開発から最大限の利益を得ることができるのであれば，従来形式の開発契約は考え直す必要があります。この領域は今なお発展中であって，企業はアジャイル契約のための新たなモデルを模索し続けているところなのです。そのため，革新的な思想の持ち主が状況を混乱させることも時にあります。
この資料では，サプライヤと顧客がアジャイル開発契約を成立させる方法として，４つのモデルを検討します。やがて新しいモデルが登場すると思われますが，現時点で選択肢として存在するのは，概ねこの４つのオプションです。
固定的な契約を覆す
固定された金額，固定された期間，固定されたスコープを持った契約は，依然として IT 業界における契約の標準的ベンチマークであり続けています。この種の契約は，プロジェクトの初期段階で作業のスコープを定義可能である，という考えに基づきます。サプライヤ側はこれを基準として，何が必要か – というより，何人がどれだけの期間必要か – を決定し，金額を算出します。それが完了すれば契約書が正式に署名され，実施に移されます。
このようなモデルは，提供される対象が "もの" ，すなわち一定量の専門的ソフトウェアである，という解釈を基準としています。しかしカスタムソフトウェアを購入するというのは，テーラーメードのスーツを買うことよりも，どちらかと言えば財務上のアドバイスを受けるのに近いのです。購入対象は品物や商品というよりも，サービスなのです。
このような基準で作業の金額評価をする人々や企業を数多く見てきましたが，"固定" されたパラメータ (スコープ，コスト，スケジュールなど) をひとつとして緩和せずにプロジェクトを完遂した例には，これまでお目にかかったことがありません。IT 業界は長年に渡ってこのような形式の契約へのサインを積み重ねてきました。それは取りも直さず，開発失敗の歴史でもあるのです。
失敗の原因を見出すのは難しいことではありません – プロジェクトのスコープの変更，追加要件の出現，要件の見落としや解釈の相違 (同じ言葉でも，人によって意味の異なる場合もあります) ，といったところでしょうか。契約のスコープが変更される理由をすべて説明しようとすれば，それだけでこの記事が埋め尽くされてしまうくらいです。理由がどうあれ，"固定されている" 契約要件が変更されたならば，他の部分もすべて変更しなければなりません。当初の予定期間や人員計画も変更が必要となり，結果的に金額も変わってきます。
一歩引いて考えてみると，このような契約の形式を使い続けるというのは，まったくもって痛ましい限りです。信念の強さや肯定的思考を実演してみせた上で，次は何とか違う結果が出てくれないだろうか，と願っているのですから。
このような契約形式がこれまで生き長らえてきたのは，おそらくは法廷での自己弁護に有利だからでしょう。それでも，もし片方が契約の不履行を訴え，もう一方がそれに反論したなら – 判断は裁判に委ねられます。固定的な契約モデルが本質的に持っている欠点を考えれば，結局は裁判所に呼び出されるリスクを増やしているに過ぎないのです。そして最後に，契約にサインしたということは「要件が出尽くして確定している」「見積が適切である」「品質が許容範囲内である」ということを，関係者全員がその時点で確信していたということに他ならない，という点にも注目すべきでしょう。このタイプの契約の歴史を振り返ると，これには驚きを禁じ得ません。
すべての人には当てはまらない
それぞれのオプションについて検討する前に，この問題はソフトウェアを開発する，あるいはアジャイルを試みる企業すべてに影響するものではない，という点を強調しておきたいと思います。ソフトウェアを開発して販売する企業 – ISV (Independent Software Vendor) とも呼ばれ，Adobe や Intuit などが該当します – がこの問題に直面する機会は，ごく周辺部分に限られています。彼らの顧客の大部分は完成した製品を購入するだけであって，製品の動作に関して直接意見を言う機会がほとんどないからです。
ソフトウェア開発を行う企業内 IT 部門の中にも，これら企業と同じような方法で契約問題を回避しているものがあります。彼らは既製品のソフトウェア (SQL Server など) を購入するか，あるいは企業内でのみ使用されるカスタムソフトウェアを開発しています。ほとんどの企業内 IT 部門は作業の外部委託を行っているので，契約書の作成や締結を行う必要はありますが，この場合は IT 部門がサードパーティのソフトウェア提供企業に対する顧客の立場になります。
企業の IT 部門からの作業請負を行うサービス会社 – ESP (External Service Provider) とも呼ばれます – は，アジャイル開発を提供する契約の必要性がもっとも高い存在でしょう。
アジャイルがもっとも当てはまるのは ISV の作業形態です。実際にアジャイルプラクティスの多くが，このセグメントを起点として発生しているのです。また，企業の方針や手順がアジャイルを許容している場合には，アジャイルは企業 IT の世界にも同じようにフィットします。
しかし ESP と顧客がアジャイル開発を導入する場合には，いくつかの問題があります。両者の間で法的契約を締結する必要があるからです。同様な問題が起こる可能性は他にもあります。
顧客 (企業 IT 部門や政府部門) は IT プロジェクトに問題が発生することを想定するため，契約条件はより厳格に，金銭的なペナルティはより高価になる傾向があります。そのため，大規模な契約に入札できるのは大手 ESP に限られてきます。中小の企業はペナルティ条項に対処できないため，巨額のペナルティに対処できるだけの資金を持ち合わせた大手と競合することができないのです。
契約の構造を変更することは，潜在的に大手 IT 顧客がカスタムソフトウェアを購入する方法を変えることになり，いわゆる win-win のシナリオをもたらす可能性があります。固定された価格，固定されたスコープ，固定された開発期間から抜け出すことのできたサプライヤが，マーケットリーダを越える競争的優位性を獲得できる位置に立つのです。そして顧客は，より良い結果を提供する革新的アプローチの恩恵を受ける役なのです。
オプション１：隠す
開発契約でアジャイルを使用するにあたって，もっともシンプルで当たり障りのない方法は，その事実を隠してしまうことです。顧客に対して，自分たちが通常とは異なる作業方法を採用することを告げないでおくのです。いつもの方法で作業見積と計画を行い，ごく普通の契約にサインした上で，成果改善のためにアジャイル手法を使用するのです。
どういう形であれ，テスト駆動開発や継続的統合，定期的なリファクタリングと再計画などは，よりよい成果の獲得に有効です。提出した方の計画はどうせ "間違っている" のですから，できる限り無視するか，可能ならば捨ててしまいます。
問題なのは，顧客が "計画の進捗状況" を知りたがった場合です。そうしたら，でっちあげてしまいましょう。計画を遵守しているように見せかけるため，計画の方を更新してしまうチームの話もあるくらいですから。ただしこのアプローチには，誠実性というものがありません。実際のところ，顧客が信用しているプロセスの一部を偽るような行為に対して，どうして彼らとの信頼関係の構築が期待できるでしょうか？ 顧客に嘘は付きたくはありませんし，信頼を築きたいと望むのも当然です。計画遵守を偽るようなサプライヤを顧客が信用するはずがありません。
実際の成果よりも計画進捗の管理の方を希望する顧客など，最初からお互いを信頼などしていないのだ，という反論ももちろんあるでしょう。そうだとしても，彼らの信頼を得られる結果を示すことは，業務受託者としての私たちの仕事なのです。
ですから "隠す" 型アプローチを機能させるには，"聞かない，言わない" 形式の方針が必要になってきます。このような方針に，あるいは計画遂行よりも実際の成果進捗を計測することに同意してくれる顧客がいるとすれば，アジャイルを隠す方法もうまく行くかも知れません。しかし，そのような理解のある顧客ならば，最初からアジャイルを隠す必要もないのではないでしょうか。
オプション２：不成功，無報酬 (No cure, No pay)
"No cure, No pay" アプローチを採用するには，ある程度の信頼関係が必要です。このアプローチはごく単純で，"顧客が成果を気に入らなければ報酬を払わない" というものです。ただし支払いをしない場合には，成果を手元に残しておくことはできません。
このアプローチは厳しいものにも思えますが，同時に報酬を増やすチャンスも得られます。このアプローチを採用すればクライアントはリスク額を低減できますが，その一方で請負う側のリスクは増大します。このようなリスクの再バランスの結果として，価格が高くなるのです。
このようなアプローチは知性的な面で (おそらくは道徳的にも) 採用しやすい位置にありますが，新たなリスクの発生も伴っています。顧客側のリスクが少ないため，開発の成功に対するモチベーションが低くなるのです。難しい決断を要するとき，妥協が必要なとき，時間が不足したとき，関与が望まれるとき，必要なことを実行するためのインセンティブが顧客にはありません。
顧客に起因するものでない限りにおいては，どのような失敗もすべてサプライヤ側の失敗なのであって，顧客が失うものはなにもないのです。
サプライヤ側で責務を守る顧客のみを作業相手として選ぶことができるならば，このようなリスクも相殺できるかも知れません。それには，契約請負側が危険であると判断する作業を拒否できる状況にあること，顧客のコミットメントのレベルを適正に評価できること，この２つが前提となります。
現在までこのモデルが適用されたと聞いたのは，ごく小さなサプライヤでの１例しかありません。資金の潤沢な企業はリスクに対して慎重であるか，あるいはこのオプションの必要性をそもそも感じていないか，のいずれかなのです。
オプション３：繰り返し契約 (Rolling Contract)
顧客との関係を維持したいのならば，関係を維持するための仕組みを用意した上で，作業の再付託を継続的に要請しなければなりません。それには Rolling Contract が効果的です。大規模な開発作業に "オール・オア・ナッシング" 形式で合意を得る代わりに，顧客とサプライヤの双方で，一連の短期開発ミニプロジェクトへの構造的な合意を導入するのです。作業単位はエピソードあるいはイタレーションなど，好みの名称で呼べばよいでしょう。
契約にはたいていの場合，何らかの総合的な目標がありますが，具体的な機能に関しての個別計画リストは含まないのが通常です。ニーズを見つけ出すこと自体が，開発作業の一部なのです。私の知る ESP などは，すべての要件を法的契約の対象外にしているくらいです。各イタレーションには何らかの成果がありますが，同じくらい重要なのは要件への理解が進むことです。
顧客はサプライヤに対して成果ごとの対価を支払った上で，次のイタレーションに進むか，あるいはそこで中断するか，を選択します。この時にサプライヤ側が実施するべきことは，a) 付加価値と有用性を持つものを提供すること，b) さらに価値を高めるために実施すべき作業の存在を示すこと，の２つです。もし生み出された価値がコストより大きいと確信できなければ，顧客らはそこまでの成果を受け取って，この開発から手を引くことが可能です。顧客が非協力的であると判断すれば，サプライヤ側も同じように作業を離れることができます。
ある意味これは，個々のフェーズ – 要件定義，設計，開発，テスト，提供 – ごとに対価を支払った上で次の作業を付託する，という従来の方法と同じです。違っているのは，プロジェクトを中断した場合，従来型モデルでは顧客の手元に何も残らないのに対して，このモデルでは何らかの成果が得られるという点です。
サプライヤ側から見れば，完全な機能のバーティカルスライス(vertical slice) を通じてその価値を示すことには，明らかなインセンティブが存在します。
顧客は，開発された成果，付加された価値，それらが一体となったソリューションを確認することができるので，作業の継続に熱意を持つに違いありません。万が一誓約が守られない事態があっても，作業を中断するというオプションがあると知っていれば問題ではありません。
このオプションは，法的なフレームワークを「もの」の提供から「サービス」の提供へと移行させます。顧客はサービスに対して契約をします。したがって彼らが購入するサービスの量には，何らかの方針が必要でしょう。この作業は４人月，あるいは 200 速度ポイント ，といった具合です。
このオプションは極端に思えるかも知れませんが，IT 部門やサプライヤの多くは，すでに身近な領域でサービス契約を使っているのです。例えば IT サポートデスクやソフトウェアメンテナンス契約などです。これらの作業は，サービス契約として記載されるのが一般的です。
オプション４：早期解約，無料変更 (Money for Nothing, Change for Free)
"Money for Nothing, Change for Free" 契約に関しては，スクラムの創始者である Jeff Sutherland 氏の手による詳細な資料があります。複数の小規模プロジェクトで構成された契約を組み上げるよりも，このアプローチではむしろ大規模な契約を推奨します。同時にそれは，大規模な事前要件分析の暗黙的な提案でもあります。ただしこの契約には，２つの追加条項があるのです。
最初の追加条項は，最高の優先度の項目に最初に取り組むこと，新たな作業に対応すること，この２つを促進するように契約を変更するものです。顧客はサプライヤと定期的に会合して，残作業の優先度を再設定することに同意します。この時，代わりに何らかの作業を中断するか，あるいは実行を見合わせることを条件に，新たな作業をバックログに加える場合もあります。これによってサプライヤとの共同作業や支援へのインセンティブを高め，顧客との関係を維持するのです。
"Rolling Contract" と同じく，顧客は定期的に，例えば毎月，提供される稼働ソフトウェアに対して対価を支払います。これが第２の追加条項であり，前項と同じように顧客との関係を維持し，暗黙的な再付託を新たに受けるためのものです。
"早期解約 (Money for Nothing)" の規定により，顧客はどのステージにおいても，残りの作業をキャンセルして，それまでの成果物を獲得することが可能になります。その場合，顧客は未処理作業の 20% をサプライヤ側に支払います。
例えば 12ヶ月，1200万ドルのプロジェクトが半分完了した時点で顧客側がキャンセルすれば，それまでに実施された分の 600万ドルに加えて，120 万ドルを支払うことになります。結果的として，契約完了時よりも480万ドル節約したことになるのです。
一見するとこのオプションは，提供する側にとっては望ましくないように思われるかも知れません。本来手に入るはずの 480 万ドルを失うことになるからです。しかし，何もしないで手に入れた 120 万ドルが，最終的にはそれを相殺します。スタッフを別の業務に素早く割り当てることができれば，この 120 万ドルはまるごと利益になるのですから。
上記のようにこのオプションは，作業に参加して早期完了させることで，コスト削減を図るためのメカニズムとインセンティブを顧客に提供します。サプライヤも同様に，変更を許容し，良い作業をすることで自由な資金を得るように動機付けされるのです。
この形式の契約例は非常に少ないのが現状です。
組み合わせ
このような４つのオプションがあれば，さまざまな方法でこれらを組み合わせて，さらに別のオプションを考えることも難しくはありません。例えば "Change for Free" を他の３つのオプションのいずれかと組み合わせて，より強力なソリューションを作り出すことも可能でしょう。同じように "No cure, No pay" は，第3のオプションである "Rolling Contracts" の個々の成果に適用することができます。
金銭的な部分を除けば，オプション３と４にはおそらく大きな違いはないでしょう。違いは主としてオプション３が，開始時点ではの知識は限られたものであるという前提から，顧客の反復的な付託を積極的に依頼するという部分で，従来のモデルを打ち破っている点です。
逆にオプション４は既存モデルの範囲内において，先行的要件という仮定を維持しながら作業するものです。"Change for Free" の部分が Rolling Contract と同じようなフレームワーク – 期間と予算を決定するツールとしての初期要件 – を提供しています。この初期要件は，作業が開始されてしまえば放棄しても構いません。"Money for Nothing" の方は，プレミアムを伴うという違いはあるものの，いつでも作業を停止することができるという点で Rolling Contract をシミュレートしています。
アジャイルチームの契約がいずれの方法で書かれるにせよ，考慮すべき重要な要素が２つあります。第１に，契約自体がアジャイル開発の持つ反復的特性 – 少し実行して，少し公開して，さらに少し実行する – の具現化でなければなりません。これはアジャイルで何度となく生じるテーマであり – タイムボックス化された反復，振り返り，テスト駆動開発，等々 – PDCA サイクルの実践に他ならないのです。
第２に，契約は顧客とその代表者に対して，プロジェクト全期間に渡る継続的関与を動機付けるものでなければなりません。数々の調査研究が，顧客の関与が IT プロジェクトを成功に至らせる主要因であることを指摘しています。アジャイルを実践するか否かに関わらず，顧客との継続的関係は必須のものなのです。
最後に重要なこと
IT 業界の従来の作業方法に馴染みのない顧客には，これらのオプションのいくつかが，完全に論理的なものだと感じられるかも知れません。これまで IT サプライヤとの仕事を続けてきた人たちは，いくつかのオプションに驚きを覚えることもあるでしょう。私たちの業界は，"あなたが書き上げたことを，私たちが所定のコストと期間で構築します" という神話を広め，顧客を裏切り続けてきました。
顧客の一部は間違いなく，従来型の契約モデルに固執するでしょう。一部のサプライヤがこのような顧客に付け込んで利益を得る一方で，他のものは役に立たないモデルに固執することによって損失を被ります。どちらの結果もあまり魅力的ではありません。
私の顧客の１社は，クライアントに対して常に２つのオプション – 従来型の “固定” 契約と，反復的なアジャイル開発 – を提示しています。事前にすべてを確定することが可能である，と顧客が考えるなら，従来のアプローチを選択することができます。確信が持てないようであれば，反復的なアジャイルアプローチの方を選択すればよいでしょう。
将来，このような IT 契約の新たなアプローチ方法と幅広い選択肢が用意されていることに関する顧客の理解が進めば，すべての人たちが恩恵を受ける側に回ることができるはずです。今の時点では，新たな契約モデルへの早期移行が可能な人々に対して，選択の機会が与えられています。そう，リスクはありますが – その見返りもあるのです。
著者略歴
Allan Kelly 氏はシステム管理者，テスタ，開発者，アーキテクト，プロダクトマネージャ，開発マネージャなど，ソフトウェア業界のあらゆる業務を経験してきました。現在はロンドンに居を構えていて，ソフトウェア企業がアジャイルとリーンプラクティスを導入し，より深めていくことをトレーニングやコンサルティング，コーチングの実施を通じて支援しています。
多数の雑誌論文やカンファレンスでのプレゼンテーションに加えて，氏は "Changing Software Development: Learning to become Agile (邦題：ソフトウェア開発を変革する - もっと俊敏になるために)" という著書も持っています。