テストの内製と外注はどちらが得か｜判断の物差し

「テストは自社でやるべきか、外に出すべきか」。受託開発の現場でPMをしていると、案件が佳境に入るたびにこの問いが頭をよぎるはずです。開発は手一杯、テスト専任を置く余裕もない。かといって外注すればコストがかさむし、うまく連携できるかも不安。そんな板挟みのなかで、結論を先送りにしたまま次のリリースを迎えてしまう。

多くの記事は、この問いに対して「外注すべき」あるいは「内製すべき」と、どちらかへ寄せた答えを出します。しかしテストの外注を扱う記事は外注ありきの結論に傾きがちで、システム開発一般の内製vs外注論はテストに特化していません。テストの内製と外注をめぐる本当の難しさは、「どちらが正しいか」という問いの立て方そのものにあります。

この記事が取るのは、外注ありきでも内製ありきでもない、受託開発PMのための中立で正直な判断フレームです。テストの内製と外注は、二択で語ろうとした瞬間に判断を誤ります。以下では、二択の罠から始めて、内製・外注それぞれの正直な損得、単価でなくTCO（総コスト）で見る考え方、案件を分ける判断軸、そして多くの場合の正解であるハイブリッド運用まで、順を追って整理します。

たとえば、こんな場面を思い浮かべてください。新規案件のキックオフで、上長から「テストはどうする？」と聞かれる。専任はいない、開発メンバーはすでに稼働がいっぱい、外注の見積もりは想定より高い。その場では「まず内製で進めて、厳しければ外注を検討します」と答える——しかし「厳しくなってから」では、もう手を打つ余裕は残っていません。判断を先送りにしないためには、着手前に持てる物差しが要ります。

よくある「なんとなくの決め方」

まず、自分の意思決定が次のようになっていないかをチェックしてみてください。どれも一見もっともらしく見えて、判断を歪める典型パターンです。

• 見積書の単価だけを比べて「外注は高い」と結論している
• 「人が足りないから外注」と、リソース不足を理由に思考停止している
• 逆に「情報を外に出したくないから」と、根拠なく全部を抱え込んでいる
• 過去に一度外注で失敗したから、以降ずっと内製に固定している
• 案件の性質を問わず、いつも同じ方針（全内製か全外注か）を適用している

決め方に一貫した「物差し」がないまま、その場の事情で内製と外注を選んでいるなら、それが最初に直すべき点です。この記事のゴールは、その物差しを持ち帰ってもらうことです。

これらのパターンが根強いのは、どれも短期的には「合理的な理由」に見えるからです。単価が安いほうを選ぶのも、人がいないから外に出すのも、その瞬間の判断としては筋が通っています。問題は、その理由が案件ごとの性質を無視した「一律のルール」になってしまうことです。ある案件で正解だった選択が、別の案件では最悪手になる。だからこそ、その場の事情ではなく、軸で決める習慣が要ります。

内製と外注、それぞれの正直なメリット・デメリット

判断軸を語る前に、内製と外注の素の姿を、良い面も悪い面も揃えて並べておきます。どちらか一方を持ち上げると、それはもう判断フレームではなく宣伝になってしまうからです。

ここで一つ、前提を置いておきます。内製と外注は「優劣」ではなく「向き不向き」の関係にあります。どちらが優れているかを決める勝負ではなく、案件の条件に対してどちらが噛み合うかという相性の問題です。この前提を外すと、途端に「どちらが正義か」という不毛な議論に迷い込みます。

まず全体像を表で対比します。

観点	内製	外注
スピード（着手の速さ）	速い（社内で完結）	立ち上げに時間がかかる
仕様・ドメイン理解	深い（開発と近い）	立ち上げ期はキャッチアップが必要
テストの視点	開発者視点に固定されがち	第三者視点が入りやすい
専門技法・多様性	属人化しやすい	性能・セキュリティ等の専門性を調達しやすい
コスト構造	固定費（人件費）中心	変動費（使った分）中心
繁閑への対応	谷でも人件費は発生	山谷に合わせて増減しやすい
マネジメント負荷	社内で完結	発注・連携のコミュニケーション負荷が増える

この表を見れば、外注が常に正解ということはなく、内製が優位に立つ場面も確実に存在します。以下、それぞれをもう少し掘り下げます。

内製の強みと弱み

内製の最大の強みは、開発チームとの距離の近さです。仕様の背景や過去の障害の経緯を共有しているため、テスト観点の勘どころを外しにくく、着手も速い。テストを通じて得た知見が社内に蓄積され、次の案件に生きるのも大きな利点です。

一方、弱みは主に三つあります。

• 視点が固定されやすい：作った本人が確認すると、思い込みの前提ごと見逃す
• 繁閑に弱い：案件の谷でも人件費は発生し、山では手が足りない
• 専門技法が属人化する：性能・セキュリティなど高度な領域は担い手が限られる

とりわけ「作った人がテストする」体制は、抜け漏れの温床になりがちです。開発者が兼任でテストしている体制では、リリース直前に観点漏れが噴き出し、品質を妥協して出さざるを得ない、という悪循環に陥りやすいのが実情です。

もう一つ見落とされがちなのが、内製は「谷」の時期にコストが見えにくい点です。案件が立て込んでいる時期は人手が足りず、逆に案件の谷では手が空く。しかし人件費は固定でかかり続けるため、繁閑の波が大きい受託開発では、稼働率の低い時期の人件費が静かに利益を圧迫します。内製の安さは、稼働がしっかり埋まっている前提でのみ成り立つ——この条件は押さえておくべきです。

それでも、ドメイン理解の深さは外注では簡単には得られない資産です。長く同じ顧客のシステムを見てきたチームは、「この画面は過去にこういうトラブルがあった」「この顧客はこの操作を必ずする」といった暗黙知を持っています。こうした知識が品質を大きく左右する案件では、内製の強みが際立ちます。内製と外注の比較は、コストだけでなく、この知識資産をどう評価するかでも結論が変わってきます。

外注の強みと弱み

外注の強みは、第三者視点と専門性の調達にあります。開発者とは別の目でテストすることには、公的な裏付けもあります。JSTQBの認定テスト技術者資格のシラバスでは、テストの「独立性」——開発した本人とは別の視点でテストすることの価値——が体系的に位置づけられています。作り手の思い込みから距離を取れることが、外部視点の本質的な効き目です。

実際、社内では「仕様どおり動いている」と全員が信じていた画面が、第三者にさわられた途端、想定外の操作手順であっさり破綻する——というのはよくある話です。作った側は正しい使い方を前提に見てしまうため、その前提の外側は最初から視界に入りません。外部の目は、この「見えていないことに気づけない」という構造的な穴を埋めます。専門性の調達と並んで、ここが外注のもう一つの核心的な価値です。

加えて、性能・セキュリティ・多様なテスト技法といった専門領域を、必要なときだけ調達できる柔軟性も外注の魅力です。コストが変動費になるため、案件の山谷に合わせやすいのも受託開発とは相性が良い点です。

弱みは、コミュニケーションコストと立ち上げの時間です。仕様やドメインのキャッチアップに一定の時間がかかり、発注側にも「何をどう伝えるか」を整える手間が発生します。外注は「丸投げすれば楽になる」ものではなく、任せ方の設計を伴って初めて効果が出ます。この設計を怠ると、期待した品質もスピードも得られません。

任せ方の設計とは、具体的には「何を、どの粒度で、どう伝えるか」を決めることです。テスト観点や過去に出た障害、顧客が特に気にする箇所を最初に共有できれば、キャッチアップは短くなり、外注の第三者視点が早く効き始めます。逆に、仕様書だけ渡して「あとはよろしく」では、立ち上げに時間がかかり、認識合わせの往復でかえってコストが膨らみます。外注の成否は、委託先の質と同じくらい、発注側の準備で決まると考えておくのが安全です。

この準備の負荷は、裏を返せば内製にはないコストでもあります。だからこそ、次に見るTCO（総コスト）では、この「任せるための手間」も外注側のコストにきちんと数え込みます。単価には表れないけれど確かに存在するこのコストを見落とすと、外注を過小評価してしまい、いざ始めてから「思ったより手間がかかる」と後悔することになります。準備コストは、外注を検討する時点で織り込んでおくべき前提だと押さえておいてください。

単価でなくTCO（総コスト）で比べる

内製と外注を比べるとき、多くの判断ミスは「見えている単価」だけで決めてしまうことから生まれます。外注の見積書に並ぶ金額と、社内メンバーの人件費を単純に引き算しても、本当のコストは見えてきません。

判断の軸に据えるべきはTCO、すなわち総コストです。TCOは「見えている単価」だけでなく、その下に隠れたコストまで含めて総額で比べる考え方です。氷山の水面下にこそ、判断を左右する重さがあります。

見えている単価は、氷山の水面上に出た部分にすぎません。水面下には、発注管理やレビューにかかる社内工数、外注先とのキャッチアップにかかる時間、そして最も大きい「見逃した不具合が本番で顕在化したときのコスト」が沈んでいます。これらは見積書には載らないため、意識して数え上げないと比較から抜け落ちます。単価の差が水面上の小競り合いだとすれば、勝敗はたいてい水面下で決まります。

内製と外注、それぞれのTCOの内訳を並べてみます。

コスト項目	内製のTCO	外注のTCO
直接コスト	担当者の人件費	委託費（見積単価）
管理・調整	社内調整・進捗管理	発注管理・仕様伝達・レビュー
立ち上げ	既存メンバーなら小	キャッチアップ期間
教育・維持	スキル育成・採用コスト	（委託側が保有）
繁閑ロス	谷の遊休人件費	変動費のため小
リリース後の障害コスト	見逃し次第で増減	見逃し次第で増減

単価の比較で見落とされがちなのが、リリース後に障害が出たときの手戻りコストです。IPAがかつて公開していたソフトウェア開発分析データ集などの分析でも、不具合は後工程やリリース後に見つかるほど修正の手戻りが大きくなる傾向が繰り返し示されてきました。テスト段階でのコストを削った結果、本番障害という最も高くつくフェーズにコストが移動してしまっては、総額ではむしろ損をします。

つまりTCOで見ると、「単価が安い/高い」だけでなく、「見逃しリスクをどれだけ下げられるか」までを含めて比較する必要があります。この総額の視点は、社内で予算を承認してもらう際の説明軸としても有効です。上長に費用対効果を説明して稟議を通す進め方は、テスト外注の費用対効果を上長に説明する手順を解説した記事で具体的に整理していますので、承認プロセスで壁を感じている方はあわせて確認してください。

一文だけ補足すると、TCOは「安い方を選ぶ道具」ではなく、「同じ土俵で正しく比べる道具」です。安さそのものより、総額でリスクまで含めて釣り合っているかを問うのが本来の使い方です。

具体的に考えてみましょう。ある機能改修で、外注に出すと見積もりが社内対応の人件費の1.5倍だったとします。単価だけ見れば内製が得です。しかし、その機能が決済に関わり、障害が出れば顧客対応と信用の毀損に発展する案件だったらどうでしょう。内製で見逃しが起きたときの想定損失を織り込むと、総額の期待値では外注のほうが安く済むことは珍しくありません。逆に、社内向けの軽微なツールなら、障害コストが小さいぶん内製の単価の安さがそのまま効きます。同じ「1.5倍」でも、案件のリスクの大きさによって結論は逆転します。これがTCOで見るということです。

ここで大事なのは、TCOを厳密に計算し切ることではありません。すべての隠れコストを正確に数値化するのは現実的でないし、その必要もありません。狙いは、単価という一点だけで決めていた判断に、「管理の手間」と「見逃しの損失」という二つの重い項目を加えることです。この二つを意識に入れるだけで、多くの判断は精度が上がります。ざっくりでよいので、総額のイメージを持って比べる。それだけで単価比較の落とし穴はかなり避けられます。

テストの内製と外注を分ける判断軸

ここがこの記事の核心です。この判断は、「案件の性質」と「自社リソース」という二つの軸の掛け合わせで行います。どちらか一方だけを見ると、必ず判断を外します。

判断に使う二つの軸を、それぞれの中身に分解します。

案件の性質を測る観点

• 規模：テスト対象の広さ・ケース数の多さ
• 変更頻度：仕様変更や追加開発がどれだけ頻繁か
• 専門性要求：性能・セキュリティなど高度な技法を要するか
• リスクの高さ：障害が事業や信用に与える影響の大きさ

自社リソースを測る観点

• 人：テストに割ける手が今どれだけあるか
• スキル：必要な技法を社内で持っているか
• 時間：納期までにテストを回しきれる時間があるか

この二軸を組み合わせると、判断はおおまかに次のマトリクスに整理できます。

案件の性質＼自社リソース	リソースに余裕あり	リソースが逼迫
定型・低リスク	内製が向く	内製維持＋一部外注
変更頻繁・中リスク	内製中心＋要所を外注	ハイブリッドで分担
高い専門性・高リスク	専門領域は外注	外注中心＋社内は管理に集中

このマトリクスから、内製が向く場面と外注が向く場面を言語化しておきます。

内製が向く場面

• 仕様の変更頻度が高く、開発とテストが密に往復する必要がある
• ドメイン知識が品質を大きく左右し、外部のキャッチアップコストが重い
• 定型的な確認が中心で、社内に回せる手と時間がある

外注が向く場面

• 性能・セキュリティなど、社内にない専門技法が必要
• 障害の事業インパクトが大きく、第三者視点で見逃しを減らしたい
• 案件の山で一時的にテスト量が跳ね上がり、変動費で吸収したい

注意したいのは、これらは「どちらかに完全に振る」話ではないことです。多くの案件は、内製が向く要素と外注が向く要素の両方を抱えています。だからこそ次の節で扱うハイブリッドが効いてくるのですが、その前に、まずは自分の案件がこのマトリクスのどこに位置するかを大づかみに捉えることが出発点になります。

「人がいないから外注」ではなく、「案件の性質が要求する品質を、今の自社リソースで満たせるか」で決めるのが正しい問いの立て方です。リスクの高さに応じてテストの優先度と投資配分を決める考え方は、リスクベースドテストでリソースを最適化する実践手順で詳しく扱っています。判断軸に優先度づけを組み込みたい方の助けになるはずです。

二軸の使い方を、対照的な二つの案件で確かめてみます。一つは、長く続く顧客の基幹システムの改修案件です。変更が頻繁で、ドメイン知識が品質を左右し、社内にその知識が厚い。これは「変更頻繁・中リスク × リソースにある程度余裕あり」にあたり、内製を中心に据え、負荷試験など一部の専門領域だけを外注する形が噛み合います。もう一つは、新規のtoC向けサービスで、リリース前に性能とセキュリティを担保する必要があるものの、社内にその専門技法がなく、時間も逼迫している案件です。これは「高い専門性・高リスク × リソース逼迫」にあたり、専門テストは外注に委ね、社内は仕様確認と受け入れに集中するのが現実的です。同じチームでも、案件の座標が違えば答えは変わります。だからこそ、案件単位で座標を置き直す習慣が効いてきます。

この二軸は、上長や顧客に判断を説明するときにも役立ちます。「人が足りないので外注させてください」では通りにくい話も、「この案件はリスクが高く、社内にこの専門技法がないため、この領域だけ外部に出します」と座標で示せば、投資の根拠が伝わります。感覚ではなく軸で語れることは、承認を得るうえでも大きな武器になります。

ありがちな失敗は、この座標を一度引いたきり更新しないことです。案件は生き物で、始まった時点では「定型・低リスク」だったものが、追加開発を重ねるうちに「変更頻繁・高リスク」へ移っていくことは珍しくありません。最初の判断に固執すると、実態は要求水準を越えているのに内製で粘り続け、気づいたときには本番障害が続いている、という事態になります。座標は、案件の節目ごとに引き直すものだと考えてください。

正解は多くの場合「ハイブリッド」

ここまで内製と外注を対比してきましたが、実務での正解は「全内製か全外注か」の二択に収まらないことがほとんどです。テストの内製と外注は、案件全体で選ぶのではなく、工程や領域ごとに使い分けるのが現実解です。

一つの案件のなかにも、性質の異なるテストが混在しています。毎リリース走らせる定型の回帰テストと、仕様の隙間を突く探索的テスト、あるいは性能・セキュリティの専門テストでは、内製と外注の向き不向きが変わります。それを一括りにするから、判断が雑になるのです。

言い換えれば、「この案件は内製」「あの案件は外注」と案件を丸ごと振り分ける発想そのものが粗いのです。一つの案件のなかを領域に割り、それぞれに担い手を当てる。粒度を一段細かくするだけで、これまで見えなかった最適な配置が見えてきます。

領域ごとの典型的な切り分けを表にします。

テストの領域	向いている担い手	理由
回帰・定型テスト	内製	仕様理解が要り、繰り返し実行する
探索的テスト	外注（第三者視点）	作り手の思い込みの外から突ける
性能・負荷テスト	外注（専門性）	専門技法とツールを都度調達できる
セキュリティテスト	外注（専門性）	高度な専門知識が必要
受け入れ・最終確認	内製	顧客・仕様への最終責任は社内が持つ

もちろんこれは一例で、案件の性質と自社リソースによって最適な線引きは動きます。ポイントは、「どの領域を社内に残し、どの領域を外に出すか」を意図をもって設計することです。

ハイブリッドは、最初から完璧な線引きを決める必要はありません。むしろ、小さく始めて育てるのが現実的です。たとえば最初の一歩は、負荷テストやセキュリティテストのような「社内に技法がなく、外の力が明確に効く領域」だけを切り出して外注することです。ここは判断に迷いが少なく、効果も実感しやすい。運用してみて連携の勘所がつかめてきたら、探索的テストなど次の領域へ広げていきます。いきなり全体の分担を組み替えようとすると、発注側の準備が追いつかず頓挫しがちです。効く領域から段階的に、が定着のコツです。

外注側を具体的にどう活用するかは、外部テストでリソース課題を解決する進め方が参考になります。また、そもそも社内にテスト担当者がいない状態から選択肢を検討する段階であれば、社内にテストエンジニアがいない場合の選択肢を整理した記事を先に読むと、外注を含めた次の一手が見えやすくなります。

付け加えると、一度決めた線引きも固定ではありません。案件が育ち、変更頻度やリスクが変われば、内製と外注の最適な配分も動きます。四半期ごと、あるいは案件のフェーズが変わるタイミングで、いまの分担が案件の座標に合っているかを見直す。この定期的な問い直しがあると、体制が実態から乖離しにくくなります。

ハイブリッドは「中途半端な折衷案」ではありません。案件の各部分に、それぞれ最適な担い手を割り当てる、最も理にかなった配置です。二択で悩んでいた問題の多くは、この使い分けの発想に切り替えるだけで解けます。

まとめ｜二択でなく物差しで決める

テストの内製と外注は、「どちらが得か」を全体一括で問うと必ず判断を外します。この記事で持ち帰ってほしいのは、次の三点です。

• 二択で考えない：全内製・全外注の対立軸から降りる
• TCOで比べる：単価でなく、管理コストとリリース後の障害コストまで含めた総額で判断する
• 判断軸で決める：案件の性質（規模・変更頻度・専門性・リスク）×自社リソース（人・スキル・時間）で見極め、多くはハイブリッドに落ち着く

この三点に共通するのは、判断を「気分やその場の事情」から「再現できる手続き」へ移すという発想です。物差しさえ持っていれば、案件が変わっても、担当が変わっても、同じ基準で判断を下せます。属人的な勘に頼らないことが、少人数チームで品質を安定させる土台になります。

最後に、今日から動ける最初の一手をチェックリストにまとめます。

• いま抱えている案件を、テスト領域（回帰・探索・性能・セキュリティ・受け入れ）に分解する
• 各領域を「案件の性質」と「自社リソース」の二軸で評価する
• 領域ごとに内製／外注の仮の割り当てを引く
• 外注候補の領域について、単価でなくTCO（管理・障害コスト込み）で概算する
• その割り当てを、上長に説明できる形（総額と根拠）に整える

このチェックリストは、一度やって終わりではありません。案件が変わるたび、あるいは同じ案件でもフェーズが進むたびに、同じ手順で座標を引き直す。そうやって回していくうちに、内製と外注の判断は特別な意思決定ではなく、日常の運用の一部になっていきます。物差しを一度手にすれば、次からの判断はぐっと軽くなるはずです。

内製と外注のどちらが自社に合うか、TCOまで含めて整理したい方は、いまの案件構成の棚卸しから相談するところから始めてみてください。案件ごとの最適な切り分けを、一緒に描いていけます。