ベンダーから「来週からテスト工程に入ります」「UATをお願いします」と連絡が来たものの、自分が何をすればよいか分からず手が止まってしまった、という声をよく耳にします。テスト計画書を渡されても、自社側で「いつ」「何を」「どこまで深く」確認すべきかの判断軸が示されていないからです。
関与が薄いと「こんな動きのはずじゃなかった」と納品後に発覚し、細部まで口を出しすぎればベンダーのテスト計画を乱します。求められるのは「適切な濃度で関与する」判断力です。
単体テスト・結合テストは基本ノータッチ、システムテストは結果報告書を読み解く立場、受入テスト（UAT）では主体となって業務シナリオを確認する。この濃淡を意識できると、開発を混乱させずに納品品質を守る関与の仕方が見えてきます。
本記事ではフェーズ別の関与レベル・UATの確認方法・合格基準とバグ対応の判断軸の3軸で、発注者がテスト工程でやることを整理します。読了時に自社プロジェクトの現在位置と次のToDoが具体的にイメージできる状態を目指します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
システム開発のテスト工程と発注者の役割を一望する
最初にテスト工程全体の流れと、各工程で発注者がどの程度関与すべきかを俯瞰します。
テスト工程の4段階と目的の違い
テスト工程は内側から外側に向かって品質を確認する4段階で構成されます。
- 単体テスト（UT）: プログラムの最小単位が個別に正しく動くかを開発者が確認します。
- 結合テスト（IT）: モジュール間の連携が想定通りに動くかを確認します。
- システムテスト（ST）: 本番に近い環境で機能要件・非機能要件を満たすかを確認します。
- 受入テスト（UAT）: 発注者が業務観点で受け入れ可否を判断する最終確認です。
内側ほど技術的・細粒度、外側ほど業務的・全体的になり、発注者の関与は外側ほど主体的になります。各工程のエビデンスや確認すべき成果物についてはテスト種類ごとの確認ポイントも参考にしてください。
フェーズ別「発注者の関与レベル」一覧表
各工程の関与レベルと、その濃度でよいと判断できる根拠を一覧で示します。
テスト工程 | 関与レベル | そのレベルでよい根拠 |
|---|---|---|
単体テスト | ノータッチ | コード内部品質はベンダー責任。発注者の介入は品質を上げず計画を乱す |
結合テスト | ノータッチ（進捗監視） | モジュール間の技術的整合性確認が主目的で、業務観点の判断は後段で行えば足りる |
システムテスト | 報告書確認＋一部立ち会い | 業務観点の初期判断は必要だが主導はベンダー。重要箇所を選択的に確認すれば十分 |
受入テスト（UAT） | 主体的に実施 | 自社業務で本当に使えるかを判断できるのは発注者だけ。確認漏れは納品後トラブルに直結する |
全工程に同じ熱量で関わるとリソースが枯渇してUATで力尽きます。重点は「UATに最大の力を残しておく」ことです。
発注者関与が薄いと起きる典型トラブル
関与濃度を誤ると、要件定義時に曖昧な仕様が動作として現れる「こんな動きのはずじゃなかった」、シナリオ設計をベンダー任せにして核心が未検証のまま納品される「UATで何を見ればよいか分からないまま終わった」、事前合意がないままUAT終結時に水掛け論になる「合格基準で揉める」といった後悔パターンに陥ります。共通の原因は、発注者が何を担うかを言語化していなかった点にあります。
単体テスト・結合テストで発注者が「やるべきこと/やらなくていいこと」
単体テスト・結合テストは技術領域のテストで、発注者の役割は「離れて見守る」ことです。
単体テスト・結合テストの位置づけ
いずれも技術仕様書・設計書を基準に実施され、テスト設計・実施・結果記録はすべてベンダー側で行われます。発注者は設計書を承認した立場として、設計通りに実装されたかをベンダーが自主検証する段階だと理解しておけば十分です。テストケースの内容や粒度に立ち入る必要はありません。
発注者が確認するのは「結果」ではなく「進捗とリスクサイン」
完全に放置するわけではなく、週次報告で次のサインを確認します。
- テスト消化率がスケジュール対比で大きく遅れていないか（半分以上の遅れはUAT開始のずれ込みサイン）
- 検出バグ件数が想定の2〜3倍を超えていないか（設計または実装品質の課題を示唆）
- 致命的バグの残存件数と修正計画
確認するのは「結果の正しさ」ではなく「リスクの兆候」です。
過剰関与のアンチパターン
避けるべきは技術領域に踏み込み計画を乱す行為です。「このテストケースも追加してほしい」と細部に口を出す、「単体テストでも業務シナリオを確認してほしい」と工程の役割を取り違える、進捗の遅れに「全件レビューさせろ」と過剰反応する、といった介入はスケジュールを乱しUATの時間を削ります。技術領域はベンダーに任せ、UATで主体的に動けるリソースを温存しましょう。
システムテストで発注者が立ち会うべきシナリオと報告書の読み方
システムテスト（総合テスト）は本番に近い環境でシステム全体の動作を確認する工程で、基本はベンダー主導ですが、業務クリティカルな箇所では発注者の立ち会いが価値を持ちます。
システムテストで発注者が立ち会うべき業務シナリオの選び方
全シナリオに立ち会う必要はありません。月次締め処理・請求書発行など金銭損失や顧客影響に直結する処理、会計・EC・外部APIなど本番相当の挙動を再現しづらい連携処理、議事録に「あとで詰める」と書かれた曖昧な機能、の3点を立ち会う対象とします。発注者が同席することで、UATで再確認すべきポイントを早期に発見できます。
テスト結果報告書の確認ポイント
報告書は次の3点を中心に確認します。
- 不具合の重要度区分: 致命的／重大／軽微の分類と、区分の定義が明示されているか。
- 残存バグ数と修正計画: UAT開始時点で解消済みのバグと、残ったままUATに進むバグの区別。
- 性能指標: 応答時間・スループット・同時接続数などが合意目標値を満たしているか。
不明点はベンダーに質問してリスクを言語化しておくと、UATでの確認観点が明確になります。報告書の前段にあたるテスト計画書をどう読み解くかはテスト計画書の読み方もあわせて参照してください。
UATに進む前に発注者が確認しておくべき事項
移行判定では、致命的・重大バグの残存と修正見込み、非機能要件の合意値達成、UAT環境とテストデータの準備状況の3点を確認します。
ここで意識したいのは「後悔ポイントの先回り」です。システムテスト段階で覚えた違和感（画面遷移が想定より遅い、連携処理でタイムアウトが時々起きる等）を「UATで改めて見ればいい」と先送りすると、UAT中に再現できず原因究明に時間を取られたり、本番直前まで未解決のまま残ったりします。違和感はその場でベンダーに共有し、原因と対策の見通しを文書化してからUATに進む。これだけで本番移行時のトラブルを大きく減らせます。
受入テスト（UAT）の進め方と発注者が確認する具体的な方法
UATは発注者が主体となる唯一の工程であり、本記事の中核です。
UATの目的と発注者が責任を負う範囲
UATの目的は「ベンダーが作ったシステムが自社の業務に適合しているか」を確認することです。技術的な正しさはシステムテストまでで担保されており、UATで問うのは業務観点の妥当性です。
発注者が負う責任は、業務シナリオの設計、業務担当者による実行の判断、検出問題の業務影響度の判定、最終的な受け入れ可否判断の4点です。ベンダー作成シナリオを操作するだけでは自社固有の検証が漏れるため、シナリオ設計の主導権を発注者が持つことがUAT成功の出発点です。
確認すべき4種類のテスト
UATで実施すべきテストは大きく4種類に分類できます。
- 機能確認テスト: 個別機能が業務担当者の操作で期待通りに動くか。
- 業務シナリオテスト: 「受注 → 在庫引当 → 出荷 → 請求」のような業務フロー全体を通して実行する。
- 連携テスト: 他システムとのデータ授受が業務として成立するか。
- 例外処理テスト: 入力エラー・通信エラー・データ不整合など、異常系で業務が止まらないか。
機能確認だけで終わらせず、業務シナリオと例外処理まで踏み込めるかがUAT品質の分かれ目です。
UATテストケースの設計手順
UATテストケースは自社の業務フローから逆算して設計します。
- 標準フロー（ハッピーパス）と想定される例外パターンを書き出す。
- 各フローを「誰が・どの画面で・何を入力し・何を確認するか」のステップに分解する。
- 「画面に○○が表示される」「△△データが□□に保存される」など、合否の判断基準をステップ単位で記述する。
- 設計したシナリオを現場の業務担当者に見せ、抜けを補完する。
「ITに不慣れな業務担当者でも迷わず実行できる粒度」が目安です。
UAT実施のスケジュール目安と社内体制
実施期間は2〜4週間が一般的です。短すぎると例外シナリオまで踏み込めず、長すぎると通常業務が滞ります。
社内体制は、発注側プロジェクトオーナーがUATリーダーを兼ね、各業務領域の現場担当者を1〜2名ずつテスターとしてアサインし、バグ票・実施記録を集約する記録担当を置く構成が基本形です。実施結果は「シナリオごとの合否」「検出バグ一覧」「未実施シナリオ」を一覧化し、毎日ベンダーと共有します。
受入テスト 発注者 確認方法は、業務担当者が現場の言葉でシナリオを実行し合否を記録に残せる仕組みをつくることに尽きます。UATのチェックリストや工程別の具体的な確認項目についてはUATの進め方で詳しく解説しています。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
テスト合格基準の設定方法（何をもってOKとするか）
ここではテストを承認する側の発注者として、何をもって合格と判断するかを整理します。読み順としてはUATの後ですが、内容はテスト工程開始前にベンダーと合意しておくべき事項です。UATで何を確認するかを理解した上で読むと、各項目が「なぜ必要なのか」が腑に落ちやすくなります。
合格基準を事前合意しないと起きるトラブル
合格基準を文書化せずにテスト工程に入ると、UAT終結時にベンダーは「軽微なバグは残ったが致命的なものはない、合格でよい」と主張し、発注者は「気になる動作がまだ多い、受け入れられない」と主張する対立が起きます。「合格」のイメージが言語化されていないため合意形成に時間がかかり、リリースが遅延します。
これを防ぐには、テスト工程の開始前に「どの状態になればUATを終結とし、テストを承認するか」を数値・条件で合意し文書化しておく必要があります。
合格基準の具体例
合格基準は次の4軸で設定するのが実務的です。
- バグ残存数の基準: 致命的バグ0件、重大バグ3件以下、軽微バグは本番後対応で許容、など。
- 業務シナリオ網羅率: UATで設計した業務シナリオの100%を実施完了し、合格であること。
- 非機能要件の達成: 性能・セキュリティ・運用要件のすべてが合意値を満たしていること。
- 業務担当者の受入判定: 各業務領域の責任者が「業務として使える」と判定書に署名していること。
これらを「合格基準書」または「UAT終結条件書」として文書化し、ベンダーと相互合意します。
合格基準をベンダーと合意するタイミングと文書化の方法
合意はシステムテスト開始前が理想で、遅くともUAT開始2週間前までには文書化を済ませます。テスト計画書に「終結条件」として組み込み、基準値の根拠と未達時の対応方針も併記しておくと判定で揉めません。途中で達成不能と判明した場合は再合意して文書を更新します。最初の基準を絶対視せず、都度合意して動かす運用が現実的なリリースに繋がります。
バグ発見時の対応フロー・修正依頼と優先度の決め方
UATで発見したバグをどう報告し、どの優先度で扱うかは、リリース可否を左右する判断です。「全部直してほしい」要求がリリース遅延を招くトレードオフを意識しながら判定軸を整理します。
バグ報告書に書くべき情報
ベンダーが再現・原因究明・修正できる粒度で情報を残します。発生環境（環境名・ブラウザ／OS・データ状態）、再現手順（ステップ単位で順序明示）、期待動作と実際の動作、スクリーンショット／ログ、業務影響度の初期評価。これらが揃っていないと「再現できません」「仕様通りです」と返され、修正対応が進まないまま時間が過ぎます。
バグ優先度の判定軸
優先度は「業務影響度 × 発生頻度」のマトリクスで判定します。
影響度: 大（業務停止） | 影響度: 中（業務支障あり） | 影響度: 小（運用回避可能） | |
|---|---|---|---|
頻度: 高（毎日発生） | 致命的（即時修正） | 重大（リリース前修正） | 軽微（リリース後でも可） |
頻度: 中（週次発生） | 致命的（即時修正） | 重大（リリース前修正） | 軽微（リリース後でも可） |
頻度: 低（月次以下） | 重大（リリース前修正） | 軽微（リリース後でも可） | 軽微（リリース後でも可） |
事前共有しておくと優先度判定で揉めにくくなります。致命的・重大のみリリース前修正、軽微は本番後の継続改善で対応する判断軸が、リリース時期を守る鍵です。
リリース可否を決める最終判定
UATをすべて実施し合格基準と照合した結果、発注者がテストを承認するか否かの最終判定を下します。判定パターンは3つです。
- 完全合格（無条件受入）: 合格基準を全項目満たし、リリース許可。
- 条件付き受入: 軽微バグの本番後修正計画と暫定運用回避策をベンダーと合意した上でリリース許可。
- 差し戻し: 致命的・重大バグの残存または業務シナリオの未消化があり、再UATを実施。
条件付き受入を選ぶ場合は「いつまでに」「どのバグを」「どう修正するか」を文書化し、本番後の対応漏れを防ぎます。「テストを承認する」判断はリリース後の運用責任までを引き受ける宣言だと意識して臨むのが望ましい姿勢です。
テスト工程後の本番移行・運用開始に向けた準備
UAT合格判定が出てから本番準備を始めるとトラブルが集中します。テスト工程の後半から並行して本番移行の準備を進めるのが安全策です。UAT実施中から進めておきたい準備は次の通りです。
- 業務手順書の整備: UATシナリオをベースにマニュアル・操作手順書を作成し、分かりにくい操作は補強しておく。
- 社内ユーザー研修: 集合研修・eラーニング・OJTを設計し、UAT終結直後〜本番リリースの間に日程を確保する。
- 初期サポート体制: 問い合わせ窓口・エスカレーション経路・緊急対応SLAをベンダーと合意。リリース初日〜1週間はベンダー常駐対応も検討する。
- データ移行と切り戻し条件: 移行リハーサル・本番移行手順・切り戻し条件を文書化し、双方で事前合意する。
テスト工程の前半から本番移行を視野に入れた段取りを組み、テストと運用準備を地続きで進めることがリリース後の安定運用に繋がります。
まとめ — テスト工程で発注者が押さえるべき要点
テスト工程で発注者が担うべき役割を4つの要点に集約します。
- フェーズ別関与レベルを濃淡で設計する: 単体・結合はノータッチで進捗監視のみ、システムテストは報告書確認＋一部立ち会い、UATは主体的に実施。
- UATは業務観点で4種類のテストを実施する: 機能確認・業務シナリオ・連携・例外処理を、自社業務フローから逆算したテストケースで確認する。
- 合格基準を事前に文書化し合意する: バグ残存数・業務シナリオ網羅率・非機能要件・業務担当者の受入判定を、テスト工程開始前にベンダーと合意する。
- バグ優先度はマトリクスで判定する: 致命的・重大のみリライト前修正に絞り、軽微は本番後対応で割り切る。
テスト工程は品質確認の場であり、発注者が納品承認の判断軸を作る場でもあります。関与レベルとUATの進め方を参考に、自社プロジェクトの現在位置と次のToDoを整理してみましょう。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
