システム戦略とシステム企画は、午前1（科目A-1）の中で「開発が始まる前の話」だけを集めた分野です。エンタープライズアーキテクチャ、BPR、共通フレーム、RFIとRFP。どれも実務では日常語なのに、試験になると急に手が止まります。理由ははっきりしていて、この分野の用語がすべて「誰が、いつ、何を決めるか」という役割の違いでしか区別できないからです。技術的な難しさはゼロなのに、輪郭がぼやけていると全滅します。
逆に言えば、対策は明確です。計算は出ません。覚えるのは、成果物と工程の対応関係、そして似た用語を分ける軸だけです。本記事では、午前1で実際に問われる形に絞って、混同ペアの対比を中心に整理します。
なお、SC試験は2026年度からCBT方式へ移行し、試験区分の名称も変更されます。午前Ⅰが科目A-1、午前Ⅱが科目A-2、午後が科目Bという呼び方になります。これはIPAの試験要綱Ver.5.6（2026年10月の試験から適用）に反映済みで、出題範囲・出題数・試験時間に変更はありません。制度変更の詳細は「【2026年度版】情報処理安全確保支援士試験のCBT化で何が変わる？科目A/科目Bの新名称と対策の変え方」で解説しています。本記事では検索でたどり着きやすい「午前1」の呼称を主軸にしつつ、新名称を併記して進めます。
筆者はインフラエンジニアとして1999年から2005年ごろまでサーバーやルーターの設定・設計を担当し、その後、事業会社のCIOとしてIT投資の判断を行う立場になりました。受託側にいた頃はRFPが「降ってくる紙」でしたが、CIOになると自分がその紙を書く側になります。何を書き、何を書かないか。その一行の差が、半年後の揉め事の量を決めます。この分野の用語は、まさにその実務を言語化したものです。試験のための暗記に見えて、じつは発注側と受注側のどちらに立っても効く語彙です。
本シリーズの全体戦略は導入記事「元CIOが実践するスタミナ温存術！「コスパ極振り」最短エスケープルート・完全版ロードマップ」に、前回の技術戦略マネジメントは「技術戦略マネジメントを攻略！MOT・技術のSカーブ・キャズムの頻出パターン完全ガイド」にまとめています。本記事は第13回、ストラテジ系（第3部）の3本目です。
この記事で学べること
- 情報システム戦略と全体最適化計画の位置づけ、CIOの役割
- エンタープライズアーキテクチャ（EA）の4体系と、As-Is・To-Be・ギャップ分析の流れ
- BPR・BPM・BPOの違いと、業務プロセス改善に使われる道具（ワークフロー、RPA、SOA、BPMN）
- SaaS・PaaS・IaaSの区別と、クラウドの利用形態・責任共有モデル
- 共通フレームが定める企画・要件定義から保守までのプロセスと、その正しい使われ方
- 業務要件・機能要件・非機能要件の切り分けと、非機能要求グレードの6分類
- RFIとRFPの違い、調達フローと提案評価の進め方
- 午前1で狙われる混同ペアの総まとめ
午前1のシステム戦略は「決め方」の分野と割り切る
まず投資判断から入ります。この分野は覚える量に比べて、得点効率がかなり良い部類です。
出題数は少なくても、確実に1問前後は現れる
午前1は30問出題され、100点満点中60点以上で通過します。18問取れれば合格ラインです。分野ごとの出題数はIPAが公表していませんが、過去問の傾向を見る限り、ストラテジ系は8問前後で、そのうちシステム戦略・システム企画に割かれるのは1問から2問というのが実感です。
しかもこの1問から2問は、問われ方が驚くほど安定しています。「EAのビジネスアーキテクチャに該当する成果物はどれか」「RFIの説明はどれか」「BPRの説明はどれか」。用語の定義を問う形と、調達の順序を問う形。この2つでほぼ尽きます。過去に出た問題がそのままの形で再出題されることも珍しくありません。
つまりこの分野は、「用語の輪郭さえ持てば取れる」という費用対効果の良いポジションにあります。テクノロジ系の学習で疲れた日に、短時間で回すのに向いています。
取る問題はEA・BPR・クラウド・RFIとRFP
優先して押さえるのは次の4つです。
1つ目はEA（エンタープライズアーキテクチャ）の4体系です。 ビジネス、データ、アプリケーション、テクノロジ。成果物との対応を問う形が定番です。
2つ目はBPR・BPM・BPOの区別です。 名前が似ているうえ、意味も近い領域にあるため、選択肢を並べられると迷います。
3つ目はクラウドのサービス区分です。 SaaS、PaaS、IaaSの守備範囲は午前1だけでなく、SC試験の午後でも前提知識になります。
4つ目は調達の流れです。 RFI、RFP、提案書、見積書、契約。順序と各文書の目的を押さえれば、そのまま1問になります。
捨てる問題は個別ツールの細部と業種別の事例
逆に、時間をかけない領域も決めます。個別のBIツールやERPパッケージの製品仕様、業種特化の業務モデル、共通フレームの各プロセスに含まれるアクティビティの網羅的な一覧などは、覚える量に対して出題頻度が見合いません。共通フレームは「企画・要件定義・開発・運用・保守という並び」と、その位置づけを1行で言えれば十分です。
なお、システム開発そのもの（開発モデル、テスト技法、レビュー）は第6回のシステム開発技術で、プロジェクトの管理は第8回で扱っています。本記事は「開発が始まる前」に絞ります。この線引きを最初に決めておくことが、範囲の広いストラテジ系で時間を溶かさないコツです。
用語は「工程の順序」と「誰が書く文書か」で覚える
新卒エンジニアにインフラを教えていた頃、ドキュメント名の暗記でつまずく人には共通点がありました。文書の名前だけを覚えて、その文書が「工程のどこで、誰から誰へ渡るものか」を持っていないのです。
RFIは発注側からベンダへ「情報をください」と出す紙、RFPは発注側からベンダへ「提案をください」と出す紙、提案書と見積書はベンダから発注側へ返ってくる紙。この向きと順序を持てば、選択肢を読んだ瞬間に判別できます。逆に順序を持っていないと、どの選択肢もそれらしく見えてしまいます。この分野のゴールは、用語を見た瞬間に工程表の上へ置ける状態です。
テンプレート集
＋おまけ：毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。
情報システム戦略とエンタープライズアーキテクチャ
ここからは頻出用語を順に整理します。まずは最上位にある情報システム戦略と、その設計図であるEAからです。
情報システム戦略は経営戦略から降りてくる
情報システム戦略は、経営戦略の実現を支えるために、情報システムを中長期的にどう構築・活用していくかを定めた方針です。重要なのは、経営戦略が上位にあり、情報システム戦略はそこから導かれるという関係です。「情報システム戦略に合わせて経営戦略を立てる」という説明が並んだら、向きが逆なので誤りです。
情報システム戦略に基づいて策定されるのが全体最適化計画です。部門ごとの個別最適でシステムが乱立する状態を避け、組織全体として整合の取れた姿を目指すための計画で、その方針を示したものを全体最適化方針と呼びます。ここで「部分最適の集合は全体最適にならない」という前提が置かれている点が、出題の背景にあります。
これらの策定と実行に責任を持つ役職がCIO（Chief Information Officer：最高情報責任者）です。情報システム部門の長という意味ではなく、経営の一員として情報化の投資判断を行う立場だという点が定義の核心になります。
この全体最適化計画のもとに、どのシステムをどの順序で構築するかを具体化した個別のシステム化計画が位置します。上位から順に、経営戦略、情報システム戦略、全体最適化計画、個別のシステム化計画。この階層で並べておけば、どの用語が問われても位置を答えられます。
EAは組織全体を4つの体系でモデル化する
EA（Enterprise Architecture：エンタープライズアーキテクチャ）は、組織全体の業務と情報システムを統一的な手法でモデル化し、全体最適の観点から改善していくための設計・管理手法です。もともとは行政機関の情報化で広く用いられた枠組みで、試験では4つの体系（アーキテクチャ）とその成果物の対応が問われます。
- ビジネスアーキテクチャ（BA：政策・業務体系）：組織の目標と業務そのものを体系化したもの。代表的な成果物は業務説明書、機能構成図（DMM）、業務流れ図（DFD、WFA）
- データアーキテクチャ（DA：データ体系）：業務に必要なデータの構成と関連を体系化したもの。代表的な成果物は情報体系整理図（UMLクラス図）、実体関連ダイアグラム（E-R図）、データ定義表
- アプリケーションアーキテクチャ（AA：適用処理体系）：業務を実現するアプリケーションの構成と、業務との対応関係を体系化したもの。代表的な成果物は情報システム関連図、情報システム機能構成図
- テクノロジアーキテクチャ（TA：技術体系）：アプリケーションを支えるハードウェア、ソフトウェア、ネットワークなどの技術要素を体系化したもの。代表的な成果物はネットワーク構成図、ソフトウェア構成図、ハードウェア構成図
覚え方は上から下への並びです。「業務があり、そこで扱うデータがあり、それを処理するアプリがあり、それを載せる基盤がある」。この順序で並べれば、成果物がどの層に属するかは自然に決まります。E-R図はデータ、ネットワーク構成図は技術、業務流れ図はビジネス。この3つだけでも押さえておけば、かなりの確率で当たります。
As-IsとTo-Beの差分を埋めるのがEAの進め方
EAの進め方は、現状と理想を並べて差を測るという単純な構造です。
- As-Isモデル：現状の業務とシステムの姿をモデル化する
- To-Beモデル：目指すべき理想の姿をモデル化する
- ギャップ分析：両者の差分を洗い出し、埋めるべき課題を特定する
- 次期モデル（移行計画）：制約を踏まえて現実的に到達可能な姿を定め、移行計画に落とす
出題では、As-IsとTo-Beを入れ替えた選択肢が定番です。「As-Isは現状、To-Beはあるべき姿」とだけ覚えれば足ります。また「理想の姿をそのまま次期システムにする」という説明も誤りです。理想と現実の間には制約があり、そこを詰めるのがEAの実務だからです。
EAの標準的な部品として参照モデルが用意されています。業務参照モデル（BRM）、データ参照モデル（DRM）、サービスコンポーネント参照モデル（SRM）、技術参照モデル（TRM）、業績測定参照モデル（PRM：パフォーマンス参照モデル）の5つです。PRMは政策・業務の達成度を測る指標（成果指標）の体系であり、システムの応答性能を指すものではない点だけ注意してください。名前と対象の対応が問われる程度なので、深追いは不要です。
システムの分類はSoRとSoEで語られることがある
近年の出題や午後の題材では、システムを性格で分ける言い方も登場します。
- SoR（System of Record：記録のシステム）：基幹業務のようにデータを正確に記録・保持することが目的のシステム。安定性と信頼性が重視される
- SoE（System of Engagement：つながりのシステム）：顧客との接点を作り、体験を高めることが目的のシステム。変化への速さが重視される
SC試験の観点では、この2つは求められる可用性やリリース頻度が違い、したがってセキュリティ対策の当て方も変わります。SoEは外部に露出する分だけ攻撃面が広く、SoRは停止したときの被害が業務全体に及ぶ、という捉え方をしておくと午後の読解が楽になります。
業務プロセスの改善：BPR・BPM・BPO
システム戦略のもう一つの柱が、業務プロセスそのものの扱いです。名前が似た3語の切り分けが最大の山場になります。
BPRは作り直し、BPMは回し続ける
BPR（Business Process Reengineering：業務プロセス再構築）は、既存の業務プロセスを前提とせず、業務の流れや組織構造を抜本的に設計し直し、コスト・品質・スピードを劇的に改善しようとする取り組みです。キーワードは「抜本的」「ゼロベース」です。部分的な効率化はBPRとは呼びません。
BPM（Business Process Management：業務プロセス管理）は、業務プロセスを分析・設計し、実行して、その結果を評価し、改善するというサイクルを継続的に回し続ける管理手法です。PDCAの業務プロセス版だと捉えると分かりやすくなります。
両者を分ける軸は「一度きりの抜本的な作り直しか、継続的に回す管理か」です。出題ではこの2つを入れ替えた選択肢が定番になります。BPRで理想の姿に作り直し、その後はBPMで維持・改善していく、という時間的な関係で覚えると混同しません。
BPOは業務そのものを外部に出す
BPO（Business Process Outsourcing：業務プロセスアウトソーシング）は、自社の業務プロセスの一部を、その運営ごと外部の専門事業者に委託することです。システム運用の委託にとどまらず、給与計算やコールセンター、経理といった業務の遂行そのものを任せる点が特徴です。
関連する用語も一緒に押さえます。
- シェアードサービス：グループ内の複数企業に共通する間接業務を、専門の会社や部門に集約して効率化すること。外部委託ではなく「グループ内への集約」である点がBPOとの違いです
- オフショアアウトソーシング：人件費の安い海外の事業者へ委託すること。ニアショアは国内の地方拠点へ委託する形
- ホスティングサービス：事業者が用意したサーバーを借りて利用する形態
- ハウジングサービス：自社が所有する機器を事業者のデータセンターに設置し、設備と回線を借りる形態
ホスティングとハウジングは「機器の持ち主が事業者か自社か」で分かれます。混同しやすいので、機器の所有者を基準に判定してください。
SC試験の観点では、BPOは「委託先管理」の話に直結します。業務を外に出しても、個人情報の管理責任や委託元としての監督義務は消えません。委託契約にセキュリティ要件を書き込み、監査権限を確保し、再委託の可否を定める。午後問題で委託先経由の情報漏えいが題材になるとき、問われているのはこの設計です。
業務プロセスを支える道具：ワークフロー・RPA・SOA
業務プロセスを実現・改善するための技術用語も、まとめて出題されます。
- ワークフローシステム：申請や承認といった業務の流れを電子化し、決められた経路に沿って処理を回す仕組み
- RPA（Robotic Process Automation）：定型的な事務作業を、ソフトウェアのロボットが人の操作を代行する形で自動化する仕組み。判断を伴わない繰り返し作業が対象
- SOA（Service Oriented Architecture：サービス指向アーキテクチャ）：業務機能を独立した「サービス」として部品化し、それらを組み合わせてシステムを構築する考え方。業務の変化に対して組み替えで対応しやすくなる
- BPMN（Business Process Model and Notation）：業務プロセスを図式で表現するための表記法の標準
- DFD（Data Flow Diagram）：データの流れに着目して業務やシステムを表す図。EAではビジネスアーキテクチャの成果物として登場する
RPAの引っかけは「高度な判断を伴う業務を自動化する」という説明です。RPAが得意なのは定型作業であり、判断そのものを担うものではありません。またSOAを「サーバーを仮想化して集約する技術」と説明する選択肢も誤りで、SOAは業務機能の部品化の話です。
ソリューションビジネスとクラウドサービス
システム戦略の中で、外部サービスの利用形態を問う出題も安定して現れます。ここはSC試験の午後にも直結する領域です。
SaaS・PaaS・IaaSは「どこまで借りるか」で分かれる
クラウドサービスの3区分は、事業者が提供する範囲の違いで整理します。
- SaaS（Software as a Service）：アプリケーションそのものを利用する形態。利用者は機能を使うだけで、実行環境も基盤も管理しない
- PaaS（Platform as a Service）：アプリケーションの実行環境（OS、ミドルウェア、開発基盤）までを借りる形態。利用者は自分のアプリケーションとデータを管理する
- IaaS（Infrastructure as a Service）：サーバー、ストレージ、ネットワークといった基盤だけを借りる形態。利用者はOSから上を自分で管理する
覚え方は「借りる範囲が広い順にSaaS、PaaS、IaaS」です。SaaSがいちばん任せる範囲が広く、IaaSがいちばん自分で管理する範囲が広くなります。
古い用語としてASP（Application Service Provider）も出題されます。ネットワーク経由でアプリケーションを提供する事業者という意味でSaaSに近いのですが、ASPは利用者ごとに個別のシステムを用意する形が中心だったのに対し、SaaSは1つの環境を複数の利用者で共有するマルチテナント方式が前提になっている点が違いとして説明されます。
利用形態はパブリック・プライベート・ハイブリッド
サービスの種類とは別に、誰と共有するかによる分類もあります。
- パブリッククラウド：不特定多数の利用者が共有する形態
- プライベートクラウド：特定の組織が専有する形態。自社で構築するオンプレミス型と、事業者の設備を専有するホステッド型がある
- ハイブリッドクラウド：パブリックとプライベート、あるいはオンプレミスを組み合わせて使う形態
- マルチクラウド：複数の事業者のパブリッククラウドを併用する形態。特定事業者への依存（ベンダロックイン）を避ける狙いがある
- コミュニティクラウド：業界など共通の目的を持つ複数の組織で共有する形態
引っかけは、ハイブリッドクラウドとマルチクラウドの取り違えです。「性質の違うものを組み合わせるのがハイブリッド、同じパブリックを複数使うのがマルチ」と切り分けてください。
責任共有モデルはSC試験の必修知識
クラウド利用で最も重要な考え方が責任共有モデルです。事業者と利用者のどちらがどの範囲のセキュリティに責任を持つかを定めたもので、サービス区分によって境界が動きます。IaaSであればOSのパッチ適用や設定は利用者の責任、SaaSであればアクセス権限の設定や利用者アカウントの管理が利用者の責任になります。
「クラウドに移したからセキュリティは事業者に任せられる」という思い込みが、設定ミスによる情報公開事故の温床になります。この論点はSC試験の午後でも頻出です。詳細は「IaaS・PaaS・SaaSの違いとは？クラウドの責任共有モデルを完全図解」で扱っていますので、午後対策としてはそちらを参照してください。午前1で問われるのは、あくまで3区分の守備範囲の定義です。
システム化計画から要件定義、そして調達へ
最後に、企画から調達までの流れを工程順に整理します。ここが本記事で最も出題に直結するパートです。
共通フレームは作業内容の「ものさし」
共通フレーム（SLCP-JCF：ソフトウェアライフサイクルプロセス）は、ソフトウェアの企画から開発、運用、保守、廃棄に至るまでの作業内容を体系的に整理した、日本国内向けの共通の枠組みです。現時点の最新版はIPAが公開している共通フレーム2013です。
目的は「取得者（発注側）と供給者（受注側）が同じ言葉で話せるようにすること」にあります。作業の範囲や責任の所在をめぐる認識の食い違いを防ぐための、共通のものさしです。
出題で最も狙われるのは、この位置づけです。共通フレームは「作業内容のものさし」であって、開発方法論や手順、成果物の様式を規定するものではありません。「具体的な開発手順を定めた標準」という説明が並んだら誤りです。また、共通フレームに定義された作業をすべて実施しなければならないわけではなく、プロジェクトの特性に応じて必要な部分を選んで使う（テーラリング）ことが前提になっています。
主なプロセスは次の並びです。
- 企画プロセス：経営上のニーズを受け、システム化構想とシステム化計画を立てる
- 要件定義プロセス：利害関係者のニーズを明確にし、要件として合意する
- 開発プロセス：システム要件定義からソフトウェア実装、テスト、導入まで
- 運用プロセス：稼働後のシステムを運用し、利用者を支援する
- 保守プロセス：稼働後の修正・改良を行う
これに加えて、支援プロセス（監査、構成管理、文書化など）と組織に関するプロセスが横断的に置かれます。
企画プロセスはシステム化構想とシステム化計画
企画プロセスは2段階に分かれます。ここは順序が問われます。
システム化構想の立案では、経営上のニーズや課題を受けて、新しい業務とシステムの全体像を描き、実現可能性を検討します。まだ具体的な仕様の話には入りません。
システム化計画の立案では、構想を受けて、対象業務の範囲、システム化の対象、開発のスケジュール、体制、費用と効果、リスクなどを具体化し、投資の意思決定ができる形に落とします。費用対効果の見積もりや投資対効果の評価が行われるのはこの段階です。
引っかけは、システム化計画で行うべき検討を要件定義に含めたり、その逆を問う形です。「構想は方向づけ、計画は投資判断、要件定義は合意」という役割で分けると迷いません。
要件定義は業務要件・機能要件・非機能要件に分かれる
要件定義プロセスでは、システムに求められることを整理して合意します。分類は3つです。
- 業務要件：新しい業務がどうあるべきかという要件。業務の流れ、扱う情報、体制、必要な人材などを含む
- 機能要件：システムが提供すべき機能に関する要件。どの画面で何ができ、どんな処理を行い、どんな帳票を出すか
- 非機能要件：機能以外の品質・制約に関する要件。性能、可用性、セキュリティ、運用性、拡張性など
非機能要件を整理するための指針としてIPAが公開しているのが非機能要求グレードで、大項目は次の6つです。
- 可用性：継続稼働、障害時の復旧目標など
- 性能・拡張性：応答時間、処理量、将来の増加への対応
- 運用・保守性：運用時間、バックアップ、監視、保守作業の条件
- 移行性：既存システムからの移行方式、移行期間、移行データ
- セキュリティ：アクセス制御、データの秘匿、不正追跡、監査
- システム環境・エコロジー：設置環境、耐震、消費電力などの制約
SC試験の受験者にとって重要なのは、「セキュリティは非機能要件として、要件定義の段階で定義されるべきもの」という点です。開発が終わってから後付けで足すものではなく、企画・要件定義の段階で品質特性として合意しておく。セキュリティバイデザインの考え方は、まさにこの分類の上に成り立っています。
学び始めの人が最もつまずくのは、機能要件と非機能要件の境目です。「何ができるか」が機能要件、「どのくらいの品質でできるか」が非機能要件と切り分けてください。「利用者を認証する機能を持つこと」は機能要件、「認証の応答は2秒以内であること」「パスワードは暗号学的ハッシュで保存すること」は非機能要件の側の話になります。
要件定義がずれたまま先へ進むと、後工程では取り返せません。CIO時代に、CTIと顧客管理システムを連携させる案件を進めたことがあります。営業部門が求めていたのは着信時に顧客情報が自動で出ることでしたが、要件のすり合わせが浅いまま構築を進めた結果、現場の運用に合わず定着しませんでした。技術的には動いていたのに、です。要件定義プロセスが独立した工程として置かれている理由は、まさにここにあります。
調達はRFIからRFPへ、そして提案評価
システム化計画が固まると、調達に入ります。試験で問われるのは、文書の目的と順序です。
- 情報提供依頼（RFI：Request For Information）：提案を依頼する前段階として、システム化の目的や業務の概要をベンダに示し、実現手段や技術動向、実績といった情報の提供を依頼する文書
- 提案依頼（RFP：Request For Proposal）：システムの目的、必要な機能、技術的な要件、予算、スケジュールなどを示し、ベンダに提案書の提出を求める文書
- 提案書・見積書の受領：ベンダから提案内容と費用が提示される
- 提案評価と選定：あらかじめ定めた評価基準に沿って提案を比較し、調達先を決定する
- 契約締結：作業範囲、責任分担、納期、検収条件などを合意する
なお、見積りだけを求める場合の文書をRFQ（Request For Quotation：見積依頼書）と呼びます。RFPに見積りの提出を含めることも多いため、実務では区別が曖昧になりがちですが、試験では「情報がRFI、提案がRFP、見積りがRFQ」と機械的に対応させれば足ります。
出題の核心はRFIとRFPの取り違えです。「情報の提供を依頼」ならRFI、「提案書の提出を依頼」ならRFP。このキーフレーズだけで判定できます。もう一つの定番は、RFIでベンダに求める情報の中身です。求めるのは適用可能な技術やその動向、他社での導入実績といったベンダ側が持つ情報であって、自社の現行システムの概要はベンダに求めるものではありません。自社情報かベンダ情報か、という切り分けが問われます。
提案評価とグリーン調達・CSR調達
提案評価では、価格だけでなく、機能の充足度、技術力、実績、保守体制、リスク対応などを含む複数の基準で比較します。基準と重みは、提案を受け取る前に定めておくのが原則です。後から基準を決めると、恣意的な選定になるためです。この考え方は、そのままシステム監査の観点にもつながります。
調達方針に関する用語も押さえます。
- グリーン調達：環境への負荷が小さい製品やサービス、あるいは環境配慮の取り組みを行っている事業者を優先して調達すること
- CSR調達：環境に加えて、労働環境や人権、法令遵守といった社会的責任の観点を調達基準に組み込むこと
- 総合評価落札方式：価格と技術提案の内容を総合的に評価して落札者を決める方式
SC試験の観点では、調達基準にセキュリティの要求事項を組み込めるかどうかが、供給者を通じたリスク（サプライチェーンリスク）への実質的な備えになります。契約書にセキュリティ要件と監査権限を書けていない委託は、後から是正するのが極めて難しくなります。
午前1で狙われる混同ペア総まとめ
この分野の得点源は、似た用語の識別です。誤りの形と正しい形を対にして整理します。
| 誤りの表現（選択肢に出る形） | 正しい表現・考え方 |
|---|---|
| 情報システム戦略に合わせて経営戦略を立てる | 向きが逆。経営戦略が上位にあり、情報システム戦略はそこから導かれる |
| E-R図はEAのビジネスアーキテクチャの成果物 | E-R図はデータアーキテクチャ。ビジネスは業務流れ図・機能構成図 |
| ネットワーク構成図はアプリケーションアーキテクチャの成果物 | テクノロジアーキテクチャの成果物 |
| As-Isモデルはあるべき姿を表す | As-Isは現状。あるべき姿はTo-Be |
| BPRは業務プロセスを継続的に改善するサイクル | 継続的なサイクルはBPM。BPRは抜本的な作り直し |
| BPOはグループ内の共通業務を1社に集約すること | それはシェアードサービス。BPOは外部事業者への委託 |
| RPAは高度な判断を伴う業務を自動化する | RPAが担うのは定型的な繰り返し作業 |
| SOAはサーバーを仮想化して集約する技術 | SOAは業務機能をサービスとして部品化し組み合わせる考え方 |
| ハウジングは事業者所有のサーバーを借りること | それはホスティング。ハウジングは自社機器を預ける |
| マルチクラウドはパブリックとプライベートの組み合わせ | それはハイブリッドクラウド。マルチは複数のパブリックの併用 |
| IaaSでは事業者がOSのパッチ適用まで行う | IaaSはOSから上が利用者の責任。事業者は基盤まで |
| 共通フレームは開発の具体的な手順と成果物様式を規定する | 規定するのは作業内容のものさし。手順・方法論は規定しない |
| システム化構想の立案で開発費用と体制を確定する | 確定するのはシステム化計画。構想は全体像と実現可能性の検討 |
| 「応答時間は3秒以内」は機能要件 | 品質に関する要求なので非機能要件 |
| RFPはベンダに技術動向などの情報提供を求める文書 | それはRFI。RFPは提案書の提出を求める文書 |
| RFIでベンダに自社の現行システムの概要を求める | 求めるのはベンダが持つ情報（技術動向・実績など） |
| グリーン調達は最も安価な事業者を選定する方式 | 環境負荷の小さい製品・事業者を優先する調達方針 |
この表は、そのまま選択肢の切り捨て基準として使えます。システム戦略の問題を見たら、まず「これは隣の用語の説明ではないか」を疑うのが最短経路です。
SC試験での出題パターンと対策
最後に、この分野がSC試験の中でどう出るかを整理します。
午前1で繰り返される3つの型
型1：用語の定義を問う問題。 「BPMの説明はどれか」「RFIを説明したものはどれか」という、最も素直な形です。選択肢には必ず隣の用語の説明が混ざります。混同ペアの表を持っていれば即答できます。
型2：成果物と体系の対応を問う問題。 EAの4体系のうち、ある成果物がどれに属するかを選ばせる形です。業務・データ・アプリ・技術という4層の並びを持っていれば、成果物の名前から層は推測できます。
型3：工程の順序を問う問題。 調達フローや企画プロセスの空欄を埋めさせる形です。RFI、RFP、提案書、選定、契約という順序、あるいは構想、計画、要件定義という順序を、そのまま並びとして覚えておきます。
この分野で計算問題は出ません。見たことのない用語が出た場合は、消去法で残ったものを選んで先へ進む判断で構いません。
午前2・午後との接続
システム戦略の用語は、SC試験本体でも形を変えて現れます。
セキュリティ要件は非機能要件として問われます。 午後で「システム化の要件定義に不足していたものは何か」と問われるとき、答えが認証方式やログの保存期間といった非機能要件であることは珍しくありません。要件定義の段階で決めるべきものを開発後に足そうとして破綻する、という筋書きは午後の定番です。
委託先管理はBPOの延長線上にあります。 委託契約にセキュリティ要件を明記し、監査権限を確保し、再委託の可否を定める。午後で問われる委託先経由のインシデントは、調達と契約の設計不足として読むと構造が見えます。
クラウドの責任範囲は毎回のように出ます。 IaaSとSaaSでは、設定ミスの責任も検知手段も変わります。SaaSの管理者アカウント、IaaSのストレージ公開設定。区分ごとの守備範囲を持っていれば、答えの方向が定まります。
EAの発想は現状把握そのものです。 インシデント対応でも脆弱性管理でも、最初に必要なのは資産の把握です。As-Isを描けない組織は、守るべきものを列挙できません。試験用語として覚えたEAが、実務では資産管理の思想として効いてきます。
【演習】システム戦略とシステム企画の頻出パターン理解度チェック（全10問）
午前1のシステム戦略・システム企画は、用語の定義、成果物と体系の対応、工程の順序という3つの型が出題の中心です。定番の引っかけは、RFIとRFPの取り違え、BPRとBPMの入れ替え、E-R図をビジネスアーキテクチャの成果物と説明するもの、そして機能要件と非機能要件の境目を曖昧にした選択肢です。以下の練習問題で本記事の理解度を確認してみましょう。
まとめ：システム戦略は開発前の合意を言語化した分野
午前1のシステム戦略・システム企画は、覚える軸が少ない分野です。EAは業務・データ・アプリ・技術の4層、BPRとBPMは抜本か継続か、クラウドは借りる範囲の広さ、調達はRFIからRFPへの順序。この4本の軸と混同ペアの表があれば、出題の大半に手が届きます。計算に時間を取られないので、テクノロジ系の学習で疲れた日の穴埋めに向いています。
同時に、この分野は現場で最も揉める部分を言葉にしたものでもあります。要件定義が浅いまま構築に入ったシステムは、動いていても使われません。委託先に業務を出しても、責任は出せません。クラウドに移しても、設定する責任は残ります。どれも試験の外で何度も繰り返されてきた話で、用語はその教訓に名前を付けたものです。
新卒エンジニアにインフラを教えていて感じたのは、技術の話はできても「なぜこの構成に決まったのか」を説明できる人は少ないということです。RFPに何が書かれ、非機能要件として何が合意されたのか。そこをたどれる人は、障害対応でも設計変更でも判断が速くなります。1問のための暗記だと割り切って構いませんが、後で使う語彙が手に入ると思えば、費やす時間の価値は上がります。
次回、第14回は企業活動を扱います。企業会計と財務諸表の読み方、損益分岐点、在庫評価、OR・IEの手法、そして企業統治と組織形態まで、ストラテジ系で唯一まとまった計算が出る領域を整理します。
本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。
参考資料
- IPA 試験要綱・シラバスについて
- IPA 情報処理技術者試験 過去問題
- IPA SEC BOOKS：共通フレーム2013
- IPA 「非機能要求グレード2018」
- IPA 「情報処理安全確保支援士試験（レベル4）」シラバス（Ver.2.1）
テンプレート集
＋おまけ：毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。
