この章で学ぶこと
システム戦略と企画は 5〜7 問程度出題される領域です。RFI/RFP・要件定義など調達フェーズの用語が頻出。
学習ゴール
この章を読み終えた時点で、以下ができるようになっていることを目指します。
- 情報システム戦略と EA(Enterprise Architecture)の役割を判別できる
- BPR・BPM・業務モデリングの違いを使いこなせる
- RFI・RFP・提案依頼の流れを判別して、調達プロセスを説明できる
- 要件定義(機能要件・非機能要件)を判別できる
- SaaS・PaaS・IaaS の違いと選定基準を使いこなせる
1. 情報システム戦略
1.1 IT ガバナンスと EA
- IT ガバナンス — IT を経営戦略に整合させる統制
- EA(Enterprise Architecture) — 組織全体の業務・システムを **4 階層に分けて体系化**するフレームワーク
| 階層 | 略称 | 名称 | 内容 |
| 1(業務寄り) | BA | ビジネスアーキテクチャ | 業務体系(業務プロセス・組織) |
| 2 | DA | データアーキテクチャ | データ体系(データモデル・項目) |
| 3 | AA | アプリケーションアーキテクチャ | システム体系(業務システム群) |
| 4(技術寄り) | TA | テクノロジアーキテクチャ | 技術体系(OS・DB・ネットワーク 等) |
上位(業務)↔ 下位(技術)の整合性を保つ。覚え方: Biz → Data → App → Tech。
覚え方: 上から BA → DA → AA → TA の頭文字。「Biz → Data → App → Tech」と「業務寄りから技術寄りへ」の順番。
1.2 BCP と BCM
- BCP(Business Continuity Plan) — 事業継続計画。災害・事故時に事業を継続する計画
- BCM(Business Continuity Management) — BCP を**継続的に見直す**管理活動
- RTO(Recovery Time Objective) — 目標復旧時間(どこまで早く復旧すべきか)
- RPO(Recovery Point Objective) — 目標復旧時点(どこまで前のデータに戻ってもよいか)
- ディザスタリカバリ(DR) — 災害時のシステム復旧
RTO と RPO の違い(時間軸での位置)
直近のバックアップ ──── ⚠災害発生 ──── 復旧完了
| 区間 | 略称 | 意味 |
|---|
| バックアップ → 災害 | RPO(Recovery Point Objective) | 失われるデータの時間幅 |
| 災害 → 復旧 | RTO(Recovery Time Objective) | サービス停止時間 |
小さいほど厳しい目標(要投資)。RTO=2 時間 / RPO=1 時間なら「1 時間前まで遡って復旧でき、2 時間以内にサービス再開」が要件。
頻出引っかけ: RTO(Recovery Time Objective)= 時間、RPO(Recovery Point Objective)= ポイント(時点)。Time の T、Point の P で覚える。RTO は「停止時間の許容上限」、RPO は「失っていいデータの時間幅」。RTO=2 時間 / RPO=1 時間なら「1 時間前まで遡って復旧でき、2 時間以内にサービス再開」が要件。
1.3 情報システム戦略関連用語
| 用語 | 意味 |
|---|
| SoR | Systems of Record。基幹系(記録・管理) |
| SoE | Systems of Engagement。顧客接点系 |
| SoI | Systems of Insight。データ分析系 |
| DX | Digital Transformation。デジタル変革 |
2. 業務プロセスと業務改革
2.1 BPR と BPM
- BPR(Business Process Re-engineering) — 業務プロセスの**抜本的再設計**(一気にやり直す)
- BPM(Business Process Management) — 業務プロセスの**継続的改善**(少しずつ磨き続ける)
- BPO(Business Process Outsourcing) — 業務プロセスの**外部委託**
- ワークフローシステム — 業務の流れを電子化して管理
頻出引っかけ: BPR は破壊的・革命的・一回、BPM は継続的・進化的・サイクル型。「Re-engineering の Re = やり直し」、「Management の M = 継続的に管理」と区別。
2.2 業務可視化の手法
| 手法 | 用途 |
|---|
| DFD(Data Flow Diagram) | データの流れを可視化 |
| BPMN | Business Process Model and Notation。業務プロセス記述 |
| ERD | エンティティ関連図(データモデル) |
| UML | 統一モデリング言語(システム設計に多用) |
2.3 データ利活用
- データサイエンティスト — データから価値を引き出す専門家
- データドリブン経営 — データに基づく意思決定
- BI(Business Intelligence) — ビジネスデータの分析・可視化
- ETL — Extract・Transform・Load。データ統合処理
- データウェアハウス(DWH) — 分析用に統合されたデータ格納庫
- データレイク — 生データを保管する大容量ストレージ
3. ソリューションビジネス
3.1 クラウドサービスの形態
| 略称 | 正式名 | 提供範囲 | 例 |
|---|
| SaaS | Software as a Service | アプリケーション | Gmail、Salesforce |
| PaaS | Platform as a Service | 実行環境 | Heroku、Google App Engine |
| IaaS | Infrastructure as a Service | サーバ・ネットワーク | AWS EC2、Azure VM |
| DaaS | Desktop as a Service | 仮想デスクトップ | Azure Virtual Desktop |
3.2 クラウドの配置形態
- パブリッククラウド — 不特定多数向け
- プライベートクラウド — 自社専用
- ハイブリッドクラウド — 両者の組み合わせ
- マルチクラウド — 複数クラウドベンダーを併用
3.3 システム活用促進
- デジタルデバイド — IT を使える人と使えない人の格差
- アクセシビリティ — 障がい者等も含む誰もが使える状態
- ユニバーサルデザイン — 年齢・能力を問わず誰もが使えるデザイン
- リスキリング — 新しい技術・知識を学び直すこと
4. システム企画
4.1 システム企画プロセス
- システム化計画 — 全体方針決定
- 要件定義 — 必要な機能・性能の定義
- 調達 — ベンダー選定・契約
- 開発 — 次章(章 4)
- 運用・評価
4.2 調達プロセス
ベンダーからシステムを購入・委託する際は、情報収集 → 提案依頼 → 見積依頼 → 選定 → 契約の順序で進めます。各段階でベンダーに渡す書類が違うのが頻出ポイント。
- RFI(Request For Information、情報提供依頼書)— 「こんなテーマで何ができますか?」
- RFP(Request For Proposal、提案依頼書)— 「この要件で提案してください」
- RFQ(Request For Quotation、見積依頼書)— 「この内容でいくらですか?」
- ベンダー選定 — 提案 + 見積を比較評価
- 契約締結 — SLA / 納期 / 費用 / 保守等を確定
| 用語 | 意味 | 渡す内容 |
|---|
| RFI(Request For Information) | 情報提供依頼書 | 「こんなテーマで何ができますか?」 |
| RFP(Request For Proposal) | 提案依頼書 | 「この要件で提案してください」 |
| RFQ(Request For Quotation) | 見積依頼書 | 「この内容でいくらですか?」 |
| ベンダー | システム提供企業 | — |
| グリーン調達 | 環境配慮型製品を優先的に調達 | — |
| CSR 調達 | 企業の社会的責任に配慮した調達 | — |
| フェアトレード | 公正な取引条件で調達 | — |
頻出引っかけ: **RFI → RFP → RFQ の順序**は試験定番。「最初にざっくり情報収集(RFI)」→「具体的な要件で提案を募る(RFP)」→「最終的にいくらか見積もる(RFQ)」の順。逆順や RFP/RFQ の混同に注意。
4.3 要件定義
| 区分 | 内容 | 例 |
|---|
| 機能要件 | システムが**何をするか** | ログイン機能・検索機能・在庫表示 |
| 非機能要件 | どのように動くか(品質特性) | 性能・可用性・セキュリティ・保守性 |
頻出引っかけ: 「応答時間 3 秒以内」「99.9% の可用性」「SQL インジェクション対策」はすべて**非機能要件(品質特性)。一方「ログイン機能」「検索機能」「在庫表示」は機能要件**。「~を実装する」が機能、「~の品質を担保する」が非機能、と区別。
4.4 システム企画で使う手法
- フィージビリティスタディ — 実現可能性調査
- SoR/SoE の切り分け — 基幹系と接点系で異なる要件設計
- プロトタイピング — 試作モデルで要件を具体化
- ユーザーストーリー — 利用者視点の要件記述
📋 章末まとめ
最重要ポイント 10 連発
- EA の 4 階層 — BA・DA・AA・TA
- BCP と BCM の違い — 計画と継続的管理
- RTO と RPO の意味 — 時間軸と時点軸
- BPR と BPM — 抜本再設計 vs 継続改善
- SaaS/PaaS/IaaS の提供範囲 — 上位ほどユーザが管理する範囲が狭い
- RFI と RFP の順序 — 情報収集 → 提案依頼
- 機能要件と非機能要件 — 何をする vs どう動くか
- DX の意味 — IT 活用による事業変革
- DWH とデータレイク — 統合整形済み vs 生データ
- デジタルデバイド・アクセシビリティ — 共生社会の概念
出題傾向のコツ
- 英略語の意味を**日本語と英語両方で**答えられるようにする
- 調達プロセスの**順番**を問う問題が多い(RFI → RFP → 契約)
- 非機能要件は「性能・可用性・セキュリティ」を柱に整理