---
title: "共通フレームとは？システム開発プロセスを共通の言葉で整理する考え方【基本情報技術者試験】"
description: "共通フレームを「システムやソフトウェア開発に関わる作業を共通のプロセス名で整理する枠組み」として押さえ、企画プロセス、要件定義、開発、運用、保守、品質保証、問題解決、文書化プロセスの違いをFE試験向けに解説します。"
last_modified_at: "2026-07-15"
canonical_url: "https://stemtazoo.github.io/fe/common-frame/"
section: "fe"
---

## まず結論

共通フレームとは、**システムやソフトウェアに関わる作業を、共通のプロセスとして整理するための枠組み**です。

基本情報技術者試験では、共通フレームを**企画、要件定義、開発、運用、保守、支援などの作業を共通の言葉で整理したもの**と考えると分かりやすいです。

古い過去問では「共通フレーム2007」と書かれていることがあります。学習では、細かい版の暗記よりも、プロセスの目的で切り分けます。

```text
経営事業の目的・目標を達成するために、
必要なシステム化の方針と実施計画を得る
→ 企画プロセス
```

試験では、**「経営目的・目標」＋「システム化方針」＋「実施計画」**が出たら、企画プロセスを疑います。

## 直感的な説明

共通フレームは、システム開発のための**共通の地図**のようなものです。

システム開発には、利用者、発注者、開発者、運用担当者、保守担当者など、いろいろな立場の人が関わります。

```text
経営層：事業目標を達成したい
業務部門：業務をこう変えたい
情報システム部門：システムとして実現したい
開発者：仕様に沿って作りたい
運用担当：安定して使えるようにしたい
```

共通フレームでは、こうした作業を共通のプロセスとして整理します。

つまり、共通フレームは**関係者が同じ地図を見ながら、どの作業の話をしているかを合わせるための枠組み**です。

## 定義・仕組み

共通フレームでは、システムやソフトウェアのライフサイクルに関わる作業を、プロセスとして整理します。

| プロセス群・視点 | 役割のイメージ |
|---|---|
| 合意プロセス | 取得や供給など、契約・合意に関わる |
| 企画プロセス | 経営目的を達成するためのシステム化方針と実施計画を得る |
| 要件定義プロセス | 利用者や業務から見た要求を明確にする |
| 開発プロセス | システムやソフトウェアを設計・実装・テストする |
| 運用プロセス | 稼働したシステムを使い続けられるようにする |
| 保守プロセス | 稼働後の変更や修正に対応する |
| マネジメントプロセス | プロジェクト、品質、リスクなどを管理する |
| 支援プロセス | 品質保証、検証、妥当性確認、文書化、問題解決などで活動を支える |

共通フレームのポイントは、具体的な開発手法そのものではなく、**作業をどのようなプロセスとして整理するか**にあります。

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

共通フレームは、国際規格のシステムライフサイクルプロセスやソフトウェアライフサイクルプロセスの考え方と関係します。一次情報としては、[ISO：ISO/IEC/IEEE 15288:2023](https://www.iso.org/standard/81702.html) や [ISO：ISO/IEC/IEEE 12207:2017](https://www.iso.org/standard/63712.html) も確認先になります。

## 科目Aでどう出る？

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

判断するときは、プロセス名の細部よりも、まず**何をしている活動か**を見ます。

| 問題文・選択肢の表現 | 見る方向 |
|---|---|
| 経営事業の目的・目標、システム化の方針、実施計画 | 企画プロセス |
| 利用者の要求を明確にする、業務要件を整理する | 要件定義プロセス |
| 設計、実装、テストを行う | 開発プロセス |
| 稼働後にシステムを使い続ける | 運用プロセス |
| 稼働後の変更・修正に対応する | 保守プロセス |
| 作業成果物やプロセスが条件・計画に従っていることを保証する | 品質保証プロセス |
| 発見された問題を識別・分析・管理・制御し、解決する | 問題解決プロセス |
| 生成・記録された情報を文書化し、保守する | 文書化プロセス |
| 仕様どおりか確認する | 検証プロセス |
| 利用者の目的に合っているか確認する | 妥当性確認プロセス |

```text
方針・計画を得る → 企画
条件・計画どおりを保証 → 品質保証
問題を解決 → 問題解決
情報を文書化 → 文書化
```

### 企画と要件定義を切り分ける

この2つは特に混同しやすいです。

```text
経営目的から、システム化方針と実施計画を得る
→ 企画プロセス

利用者・業務の要求を明確にする
→ 要件定義プロセス
```

「経営目的・目標」が出てきたら企画側、「利用者や業務の要求」が出てきたら要件定義側に寄せて考えます。

## どんな場面で使う？

共通フレームは、発注者・利用者・開発者・運用担当者などが、システムのライフサイクル全体を共通の言葉で整理するときに使います。

```text
経営目標から方針を決める
→ 企画

業務要求を明確にする
→ 要件定義

設計・実装・テストを行う
→ 開発

稼働後に利用・監視する
→ 運用

稼働後に修正・変更する
→ 保守
```

共通フレームは、ウォーターフォールやアジャイルのような開発手法ではありません。

どの手法を採用する場合でも、関係者間で作業や責任の認識をそろえるための枠組みとして使われます。

## よくある誤解・混同

| 誤解 | 正しい理解 |
|---|---|
| 共通フレームはウォーターフォールやアジャイルの一種 | 開発手法ではなく、作業を共通のプロセスとして整理する枠組み |
| 共通フレームは開発者だけが使う | 発注者、利用者、開発者、運用担当など関係者全体に関わる |
| 企画プロセスは要件定義と同じ | 企画は経営目的からシステム化方針・実施計画を得る。要件定義は要求を明確にする |
| 品質保証はテストそのもの | 成果物やプロセスが計画・基準に従っていることを保証する活動 |
| 問題解決は開発そのもの | 発見された問題を識別・分析・管理・制御し、解決する活動 |
| 文書化は設計だけの作業 | プロセスで生成・記録された情報を文書化し、保守する活動 |
| 検証と妥当性確認は同じ | 検証は仕様どおり、妥当性確認は利用者の目的どおり |

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

- 共通フレームは、システム開発や運用の作業を共通のプロセスで整理する枠組み
- 企画プロセスは、経営目的・目標を達成するためのシステム化方針と実施計画を得る
- 要件定義プロセスは、利用者や業務の要求を明確にする
- 品質保証は条件・計画への適合を保証し、問題解決は問題を識別・分析して解決する
- 「仕様どおりか」は検証、「利用者の目的どおりか」は妥当性確認