---
title: "共通フレームの支援プロセスとは？検証・妥当性確認・監査の違い【基本情報技術者試験】"
description: "共通フレームの支援プロセスを「成果物やプロセスを横から支える活動」として整理し、検証、妥当性確認、監査、使用性向上の違いをFE試験の選択肢で切れる形で解説します。"
last_modified_at: "2026-07-25"
canonical_url: "https://stemtazoo.github.io/fe/common-frame-support-processes/"
section: "fe"
---

## まず結論

共通フレームの支援プロセスとは、**開発・運用・保守などの主な作業を横から支えるためのプロセス群**です。

基本情報技術者試験では、支援プロセスの中でも **検証プロセス、妥当性確認プロセス、監査プロセス、使用性向上プロセス** の切り分けが出題されやすいです。

特に大切なのは、次の違いです。

| プロセス | ひとことでいうと |
|---|---|
| 検証プロセス | 仕様や要件どおりに作れているかを確認する |
| 妥当性確認プロセス | 利用者の目的や使い方に合っているかを確認する |
| 監査プロセス | 独立した立場で適合性を確認する |
| 使用性向上プロセス | 利用者にとって使いやすくする |

試験では、**仕様どおりか** と **利用者の意図どおりか** を分けると、かなり選択肢を切りやすくなります。

## 直感的な説明

検証と妥当性確認は、似ていますが見る方向が違います。

よく使われる英語の考え方でいうと、次の違いです。

```text
検証：Are we building the product right?
妥当性確認：Are we building the right product?
```

日本語にすると、こうです。

```text
検証：決められた仕様どおりに作れているか
妥当性確認：利用者が本当に欲しかったものになっているか
```

例えば、注文システムを作るとします。

仕様書に「注文ボタンを押すと注文が登録される」と書かれていて、その通りに動けば、検証の観点では正しいです。

でも、利用者が本当に求めていたのが「注文前に内容を確認できる画面」だった場合、利用者の目的に合っていないかもしれません。

このように、**仕様どおりかを見るのが検証、利用者にとって意図したものかを見るのが妥当性確認** です。

## 定義・仕組み

共通フレームは、システムやソフトウェアの企画、開発、運用、保守などの作業を、共通のプロセスとして整理する考え方です。

その中で支援プロセスは、特定の工程だけでなく、いろいろな場面で横断的に使われます。

FE試験では、支援プロセス全体を細かく暗記するよりも、混同しやすいものを切り分けることが大切です。

| プロセス | 確認すること | 判断キーワード |
|---|---|---|
| 検証プロセス | 成果物やサービスが規定された要求を満たしているか | 要求、仕様、規定、反映 |
| 妥当性確認プロセス | 指定された使用方法や利用者の意図に合っているか | 利用者、使用方法、意図、目的 |
| 監査プロセス | 要求、計画、合意に適合しているかを独立した立場で確認する | 独立、監査、適合、合意 |
| 使用性向上プロセス | 利用者の効率性や満足度を高める | ユーザビリティ、使いやすさ、満足度 |
| 品質保証プロセス | 品質に関する活動が適切に行われるようにする | 品質保証、品質計画、品質活動 |
| 問題解決プロセス | 発生した問題を分析し、解決する | 問題、原因、是正、解決 |

このテーマは、基本情報技術者試験の「ソフトウェア開発」や「システム開発技術」と関係する内容です。公式の出題範囲やシラバスは、[IPA：基本情報技術者試験](https://www.ipa.go.jp/shiken/kubun/fe.html) から確認できます。

## 科目Aでどう出る？

科目Aでは、共通フレームのプロセス名と説明を対応させる問題で出題されやすいです。

判断するときは、問題文の中にある **見る視点** を探します。

| 問題文・選択肢の表現 | 選ぶプロセス |
|---|---|
| 作成された成果物が規定要求を反映しているか | 検証プロセス |
| 利用者の視点から意図されたものになっているか | 妥当性確認プロセス |
| 指定された使用方法に対する要件を満たしているか | 妥当性確認プロセス |
| 成果物やプロセスが要求、計画、合意に適合しているか | 監査プロセス |
| 独立した立場から確認する | 監査プロセス |
| ユーザビリティを高める | 使用性向上プロセス |
| 利用者の効率性や満足度を高める | 使用性向上プロセス |

特に、検証と妥当性確認はかなり似ています。

```text
仕様どおり？ → 検証
利用者の目的どおり？ → 妥当性確認
```

この2つを分けられると、共通フレームの問題はかなり解きやすくなります。

## どんな場面で使う？


システム開発やテスト工程の説明文を読むときに、**誰の視点で何を確認しているか** を整理する力は役立ちます。

例えば、次のように読み分けます。

```text
開発側が仕様との一致を見る
→ 検証

利用者側の目的や使用方法に合うかを見る
→ 妥当性確認

第三者・独立した立場で適合性を見る
→ 監査

使いやすさを改善する
→ 使用性向上
```

問題文では、文章が長くなるほど、どの言葉が判断材料なのかを見失いやすくなります。

そのため、**仕様、利用者、独立、使いやすさ** の4語を拾うと判断しやすくなります。

## よくある誤解・混同

共通フレームの支援プロセスで一番混同しやすいのは、検証プロセスと妥当性確認プロセスです。

| 誤解 | 正しい理解 |
|---|---|
| 検証も妥当性確認も同じ | 検証は仕様どおり、妥当性確認は利用者の目的どおり |
| 利用者の視点とあれば検証 | 利用者の視点なら妥当性確認を疑う |
| 独立した立場で確認すれば妥当性確認 | 独立した立場なら監査プロセス |
| 使いやすさの確認は妥当性確認だけ | ユーザビリティ向上なら使用性向上プロセス |
| 監査は成果物を作るプロセス | 監査は適合性を独立して確認するプロセス |

試験では、次のように切り分けると迷いにくいです。

```text
要求・仕様・規定 → 検証
利用者・使用方法・意図 → 妥当性確認
独立・適合・合意 → 監査
ユーザビリティ・効率・満足度 → 使用性向上
```

特に、**利用者の視点から意図された正しいものか** という表現は、妥当性確認プロセスを選ぶ重要なサインです。

## まとめ（試験直前用）

- 共通フレームの支援プロセスは、開発や運用を横から支えるプロセス群
- 検証プロセスは、仕様や要件どおりに作れているかを見る
- 妥当性確認プロセスは、利用者の目的や使用方法に合っているかを見る
- 監査プロセスは、独立した立場で適合性を見る
- 使用性向上プロセスは、ユーザビリティや満足度を高める
- 「仕様どおりか」と「利用者の意図どおりか」を分ける