アジャイル開発の外注は準委任で組む【2026年版】契約・体制・スプリント運用と失敗する5つの理由

「アジャイルで進めたいのに、見積もりを頼むと仕様を全部決めてくれと言われる」——アジャイル開発の外注を検討している方から、こうした相談をよく受けます。要件は使いながら決めたい。けれど請負の見積もりには確定した仕様が要る。社内の法務は請負契約のひな型しか持っていない。この噛み合わなさの前で止まってしまう方が、とても多いのが実情です。

結論から言うと、アジャイル開発の外注は請負ではなく準委任契約(ラボ型を含む)で組みます。そのうえで、プロダクトオーナーは発注者側が担い、スクラムマスターは開発会社側が担う。この2つを契約前に決められるかどうかで、成否がほぼ決まります。独立行政法人情報処理推進機構(IPA)が公開している「情報システム・モデル取引・契約書(アジャイル開発版)」も、準委任を前提とし、ユーザー企業がプロダクトオーナーを選任することを定めています。

契約と体制さえ設計できれば、外注でもスプリントは回ります。時差2時間のベトナムでも、日本の午前中に投げた質問はその日のうちに返ってきますし、デモも振り返りも成立します。逆に、受入基準を書かないまま着手し、報告を週次のメールだけにした案件は、距離に関係なく3か月目に破綻します。

本記事では、請負が噛み合わない理由と契約形態の選び方、外注でスクラムを回す体制と役割分担、スプリントの回し方と完了の定義、失敗する5つの理由と対策、オフショアで回す実務と当社の体制、よくある質問の順に解説します。契約比較・役割分担・スプリントの時間割は、そのまま社内の説明資料に転記できる表にしました。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。アジャイルの外注でうまくいかなかった案件の原因は、ほぼ2つに集約されます。この記事を読み終えるころには、自社でアジャイルを外注できるか、何を先に決めるべきかが判断できるはずです。

アジャイル開発の外注が請負と噛み合わない理由——準委任が前提になる構造とIPAのモデル契約

アジャイル開発を外注しようとして最初にぶつかるのが、契約の壁です。開発会社に見積もりを頼むと「仕様を確定してください」と言われ、社内の法務に相談すると「請負契約のひな型しかない」と返ってくる。この行き詰まりは担当者の準備不足ではなく、請負という契約の構造とアジャイルの前提が噛み合っていないことから起きています。まず、なぜ噛み合わないのかを整理します。

請負が合わない3つの理由——「完成」が動く、仕様固定が前提、変更のたびに契約変更

請負契約は「仕事の完成」に対して報酬を支払う契約です。受注側は完成責任を負い、引き渡した成果物が契約の内容に適合しなければ契約不適合責任を負います。この仕組みがアジャイル開発と衝突する点は3つあります。

1つ目は、「完成」の定義が反復のなかで動くことです。アジャイル開発は毎スプリントで動くソフトウェアを積み上げ、使ってみた結果から次に作るものを決め直します。最初に定義した完成形が3か月後には変わっているのが正常な状態であり、契約時点の「完成」を基準に責任を問う請負とは相性が悪いということになります。

2つ目は、仕様を先に確定させる前提です。請負で見積もるには、作るものの範囲が確定していなければなりません。要件が固まっていないから反復で確かめたい、という動機でアジャイルを選んだ案件では、この前提がそもそも成り立ちません。

3つ目は、変更のたびに契約変更が要ることです。優先順位を入れ替えるたびに変更見積もりと合意の手続きが発生し、アジャイルの速さが契約事務に食われます。「今週の振り返りで決めたことを来週から試す」という動き方は、この手続きの下では成立しません。

誤解のないように書いておくと、請負が悪い契約だという話ではありません。仕様が確定した機能を切り出して発注するなら、請負のほうが発注側の負担は軽く、費用も固定できます。契約形態は案件の性質で決まるものであって、優劣ではないというのが私の考えです。

契約形態の比較表(請負/準委任・スプリント単位/ラボ型/多段階)

アジャイル開発の外注で実際に使われる契約形態は、次の4つに整理できます。呼び方は会社によって違いますが、責任の持ち方と支払いの考え方で分けると、どの会社の提案もこの4分類のどれかに収まります。

実務でいちばん多いのは、準委任を基本契約にして、継続が見えた段階でラボ型に寄せていく形です。そして、管理画面のCRUDのように仕様が固まった部分だけを請負で切り出す。この組み合わせが現実的な落としどころになります。

IPA「情報システム・モデル取引・契約書(アジャイル開発版)」——準委任が前提、スクラムを採用

法務部門を説得する材料として使えるのが、独立行政法人情報処理推進機構(IPA)が公開している「情報システム・モデル取引・契約書(アジャイル開発版)」です。2020年3月31日に公開され、解説付き資料は2025年4月8日に更新されています。

この版の特徴は3つあります。第1に、「あらかじめ特定した成果物の完成に対して対価を支払う請負契約ではなく、ベンダ企業が専門家として業務を遂行すること自体に対価を支払う準委任契約を前提としている」と明記されている点。第2に、開発手法としてスクラムを採用し、プロダクトオーナーはユーザー企業が選任すると定めている点。第3に、契約前チェックリスト(9分野)と「アジャイル開発進め方の指針」が補足資料として付いている点です。

契約書のひな型はWord形式、契約前チェックリストはExcel形式で配布されており、カスタマイズして使えます。社内の法務が準委任に慣れていない場合、「公的機関が用意したひな型がある」という事実だけで話が前に進むことがよくあります。なお、IPA自身も「そのまま使うのではなく、プロジェクトごとにカスタマイズする前提」としているため、条文の具体的な検討はIT分野に詳しい弁護士に相談してください。

基本契約+スプリント単位の個別契約で、予算の上限を管理する

準委任で発注側が最も不安に感じるのは「完成責任がないなら、いつまで費用が出続けるのか」という点です。ここは契約の構造で管理できます。

一般的なのは、プロジェクト全体の取り決め(善管注意義務、秘密保持、知的財産権の帰属、終了事由など)を定める基本契約と、スプリントごとの作業範囲・期間・チーム規模・費用を定める個別契約の二層構造です。スプリントが終わるたびに次の個別契約を結ぶ運用にすれば、発注側は成果を見ながら継続か終了かを判断できます。予算の上限は「総額をいくらにするか」ではなく「何スプリント分を発注するか」で管理する、と考えると社内稟議の説明もしやすくなります。

知的財産権の帰属は必ず契約書に書いてください。準委任では、特に定めがなければソースコードの著作権が受注側に残る可能性があります。ここは請負と違って自動的には発注側に来ません。契約の形が決まったら、次は体制です。誰がプロダクトオーナーを務めるかが、次の関門になります。

外注でスクラムを回す体制——プロダクトオーナーは発注者側、スクラムマスターは開発会社側

契約の形が決まったら、次に決めるのは誰が何を担うかです。アジャイル開発の外注では、役割の置き場所が固定されています。プロダクトオーナー(PO)は発注者側、スクラムマスターは開発会社側。IPAのモデル契約もこの分担を前提にしています。ここを曖昧にしたまま着手すると、優先順位が決まらないまま稼働だけが進む状態になります。

役割分担の表(PO・スクラムマスター・開発チーム・ステークホルダー)

スクラムを外注で回すときの役割は、次のように整理できます。

IPAのモデル契約では、開発チームは1チーム最大10名程度を上限として想定しています。この規模を超える場合は、チームを分けるか、対象範囲を絞るかの判断が要ります。当社が最小構成を「日本人PMフロント+2〜3人月」としているのも、1チームで回る規模から始めたほうが立ち上がりが速いためです。

バックログの優先順位は誰が決めるのか——決められないときに起きること

外注でいちばん揉めるのが、この問いです。答えははっきりしていて、バックログの優先順位を決めるのはPO、つまり発注者側です。開発会社は「どう作るか」と「どのくらいかかるか」は答えられますが、「何をなぜ先に作るか」は事業判断なので答えられません。

決められないときに何が起きるか。開発チームは着手できるものから着手します。結果として、優先度の低い機能が先に完成し、本当に必要だった機能が後ろに回ります。3か月後のレビューで「これは今要らなかった」という話になり、手戻りと稼働の消費だけが残る。これが典型的な失敗のもとです。

介護記録SaaS「CareViewer」の案件では、日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制で継続開発を進めていますが、発注側が週次で優先順位を判断する運用を最初から固めています。要件が動き続けるSaaSでも、判断の場が毎週あれば、開発が漂流することはありません。

発注側が確保する時間の目安と、開発会社が巻き取れる範囲

POの負担がどのくらいかは、外注に踏み切れるかどうかの分かれ目です。2週間スプリントなら、スプリントプランニング、スプリントレビュー、バックログのリファインメントが隔週で入り、これに日々の質問への回答と、月次のロードマップ見直しが重なります。片手間の空き時間で回せる量ではありません。当社が相談をお受けするときも、この時間を業務として確保できるかを先に確認し、確保できないなら請負を勧めています。

この時間を確保できないなら、アジャイルの外注は選ばないほうがよいというのが私の考えです。ただし、負担の中身は開発会社によって大きく変わります。要件の細部の言語化、チケットへの落とし込み、進捗管理、コードレビュー、リリース判定の準備は、日本人PMやブリッジSEをフロントに置く体制なら開発会社側が巻き取れます。発注側に残るのは「何を優先するか」「これで受け入れてよいか」の判断だけ、という形にできます。丸投げはできませんが、丸投げできる範囲は会社によって違う、というのが実情です。

直接の作業指示は避ける——偽装請負を指摘されないための経路

もう1つ、契約と体制の両方にまたがる注意点があります。発注側の担当者が外注先のエンジニアに直接、日々の作業を指示すると、偽装請負を指摘されるおそれがあります。準委任契約では、指揮命令権は受注側にあるためです。

実務上は、コミュニケーションの経路をPO⇔スクラムマスターに集約し、開発チームへの作業指示はスクラムマスター経由にします。デイリースクラムに発注側が同席すること自体は問題になりませんが、その場で個々のエンジニアに作業を割り振るのは避けてください。この点については、厚生労働省が「労働者派遣事業と請負により行われる事業との区分に関する基準(37号告示)に関する疑義応答集(第3集)」を2021年9月21日に公表しており、IPAもモデル契約のページから参照しています。契約書に役割と経路を書き、実際の運用もそれに合わせる。この一致が要注意です。

スプリントの回し方——リズムの決め方、デイリー、レビュー、レトロスペクティブ、完了の定義

体制が決まったら、あとはリズムを固定するだけです。スプリントの長さ、イベントの曜日と時間、参加者、そして「何をもって終わりとするか」。この4つを着手前に紙に書いて合意しておくと、1スプリント目から動けます。逆に、走りながら決めようとすると、最初の2か月がリズム作りだけで消えていきます。

2週間スプリントの標準的な流れ(表)

スクラムガイド(2020年版)は、スプリントを1か月以内の固定した長さのイベントと定めています。その範囲のどこに置くかはプロダクト次第で、要件の変化が速い立ち上げ初期は短く、方向が固まっていれば長めが扱いやすくなります。ここでは外注で採りやすい2週間を例に、標準的な時間割を示します。

発注側のPOが必ず出るのはプランニングとレビューの2つです。デイリーは任意でよく、出るとしても聞き役に徹します。レトロスペクティブは開発チーム内で行われるのが通例ですが、コミュニケーションやドキュメントに関する要望はスクラムマスター経由で議題に入れてもらえます。

受入基準と完了の定義(DoD)を着手前に文章にする

準委任には完成責任がありません。だからこそ、何をもって「できた」とするかを別に決めておく必要があります。ここを飛ばすと、レビューのたびに「想定と違う」という言い合いが起き、判定が終わらないまま次のスプリントに持ち越されます。

決めるものは2つです。1つは、バックログアイテムごとの受入基準。「メールアドレスの形式検証が動く」「既存のメールアドレスでの登録はエラーになる」のように、動作で判定できる箇条書きにします。もう1つは、全アイテムに共通する完了の定義(Definition of Done)です。単体テストが通っている、コードレビュー済み、CIが通っている、検証環境で動作確認済み、といった条件を列挙します。

受入基準は「作ってほしいもの」ではなく「満たしていたら受け入れる条件」として書くのがこつです。「ログイン機能を作って」では判定できません。判定できない基準は、そもそも基準ではないということになります。完了の定義は開発が進むにつれて更新してかまいませんが、変えるときはPOとスクラムマスターが合意して文書に残してください。

スプリント単位の検収と支払い、品質の担保

検収は、スプリントレビューでの受入判断とひも付けるのが実務的です。個別契約に「スプリント終了時にデモ可能な動作状態のソフトウェアを確認し、受入基準の充足をもって検収とする」と書いておけば、準委任のまま検収の基準を明確にできます。受入不可となったアイテムはバックログに戻し、次スプリント以降で再度取り上げます。支払いは月次、またはスプリント終了時が一般的です。

品質は契約ではなく仕組みで担保します。当社の場合は、日本人PMによる設計レビュー、Gitのプルリクエストを使ったコードレビューの標準化、リリース前のダブルチェックの3点を標準の工程に組み込んでいます。完了の定義にコードレビューとテストを入れておけば、スピードを優先して品質が置き去りになる事態も防げます。契約で問えない品質を、日々の工程で積み上げる仕組み。

外注でアジャイルが失敗する5つの理由と対策——受入基準、PO不在、週次報告、入れ替わり、時差

アジャイル開発の外注がうまくいかないとき、原因はたいてい着手前に決めていなかったことに戻ります。逆に言えば、契約前と立ち上げ時に手を打てる論点ばかりです。ここでは、相談で繰り返し見てきた5つの失敗と、それぞれの対策を整理します。

失敗の5パターンと対策(表)

5つとも、共通するのは「決めていないから起きる」という点です。距離やスキルの問題に見えることが多いのですが、実際には設計の問題です。

私が見てきた失敗に共通する2つ——受入基準を書かない、報告が週次のみ

2018年からホーチミンで約100社の開発体制の相談に乗ってきましたが、アジャイルの外注で行き詰まった案件には共通点が2つあります。

1つ目は、受入基準を書かないまま着手したケースです。「使いながら決めるのがアジャイルだから」と、バックログに機能名だけを並べて走り出す。最初の2スプリントは勢いで進みますが、3スプリント目のレビューで「この画面はこういう意味ではなかった」という話が出て、そこから毎回、判定に1時間以上かかるようになります。作り直しの分だけ費用が増え、双方に不信が残ります。アジャイルは「何も決めなくてよい」という意味ではない、というのがここでの教訓です。

2つ目は、報告が週次のメールだけになっていたケースです。スプリントという言葉は使われているのに、レビューは画面のスクリーンショットを貼った報告書で、優先順位の入れ替えは一度も起きていない。3か月目に初めて動くものを触って、方向がずれていたことに気づく。これは形だけのアジャイルであって、ウォーターフォールをスプリントに刻んだだけです。動くソフトウェアを毎回触れるかどうかが、見分ける唯一の基準だと考えています。

「アジャイルできます」を見極める7つの質問

提案を受ける段階で、実際にスクラムを回せる相手かどうかは質問で確かめられます。当社がお客様から聞かれて答えている内容でもあります。

1. 直近のプロジェクトでスプリントの長さと振り返りの頻度はどうでしたか
2. 発注側のプロダクトオーナーと日常的にやり取りした経験はありますか。頻度はどのくらいでしたか
3. 毎スプリントの終わりに動くソフトウェアのデモを行っていますか。デモの形式を教えてください
4. アサインされたメンバーは期間中固定されますか。交代が生じる場合のルールはありますか
5. コードレビュー、テスト、CIは標準の工程に入っていますか
6. 見積もりはどう出していますか。精度をどう改善していますか
7. 振り返りで出た改善点をどう追跡し、実際に何が変わりましたか

答えが抽象的な場合は、実績が薄いと考えたほうが安全です。とくに3番と4番は、形だけのアジャイルを見分けるのに効きます。ここまでが、国内・海外を問わず共通する話でした。では、時差と言語のある海外チームでは、この運用をどう成立させればよいのでしょうか。

オフショアでアジャイルを回す実務と当社の体制——時差2時間、日本人PMがスクラムマスター役

「海外のチームでスクラムは回るのか」という質問は、相談の場でほぼ必ず出ます。結論から言えば回ります。ただし条件があり、時差が小さいこと、スクラムマスター役を日本語で担える人がいること、進捗が文字とコードで見えることの3つです。ベトナムはこの3つをそろえやすい場所で、当社が拠点を置いているのもそのためです。

時差2時間で同日中に往復する——会議の置き方と非同期の使い分け

ベトナムと日本の時差は2時間です。日本の午前10時はホーチミンの午前8時にあたり、日本の定時内はほぼそのまま現地の稼働時間と重なります。午前中に投げた質問はその日のうちに返ってくるので、判断待ちでスプリントが止まる時間を短くできます。

会議の置き方は次のようにしています。デイリースクラムは日本時間の午前中(現地の始業直後)に15分。スプリントプランニングとレビューは日本時間の午後に設定し、ステークホルダーが参加しやすい時間に寄せます。すべてをリアルタイムにする必要はなく、デモは録画を残して後から確認できるようにし、仕様の質問はチケットのコメントに集約する。同期と非同期を分けておくと、参加者の負担が下がります。

注意点は祝日です。ベトナムの祝日は2026年で年12日(労働法112条の法定は11日で、2026年からベトナム文化の日が加わります)で日本より少ないのですが、旧正月(テト)だけは長期休暇になります。2026年は2月14日から22日までがテト休暇にあたるため、この期間をまたぐスプリントは計画を前後に寄せるか、期間を調整します。

Gitのプルリクエストとチケットで可視化する

距離のあるチームで信頼を作るのは、報告書ではなく現物です。当社では、作業の単位をチケットに落とし、コードの変更はすべてGitのプルリクエストとして残し、日本人PMが設計レビューとコードレビューを行う運用を標準にしています。発注側は、いつでもチケットの状態とプルリクエストの差分を見られます。

この形にしておくと、進捗を人に聞かなくても分かります。「今どこまで進んでいますか」というメールのやり取りが消え、スプリントレビューでは動くものを見る時間に集中できます。リリース前のダブルチェックを工程に入れているのも、完成責任のない準委任で品質を担保するための仕組みです。当社はAWS認定11冠の体制でインフラまで見られるため、環境まわりで発注側が手を動かす場面も減らせます。

当社のラボ型(準委任)——最小構成 日本人PM+2〜3人月で月額約80万円〜

当社が提供しているのはラボ型開発で、契約はここまで説明してきた準委任です。体制は2パターンあり、日本人PM/ブリッジSEをフロントに置いてエンジニアを付けるパターンA(推奨)と、エンジニアのみのパターンBです。アジャイルで回す場合、スクラムマスター役を日本語で担える人が必要になるため、パターンAをお勧めしています。

アジャイル外注の費用は、スプリントごとに動くチームの人数と役割構成で決まります。当社の月額約80万円〜は日本人PM+2〜3人月の最小構成の数字で、チーム規模と役割構成が変われば金額も変わるため、他社の提示額と単純に比較はできません。人数と役割をそろえたうえで比べてください。費用の考え方は「ラボ型開発 費用」の記事でも整理しています。

アジャイルの外注が向く案件・向かない案件

最後に、正直なところを書いておきます。当社に相談いただいても、アジャイルの外注をお勧めしない案件があります。

向くのは、要件が使いながら固まっていくプロダクト開発、リリース後も継続して改善する自社サービス、内製チームの手が足りず同じリズムで動ける人員を足したい場合、そして優先順位を決められる担当者が社内にいる場合です。CareViewerのように、要件が動き続ける介護記録SaaSを週次の判断で回している案件は、この条件がそろっています。従来の半分以下のコストで継続開発できているのは、作らなくてよいものを作らずに済んでいるからです。

向かないのは、仕様が確定していて期日も固定の単発開発、優先順位を判断する担当者を置けない体制、そして月あたりの開発量が読めない不定期な案件です。1つ目は請負のほうが発注側の負担が軽く、費用も固定できます。2つ目は、どの開発会社に出しても同じ結果になります。こうした案件では、当社からも率直にその旨をお伝えしています。

アジャイル開発の外注でよくある質問

アジャイル開発の外注について、相談の場で繰り返し聞かれる質問を5つにまとめました。社内の稟議や法務との調整にもお使いください。

Q1. どうしても請負で発注したいのですが、無理でしょうか?

全体を請負にするのは勧めません。ただし併用はできます。探索が必要な部分は準委任で進め、仕様が固まった機能(管理画面の一覧・登録・更新など)を切り出して請負で発注する形は現実的です。IPAのモデル契約も、フェーズを分ける多段階の考え方を含んでいます。

Q2. プロダクトオーナーを外部に任せられますか?

一部は任せられますが、全部は任せられません。要件の言語化、チケットへの落とし込み、進捗管理は開発会社側が巻き取れます。一方、何を優先するかという事業判断と、受け入れてよいかの最終判断は発注側に残ります。ここを外に出すと、誰も事業責任を持たない状態になります。

Q3. 「いつ完成するか」を約束してもらえますか?

準委任では完成を約束できません。代わりに示せるのは、直近数スプリントの実績から逆算した見通しです。当社では3スプリント程度の実績が出た段階で、残りのバックログに対する概算の期間をお伝えしています。精度が上がるのは助走期を過ぎてからで、最初の2スプリントの速度で長期計画を立てるのは失敗のもとです。

Q4. 時差のあるチームでスクラムは回りますか?

回ります。ベトナムとの時差は2時間で、日本の定時内がほぼそのまま重なるため、質問の往復は同日中に完結します。当社は日本人PMがスクラムマスター役を担い、デイリー・レビュー・振り返りを日本語で運営しています。テト休暇(2026年は2月14日〜22日)の期間だけは、スプリントの計画を調整してください。

Q5. 途中でやめられますか?

スプリント単位の個別契約にしておけば、次の個別契約を結ばないことで終了できます。当社の場合、増員は約1週間、縮小・交代は1か月単位で対応しています。終了時のソースコードとドキュメントの引き渡し方法は、基本契約に書いておくのが安全。

まとめ: 準委任で組み、POを社内に立て、スクラムマスターは開発会社に持たせる

アジャイル開発の外注は、請負ではなく準委任契約(ラボ型を含む)で組みます。請負は「確定した仕様の成果物の完成」に対価を払う契約で、完成の定義が反復のなかで動き、変更のたびに契約変更が要るアジャイルとは前提が噛み合わないためです。IPAの「情報システム・モデル取引・契約書(アジャイル開発版)」も準委任を前提としており、契約前チェックリストとひな型は社内の法務との調整にそのまま使えます。仕様が固まった機能だけを請負で切り出す併用は有効です。

体制は、プロダクトオーナーを発注者側が担い、スクラムマスターを開発会社側が担う。この線引きを崩さないことが条件です。バックログの優先順位は事業判断なので発注側に残りますが、要件の言語化・進捗管理・品質の担保は開発会社が巻き取れます。発注側は、スプリントの定例と日々の質問対応に充てる時間を、担当者の業務として確保してください。受入基準と完了の定義を着手前に文章にし、スプリント単位で検収する。失敗する案件は、この準備を飛ばしたか、報告が週次だけでスプリントが形だけになったかのどちらかです。

オフショアでも条件がそろえばスクラムは回ります。当社はホーチミンを拠点に、時差2時間で同日中に往復できる環境で、日本人PMがスクラムマスター役を担い、Gitのプルリクエストとチケットで進捗を可視化しています。契約は準委任(ラボ型)で、最小構成は日本人PMフロント+2〜3人月の月額約80万円〜、1名から最短2週間で開始でき、増員は約1週間、縮小・交代は1か月単位です。ラボ型そのものの全体像はラボ型開発とは、契約の法的な違いは準委任と請負の違いもあわせてご覧ください。現在の体制と要件をお聞かせいただければ、アジャイルで外注できる案件かどうかの判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。