テスト外注の契約形態｜準委任と請負の選び方と判断軸

外注は決めた。数社から見積も取った。あとは発注するだけ——そう思って見積書を眺めていると、「準委任」の三文字で手が止まります。上長に「これ、請負とどう違うの？」と聞かれて、うまく答えられなかった経験はないでしょうか。

テストを外に出す判断そのものは済んでいるのに、どの契約形態を選べば自社の案件に合うのか、確信が持てない。これは決め方がわからないというより、選んだ理由を自分の言葉で説明できないことのほうが大きな壁です。

この記事では、テスト外注の契約形態を準委任と請負のどちらにすべきか、6つの判断軸に沿って解説します。読み終えるころには、自社の案件を軸に当てはめて、自分で結論づけられる状態になります。法律の解説ではなく、現場で何が起きるかという視点で進めます。

テスト外注の契約形態が結果を左右する理由

契約形態は、単なる料金の払い方の違いではありません。外注先とどう協業するかを決める「設計図」です。ここを曖昧にしたまま進めると、後工程で必ずひずみが出ます。

そして、テストの外注には開発全般の契約解説がそのまま当てはまらない、という固有の事情があります。まずこの点を押さえておくと、以降の判断軸が腹落ちしやすくなります。

契約形態が決めるのは「お金」ではなく「責任と動き方」

契約形態が実際に規定するのは、次の3つです。

• 指揮命令の可否: 外注先の担当者に直接指示を出せるのか、それとも窓口を通すのか
• 報告物の定義: 何を、どの粒度で、いつ受け取れるのか
• 品質責任の所在: バグを見逃したとき、その責任はどちらが負うのか

「うまく連携できるか不安」という気持ちの多くは、この3点が見えていないことから来ています。裏を返せば、契約形態を理解するだけで、連携イメージのかなりの部分は解像度が上がります。契約形態は「お金」ではなく「責任と動き方」を決めるものと捉え直すのが第一歩です。

システム開発全般の契約解説がテストにそのまま使えない理由

契約形態を調べると、システム開発一般の解説がたくさん出てきます。しかしテストには、開発とは決定的に違う業務特性があります。

それは、テストは欠陥の存在は示せても、欠陥の不在は証明できないという性質です。これはソフトウェアテストの世界で広く共有されている基本原則で、どれだけ丁寧にテストしても「バグが見つからなかった」としか言えず、「バグがゼロである」ことは示せません。「存在しないこと」の証明が原理的に難しいという意味では、いわゆる悪魔の証明にも通じる話です。

ここで押さえたいのは切り分けです。保証できないのは「バグゼロ」という結果であって、合意した範囲のテストをきちんと実行し報告する、という業務の質そのものは問えます。この区別は後半の品質責任の軸で改めて効いてきます。

開発の「完成」は、動く成果物として目に見えます。一方でテストの「完成」は、何をもって完成とするかを事前に合意しておかないと、そもそも定義できません。この違いを無視して開発の契約感覚を持ち込むと、期待のズレが生まれます。ここが本記事の核心です。

もう一つ、テスト固有の事情があります。それは、テストの範囲が「どこまでやるか」の判断に強く依存する点です。開発の成果物は仕様が決めますが、テストは同じ機能に対しても、正常系だけ確認するのか、異常系や境界値まで踏み込むのかで工数が何倍にも変わります。

この「どこまで」を契約時に握れているかどうかが、後のトラブルを分けます。裏を返せば、範囲の握りが甘い案件ほど、成果物を固定する請負は組みにくくなるということです。

契約の確認を後回しにすると起きる典型トラブル

契約形態の確認を「細かいことは後で」と後回しにすると、次のようなトラブルが典型的に発生します。

• 追加費用の紛争: テスト範囲が動いたのに、追加費用の扱いを決めておらず揉める
• 成果物の期待ズレ: 「テストが終わったら報告書が出る」と思っていたら、想定と違う粒度のものが出てきた
• 検収できない報告書: 何をもって合格とするかを決めていないため、受け取った報告書で検収の判断ができない

実際に外部へテストを委託した現場の振り返りでも、内製と違って開発の経緯や裏仕様が自然には伝わらず、この情報格差を意図的に埋めるフェーズを設計しないと表面的なテストにとどまる、という教訓が語られています。連携の質は、発注前の契約設計の段階でかなりの部分が決まるということです。

準委任契約と請負契約の違い｜テスト外注で効く3つのポイント

ここからは準委任と請負の違いを見ていきます。ただし基礎定義は最小限にとどめ、すぐに「テストの外注で実務上効いてくる違い」に進みます。法的な深掘りは公的な資料に委ねます。

準委任契約とは｜業務の遂行に責任を持つ契約

準委任契約は、決められた業務を誠実に遂行することに責任を持つ契約です。専門家として注意を払って業務にあたる義務（善管注意義務）を負いますが、成果物の完成そのものは保証しません。

費用は原則として、かかった工数に応じて精算されます。「この範囲のテストを、この体制で進める」という遂行そのものに対して対価を払う形です。詳しい定義はe-Gov法令検索で民法の該当条文を確認できます。

請負契約とは｜成果物の完成に責任を持つ契約

請負契約は、あらかじめ約束した成果物を完成させることに責任を持つ契約です。完成させて初めて対価が発生し、発注側は成果物を確認して受け取る検収を行います。

費用は成果物に対する固定価格が基本です。「このテストをやり切って、この報告書を納める」という完成に対して対価を払います。発注側から受注側の担当者へ直接の指示は出さないのが原則です。テスト工程を含めた契約の組み立て方は、IPAの「情報システム・モデル取引・契約書」が実務の設計例として参考になります。

テスト外注で効いてくる3つの違い

定義よりも大事なのは、この違いがテストの外注で実際にどう効いてくるかです。3つの場面で整理します。

テスト外注の場面	準委任契約	請負契約
バグを見逃した場合の責任	プロセスを尽くしたかが問われる（プロセス責任）	合意した範囲のテストを規定どおり実行・報告する完成責任は負う。ただし範囲外・原理的に検出不能なバグの不存在までは保証しない
テスト項目を追加したくなった場合	工数の範囲内で調整、または工数追加で対応しやすい	原則として再見積・スコープの再交渉になる
成果物と検収	テスト完了報告書は活動の記録という位置づけ	テスト完了報告書が検収対象の成果物になりうる

3つの場面のうち、実務で最も揉めやすいのは2段目の「テスト項目の追加」です。テストを進めると、当初想定していなかった観点や、開発側の仕様変更に伴う追加検証が必ずと言っていいほど出てきます。準委任なら工数の枠内で柔軟に吸収できますが、請負では一つひとつが再見積の対象になり、そのたびに交渉が発生します。テストが「動きながら固まっていく」性質を持つ以上、この差は軽視できません。

もう一点、注意があります。準委任は「業務を人に頼む」形のため、労働者派遣や偽装請負と混同されやすいものです。指揮命令の線引きを誤ると問題になりますが、これは後半で改めて触れます。まずは、この3つの違いが「範囲が動くかどうか」に集約されることだけ押さえておいてください。

テスト外注の契約形態を決める6つの判断軸

いよいよ本題です。ここでは、自社の案件を当てはめて自分で結論を出せる物差しを提示します。各軸は「テスト範囲は仕様書で確定しているか？ Yes→請負寄り／No→準委任寄り」という問いの形で読んでください。上から順に自問して傾きを数えれば、テスト外注の契約形態は6軸の合計で見えてきます。

軸1・2：テスト範囲の確定度と仕様変更の頻度

軸1：テスト範囲は仕様書で確定しているか？ テスト仕様書があり、対象範囲がはっきり切れているなら請負が組めます（Yes→請負寄り）。仕様資料が揃わず範囲が曖昧なら、完成を約束しようがないため準委任が現実的です（No→準委任寄り）。

なお、どのテストレベルを外注するかで範囲の固めやすさは変わります。システムテストは仕様書で範囲を固定しやすい一方、結合や回帰は開発と並走して流動的になりやすい——同じ案件でもレベルによって傾きが違う点は意識しておきましょう。

軸2：テスト期間中に仕様が動くか？ テスト中も仕様が変わり続けるなら準委任が向きます（動く→準委任寄り）。仕様が凍結済みで、テスト期間中に動かないと見込めるなら請負も選べます（凍結→請負寄り）。

軸3・4：品質責任の所在と開発モデル

軸3：品質責任を「完成」で約束できるか？ ここで最も多い誤解を正しておきます。請負で保証できるのは「合意したテストを完了させること」であって、「バグがゼロであること」ではありません。「バグゼロ」は請負でも準委任でも、どちらでも保証されない——これは契約形態の問題ではなく、テストという業務の本質です。ただし「合意範囲のテストを規定どおり実行したか」という実行の質は問えます。請負にすれば品質そのものが保証される、という期待だけは最初に手放してください（完成範囲を定義できる→請負寄り／プロセス保証にとどまる→準委任寄り）。

軸4：開発モデルは反復型か終盤の確定型か？ アジャイル開発のように反復しながら進める場合、範囲を都度確定できないため準委任寄りになります（反復→準委任寄り）。IPAが公開するアジャイル開発向けのモデル契約も準委任をベースにしています。ウォーターフォールの終盤で、テスト範囲が確定しているフェーズなら請負も成立します（終盤の確定範囲→請負寄り）。

軸5・6：依頼の形（スポット/継続）と成果物・検収の要否

軸5：依頼はスポットか継続か？ リリース前に範囲を切って一度だけ依頼するスポット依頼で、対象が確定しているなら請負がなじみます（スポット確定→請負寄り）。継続的にQAを支援してほしい形なら準委任が向いています（継続支援→準委任寄り）。

軸6：検収基準を自社で書けるか？ テスト完了報告書をもって検収したく、合格基準を自社で示せるなら、成果物が明確な請負が明快です（書ける→請負寄り）。逆に、何をもって合格とするかを書けないなら、請負はむしろリスクになります（書けない→準委任寄り）。完成の定義を発注側が示せない請負は、後で揉める火種だからです。

以上6軸を、上から○×を付けるだけで結論に着地できる早見表にまとめます。各行の問いに答え、傾きの多いほうが第一候補です。

判断軸（問い）	Yes / 該当なら	No / 逆なら
軸1：テスト範囲は仕様書で確定しているか？	請負寄り	準委任寄り
軸2：テスト期間中に仕様が動くか？	準委任寄り	請負寄り
軸3：品質責任を「完成範囲」で約束できるか？	請負寄り	準委任寄り
軸4：開発モデルは反復型か？	準委任寄り	請負寄り（終盤の確定範囲）
軸5：依頼は範囲確定のスポットか？	請負寄り	準委任寄り（継続支援）
軸6：検収基準を自社で書けるか？	請負寄り	準委任寄り

この6軸は、すべてが同じ向きにそろうとは限りません。たとえば「範囲は確定しているが、開発はアジャイル」という案件では、軸1は請負寄り・軸4は準委任寄りと、傾きが割れます。その場合は、より重い軸を優先します。

実務では、範囲の確定度（軸1）と検収基準を書けるか（軸6）の2つが最も重く効きます。この2軸がそろって請負寄りなら請負、片方でも崩れるなら準委任を軸に考える、という重みづけを覚えておくと判断が速くなります。

軸6の「検収基準を書けるか」で悩む場合は、テストの完了基準の決め方から整理し直すのが近道です。テストの完了基準の決め方を判断軸から解説した記事もあわせて読んでみてください。

ケース別に見る契約の選び方

6つの判断軸を、実際の案件パターンに当てはめてみます。「うちはこのケースだ」と自己判定できるようにするのが狙いです。テスト外注の契約形態は、案件のパターンごとに傾きが読めます。

請負が成立しやすいケース

次の条件がそろうと、請負が組みやすくなります。

• ウォーターフォールの終盤で、テストフェーズに入っている
• テスト仕様書があり、対象範囲が明文化されている
• テスト期間中に仕様が動かない（範囲が凍結されている）
• テスト完了報告書で検収したい意図がある

要件が固まり、何を完成とするかを発注側が示せる状態です。範囲を発注側が明文化できる案件ほど、固定価格の請負が噛み合うといえます。

準委任が現実的なケース

一方、次のような案件では準委任が現実的です。

• アジャイルで開発と並走し、範囲が都度変わる
• 仕様資料が十分に揃っていない
• 探索的テスト中心で、進めながらテスト対象を見極めたい
• 継続的にテストを支援してほしい

探索的テストとは、James Bachによれば「テスト設計とテスト実行を同時並行で進める学習行為」です。要件が不完全で変化し続ける現実の中で、テストしながら次に何を見るかを決めていくアプローチのため、事前にテストケースを固定する形の請負とは相性が良くありません。チャーターやセッション単位で成果を定義すれば請負化も一応可能ですが、範囲の確定度が低いほど準委任のほうが現実的です。

なお「資料が揃っていないから外注できない」わけではありません。資料が薄い状態でも進める方法はあります。資料が揃っていない状態でのテスト代行の進め方は別記事で具体的に解説しています。

迷ったときの現実解｜フェーズで分ける

多くの案件は、きれいにどちらか一方に振り切れません。そこで有効なのが、フェーズで契約を分ける現実解です。

テスト計画・設計のように、進めながら固めていく段階は準委任にする。範囲が確定したテスト実行フェーズは請負にする。こうして段階を分割すれば、それぞれの特性に契約を合わせられます。

契約が2本になると事務が増えるように見えますが、同一の外注先にフェーズで契約種別を切り替える形なら、発注窓口は実質1本で事務負荷は抑えられます。「どちらか一方で貫く必要はない」という発想を持つだけで、選択肢はぐっと広がります。

このフェーズ分割には、もう一つ実務的な利点があります。準委任のテスト設計フェーズを通じて、外注先が案件の勘所や裏仕様を掴んだ状態で、実行フェーズの請負に入れる点です。いきなり範囲を固めて請負を発注するより、設計を一緒に走らせたあとのほうが、双方にとって範囲の合意が正確になります。

結果として、請負フェーズでの「言った・言わない」の紛争も起きにくくなります。段階を分けることは、単なる契約の使い分けではなく、情報格差を埋める段取りでもあるのです。

契約形態の誤選択で起きる症状と対処

ここでは「選び間違えるとどうなるか」を、法律論ではなく現場の症状として見ていきます。原因と対処をセットで押さえておくと、発注前に予防できます。

請負なのに仕様が流動的｜追加費用と範囲の紛争

範囲が確定していないのに請負を選ぶと、仕様が動くたびに再見積とスコープ交渉が発生します。とくにリリース直前の変更は、費用の紛争に発展しやすい典型です。「間に合わせたいのに、契約の話で止まる」という最悪の展開になりかねません。

このパターンで厄介なのは、当初は請負が正しく見えてしまう点です。発注の時点では範囲が固まっているように感じても、開発が遅れれば仕様は後ろ倒しで動きます。テストは開発の下流にあるため、上流の遅れやブレをまとめて引き受ける構造にあるのです。

「請負にしたのに結局もめた」という声の多くは、この構造を読めていなかったことに起因します。範囲が本当に凍結されているかは、発注側の願望ではなく、開発の進捗という事実で確かめる必要があります。

準委任なのに完了保証を期待｜期待ズレの構造

準委任なのに「お金を払ったのだから、テストは完了して当然」と期待すると、必ずズレが生まれます。準委任が約束しているのは遂行であって、完成ではないからです。

対処は、工数の中で「何を、どこまでやるか」を発注前に合意することです。ここを言語化しておけば、「払ったのに終わっていない」という感情的な対立は避けられます。

指揮命令の混同｜準委任で直接指示を出しすぎるリスク

準委任だからと外注先の担当者に直接こまごまと指示を出しすぎると、偽装請負とみなされるリスクがあります。詳細は厚生労働省の労働者派遣・請負に関する情報を確認してください。

対処はシンプルです。窓口を一本化し、指示は文書で残すこと。口頭での個別指示を積み重ねる運用をやめ、作業依頼は成果物ベースで受注側のリーダーに渡す形に変えるだけで、多くのリスクは下げられます。

判断のよりどころは「日々の作業に細かく口を出しているか」です。テストケースの実行順序や担当割りといった内部の進め方は、受注側に委ねるのが原則です。発注側が示すのは「何を、いつまでに、どの品質基準で」という到達点であって、そこへ至る手順そのものではありません。この線引きさえ守れば、準委任でも過度に神経質になる必要はありません。

症状と対処を、表で整理します。

症状	原因	対処
変更のたびに再見積・費用で揉める	流動的な範囲に請負を適用した	範囲を凍結できるまで準委任にする／フェーズ分割
「払ったのに終わっていない」不満	準委任に完成を期待した	工数内でやる範囲を発注前に合意
偽装請負を指摘される懸念	準委任で直接指示を出しすぎた	窓口の一本化・指示の文書化

期待のズレを防ぐには、契約以前に連携の作り方そのものが効きます。外注先との連携で品質を保つコツをまとめた記事も参考になります。

上長に説明できる契約形態の整理｜稟議を通す準備

最後に、冒頭の「上長を説得しきれない」という壁に戻ります。契約形態を、費用対効果とリスクの言葉に翻訳できれば、稟議はぐっと通りやすくなります。

コスト構造とリスクの持ち方をどう説明するか

準委任と請負は、コストの構造とリスクの持ち手が異なります。金額そのものは案件次第ですが、費用の「構造」は次のように整理できます。

• 準委任：工数×単価の変動費。工数の上限を設定すれば費用の天井を管理できる。範囲が動くリスクは発注側が持つ
• 請負：範囲を完成させる固定費。範囲を確定させたぶんに相応のバッファが価格へ乗る。範囲を完成させるリスクは受注側が持つ

この違いは、リスクを「誰が値段に織り込むか」の違いとも言えます。準委任では、範囲が動くリスクを発注側が抱えるかわり、単価は素直な水準になりやすい。請負では、範囲を完成させきるリスクを受注側が負うため、その不確実性の分がバッファとして価格に乗ります。つまり、範囲が読めない案件で無理に請負を求めると、見えないリスク料を余分に払うことになりがちです。

上長に出すときは、金額を並べる前に「構造」を1枚で見せると通りやすくなります。以下のようなフォーマットが有効です。

比較項目	準委任	請負
課金方式	工数×単価（変動）	成果物への固定価格
費用の上限管理	工数上限で天井を設定できる	契約時に固定（範囲確定が前提）
範囲変更・追加時の扱い	工数の追加で吸収しやすい	再見積・スコープ再交渉
リスクの持ち手	範囲が動くリスクは発注側	完成リスクは受注側（バッファが価格に反映）

ここで上長に伝えるべきは「どちらが安いか」ではありません。契約形態は「どちらが安いか」ではなく「今の案件にどちらのリスクの持ち方が合うか」で選ぶ——この一言が、稟議の説得力を変えます。範囲が読めない案件で固定価格を求めれば、そのリスク分は価格に転嫁されるだけだからです。費用の考え方はテスト代行の費用相場を整理した記事も合わせて確認できます。

見積比較で確認すべき契約関連チェック項目

複数社の見積を比較するとき、金額の前に契約面で見るべき項目があります。

• 契約形態が準委任か請負か、明記されているか
• 準委任なら、工数の精算幅（上限・下限）はどうなっているか
• 報告物（テスト完了報告書など）の内容と粒度が定義されているか
• 請負なら、検収条件（何をもって合格とするか）が書かれているか
• 仕様変更が起きたときの扱い（追加費用の考え方）が決まっているか

金額だけを横並びにすると、安く見える見積が実は範囲を絞っていた、という落とし穴にはまります。テスト完了報告書のような成果物は、テストサマリレポートや不具合報告書など複数の書類で構成されるのが一般的です（布施昌弘『ソフトウェアテスト教科書』でも報告書は用途別に整理されています）。何が含まれるかまで確認しておきましょう。

発注前に社内で決めておくこと

契約形態を選ぶ前に、社内で決めておくべきことがあります。

• 自社のテスト範囲がどれだけ確定しているかの自己評価
• テスト完了報告書が必要かどうか
• 外注先とのやり取りの窓口担当を誰にするか

窓口については、専任を新たに置く必要はありません。PM自身が窓口を兼ねてもよく、指示ルートを1本化するだけで足ります。人を増やせない体制でも、この整理さえできていれば運用は回ります。

逆にここが曖昧だと、どの契約形態を選んでも運用でつまずきます。テスト代行を依頼する前の準備を解説した記事で、発注前の段取りを確認しておくと安心です。

まとめ｜テスト外注の契約形態は案件の性質で決まる

テスト外注の契約形態は、準委任と請負のどちらが正解と決まっているわけではありません。案件の性質に合うほうを選ぶ、というのが結論です。改めて6つの判断軸を再掲します。

• 軸1：テスト範囲の確定度
• 軸2：仕様変更の頻度
• 軸3：品質責任の持ち方（バグゼロはどちらでも保証されない）
• 軸4：開発モデル
• 軸5：依頼の形（スポット／継続）
• 軸6：成果物・検収の要否

正解は「どちらか一方」ではなく、案件の性質が契約形態を決める。範囲が固まれば請負、動くなら準委任、迷えばフェーズで分ける——この物差しがあれば、上長にも自信を持って説明できます。

そして、契約形態の検討は外注先の選定と切り離す必要はありません。誠実な外注先なら、案件を聞いたうえで契約形態から一緒に設計してくれます。工数ベースの準委任型でスポット契約に対応し、探索的テストにも柔軟に応じてくれる相手なら、範囲が固まりきらない段階からでも相談しやすいはずです。自社の案件に合う契約形態を含めて、テスト外注の進め方を相談するところから始めてみてください。