6.1システム戦略と企画

経営戦略を実現する手段としてITをどう使うかを定めるのが情報システム戦略です。応用情報のストラテジ系では、単に用語の定義を覚えるだけでなく、なぜその手順・その体系で進めるのが妥当なのかという因果関係まで問われます。戦略から全体最適の設計図（EA）に落とし込み、必要なら業務プロセス自体を作り変え、実際のシステム化・調達プロジェクトへとつなげる一連の流れと、それぞれの工程で何を判断材料にするかを理解することが土台になります。

6.1.1情報システム戦略とEA

• 情報システム戦略＝経営戦略・事業戦略を実現するために、情報システムをどう整備・活用するかを定めた中長期の方針。単なるIT部門の計画ではなく、経営目標との整合が出発点になります。
• エンタープライズアーキテクチャ（EA）＝組織全体の業務とシステムをビジネス・データ・アプリケーション・テクノロジの4体系で整理し、「現状（As-Is）」から「あるべき姿（To-Be）」への移行計画を描く手法。部門ごとに個別最適化されたシステムの乱立（サイロ化）を防ぎ、全体最適を図る狙いがあります。EAの策定・実行サイクルは、方針を定める「アーキテクチャ・ビジョン」→現状分析の「As-Is」→将来像の「To-Be」→両者の差分を埋める「移行計画」という順で進みます。

6.1.2BPR/BPM・業務モデリング・RPA・DX

• BPR（Business Process Reengineering）＝既存の業務プロセスをゼロベースで根本的に見直し、再設計する取り組み。単なる部分改善ではなく、組織構造や業務フローの抜本的な変革を指します。BPM（Business Process Management）＝業務プロセスを継続的に可視化・分析・改善していくマネジメント手法（PDCAに近い改善サイクルを業務プロセスに適用）。BPRが「一度の抜本改革」なら、BPMは「改善を回し続ける仕組み」です。
• 業務モデリング＝業務の流れや情報のやり取りを図式化して可視化する手法（例：業務フロー図、DFD（データフローダイアグラム））。現状把握と改善対象の特定に使い、後続の要件定義の入力にもなります。RPA（Robotic Process Automation）＝定型的な事務作業（データ入力・転記・帳票出力など）をソフトウェアロボットが人に代わって自動実行する仕組み。人手不足対策・ヒューマンエラー削減に直結しますが、業務プロセス自体の見直し（BPR）を伴わずにRPA化すると非効率な手順をそのまま自動化してしまう点に注意が必要です。
• DX（デジタルトランスフォーメーション）＝デジタル技術の活用により、製品・サービス・ビジネスモデルそのもの、さらには組織文化までも変革し、競争上の優位性を確立すること。既存業務のIT化（デジタイゼーション）や部分的なデジタル化（デジタライゼーション）にとどまらず、事業モデルの変革まで踏み込む点が本質です。

6.1.3システム化計画・要件定義・調達

• システム化計画＝経営戦略・情報システム戦略を踏まえ、どのシステムを・いつ・どの優先順位で開発するかを定める計画。要件定義＝システム化計画を受け、利用者・業務部門が何を実現したいか（業務要件・機能要件・非機能要件）を明確にする工程。この後の開発工程すべての土台になるため、ここでの認識齟齬が手戻りの最大要因になります（上流工程での誤りほど、下流での修正コストが指数的に増大する）。
• RFI（Request For Information）＝発注候補となるベンダーに情報提供を依頼する文書（技術動向・実績の把握が目的）。RFP（Request For Proposal）＝要件を提示し、具体的な提案（システム構成・スケジュール・見積り）を依頼する文書。RFIが先・RFPが後という順序、および「情報収集」か「提案依頼」かという目的の違いが問われます。相見積り＝複数のベンダーから見積りを取り、価格・提案内容を比較検討すること。単純な価格比較だけでなく、提案内容の実現性・実績も含めた総合評価が求められる点がレベル3の論点です。
• ソリューションビジネス＝製品単体を売るのではなく、顧客の経営課題を分析し、最適な解決策（システム・サービス・運用）を組み合わせて提供するビジネス形態。近年はクラウド（IaaS/PaaS/SaaS）・SaaSの活用提案が中心で、自社で基盤を保有せず利用形態で調達する選択肢の妥当性を判断する場面が増えています。

中堅製造業A社が紙の伝票処理と部門別に乱立したExcel管理から脱却したいという相談を例に、判断の連鎖を追ってみます。まず経営層は「3年で受発注業務のリードタイムを半減する」という経営目標を掲げ、これを実現する情報システム戦略を策定します。次に、現状の業務システムが部門ごとにバラバラで全体最適になっていないことが分かったため、EAの手法でビジネス（受発注プロセス）・データ（顧客/在庫マスタ）・アプリケーション（各部門の個別システム）・テクノロジ（老朽化したサーバー群）の4体系についてAs-Is/To-Beを整理します。その過程で、紙の承認フローが処理遅延の主因と判明しました。ここでA社のIT部門は当初「承認業務をそのままRPAで自動化すればよい」と考えましたが、業務モデリングでDFDを描いて分析したところ、承認ルートに重複した確認工程が2つ含まれていることが判明します。非効率な手順をそのままRPA化すると、遅い処理が速く回るだけで根本課題は残ると判断し、まず承認プロセス自体を電子化・簡素化するBPRに踏み切ってから、定型的な受注データ入力をRPAで自動化する、という正しい順序を選びました。空いた人員はより付加価値の高い顧客対応へ再配置します。ここまでは既存業務の効率化ですが、A社はさらに一歩進め、蓄積した受発注データを分析して需要予測サービスを取引先に提供する新事業を立ち上げることを決め、これをDXと位置づけます。実際のシステム化にあたってはシステム化計画で優先順位（まず受発注システムの刷新から着手）を定め、業務部門を巻き込んだ要件定義で「発注から出荷までの処理を3日以内に完了させる」といった要件を固めます。開発を外部委託するにあたり、まず複数のベンダーに技術動向や実績を尋ねるRFIを送付し、その回答をもとに絞り込んだ数社へRFPを発行して提案を求め、さらに相見積りで価格だけでなく提案内容の実現性・過去の類似案件実績も含めて総合評価し、発注先を決定します。自社基盤を新設せずクラウドSaaSを利用形態で調達する案も候補に残し、初期投資を抑える選択肢として比較検討します。

6.1.4この節のまとめ

• 情報システム戦略＝経営目標との整合が出発点。EA＝ビジネス/データ/アプリケーション/テクノロジの4体系でAs-Is→To-Beを描き全体最適を図る
• BPR＝抜本的な一度の再設計を先に行い、その後でRPA（定型自動化）を適用するのが妥当な順序。DX＝事業モデル/組織文化の変革（目的）
• 要件定義は開発の最上流（手戻りの最大要因）。調達はRFI（情報提供）→RFP（提案依頼）→相見積り（総合評価）の順