システム開発の検証プロセスとは｜発注者が知るべき手順と判断ポイントを解説

システム開発において検証工程が軽視されやすい理由

システム開発プロジェクトにおいて、検証工程（テスト・品質確認フェーズ）は開発後半に集中します。スケジュールが押してくると、最初に圧縮される対象になりやすい工程です。発注者側が「開発会社に任せておけばよい」と考えるケースも多く、検証工程への関与が薄くなりがちです。しかし、この判断が後工程での大きなコスト増や手戻りを招く原因になります。

手戻りの大半は検証工程で発生する——開発コストへの影響

米国国立標準技術研究所（NIST）の調査によれば、バグの発見が遅れるほど修正コストは指数関数的に増加します。設計段階で発見した場合と比べ、リリース後に発見した場合の修正コストは最大30倍に達するとされています。検証工程での見落としは、単なる「直し」にとどまらず、設計やデータ構造の見直しまで波及するケースが少なくありません。

具体的には、次のような手戻りが発生しやすくなります。

• 業務フローとシステムの動作が合致しておらず、画面設計から再作成が必要になる
• 外部システムとの連携部分で仕様の解釈違いが発覚し、API設計を修正する
• 本番データを使って初めて発覚するパフォーマンス問題が、インフラ構成の見直しに発展する

いずれも、検証工程を十分に確保し、適切な条件でテストを実施していれば早期に発見できた問題です。検証工程の省略や形骸化が、結果的に開発コスト全体を押し上げます。

発注者が検証工程に関与しない場合に起きやすい問題

発注者が検証工程を開発会社に一任すると、確認の視点が「技術的な動作保証」に偏りやすくなります。システムが仕様書どおりに動いていても、実際の業務で使いやすいかどうか、現場の運用フローと整合しているかどうかは、発注者自身が確かめなければ分かりません。

発注者の関与が薄い検証工程では、以下のような問題が起きやすくなります。

• 業務要件の取りこぼし：開発会社は仕様書に基づいてテストするため、仕様書に書かれていない暗黙の業務ルールが見過ごされる
• 受入基準の曖昧さ：「完成」の定義が発注者と開発会社の間で共有されておらず、リリース直前に認識のズレが顕在化する
• 現場からの反発：実際にシステムを使うエンドユーザーが検証に参加しないまま本番稼働し、操作性の問題が大量のサポート対応につながる

検証工程とは何か、どのような手順で進めるべきかを発注者が正しく理解しておくことは、プロジェクトの成否に直結します。開発会社への丸投げを防ぎ、発注者として適切に関与するための前提知識として、次のセクション以降で検証プロセスの全体像を整理します。

検証プロセスとは何か——開発工程における位置づけと目的

システム開発における「検証」という言葉は、実際には複数の意味を含んでいます。混乱を避けるために、まず概念の整理から始めましょう。

検証（Verification）と妥当性確認（Validation）——混同しやすい2つの概念

国際標準規格（ISO/IEC 12207など）では、検証工程に関連する活動を「Verification（検証）」と「Validation（妥当性確認）」の2つに区別しています。

• Verification（検証）：システムが仕様書どおりに作られているかを確かめるプロセス。「正しく作ったか」を問います。
• Validation（妥当性確認）：システムが発注者の本来の目的や業務要件を満たしているかを確かめるプロセス。「正しいものを作ったか」を問います。

たとえば、仕様書に記載された機能がすべて実装されていても、実際の業務フローに合わなければ妥当性確認は通りません。開発会社側が主導するのはVerificationであり、発注者が深く関与すべきはValidationにあたる工程です。この違いを理解しておくことで、自社がどの検証ステップに責任を持つべきかが明確になります。

開発フェーズとテスト種別の対応関係——Vモデルで整理する

検証工程がシステム開発のどのフェーズに位置するかを把握するうえで、「Vモデル」は有用な整理方法です。Vモデルでは、設計フェーズと対応するテスト種別を左右対称に配置します。

• 単体テスト：個々のプログラムモジュールが詳細設計どおりに動作するかを確認します。
• 結合テスト：複数のモジュールを組み合わせ、基本設計で定義したデータの受け渡しや連携が正しく機能するかを確認します。
• システムテスト：システム全体として要件定義の内容を満たしているかを確認します。性能・セキュリティ・負荷への耐性もここで検証します。
• 受入テスト（UAT：User Acceptance Testing）：発注者が実際の業務シナリオに基づいてシステムを操作し、本番導入の可否を判断します。

単体テストから結合テストまでは主に開発会社が担いますが、システムテスト以降は発注者の関与が不可欠になります。

発注者が特に関与すべきテスト種別はどれか

発注経験が浅い段階では、検証工程のすべてを開発会社に委ねてしまうケースが少なくありません。しかし、受入テストは発注者が主体的に実施すべき検証ステップです。

システム開発の検証工程において、開発会社が「仕様どおりに動く」ことを証明できても、「発注者の業務に合っている」かどうかは発注者自身にしか判断できません。受入テストを形式的に済ませてしまうと、本番稼働後に業務上の不整合が発覚し、追加改修コストが発生するリスクが高まります。

次節以降では、こうした検証工程全体を発注者の視点からどのように進めるべきかを、具体的な手順と確認ポイントとともに整理していきます。

検証プロセスの全体手順——4つのステップで進める

検証工程は「なんとなく動作確認をする期間」ではなく、計画から完了判定まで明確な手順で進める工程です。全体を「計画→準備→実施→完了判定」の4ステップに整理すると、発注者が関与すべき場面と開発会社が主導する場面を区別しやすくなります。

ステップ1：検証計画——目的・範囲・スケジュールを確定する

最初のステップでは、何を・どこまで・いつまでに検証するかを書面で確定します。主体は開発会社ですが、計画書の内容を発注者がレビューし、承認する場面が必ず発生します。

確定すべき内容は主に3点です。

• 検証の目的と範囲：機能要件・非機能要件（性能・セキュリティなど）のどこまでをテスト対象とするか
• テストの種類と担当：単体テスト・結合テスト・システムテスト・受入テスト（UAT）のそれぞれを誰が実施するか
• スケジュールと完了基準：各テストフェーズの期間と、次ステップに進む条件

発注者が計画書を確認せずに進めると、後から「この機能はテストされていなかった」という抜け漏れが生じるリスクがあります。

ステップ2：テスト設計と環境準備——何をどう確かめるかを設計する

計画が固まったら、具体的なテストケースの設計と、実行環境の整備を並行して進めます。このステップは主に開発会社が主導しますが、発注者の業務知識が必要な場面も出てきます。

たとえば「受注処理で金額が3桁区切りで表示されるか」といった業務固有の確認事項は、発注者側でないと正しく設計できないケースが少なくありません。テスト仕様書のレビュー時に、業務担当者が抜け漏れを指摘できる体制を整えておくと、後工程での手戻りを減らせます。

環境準備では、本番に近い条件でテストを実施できるかどうかも確認ポイントです。テスト環境と本番環境の構成が大きく異なると、検証の精度が下がります。

ステップ3：テスト実施とバグ管理——検出・記録・修正のサイクル

テストを実行し、問題を検出・記録・修正するサイクルを繰り返すのがこのステップです。開発会社が中心となって進めますが、発注者はバグの優先度判定に関与する場面があります。

検出されたバグはすべて修正するわけではなく、影響度と緊急度に応じて対応順位が決まります。「この不具合はリリースまでに直す必要があるか」という判断には、業務への影響度を知っている発注者の視点が欠かせません。バグ管理ツール上での進捗確認や、定期的な状況報告を受け取れる仕組みを開発会社と事前に取り決めておくとスムーズです。

ステップ4：完了判定——リリース可否を誰がどう決めるか

最終ステップでは、テスト結果をもとにリリースを承認するかどうかを発注者が意思決定します。開発会社がテスト結果のサマリーを提出し、合格基準（例：重大バグ件数ゼロ、テストケース消化率95%以上など）への達成状況を報告するのが一般的な流れです。

完了判定を行うのは開発会社ではなく、発注者です。「開発会社がOKと言ったから」という理由だけでリリース判断を下すのではなく、判断の根拠となる指標を事前に合意しておくことが重要です。この合意がステップ1の検証計画に含まれているかどうかを、計画レビュー時に確認しておくとよいでしょう。

発注者が検証計画のレビュー時に確認すべき5つのポイント

開発会社から検証計画書が提示されたとき、技術的な詳細を読み解けなくても、発注者として必ず確認すべき観点があります。以下の5点を押さえておくことで、計画の抜け漏れや後からの認識齟齬を防ぐことができます。

テスト範囲と優先順位——重要機能が漏れていないか

検証計画書には、どの機能・画面・データをテストするかが記載されています。まず確認したいのは、自社の業務にとって重要な機能が対象に含まれているかどうかです。たとえば、受発注処理や決済フローなど、障害が発生した際の業務影響が大きい機能は、優先度「高」として明示されているべきです。網羅性だけでなく、優先順位の根拠も確認しましょう。

合否基準（Exit Criteria）——「何をもって完了とするか」が明文化されているか

検証が「完了した」と判断する条件が曖昧なまま進むと、開発会社と発注者の間で完了の認識がずれるリスクがあります。合否基準（Exit Criteria）とは、たとえば「重大度の高いバグがゼロであること」「テストケースの消化率が95%以上であること」といった具体的な数値や条件のことです。感覚的な判断ではなく、数値で定義されているかどうかを確認してください。

テスト環境——本番環境と乖離していないか

テストは本番に近い環境で行われなければ、実際の運用時に想定外の不具合が発生するリスクが高まります。サーバースペック・ネットワーク構成・利用するデータの形式などが本番と大きく異なる場合、テスト結果の信頼性が下がります。「なぜその環境でテストするのか」を開発会社に確認し、乖離がある場合はその理由と対策を説明してもらいましょう。

スケジュールと工数——バッファは十分か

検証工程は、バグ修正と再テストの繰り返しが発生するため、想定以上に時間がかかるケースが少なくありません。スケジュールを確認する際は、バグ対応や再テストのための予備期間（バッファ）が設けられているかどうかを見てください。バッファがなく工程がぎっしり詰まっているスケジュールは、問題が発生した際にリリース日程全体を圧迫する可能性があります。

役割分担——発注者側が担う作業の範囲はどこまでか

検証工程において、発注者側にも一定の作業が発生します。テストデータの準備、テスト実施への参加、結果の確認・承認などが代表的です。これらが計画書に明記されていない場合、直前になって対応を求められ、社内リソースの確保が間に合わないことがあります。発注者側の作業内容・担当者・期限を計画書の段階で確認しておくことが重要です。

受入テスト（UAT）——発注者が主導する検証工程の進め方

UAT（User Acceptance Test：ユーザー受入テスト）は、開発会社ではなく発注者自身が主体となって実施する検証工程です。「実際の業務でこのシステムを使えるか」を確認する最終関門であり、開発会社任せにしてしまうと、リリース後に現場で使えないという事態が起きやすくなります。

UATのシナリオ設計——業務フローに沿ったテストケースの作り方

テストシナリオは、機能の一覧ではなく実際の業務フローを起点に作成します。たとえば「営業担当者が受注を登録し、経理が請求書を発行するまでの一連の流れ」のように、部門をまたぐシナリオを想定することが重要です。

具体的な作り方は次の手順で進めると整理しやすくなります。

1. 自社の主要業務フローを洗い出し、優先度の高い順に並べる
2. 各フローを「誰が・何を・どのような条件で操作するか」に分解する
3. 正常系（想定どおりの操作）と異常系（誤入力・例外処理）の両方を用意する
4. 業務部門の担当者にシナリオをレビューしてもらい、抜け漏れを確認する

情報システム担当者だけでシナリオを作ると、現場の実態と乖離しやすくなります。営業・経理・物流など、実際にシステムを使う部門を早期に巻き込むことが、テストの精度を高める最大のポイントです。

不具合の重要度分類——Critical・Major・Minorの基準をあらかじめ決める

UATでは必ず不具合が発見されます。すべての不具合をリリースまでに解消しようとすると、スケジュールが破綻しやすくなります。そのため、重要度の分類基準をテスト開始前に定めておくことが不可欠です。

• Critical（致命的）：業務が完全に止まる、データが消える・壊れるなど、リリースを阻止すべき不具合
• Major（重要）：業務に支障をきたすが代替手段がある、または一部機能が動かない不具合
• Minor（軽微）：表示のずれ・文言の誤りなど、業務への影響が限定的な不具合

Criticalはリリース前に必ず修正、MajorはリリースまでのPJT判断、Minorは次期対応を検討、という基準を設けておくと、判断がスムーズに進みます。この分類は発注者と開発会社が合意した形で文書化しておくことが重要です。

UATの判定会議——合否をどのように意思決定するか

UAT期間が終了したら、判定会議を設けてリリース可否を決定します。判定会議では以下の情報を事前に整理して臨むと、議論が迷走しにくくなります。

• テストシナリオの消化率（何件中何件を実施できたか）
• 不具合の件数と重要度別の内訳
• 未解消のCritical・Major不具合の内容と対応見込み
• 業務部門からの総合評価コメント

判定の権限は情報システム部門だけでなく、業務部門の責任者も含めて持つ体制が望ましいです。「現場が使えると判断したか」という視点が、受入テストの本来の目的に沿った意思決定につながります。合否の基準（たとえば「Criticalゼロ、かつテスト消化率90%以上」など）も事前に決めておくと、判定会議の議論を客観的な根拠に基づかせることができます。

完了判定で陥りやすい落とし穴と対処法

検証工程の最終局面で発注者が直面しやすいのが、「完了判定」の難しさです。テストを実施しても、それを「合格」とみなしてリリースに進んでよいかどうかの判断に迷うケースは少なくありません。CLANEが関与したプロジェクトでも、完了判定の設計が不十分だったために、後工程で混乱が生じた事例が複数見られています。

「日程ありき」の完了判定がもたらすリスク

最もよく見られる落とし穴は、リリース日を固定したまま検証を進めることです。「〇月末には必ずリリースする」という前提が組織内で共有されてしまうと、検証ステップの途中でバグが見つかっても、日程を優先してリリース判定を通過させてしまうことがあります。

この判断は短期的にはプロジェクトを前進させるように見えますが、本番環境で問題が再現した場合の対応コストは、リリース延期のコストをはるかに上回ることが多いです。発注者側の意思決定者が「日程とリスクはトレードオフである」という認識を事前に持ち、判定基準を日程から切り離して設計しておくことが重要です。

残存バグの扱い——既知の不具合リストと運用回避策の整理

検証工程を終えた段階でも、すべてのバグが解消されているケースはむしろ少ないです。重要なのは、残存バグを「ないことにする」のではなく、既知の不具合リストとして明文化したうえで、それぞれに対して運用上の回避策を整理することです。

具体的には、以下の観点で不具合を分類することが有効です。

• 業務影響度：その不具合が発生した場合に、業務フローにどの程度の支障が生じるか
• 発生頻度の想定：通常の操作範囲内で発生しうるか、特殊な条件下でのみ起きるか
• 修正時期の見通し：リリース後の次期アップデートで対応できるか

CLANEが担当したプロジェクトでは、この既知不具合リストをリリース判定会議の議題に組み込み、発注者・開発会社・運用担当者が同じ情報をもとに判断できる体制を整えたことで、リリース後のトラブル対応が円滑に進んだケースがあります。

リリース判定会議の設計——誰が・何をもとに・最終決裁するか

完了判定を属人的な感覚や慣習で行うことも、よくある問題のひとつです。「開発会社がOKと言ったから」「テスト担当者が問題ないと言ったから」という理由だけでリリースが決まってしまうと、発注者側の意思決定が形骸化します。

判定会議を設計する際は、次の3点を事前に決めておくことが有効です。

1. 参加者の役割：発注者側の決裁者・業務担当者・開発会社の責任者が揃っているか
2. 判断材料：テスト結果レポート・残存バグリスト・合否基準の達成状況が書面で共有されているか
3. 最終決裁者：「誰が」「どの条件を確認したうえで」承認サインを出すかを明確にする

合否基準があいまいなまま会議を開いても、その場で判断を下すことは困難です。検証計画の段階で合否条件を数値や状態で定義しておくことが、判定会議を機能させるための前提となります。

検証プロセスを円滑に進めるために発注者が事前に整えておくこと

検証工程がスムーズに進むかどうかは、テスト実施フェーズそのものよりも、要件定義・設計という上流工程での取り組みに大きく依存します。「テストは開発会社に任せればよい」と考えていると、いざ検証段階になって仕様の曖昧さや関係者の調整不足が表面化し、スケジュールが大幅に乱れるケースは少なくありません。発注者として、契約・要件定義フェーズから意識しておくべき準備事項を整理します。

要件定義の段階でテスト観点を意識する——検証可能な仕様書とは

要件定義書に「直感的に操作できること」「高速に動作すること」といった抽象的な表現が含まれていると、検証段階で合否判定ができません。検証可能な仕様書とは、合否を客観的に判断できる条件が明記されたものを指します。

具体的には、以下のような書き方を意識する必要があります。

• 「検索結果は3秒以内に表示されること」など、数値で測定できる条件を設ける
• 「〇〇の操作を行ったとき、△△の画面に遷移すること」のように、入力と期待結果をセットで記述する
• 「エラー発生時は〇〇のメッセージを表示し、ログに記録すること」のように例外ケースも明文化する

要件定義の段階でテスト担当者（または開発会社のQAエンジニア）を仕様レビューに加えると、検証しにくい記述を早期に発見できます。

業務部門の早期巻き込み——UATに協力してもらうための根回し

受入テスト（UAT）は、実際にシステムを使う業務部門のメンバーが主体となって行う工程です。しかし、「開発終盤になって突然協力を依頼される」という状況では、業務部門側の準備が整わず、テスト期間が形式的なものになりがちです。

発注者（情報システム部門や事業推進担当）は、要件定義フェーズの段階から業務部門の担当者を巻き込んでおくことが重要です。具体的には、要件レビューへの参加を求め、現場の業務フローとの整合性を早期に確認しておくと、UATでの手戻りを減らせます。また、UATのスケジュールを業務カレンダーに組み込んでもらうよう、上長を含めて合意を取っておくことも欠かせません。

テスト管理ツールの選定——課題追跡と進捗管理を一元化する

検証工程では、テストケースの実施状況、バグ報告、修正対応の進捗を一元管理できる環境が必要です。メールやExcelで管理していると、報告の抜け漏れや最新状況の把握に時間がかかり、完了判定の精度も下がります。

TestRailやRedmine、Backlogといったツールを活用すると、テストケースごとの合否記録・バグのステータス管理・進捗レポートを一カ所で確認できます。開発会社が使用するツールと発注者側の管理環境を統一しておくと、情報の非対称が生じにくくなります。ツールの選定は、開発契約を締結する前後の段階で開発会社と合意しておくことが望ましいです。

まとめ——発注者が検証プロセスに能動的に関与することの意味

システム開発における検証プロセスは、開発会社だけに委ねていれば完結するものではありません。発注者が各ステップに能動的に関与することで、品質の確認精度が高まり、リリース判定の確実性も上がります。

記事全体を通じて解説してきた内容を、発注者が取るべきアクションとして整理すると、以下のようになります。

• 検証計画のレビュー時：テスト範囲・合否基準・スケジュールの妥当性を自社側の視点で確認し、業務要件との乖離がないかを検証する
• 受入テスト（UAT）の実施時：実際の業務シナリオをベースにしたテストケースを発注者側で用意し、エンドユーザーを交えた検証を主導する
• 完了判定の場面：「残課題の影響度」と「運用でカバーできる範囲」を明確に定義したうえで、リリース可否を自社の判断として下す

これらのアクションに共通しているのは、発注者が「確認を受ける側」ではなく「判断する主体」として関与するという姿勢です。検証手順はシステム開発の中でも特に専門性が問われる工程ですが、その分、発注者が適切に関与できるかどうかで最終的な品質に差が生まれます。

事前に社内の体制・テストデータ・判定基準を整えておくことが、スムーズな検証プロセスの前提条件です。準備が不十分なまま工程が進んでしまうと、手戻りや完了判定の遅延につながるケースが少なくありません。

検証プロセスへの理解を深め、発注者として主体的に関与することが、期待どおりのシステムをリリースするための確実な手段となります。