企画プロセスとは？要件定義・開発プロセスとの違いを整理【基本情報技術者試験】

まず結論

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

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

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

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

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

特に、「経営目的」「経営ニーズ」「業務課題」「システム化方針」「情報技術動向の調査・分析」 が出てきたら、企画プロセスを疑います。

直感的な説明

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

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

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

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

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

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

例えばAIを使う場合でも、企画段階で考えるのは「AIをどう実装するか」ではなく、AIなどの技術を事業や業務にどう生かせるかです。

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

定義・仕組み

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

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

経営目的・目標
経営上のニーズ
業務上の課題
事業環境・業務環境の調査分析
現行業務・システムの調査分析
情報技術動向の調査分析
システム化の対象範囲
システム化の方針
投資や実施の基本方針

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

企画プロセス

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

システム化構想の立案

企画プロセスの中では、経営上のニーズや課題を確認し、事業・業務・技術の状況を調べながら、システム化の方向性を考えます。

IPAの「共通フレーム2013」に基づく資料では、システム化構想の立案に、次のような作業が示されています。

経営上のニーズ、課題の確認
↓
事業環境、業務環境の調査分析
↓
現行業務、システムの調査分析
↓
情報技術動向の調査分析
↓
対象となる業務の明確化
↓
業務の新全体像の作成
↓
対象となる業務と投資目標の策定

ここで試験対策として特に重要なのが、「情報技術動向の調査分析」も企画段階の作業だという点です。

例えば、

AIの技術動向を調べる
↓
顧客対応の省力化や品質向上に使えるか分析する
↓
システム化の方向性を考える

という流れは、具体的なAIシステムを設計しているのではなく、技術を事業にどう活用するかを検討しているので企画です。

一次情報として、IPAが公開している「共通フレーム2013」に基づく調達管理ガイド（試作版）では、「システム化構想の立案」のタスクとして「情報技術動向の調査分析」などが確認できます。

また、IPA：共通フレーム2013では、共通フレーム2013を、システムの構想から開発・運用・保守・廃棄までのライフサイクルを共通の枠組みで整理したものとして公開しています。

要件定義プロセス

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

業務要件
機能要件
非機能要件

などを定義します。

開発プロセス

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

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

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

このテーマは、基本情報技術者試験のシステム戦略やシステム企画に関係します。公式の出題範囲やシラバスは、IPA：基本情報技術者試験から確認できます。

科目Aでどう出る？

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

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

問題文の表現	主に該当するプロセス
経営目的、経営目標、経営ニーズ	企画プロセス
業務課題、システム化の必要性	企画プロセス
システム化の方針・範囲	企画プロセス
AI・クラウドなど情報技術動向の調査分析	企画プロセス
情報技術を事業や業務にどう活用するか分析	企画プロセス
業務手順、責任、権限、ルール	要件定義プロセス
必要な機能	要件定義プロセス
性能、信頼性、安全性、セキュリティ	要件定義プロセス
システムの構成や方式	開発プロセス
詳細な処理方法	開発プロセス
実装・テスト	開発プロセス

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

なぜ？
→ 企画

何を？
→ 要件定義

どうやって？
→ 開発

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

問題文に、

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

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

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

「AI」という言葉だけで開発と決めない

試験では、AIやクラウドなど具体的な技術名が出ても、それだけで開発プロセスとは判断できません。

AIの動向を調査する
AIを業務にどう活用できるか分析する
→ 企画

AIを使ったシステムに必要な機能・性能を決める
→ 要件定義

AIをどのような構成・方式で実現するか決める
→ 開発

技術をどう事業に使う？ → 企画

と切り分けると判断しやすくなります。

どんな場面で使う？

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

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

受注業務を効率化したい
在庫管理のミスを減らしたい
顧客情報を一元管理したい
古いシステムを刷新したい
AIやクラウドなど新しい技術を業務に活用したい
新規事業を支えるシステムが必要になった

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

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

よくある誤解・混同

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

基本的には違います。

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

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

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

AIの技術動向を調べるのは開発？

必ずしもそうではありません。

AIなどの情報技術について、

どんな技術があるか
業務のどこに使えるか
どんな効果が期待できるか

を調査・分析している段階なら、システム化構想を考える企画プロセスです。

一方で、具体的なシステム構成や実装方式を決めているなら開発側です。

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

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

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

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

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

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

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

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

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

違います。

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

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

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

まとめ（試験直前用）

企画プロセスは、経営目的や業務課題からシステム化の方向性を決める
「経営目的・経営ニーズ・業務課題・システム化方針」が出たら企画を疑う
情報技術動向の調査分析も、システム化構想の立案に含まれる
AIなどの技術名ではなく、「技術を事業にどう使うか」なら企画と判断する
要件定義は、業務要件・機能要件・非機能要件を具体化する
開発プロセスは、要件を満たすシステムを設計・実装する
迷ったら 「なぜ？＝企画、何を？＝要件定義、どうやって？＝開発」 で切り分ける

🔗 関連記事

🏠 基本情報技術者トップに戻る