SIerのテスト外注｜多重下請けでも品質を担保する依頼設計

2026 8/07

2026年8月7日 2026年8月7日

大規模で長期のシステム開発を束ねるSIerのPMにとって、テスト工程は品質と納期の両方が集中する最大の難所です。多重下請けで開発が進むなかで、テストだけを自社や一次請けで抱えきれず、外部の力を借りたい場面は少なくありません。

しかし、SIerのテスト外注は、一般的なテスト代行とは事情が大きく異なります。エンドユーザー・元請け・下請けという三者以上の関係、厳しい検収基準、再委託や秘密保持の制約が絡み合うからです。

この記事では、多重下請け構造という業界特有の文脈を前提に、責任範囲の切り分けから契約設計、品質説明の組み立てまで、PMがそのまま依頼設計に使える形で整理します。

テスト外注そのものの一般論ではなく、SIer・大規模受託の現場でPMがつまずきやすい論点に絞って解説します。汎用の記事では触れられない「三者以上の関係のなかで、どこまでを誰の責任にするか」という問いに、依頼前の設計として答えを出すことがねらいです。

SIerのテスト外注が一般的な外注と異なる4つの前提

一般的な「テスト代行」の記事は、開発会社が単独でベンダーへ依頼する構図を前提にしています。ところがSIerの現場では、その前提がほとんど成り立ちません。まず押さえるべきは、SIerのテスト外注に固有の4つの前提です。

三者以上の関係が常態：エンドユーザー、元請け、一次請け、二次請けと登場人物が多く、意思決定と情報が分断されやすい
大規模・長期・ウォーターフォール寄り：工程が明確に分かれ、結合・システムテストの規模が単独案件と桁違いになる
検収・受入基準が厳格：エンドユーザーの検収が最終関門で、合否判定の根拠を書面で説明する責任が重い
契約と再委託の制約：準委任・請負の別、再委託の可否、秘密保持や個人情報の取り扱いが案件ごとに縛られる

この4つは、それぞれが依頼設計に具体的な制約を課します。三者以上の関係は、合意形成のたびに承認の階層を増やし、意思決定を遅くします。大規模・長期の工程は、テストの母数を膨らませ、単独案件の感覚で見積もると工数が破綻します。

厳格な検収は、実施量だけでなく「なぜ出荷して問題ないか」の説明責任をPMに残します。契約と再委託の制約は、外注先の選定や作業範囲を法務・元請け契約の側から縛ります。

SIerのテスト外注で失敗する典型は、これら4つの前提を無視して汎用の「テスト代行の進め方」をそのまま当てはめてしまうことです。

汎用のテスト外注とSIer案件の違いを、対比で整理すると次のようになります。

観点	一般的なテスト外注	SIer案件のテスト外注
関係者	発注者と代行会社の二者	エンドユーザー・元請け・下請けの三者以上
開発規模	単一プロダクト中心	複数サブシステムの大規模結合
開発プロセス	アジャイル／小規模が多い	ウォーターフォール寄りの工程分割
品質の説明先	社内の上長が中心	エンドユーザーの検収部門まで
契約の論点	準委任か請負かが中心	再委託・秘密保持・責任分界も加わる

まずは自案件がこの右列のどこに当てはまるかを言語化することが、依頼設計の出発点になります。なお、SIerではなく自社製品や受託開発単体での委託を検討している場合は、受託開発のQA委託で体制と依頼範囲を決める考え方のほうが実情に近いので、そちらもあわせて確認してください。

多重下請け構造で崩れやすい「テストの責任範囲」を切り分ける

多重下請けの案件で最も事故が起きやすいのは、テストの責任範囲があいまいなまま外注が始まるケースです。「誰がどのテストレベルの品質に責任を持つのか」が層をまたいで曖昧になると、不具合が出たときに責任の押し付け合いが起きます。

責任分界点を「テストレベル×担い手」で表にする

責任範囲は口頭の合意ではなく、テストレベルと担い手を掛け合わせた表で固定するのが確実です。空欄を作らず、各セルに担い手と成果物を明記します。

テストレベル	一次請け（元請）	二次請け（開発）	テスト外注先
単体テスト	レビュー・基準策定	実施・エビデンス提出	該当なし
結合テスト	テスト計画の承認	一次実施	観点補強・再テスト
システムテスト	合否判定の責任	環境・データ提供	設計・実施の主担当
受入テスト支援	エンドユーザーと調整	不具合改修	検証支援・報告作成

この表を関係者全員が同じものを見ている状態にするだけで、後工程での混乱は大きく減ります。責任範囲は「工程」ではなく「テストレベル×担い手×成果物」の三軸で固定すると抜けが出ません。

とくに注意したいのが「該当なし」のセルです。表を作るときに空欄を残すと、そこが責任の空白地帯になります。外注先が担当しない単体テストであっても、「該当なし」と明示することで、誰の責任かをめぐる後日の議論を防げます。

責任分界点の合意は、キックオフの一度きりで終わらせず、仕様変更や体制変更のたびに見直すことが大切です。長期案件では担当者の入れ替わりも起きるため、表を更新し続ける運用者を決めておくと、認識のずれが蓄積しません。

情報連携の経路を先に決める

多重下請けでは、仕様変更や不具合情報が層をまたぐたびに劣化・遅延します。テスト外注先が二次請けの下にぶら下がる場合、元請けの仕様変更が届くまでに数日かかることも珍しくありません。

仕様・変更情報を外注先に届ける正規ルートを1本に定める
不具合の起票先とトリアージの責任者を層ごとに明記する
元請けへのエスカレーション基準（重大度・件数）を数値で決める
定例の頻度と参加範囲を、層を飛ばさない形で設定する

とくに不具合のトリアージは、層をまたぐと判断が滞りがちです。外注先が起票した不具合が、二次請け・一次請けと承認を経るうちに、対応要否の判断が数日単位で遅れることがあります。重大度の高い不具合は、層を飛ばして元請けの品質責任者へ直接エスカレーションできる例外ルートを、あらかじめ用意しておくと安全です。

情報連携の遅延は、そのままコストに跳ね返ります。試算例として、外注先が仕様変更を知るのが3日遅れ、その間に作った20ケースが作り直しになったとします。1ケースの設計・実施を仮に30分とすれば、それだけで10時間の手戻りです。こうしたロスが工程を通じて積み重なると、外注で削減したはずの工数が相殺されてしまいます。

工程ごとの切り分けをさらに細かく詰めたい場合は、テストの工程別外注で切り分けの判断軸を確認すると、どのレベルを外に出すべきか判断しやすくなります。

SIerのテスト外注に向く工程と向かない工程

限られた予算のなかで効果を最大化するには、外注に向く工程を見極めることが欠かせません。SIerのテスト外注では、規模が大きく反復的で、独立性が価値を生む工程ほど外部委託の効果が高くなります。

外注効果が高い工程・低い工程

工程	外注の向き	理由
システムテスト	向く	規模が大きく人手を要し、独立検証の価値が高い
大規模結合テスト	向く	ケース数が膨大で、専門部隊の量産力が効く
受入テスト支援	条件付きで向く	エンドユーザー調整は残るが実行支援は委託可能
単体テスト	向かない	実装知識と密結合で、開発側が持つべき
要件定義レビュー	向かない	業務知識と意思決定が必要で外部化しにくい

単体テストや要件定義レビューが外注に向かないのは、コストの問題ではありません。実装の内部構造や業務の意思決定と密結合しているため、外部に切り出すと連携のオーバーヘッドが成果を上回ってしまうからです。開発側が持つべき責任を無理に外へ出すと、かえって品質が下がります。

規模・反復性・独立性の3条件がそろう工程ほど、SIerのテスト外注の費用対効果は高くなります。

使いどころは「山」と「関門」に集中させる

外注を薄く広げると、連携コストばかりが増えて効果が薄まります。委託は工数の山になる工程と、品質の関門になる工程に集中させるのが定石です。

山：結合・システムテストのケース実行のように、短期間に大量の工数が必要な箇所
関門：検収前の最終確認のように、見落としが致命傷になる箇所

工程を絞り込むときは、費用対効果を数値で試算しておくと上長への説明が楽になります。たとえば、システムテストのケース実行を外注し、社内エンジニアが本来の開発に専念できた時間を金額換算すると、外注費との比較が具体的になります。SIerでは案件金額が大きいぶん、テスト遅延によるペナルティや信頼低下の損失も大きく、外注の効果は単純な人件費差以上に評価すべきです。

なお、そもそも内製と外注のどちらが得かを上長に説明する段階であれば、テストの内製と外注を判断する物差しを先に押さえると、投資判断の軸が明確になります。

第三者検証（IV&V）という選択肢をいつ使うか

SIer案件で汎用のテスト外注と一線を画すのが、第三者検証（IV&V：Independent Verification and Validation）の活用です。開発を担う組織から独立した立場で検証を行うことで、開発当事者では気づきにくい欠陥や、仕様と実装の乖離を洗い出します。

独立検証が効く場面

第三者検証は、単なる人手不足の補填ではなく「独立性」に価値がある場面で使うべきものです。次のような案件で効果を発揮します。

ミッションクリティカルで障害が社会的影響を持つシステム
開発ベンダーへの過度な依存を避け、品質を客観的に説明したい案件
元請けとエンドユーザーの間で品質の見解が割れやすい案件
大規模改修で、既存仕様の理解が属人化している案件

第三者検証の本質は工数の肩代わりではなく、開発当事者から独立した目で品質を保証できる点にあります。

IV&Vと通常のテスト代行の違い

同じ「外注」でも、独立検証と通常のテスト代行では狙いが異なります。混同すると期待値がずれ、成果の評価もぶれます。

項目	通常のテスト代行	第三者検証（IV&V）
主目的	工数の補完・実行力	独立した立場での品質保証
立ち位置	開発チームの一部として動く	開発から独立して検証する
主な成果	テスト実行とエビデンス	客観的な品質評価と指摘
説明先での効果	実施量の担保	検収・監査での説得力

第三者検証を導入するときは、独立性を担保するための体制づくりが欠かせません。検証チームが開発チームと同じ指揮命令下に入ってしまうと、独立検証の看板だけで実態が伴わなくなります。レビューの指摘を開発側が握りつぶせない報告ルートを、あらかじめ設計しておく必要があります。

コスト面では、第三者検証は通常のテスト代行より単価が高くなる傾向があります。独立した分析や評価に専門性が求められるためです。そのぶん、全工程に一律で使うのではなく、リスクの高い機能や、説明責任の重い関門に絞って投入するのが現実的です。

テストレベルや検証の考え方は、JSTQBが公開するJSTQBのシラバス・用語集で用語の定義を確認しておくと、関係者との認識合わせがスムーズになります。国際的に整合した用語を使うことで、元請けやエンドユーザーとの議論のぶれを抑えられます。

準委任・請負と再委託・秘密保持をどう設計するか

SIerのテスト外注では、契約形態の選択が品質と責任の所在を大きく左右します。準委任と請負のどちらを選ぶか、再委託を認めるか、秘密保持をどう縛るかを、案件の性質に合わせて設計する必要があります。

準委任と請負の使い分け

準委任は「善良な管理者の注意義務」を負い、成果物の完成責任は負いません。一方の請負は仕事の完成に責任を持ち、契約不適合責任が生じます。テスト工程では、どちらが適しているかは委託範囲によって変わります。

契約形態	責任の性質	テスト外注で向く場面
準委任	業務遂行の注意義務	探索的検証や継続的な支援など、範囲が流動的な工程
請負	成果物の完成責任	仕様が固定され、成果物を明確に定義できる工程

たとえば、システムテストの実行支援のように範囲が変わりやすい工程では、準委任のほうが柔軟に対応できます。一方で、特定の帳票機能のテストのように成果物を明確に切り出せる工程なら、請負で完成責任を負ってもらう選択も有効です。案件全体を一律の契約でまとめず、工程ごとに使い分ける発想が重要になります。

仕様が固まらない段階で請負契約を結ぶと、変更のたびに再見積もりと交渉が発生し、かえって品質と納期を圧迫します。契約形態の詳しい判断軸は、テスト外注の契約形態で準委任と請負を選ぶ考え方に整理があります。

再委託・秘密保持で確認すべき点

多重下請けでは、テスト外注先がさらに別会社へ再委託するケースもあります。エンドユーザーとの元請け契約で再委託が制限されている場合、無断の再委託は契約違反になりかねません。次の点を契約前に必ず確認します。

元請け契約で再委託が認められているか、書面承諾が必要か
秘密情報・個人情報の取り扱い範囲と、持ち出し・保管のルール
検証環境やテストデータのアクセス権限を誰まで付与するか
瑕疵・契約不適合が生じた場合の責任分界と是正の手順

秘密保持の縛りは、テスト環境やデータの扱いに直結します。エンドユーザーの本番データを検証に使う場合、マスキングの要否や保管場所の制約が加わることもあります。外注先の作業環境が、元請け契約で求めるセキュリティ水準を満たせるかを、契約前に必ず突き合わせておきます。

契約や再委託の枠組みは、IPAが公開するIPAの情報システム・モデル取引・契約書が参考になります。各開発段階で担うべき責務や契約書のひな型が整理されており、自社の契約書を見直す際の下敷きとして有用です。

元請け・エンドユーザーへの品質説明を外注前提で組み立てる

SIerのPMには、外注したテストの品質をエンドユーザーや元請けに説明する責任が残ります。「外注したから品質はベンダー任せ」では通用しません。むしろ外注前提だからこそ、品質を客観的に説明できる設計が重要になります。

多重下請けでは、品質の説明が層を上がるたびに要約され、粒度が落ちていきます。外注先の詳細な検証結果が、元請けやエンドユーザーに届くころには「テストは完了しました」の一言に丸められてしまうこともあります。これを防ぐには、各層でどの粒度の情報を残すかを、依頼設計の段階で決めておく必要があります。

検収を通すための説明材料をそろえる

エンドユーザーの検収は、SIer案件の最終関門です。合否判定の根拠を、外注先の成果物から逆算してそろえておきます。

テスト計画と実施範囲を、要件とのトレーサビリティで示す
消化率・不具合の検出/収束状況を、推移で可視化する
残存リスクと未実施範囲を、隠さず一覧化する
重大不具合の再発防止策を、対応履歴とともに示す

検収で問われるのは「どれだけテストしたか」ではなく「なぜ出荷して問題ないと言えるか」の説明です。

説明責任を外注先の成果物設計に落とす

品質説明に必要な材料は、外注が始まってから頼んでも間に合いません。依頼時点で「どの報告物を、どの粒度で、いつ出すか」を成果物として定義しておきます。

説明の場面	必要な材料	外注先に依頼する成果物
元請けへの進捗報告	消化率と不具合傾向	週次のテスト状況レポート
エンドユーザー検収	合否判定の根拠	実施結果サマリと残存リスク一覧
監査・品質会議	独立した評価	第三者検証の指摘と是正状況

報告物は「作ること」自体が目的化しがちです。しかし本当に必要なのは、元請けやエンドユーザーの意思決定に使える粒度で情報が届くことです。週次レポートに残存リスクの見通しが書かれていなければ、検収直前に想定外の指摘が噴出します。依頼時に、報告物のフォーマットとサンプルまで合意しておくと、認識のずれを最小化できます。

受入や検収の線引きをさらに詰めたい場合は、受入テストの外注で任せる範囲と最終判断を線引きする方法が具体的な判断材料になります。

SIerのテスト外注でありがちな3つの失敗と回避策

依頼設計の重要性は、失敗事例から逆算すると理解しやすくなります。多重下請けの現場でとくに繰り返される3つの失敗と、その回避策を整理します。

失敗1：責任範囲を決めずに人手だけ増やす

もっとも多いのが、工数が逼迫したときに「とにかく人を入れる」発想で外注を始めるパターンです。責任範囲を決めないまま人員だけ増やすと、外注先は「言われた分だけ実施する」動きになり、品質の主体的な担保が誰の手にも残りません。

回避策：人を入れる前に、テストレベルと成果物の責任分界を合意する
回避策：外注先に「実施」だけでなく「品質の説明材料の作成」まで役割として持たせる

人手不足を人数だけで解こうとすると、責任の空白が生まれ、不具合の流出リスクはむしろ高まります。

失敗2：多重下請けの情報経路を放置する

外注先が下位の層にぶら下がると、仕様変更や不具合情報が正しく届かなくなります。層をまたぐたびに情報が劣化し、外注先は古い仕様のままテストを続けてしまいます。

回避策：仕様・変更情報を届ける正規ルートを1本に定め、層を飛ばす連絡経路を許容する
回避策：重大な変更は、外注先まで直接届いたことを確認する運用にする

失敗3：契約と検収要件のずれを見落とす

準委任で契約したのに成果物の完成を暗黙に期待していたり、再委託の制限を見落として法務指摘を受けたりする失敗も頻発します。契約と現場の期待、そしてエンドユーザーの検収要件がずれていると、終盤で必ず衝突します。

回避策：契約形態と期待する成果物の関係を、依頼時に文書で一致させる
回避策：再委託・秘密保持・検収基準を、元請け契約と照合してから発注する

3つの失敗に共通するのは、いずれも「実行段階の問題」に見えて、実は「設計段階の欠落」が根っこにある点です。テスト実行の途中で発覚するため現場の頑張りで乗り切ろうとしがちですが、そこで消耗しても根本は解決しません。責任・情報・契約という上流の設計に立ち返ることが、遠回りに見えて最短の解決策になります。

これらの失敗は、いずれも「実行が始まる前の設計」で防げるものばかりです。裏を返せば、依頼設計さえ丁寧に行えば、外注は品質向上の強い味方になります。

SIerのテスト外注を成功させる依頼設計チェックリスト

ここまでの論点を、依頼前に確認できるチェックリストにまとめます。多重下請けという文脈を踏まえ、責任・契約・情報連携・品質説明の4領域で抜けを防ぎます。

このチェックリストは、外注を検討し始めた時点で一度ざっと通し、発注の直前にもう一度精査する二段階の使い方が有効です。最初の通しで埋まらない項目が、そのまま案件のリスクの在りかを示します。埋めきれない項目があるなら、外注を急ぐより先に、その論点を関係者と詰めるべきサインだと捉えてください。

依頼前チェックリスト

責任範囲：テストレベル×担い手×成果物の表を作り、関係者で合意したか
工程の選定：規模・反復性・独立性の観点で、外注する工程を絞ったか
独立検証：第三者検証を使うべき案件か、通常代行で足りるかを判断したか
契約形態：準委任と請負を、委託範囲の流動性に合わせて選んだか
再委託・機密：再委託の可否と秘密保持の縛りを、元請け契約と照合したか
情報連携：仕様変更と不具合情報の正規ルートを1本化したか
品質説明：検収・報告に必要な成果物を、依頼時点で定義したか

このチェックリストの7項目を依頼前に埋められない案件は、外注してから必ずどこかで手戻りが発生します。

依頼設計を回す順番

チェック項目は、次の順番で詰めると手戻りが減ります。

責任範囲の表を作り、関係者で合意する
外注する工程と、独立検証の要否を決める
契約形態・再委託・秘密保持を確定する
情報連携の経路と成果物の定義を固める
品質説明の材料と報告のリズムを設計する

この順番であれば、上流の合意が下流の契約や成果物に一貫して反映されます。逆に契約から入ると、責任範囲が未定のまま条項だけが固まり、後で辻褄が合わなくなります。

外注先を選ぶときに確認する観点

SIer案件では、外注先の「テスト実行力」だけを見て選ぶと後悔します。多重下請けの文脈に対応できるか、品質を説明する成果物を出せるかまで含めて評価します。

評価軸	確認すること	望ましい状態
大規模対応力	大量ケースの量産・進捗管理の実績	大規模結合・システムテストの経験がある
独立検証の姿勢	開発から独立した指摘ができるか	忖度なく品質リスクを報告する体制がある
成果物の質	検収・報告に使える文書を出せるか	サンプルレポートを事前提示できる
契約の柔軟性	準委任・請負を工程で使い分けられるか	範囲変更に交渉なく対応できる
情報統制	秘密保持・再委託の管理体制	元請け契約のセキュリティ水準を満たす

外注先は「速く安く実施できるか」ではなく「品質を説明できる成果物まで出せるか」で選ぶと、検収での手戻りが減ります。

見積もりを複数社で比べるときは、金額だけで並べず、この評価軸を加えた総合判断にすると失敗を避けやすくなります。安さだけで選ぶと、後から成果物の不足を自社で埋める羽目になり、結果的に高くつくことも珍しくありません。

まとめ：SIer特有の文脈に合わせた依頼設計が品質を守る

SIerのテスト外注は、汎用のテスト代行のノウハウだけでは乗り切れません。多重下請け構造、三者以上の関係、厳しい検収、再委託や秘密保持の制約という業界固有の事情が、依頼設計の随所に影響するからです。

責任範囲はテストレベル×担い手×成果物の表で固定する
外注は規模・反復性・独立性のそろう工程に集中させる
独立性が価値を生む案件では第三者検証を活用する
契約形態・再委託・秘密保持を案件の性質に合わせて設計する
検収・報告に必要な成果物を依頼時点で定義する

言い換えれば、外注は「丸投げ」ではなく「設計」です。SIerのPMが担うべき仕事は、テストを外に出して手を離すことではなく、多重下請けの構造を踏まえて責任と情報の流れを設計し、品質を説明できる状態を保つことにあります。この設計さえ握っていれば、外注はリソースの穴埋めを超えて、品質保証の実効性を高める手段になります。

品質を担保する鍵は、外注先の実行力そのものより、SIer特有の文脈に合わせて組んだ依頼設計の側にあります。

自社案件の多重下請け構造や検収要件を踏まえたテスト外注の進め方に迷ったときは、テスト体制の見直しについて相談することで、依頼設計の論点を一緒に整理できます。まずは責任範囲の表づくりから着手し、外注を品質の説明責任まで含めて設計してみてください。