--- title: "検証と妥当性確認の違い｜仕様どおりか・利用目的に合うかで判断【基本情報技術者試験】" description: "検証は成果物が仕様や要求どおりに作られているか、妥当性確認は利用者の意図や利用目的を満たしているかを確認します。使用性向上や監査との違いも含め、FE試験での切り分け方を整理します。" last_modified_at: "2026-08-17" canonical_url: "https://stemtazoo.github.io/fe/verification-validation/" section: "fe" --- ## まず結論 **検証（Verification）**は、作った成果物が**仕様や要求どおりになっているか**を確認することです。 **妥当性確認（Validation）**は、作った成果物が**利用者の意図や実際の利用目的に合っているか**を確認することです。 FE試験では、次のように切り分けると判断しやすくなります。 ```text 仕様どおりに作れた？ → 検証 利用者が本当に必要とするものになった？ → 妥当性確認 ``` 英語では、次の言い回しで覚える方法もあります。 ```text Verification → Are we building the product right? Validation → Are we building the right product? ``` ## 直感的な説明 新しい在庫管理システムを作る場面を考えます。 設計書には、次のように書かれているとします。 - 商品コードを入力すると在庫数を表示する - 在庫数が0なら警告を表示する - 入出庫履歴を保存する 完成したシステムが、この設計書どおりに動くかを確認するのが**検証**です。 ```text 設計書に書いたとおり動く？ → 検証 ``` しかし、設計書どおりに動いたとしても、実際の倉庫担当者が必要とする仕事を十分にできるとは限りません。 たとえば、現場では「複数倉庫をまとめて検索したい」という要望があるのに、その機能が設計に入っていなければ、設計書どおりに作れていても利用目的を十分に満たしていません。 このように、**実際に使う人の目的に合っているか**を見るのが妥当性確認です。 ## 定義・仕組み ### 検証とは 検証は、ソフトウェアやシステムの成果物が、定められた要求や仕様に適合しているかを確認する考え方です。 確認対象には、たとえば次のようなものがあります。 - 要件定義書 - 設計書 - プログラム - テスト結果 - 各種ドキュメント 判断の中心は、**決められた内容を正しく反映しているか**です。 ```text 要求仕様 ↓ 設計 ↓ 実装 ↓ 仕様と一致しているか確認 → 検証 ``` ### 妥当性確認とは 妥当性確認は、完成した成果物やサービスが、意図した利用目的や利用者のニーズを満たしているかを確認する考え方です。 判断の中心は、**本当に必要なものを作れているか**です。 ```text 利用者の目的 ↓ 実際に使う ↓ 期待した仕事ができるか確認 → 妥当性確認 ``` ### 検証と妥当性確認の比較 | 観点 | 検証 | 妥当性確認 | |---|---|---| | 英語 | Verification | Validation | | 主な確認対象 | 仕様・要求との一致 | 利用目的・利用者ニーズとの一致 | | 判断の問い | 正しく作ったか | 正しいものを作ったか | | 視点 | 開発成果物・仕様 | 利用者・実運用 | ## 科目Aでどう出る？ 科目Aでは、説明文を読んで「検証」「妥当性確認」「使用性向上」「監査」などを選ばせる問題として出やすいです。 まず、問題文に何が書かれているかを見ます。 ```text 仕様書どおり 規定要求を反映 設計どおり → 検証 利用者の視点 意図した利用目的 本当に必要な機能 → 妥当性確認 ``` ### 使用性向上との違い 「利用者」という言葉があるだけで妥当性確認とは限りません。 ```text 必要な仕事ができるか → 妥当性確認 操作しやすいか 分かりやすいか 効率よく使えるか → 使用性・ユーザビリティ ``` たとえば、ボタンの位置を分かりやすくしたり、入力手順を短くしたりするのは、主に使用性向上の話です。 ### 監査との違い 監査は、独立した立場から、対象となる成果物やプロセスが要求・計画・合意などに適合しているかを確認します。 ```text 仕様との一致を確認 → 検証 利用目的との一致を確認 → 妥当性確認 独立した立場から適合性を確認 → 監査 ``` ## どんな場面で使う？ ### 開発途中で仕様とのズレを確認する 設計書やプログラムが、要求仕様に沿っているかを確認します。 これは検証の考え方です。 ### 完成後に利用者の目的を満たせるか確認する 実際の利用者がシステムを使い、業務上必要な処理ができるかを確認します。 これは妥当性確認の考え方です。 ### 受入れテストとの関係 利用者や発注者の立場で、実際の利用目的を満たしているかを見る場面では、妥当性確認の考え方が特に重要です。 ただし、受入れテストという言葉だけで機械的に判断せず、**何を確認しているのか**を見ることが大切です。 ## よくある誤解・混同 ### 検証と妥当性確認は同じ 違います。 ```text 検証 → 仕様どおりか 妥当性確認 → 目的に合っているか ``` この2つを混同しないことが最重要です。 ### 利用者が登場したら必ず使用性向上 違います。 利用者の目的やニーズを満たしているかを見るなら、妥当性確認です。 操作のしやすさや分かりやすさを改善するなら、使用性向上です。 ### 仕様どおりなら妥当性も必ず満たす そうとは限りません。 仕様そのものが利用者のニーズを十分に反映していなければ、仕様どおりに作れていても、実際の目的には合わないことがあります。 つまり、 ```text 検証に合格 ≠ 必ず妥当性もOK ``` です。 ## 確認問題（FE試験対策） ある会社が配送管理システムを開発した。開発チームは、設計書に記載された配送先登録・配送状況表示・到着予定時刻計算の各機能が仕様どおりに動作することを確認済みである。 その後、実際の配車担当者にシステムを使ってもらい、日々の配送計画を作成するうえで必要な情報がそろっており、業務の目的を満たせるかを確認した。 後半の確認として最も適切なものはどれか。 - ア. 監査 - イ. 検証 - ウ. 使用性向上 - エ. 妥当性確認
▶ クリックして答えと解説を見る（ここを開く） **正解：エ** 後半では、実際の利用者である配車担当者が、日々の業務目的を満たせるかを確認しています。 これは、成果物が利用目的や利用者のニーズに合っているかを見る**妥当性確認**です。 一方、前半の「設計書に記載された機能が仕様どおりに動くか」という確認は、**検証**に当たります。 👉 判断ポイント **仕様どおりか → 検証、目的に合うか → 妥当性確認**です。
## まとめ（試験直前用） - 検証は、成果物が仕様・要求どおりかを確認する - 妥当性確認は、成果物が利用目的・利用者ニーズに合うかを確認する - 「仕様どおり？」なら検証 - 「本当に必要なもの？」なら妥当性確認 - 「使いやすい？」なら使用性・ユーザビリティ > **Verification = 正しく作ったか、Validation = 正しいものを作ったか**