アジャイル契約

アジャイル固定価格は、アジャイル手法を使用してソフトウェアを開発する IT プロジェクトのサプライヤーと顧客が合意する契約モデルです。このモデルでは、最初のテスト フェーズが導入され、その後、予算、期限、フレームワーク内での範囲の調整方法が合意されます。

これは従来の固定価格契約とは異なり、固定価格契約では通常、契約の主題の詳細かつ正確な説明が事前に必要となります。固定価格契約は、予測できない後からの変更によって生じる潜在的なリスクを最小限に抑えることを目的としています。対照的に、アジャイル固定価格契約では、詳細な説明ではなく、プロジェクト全体の大まかな説明が求められます。^[1]

アジャイル契約では、サプライヤーと顧客が協力して、ビジネス価値、実装リスク、経費 (労力)、コストに関する共通の想定を定義します。これらの想定に基づいて、両者は、まだ契約上拘束力のない、目安となる固定価格の範囲について合意します。その後、テスト フェーズ (チェックポイント フェーズ) が続き、実際の実装が開始されます。このフェーズの最後に、両当事者は、実証結果と当初の想定を比較します。その後、両者は協力して、プロジェクト全体の実装を決定し、変更が許可される条件を確立します。

アジャイル契約のさらなる側面としては、リスク共有 (両当事者が予期しない変更による追加費用を均等に分担する) や、いずれかの当事者が任意の段階で契約を終了できるオプション (終了ポイント) などがあります。

上限付きT&M契約は、従来のT&M契約と同じように機能します。ただし、顧客が支払う金額には上限があります。このように、サプライヤーは早期の時間枠変更の恩恵を受けることができ、顧客は上限コストの上限に達するまでしか支払う必要がありません。^[2]

目標コスト契約では、契約に関係する当事者は交渉中に最終価格に合意します。この契約では、契約が予算を下回る場合は両当事者のコスト削減が可能になりますが、契約が予算を上回る場合は両当事者が追加コストを負担することになります。

インクリメンタル デリバリー契約では、契約ライフサイクルの指定されたポイントで顧客が契約を確認できます。これらのポイントは契約に交渉され、顧客はプロジェクトを変更、継続、または終了できます。

• 最初のステップでは、契約内容を広範囲に網羅します。これには、最も重要なプロジェクトの目標、トピック、エピック 、法的枠組みが含まれます。^[3]
• プロジェクト全体を最もよく表すエピックの 1 つが選択され、より詳細に指定され、いくつかのユーザー ストーリーに変換されます。適切に選択されたエピックは、それぞれが異なり、さまざまな機能を含む多数のユーザー ストーリーに変換されるはずです。したがって、それらは参照ユーザー ストーリーとして使用できます。^[3]
• 次に、サプライヤーと顧客がワークショップに集まり、これらの参照ユーザー ストーリーとその他のすべてのエピックに基づいて、ストーリー ポイントを使用してプロジェクト全体の費用を定義します。実装リスクとビジネス価値の点でも仮定が立てられます。この情報から、参考固定価格フレームワークが作成されますが、これはまだ法的拘束力はなく、後のステップ (いわゆるチェックポイント フェーズの終了時) でのみ固定されます。
• 次に、チェックポイント フェーズが定義されます。これはコラボレーションのテスト フェーズであり、実装が開始され、初期の経験的洞察が得られます。このフェーズは、約 2 ～ 5 スプリント (スプリントの長さは 2 週間) 続くようにすることをお勧めします。チェックポイント フェーズの最後に、顧客とサプライヤーは最初の想定を確認し、プロジェクトの全体または一部を実現するかどうかを決定します。その後、指標となる固定価格の枠組みが正式に合意され、契約上拘束力を持つようになります。チェックポイント フェーズでは、リスク シェアも決定され、固定価格を超える追加費用が顧客に請求される範囲が定義されます。^[3]
• さらに、プロジェクトの運営を担う役割を定義し、その役割を担わせる必要があります。顧客はプロジェクト マネージャーを、サプライヤーはプロダクト オーナーを任命します。両者の合意により選ばれた独立した IT コンサルタントを関与させることが推奨されます。これらの役割が一体となって運営委員会 (スコープ ガバナンス^[3] ) を形成し、正式な意思決定パネルの権限が与えられます。この委員会は定期的に会合を開き、最優先の要件がユーザー ストーリーとして指定されるなど、継続的な仕様策定プロセスが順守されるようにします。^[3]
• 従来の固定価格プロジェクトとは対照的に、アジャイル契約によるプロジェクトは、顧客がすでに提供された機能によって期待された価値が得られたと確信している場合、早期に終了することがあります。これは、合意された機能がすべて実装される前に発生する可能性があります。この契約上の柔軟性が顧客とサプライヤーの両方に有利になるようにするには、特定の合意に達する必要があります。つまり、未提供の機能に対して残った予算の一定の割合をサプライヤーに支払うか、残った予算の範囲をサプライヤーに新たに割り当てることができます。

アジャイル固定価格は、範囲、進捗、コストを事前に決定することが難しい複雑な IT プロジェクトに最適な契約フレームワークです。過去に同じまたは同様の方法ですでに行われている標準プロジェクトの場合、テストフェーズとプロジェクト進捗の評価は省略できます。この契約モデルを成功させるには、サプライヤーと顧客がプロジェクトの全期間にわたって緊密に協力する必要があります。さらに、予算、費用、機能の範囲について合意するには、ある程度の相互信頼が不可欠です。また、プロジェクトの開始時にリストされた広範な要件 (エピック) をできるだけ早く、より小さく詳細な要件 (ユーザーストーリー) に変換することもお勧めします。そうしないと、不確実性とそれに関連するリスクの可能性が高まります。^[4]

• Andreas Opelt、Boris Gloger、Wolfgang Pfarl、Ralf Mittermayr: Agile Contracts: Scrum による成功するプロジェクトの作成と管理。第 1 版、Wiley Series in Systems Engineering and Management、2013 年。
• Michael Overly、James R. Kalyvas: 『ソフトウェア契約書の1行ずつ。ニーズに合わせてソフトウェア ライセンスと契約を理解し、変更する方法』。Aspatore Books、2004 年、ISBN  978-1-58762-369-1。
• Eckhart Hanser:アジャイル プロゼッセ。 XP の超スクラム ビス MAP。 Springer-Verlag、2010 年、ISBN 978-3-642-12313-9。 
• Debbie Madden: 「私はアジャイルですが、契約はそうではありません」 http://blog.stridenyc.com/blog/im-agile-but-my-contract-isnt-how-to-align-contracts-with-agile-software-development-teams/