---
title: "企画プロセスとは？要件定義・開発プロセスとの違いを整理【基本情報技術者試験】"
description: "企画プロセスを、経営目的や業務課題からシステム化の方針を決める段階として整理し、要件定義プロセス・開発プロセスとの違いをFE試験向けに解説します。"
last_modified_at: "2026-08-16"
canonical_url: "https://stemtazoo.github.io/fe/planning-process/"
section: "fe"
---

## まず結論

企画プロセスとは、**経営上の目的や目標、業務上の課題を整理し、どのようなシステム化が必要かを決める段階**です。

基本情報技術者試験では、次の3段階で切り分けると分かりやすくなります。

```text
なぜシステム化する？
→ 企画プロセス

何を満たす必要がある？
→ 要件定義プロセス

どう作る？
→ 開発プロセス
```

特に、**「経営目的」「経営ニーズ」「業務課題」「システム化方針」** が出てきたら、企画プロセスを疑います。

## 直感的な説明

新しいシステムを作るとき、いきなり機能一覧を考えるわけではありません。

まずは、会社として何を実現したいのかを考えます。

```text
売上を伸ばしたい
業務時間を減らしたい
ミスを減らしたい
顧客対応を早くしたい
```

このような経営目的や業務課題を整理して、

```text
どこをシステム化するか
どの範囲を対象にするか
どんな方針で進めるか
```

を決めるのが企画プロセスです。

その後に、必要な機能や性能を具体化する要件定義へ進みます。

## 定義・仕組み

企画プロセスでは、経営や業務の視点から、システム化の必要性や方向性を整理します。

代表的には、次のような内容を考えます。

- 経営目的・目標
- 経営上のニーズ
- 業務上の課題
- システム化の対象範囲
- システム化の方針
- 投資や実施の基本方針

ここで重要なのは、**具体的な機能を細かく決める前の段階**だということです。

### 企画プロセス

```text
経営目的・業務課題
↓
システム化の必要性を整理
↓
システム化の方針・範囲を決める
```

### 要件定義プロセス

企画で方向性が決まったら、次は「何を実現しなければならないか」を具体化します。

```text
業務要件
機能要件
非機能要件
```

などを定義します。

### 開発プロセス

要件が決まったら、その要件を満たすシステムを設計・実装します。

```text
方式設計
詳細設計
プログラミング
テスト
```

といった工程が中心です。

このテーマは、基本情報技術者試験のシステム戦略やシステム企画に関係します。公式の出題範囲やシラバスは、[IPA：基本情報技術者試験](https://www.ipa.go.jp/shiken/kubun/fe.html) から確認できます。

## 科目Aでどう出る？

科目Aでは、各プロセスで定義する内容を入れ替えた選択肢が出やすいです。

次の表で切り分けると判断しやすくなります。

| 問題文の表現 | 主に該当するプロセス |
|---|---|
| 経営目的、経営目標、経営ニーズ | 企画プロセス |
| 業務課題、システム化の必要性 | 企画プロセス |
| システム化の方針・範囲 | 企画プロセス |
| 業務手順、責任、権限、ルール | 要件定義プロセス |
| 必要な機能 | 要件定義プロセス |
| 性能、信頼性、安全性、セキュリティ | 要件定義プロセス |
| システムの構成や方式 | 開発プロセス |
| 詳細な処理方法 | 開発プロセス |
| 実装・テスト | 開発プロセス |

迷ったら、次の3語で戻します。

```text
なぜ？
→ 企画

何を？
→ 要件定義

どうやって？
→ 開発
```

### 「経営」の言葉を見逃さない

問題文に、

```text
経営目的
経営目標
経営ニーズ
経営課題
```

が出てきたら、かなり強く企画プロセスを疑えます。

企画は、システムそのものより**経営や業務の目的から考える段階**だからです。

## どんな場面で使う？

企画プロセスは、新しいシステムを導入したり、既存システムを大きく見直したりするときに使います。

例えば、次のような場面です。

- 受注業務を効率化したい
- 在庫管理のミスを減らしたい
- 顧客情報を一元管理したい
- 古いシステムを刷新したい
- 新規事業を支えるシステムが必要になった

こうした課題に対して、まず「システム化する価値があるか」「どこまでシステム化するか」を整理します。

その後、要件定義で必要な機能や性能を具体化します。

## よくある誤解・混同

### 企画プロセスで機能要件を細かく決める？

基本的には違います。

```text
企画
→ 経営目的・業務課題から方向性を決める

要件定義
→ 必要な機能や性能を具体化する
```

「ログイン機能が必要」「応答時間は3秒以内」のような具体的な要求は、要件定義側で考えます。

### 業務手順や責任・権限は企画？

これも要件定義寄りです。

```text
誰が何をするか
どの手順で業務を行うか
どんなルールがあるか
```

は、業務要件として整理します。

### 信頼性・安全性・セキュリティは企画？

具体的な品質要求として定義する場合は、要件定義側です。

```text
信頼性
可用性
性能
安全性
セキュリティ
```

などは非機能要件として扱われます。

### システム化の方針とシステム設計は同じ？

違います。

```text
システム化の方針
→ どこを、どんな方向でシステム化するか
→ 企画

システム設計
→ どんな構成・方式で実現するか
→ 開発
```

ここは「方向性」と「具体的な作り方」の違いで切り分けます。

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

- 企画プロセスは、経営目的や業務課題からシステム化の方向性を決める
- 「経営目的・経営ニーズ・業務課題・システム化方針」が出たら企画を疑う
- 要件定義は、業務要件・機能要件・非機能要件を具体化する
- 開発プロセスは、要件を満たすシステムを設計・実装する
- 迷ったら **「なぜ？＝企画、何を？＝要件定義、どうやって？＝開発」** で切り分ける