アジャイル契約の進め方｜準委任・SES・成果報酬の比較と選び方

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

アジャイル開発で契約トラブルが起きる最大の原因は、「仕様が変わる開発を、仕様変更を前提としない請負契約で進めること」にあります。 結論から言えば、アジャイル開発には準委任契約が最も適しています。IPA（独立行政法人情報処理推進機構）が2020年に公開した「情報システム・モデル取引・契約書（アジャイル開発版）」も、請負ではなく準委任契約を前提として設計されています。ただし、SES契約・成果報酬型・ハイブリッド型にはそれぞれ適した場面があり、契約形態の選択を誤るとベンダーとの関係崩壊や偽装請負リスクに直結します。本記事では、各契約形態の仕組みと比較・選択基準・ベンダーマネジメントの工夫を1本に整理します。

なぜアジャイル開発に「請負契約」が合わないのか

まず問題の本質を整理します。

請負契約は「成果物の完成」を約束する契約です。 民法上、受注者（ベンダ）は約束した成果物を完成させる義務（完成義務）を負います。もし完成できなければ、原則として対価は発生しません。

一方、アジャイル開発は**「スプリントを回しながら要件を発見・変更していく開発スタイル」**です。スプリント1開始時点では、スプリント10で何を作るかはわかりません。これは構造的に矛盾します。

観点	請負契約	アジャイル開発の実態
仕様の確定タイミング	契約前にすべて確定	スプリントを重ねながら確定
変更への対応	変更は「追加費用」が発生	変更はプロセスの一部（正常）
未完成時のリスク	ベンダが完成義務を負う	未確定ゆえに完成の定義が変わりうる
検収のタイミング	最終成果物を一括検収	スプリントごとに動くものを検収

Publickeyは「IPAが公開したアジャイル開発版モデル契約書は、あらかじめ特定した成果物の完成に対して対価を支払う『請負契約』ではなく、ベンダ企業が専門家として業務を遂行すること自体に対価を支払う『準委任契約』を前提としている」と報告しています。

---

契約形態の全体像と比較表

アジャイル開発の外部委託で使われる主な契約形態は3種類です。

契約形態	民法上の分類	報酬の発生条件	アジャイルとの相性
請負契約	民法632条	成果物の完成	❌ 低い
準委任契約	民法643条・656条	業務の処理・遂行	✅ 高い
SES契約	準委任契約の一形態	エンジニアの稼働時間	✅ 場合による

さらに実務では以下のバリエーションが使われます：

• タイムアンドマテリアル（T&M）：稼働時間×単価で費用が確定する準委任的な形態
• フィクスドプライス（FP）：スプリント単位に固定額を設定する変形請負
• ハイブリッド（段階型）：上流は準委任、下流（実装期）は請負に切り替え

---

準委任契約：アジャイルに最も向く理由

仕組み

準委任契約は「委任者（ユーザ）から一定の業務処理を依頼され、受任者（ベンダ）がその業務を誠実に処理する」契約です。成果物の完成は義務ではなく、業務処理のプロセス自体に対価が発生します。

ITトレンドは「準委任契約では、受任者は業務遂行に対して責任を負い、成果物の完成に対しては責任を負わない」と定義しています。

なぜアジャイルに向くのか

1. 仕様変更が「追加費用」にならない — スプリントで要件が変わっても、稼働時間分の費用は変わらない
2. スプリントごとの中間成果を検収できる — 動く成果物を都度確認しながら進められる
3. 不完全な状態でのリリースが可能 — MVPで出して改善するアプローチに合う
4. 協働関係を築きやすい — ベンダを「完成させる義務を持つ外注」でなく「一緒に作るパートナー」として関われる

SunAsteriskは「準委任契約の場合、ベンダ企業は成果物の完成責任を負わない分、仕様変更・技術的な試行錯誤・スプリントの振れ幅に柔軟に対応できる」としています。

注意点

準委任契約は「ベンダが手抜きをしても問題ない」という意味ではありません。 受任者（ベンダ）は善管注意義務（善良な管理者の注意義務）を負います。スプリント目標の未達、明らかな品質低下、議事録・レポートの未作成などは義務違反になりえます。

---

SES契約：エンジニアの技術提供

SES（System Engineering Service）とは

SES契約は準委任契約の一形態で、「エンジニアの技術・スキルを一定期間提供する」契約です。

テンプスタッフは「SES契約では、エンジニアが行った作業時間に応じて報酬が発生し、成果物の納品を前提とするのではなく、エンジニアが持つスキルや労働時間そのものを提供するサービス形態」と説明しています。

SESが向く場面

• スキルを持つエンジニアをチームに一定期間参加させたい
• 社内にノウハウがなく、外部専門家の常駐支援が必要
• スプリントチームの人数補強に特定スキルの人材が必要

SESと労働者派遣の違い

観点	SES契約（準委任）	労働者派遣
指揮命令権	ベンダ企業（SES会社）が持つ	ユーザ企業（発注側）が持つ
業務指示	ベンダ企業の管理者経由	ユーザ企業が直接指示
法的根拠	民法（準委任）	労働者派遣法

---

成果報酬型・ハイブリッド型の選択肢

タイムアンドマテリアル（T&M）

稼働時間（Time）×単価（Material）で費用が確定する準委任的な契約形態です。米国のアジャイル開発では一般的です。

• メリット：スプリントの作業量に比例してコストが発生するため、透明性が高い
• デメリット：予算の上限が見えにくく、コスト管理が難しい
• 向く場面：要件が流動的で、総量予測が困難なプロダクト開発

マイルストーン型（フィクスドプライス×スプリント）

スプリント単位に固定金額を設定し、スプリントゴール達成を検収条件とする形態です。

• メリット：予算を一定程度コントロールできる
• デメリット：スプリントゴールが達成できなかった場合の扱いが複雑
• 向く場面：予算管理が厳しい大手企業のアジャイルプロジェクト

ハイブリッド（段階型）

アジャイル開発の初期フェーズを準委任、要件が固まった後半を請負に切り替える方式です。

フェーズ1（探索・設計）: 準委任契約 ─→ スプリントで要件を確定
フェーズ2（実装・テスト）: 請負契約 ─→ 確定仕様で完成義務

Workship ENTERPRISEは「ハイブリッド型は、プロジェクトの前半で柔軟性を確保しながら、仕様確定後は予算・品質の確定性も担保できる」としています。

---

IPA公式「モデル取引・契約書（アジャイル開発版）」の要点

2020年にIPAが公開した情報システム・モデル取引・契約書（アジャイル開発版）は、日本のアジャイル開発契約の実務的な標準として広く参照されています。

重要な設計方針

1. 基本合意書＋個別作業指示書（スプリントごとに発行）の2階層構造

   • 基本合意書：プロジェクト全体のルール（スプリント期間・報告義務・ガバナンス）を規定
   • 個別作業指示書：スプリントごとの作業内容・スプリントゴールを記載

2. 準委任契約を前提とした報酬設計

   • 月次・スプリント単位での稼働費用（時間×単価）を基本とする
   • 成果物の完成ではなく「業務処理」に対価が発生することを明記

3. ユーザとベンダの共同義務の明記

   • ユーザ側：プロダクトオーナーの指名・バックログの優先度決定・スプリントレビューへの参加
   • ベンダ側：スプリント計画・デイリースクラム・レトロスペクティブの実施・議事録作成

---

ベンダーマネジメントの5つの工夫

契約形態を選んだ後、実際のプロジェクト運営でベンダとの関係をうまく回すための工夫をまとめます。

① 完了の定義（DoD）を事前に合意する

「動けばOK」では検収の合否が曖昧になります。スプリントの完了条件（DoD）を契約書または別紙に明記し、スプリントレビューで評価する基準を双方で持ちます。

例：「①コードレビュー完了 ②ユニットテスト合格 ③ステージング環境で受入確認 ④バグ件数P1=0件 ⑤ドキュメント更新完了」

② スプリントレビューをガバナンスの場にする

スプリントレビューはユーザ企業のPO・PM・ステークホルダーが動くプロダクトを確認し、バックログを調整する場です。単なるデモ報告会にせず、次スプリントの優先度を決める意思決定の場として設計してください。

③ 指揮命令のルートを明確にする（偽装請負防止）

SES契約を使う場合は特に重要です。「ユーザ企業→SES会社の管理者→エンジニア」の指揮ルートを守り、デイリースクラムでの直接指示が偽装請負にならないよう、スクラムイベントへの参加形態を契約書に明記します。

④ 変更管理プロセスをスプリントに組み込む

バックログへの追加・削除・優先度変更は「ユーザPOが決め、ベンダPMが次スプリントに反映する」フローを確立します。口頭の変更指示は原則禁止とし、バックログ管理ツール（Jira・Backlog等）でトレーサビリティを確保します。詳しくは変更管理プロセスの設計を参照してください。

⑤ コスト見える化の仕組みを作る

準委任・T&M型では「気づいたらコストオーバー」になるリスクがあります。スプリントごとに「予算消化率」と「バックログ残量（ストーリーポイント）」の両方をトラッキングし、ベロシティから残スプリント数を推計してコスト着地を予測します。

---

---

よくある失敗5選

失敗① 「とりあえず請負契約」でスタートする

「法務に聞いたら請負でいいと言われた」「過去プロジェクトと同じ契約書を使い回した」というケースで、仕様変更のたびにベンダと追加費用の交渉が発生し、スプリントが止まります。

対策： アジャイルと決めた段階で、法務・ベンダと「準委任でいく」合意をプロジェクト開始前に取る。

失敗② SES常駐エンジニアに直接指示を出す

スクラムマスター・POがSESエンジニアのタスクを直接割り当て・指示する運用が慣例化し、偽装請負状態になります。

対策： SES会社との契約書に「業務指示はSES社の管理者経由」を明記し、スプリントイベントへの参加形態（オブザーバーか共同開発者か）を契約時に合意する。

失敗③ DoDなしにスプリントを完了扱いにする

「動いているのに検収が通らない」「スプリントレビューで毎回揉める」の原因の多くはDoDの不在です。

対策： プロジェクト開始前にDoDを文書化し、契約書（または別紙）に添付する。スプリント1でDoDを試運転し、レトロスペクティブで修正する。

失敗④ ベンダ任せでバックログを管理しない

「バックログはベンダが管理しているのでよくわからない」状態では、優先度の意思決定ができず、スプリント目標が形骸化します。

対策： ユーザ企業のPOがバックログを所有する原則を契約書に明記。バックログへのアクセス権限をユーザ企業が持つ。

失敗⑤ コスト超過に気づくのが遅い

月末に請求書が来て初めてコストオーバーを知る、というパターンです。

対策： スプリントごとに消化コストを確認する仕組みを作る。T&M型なら「月次予算消化レポート」をベンダの義務として契約書に明記する。

---

FAQ

Q. 準委任契約でも「成果物」の品質保証はできますか？

A. 準委任契約では成果物の完成義務はありませんが、善管注意義務（民法644条）があります。契約書にDoDや品質基準を明記することで、「一定の品質を満たした業務処理」を義務づけることは可能です。成果物の完全性保証が必要なら、「フェーズ2は請負に切り替えるハイブリッド型」を検討してください。

Q. SES契約と労働者派遣の見分け方は？

A. 最大の判断基準は指揮命令権の所在です。「誰がエンジニアにどのタスクをこなすよう指示するか」をチェックしてください。ユーザ企業の担当者が直接タスク指示・業務命令を出しているなら労働者派遣として規制されます（偽装請負）。スクラムのデイリースクラムでユーザPMがタスクを割り当てる場合は特に注意が必要です。

Q. 請負契約でアジャイルをうまく進める方法はないですか？

A. スプリント単位に固定額を設定する「フィクスドプライス×スプリント方式」は、一定の仕様変更コストをスプリントバッファに含めることで機能することがあります。ただし、スプリントゴールが未達だった場合の対価の扱い（全額・一部・なし）を事前に明確にしないと紛争になります。多くの実務家はこのリスクから準委任を選びます。

Q. 外資ベンダ・海外オフショアと契約する場合は？

A. 準委任・請負の区分は日本の民法概念です。海外ベンダとはT&M（タイムアンドマテリアル）またはフィクスドプライスが一般的です。T&Mは実稼働時間×単価で費用が決まり、日本の準委任に近い性格を持ちます。米国PMIの調達マネジメント（PMBOK® 第7版）でも、アジャイルプロジェクトにはT&M契約を推奨しています。

Q. IPA モデル契約書はそのまま使えますか？

A. たたき台としては非常に優れています。ただし「自社の知的財産権の帰属」「ソースコードのエスクロウ」「偽装請負を防ぐ具体的な指揮命令ルート」などは自社状況に合わせて加筆が必要です。外部委託金額が大きい案件では弁護士（IT法務経験者）のレビューを経ることを強く推奨します。

---

まとめ：アジャイル契約の選び方フロー

状況	推奨契約形態
要件が流動的・MVP開発	準委任契約（T&M）
特定スキルのエンジニアを常駐させたい	SES契約（偽装請負対策を徹底）
探索フェーズ後に仕様確定	ハイブリッド（準委任→請負）
予算の上限を厳格に管理したい	フィクスドプライス×スプリント
海外ベンダとのアジャイル開発	T&M契約

アジャイル開発を外部委託する際の鉄則は「契約形態とアジャイルの価値観を一致させる」ことです。IPAモデル契約書の準委任ベースの設計を参考に、ベンダとの協働関係を最初から設計に組み込んでください。

本記事で扱ったアジャイルの進め方については、スクラムの5つのイベント完全解説・スプリントバックログとプロダクトバックログ・アジャイルとウォーターフォールの使い分けも合わせてご覧ください。ベンダ選定時の契約交渉に必要なスコープ管理についてはスコープ定義書（SOW）の書き方・変更管理プロセスの設計も参照してください。