最終更新日：2026年10月1日
fe fe-strategy system-strategy
まず結論
全体最適化計画で業務モデルを定義する目的は、組織全体の業務と情報の関係を整理し、情報システムのあるべき姿を明確にすることです。
用語の注意： 「全体最適化計画」「開発計画」は、旧「システム管理基準」を前提とする過去問で見かける表現です。現在のFEシラバスでは、システム化構想・システム化計画を中心に学習します。古い過去問は当時の用語で解き、現在の学習用語へ読み替えて理解するのが安全です。
基本情報技術者試験では、次のように切り分けると判断しやすくなります。
あるべき姿を描く
→ 全体最適化・業務モデル
期間・工数・費用を見積もる
→ システム化計画
HW・SW・ネットワーク構成を決める
→ システム方式設計
試験直前は、次の一文で整理します。
「業務全体と情報の関係を整理して、将来のあるべき姿を描く」なら業務モデル。
直感的な説明
いきなり「どのサーバを使うか」「何か月で作るか」を考えるのではなく、まず会社全体として何を目指すかを整理します。
イメージは次の順番です。
現在の業務を整理する
↓
業務と情報の関係を見る
↓
将来どうあるべきかを描く
↓
その姿を実現するシステムを考える
この最初の大きな設計図に当たるのが、全体最適化や業務モデルの考え方です。
FEでは、「全体」「業務」「情報」「あるべき姿」という言葉がそろっていたら、業務モデルを強く疑います。
定義・仕組み
IPAの基本情報技術者試験シラバスでは、エンタープライズアーキテクチャ（EA）について、組織全体の業務とシステムを統一的にモデル化し、全体最適化を図る考え方として整理されています。
また、業務・データ・アプリケーション・技術の各アーキテクチャを整理し、現状と理想像を表現することが示されています。
業務モデル
業務モデルは、企業や組織の業務を整理し、業務同士の関係や、そこで利用される情報との関係を表すものです。
重要なのは、単に現在の業務を書き写すことではありません。
現状を整理する
＋
目標とする業務の姿を考える
→ あるべき姿を明確にする
という目的があります。
システム化計画との違い
システム化計画では、対象範囲や規模、期間、工数、費用など、システム化を具体的に進めるための計画を整理します。
何を目指す？
→ 全体最適化・業務モデル
どれくらいの規模で、いつまでに、いくらで？
→ システム化計画
システム方式設計との違い
システム方式設計では、システムを実現するために必要なハードウェア、ソフトウェア、ネットワークなどの構成を考えます。
業務のあるべき姿
→ 業務モデル
システムを何で構成するか
→ システム方式設計
1次情報
学習時は、次の公式資料を基準に確認できます。
IPAシラバスでは、EAについて「組織全体の業務とシステム」「全体最適化」「現状と理想像」といった観点が明記されています。
科目Aでどう出る？
科目Aでは、似た工程・活動の説明から正しいものを選ぶ問題として出題されます。
次のキーワードで切り分けると判断しやすくなります。
| 問題文のキーワード | 判断 |
|---|---|
| 全体業務・情報の関連・あるべき姿 | 全体最適化・業務モデル |
| 範囲・規模・期間・工数・費用 | システム化計画 |
| ハードウェア・ソフトウェア・ネットワーク構成 | システム方式設計 |
| 運用マニュアル・利用手順 | 運用準備寄り |
旧過去問の「開発計画」を現在のFE用語へ橋渡しする
古いFE過去問では、旧「システム管理基準」に基づき、開発計画について次のような内容を明確にする説明が出てきます。
目的・対象業務
費用
スケジュール
開発体制
投資効果
この文脈の過去問では、「費用・スケジュール・開発体制・投資効果などを明確にする計画」を開発計画と判断するのが当時の基準に沿った答えです。
一方、現在のIPA：基本情報技術者試験シラバス Ver.9.2では、学習の中心はシステム化計画の立案です。用語例として、次の内容が示されています。
- 全体開発スケジュール
- プロジェクト推進体制
- 要員教育計画
- 開発投資効果
- システムライフサイクル
- 情報システム導入リスク分析
したがって、古い問題と現在の学習は次のように橋渡しすると混乱しにくくなります。
| 学習場面 | 用語 | 判断のポイント |
|---|---|---|
| 旧「システム管理基準」を前提とする過去問 | 開発計画 | 費用・スケジュール・開発体制・投資効果など |
| 現在のFEシラバス | システム化計画 | 全体開発スケジュール・推進体制・開発投資効果など |
| 組織全体のあるべき姿を考える文脈 | 全体最適化・業務モデル | 業務と情報の関係、全体の方向性 |
古い過去問は「当時の用語で正解を選ぶ」。現在の学習では「システム化計画」へつなげて理解する。
旧基準の「開発計画」の具体的な管理項目は、経済産業省のシステム管理基準 追補版でも確認できます。
成果物名だけでなく「何を決めるか」で切り分ける
科目Aでは、古い基準の成果物名がそのまま出る問題もあれば、現在のシラバスに沿った表現が使われる問題もあります。
そのため、用語だけを丸暗記するより、次のように何を決めているかで判断します。
組織全体のあるべき姿
→ 全体最適化・業務モデル
いつ・どんな体制で・どの程度の投資で進めるか
→ システム化計画
（旧過去問では「開発計画」と表現されることがある）
HW・SW・ネットワークをどう構成するか
→ システム方式設計
単語だけで選ばず、「何を決める計画か」で切る。
特に、次の流れを覚えておくと便利です。
あるべき姿を決める
↓
計画を具体化する
↓
システム構成を決める
問題文がどの段階を説明しているかを見るのがコツです。
どんな場面で使う？
全体最適化や業務モデルは、個別システムを作る前に、組織全体として業務や情報システムの方向性を整理するときに使います。
例えば、次のような場面です。
- 部門ごとに別々のシステムがあり、全体として重複が多い
- 同じ情報を複数部門で別々に管理している
- 業務プロセスとシステムの関係を見直したい
- 将来の業務像に合わせてシステム全体を再設計したい
ここでは、個別の製品や機器を選ぶ前に、組織全体として何を目指すかを整理します。
よくある誤解・混同
業務モデルは開発費を見積もるもの
違います。
開発期間、工数、費用などの具体的な見積りは、システム化計画の側です。
あるべき姿
→ 業務モデル
期間・工数・費用
→ システム化計画
業務モデルはハードウェア構成を決めるもの
違います。
ハードウェア、ソフトウェア、ネットワークなどの構成を考えるのは、システム方式設計の側です。
「全体最適化」と書いてあれば全体最適化計画
必ずしもそうではありません。
選択肢の説明中に「全体最適化」という言葉があっても、実際に問われているのが個別システムのスケジュール・体制・投資効果なら、全体最適化そのものではありません。
試験では、キーワードだけでなく、その計画で何を決めているかまで読むことが大切です。
古い問題の「開発計画」を現在もそのまま暗記する？
おすすめしません。
旧基準の過去問では「開発計画」が正解になる問題がありますが、現在のFEシラバスではシステム化計画を中心に整理されています。
過去問を解く
→ 当時の「開発計画」で判断
現在の知識として整理する
→ 「システム化計画」へ接続
この2段階で覚えると、古い問題と現在のシラバスを混同しにくくなります。
「業務手順を確認する」と書いてあれば業務モデル
必ずしもそうではありません。
ユーザーマニュアルや運用マニュアル作成のための確認なら、運用準備の文脈です。
試験では、単語一つではなく、何のために業務を整理しているかを確認します。
全体最適化は各部門を個別に最適化すること
逆です。
各部門だけを最適化すると、組織全体では重複や不整合が残ることがあります。
部門ごとに最適
→ 部分最適
組織全体で整合
→ 全体最適
まとめ（試験直前用）
- 業務モデルは、組織全体の業務と情報の関係を整理する
- 目的は、情報システムのあるべき姿を明確にすること
- 全体最適化・業務モデルは、組織全体の業務と情報のあるべき姿を考える
- 旧「システム管理基準」の過去問では、費用・スケジュール・開発体制・投資効果などを明確にするものを開発計画と表現する場合がある
- 現在のFEシラバスでは、全体開発スケジュール・プロジェクト推進体制・開発投資効果などをシステム化計画として整理する
- HW・SW・ネットワーク構成ならシステム方式設計
- 「全体」「業務」「情報」「あるべき姿」が重要キーワード
- 古い過去問は当時の用語で解き、現在の用語へ橋渡しして覚える
- 工程名だけでなく、何を決める段階かで切り分ける
組織全体のあるべき姿
→ 全体最適化・業務モデル
費用・スケジュール・体制・投資効果
→ 旧過去問：開発計画
→ 現在 ：システム化計画
HW・SW・ネットワーク
→ システム方式設計
FEでは、古い用語をそのまま現在の用語として暗記せず、「当時の正解」と「現在の学習用語」を分けて整理する。