システム戦略・企画

企業が IT を活用して競争力を高めるには、場当たり的にシステムを導入するのではなく、経営戦略と整合した 情報システム戦略 を立てることが欠かせません。たとえば、ある小売チェーンが「全店舗の在庫をリアルタイムに把握したい」と考えたとき、POS システム・倉庫管理システム・本部の分析基盤をどう組み合わせるかを全体最適の視点で設計する必要があります。

このセクションでは、組織全体の IT 構造を俯瞰する エンタープライズアーキテクチャ（EA） 、業務そのものを見直す BPR・BPM 、外部サービスを活用する ソリューションビジネス と クラウドサービス 、そしてシステム導入の計画立案までを体系的に学びます。

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

エンタープライズアーキテクチャ（EA） とは、組織全体の業務と情報システムの構造を4つの体系（アーキテクチャ）で整理し、全体最適を実現するための設計手法です。経済産業省が推進した「EA 策定ガイドライン」にも採用されており、FE 試験でも頻出です。

EA の4つの体系

体系	英語	対象	具体例
ビジネスアーキテクチャ（BA）	Business Architecture	業務プロセス・組織構造	業務フロー図、組織図
データアーキテクチャ（DA）	Data Architecture	データの構造・関連	ER 図、データ辞書
アプリケーションアーキテクチャ（AA）	Application Architecture	アプリケーションの構成・連携	アプリケーション関連図
テクノロジアーキテクチャ（TA）	Technology Architecture	ハードウェア・ネットワーク基盤	ネットワーク構成図、HW 一覧

EA では、まず現状の姿（ As-Is ）を整理し、次に理想の姿（ To-Be ）を描き、そのギャップを埋める移行計画を策定します。

上位のアーキテクチャが下位を規定する関係にあり、業務要件（BA）からデータ（DA）→アプリ（AA）→技術基盤（TA）の順に設計します。

業務プロセスの改善手法

BPR（Business Process Reengineering）

既存の業務プロセスを根本的に見直し、 ゼロベースで再設計 する手法です。マイケル・ハマーとジェイムズ・チャンピーが提唱しました。

• 特徴: 既存のやり方を前提にしない抜本的な改革
• 例: 紙の申請書を回覧する承認プロセスを廃止し、ワークフローシステムで即時承認に変更

BPR は「改善」ではなく「改革」です。部分的な効率化ではなく、業務の目的そのものに立ち返って設計し直す点が特徴です。

BPM（Business Process Management）

業務プロセスを 継続的に モニタリング・分析・改善する管理手法です。BPR が一度きりの大改革であるのに対し、BPM は PDCA サイクル を回し続ける点が異なります。

項目	BPR	BPM
アプローチ	抜本的な再設計	継続的な改善
頻度	一度きり（大規模）	継続的（日常的）
リスク	高い（大きな変化）	低い（段階的）

BPO（Business Process Outsourcing）

業務プロセスの一部を 外部の専門業者に委託 することです。コールセンター業務や給与計算など、コア業務以外を外部に任せて自社はコア業務に集中する戦略です。

業務プロセスのモデリング手法

業務の流れを可視化するために、さまざまなモデリング手法が使われます。

DFD（Data Flow Diagram）

データの流れを図示する手法です。4つの記号で構成されます。

記号	名称	意味
丸（○）	プロセス	データを処理・変換する機能
矢印（→）	データフロー	データの流れ
二重線（＝）	データストア	データの保管場所
四角（□）	外部エンティティ	システムの外部（顧客・取引先等）

E-R 図（Entity-Relationship Diagram）

データの実体（エンティティ）と関連（リレーションシップ）を図示する手法です。データベース設計の基礎として使われ、データアーキテクチャ（DA）の中核をなします。

ワークフロー

業務の手順・承認ルートを定義し、電子的に管理する仕組みです。紙の回覧を電子化することで、承認の迅速化・進捗の可視化・証跡の記録が可能になります。

ソリューションビジネス

ソリューションビジネス とは、顧客の経営課題に対して IT を活用した解決策（ソリューション）を提供するビジネスの総称です。単にハードウェアやソフトウェアを売るのではなく、課題の分析からシステム構築・運用までを一体的に提供します。

主なソリューションサービスの種類

サービス	説明
SoE（System of Engagement）	顧客や取引先との「つながり」を重視するシステム（SNS、モバイルアプリ等）
SoR（System of Record）	企業の基幹業務データを正確に記録・管理するシステム（会計、在庫管理等）
SOA（Service Oriented Architecture）	業務機能をサービス単位で部品化し、それらを組み合わせてシステムを構築する設計手法
ASP（Application Service Provider）	アプリケーションをネットワーク経由で提供する事業者
ホスティングサービス	サーバやストレージを貸し出すサービス。自社で機器を保有しなくてよい
ハウジングサービス	顧客の機器をデータセンターに設置し、回線や電源を提供するサービス

クラウドサービス（SaaS・PaaS・IaaS）

クラウドサービスは、IT リソースをインターネット経由で利用する形態です。自社でサーバを保有・管理する オンプレミス に対し、初期費用を抑えて柔軟にスケールできるメリットがあります。

サービスモデル

モデル	提供範囲	利用者が管理する範囲	代表例
IaaS （Infrastructure as a Service）	ハードウェア + 仮想化基盤	OS、ミドルウェア、アプリ	AWS EC2, Azure VM
PaaS （Platform as a Service）	IaaS + OS + ミドルウェア	アプリケーションのみ	Heroku, Google App Engine
SaaS （Software as a Service）	すべて（アプリまで）	設定・データのみ	Gmail, Microsoft 365, Salesforce

クラウドの導入形態

形態	説明
パブリッククラウド	不特定多数の利用者にサービスを提供（AWS、Azure、GCP 等）
プライベートクラウド	特定の組織専用に構築されたクラウド環境
ハイブリッドクラウド	パブリックとプライベートを組み合わせて使い分ける
マルチクラウド	複数のパブリッククラウドを併用する

システム化計画

システム化計画とは、経営戦略や情報システム戦略に基づいて、 どの業務をどのようにシステム化するか を具体的に計画することです。

システム化計画の主な内容

項目	説明
対象業務の明確化	どの業務をシステム化するかを決定する
システム化の目標	システム化によって達成したい定量的な目標を設定する
対象範囲の決定	システム化する範囲と、しない範囲を明確にする
スケジュール	開発・導入のスケジュールを策定する
費用対効果	システム投資の効果を定量的に評価する
リスク分析	想定されるリスクと対策を明確にする

システム化の費用対効果

システム投資の判断には、費用対効果の分析が重要です。

• TCO（Total Cost of Ownership） : システムの導入から運用・廃棄までの総保有コスト。初期費用（ハードウェア、ソフトウェア、開発費）だけでなく、運用費（保守、電気代、人件費）も含めて評価する
• ROI（Return on Investment） : 投資利益率 = 利益 / 投資額 × 100（%）

TCO を正しく見積もらないと、「導入は安かったが運用費がかさんで結局高くついた」という事態になりかねません。運用・保守費は一般に TCO の 70〜80% を占めるとも言われます。

システム化計画が定まったら、次は具体的にシステムを企画し、開発を担うベンダー（IT 事業者）を選定・調達するフェーズに入ります。たとえば、ある製造業の企業が「生産管理システムを刷新したい」と決めた場合、まずユーザー部門の要望を整理し（要件定義）、複数の IT ベンダーに提案を依頼し（RFP）、最適なベンダーを選定して契約します。

このセクションでは、 要件定義 の進め方、ベンダー選定に使う RFI・RFP 、 調達計画 と 提案評価 の手法、そしてサービス品質を担保する SLA までを学びます。

要件定義

要件定義 とは、システムに求められる機能や性能を明確にするプロセスです。開発の最上流工程であり、ここでの認識のずれは後工程で大きな手戻りを生むため、最も重要な工程の一つです。

要件の分類

種類	説明	例
業務要件	システム化の対象となる業務の内容・ルール	「注文は翌営業日までに出荷する」
機能要件	システムが実現すべき機能	「在庫数が基準値を下回ったら自動発注する」
非機能要件	性能・信頼性・セキュリティ等の品質要件	「応答時間3秒以内」「稼働率99.9%以上」

非機能要件の主な項目

項目	内容
性能要件	レスポンスタイム、スループット
信頼性要件	稼働率、障害復旧時間
拡張性要件	将来のデータ量増加やユーザー数増加への対応
セキュリティ要件	認証方式、暗号化、アクセス制御
移行要件	既存システムからのデータ移行方法
運用・保守要件	バックアップ方針、監視体制、障害対応手順

非機能要件は「当たり前品質」とも言われ、ユーザーが明示的に言語化しにくい要件です。開発側がヒアリングでうまく引き出すことが求められます。

要件定義の手法

要件定義ではユーザー部門と開発部門の認識を合わせるために、さまざまな手法が使われます。

手法	説明
ヒアリング（インタビュー）	ユーザーに直接話を聞いて要件を引き出す
ブレーンストーミング	複数の関係者でアイデアを自由に出し合う
プロトタイピング	試作品（プロトタイプ）を作成し、ユーザーの反応を見ながら要件を確認する
ユースケース分析	システムの利用場面（ユースケース）を洗い出し、アクターとシステムのやりとりを記述する

上の図のように、システム企画は経営戦略から始まり、要件定義を経て調達へと進みます。各工程が前工程の成果物に依存するため、上流での品質確保が極めて重要です。

RFI（情報提供依頼書）と RFP（提案依頼書）

ベンダー選定のプロセスでは、 RFI と RFP という2つの文書が登場します。

RFI（Request for Information: 情報提供依頼書）

ベンダーに対して、技術動向・製品情報・事例などの 情報提供を依頼 する文書です。RFP を作成する前段階で、市場調査や候補ベンダーの絞り込みに使います。

• 目的: ベンダーの技術力や実績を事前に把握する
• タイミング: RFP 作成前

RFP（Request for Proposal: 提案依頼書）

ベンダーに対して、システムの要件・制約条件・評価基準などを示し、 具体的な提案を依頼 する文書です。

RFP に含まれる主な項目:

項目	内容
システム概要	目的、対象業務、利用者数
要件	機能要件、非機能要件
制約条件	予算、スケジュール、技術的制約
提案に含めてほしい事項	開発体制、スケジュール、費用見積
評価基準	提案を評価するための基準（配点等）
契約条件	契約形態、知的財産の帰属

RFI → RFP の順序 で進める点が試験で問われます。RFI で情報収集してから RFP で具体的な提案を求めるという流れです。

調達計画と提案評価

調達計画

調達計画では、 何を、いつ、どのように調達するか を計画します。

項目	説明
調達対象	ハードウェア、ソフトウェア、開発サービス、運用サービスなど
調達方式	一括調達か分割調達か。自社開発か外部委託か
調達スケジュール	RFP 発行から契約締結までのタイムライン
選定基準	技術力、価格、実績、信頼性などの評価基準と配点

提案評価の手法

ベンダーからの提案書を公正に評価するために、定量的な評価手法を用います。

手法	説明
総合評価落札方式	価格と技術の両面を総合的に評価して選定する
加点方式	評価項目ごとに点数をつけ、合計点で比較する
除外方式	最低基準を満たさない提案を除外してから評価する

提案評価の例（加点方式）

評価項目	配点	A社	B社	C社
技術力	30	25	28	22
価格	25	20	18	25
実績	20	18	15	12
保守体制	15	12	14	10
プロジェクト管理	10	8	9	7
合計	100	83	84	76

この例では B 社が最高得点で選定されます。価格だけでなく総合力で判断する点がポイントです。

SLA（Service Level Agreement: サービスレベル合意書）

SLA とは、サービスの提供者と利用者の間で、サービスの品質水準を具体的な数値で合意する文書です。「このレベルのサービスを保証します」という約束を明文化したものです。

SLA に含まれる主な指標

指標	内容	例
可用性	サービスが利用可能な時間の割合	稼働率 99.9% 以上
応答時間	リクエストに対する応答にかかる時間	平均応答時間 3 秒以内
障害復旧時間	障害発生から復旧までの時間	4 時間以内に復旧
サポート対応時間	問い合わせへの対応可能時間帯	24 時間 365 日対応
データバックアップ	バックアップの頻度と保存期間	日次バックアップ、30 日間保持

SLA の運用

• SLO（Service Level Objective） : サービス提供者が設定する内部的な目標値。SLA より厳しい値を設定するのが一般的
• ペナルティ条項 : SLA 未達の場合の補償（料金減額等）を定めることがある
• 定期レビュー : SLA の達成状況を定期的に確認し、必要に応じて見直す

SLA はクラウドサービスの契約でも重要です。たとえば AWS は EC2 に対して月間稼働率 99.99% の SLA を提示しています。SLA を理解しておくことで、ベンダーのサービス品質を客観的に比較・評価できます。

契約形態

システム開発の契約は、大きく2種類に分かれます。

契約形態	説明	リスク負担
請負契約	成果物の完成を約束する。完成責任はベンダーが負う	ベンダー側が大きい
準委任契約	業務の遂行を約束する。成果物の完成義務はない	発注者側が大きい

• 請負契約 は、要件が明確な場合に適します。ベンダーは成果物を完成させる義務があり、瑕疵（かし）があれば修補責任を負います
• 準委任契約 は、要件が不明確な上流工程（要件定義、コンサルティング）や、運用・保守に適します。善管注意義務をもって業務を遂行する

一般的に、要件定義は準委任契約、設計・開発は請負契約とする 多段階契約 が推奨されています。