第三者検証とは：開発会社のテストとの役割分担・費用の決まり方・発注のタイミング

第三者検証は、システムを作った開発チームとは別の担当が、そのソフトウェアの品質を確かめる取り組みです。受託開発では、発注者が開発会社とは別の検証会社や社内の独立した部署に、テストやレビューを任せる形で行われます。本記事で順に整理するのは、テストの独立性の段階とIV&V・第三者認証との違い、開発会社のテストとの工程別の分担、費用が決まる要素、発注するタイミングです。最後に、第三者検証を入れるべき案件と見送ってよい案件を条件付きで示します。

まとめ：第三者検証は開発会社のテストを置き換えず残るリスクを測る発注者側の手段

第三者検証は、開発会社のテストを省くための仕組みではありません。単体テストや結合テストは引き続き開発会社が行い、第三者はその外側から、要件の解釈違いや開発会社が想定していなかった使われ方を確かめます。

費用は、検証の対象範囲・システムの規模・関与する期間の掛け算で決まります。上流から並走させるほど設計の誤りを早く見つけられる一方、関与期間が延びる分だけ費用も増える仕組みです。障害が起きたときの損失が大きい基幹系や決済系、開発会社1社に品質の説明を頼りきっている案件では入れる価値があります。逆に、利用者が社内の数人に限られる小さなツールでは見送ってかまいません。

第三者検証とは何か｜独立性の段階とIV&V・第三者認証との違い

「第三者検証」は法律や規格で決められた用語ではなく、検証会社ごとに指す範囲が少しずつ違います。まずは国際的なテストの資格制度での位置づけを確認します。

第三者検証の定義｜作成者から独立した担当が品質を確かめる活動

ソフトウェアテストの資格制度であるJSTQBのFoundation Levelシラバス（V4.0・2023年4月12日版）は、1.5.3節「テストの独立性」でこの考え方を扱っています。作成者とテスト担当者では認知バイアスが異なるため、ある程度の独立性があるとテスト担当者が欠陥を効果的に見つけやすくなる、という説明です。

第三者検証は、この独立性を意図して高めたテストやレビューを指す言葉として使われています。対象はテストの実行だけではありません。要件定義書や設計書のレビュー、テスト計画の妥当性の確認、開発会社が出したテスト結果の評価まで含めて請け負う検証会社もあります。

JSTQBが示すテストの独立性の4段階｜作成者本人から組織外の担当まで

同じ1.5.3節は、誰がテストするかによって独立性を4段階に分けています。

シラバスは、ほとんどのプロジェクトでは複数の独立性のレベルを組み合わせるのが最善としています。開発担当がコンポーネントのテストを、テストチームがシステムテストを、業務側の代表者が受け入れテストを担う形です。第三者検証は、この組み合わせの中で「組織外」の段を発注者が意図して加える選択だと捉えると、位置づけを誤りません。

IV&Vと第三者認証との違い｜開発と並走する検証と規格適合の審査

第三者検証と近い言葉に、IV&V（Independent Verification and Validation）と第三者認証があります。IPAのSECが公開した先進的な設計・検証技術の適用事例報告書2017年度版（SEC-2017-80-01）では、JAXAが宇宙機のソフトウェアで行うIV&Vを、「技術、組織、資金」の独立性を確保した第三者の技術者による検証と説明しています。設計書やソースコードなどの成果物を、開発担当と異なる技術者が開発と並行して評価し、問題点の修正提案や重大な問題の有無をステークホルダーへ報告する活動です。

受託開発の現場で「第三者検証」と言うとき、多くはテスト工程を中心とした検証を指します。上流から並走させるならIV&Vの考え方に近づき、ISMSのような認証の取得とは目的がまったく異なります。見積もりを取る前に、どれを求めているのかを社内でそろえてください。

開発会社のテストと第三者検証の役割分担｜工程別に誰が何を確かめるか

第三者検証を入れても、開発会社が負うテストの責任は変わりません。重なりと抜けを作らないために、工程ごとの担当を先に決めます。

工程別の分担表｜単体テストから受入テストまでの担当と第三者の関与

受託開発で一般的な分担は次のとおりです。

第三者が単体テストをやり直す分担は避けます。コードの中身を最もよく知る開発担当のほうが短時間で欠陥を見つけられるうえ、同じ作業を2社に払うことになるためです。工程全体の流れとV字モデルの対応はシステム開発のテスト工程とは？種類・流れとV字モデルで整理しています。

第三者に任せる範囲の決め方｜要件定義書レビューからシステムテストの再実施まで

任せる範囲は、発注者が自力で確かめられないところから決めます。業務の流れは発注者が一番よく知っているので、受入テストの主体は発注者のままです。一方、性能・負荷、同時アクセス時の不整合、権限の抜け、外部システムとの境界条件は、業務担当が触っても見つけにくい領域で、第三者に任せる効果が出やすい部分です。

セキュリティの観点は、第三者検証とは別に専門の脆弱性診断として発注するのが一般的です。診断項目と費用の考え方は脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準にまとめています。受入テストのうち発注者が担う部分の進め方は受入テスト（UAT）とは？進め方と合否基準を参照してください。

独立性の利点と欠点｜異なる欠陥が見つかる一方で開発側の責任感が薄れる

JSTQBシラバスは独立性の利点として、経歴や技術的な視点、バイアスが異なるため、開発担当とは違う種類の故障や欠陥に気づきやすいことを挙げています。仕様を決めたときの前提を検証し、異議を唱えられる点も利点とされています。

欠点も明記されています。独立したテスト担当が開発チームから孤立し、情報が伝わらない、敵対関係に陥る、開発担当が品質への責任感を失う、テスト担当がボトルネックやリリース遅れの原因と見なされる、といったものです。受託開発に置き換えると、開発会社が「最後は検証会社が見るから」とテストを薄くする事態が最も起きやすい失敗です。開発会社との契約では、第三者検証の有無にかかわらず、各工程のテスト完了基準と報告書の提出を開発会社の義務として残します。品質保証と品質管理の役割の違いは品質管理と品質保証の違いとは？QCとQAの役割分担で解説しています。

第三者検証の費用の決まり方｜検証範囲・規模・期間で見積もりが変わる理由

第三者検証には公的な料金表がなく、見積もりは案件ごとに大きく変わります。金額そのものより、何で金額が決まるかを知っておくと、見積もりの比較がしやすくなります。

費用を決める要素｜検証範囲・対象の規模・関与する期間と担当体制

費用は、検証の作業量に技術者の単価を掛けて決まります。作業量を左右するのは、どの工程に関与するか（範囲）、画面数や機能数、連携する外部システムの数（規模）、何か月関与するか（期間）の3つです。テスト実行だけを2週間任せる場合と、要件定義から稼働まで並走させる場合では、作業量の桁が変わります。

単価は、テスト設計やレビューを担う技術者と、決められた手順でテストを実行する担当とで差があります。職種とスキルによる人月単価の違いは人月単価とは？職種・スキル別の相場と内訳で解説しています。見積もりの段階では、どの作業をどの単価の人が担うのかを内訳で出してもらってください。

見積もりの比べ方｜テスト観点・テストケース数と報告書の中身をそろえる

複数の検証会社から見積もりを取ると、金額が数倍違うことは珍しくありません。差の多くは、想定しているテスト観点の数、テストケースの数、再テストの回数、報告書の中身の違いから生まれます。総額だけで比べると、テストケース数が少ない会社ほど安く見えます。

比べる前に、成果物を指定してそろえます。JSTQBシラバスの5.3.2項は、定期的に作るテスト進捗レポートに期間・進捗・支障と回避策・メトリクス・新たなリスク・次期の計画を含めるとしています。完了時のテスト完了レポートには、テスト概要、メトリクス、未解決のリスクと修正されなかった欠陥、学んだ教訓が入る形です。この項目を見積もり依頼に書き、各社が同じ報告書を出す前提で金額を比べます。テストケースの書き方とレビューの観点はテスト仕様書とは？書き方とテストケースの項目が参考になります。

契約形態と費用の負担｜開発会社の請負とは別に準委任で発注する場合

第三者検証は、開発会社との請負契約とは別に、発注者が検証会社と準委任契約を結ぶ形が多くなります。検証の作業量は見つかる欠陥の数で増減し、完成の基準を事前に決めにくいためです。請負と準委任の違いは準委任契約とは？請負・派遣との違いとシステム開発での使い分けで整理しています。

注意したいのは、開発会社側の協力です。第三者が設計書を読み、テスト環境に入り、見つけた欠陥を報告するには、開発会社による資料提供と問い合わせ対応が必要です。IPAの情報システム・モデル取引・契約書（第二版）は発注者と開発会社の2者間を前提にした雛形なので、第三者検証への協力範囲や問い合わせの窓口は、開発会社との個別契約に別途書き足しておきます。第三者が見つけた欠陥のうち、仕様どおりに作られていないものは開発会社が無償で直し、仕様にない要望は変更として扱う、という線引きもこのとき決めます。

第三者検証を発注するタイミング｜要件定義から入るか総合テスト後に入るか

第三者が入る時期は、大きく「上流から並走する」か「テスト工程の後半から入る」かに分かれます。効果と費用の釣り合いがそれぞれ違います。

要件定義・設計から入る並走型｜設計書の誤りを作る前に見つける

並走型は、要件定義書や設計書の段階から第三者がレビューに加わる形です。IPAの報告書が紹介するJAXAのIV&Vもこの形で、開発と並行して成果物を評価し、問題点をフィードバックします。要件の矛盾や考慮漏れは、プログラムを書いた後に見つかると設計・実装・テストのやり直しが連鎖し、書く前に見つければ直すのは文書だけで済みます。

その代わり、関与する期間が長くなり、費用は後追い型より大きくなります。並走型が見合うのは、要件が複雑で関係部署が多い基幹系の刷新や、一度稼働すると止められない決済・受発注の系統です。

総合テスト後に入る後追い型｜受入テストの前に行う品質の再評価

後追い型は、開発会社の総合テストが終わった段階で第三者が入り、追加の観点でテストを行う形です。開発会社のテスト結果報告書を評価し、テストが薄い機能を選んで再実施します。期間は数週間程度に収めやすく、費用も並走型より抑えられます。

弱点は、見つかった欠陥の原因が設計にあった場合、直す時間が残っていないことです。後追い型を選ぶなら、受入テストと稼働日の間に修正と再テストのための期間を最初から確保しておきます。修正のたびに確かめる範囲の選び方はリグレッションテスト（回帰テスト）とは？で扱っています。

発注前に準備するもの｜テストベース・開発会社の協力範囲・報告先

どちらの型でも、検証会社に声をかける前に次の4点を用意しておくと、見積もりと立ち上がりが早くなります。

1. テストの元になる文書（要件定義書・設計書・業務フロー）の最新版と、その更新ルール
2. 開発会社が提出するテスト計画書とテスト結果報告書の様式
3. 開発会社が第三者に対応する範囲（資料提供・問い合わせ窓口・テスト環境の利用）
4. 第三者の報告を受け取る発注者側の担当者と、判断を下す会議体

4つ目が抜けると、検証会社の報告書が誰にも読まれずに終わります。報告を受けて開発会社に修正を指示する権限が誰にあるかを、体制図に書いておいてください。

第三者検証を入れるべき案件と見送る案件｜発注者が判断する条件

第三者検証はどの案件にも必要なものではありません。入れる場合と見送る場合を、条件で分けて判断します。

第三者検証を入れるべき条件｜障害時の損失・開発会社への依存・社内の不在

次のいずれかに当てはまる案件では、第三者検証の費用を予算に入れて検討します。

• 止まると売上や取引先に直接影響する（受発注・決済・在庫引当・給与計算など）
• 品質の説明を開発会社1社の報告に頼るしかなく、社内に報告を読み解ける人がいない
• 利用者が社外の顧客や取引先で、不具合がそのまま信用の問題になる
• 監査や取引先から、テストの客観性について説明を求められる

最も多いのは2つ目のケースです。開発会社の報告書が「テストケース1,200件・合格率100%」と書いてあっても、その1,200件が業務の重要な場面を押さえているかを判断できなければ、数字は安心材料になりません。

第三者検証を見送る条件｜小さな社内ツールと仕様が固まらない初期開発

利用者が社内の数人で、止まっても手作業で代替できるツールには、第三者検証は過剰です。開発会社のテストと発注者の受入テストで足ります。

仕様が毎週変わる試作段階やPoCも見送ります。検証の前提になる仕様が固まっていないため、第三者が書いたテストケースがすぐに使えなくなるからです。この段階で必要なのは独立した検証よりも、要件を固めて受入基準を書けるようにすることです。

第三者検証でよくある失敗｜開発会社との対立と報告書を読まない発注者

失敗の1つ目は、第三者を開発会社の監視役として入れ、指摘のたびに責任の押し付け合いになる形です。JSTQBシラバスが欠点に挙げた敵対関係そのもので、欠陥の修正より言い分の応酬に時間が消えます。第三者の指摘は発注者が受け取り、不具合か仕様変更かを発注者が判定してから開発会社へ渡す流れにすれば、対立を避けられます。

2つ目は、発注者が報告書を読まず、検証会社の「合格」をそのまま検収の根拠にする形です。第三者検証は判断材料を増やす手段であり、受け入れるかどうかを決めるのは発注者です。社内に報告書を読み解き、検証範囲や受入基準を設計できる人がいない場合は、発注者側に立つ支援を別に置く方法があります。一創の要件定義・RFP作成・PMO支援では、要件定義書の整備から、テスト計画と受入基準のレビュー、開発会社から出る報告書の評価までを発注者側で支援しています。

第三者検証の範囲・費用・依頼先について発注者からよくある質問

第三者検証を検討する発注者から寄せられやすい質問に回答します。

第三者検証とテストの外注は同じ意味ですか？

重なる部分はありますが、同じではありません。テストの外注は、開発会社が自社のテスト作業の一部を別会社に出す場合も含みます。この場合、テストする会社は開発会社の下請けで、発注者から見た独立性はありません。第三者検証と言うときは、発注者が開発会社とは別に契約し、報告を発注者が直接受け取る形を指すのが一般的です。誰と契約し、誰に報告するかで区別してください。

開発会社の品質保証部門のテストでは足りないのですか？

JSTQBシラバスの区分では、開発会社の品質保証部門は「チーム外だが組織内」にあたり、独立性は高い段階です。開発会社のテスト体制がしっかりしていれば、多くの案件はそれで足ります。ただし、品質保証部門も開発会社の一員であり、納期や費用の都合を共有する立場です。障害時の損失が大きく、発注者として品質の説明を独立した立場から受けたい場合に、組織外の第三者を加えます。

第三者検証はいつ依頼すればよいですか？

上流から並走させるなら、要件定義に入る前に検証会社を決め、要件定義書のレビューから関与してもらいます。総合テスト後に入る後追い型でも、依頼は開発の発注と同じ時期に済ませてください。開発会社の協力範囲を契約に書き込む必要があり、テスト工程が始まってからでは、テスト環境や資料の提供を後から交渉することになるためです。

第三者検証で見つかった不具合の修正費用は誰が払いますか？

要件定義書や設計書のとおりに作られていない不具合であれば、開発会社が直すのが一般的です。誰が見つけたかで扱いは変わりません。一方、第三者の指摘が仕様に書かれていない要望や使い勝手の改善であれば、仕様変更として開発会社に別途見積もってもらいます。不具合か仕様変更かの判定は、第三者でも開発会社でもなく発注者が行う、と事前に決めておくと揉めません。

アジャイル開発でも第三者検証は必要ですか？

アジャイル開発では、数週間ごとに動くソフトウェアができあがるため、最後にまとめて検証する後追い型は合いません。第三者を入れるなら、スプリントごとに受け入れ基準のレビューや探索的なテストに加わってもらう形にします。その分、開発チームとの距離が近くなり独立性は下がるので、報告先を開発チームではなく発注者側のプロダクトオーナーに置き、指摘が開発チーム内で握りつぶされない経路を作ってください。

関連記事

• システム開発の品質管理とは？工程別レビュー・テスト管理とメトリクス判定の手順：開発会社が工程ごとに品質をどう測るかを、第三者の評価の前提として確認できます。
• システム開発の見積もりとは？見積書の見方・依頼方法・相見積もりの比較：検証会社の見積もりを比べるときにも使える、見積書の読み方を解説しています。
• PMOとは？役割・種類とPMとの違い｜システム開発でPMOを外部に任せる判断：第三者検証と並べて検討されることの多い、発注者側の管理支援の判断材料です。