アジャイル契約

情報技術プロジェクトの契約モデル

アジャイル固定価格は、アジャイル手法を用いてソフトウェアを開発する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年。
  • マイケル・オーバリー、ジェームズ・R・カリヴァス著:ソフトウェア契約の明細。ニーズに合わせてソフトウェアライセンスと契約を理解し、変更する方法。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/

参考文献

  1. ^ Andreas Opelt他著:アジャイル契約:スクラムによる成功するプロジェクトの作成と管理。Wileyシリーズ、システムエンジニアリングとマネジメント。45-46
  2. ^ ヴィラノバ大学:アジャイル契約管理。アジャイル契約管理
  3. ^ abcde Andreas Opelt他:「アジャイル契約:スクラムによる成功するプロジェクトの作成と管理」Wileyシリーズ、システムエンジニアリングとマネジメント、47-72
  4. ^ Michael Overly、James R. Kalyvas著「ソフトウェア契約の1行1行。ニーズに合わせてソフトウェアライセンスと契約を理解し、変更する方法」Aspatore Books、278~279ページ。
「https://en.wikipedia.org/w/index.php?title=Agile_contracts&oldid=1233895324」より取得