LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・運用を受託

アジャイル外注の全体像 — 準委任契約が前提となる理由

アジャイル開発を外注するとは、スプリント（反復開発サイクル）を軸としたソフトウェア開発業務を、専門ベンダーに準委任契約で委ねる取り組みです。IPA（独立行政法人情報処理推進機構）が2020年3月に公表した「情報システム・モデル取引・契約書（アジャイル開発版）」では、「ベンダー企業が専門家として業務を遂行すること自体に対価を支払う準委任契約を前提としている」と明記されています。

ウォーターフォール外注との根本的な違い

ウォーターフォール外注では、要件定義から設計・開発・テストまでを一括して請負契約で発注します。成果物（動くシステム）の完成を条件に報酬を支払う構造です。仕様が事前に確定していることが前提のため、途中変更は契約改定を要します。

アジャイル外注では、同じ「開発外注」でも進め方が根本的に異なります。スプリント（通常2週間〜4週間の短期開発サイクル）を繰り返しながら機能を積み上げていくため、仕様は段階的に確定します。この「仕様の不確実性」があるため、成果物完成を前提とする請負ではなく、「業務遂行そのものへの対価」を支払う準委任が適合するのです。

IPAモデル契約書（アジャイル開発版）が示す準委任前提の考え方

IPA（独立行政法人情報処理推進機構）は2020年3月31日、「情報システム・モデル取引・契約書（アジャイル開発版）」を公表しました（2025年4月8日更新）。同資料では、アジャイル開発の外注に際して準委任契約を前提とする根拠を整理しています。

同資料が示す体制の標準形は、発注側が選任するプロダクトオーナー（PO）と、ベンダー側が選任するスクラムマスター（SM）、そして開発チームの3層です。発注側のPOがプロダクトバックログ（機能要求の優先順位リスト）を管理し、スプリントごとに開発する機能を決定します。この構造では発注側の関与が請負より深く、「丸投げ」での外注が難しい点が特徴です。

アジャイル外注で締結する準委任契約の3つの構造

アジャイル開発版モデル契約書をもとにすると、準委任契約は「基本契約＋個別契約のスプリント単位発注」「タイムアンドマテリアル型報酬」「成果物の検収基準の明確化」という3つの構造で組み立てます。

基本契約と個別契約（スプリント単位の発注）

アジャイル外注では通常、プロジェクト全体の取り決めを定める基本契約と、スプリントごとの作業範囲・期間・費用を定める個別契約の二層構造を採用します。基本契約には、準委任関係の前提となる善管注意義務^*1・機密保持・知的財産権の帰属・秘密保持・終了事由などを定めます。

個別契約はスプリントの開始前に締結し、そのスプリントで対応するバックログアイテム（機能要求）・チーム規模・単価・期間を記載します。スプリントが終わるたびに次のスプリント分の個別契約を結ぶ運用により、発注側は進捗を確認しながら開発優先度を調整できます。

タイムアンドマテリアル型報酬と月次払い

準委任では、「仕事の完成」ではなく「業務遂行そのもの」に対価が発生します。アジャイル外注でよく採用されるのは、エンジニアの稼働時間（タイム）と使用する資材・ツール費（マテリアル）に応じて費用を精算するタイムアンドマテリアル方式です。

報酬の支払いは月次払いが一般的で、スプリント期間が1か月を超える場合はスプリント終了時払いにする場合もあります。民法第648条（受任者の報酬）が定める「履行割合型報酬」の枠組みが適用され^*1、業務の進捗に応じて対価が発生する仕組みです。

成果物の定義と検収のポイント

準委任では請負のような「完成物に対する契約不適合責任」^*2は原則として適用されません。一方で、スプリントレビューで動作確認した機能については「その機能が動作すること」を検収基準として個別契約に明記することが実務上重要です。

IPA第二版モデル契約書（情報システム・モデル取引・契約書（第二版）、2020年12月公開）でも、準委任における成果報酬型（民法第648条の2）と履行割合型の使い分けを整理しています。アジャイル外注では、スプリント完了時に「デモ可能な動作状態のソフトウェア」を成果基準として設定することで、完全な準委任型でありながら検収基準を明確にできます。

発注側に必要な体制 — プロダクトオーナーを立てる

アジャイル外注で最も見落とされがちな要件が、発注側の体制です。ウォーターフォール型の請負では「要件書を渡して完成を待つ」スタイルが一般的ですが、アジャイルでは発注側が開発の意思決定に継続的に関与しなければなりません。

プロダクトオーナーの役割と必要スキル

プロダクトオーナー（PO）は、開発するプロダクト（ソフトウェア）の価値を高めるためにバックログを管理する役割です。具体的には、以下の業務を担います。

• プロダクトバックログ（機能要求リスト）の作成・優先順位付け
• スプリントプランニングでの作業範囲の確定
• スプリントレビューでの完成基準（DoD：Definition of Done）の判定
• ステークホルダーへの進捗説明・優先度調整

POには「ビジネス要件を開発チームが理解できる粒度に分解する能力」と「開発優先度を素早く判断できる権限」の両方が必要です。社内のプロジェクトマネジャーや事業担当者が担うケースが一般的ですが、いずれの場合もスプリントプランニング（週1〜2時間程度）への参加が不可欠です。

スクラムマスター・開発チームとの責任分担

IPAアジャイル開発版モデル契約書では、スクラムマスター（SM）はベンダー側が選任するとされています。SMはスクラムプロセスの進行管理・障害除去・チームのパフォーマンス改善を担い、発注側POへの進捗報告窓口にもなります。

開発チームは1チーム10名程度を上限として構成されます（IPAモデル契約書記載）。発注側はSMを通じて間接的に開発チームに要求を伝える形をとり、直接の作業指示は行いません。直接指示は偽装請負リスクを生じさせる可能性があるため、コミュニケーションはPO⇔SMの経路に集約することが重要です。

社内ステークホルダーとの合意形成

アジャイル外注では仕様が段階的に確定するため、社内の関係部門（営業・経理・法務等）との事前合意が特に大切になります。「最初の仕様書と最終成果物が変わる可能性がある」ことを予算承認段階で説明し、変更が生じた場合の意思決定フロー（誰がバックログ優先度を変更できるか）を文書化しておきましょう。

特に費用の変動については、スプリント単位で稼働実績を共有する仕組みを契約前に取り決めることで、社内稟議や予算管理との整合がとりやすくなります。

アジャイル外注の進め方 — 契約締結からスプリント安定稼働まで

アジャイル外注の実務は、「RFP・ベンダー選定」「契約締結・バックログ初期化」「スプリント運営」「リリース・契約更新」の4つのステップで進みます。各ステップで押さえるべき要点を整理します。

ステップ1：RFP・ベンダー選定 — アジャイル実績と体制明示を軸に

アジャイル外注のRFP（提案依頼書）には、通常の開発発注と異なるポイントが2つあります。第1に、「完成品の仕様」ではなく「達成したいビジネス目標とMVP（実用最小限のプロダクト）の定義」を提示することです。第2に、ベンダーに求める体制として「スクラムマスターの選任経験」「アジャイル開発の継続実績（スプリント回数・プロジェクト件数）」を明示することです。

ベンダー評価では、技術スタックの一致だけでなく「プロダクトオーナーとの協働経験」を確認するとよいでしょう。POとSMが初めて協働する場合、最初の1〜2スプリントはコミュニケーション習熟期間として工数の余裕を見込んでおくことが実務上の鉄則です。

ステップ2：契約締結・バックログ初期化

契約締結時には基本契約と、第1スプリント分の個別契約を同時に締結します。このタイミングで合わせて実施すべき作業がバックログ初期化（インセプションデッキ）です。

インセプションデッキとは、プロジェクトの目的・優先事項・懸念事項を一枚紙にまとめたドキュメントで、アジャイル外注でPO・SM・開発チームが共通認識を持つために用います。「何を作らないか」「予算・期間の優先度」「技術的な前提条件」などを明記することで、スプリント中の手戻りを減らせます。

ステップ3：スプリント運営とレビュー・振り返り

1スプリントは通常2週間です。各スプリントは「プランニング→デイリースクラム→レビュー→レトロスペクティブ（振り返り）」の4つのイベントで構成されます。発注側POが参加必須なのは、プランニングとレビューの2イベントです。

スプリントレビューでは、ベンダーがその期間に開発した機能を実際に動かしてデモを行い、POが受け入れ基準（DoD）を満たしているかを判定します。ここで「受け入れ不可」となった機能はバックログに戻り、次スプリント以降に再開発されます。この判定を毎スプリント繰り返すことが、最終成果物の品質を積み上げていく仕組みです。

レトロスペクティブはチーム内の改善会議で、通常はベンダー内で行われます。ただし、発注側からの要望（コミュニケーション改善・ドキュメント追加等）をSM経由でレトロスペクティブのインプットとして提供することは実務上よく行われます。

ステップ4：リリース判断と契約延長・終了

スプリントを重ねてMVPが完成したタイミングで、正式なリリース判断を行います。継続開発が必要な場合は個別契約を更新し、次フェーズのバックログを整備します。プロジェクトを終了する場合は基本契約に定めた終了手続き（引き継ぎドキュメント・ソースコードのリポジトリ移管等）を経て完了します。

アジャイル外注では「いつプロジェクトが終わるか」が請負ほど明確ではないため、四半期ごとの予算・継続可否レビューをスケジュールに組み込んでおくと、社内のガバナンスが保ちやすくなります。

費用の考え方 — 請負型と何が違うか

アジャイル外注の費用構造は、請負型の「一括固定費用」とは異なります。準委任型の費用発生原理を理解しておくことが、予算管理上のトラブルを防ぐ第一歩です。

準委任型の費用発生構造（人月単価×期間）

アジャイル外注では、エンジニアの人月単価に稼働期間（月数）を掛けた金額が基本コストになります。具体的な費用レンジについては、エンジニアのスキルレベル・地域・ベンダーの規模・開発領域によって大きく異なるため、本記事では一次資料に基づく確定値を掲載せず、相見積もりで確認することをお勧めします（市場参考値であり一次資料ではありません）。

チーム構成の目安として、IPAアジャイル開発版モデル契約書では「1チーム10名程度を上限」とされています。フロントエンド・バックエンド・QA・インフラ等の役割構成は案件によって異なり、必要な専門知識の領域も複数にわたります。内製でこれらの役割をそろえようとする場合、採用・育成コストと期間が相当規模になる点は考慮が必要です。

スプリント変動費の把握方法

スプリントごとに取り組むバックログアイテムの量が変わると、必要な工数も変動します。工数変動が費用変動につながる準委任型では、各スプリント終了時に「計画工数vs実績工数」の報告をSMから受け取る仕組みを取り決めておくことが重要です。

ツール費用（クラウドインフラ・SaaS・ライセンス等）が別途発生する場合は、タイムアンドマテリアル契約のマテリアル部分として個別契約に明記します。ツール費が実費精算か固定費かによって月次の費用予測精度が変わるため、初回の個別契約締結時に確認しておきましょう。

費用肥大を防ぐバックログ管理

アジャイル外注で費用が膨らむ主因は、バックログが際限なく追加されることです。POが「ついでにこれも」とバックログに機能を積み上げ続けると、スプリント数が増え費用が拡大します。

対策は「バックログの総量キャップ（上限管理）」と「優先度の定期的な棚卸し」です。四半期ごとにバックログを見直し、ビジネス価値が低下した機能要求は削除または延期します。この「バックログの削減意思決定」をPOが積極的に行えるかどうかが、アジャイル外注のコスト管理の要となります。

発注側が陥りやすい3つのリスクと対策

アジャイル外注で発生しやすいトラブルを、発注側の視点から整理します。リスクのほとんどは「発注前の取り決め」で対策できます。

リスク1：要件が固まらないまま外注開始 — バックログ0件のスプリント

「アジャイルだから要件はあとから決めればいい」という誤解が、最初のリスクです。アジャイルは「変更を受け入れる」開発手法ですが、「何も決めなくてよい」ではありません。スプリント開始時点でバックログに一切のアイテムがない状態では、開発チームは動けず、人月費用だけが発生します。

対策は、契約締結前にインセプションデッキを作成し、最低でも「第1スプリントで着手できるユーザーストーリー（機能要求）を5〜10件程度」バックログに積んでおくことです。バックログの量・質がスプリントの稼働効率を直接左右します。

リスク2：検収基準が曖昧なまま準委任継続 — DoD未定義

準委任には完成責任がないため、「どこまでできたら受け入れるか」をあらかじめ定めておかないと、スプリントレビューで毎回議論が発生します。この状態が続くと、完了判定ができないまま次スプリントへ持ち越しが続き、費用対効果の判断が困難になります。

対策は、個別契約または別紙でDoD（Definition of Done：完了の定義）を明文化することです。「ユニットテスト通過」「レビュー環境で動作確認済み」「指定のコーディング規約準拠」など、具体的な検収基準を列挙します。DoDは開発が進むにつれて改訂することも想定し、変更時はPOとSMが合意して文書化するルールも設けておきましょう。

リスク3：プロダクトオーナー不在による開発漂流

アジャイル外注で最も深刻なリスクが、POが機能しないケースです。担当者の業務過多・権限不足・スクラムへの理解不足が重なると、スプリントプランニングで優先度が決まらず、開発チームが「何を作ればよいかわからない」状態に陥ります。結果として人月費用を費消しながら成果が出ない「開発漂流」に至ります。

対策は、PO役割の要件定義を採用・アサイン前に行うことです。「週○時間の開発関与」「バックログ優先度の決定権限」「ステークホルダーへの説明責任」の3点を明確にし、業務量として現実的かを事前に確認します。社内でPOを担える人材がいない場合は、外部のアジャイルコーチやPO支援サービスを活用するか、ベンダー側のSMが暫定的にPOを兼ねる形（ただし利益相反に注意）を検討します。

内製でPO機能を持たずにアジャイル外注に踏み切る場合、スプリントレビューへの参加・バックログ管理・ステークホルダー合意という3つの業務を誰かが担う必要があります。これらをアウトソースするかどうかの検討も含め、外注開始前に体制を確定させることが外注成功の前提条件です。

まとめ — アジャイル外注を成功させる3つの判断軸

本稿では、アジャイル開発を外注する際の準委任契約の構造・発注側体制・スプリント運営・費用管理・リスク対策を整理しました。要点を3点に集約します。

第一に、アジャイル外注は準委任契約が前提であること。IPA「情報システム・モデル取引・契約書（アジャイル開発版）」が示す通り、請負型の「成果物完成払い」ではなく、「業務遂行への対価」構造を理解した上で契約設計を行う必要があります。

第二に、発注側のプロダクトオーナー体制が外注品質を左右すること。スプリントごとのバックログ優先度決定・レビュー判定・ステークホルダー調整をPOが担えない場合、費用だけが発生して成果が出ない開発漂流に陥るリスクがあります。

第三に、バックログ管理が費用コントロールの鍵であること。準委任型では要件追加が即費用増につながります。四半期ごとのバックログ棚卸しと優先度の見直しを発注側が主体的に行うことで、スコープと予算の整合を保てます。

よくある質問

アジャイル外注は準委任契約でないといけませんか？

法律上は請負契約でアジャイル開発を外注することも可能ですが、実務的には困難を伴います。アジャイルは仕様を段階的に確定させる手法のため、「成果物の完成」を前提とする請負では途中変更のたびに契約改定が必要になります。IPA「情報システム・モデル取引・契約書（アジャイル開発版）」も準委任契約を前提として設計されており、アジャイル外注の標準的な契約形態は準委任です。

アジャイル外注でプロダクトオーナーを社外に委託することはできますか？

可能ですが、注意が必要です。PO役割をベンダー側SMが兼ねる場合、発注側の意図が反映されにくくなる利益相反リスクがあります。外部コンサルタントやアジャイルコーチにPO支援を依頼する場合は、社内の意思決定者と密に連携できる体制を確保することが大切です。社内でPO候補を育てながら、当初は外部支援を並走させる移行型がリスクを抑えた方法です。

アジャイル外注とウォーターフォール外注を同じプロジェクトで混在させることはできますか？

可能です。実務では「要件定義・基本設計フェーズは準委任」「大規模な基幹連携開発フェーズは請負」というように工程ごとに契約形態を使い分けるケースがあります。IPA「情報システム・モデル取引・契約書（第二版）」でも工程別の契約選択について言及しています。ただし契約形態の切り替えタイミングでは引き継ぎドキュメントと成果物の確認を丁寧に行うことが重要です。

スプリント期間の途中でベンダーを変更することはできますか？

契約上は個別契約の終了をもってベンダー変更が可能ですが、現実的には容易ではありません。アジャイル外注では開発チームが蓄積したコードベースへの理解・バックログの文脈・チーム内の暗黙知が引き継ぎにくいためです。変更を検討する場合は、少なくとも1〜2スプリントの移行期間を設け、元のベンダーから新ベンダーへのドキュメント・リポジトリ・バックログの移管を契約に明記しておくことをお勧めします。

アジャイル外注でウォーターフォールより費用が高くなることはありますか？

仕様変更が多い場合は、アジャイル外注の方がトータル費用が低くなる傾向があります。ウォーターフォールでは途中の仕様変更が手戻り工数として大きな費用増になりますが、アジャイルではバックログの入れ替えで対応できるためです。一方で、スコープ管理が甘くバックログが際限なく増え続ける場合は費用が肥大するリスクがあります。費用の比較は「最終的に実現した機能量に対する総額」で評価することが実態に近い方法です。

著者：テレリモ総研編集部　鈴木 亮佑

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IPA（独立行政法人情報処理推進機構）「情報システム・モデル取引・契約書（アジャイル開発版）」（2020年3月31日公開、2025年4月8日更新）
2. *2　出典：IPA（独立行政法人情報処理推進機構）「情報システム・モデル取引・契約書（第二版）」（2020年12月22日公開）