システム戦略とシステム企画

情報システム戦略 ― 経営戦略との整合と全体最適化

情報システム戦略とは、経営戦略を実現するために「どの業務にどう IT を使うか」を全社の視点で決める中期の方針です。なぜ全社で決める必要があるのかというと、部門ごとに必要になった順にシステムを作っていくと、同じ顧客データが複数の台帳に分かれ、機能が重複し、連携のたびに個別の変換処理を書く羽目になるからです。この部分最適の積み上げを避け、先に全社のあるべき姿を描いてから投資対象を選ぶ考え方を全体最適化といいます。試験でも「経営戦略との整合」「全体最適化」という 2 語が正解肢の目印になります。

策定手順は As-Is の調査から始まり、指標の設定で終わる

シラバス Ver.7.2 は、情報システム戦略の策定タスクとして、対象領域ビジネスのプロセスレベルでの理解、現行業務（As-Is）の調査・分析、情報システム（As-Is）の調査・分析、IT 動向の調査・分析、基本戦略の策定、業務の新全体像（To-Be）と投資対象の選定、活動・成果指標の設定、策定と承認の 8 つを挙げています。順序の要点は 2 つです。第 1 に、現状（As-Is）を業務とシステムの両面から調べるのが先で、理想像（To-Be）を描くのは後です。第 2 に、最後は「どう測るか」を決めて承認を得ます。指標を決めずに承認された戦略は、実行段階でモニタリングできません。

計画の階層 ― 全体最適化計画と個別計画

経済産業省のシステム管理基準（平成 16 年版。令和 5 年 4 月改訂版では IT ガバナンス編／IT マネジメント編に再構成され、この語は使われていません）では、情報戦略の段階で組織全体のあるべき姿を明確にする計画を全体最適化計画と呼びます。シラバスの用語でいう情報システム化基本計画がこれに相当し、その下に個々のシステムをいつ・どの範囲で作るかを決める個別計画（個別の開発計画）が並びます。「組織全体のあるべき姿を明確にする計画」「情報戦略策定段階の成果物」という聞き方で 2 回出題され、答えはいずれも全体最適化計画でした。誤答肢には個別計画・開発計画・運用計画のように 1 段下の計画名が置かれます。

戦略を実行する体制も用語例に挙がっています。IT 全般の責任者が CIO（Chief Information Officer：最高情報責任者）、デジタル活用による変革の責任者が CDO（Chief Digital Officer）です。全社の意思決定機関として情報システム戦略委員会が置かれ、個々のシステムには責任者であるシステムオーナーと、そのシステムが保有するデータの責任者であるデータオーナーが定められます。策定した戦略が計画どおり進んでいるかをモニタリング指標で追い、差異分析とリスク対応を行う活動を情報システム戦略実行マネジメントといいます。なお、システム管理基準の企画プロセスに踏み込んで「ビジネス分析の達成目標」を問う出題も 1 回あり、基準の条文レベルまで聞かれる例が出てきています。

プロジェクト・プログラム・ポートフォリオの 3 層

プログラムマネジメントは、目的や目標が明確な複数のプロジェクトを有機的に組み合わせたプログラムについて、プロジェクト相互の関係を最適化し、全体として使命をより良く達成するように統合する活動です。直近 10 年で 4 回、ほぼ同一の問題として出題されており、正解文には毎回「複数のプロジェクト」「統合」「戦略の実現」が揃います。プログラムを支援する組織が PMO（Program Management Office：プログラムマネジメントオフィス）です。

目標の設定と投資対効果の指標

戦略の達成度は指標で測ります。最終的なゴールを数値で表すのが KGI（Key Goal Indicator：重要目標達成指標）、その達成に決定的に効く要因が CSF（Critical Success Factor：重要成功要因）、CSF の進み具合を測る中間指標が KPI（Key Performance Indicator：重要業績評価指標）です。導出は KGI → CSF → KPI → 施策の順で、この順序を問う読解問題が 1 回出ています。「物流コストを 10% 削減する」が KGI、「積載率の向上」が CSF、「1 便あたり積載率 85%」が KPI、「配送ルートの見直し」が施策という関係です。

投資の評価指標も、名称と計算式の対応で出ます。中分類 17 では ROI が 3 回、いずれも定義を選ぶ形（計算は出ていません）、中分類 18 では投資回収期間（PBP）が 4 回、NPV が 2 回出ています。ここでは名称と考え方を押さえ、キャッシュフローの割引計算そのものは第 21 章で扱います。

DX と DX 政策の 3 点セット

DX（Digital Transformation：デジタルトランスフォーメーション）は、データとデジタル技術を活用して製品・サービス・ビジネスモデルを変革し、あわせて業務そのものや組織・プロセス・企業文化まで変えることで、競争上の優位性を確立する取組みを指します。単にツールを導入することではなく、変革の対象に組織と文化が含まれる点が定義の核です。

情報システム戦略の留意事項には BCP（Business Continuity Plan：事業継続計画）も用語例として挙がり、2 回出題されています。正解文は毎回「中断・阻害された業務を、あらかじめ定めた時間内に復旧・再開させる手順を文書化したもの」に近い内容です。データのバックアップや従業員の安否確認は BCP の構成要素の一つにすぎず、それだけを述べた肢は誤りです。BCM の詳細（事業影響度分析、RTO・RPO）は第 21 章で扱います。

EA（エンタープライズアーキテクチャ）と SOA

EA（Enterprise Architecture：エンタープライズアーキテクチャ）は、組織全体の業務とシステムを統一的な手法でモデル化し、業務とシステムを同時に改善することを目的とした、組織の設計・管理手法です。EA が扱う領域は 4 つに分かれ、それぞれが 1 つのアーキテクチャとして整理されます。定義を選ばせる問題では「4 つの体系で組織全体を整理し、全体最適化を図る」という骨格が正解肢に入ります。この小分類は中分類 17 で最も厚く、EA そのものが 3 回、後述の SOA が 7 回、To-Be モデルが 1 回で計 11 問です。

各層には、あらかじめ用意された「ひな型」である参照モデルがあります。業務体系の参照モデルが BRM（Business Reference Model：業務参照モデル）で、業務を機能別に分類・体系化し、業務体系とシステム体系を対応付ける土台になります。同様にデータ体系には DRM、サービス部品には SRM、技術標準には TRM が対応します。EA のフレームワークとしては、企業を「何を・どのように・どこで・誰が・いつ・なぜ」の 6 つの観点と視点の階層で表すザックマンフレームワーク、業界団体 The Open Group が策定した TOGAF が用語例に挙がっています。既存の複数のアプリケーションを連携させる仕組みは EAI（Enterprise Application Integration）です。

SOA ― この中分類で最多の出題テーマ

SOA（Service Oriented Architecture：サービス指向アーキテクチャ）は、業務上の機能を独立したサービス部品に分割し、その部品を業務プロセスに対応付けて組み合わせることで、業務の変化に合わせた組み替えと連携を容易にする設計思想です。この 2 つの要素が両方そろっているかが正誤判定の分かれ目になります。

誤答肢は、SOA の 2 要素のうち片方しか満たさない近縁概念で作られます。「ソフトウェア部品を再利用しやすくする」だけならオブジェクト指向の説明であり、「既存アプリケーション同士をつなぐ」だけなら EAI の説明です。また、統合された 1 つのパッケージで基幹業務をまかなう ERP の説明を SOA として置く肢も見られます。

業務プロセスの改善 ― BPR・BPM・RPA

この 3 つは「業務をよくする」点では同じですが、扱う粒度と継続性が違います。試験ではその違いを突く肢が並ぶため、対比で覚えます。

BPR（Business Process Reengineering：ビジネスプロセスリエンジニアリング）は、マイケル・ハマーらが提唱した考え方で、既存の組織構造や業務手順を前提とせず、プロセス視点と顧客志向で業務を根本から再設計し、顧客価値の向上を図ります。既存業務の部分的な効率化ではなく、部門をまたいだ流れそのものを描き直すのが特徴です。

BPM（Business Process Management：ビジネスプロセスマネジメント）は、業務分析 → 業務設計 → 業務の実行 → モニタリング → 評価というサイクル（PDCA）を繰り返して、業務プロセスを継続的に改善する管理活動です。これを支えるシステムが BPMS（Business Process Management System）で、承認経路を電子化するワークフローシステムもこの枠に入ります。実行時に残ったログから、実際に行われているプロセスを復元・可視化する手法がプロセスマイニングです。

RPA（Robotic Process Automation）は、画面操作・転記・照合といった定型的な PC 作業を、ソフトウェアのロボットが人の代わりに実行する仕組みです。業務改善は「プロセスの可視化 → 標準化 → 自動化」の順に進めるもので、RPA はその最後の自動化の道具にあたります。標準化されていない業務にそのまま RPA を当てると、非効率な手順ごと固定してしまうため、順序が重要です。

外部に出す改善 ― BPO・シェアードサービス

業務のモデル化 ― どの図で何を表すか

業務プロセスを把握・分析して問題点を見つけるには、図に落とす必要があります。シラバスには複数の記法が並びますが、覚えるべきは「その図が何を主役にしているか」だけです。

ソリューションビジネスとクラウドサービスの選定

ソリューションビジネスとは、製品を売るのではなく、顧客の経営課題そのものを解決するサービスを提案・提供する事業形態です。提供する事業者をソリューションプロバイダといい、複数のハードウェア・ソフトウェア・サービスを組み合わせて 1 つのシステムとして構築・運用まで請け負う形態が SI（System Integration：システムインテグレーション）です。顧客との信頼関係の構築・維持が事業の前提になる点がシラバスで強調されています。

SaaS・PaaS・IaaS ― どこまで事業者が管理するか

クラウドサービスの 3 分類は、「システムのどの層までを事業者が管理するか」で決まります。利用者の自由度と運用負担は逆比例します。IaaS は OS から自分で選べる代わりに OS のパッチ適用まで自分の責任、SaaS は業務機能をそのまま使う代わりにアプリの仕様変更に従うことになります。

直近 10 年でクラウド系は 1 問ずつしか出ていませんが、いずれも定義の一行で決まります。仮想デスクトップを集中管理して端末側に画面転送だけを行う VDI（Virtual Desktop Infrastructure）、必要な資源を必要な量だけ用意して割り当てるプロビジョニング、自社のシステム機能を外部の事業者に API として公開して連携させるオープン API が出題例です。

クラウドの選定基準 ― SLA とロックイン

選定では、機能や価格の前に 2 つを確認します。第 1 に SLA（Service Level Agreement：サービスレベル合意書）で、稼働率・障害復旧時間・サポート応答時間といった水準と、達成できなかった場合の措置が明記されているかを見ます。第 2 にベンダーロックインで、独自仕様に深く依存すると他社や自社環境へ移せなくなり、価格交渉力を失います。あわせて、データの保存先の国と適用される法令（ソブリンクラウドの論点）、退去時のデータ返却・消去の条件も確認します。SLA の設計と運用そのものは第 16 章のサービスマネジメントで扱います。

システム活用促進・評価とデータ利活用

システムは作って終わりではありません。使われるように普及啓発し、実際にどう使われたかを評価・検証し、寿命が来たら計画的に廃棄する、という一連の活動がこの小分類です。直近 10 年の科目 A では、この小分類からの 6 問がすべて「蓄積したデータの分析・活用」に集中しており、普及啓発や廃棄そのものは出ていません。厚みはデータ活用側に置きます。

活用促進と利用実態の評価

普及啓発の手段は、利用者用文書類（利用者マニュアル）・業務マニュアルの整備、講習会、e-ラーニング、人材育成計画です。学習の進捗や履歴を管理する基盤が学習マネジメントシステム、ゲームの要素（達成バッジ・ランキングなど）を学習や業務に取り入れて動機づけを高める手法がゲーミフィケーションです。IT を使える人と使えない人の間に生じる格差がデジタルディバイドで、その解消も普及啓発の目的に含まれます。経営目標の実現に向けてデジタル技術を安全・有効・効率的に使いこなす能力をデジタルリテラシーと呼び、IT リテラシー・メディアリテラシー・セキュリティ意識が含まれます。

導入後の評価では、投資対効果分析、利用者満足度調査、モニタリング、ログ分析・ログ監視を行い、業務内容や業務フローが変わっていないか、運用状況はどうかを把握して改善の方向性を決めます。客観性を確保するために外部専門家による第三者評価・検証を使うこともあります。

データ利活用 ― 分析手法と用途の対応

蓄積したデータを経営判断に使うことをデータ駆動経営といい、そのためにデータの品質・定義・権限を組織的に統制する活動がデータガバナンス、データの収集・蓄積・整備・提供を継続的に行う実務がデータマネジメントです。試験では個々の分析手法の名称と用途が問われます。

オープンデータは 2 回出題されており、正解文はどちらも 3 つの要件で構成されます。すなわち、営利・非営利を問わず二次利用が可能なルールで公開されていること、機械判読に適した形式であること、原則無償で利用できることです。3 要件のうち 1 つを落とした肢が誤答になります。行政が保有するデータを企画・設計の段階から公開を前提に整えておく考え方をオープンデータバイデザインといい、官民データ活用推進基本法に基づく取組みとして出題されました。AI の活用については、公平性・透明性・説明責任・人間の関与といった観点を整理した AI 利活用のガイドラインが各所で示されており、業務適用の際にはこれらを前提に検討します。

システム化計画 ― 企画プロセスの 2 段構え

ここからは、戦略を 1 つのシステムに落とし込む流れに入ります。IPA が公開している共通フレーム 2013（SLCP-JCF2013）では、開発の前に企画プロセスと要件定義プロセスが置かれ、企画プロセスはさらに「システム化構想の立案」と「システム化計画の立案」の 2 段に分かれます。この構造と各プロセスの代表的な作業が、直近 10 年で 3 回そのまま問われています。

システム化構想の立案 ― 経営課題から出発する

構想立案では、対象業務システムの課題を定義し、業務を分析し、適用できる情報技術を調査したうえで、ビジネスモデルと業務プロセスを企画し、システム方式を策定します。さらに業務運用の評価指標を設定し、費用とシステム投資効果を予測し、情報システム戦略との整合を検証してから承認を受けます。成果物はシステム化構想書で、共通フレームでは最上位の業務機能と業務組織の全体像を示すものと位置づけられます。出題では「情報技術動向を調査し、競争優位を得られる利用方法を分析する」という記述が構想立案の作業として正解になりました。誤答肢には、後工程（計画立案・要件定義）の作業が置かれます。

システム化計画の立案 ― 実現できるかを詰める

計画立案では、基本要件の実現性を検討し、開発スケジュールの大枠を作り、システム選定方針を定め、プロジェクト推進体制を決めます。加えて、システム移行・運用と保守・環境整備・教育訓練・品質に対する基本方針を明確にし、システム運用の評価指標を設定して承認を受けます。全社を対象にした全体システム化計画と、個々のシステムを対象にした個別システム化計画があり、責任者としてプロジェクトオーナーと実行責任者を置きます。

SoR・SoE・SoI とパッケージ適用の方針

パッケージやクラウドサービスを使う場合は、製品の標準機能に業務のやり方を合わせるFit to Standard という方針が取られます。標準機能をそのまま使うことを OOTB（Out Of The Box）といい、いずれもアドオン開発を減らして導入期間と保守コストを抑える狙いです。逆に自社業務に合わせて作り込むほど、バージョンアップのたびに改修が必要になります。

計画で検討する項目と投資回収期間の型

全体開発スケジュールでは、対象をサブシステムに分割し、優先順位を付けて、要員・納期・費用・品質のバランスを取ります。要員教育計画では、教育・訓練の基本要件、体制、スケジュール、対象者を決めます。導入リスク分析では、リスクの発生頻度・影響・範囲を見積もり、リスク回避・損失予防・損失軽減・リスク移転・リスク保有といった対応を選びます。想定した損害は財産損失・賠償責任損失・純収益損失・人的損失に分けて考えます。リスクが顕在化した場合に備えてあらかじめ対処方法を定めておく計画がコンティンジェンシープランで、製造委託を題材に 1 回出題されています。

投資の意思決定法としては PBP（Pay Back Period：投資回収期間）が中分類 18 で最多の 4 回出題されており、うち 1 回が計算型でした。定義選択が 3 回、計算が 1 回という配分です。

NPV（正味現在価値）は 2 回とも「3 年間・3 シナリオの回収額から NPV が最大のものを選ぶ」形で、正解はいずれも早期に多く回収するシナリオでした。回収額の合計が同じなら、早く受け取るほど割引による目減りが小さく NPV は大きくなります。この性質を知っていれば割引計算を省ける場合があります。割引計算そのものの手順は第 21 章で扱います。

要件定義 ― 業務要件・機能要件・非機能要件

要求分析は、要求項目を洗い出して分析し、システム化のニーズを整理し、前提条件や制約条件をまとめる作業です。現状の業務を出発点にする現状指向型アプローチと、目指す姿から逆算する目的指向型アプローチがあります。要求を体系的に扱う学問・技術体系が要求工学（Requirements Engineering）、ビジネスアナリシスの知識体系が BABOK です。手法としては、アンケート、インタビュー（質問を固定する構造化・大枠だけ決める半構造化・自由に聞く非構造化）、意見をグループ化する親和図、機能分析、構造分析、データフローモデル、E-R モデル、並行動作を扱うペトリネットモデル、目標から要求を分解するゴール指向要求分析（KAOS 法、アイスター）が挙がっています。

要件定義プロセスの手順は「誰の要求か」から始まる

共通フレームの要件定義プロセスは、利害関係者の識別 → 利害関係者のニーズの抽出 → 要件への変換 → 分析 → 妥当性確認 → 合意・承認という順に進みます（ただし公式ガイドはこれを固定的な一方向の手順ではなく反復して行う活動と位置づけており、妥当性確認は本来は別プロセスに属します）。出題はこの入口の 2 つ（「利害関係者を識別する」「利害関係者のニーズを抽出する」）に集中しており、誤答肢には設計・テストといった後工程の作業が置かれます。要件定義は「何を作るか」を決める工程であり、設計は「どう作るか」を決める工程だという線引きで判別できます。

3 分類 ― 業務要件・機能要件・非機能要件

シラバスが挙げる要件の種類は、業務要件定義・業務処理手順・機能要件定義・非機能要件定義に加え、性能要件、セキュリティ要件、周辺インタフェース要件、情報・データ要件、運用要件、移行要件、保守要件です。非機能要件は 2 回出題され、1 回は「システム基盤に関わる項目」（可用性・性能・拡張性・運用性・保守性）を選ぶ形、もう 1 回は品質特性の一つである使用性の具体例を選ぶ形でした。要件を機能／非機能に振り分けるだけでなく、非機能の中の品質特性名まで問われる 2 段構えです。

要求はすべてを同じ重みで実現できないため、優先順位を付けます。代表的な枠組みが MoSCoW で、Must have（必須）・Should have（あるべき）・Could have（あればよい）・Won't have（今回は対象外）の 4 段階に分けます。合意した要件は要件定義書として承認を受け、以後の変更は要件変更のルールに従います。要求の根拠と成果物の相互関係が文書化され、仕様変更の影響を追跡・検証できる状態をトレーサビリティといい、直近 3 年で新たに出題されました。合意形成の場を進める技術がファシリテーション、決定の経過と根拠を説明できることがアカウンタビリティです。

定義した要件が正しいかを確かめる手段も規格化されています。要求工学に関する規格 JIS X 0166 では検証の手法として、文書を人が読んで要件への適合度合いを検査するインスペクション、分析、実証、試験が挙げられており、「文書の要件遵守の度合いを検査する手法」を選ばせる出題ではインスペクションが正解でした。また、機能が有効に働くことに加えて、使う人の快適さや楽しさといった体験価値まで含めて設計する思想が UX（User Experience）デザインで、画面の見た目だけを指すものではありません。

要件定義の手法と UML 図の使い分け

構造化分析手法では、処理をプロセス仕様と DFD で表し、データ項目を DD（Data Dictionary：データ辞書）にまとめ、条件と処理の組合せを決定表（デシジョンテーブル）やデシジョンツリーで整理します。データを中心に据える設計方針が DOA（Data Oriented Approach：データ中心アプローチ）です。オブジェクト指向分析では UML を使い、古典的な手法としてコード・ヨードン技法、シュレア・メラー技法が用語例に挙がっています。

調達計画・実施 ― RFI から契約まで

調達計画では、要件定義を踏まえて、既成の製品やサービスを買うのか、社内で開発するのか、外部に委託するのかを選びます。この判断のよりどころが内外作基準です。競争力の源泉になる業務は内製し、標準化された業務は外部の製品・サービスを使う、という切り分けが典型です。調達の対象・要求事項・条件を定義したうえで、次の実施段階に進みます。入札への参加を募る文書は IFB（Invitation For Bids：入札募集）です。

RFI・RFP・RFQ ― 誰が誰に何を求める文書か

調達の方法には、価格だけで決める一般競争入札のほか、提案内容を競わせる企画競争入札、価格と技術評価点を合算して評価する総合評価落札方式（加算方式）があります。一定金額以上の政府調達には WTO 政府調達協定に基づく手続が適用されます（対象となる機関・品目の調達であることも条件です）。あわせて、調達を適切に行うためにシステム資産・ソフトウェア資産を管理する必要があり、ソフトウェアのサプライチェーンマネジメント、ライセンス管理、構成管理が用語例に挙がっています。外部資源としては、SI 事業者、ASP、IDC、Web サービス、ソフトウェアパッケージ、OSS の適用のほか、製造委託の形態として OEM・ODM・ファブレス・ファウンドリが並びます。

提案評価 ― 重み付け評価表の計算

複数の提案を比べるときは、評価項目ごとに重みを決め、各社の評価点を掛けて合計し、満点に対する割合で比較します。この計算は中分類 18 で 2 回、中分類 17 でも同型が 1 回出ており、正解の数値まで同じ再出題が含まれます。落とすと痛い、確実に取れる型です。

契約 ― 工程ごとに類型が変わる

経済産業省と IPA が公表している「情報システム・モデル取引・契約書」は、工程ごとに適した契約類型を示しています。直近 10 年で 4 回出題され、準委任側から聞く形と請負側から聞く形の両方があります。判断の軸は「その工程の成果物が、契約の時点で確定しているか」です。

直近では、ネットワーク試験の遅延で生じた追加費用をどちらが負担するかを事例から判断させる読解型も出ています。用語の暗記ではなく、契約上どちらの責任範囲かを本文から読む問題です。請負・準委任と労働者派遣の違い（指揮命令権の所在）は第 22 章で扱います。

調達に伴うリスクは、品質リスク・納期リスク・費用超過リスク・要員スキルに関するリスクに分けて分析します。加えて、内部統制・法令遵守の観点、環境に配慮した製品を優先するグリーン調達、人権や労働環境に配慮した CSR（Corporate Social Responsibility：企業の社会的責任）調達の観点からも評価が必要です。

ひっかけポイント

理解度チェック（科目 A 形式）

まとめ

• 順序の暗記が 3 か所で効きます。策定手順は As-Is → To-Be → 指標設定 → 承認、企画は構想 → 計画 → 要件定義、調達は RFI → RFP・RFQ → 提案評価 → 契約です
• 粒度の対比が 2 か所で効きます。BPR（プロセス全体）・BPM（運用）・RPA（操作）と、ポートフォリオ（投資）・プログラム（複数 PJ）・プロジェクト（QCD）です
• 計算は 2 型だけです。重み付け評価は「加重合計 ÷（重み合計 × 最高評価点）」、PBP は「累積が投資額に達する年」。どちらも早期・高評価が有利で、合計の大きさだけでは決まりません

この章では「経営戦略に沿って」という前提を繰り返してきました。次章では、その経営戦略そのものをどう分析・立案するのか、SWOT・PPM・5 フォース・アンゾフの成長マトリクス・バランススコアカードといったフレームワークと、技術戦略マネジメントを扱います。