テスト設計の委託｜実行は内製・設計だけ任せる判断

2026 7/31

2026年7月31日

テストがいつもリリース直前に間に合わない。エンジニアが実装と兼任でテストを回すため、どうしても観点が抜ける。かといって専任のテスト担当を採用できる規模でもない——受託開発の現場で、こうした状態が慢性化しているPMは少なくありません。

多くの場合、最初に検討されるのは「テスト実行の外注」です。手が足りないのだから、人手のかかる実行部分を外に出そう、という発想は自然です。

ですが、テストの品質を左右しているのは、実行の量ではなく設計の質であることがほとんどです。どれだけ手を動かしても、そもそも検証すべき観点が抜けていれば、そこは永遠にテストされません。

そこで本記事では、実行は内製に残したまま、上流の設計だけを外に出す「テスト設計の委託」という選択肢を、受託開発のPMの視点で整理します。向く／向かないケース、渡すものと返る成果物の見極め方、内製実行との連携、契約形態と費用感まで、発注判断に必要な論点を順に見ていきます。

なお本記事は、境界値分析や同値分割といった技法の「やり方」そのものには踏み込みません。あくまでPMが委託の可否を判断し、依頼を設計し、成果物を見極めるための実務に絞ります。

抜け漏れは「実行」より「設計」で決まる

テストが甘い、という自覚があるとき、多くの現場はまず「テストの数を増やそう」とします。ケースを追加し、実行の回数を増やす。ですが、それで網羅性が上がるとは限りません。

テストは大きく、「何を確認するかを決める工程（設計）」と「決めたことを実際に動かして確かめる工程（実行）」に分かれます。実行はあくまで、設計で決めた範囲を確かめる作業です。

設計の段階で観点が抜けていれば、実行をいくら丁寧にやってもその抜けは埋まりません。存在しないケースは、実行しようがないからです。

例えば、ある入力項目の「正常な値」ばかりを厚くテストしても、「異常な値」「境界の値」「項目同士の組み合わせ」という観点が設計に入っていなければ、そこは検証されないまま出荷されます。バグは、たいていこの「入っていなかった観点」から出ます。

設計が上流工程として品質全体に効くことは、ソフトウェア開発のデータからも裏付けられます。工程ごとの品質・工数の傾向はIPA ソフトウェア開発分析データ集にまとまっており、上流の設計の巧拙が後工程の手戻りに響くことが読み取れます。だからこそ、設計の質を底上げする打ち手には投資対効果があります。

実行を増やしても網羅性は上がらない

ここで押さえたいのは、実行と網羅性は別物だという点です。

実行を増やす＝すでに決まった観点を、繰り返し・多環境で確かめること
網羅性を上げる＝そもそも確認すべき観点そのものを増やすこと

前者は再現性やリグレッション（後退）の担保には効きますが、抜けている観点を発見してはくれません。後者は設計工程の仕事です。

つまり、抜け漏れに悩んでいる現場が本当に強化すべきなのは、実行の物量ではなく設計の質だということになります。

ただし、ここには重要な但し書きがあります。設計は網羅性の「上限」を規定し、実行の品質が「下限」を規定します。つまり、設計をどれだけ精緻にしても、実行側がケースの記載を守らず、環境整備も甘ければ、不具合の流出は防げません。設計を委託しても、実行するメンバーが手順・前提を丁寧になぞり、テスト環境を整えることが前提になります。「設計だけ外に出せば品質が上がる」という話ではなく、内製の実行品質とセットで初めて効く、という点は最初に押さえておいてください。

設計は高スキルの工程である

やっかいなのは、この設計工程が「経験と観点の引き出し」に大きく依存する、高スキルの作業だという点です。

仕様書を読み、どこにリスクが潜むかを想像し、適切な技法を選んでケースに落とす。この一連は、テストの経験を積んだ人ほど精度が上がります。兼任のエンジニアが実装の合間に片手間でこなすには、本来かなり負荷の高い工程なのです。

観点の洗い出しやテスト技法の選び方そのものについては、テスト観点の洗い出し方を解説した記事や同値分割・境界値分析の使い分けを整理した記事で詳しく扱っています。本記事では、この高スキルな設計工程を「誰が担うか」という体制の話に絞って進めます。

テスト設計の委託という選択肢（実行は内製に残す）

テスト実行の外注とテスト設計の委託で、設計と実行のどちらを外に出しどちらを自社に残すかが逆になることを示す上下2レーンの対比図

ここまでを踏まえると、一つの選択肢が見えてきます。負荷が高く、かつ品質を左右する設計工程だけを外部の専門家に任せ、実行は自社に残す。これがテスト設計の委託という考え方です。実行の外注が「手を借りる」発想なら、こちらは「頭を借りる」発想だと言えます。

一般的な「テスト実行の外注」とは、切り出す工程が逆になります。両者の違いを整理すると次のようになります。

観点	テスト実行の外注	テスト設計の委託
外に出す工程	ケースを動かす実行部分	観点洗い出し・ケース作成の設計部分
自社に残る工程	設計・観点の判断	実行・進捗の主導権
主に解決する課題	実行の人手不足	観点の抜け漏れ・設計スキル不足
向く状況	何を確認するかは決まっている	何を確認すべきかに自信がない

なぜ設計だけを外に出すのか

設計だけを切り出す理由は、現場の事情と結びついています。よくあるのは次のようなケースです。

テスト設計をできる人が社内にいない、または一人に集中している
エンジニアが兼任のため、腰を据えて観点を洗い出す時間が取れない
新規のドメインや技術で、どこにリスクがあるか自社では読み切れない

いずれも「実行する体力はあるが、設計の質に不安がある」状態です。ここに外部の設計スキルを注入するのが、設計の委託の狙いです。

実行の主導権は自社に残る

設計を外に出すことへの抵抗として、「テストの主導権を握られるのでは」という懸念があります。ですが、設計だけの委託であれば、それは起きにくい構造です。

設計を外注しても、実行するのは自社のメンバーなので、進捗の把握もスケジュールの調整も自社の手の内に残ります。プロダクトの中身を最もよく知る自社が実行を握ることには、品質面でも大きな意味があります。

工程ごとに内製と外注をどう切り分けるかは、テスト工程を工程別に切り分ける考え方の記事で体系的に整理しています。また、内製と外注それぞれの得失を天秤にかけたい場合は、内製と外注の判断軸を整理した観点もあわせて押さえておくと、社内での意思決定がスムーズになります。

設計だけの委託が向くケース・向かないケース

設計だけの委託は万能ではありません。効果が出やすい状況と、そうでない状況があります。発注前に、自社がどちらに近いかを見極めておくことが大切です。

まず、向くケースと向かないケースを対比で整理します。

判断軸	向くケース	向かないケース
実行体制	実行するメンバーは社内にいる	実行する人手もそもそも足りない
設計スキル	設計の観点出しに自信がない	設計も実行も両方任せたい
対象領域	新規領域で観点の勘所がつかめない	固定成果物の請負には仕様が流動的すぎる
ドメイン共有	仕様やリスクを言語化して渡せる	ドメインが特殊すぎて共有に膨大な工数がかかる
目的	設計を標準化・資産化したい	一度きりで再利用の予定がない

向くケースの特徴

設計の委託が最も効くのは、「実行する体制はあるが、何を確認すべきかの設計が弱い」という状態です。

具体的には、次のような状況が該当します。

実行担当は確保できているが、観点の洗い出しに抜けが多い
新しい業務ドメインで、経験者ならではのリスクの勘所が欲しい
属人的になっているテスト設計を、外部の型を借りて標準化したい

たとえば、複数案件を並行して回し、テストを実装担当が兼任している——そんな現場では、設計に腰を据える時間がまとまって取れません。ここで観点出しやケース作成だけをスポットで外に出せると、実行は自社で回しつつ設計の穴だけを埋められます。工程単位・スポットで受ける委託先もあるため、設計だけの小口発注は必ずしも机上論ではありません。

特に3つ目の「標準化」は見落とされがちですが、外部の設計者が作ったテスト観点一覧やテスト設計書は、そのまま社内の資産になります。次回以降の設計の土台として再利用できる点は、単発の実行外注にはないメリットです。

向かないケースと、迷ったときの問い

一方、仕様がまだ固まっていない段階での委託は、慎重に考えたほうがよいケースです。設計は仕様を前提に組み立てるため、土台が動くと成果物も作り直しになりやすいからです。

ただし、これは「絶対に向かない」という話ではありません。テスト設計書一式を固定成果物として納める請負型には不向きですが、観点出しから探索的に伴走する準委任型なら、仕様が動く前提で一緒に設計を育てられ、価値が出る場合もあります。向き・不向きは契約形態の選び方とセットで考えるのが実務的です（契約形態は後段で詳しく扱います）。

また、ドメインが極端に特殊で、前提の共有だけで膨大な工数がかかる場合も、委託の効果は薄れます。

迷ったときは、次の問いを自分に投げてみてください。

「何を確認すべきか」に迷っているのか、「確認する手が足りない」だけなのか
外部に渡せるだけの仕様とリスク情報が、いま手元に揃っているか

前者が「何を確認すべきか」寄りで、後者が「揃っている」なら、設計の委託が向いています。

委託する「設計工程」の中身と、渡すもの・返るもの

自社が渡す仕様書・テスト対象範囲・リスク情報・過去の不具合履歴が委託先へ流れ込み、テスト観点一覧・テストケース・テスト設計書が返ってくる入出力フロー図

「設計を委託する」と言っても、設計工程にはいくつかの段階があります。どこからどこまでを任せるのかを曖昧にすると、期待と成果物がずれます。ここを具体化しておきましょう。

一般的に、テスト設計の工程は次の流れで進みます。

テスト観点の洗い出し（何を確認するかの列挙）
テスト技法の選択（各観点をどう検証するか）
テストケースの作成（具体的な入力・操作・期待結果への落とし込み）
優先度付け（限られた時間でどこを厚くするか）

なお、テストケースの作成をさらに具体化する「テスト実装」——テスト手順・テストデータ・前提条件まで書き下す工程——をどこまで委託範囲に含めるかで、実行側に残る負荷は大きく変わります。手順・データまで作り込んでもらえば実行はなぞるだけで済みますが、その分だけ委託の工数と費用は増えます。委託の際は、この4段階のどこまでを任せるかを合意します。観点出しだけを頼むのか、テスト実装まで一気通貫で頼むのかで、費用も成果物も変わります。

渡すもの（インプット）

良い設計は、良いインプットから生まれます。委託先に渡すべき主な情報は次のとおりです。

渡すもの	目的
仕様書・画面設計	何を作っているかを正確に伝える
テスト対象範囲	今回どこを検証するかの線引き
リスク情報	どこが壊れると影響が大きいか
過去の不具合履歴	過去に問題が出た弱点の共有

特に過去の不具合履歴は、外部の設計者が自社の「弱点」を知るための貴重な情報で、渡すか渡さないかで観点の精度が大きく変わります。

返るもの（アウトプット）

委託の結果として返ってくる成果物は、主に次の3点です。それぞれ役割が違うので、用語の意味を揃えておくと認識のずれを防げます。

テスト観点一覧：確認すべきテスト条件を構造的にまとめたもの（現場では「テスト観点」と呼びますが、JSTQBでいう「テスト条件」に相当します）
テストケース：入力・前提条件・期待結果を具体的な手順まで落とし込んだもの
テスト設計書：どの技法を選び、なぜその優先度で網羅するのか、判断の根拠を記した設計の説明書

理想は、要件→テスト観点→テストケースがたどれる形（トレーサビリティ）で成果物がつながっていることです。要件のどこがどの観点・ケースで確認されるかが追えると、抜けの検知や仕様変更時の追随がしやすくなります。

これらの言葉の標準的な定義は、JSTQBのシラバス・用語集で確認できます。委託先との会話の共通言語として、事前に目を通しておくと安心です。

なお、テストケースを実務でどう作り込むかについては、システムテストのテストケース作成手順を扱った資料を手元に置くと、返ってきた成果物の粒度を評価する際の物差しとして使えます。

テスト設計の委託で成果物を見極める依頼設計

テスト設計の委託で成否を分けるのは、依頼のかけ方です。同じ委託先でも、渡し方が違えば成果物の質は大きく変わります。ここでは、依頼の組み立てと、返ってきた成果物の見極め方を整理します。

その前に一つ、自社の課題が「設計」なのか「実行」なのかを切り分ける簡易チェックを置いておきます。月曜からすぐ確認できる粒度です。

テスト観点一覧やテストケース一覧が、そもそも存在しない → 設計課題（委託の対象になりやすい）
ケースはあるが、時間切れで未消化・環境都合で落ちている → 実行課題（委託より実行体制の増強が先）
ケースはあるのに本番で同種の不具合が出た → 観点の抜け＝設計課題の可能性

上2つ以上が「設計課題」に振れるなら、設計だけの委託を具体的に検討する価値があります。

丸投げしないための依頼設計

最もありがちな失敗が、仕様書だけを渡して「あとはよろしく」と丸投げすることです。外部の設計者は、その業務ドメインの素人からスタートします。前提を共有しなければ、的外れな観点になりかねません。

依頼を組み立てる際は、次の順で情報を渡すのが効果的です。

まずドメイン理解を共有する（何のためのシステムで、誰がどう使うか）
リスクの高い箇所を明示する（ここが壊れると致命的、という優先度）
成果物のフォーマットを事前に合意する（一覧の粒度・項目・記載レベル）

リスクベースで「どこを厚く見てほしいか」を先に伝えるだけで、限られた工数の配分が大きく変わります。すべてを均等に見るのではなく、影響の大きい箇所に設計の力点を置いてもらうわけです。

リスクの見立てをどう作るかは、リスクベースでテスト範囲を絞る考え方の記事が参考になります。依頼前に自社側でリスクを言語化しておくと、委託の精度が一段上がります。

依頼前に何を準備しておくべきかの全体像も、あらかじめ整理しておくと安心です。初めて外部に設計を出す場合は、渡す資料と前提情報のリストを先に棚卸ししておきましょう。

成果物は「数」で測らない

返ってきた成果物を評価するとき、つい「ケースが何件あるか」で見てしまいがちです。ですが、ケース数の多さは質を意味しません。冗長なケースが並んでいるだけかもしれないからです。

見極めるべきは、次の3つの軸です。

網羅性：確認すべき観点が漏れなく拾えているか
保守性：後から読んで理解でき、修正・追加しやすいか
優先度付けの妥当性：厚く見るべき箇所と、軽く済ませる箇所の判断が納得できるか

チェックリストとして手元に置くなら、次の問いが使えます。

リスクの高い箇所に、相応の観点・ケースが割かれているか
観点一覧に、明らかな抜け（異常系・境界・組み合わせ）はないか
実行担当が読んで、意図を取り違えずに動かせる書き方か
過去の不具合と同種の観点が、きちんとカバーされているか

ケース数ではなく「リスクの高い箇所に設計の力点が置かれているか」を評価軸にすることが、良い成果物を見抜く鍵になります。

なお、外注全般で「どこまで自社で準備し、どこから外に頼むか」の線引きに迷う場合は、内製と外注の判断軸を整理しておくと、社内・クライアント説明の材料としても役立ちます。

設計者と実行者が分かれるときの連携設計

設計だけを外に出す構成には、一つ構造上の落とし穴があります。設計する人と実行する人が別になるため、設計者の意図が実行者に伝わらないと、せっかくの設計が形骸化します。

例えば、テストケースに「境界値を確認」とだけ書かれていても、なぜその値が境界なのか、どんな不具合を想定しているのかが伝わらなければ、実行者はただ手順をなぞるだけになります。想定外の挙動に気づく感度も鈍ります。

引き継ぎを左右するのは「読みやすさ」

この断絶を防ぐ最大の要素が、成果物の読みやすさと保守性です。

各ケースが「何を・なぜ確認するか」まで書かれているか
実行者が前提知識なしで読み進められる粒度か
後から仕様変更が入ったとき、どこを直せばいいかが追えるか

設計書やケースが読み手を意識して書かれているほど、設計者と実行者のあいだの溝は浅くなります。逆に、設計者の頭の中だけで完結した成果物は、渡した瞬間に価値が目減りします。

連携で決めておくこと

設計と実行を分けるなら、発注時に次の点を取り決めておくと、後の混乱を防げます。

決めること	内容
質問窓口	実行中の疑問を、誰に・どう聞くか
レビューの持ち方	設計の意図確認をいつ・どの形で行うか
記載の粒度	実行者が迷わない詳しさのレベル
更新の責任	仕様変更時に設計を誰が直すか

委託先を選ぶ際の中立的な基準としては、観点を一緒に洗い出し、設計の意図を実行者へ橋渡しできる相手かどうかを見ることが有効です。単に成果物を納品して終わり、ではなく、設計と実行の間をつなぐ意識がある相手だと、形骸化のリスクが下がります。

実務上おすすめなのは、納品前にキックオフとは別の「引き継ぎミーティング」を1回設けることです。設計者が観点一覧やテスト設計書を画面共有しながら、「なぜこの観点を厚くしたのか」「どの不具合を警戒しているのか」を実行担当に口頭で説明する場を持つと、成果物の文面だけでは伝わらない設計の意図が補完されます。

30分程度の引き継ぎの場を一度挟むだけで、実行フェーズでの手戻りや質問往復が目に見えて減ります。設計を外に出す構成では、この「意図の受け渡し」に少しだけ時間を投資する価値があります。逆に、この場を省くと、実行担当が「書いてある通りに動かしたのに、なぜ指摘されるのか」と迷い、設計者と実行者の間に不信が生まれがちです。

契約形態と費用感、よくある失敗

内製フル・設計委託＋内製実行・全外注の3つの発注形態を、発注コストと社内工数の2軸マップ上に配置し、設計委託＋内製実行が中間の選択肢であることを示すポジショニングマップ

最後に、実際に発注する段になって必要となる、契約形態・費用感・失敗パターンを整理します。ここはPMが上長を説得する際にも問われやすい論点です。

準委任と請負のどちらが合うか

準委任と請負のどちらの契約形態が合うかは、任せ方によって変わります。

契約形態	向く任せ方	特徴
請負	テスト設計書一式を成果物として納品してほしい	成果物と完成責任が明確。範囲が固まっている案件向き
準委任	観点出しから伴走・探索的に進めてほしい	柔軟に相談しながら進められる。範囲が流動的な案件向き

成果物がはっきり定義できるなら請負寄り、探索や伴走の色が濃いなら準委任寄り、と考えると整理しやすくなります。契約形態それぞれのメリット・注意点は、準委任と請負の選び方を解説した記事で詳しく扱っています。

費用対効果は「発注形態」で向きが変わる

費用は「設計する対象の規模」と「任せる工程の範囲」で決まります。観点出しだけなのか、テスト実装まで含むのかで工数が変わり、それが金額に反映されます。

ここで具体的な相場額を断定することは避けます。プロダクトの規模やドメインの複雑さで大きく振れるためです。ただ、金額の絶対値を出せなくても、発注形態ごとに費用対効果の「向き」を比べることはできます。次の相対比較が、上長への説明の土台になります。

比較軸	内製フルで設計・実行	設計だけ委託＋実行は内製	実行含め全外注
発注コストの向き	なし（発注ゼロ）	中（設計工程分のみ）	高（設計＋実行分）
社内工数	高い（全部自社）	中（実行は残る）	低い（ほぼ丸投げ）
設計品質への効き	社内スキル次第で振れる	高い（専門性を注入）	委託先次第で振れる
実行の主導権	自社	自社	委託先寄り
向く状況	設計スキルが社内にある	実行はできるが設計が弱い	実行の人手も足りない

設計のみの委託なら、実行込みの全外注より発注額は下がりますが、内製実行の工数は自社に残ります。つまり「発注コストを抑えつつ、品質を左右する設計だけに外部の専門性を効かせたい」という費用対効果を狙う形です。全外注より安く、内製フルより設計品質が安定しやすい——この中間の選択肢だと捉えると、上長にも説明しやすくなります。

料金がどんな要素で決まるのかの構造や、複数社の見積もりを比較する視点も、発注前に押さえておきたい論点です。工程範囲と成果物の粒度を揃えたうえで比べると、金額の差の意味が読み取りやすくなります。

よくある失敗と回避策

つまずくパターンは、だいたい次の3つに集約されます。

よくある失敗	何が起きるか	回避策
ドメイン未共有の丸投げ	的外れな観点になり作り直し	依頼前にドメイン理解とリスクを共有する
ケース数で成果物を評価	冗長なケースが量産される	網羅性・保守性・優先度で見極める
設計と実行の断絶	意図が伝わらず設計が形骸化	質問窓口とレビューを事前に決める

この3つは、いずれも「発注前の設計」で防げる失敗です。契約を結んでから慌てるのではなく、依頼の組み立て段階で潰しておくことが肝心です。

もう一つ、見落とされがちな失敗として「成果物の受け取り方を決めていない」ケースがあります。テスト観点一覧やテスト設計書が納品されても、それを社内の誰がレビューし、どの基準で合格とするかが曖昧だと、成果物が受領されないまま実行フェーズに突入してしまいます。発注時に、成果物を確認する担当者と、確認の観点（前述の網羅性・保守性・優先度付け）をあらかじめ決めておきましょう。

小さく始めるなら、まずは1機能・1画面といった限定された範囲で設計だけを試しに委託し、成果物の質と自社の実行のかみ合い方を確かめる進め方が現実的です。いきなり全体を任せるより、相性とプロセスを見極めてから範囲を広げるほうが、上長にも説明しやすく、失敗したときの傷も浅く済みます。

まとめ

テスト実行は内製に残し、上流の設計だけを外に出す。これがテスト設計の委託という選択肢でした。抜け漏れは実行の量ではなく設計の質で決まるからこそ、品質を左右する設計工程に外部の専門性を注入する意味があります。ただし設計は網羅性の上限を決めるだけで、実行の品質という下限が伴って初めて流出を防げる、という前提は忘れないでください。

発注の可否を判断するうえで、押さえるべきポイントを3つに絞ると次のとおりです。