受託開発のQA委託｜体制設計と依頼範囲の決め方

2026 7/29

2026年7月29日

外注する、とは決めた。あとはお願いするだけ——そう思って動き出した瞬間に、次の壁が立ちはだかります。「どこまで任せればいいのか」「継続で頼むのか、案件ごとに頼むのか」「クライアントの仕様を外の会社に見せて大丈夫なのか」。

判断そのものは済んでいるのに、具体的な進め方の解像度が上がらない。これは珍しいことではありません。多くの記事が「外注すべきか否か」で終わってしまい、決めた後の設計図を示してくれないからです。

この記事では、受託開発のQA委託を決めたPMが、明日から段取りを組めるようになることをゴールに置きます。委託に向く範囲の切り分けから、体制設計、依頼範囲の決め方、そして受託開発ならではの三者関係の注意点まで、実務の順序で解説します。

受託開発のQA委託は「作る」ではなく「任せる」設計から始める

社内にQAチームを立ち上げる話と、QAを外部に委託する話は、似ているようで設計の起点がまったく異なります。前者は採用・育成・評価という「組織づくり」が中心です。後者は役割分担と情報の受け渡しをどう設計するかという「協業のしくみづくり」が中心になります。

ここを取り違えると、委託先に丸投げして品質が落ちるか、逆に細かく指示しすぎて自社の工数が減らない、という両極端に陥ります。受託開発のQA委託でまず固めるべきは、次の3点です。

範囲：どのテスト業務を任せ、どこは自社に残すか
体制：継続的に委託するか、案件単位のスポットで委託するか
関係：自社・委託先・エンドクライアントの三者で情報と責任をどう扱うか

この3点が曖昧なまま見積もりだけを取ると、金額の比較しかできず、結局「安いところ」で決めてしまいがちです。設計を先に描くことで、見積もりの前提そのものを揃えられます。

丸投げが失敗しやすいのは、委託先が「何を品質のゴールとするか」を共有されないまま作業に入るからです。たとえば「一通り触ってバグを出してほしい」とだけ伝えると、委託先は網羅の基準を持てず、重要機能とささいな画面に同じ工数をかけてしまいます。逆に、対象・観点・優先度を渡せば、限られた工数を効くところへ集中できます。委託の質は、指示の細かさではなく前提共有の質で決まると考えてください。

なお、そもそも内製と外注のどちらが自社に合うかを迷っている段階であれば、判断の物差しから整理したほうが近道です。委託を選ぶ前提の比較検討は、テストの内製と外注を比較して自社の判断軸を整えるで詳しく扱っています。本記事は「委託を選んだ後」に焦点を絞ります。

QA委託に向く範囲・向かない範囲を切り分ける

すべてのテスト業務が委託に向くわけではありません。委託先が力を発揮しやすい領域と、自社に残したほうがよい領域を先に線引きします。この切り分けを飛ばすと、任せるべきでない意思決定まで外に出してしまい、責任の所在が濁ります。

判断の目安は、「作業の再現性が高いほど委託に向き、事業判断が絡むほど自社に残す」という軸です。下表は代表的な業務の向き不向きを整理したものです。

テスト業務	委託のしやすさ	補足
機能テストの実行	◎ 向く	手順が明確で成果が測りやすい
回帰テスト	◎ 向く	反復作業で自動化とも相性が良い
テスト設計・観点の洗い出し	○ 条件付きで向く	仕様共有が前提。丸投げは不可
探索的テスト	○ 条件付きで向く	委託先の力量差が大きく事前確認が要る
受入テストの合否判断	× 自社に残す	検収の最終責任は元請けが負う
リリース可否の意思決定	× 自社に残す	事業・契約リスクを伴う判断のため

ポイントは、委託しにくい業務を委託先の外に置くこと自体は失敗ではないという点です。むしろ「実行はすべて任せ、判断は自社が握る」という分担が明確なほど、委託はうまく回ります。向く範囲を見極めるうえでは、依頼前に何を渡し何を決めておくかという準備が品質を大きく左右します。

判断を自社に残す理由は、責任の連鎖にあります。受入テストの合否やリリース可否は、そのままクライアントへの納品判断につながります。ここを外部に委ねると、問題が起きたときに「委託先がよいと言った」という説明しかできず、元請けとしての責任を果たせません。実行は任せても、ゴーサインは自社が出す。この線引きが、委託を安全に使うための土台になります。

表で「条件付きで向く」とした探索的テストやテスト設計は、委託先の力量差が結果に直結します。手順が決まった機能テストと違い、これらは仕様の理解度と経験がものを言うためです。委託する場合は、過去の実績や小さな試行で力量を確かめ、最初は自社のレビューを厚めに入れると安全です。慣れてきたら任せる範囲を広げていく、という段階的な移譲が現実的でしょう。

委託の体制設計｜継続委託とスポット委託を選ぶ

範囲が見えたら、次は「どういう頼み方をするか」です。QA委託の体制は、大きく継続委託とスポット委託に分かれます。どちらが優れているというより、案件の性質と自社の状況で選ぶものです。

継続委託とスポット委託の比較

観点	継続委託	スポット委託
向く案件	長期保守・定期リリースがある案件	単発リリース・繁忙期の一時対応
コスト構造	月額・固定に近く予算化しやすい	都度見積もりで変動しやすい
立ち上げ負荷	初回のみ高く2回目以降は軽い	依頼のたびに説明コストが発生
ナレッジ蓄積	委託先に案件知識が溜まる	溜まりにくく引き継ぎが要る
品質の安定度	高い（同じ担当が継続）	案件ごとにばらつきやすい

継続委託の最大の利点は、委託先に案件知識が蓄積し、回を重ねるごとにテストの精度と速度が上がることです。一方で、稼働が少ない月も費用が発生するため、リリース頻度が読めない案件では過剰投資になりかねません。

コスト感をつかむ試算例

具体的な金額は委託先や難易度で大きく変わります。ここでは考え方の枠組みだけを、仮の試算例として示します。数字は実在の相場ではなく、比較の型を示すための例だと捉えてください。

スポット委託の例：単発リリースで一定量のテストを依頼する場合、都度見積もりのため1人日あたりの単価は高めになりやすい
継続委託の例：毎月ほぼ一定量のテストが発生するなら、月額に近い形で1人日あたりの単価を抑えやすい
切り替えの目安：スポットを年に何度も繰り返すなら、合算した費用と依頼のたびの管理工数から、継続委託の検討余地が生まれる

比較で外しがちなのが、単価に表れない間接コストです。スポットは依頼のたびに仕様説明と立ち上げの時間がかかり、その分だけ自社のPMの手も取られます。単価の安さだけでなく、こうした見えにくいコストまで含めて総額で比べると、判断を誤りにくくなります。

自社の状況から選ぶ判断ステップ

体制選びで迷ったら、次の順で考えると整理しやすくなります。

STEP1：向こう半年のリリース予定を洗い出し、テスト需要が定期的か単発かを見る
STEP2：定期的なら継続委託、単発中心ならスポット委託を第一候補にする
STEP3：予算の組み方（固定費で持てるか、案件原価に載せるか）と照らし合わせる
STEP4：まずスポットで小さく試し、相性を確認してから継続へ移行する道も検討する

いきなり継続委託で大きく契約するより、小さなスポット委託で委託先の実力と連携のしやすさを確かめるほうが、失敗したときの傷が浅く済みます。相性が確認できてから継続へ切り替えれば、立ち上げの学習コストも一度で済みます。

体制を選ぶうえで見落としがちなのが、初回の立ち上げ負荷です。どちらの体制でも、最初は仕様説明・環境準備・分担のすり合わせに一定の時間がかかります。継続委託ならこの負荷は初回だけで済みますが、スポットを繰り返すと毎回発生します。回数が増えるほど立ち上げの手間が積み上がる点は、頭に入れておきましょう。

なお、継続かスポットかという頼み方は、契約形態（準委任か請負か）の選択とも密接に関わります。責任範囲の設計に直結する論点なので、準委任と請負のどちらが自社の委託に合うかを見極めるとあわせて検討してください。

依頼範囲の切り分け方｜どこまで任せるかを言語化する

「向く範囲」を業務種別で線引きしたら、次は個別案件で「今回はどこからどこまでを任せるか」を具体的に言語化します。ここが曖昧だと、委託先は「言われていないから」とテストせず、自社は「当然やってくれると思った」とすれ違います。抜け漏れの多くは、実力不足ではなく範囲定義の甘さから生まれます。

依頼範囲を決める4つの軸

範囲を切り分けるときは、次の4軸で明文化すると漏れが減ります。

対象範囲：どの機能・画面・APIをテスト対象にするか、対象外はどこか
テストレベル：単体・結合・システム・受入のどこを担当してもらうか
成果物：テストケース・実施結果・バグ票・報告書のどれを納品物とするか
判断権限：バグの起票までか、優先度づけや再テストの判断まで含むか

とくに見落とされやすいのが「対象外」の明示です。やることリストだけでなく「やらないこと」を書面に残すと、後からの認識ずれを大きく減らせます。

依頼範囲を書き出すミニ表の例

初回の擦り合わせでは、次のような表を1枚用意しておくと会話がぶれません。

項目	委託先の担当	自社の担当
テスト設計	委託先が原案作成	自社がレビュー・承認
テスト実行	委託先が全実行	自社は立ち会わない
バグ起票	委託先が起票	自社が受領・確認
優先度判断	委託先が一次案を提示	自社が最終決定
再テスト	委託先が実施	自社が完了を確認

この表を委託先と一緒に埋めるだけで、責任の空白地帯が可視化されます。空欄が残る行があれば、そこが将来のトラブル候補です。依頼から納品までの一連の流れをイメージしながら、委託開始前に必ず埋め切ってください。

実務でとくに揉めやすいのが、バグ修正後の再テストの担当です。委託先は「起票までが自分の仕事」と考え、自社は「直したら再確認までやってくれる」と思い込む。この認識のずれが、リリース直前の押し付け合いを生みます。再テストの範囲・回数・完了の条件まで、最初に分担表へ書き込んでおきましょう。

もう一つ見落とされるのが、対象環境と使用データの取り決めです。どの環境でテストするのか、どのアカウントやデータを使うのかが曖昧だと、委託先は手を止めて確認するたびに待ち時間が生まれます。環境とデータの準備は自社の責任範囲として、着手前に整えておくとスムーズに進みます。

範囲は、あとから増えることも前提にしておきます。テスト中に新しい観点や不具合の傾向が見えれば、当初の範囲を広げる判断が要る場面が出てきます。そのとき慌てないよう、範囲変更の相談窓口と追加費用の扱いを最初に決めておくとよいでしょう。範囲は固定するものではなく、合意のうえで動かせるようにしておくのが実務的です。

受託開発ならではの三者関係で注意すべきこと

ここが、受託開発におけるQA委託が自社プロダクトのQA委託と決定的に異なる点です。自社サービスなら「自社」と「委託先」の二者ですが、受託開発ではエンドクライアントが加わり、自社・QA委託先・エンドクライアントの三者関係になります。この構造を意識しないと、情報共有・責任・秘密保持のいずれかで足をすくわれます。二者なら社内で完結する判断も、三者では契約とクライアントへの説明という一手間を挟みます。この差を軽く見ると、テストの品質そのものは問題なくてもトラブルに発展しかねません。

三者の責任範囲を整理する

まず、バグや障害が起きたとき誰が何に責任を負うのかを整理します。下表は典型的な分担の例です。実際の分担は契約で定めますが、初期の共通認識として役立ちます。

局面	自社（元請け）	QA委託先	エンドクライアント
仕様の提供	委託先へ正確に伝達する	受領し不明点を確認する	元請けへ要件を提示する
テスト設計の妥当性	最終レビューし承認する	原案を設計する	関与しない
バグ検出漏れ	検収責任を負う	契約範囲内で品質を担保する	検収で最終確認する
本番障害の対応	一次窓口として対応する	原因調査を支援する	影響を報告し復旧を待つ
クライアント報告	報告主体となる	元請け経由で情報提供する	報告を受ける立場

重要なのは、エンドクライアントに対する最終責任は、原則として元請けである自社が負うという点です。委託先に検出漏れがあっても、クライアントから見れば「発注先＝自社」の品質問題です。この前提を忘れると、委託先へ責任を転嫁する構図になり、関係が壊れます。

情報共有と秘密保持の落とし穴

三者関係で最も見落とされるのが、クライアントの機密情報の扱いです。テストには仕様書・画面・時に実データが必要ですが、それらはクライアントの資産です。これを勝手に第三者へ渡すと、契約違反になりかねません。

再委託の可否：クライアントとの契約に再委託を制限する条項がないかを確認する
秘密保持（NDA）：委託先とNDAを結び、クライアントとのNDA条件と矛盾しないようにする
開示の要否：QAを外部委託する旨をクライアントへ開示・承諾を得るべきか確認する
データの扱い：本番データを渡さず、マスキングやテストデータで代替できないか検討する

とくに再委託条項の見落としは深刻です。契約上クライアントの承諾なく再委託できないのに、黙ってQAを外注していた——これが後で発覚すると、案件全体の信頼を失います。委託を決めた段階で、必ず自社とクライアントの契約書を読み返してください。

よくある失敗例をひとつ挙げます。ある受託案件で、納期を優先してQAを急いで外注したものの、クライアント契約に再委託の事前承諾条項があることに気づかないまま進めてしまいました。リリース後に委託先の関与が発覚し、品質そのものより「聞いていない」という不信が問題化したのです。技術的な失敗ではなく、契約と説明の手順を飛ばしたことが原因でした。

データの扱いも同じ発想で慎重に進めます。テストに本番データが必要に見えても、多くの場合はマスキングやテストデータで代替できます。個人情報や機密性の高いデータを外部へ渡すほど、管理の負担と漏えいのリスクは増します。渡さずに済む方法を先に検討し、どうしても必要な場合はクライアントの承諾と取り扱いルールをセットで決めてください。

報告はワンボイスに揃える

三者関係で信頼を守る要は、クライアントへの報告を自社に一本化することです。委託先が良かれと思ってクライアントへ直接連絡すると、元請けが把握していない情報が先に伝わり、話がねじれます。窓口は自社に集約し、委託先からの報告はいったん自社が受け止めてから、必要な内容だけを整理してクライアントへ伝えます。

このワンボイスの原則は、悪い知らせほど効いてきます。重大なバグや遅延が見つかったとき、誰がいつ何を伝えるかが決まっていないと、報告が遅れたり食い違ったりします。自社が要約と判断を担い、委託先は事実と一次情報を提供する。この役割を最初に共有しておけば、いざというときも足並みが揃います。

情報格差を埋めるフェーズを設計する

テスト代行の現場では、開発の経緯や裏仕様が自然には伝わらない、という情報格差が繰り返し問題になります。ある案件の振り返りでも、アプリの全体像を把握しないまま作業を始めた結果、無駄な操作が増えて時間を浪費した、という教訓が共有されました。

対策はシンプルです。最初に全体像を共有する時間を惜しまないこと。一見遠回りに見えても、全員で同じ画面を見ながら仕様の背景を伝える時間が、後工程の精度と速度を押し上げます。三者関係では、この情報の受け渡し役を自社（元請け）が担うことを忘れないでください。委託先とクライアントは直接つながっていないのが原則だからです。

具体的には、キックオフでシステムの全体像と主要な業務フローを、一度通しで説明する時間を設けます。画面遷移の背景や、過去に不具合が起きた箇所も共有しておくと、委託先はどこを重点的に見るべきか判断できます。この最初の共有が薄いと、テストが表面的な動作確認にとどまり、肝心の欠陥を見逃す原因になります。急がば回れで、理解のための投資が結局は総時間を縮めます。

委託先との日々の連携で品質を保つ具体策は、テスト代行との連携で品質を保つコツを押さえるでも掘り下げています。

継続委託のマネジメント｜品質を可視化しレポーティングする

委託を始めたら終わり、ではありません。とくに継続委託では、品質が見えないままブラックボックス化するのが最大のリスクです。自社が品質を説明できなくなると、クライアントへの報告も曖昧になり、信頼が揺らぎます。マネジメントの要は「品質の可視化」です。

追うべき指標を絞る

指標は多ければよいものではありません。PMがクライアントや上長に説明できる粒度で、少数に絞ります。ソフトウェアの品質特性は国際規格でも体系化されており、たとえばIPAが公開する資料でも品質を多面的に捉える考え方が示されています（IPA 情報処理推進機構）。まずは次のような基本指標から始めると扱いやすいでしょう。

指標	見るもの	活用の仕方
バグ検出件数	期間ごとの検出数の推移	収束傾向でリリース判断の材料にする
バグ再現率	起票バグが再現できた割合	低ければバグ票の質を改善する
テスト消化率	計画に対する実施済みの割合	進捗の遅れを早期に検知する
重大度別内訳	致命・重大・軽微の分布	致命バグの偏りから弱点を特定する

用語や重大度の定義がぶれると、指標そのものが意味を失います。委託先と定義を揃えるうえでは、JSTQBが公開する用語集など、共通の物差しを参照すると認識合わせがスムーズです。

指標は最初から完璧に揃える必要はありません。まずはバグ検出件数とテスト消化率の2つだけでも、案件の状況は十分に見えてきます。運用しながら「この案件では重大度の偏りが問題になりやすい」と分かれば、そこで内訳を足せばよいのです。数を増やすより、少数を毎回同じ定義で追い続けることのほうが、変化に気づく力を育てます。

レポーティングの型を決める

可視化の効果は、定期的に同じ型で報告されて初めて生まれます。継続委託では、次の運用を最初に取り決めておきます。

頻度：週次でサマリ、リリース前に総括、という2層で回す
形式：毎回同じフォーマットにし、前回との差分を追えるようにする
報告経路：委託先→自社→クライアントの順で、自社が要約して伝える
アラート基準：致命バグ発生や消化率の大幅遅延は即時共有とする

同じ形式で継続的に報告されるからこそ、品質の変化に気づけるのです。毎回バラバラな報告では、数字が並んでいても傾向が読めません。

レポートを出すだけで終わらせず、月に一度は委託先と短い定例を持つことをおすすめします。数字の背景、つまりなぜバグが偏ったのか、どの機能が不安定なのかは、対話でしか拾えないことが多いためです。指標は良くても現場の肌感覚では不安が残る、というギャップも、この場で早めに解消できます。

あわせて、致命的な問題が起きたときの連絡先と初動を、あらかじめ一枚にまとめておきます。エスカレーションの経路が決まっていれば、いざというとき自社が慌てず、クライアントへ落ち着いて状況を説明できます。三者関係では、自社が情報のハブになる場面が必ず訪れるからです。

こうした品質の可視化は、上長やクライアントへ費用対効果を説明する際の材料にもなります。委託の投資対効果を社内で通す進め方は費用対効果を上長に説明し稟議を通す方法を知るが参考になります。

受託開発のQA委託を始める前の最終チェックリスト

ここまでの内容を、着手前に確認できる形にまとめます。委託の成否は、契約書にサインする前の準備でほぼ決まります。次のリストに一つでも「未定」が残るなら、そこを埋めてから発注してください。

範囲：委託する業務と自社に残す判断を線引きし、対象外も明記したか
体制：継続委託かスポット委託かを、リリース頻度と予算から選んだか
依頼範囲：担当分担表を委託先と埋め、空欄をゼロにしたか
契約確認：クライアント契約の再委託条項とNDAを読み返したか
情報共有：全体像を伝えるフェーズを工程に組み込んだか
可視化：追う指標とレポーティングの型を先に決めたか

このチェックリストが埋まっていれば、委託先選定の面談でも的確な質問ができ、見積もりの前提も揃います。逆に、ここを飛ばして金額だけで選ぶと、安く始めても手戻りで高くつきがちです。

自社内にQAを「作る」道と比較検討したい場合は、ゼロから体制を立ち上げた実例をまとめた受託開発会社がQAチームを立ち上げた過程を読むもあわせてご覧ください。作る場合と任せる場合の違いが、判断の助けになるはずです。

よくある質問｜QA委託でつまずきやすい点

最後に、委託を検討するPMからよく挙がる疑問を整理します。着手前の判断材料にしてください。

Q. 小さな案件でもQAを委託する意味はありますか。 A. あります。規模が小さくても、兼任のエンジニアがテストに割いていた時間を開発へ戻せる効果は大きいものです。まずはスポット委託で一部の機能だけを任せ、効果を確かめてから広げる進め方が現実的です。

Q. 委託するとテストのノウハウが社内に残らないのでは。 A. 残せます。レポーティングと定例を通じて、テスト観点や不具合の傾向を自社へ還元する設計にすればよいのです。丸投げにせず、テスト設計のレビューを自社が担うことが、ノウハウを社内に留める鍵になります。

Q. クライアントにQAの外部委託を伝えるべきですか。 A. 契約の再委託条項によります。事前承諾が必要な契約であれば必ず確認し、承諾を得てから進めます。伝えること自体がリスクなのではなく、黙って進めて後から発覚することがリスクです。

Q. 継続委託とスポット委託は途中で切り替えられますか。 A. 切り替えられます。むしろスポットで相性を確かめてから継続へ移るのが定石です。逆に、稼働が減った継続契約をスポットへ戻す見直しも、定期的に行うとよいでしょう。

Q. 委託先が出したバグ票の質が低いときはどうすればよいですか。 A. まずは再現率という指標で状況を可視化し、事実ベースで擦り合わせます。バグ票のテンプレートや必要項目を自社から提示すると、質は短期間で揃っていきます。責める前に、伝わる形式を渡すことが先決です。

委託は一度決めて終わりではなく、案件の状況に合わせて頻度も範囲も調整していくものです。疑問が出るたびに委託先と対話し、分担と型を更新し続けることが、長く安定した協業につながります。

まとめ｜設計してから任せれば委託は武器になる

受託開発のQA委託は、丸投げではなく設計です。委託に向く範囲を切り分け、継続かスポットかの体制を選び、依頼範囲を担当分担表で言語化する。そして受託開発特有の三者関係では、責任の所在・秘密保持・情報共有を先に整える。継続委託では品質を可視化し、同じ型で報告し続ける。この順序を踏めば、委託は品質と納期を守る武器になります。

委託は「作る」ではなく「任せる」設計から始める
判断は自社に残し、再現性の高い実行を任せる
三者関係では最終責任が元請けにあることを忘れない
品質は可視化し、継続的に同じ型で報告する

一度この型が決まれば、次の案件からは同じ設計を土台にでき、依頼のたびにゼロから悩む必要はなくなります。自社の案件でどこまでを委託し、どこを残すべきか整理しきれないときは、専門の視点を交えて考えると論点が早く定まります。テスト体制の見直しやQA委託の進め方を検討されている方は、現状の課題整理から相談するところから始めてみてください。設計図さえ描ければ、委託は確かな戦力になります。