IT戦略・BPR・DX・ITガバナンス

IT戦略策定、EA、SOA、BPR、DX、RPA、主要システム、IT投資評価、ITガバナンス、調達プロセスを体系的に学ぶ

このページの役割

経営課題を解決するための 情報システムの設計・導入・評価 は、中小企業診断士が関わる重要なコンサルティング領域です。このページでは、IT戦略の策定から、企業全体をどう設計するか（EA）、業務をどう再構築するか（BPR・DX）、そしてシステム導入をどう進めるか（調達・ガバナンス）まで、試験で繰り返し出題される体系的な枠組みを学びます。

試験問題の多くは「経営課題が与えられて、どのIT戦略を採るべきか」という設定で出題されます。このページで全体像を理解することで、個々の概念がどう関連し、試験でどう組み合わせて問われるかが見えるようになります。

学習の流れ

第1段階：経営戦略との結びつきを理解する

IT戦略が経営戦略から導かれるプロセスを把握

第2段階：企業全体のIT設計の枠組みを学ぶ

EA（エンタープライズアーキテクチャ）で4層の構造を整理

SOAでシステムの柔軟性を理解

第3段階：業務変革とデジタル化の違いを区別する

BPR は業務プロセスの再設計

DX はビジネスモデルの変革

RPA・EPA・CA は自動化の段階

第4段階：主要システムが対象とする業務を整理する

ERP・SCM・CRM・SFA など、各システムが誰の何をサポートするか

第5段階：IT投資の評価と統制を理解する

TCO・ROI・NPV・IRR で投資判断をする

COBIT とIT統制で運用を監視する

RFI・RFP・RFQ で調達を進める

第1部 IT戦略策定プロセス

経営戦略とIT戦略の整合（ストラテジックアライメント）

定義：何が「アライメント」なのか

IT戦略とは、「経営戦略を実現するための情報技術の活用方針」です。経営層が「次の3年間で顧客基盤を2倍にする」と決めたなら、IT部門はそれを支える情報システムをどう構築・運用するかを決める必要があります。これが ストラテジックアライメント（戦略的整合） の基本です。

よくある誤りは、IT部門が独立して「最新技術を導入しよう」と判断することです。しかし診断士の立場では、経営課題との結びつきが常に問われます。

メカニズム：なぜアライメントが大切か

企業が成長するには、経営戦略と実行体制が一致していることが不可欠です。IT投資も例外ではありません。もし経営戦略が「ハイエンド市場への展開」なのに、IT戦略が「コスト削減」に偏っていたら、システム投資は無駄になります。

逆に、IT部門が経営戦略を理解していれば、投資の優先順位付けができます。「顧客基盤拡大が目標なら、CRM（顧客関係管理システム）が重要」「効率化が目標なら、業務プロセス改善とERP（統合基幹システム）の導入」といった判断ができるようになります。

比較：3つのレベルで整合を実現する

ストラテジックアライメントは1つのレベルだけでなく、3つのレベルで実現される必要があります。

レベル	対象	内容	具体例
戦略レベル	経営目標	経営戦略の目標とIT投資の方向性が一致しているか	「顧客基盤の拡大」が経営目標 → CRM導入で顧客情報を一元化して営業活動を見える化
プロセスレベル	行動計画	経営部門とIT部門が意思決定を共有できているか	新規事業立ち上げ時に、経営層とIT部門が最初から一緒にシステム構想を検討
組織レベル	統制体制	経営層がIT投資を監視・統制する仕組みが整っているか	CIO（最高情報責任者）を置いて経営会議に参加させ、IT投資の成果を報告

具体例：見直しを促す観点

「新規事業展開」という経営戦略が出たとき、IT側が考えるべき問いかけ：

新規事業の顧客層は？（CRM導入の必要性）

サプライチェーンは既存と統合？（SCM の再構築か）

意思決定スピードをどこまで上げる？（データウェアハウスやBIツール）

既存システムとの連携は可能？（マイクロサービス化の検討）

こうした問いを「戦略レベル」で経営層と議論し、「プロセスレベル」で計画化し、「組織レベル」で監視することが、真の整合です。

IT戦略策定の実践的な流れ

IT戦略を策定するには、単に「何にいくら投資するか」を決めるだけでなく、現状を正確に理解し、達成するべき姿を明確にする必要があります。

ステップ1：経営戦略の確認

中期経営計画、成長戦略、競争優位の源泉を把握

「今後3年で営業効率を30%向上させる」といった具体的な経営目標をIT言語に翻訳

ステップ2：企業環境分析（外部視点）

業界トレンド：DX の進展度、競合他社のIT化状況

技術動向：クラウド化、AI、API 経済の影響

規制変化：データ保護規制（GDPR等）への対応

競争環境：新興企業の参入、既存プレイヤーの動向

ステップ3：IT現状評価（内部視点）

既存システムの機能・老朽度：老朽システムは技術的負債として機能拡張を阻害

IT部門の能力：自社で高度なシステム開発ができるか、外部委託が必要か

運用コスト：毎年いくら運用費に使っているか、その中身は何か

ステップ4：ギャップ分析と優先順位付け

「達成すべき姿」（目標アーキテクチャ）と「現在の姿」（現状アーキテクチャ）の差を埋める施策を列挙

ROI・TCO・実現難易度を考慮して、優先順位をつける

例：「レガシーシステムの更新」「CRM導入」「AI導入」の3つ → どれから手をつけるか判断

ステップ5：IT戦略の策定と文書化

3～5年の中期IT計画を文書化

各年度の投資額、期待効果、リスク対応を明記

経営層の意思決定を記録し、後で判断の根拠を追える状態にする

ステップ6：実行管理と見直し

KPI（重要業績指標）を設定：「システム稼働率99.9%」「導入から1年でROI 20%達成」等

定期的に進捗を監視し、環境変化に応じて戦略を見直す

PDCAサイクルを回すことが重要

大企業では、営業システム、製造システム、会計システム、在庫管理システムなど、多数のシステムが独立して動いていることがあります。「営業が顧客情報を入力したら、すぐに製造部門で生産計画に反映される」といったことが起こりません。こうした サイロ化（各部門が独立して存在） を避けるため、企業全体のIT構造を統一的に設計する必要があります。これが EA（エンタープライズアーキテクチャ） の目的です。

EAは、企業全体の情報システムを4つの層で統一的に捉え、「全社的な最適」を目指す仕組みです。

メカニズム：4つの層はなぜ必要か

企業のIT投資は、上から「ビジネス → データ → アプリケーション → 技術基盤」という流れで設計されるべきです。この順序を無視すると、例えば「最新技術（TA）を導入したけれど、データが分断されたままで活用できない」といったことが起こります。

EAの4層は、この上から下への設計の順序を明確にするフレームワークです。

比較表：4つのアーキテクチャの対応関係

層	アーキテクチャ	対象	成果物の例	役割
1層目	ビジネスアーキテクチャ（BA）	業務プロセス	営業フロー図、購買プロセス、業務フロー	企業が何をするか、どの順序で進めるか定義
2層目	データアーキテクチャ（DA）	データの体系	E-R図（エンティティ・リレーションシップ図）、データ辞書	業務に必要なデータを定義し、その関係性を整理
3層目	アプリケーションアーキテクチャ（AA）	システム・ソフトウェア	アプリケーション関連図、システム間連携図	BA・DAを支えるERP、CRM、SCMなどのシステムを選定・配置
4層目	テクノロジーアーキテクチャ（TA）	インフラ・技術基盤	ネットワーク構成図、サーバー・DB構成図	アプリケーションを動かすサーバー、ネットワーク、クラウドを決定

具体例：新規事業展開でのEA設計

ある製造企業がオンライン販売に参入する場合を考えます。

ビジネスアーキテクチャ（BA）:

従来：営業→製造→出荷という営業主導のフロー

新規事業：Webサイト→自動受注→製造という自動化されたフロー

データアーキテクチャ（DA）:

顧客情報：従来は営業が名刺・手書きで管理 → 統一されたDB化

在庫情報：製造部門の管理 → Webサイトからリアルタイム参照可能に

アプリケーションアーキテクチャ（AA）:

Webストア構築（eコマース）

既存ERPとの連携で受注から出荷まで自動化

CRMで顧客情報を一元化

テクノロジーアーキテクチャ（TA）:

Webサーバーはクラウド（スケーラビリティが必要）

DB は既存システムと接続可能な構成

この4層を統一的に設計することで、「コンサルタントとして、ビジネス側の課題をIT側に翻訳し、全体最適な投資案を提示できる」ようになります。

つまずきポイント：BA・DA・AA・TA の順序が大事

試験では、EA の4層の名称と内容が問われます。大事なポイント：

BA から始まる → 技術ありきではなく、業務ニーズから出発

DA は二番目 → ビジネスを支えるデータ構造を定義

AA は BA・DA をサポート → システム選定は業務・データ要件で決まる

TA は最後 → 基盤は AA の要件で決まる

「最新のクラウド技術を使いたい（TA から考える）」という逆順の思考は、多くのシステム導入失敗の原因です。

EA / ITポートフォリオ / WBS / SLA を対象で切る

年度別では、システム化の構想 投資評価 サービス契約 作業分解 の言葉が同じ設問に並ぶことがあります。ここは、何を設計・管理している言葉か を先に固定すると崩れにくくなります。

用語	何を対象にするか	使う場面	問題文の合図	典型的な誤解
EA	企業全体の業務・データ・アプリ・基盤の構造	システム化構想、全体最適	全社最適、4層、業務とデータの整合	`投資案件の優先順位付け` の道具だと思ってしまう
ITポートフォリオ	複数の IT 投資案件	投資配分、優先順位付け	リスク、ベネフィット、資源配分、案件分類	`企業全体の設計図` だと思ってしまう
WBS	1 つのプロジェクトの作業	計画立案、進捗管理	作業分解、ワークパッケージ、担当割当	`現行業務分析の手法` だと思ってしまう
SLA	提供する IT サービスの品質水準	契約、運用管理	稼働率、応答時間、復旧時間、合意	`秘密保持契約` や `投資評価指標` と混同する

全社の業務・データ・システムを上から設計する なら EA、複数案件の中で何に資源を振るか なら ITポートフォリオ、作業を漏れなく分ける なら WBS、サービス品質をどこまで約束するか なら SLA です。主語を見失わないことが最重要です。

SOA（Service Oriented Architecture）：システムの柔軟性を高める設計

定義：「サービス」とは何か

SOAは、業務機能を「サービス」という小さな単位で設計し、それらを組み合わせてシステムを構築する考え方です。

従来のシステムは、「販売管理システム」「製造管理システム」というように、大きな単位で独立していました。しかし、業務の複雑化に伴い、「請求サービス」「在庫確認サービス」「配送手配サービス」といった粒度で、異なるシステムから呼び出せるようにしたいというニーズが出てきました。これがSOAの発想です。

メカニズム：なぜ「サービス」で分割するのか

従来のシステム統合は、以下のような問題がありました：

A社システムが更新されると、B社システムも影響を受ける

システム間の通信フォーマットが異なると、都度カスタマイズが必要

新しい業務要件が出るたびに、複数システムを改造する必要

SOA では、各機能を「疎結合（お互いに独立）」で設計することで、この問題を解決します。

比較表：SOA の4つの基本原則

原則	説明	具体例	メリット
サービスとしての分割	業務機能を独立したサービスに分割	「請求」「在庫確認」「出荷」をそれぞれ別のサービスとして設計	個別にメンテナンス・更新が可能
疎結合	サービス間の依存性を最小化	「請求サービス」が「在庫確認サービス」の内部仕様を知らなくてOK	一方が変わっても他方に影響しない
再利用性	一度作ったサービスを複数の場所で利用	「請求サービス」を営業システムからも、オンライン販売からも呼び出す	開発効率向上、品質向上
相互運用性	異なるシステム・プラットフォーム同士を標準インターフェースで連携	WebService（SOAP、REST）を使って、Java で作ったシステムと C# で作ったシステムをつなぐ	プラットフォーム選択の自由度向上

具体例：ECサイト運営企業のSOA導入

あるEコマース企業が、以下のサービスを設計したとします：

【顧客が注文】 → 【受注サービス】 → 【在庫確認サービス】
                            ↓
                    【請求サービス】 → 【配送手配サービス】
                            ↓
                    【顧客情報サービス】

従来型：各機能が独立しており、注文から配送まで手作業 SOA型：すべてがWebServiceで連携。注文が確定すると、自動で在庫確認 → 請求 → 配送手配が進む

新しい要件が出た場合：

「ギフトラッピング機能を追加」→ ギフトラッピングサービスを追加し、既存サービスと連携させるだけ

「営業代行店からも注文可能に」→ 既存の受注サービスを営業システムから呼び出す

ESB（Enterprise Service Bus）：SOA を支える技術基盤

SOA の思想を実装するには、複数のサービス（システム）間のメッセージを、統一的に管理・変換する仕組みが必要です。これが ESB です。

ESB の役割：

メッセージ変換 → システムAが送るXMLデータを、システムBが理解するJSONに変換

ルーティング → 受注メッセージを、通常注文と緊急注文で異なるサービスに振り分け

フロー制御 → メッセージの順序を保証、エラー時のリトライを自動実行

具体例： A社の販売システムから受注データが出ると、ESB が以下を自動実行：

データ形式を確認

B社の仕入先システムが理解できる形式に変換

在庫確認メッセージを送信

在庫確認結果を受け取り、発注データに変換

ERP に登録

従来は手作業だったステップが、ESB を使うことで自動化されます。

つまずきポイント：SOA とマイクロサービスの違い

試験では、SOA とマイクロサービスを区別する問題が出ることがあります：

SOA → ESB で中央集約的に管理。各サービスは独立性より整合性を重視

マイクロサービス → 各サービスが完全に独立。ESBを介さずに直接通信（API呼び出し）

SOA は「大規模企業が既存システムを統合するための設計」と覚えておくと、試験で区別しやすいです。

第3部 BPR と BPM：変化の深さによる区別

BPR（Business Process Reengineering）：業務プロセスの抜本的再設計

定義：なぜ「改善」ではなく「再設計」か

BPRは、1990年代にマイケル・ハマーとジェイムズ・チャンピーが提唱した概念です。従来の業務改善（例：業務フローの効率化、無駄な工程の削減）では、限界があります。大きな経営課題（例：競争力喪失、市場シェア低下）に直面したとき、「現在の業務フローをベースに改善」という考えでは足りません。むしろ「ゼロベースで業務フローを再設計」することで、飛躍的な成果を得ようというのがBPRの考え方です。

メカニズム：従来の改善とBPR の違い

従来の改善（インクリメンタルな効率化）：

現在の営業プロセス → 見積作成を1日短縮 → 発注作成を0.5日短縮 → 合計1.5日短縮

BPR（根本的な再設計）：

問題を再定義：「なぜ見積に1日もかかるのか」→ 「実は見積は不要。顧客はシステムで自動見積を希望」

プロセス全体を再構築：顧客がWebサイトで自動見積 → システム自動発注 → 従来の営業フローは廃止

比較表：BPR の特徴（他の改善手法との比較）

観点	従来の改善	BPR（再設計）
対象	既存プロセス内の個別の無駄	業務プロセス全体の根本的変更
思考方法	「どこが遅いか」を探す	「そもそも何のためのプロセスか」を問う
成果	20～30%の改善	50～90%の削減、サイクルタイムを数分の一に短縮
投資額	数百万円	数億円～数十億円
実行期間	数ヶ月	1～3年以上
リスク	低い（局所的影響）	高い（全社的影響、失敗リスク大）
組織への影響	部分的	根本的（組織構造、人員の大規模変更）

具体例：受注から納品のリードタイム短縮

あるメーカーが、現在「注文後3ヶ月で納品」という問題に直面しており、経営課題は「業界標準並みに3週間で納品すること」です。

従来の改善アプローチ：

営業の見積作成（現在1週間） → システム導入で3日に短縮

製造計画の策定（現在2週間） → 自動化ツール導入で1週間に短縮

部材調達・生産（現在8週間） → サプライヤーとの協業で6週間に短縮

→ 合計すると2ヶ月。目標の3週間には到達できません。

BPR（再設計）：

現在のプロセス分析：

営業から製造への伝達（1週間かかる理由：紙、FAX、確認待ち）

製造計画策定（2週間かかる理由：各種条件の検討、稟議手続き）

部材調達（3週間かかる理由：規格が多く、毎回発注が異なる）

根本的な再設計：

営業側改革 → 顧客が標準仕様のみを選べるWeb注文システムに変更。注文確定と同時にシステムが製造指示を自動生成。営業プロセスを廃止。

製造側改革 → 部材を標準化・事前備蓄。注文受け次第、その日から生産開始。製造計画策定を廃止。

調達側改革 → サプライヤー契約を「標準部材の常時供給」に変更。都度発注を廃止。

→ 受注から生産開始まで1日。納品は2週間（生産期間のみ）に短縮可能。

つまずきポイント：失敗の原因を理解する

BPRプロジェクトは失敗することが多いです。原因は：

範囲が大きすぎて、管理困難 → リスク対応に失敗

組織の抵抗が大きい → 既得権（営業の裁量権、製造の計画権）を奪われるため

IT導入と同時進行 → ビジネス設計とIT実装が混乱

経営層の覚悟が弱い → 失敗時の人員配置など、覚悟がない

診断士として、「BPRは確かに成果が大きいが、失敗リスクも相応に大きい」という判断ができることが重要です。

BPM（Business Process Management）：継続的な業務改善

定義：「改善」を継続的に実行する仕組み

BPMは、BPRと異なり、既存のプロセスを大きく変えず、継続的に小さな改善を積み重ねる アプローチです。現場の業務部門が主導し、PDCAサイクルを常に回しながら、プロセスの無駄や遅れを取り除き続けます。

トヨタの「カイゼン」の思想に近いです。

メカニズム：PDCAサイクルでプロセスを監視

BPMの実行体制：

計画（Plan） → プロセスの目標設定（例：営業プロセスのリードタイムを10%削減）

実行（Do） → 現場で小さな改善を実施（例：見積フォーマットを簡潔に、確認手続きを1ステップ削減）

確認（Check） → データで成果を測定（例：リードタイムが5日短縮されたか確認）

改善（Act） → 成功した改善を定着させ、次の課題に取り組む

このサイクルを半年ごと、毎年繰り返します。

比較表：BPR vs BPM

観点	BPR（再設計）	BPM（継続改善）
対象	業務プロセス全体	プロセス内の個別の問題点
変革の深さ	抜本的（ゼロベース）	段階的（小さな改善の積み重ね）
実行期間	1～3年以上	継続的（終わりなし）
推進主体	経営層・コンサルタント	現場の業務部門
IT役割	新しい業務を実現するシステム導入	現在のプロセスを支え、改善を監視
投資規模	数億円～数十億円	数百万円、継続的
リスク	高い（失敗時の影響大）	低い（小さな失敗で学習）
成功を判定する指標	リードタイムが3ヶ月→3週間に短縮等、劇的な改善	営業プロセスが毎年5～10%改善
実例	ダイレクト流通（仲介業者をカット）	トヨタの生産カイゼン、営業プロセス改善

実践的な選択：BPRか BPMか

診断士として経営層から相談を受けたとき、どちらを提案するか判断する観点：

BPR推奨のケース：

現在のリードタイムが業界平均の3倍以上（明らかに競争力喪失）

市場環境が急速に変化し、既存プロセスそのものが時代遅れ

新しい事業モデル（オンライン販売等）への転換が必須

経営層の覚悟と予算が確保できている

BPM推奨のケース：

現在のプロセスは大きな問題がないが、さらに効率化したい

リスクを避けたい。組織の変化に対する抵抗が大きい

継続的な改善で十分な競争力が保証できる

限られた予算内で改善を進める必要がある

第4部 DX（デジタルトランスフォーメーション）：事業そのものの変革

DXの定義：「IT化」ではなく「事業変革」

定義の正確な理解

DX（デジタルトランスフォーメーション）は、よく「デジタル化」と混同されます。しかし経営層の視点では、DXはただのIT化ではありません。

DX = デジタル技術を活用して、ビジネスモデル、顧客体験、組織文化を根本的に変革し、新しい競争優位を創造すること

BPRは「業務プロセスの再設計」という対象が限定的ですが、DXはそれを含み、さらに「顧客接点」「商品・サービス自体」「利益モデル」までを変えます。

メカニズム：DX成功の本質

DXが成功するには、以下が揃う必要があります：

技術ありきではない → 経営課題から出発（顧客離脱、新興企業との競争等）

データ活用が軸 → デジタルデータを戦略的に活用して意思決定を高速化

組織・文化の変革 → ワーク・スタイルの多様化、迅速な意思決定体制の構築

継続的な改善 → 一度のプロジェクトではなく、常にテストと改善を繰り返す姿勢

DXの3段階：階段を上るように理解する

経済産業省のDXレポートは、DX実現を3つの段階に分けています。多くの企業が「第3段階のDXをしたい」と言いますが、実は第1・第2段階がまだ十分でないケースがほとんどです。

第1段階：デジタイゼーション（アナログ→デジタル）

定義：紙・手作業をデジタルデータに変換すること。単なる「IT化」です。

特徴	詳細
目的	コスト削減、業務効率化
対象	アナログデータの電子化
期間	数ヶ月～1年
投資規模	小～中規模
成果イメージ	年間数百万円の削減

具体例：

紙の請求書 → PDF電子化（印刷・郵送コスト削減）

手書きの営業日報 → タブレット入力（情報管理の効率化）

手作業の棚卸し → バーコードスキャン（ミスと時間削減）

FAX受注 → メール受注（受発注の迅速化）

陥りやすい誤解： 「紙を電子化しただけで、情報が活用できるわけではない」。PDFの請求書を受け取っても、それをデータベースに統合しなければ、分析には使えません。

第2段階：デジタライゼーション（デジタルデータの業務活用）

定義：電子化されたデータを業務プロセスで活用し、意思決定を高速化・最適化すること。

特徴	詳細
目的	業務最適化、意思決定の高速化・精度向上
対象	デジタルデータの統合・分析・活用
期間	1～2年
投資規模	中規模（CRM、BIツール等）
成果イメージ	営業効率50%向上、在庫削減20%等

具体例：

営業活動の見える化 → 顧客情報をCRMで一元化。営業パイプラインの進捗をリアルタイムで把握。マネジャーが迅速に指導

在庫最適化 → POS、ERP、サプライヤーのデータを統合。需要予測で在庫を最適化。機会損失と保管コストを削減

顧客セグメント分析 → 購買データから顧客の価値を測定。LTVが高い顧客に集中投下。マーケティングの効率化

RPA による自動化 → 月次決算、請求発行などの定型業務を自動化。人員を戦略的業務に配置転換

この段階の課題： 「データが活用されるには、組織が変わる必要」。データを見ても、経営層が迅速に判断しなければ成果は出ません。

第3段階：DX（ビジネスモデル・顧客体験の変革）

定義：デジタル技術で、顧客接点、商品・サービス、利益モデルそのものを変革すること。

特徴	詳細
目的	新規事業創出、市場シェア獲得、顧客基盤拡大
対象	ビジネスモデル、顧客体験、組織文化
期間	2～3年以上（継続的）
投資規模	大規模（新規事業プロジェクト）
成果イメージ	売上50%増、新規顧客層の獲得

具体例：

オンライン販売チャネルの構築 → 従来は営業が訪問販売。今はWebサイトで24時間顧客対応。営業コスト削減と市場拡大を同時実現

サブスクリプション型への転換 → 従来は製品販売（一度きりの売上）。今は月額課金サービス。安定した継続売上を確保

データ提供サービスの新規事業化 → 自社が保有する業界データを外部に販売。新しい利益源を創出

プラットフォーム型ビジネス → 従来は企業向け。今はスマホアプリで一般消費者も参加可能に。マーケット規模が10倍に拡大

この段階の条件：

経営層の強い覚悟（既存ビジネスを変えるリスク）

デジタル人材（プロダクトマネージャー、データサイエンティスト）の配置

スピード重視の組織文化（失敗を許容し、学習する）

比較表：3段階の違いを一覧で理解する

比較軸	デジタイゼーション	デジタライゼーション	DX
IT化の進行度	アナログ→デジタル変換	データの統合・分析	ビジネスモデル変革
主な課題	紙の処理コスト	意思決定スピード	市場シェア・競争力
導入システム例	文書管理、帳票システム	CRM、ERP、BIツール、RPA	ブロックチェーン、AI、API経済
期待できる改善	年間数百万円～1千万円のコスト削減	営業効率30～50%向上、意思決定の迅速化	売上50%増、新規事業創出、市場開拓
リスク	低い	中程度（組織変更が必要）	高い（既存ビジネスモデルの否定）
推進期間	数ヶ月～1年	1～2年	2～3年以上（継続）
失敗の典型例	PDFへの単なる置き換え	データを集めるだけで活用されない	新規事業が軌道に乗らない、組織文化の抵抗

BPR / デジタライゼーション / DX / ITガバナンスを目的で切る

年度別では、変革、改革、デジタル化、ガバナンス が同じ選択肢群に並びます。ここは 何を変える話か で分けると安定します。

用語	何を変えるか	問題文の合図	似ているが違うもの
BPR	業務プロセス	標準化、ゼロベース再設計、ERP前提の業務統一	DXより対象が狭い
デジタライゼーション	既存業務の進め方	データ活用、業務効率化、RPA、CRM導入	DXほど事業モデルまでは変えない
DX	事業モデル・顧客体験・組織文化	新しい収益源、顧客接点の再設計、競争優位	単なるIT導入やBPRだけではない
ITガバナンス	IT投資と運用の統制	経営層、責任体制、KPI、リスク、COBIT	変革の中身ではなく監督の仕組み

迷ったら、業務フローを作り直す なら BPR、今の業務をデータで賢く回す ならデジタライゼーション、事業や顧客価値そのものを変える なら DX、それらが方針通りに進んでいるか監督する なら ITガバナンスです。

情報化社会の発展段階と関連概念

診断士試験では、DX そのものだけでなく、その周辺で使われる 第三の波 インダストリー4.0 Society 5.0 Web 3.0 といった言葉の違いも問われます。これらは似ていますが、何を中心に社会を変えようとしている概念なのか が異なります。

用語	中心テーマ	押さえるべきポイント
第三の波	情報化社会への移行	農業社会、工業社会に続く `情報・知識` 中心社会という見方
インダストリー4.0	製造業のスマート化	IoT、CPS、工場の自律分散制御による生産革新
Society 5.0	社会全体の課題解決	サイバー空間とフィジカル空間を融合し、生活や社会課題まで改善する
Web 3.0	Web の分散化・価値交換	ブロックチェーン、トークン、分散型サービスなど中央集権からの転換

整理すると、インダストリー4.0 は 工場・製造現場寄り、Society 5.0 は 社会全体寄り、Web 3.0 は インターネットの構造寄り の概念です。第三の波 はこれらを含むもっと大きな歴史観だと捉えると混乱しません。

選択肢では、たとえば次のような誤りが典型です。

Society 5.0 = 製造現場だけの自動化 とする

Web 3.0 = 単なるスマホ普及 とする

インダストリー4.0 = 社会保障や交通も含む社会全体構想 とする

こうした問題は、対象が工場か、社会全体か、Web の構造か を見れば切り分けられます。

2025年の崖：経営層が本気で対応すべき警告

問題の本質

2018年、経済産業省が「2025年の崖」というレポートを発表しました。これは「2025年までに老朽システム（レガシーシステム）を更新しないと、日本企業全体で年間最大12兆円の経済損失が出るリスク」という警告です。

なぜレガシーシステムが問題なのか？

多くの日本企業は1990年代～2000年代初期に導入したシステムに依存しています：

技術は古く（COBOL、メインフレーム等）

保守サポートが終了したり、限定的

セキュリティが脆弱

新技術（クラウド、AI、API）との連携が困難

改造が難しく、新機能追加に膨大な時間・コスト

レガシー依存のデメリット：

DX推進が困難 → クラウド化、マイクロサービス化ができない

データ活用ができない → システムが分断されたままデータが統合できない

セキュリティリスク → サイバー攻撃に脆弱。顧客データ流出等の事故リスク

人材確保が困難 → 古い技術の習得者は減少。保守者の引退が進む

事業継続困難 → 年2000時間を保守に費やし、新規事業開発に人員配置できない

対策：経営層が決断すべき3つの方向

1. レガシーシステムからの脱却

クラウド移行（AWS、Azure等）

マイクロサービス化で柔軟性確保

5～10年を見据えた段階的リプレイス

2. データ活用基盤の構築

データウェアハウス、データレイクの構築

BIツール、分析環境の整備

データを経営層が戦略判断に活用

3. DX人材の育成・採用

プロダクトマネージャー、データサイエンティストの配置

デジタル素養研修の実施

必要に応じて外部からの人材採用

DX推進指標：自社のDX進捗度を測るフレームワーク

経済産業省は「DX推進指標」という自己診断ツールを提供しており、企業がDX進捗度を測るスタートラインとなります。

構成：6つの評価軸

軸	説明	評価ポイント
1. 経営層のコミットメント	DXが経営の最優先課題として認識されているか	CIOやDX推進室の設置、経営会議での報告体制
2. デジタルリテラシー	全従業員がデジタル技術の基本を理解しているか	研修体制、若手人材の配置比率
3. データ活用体制	データを戦略的に活用する組織・プロセスが確立しているか	CDO（最高データ責任者）の配置、データ活用ガイドライン
4. レガシーシステムの状況	老朽システムからどれほど脱却できているか	クラウド化率、システム統合度、保守コストの比率
5. アジャイル開発の導入	要件変化に対応できる開発手法を取り入れているか	アジャイルチームの数、本番リリース頻度
6. セキュリティ・ガバナンス	デジタル技術に対応したセキュリティが確保されているか	ISMS認証、インシデント対応体制、定期的な監査

つまずきポイント：「診断」と「実行」のギャップ

多くの企業が「DX推進指標で自己診断してみたら、成熟度が低かった」と気づきます。しかし、そこから実行に移すには：

相応の投資（数億円～数十億円）

経営層の覚悟（既存事業の人員を割く）

3～5年の継続的な施策

が必要です。診断で問題点がわかっても、実行に踏み切れない企業が多いというのが、「2025年の崖」が現実化している理由です。

第5部 RPA と自動化技術：定型業務の効率化

RPA（Robotic Process Automation）：ソフトウェアロボットによる自動化

定義：何がロボット化できるのか

RPA は、ソフトウェアロボット が人間の定型的な事務作業を自動で実行する技術です。RPA ツール（UiPath、Blue Prism、Automation Anywhere等）をプログラミングすることで、「このシステムからデータを読み込んで、別のシステムに入力する」といった作業を自動化します。

重要なのは、「既存システムの改造が不要」という点です。システム改造は数ヶ月かかるのに対し、RPA は数週間で導入できます。

メカニズム：RPA導入で何が変わるか

導入前：

営業が受注メール確認（5分）

受注情報をメモ（3分）

ERP システムに手入力（10分）

在庫管理システムで在庫確認（5分）

手書きで納期見積作成（10分） → 合計33分、1日に30件処理で約16時間

RPA 導入後：

ロボットが受注メール取得

自動でERP に入力

自動で在庫確認

自動で納期見積メール発送 → 1件あたり20秒、1日30件で10分

削減効果： 営業担当者が1日15時間、他業務に使えるようになる。

比較表：RPA が適用できる業務と適用できない業務

業務の特徴	RPA 向き	RPA 向きでない	理由
ルールが明確か	「金額が10万円以上ならA部門へ承認」（明確）	「顧客ごとに対応を判断」（曖昧）	ロボットは判断ルールの明確さが前提
パターンが少ないか	受注形式が3パターン（少ない）	メール形式が毎回異なる（多い）	パターンが多いとロボット保守負荷増
処理量が一定か	毎日50件の請求発行	件数がまちまち（不規則）	処理量が安定していないと費用対効果が低い
システム仕様が安定しているか	3年変わらないシステム	毎月アップデート	システム変更があるとロボット再調整が頻繁

具体例：RPA 導入で効果が出やすい業務

1. 月次決算処理

従来：各部門からEXCEL で提出 → 経理担当が手作業で集計 → 1週間

RPA 後：ロボットが自動取得・集計 → 数時間

2. 請求書発行

従来：ERP から受注データ取得 → メール本文作成 → 請求書PDF出力 → 送信（1件10分）

RPA 後：上記すべて自動 → 1件あたり30秒

3. 問い合わせ分類

従来：受けた問い合わせメールを担当部門に振り分け（1件2分）

RPA 後：ロボットがキーワード判定で自動振り分け

つまずきポイント：導入失敗の原因

1. 業務ルールが曖昧だと失敗する

「顧客によって対応が異なる」という文化がある企業では、ロボット化困難

導入前に業務ルール標準化が必須

2. システム変更で保守負荷が増える

ロボットは既存システムのUI に依存

システムアップデートがあるたびに、ロボットも修正が必要

保守チームがないと、すぐに「動かないロボット」になる

3. 人員削減と見なされると組織が抵抗

RPA は「人員削減ツール」と誤解されることが多い

実際は「人員を戦略的業務に配置転換するツール」という位置づけが成功のカギ

RPA・EPA・CA：自動化技術の進化段階

RPA の登場により、企業は定型業務を自動化できるようになりました。しかし、RPA だけでは解決できない業務も多くあります。そこで、AI・機械学習を組み合わせた「Intelligent Process Automation」が登場しました。

段階別：3つの自動化レベル

段階	技術名	対象業務	実装方法	処理例	難易度
第1段階	RPA	ルール明確な定型業務	ロボットがUI を操作	受注入力、請求発行、決算集計	簡単
第2段階	EPA（Enhanced Process Automation）	判断を含む半定型業務	RPA + AI・機械学習	メール分類、異常検知、簡易審査	中程度
第3段階	CA（Cognitive Automation）	複雑な判断・例外処理を含む業務	RPA + AI + プロセスマイニング	与信審査、クレーム対応、複合的な意思決定	困難

第1段階：RPA（Robotic Process Automation）

対象業務の条件：

ルールが明確（「IF 金額>100万なら承認」）

例外が少ない

処理がエンドツーエンド完結しない（複数ステップ）

実装の特徴：

プログラミング不要。ノーコード・ローコードツールで構築

既存システムの改造不要

導入期間：数週間～2ヶ月

効果：

処理時間を90%削減

ミス率をほぼゼロに

初期投資200万円程度で費用対効果が出やすい

第2段階：EPA（Enhanced Process Automation）

対象業務の条件：

ルールが完全には明確でない（「この顧客は信用できる」といった判断）

条件が変動する（シーズンによって需要予測の精度が変わる）

例外が多い

実装の特徴：

RPA の基盤に、機械学習モデルを組み込む

過去のデータから「ルール」を学習

導入期間：数ヶ月～半年

具体例：

メール分類 → 過去のメール10,000件から、「質問」「クレーム」「提案」をAI が学習。自動分類率95%を達成

異常検知 → 日次の売上データから、「この日は異常に高い」「この顧客の購買パターンが異常」をAI が自動検知

簡易与信審査 → 顧客の財務データ、業界、与信履歴をAI が分析。融資可否の一次判定を自動化

課題：

AI モデルの精度は「学習データ」に依存

データが限られていると精度が低い

「なぜこの判定が出たか」の説明性が低い（ブラックボックス問題）

第3段階：CA（Cognitive Automation）

対象業務の条件：

複合的な判断が必要（複数のルール、複数のデータソースを総合判定）

例外処理が多い（顧客ごとに対応が異なる）

人間の創意工夫や経験が活かされる業務

実装の特徴：

RPA + AI + プロセスマイニング（業務フロー自動分析）

人間の「考える過程」をシミュレート

導入期間：1年以上

具体例：

保険クレーム対応 → 金額、事故内容、顧客履歴、過去の類似事例を総合判断。通常は支払い、特殊な場合は人間に相談。実現は困難（人間の経験をモデル化する必要）

営業提案 → 顧客の業界、課題、購買履歴からニーズを推測。最適な提案内容を推奨

現状：

技術的にはまだ発展途上

大企業が実験段階

試験では「CA という概念」が問われることが多い

つまずきポイント：自動化技術の選択

診断士として、クライアントから「業務を自動化したい」と相談されたとき、技術選定の観点：

RPA を選ぶべき：

「毎月の請求発行」「月次決算集計」など、ルールが明確

6ヶ月以内に導入したい

予算が限られている（数百万円以下）

EPA（AI を含む）を選ぶべき：

「顧客の信用度判定」「異常検知」など、ルール化が困難な判断

ある程度の学習データがある

予算と時間に余裕がある

CA は現実的ではない：

現在の技術では、人間の複合的な判断を完全に置き換えるのは困難

むしろ「人間を支援する補助ツール」としての位置づけが現実的

第6部主要経営情報システム

システムの対象範囲

経営情報システムは、企業の「どこの業務」をサポートするかで分類できます。下図は主要なシステムの位置づけです。

┌─────────────────────────────────────────────┐
│ ERP（全社基幹システム）                      │
├─────────────────────────────────────────────┤
│  ┌──────────────┐  ┌──────────────┐        │
│  │  SCM        │  │  CRM        │        │
│  │ (供給連鎖)   │  │ (顧客関係)   │        │
│  └──────────────┘  └──────────────┘        │
│  ┌──────────────┐  ┌──────────────┐        │
│  │  SFA        │  │  MES/PLM    │        │
│  │ (営業管理)   │  │ (製造)      │        │
│  └──────────────┘  └──────────────┘        │
└─────────────────────────────────────────────┘
       グループウェア、ワークフロー、KMS

ERP（Enterprise Resource Planning）

目的

経営資源（ヒト・モノ・カネ・情報）を一元管理し、経営効率化を実現

対象業務

会計（財務会計・管理会計）

販売（受注管理・売上管理）

購買（発注管理・納期管理）

生産計画・管理

在庫管理

人事給与

主な機能

統一されたデータベース

基幹業務の一元化

経営ダッシュボード

会計・税務対応

導入時の課題

導入コスト・期間が大

既存業務の抜本的見直しが必要

カスタマイズと標準機能のバランス調整

SCM（Supply Chain Management）

目的

調達→生産→在庫→物流→販売までの供給連鎖全体を最適化

対象範囲

需要予測

調達計画

生産計画

在庫管理

物流配送

サプライヤー管理

主な機能

需給計画の自動化

在庫最適化

物流ネットワーク最適化

サプライヤー協働

効果

在庫削減

リードタイム短縮

納期遵守率向上

供給リスク軽減

CRM（Customer Relationship Management）

目的

顧客情報を一元管理し、顧客との関係を継続・強化

対象範囲

顧客マスタ管理

接点履歴（問い合わせ・購買）

顧客セグメンテーション

キャンペーン管理

サポート対応

主な機能

顧客ライフサイクル管理

接点履歴の可視化

顧客分析・LTV管理

多チャネル統合

効果

顧客満足度向上

リピート率向上

顧客離脱防止

クロスセル・アップセル機会の発見

SFA（Sales Force Automation）

目的

営業活動を見える化し、営業プロセスを効率化・管理

対象範囲

案件管理

営業活動管理（訪問・電話・メール）

営業進捗報告

営業成績管理

主な機能

パイプライン管理

活動計画・実績管理

顧客接点記録

営業分析・予測

効果

営業プロセスの透明化

営業管理の効率化

提案精度の向上

営業人員の育成支援

主要システムの比較表

システム	対象業務	主な目的	主な機能	効果
ERP	全社基幹業務	経営資源の一元化	統一DB、会計・販売・購買・生産	業務効率化、意思決定の迅速化
SCM	供給の流れ全体	供給連鎖最適化	需給計画、在庫、物流	在庫削減、リードタイム短縮
CRM	顧客関係	顧客満足・継続化	顧客情報、接点履歴、セグメント	顧客満足度、リピート率向上
SFA	営業活動	営業プロセス効率化	案件管理、活動記録、進捗管理	営業見える化、提案精度向上

ERP / SCM / CRM / SFA を主語で切る

この4つは、全部業務システム とだけ覚えると崩れます。誰の何を見える化・最適化するか を先に決めてください。

問題文の主語	まず疑うシステム	理由
会計、販売、購買、生産、人事を同じDBでつなぐ	ERP	全社の基幹業務を一元化する話だから
調達から物流まで在庫と需給を最適化する	SCM	供給連鎖全体を調整する話だから
顧客情報、問い合わせ履歴、LTV、離反防止を扱う	CRM	顧客との継続関係を強める話だから
営業案件、訪問履歴、商談進捗、パイプラインを扱う	SFA	営業活動そのものを見える化する話だから

CRM と SFA は一緒に導入されやすいですが、顧客全体との関係管理 が CRM、営業担当の行動管理 が SFA です。ERP と SCM も連携しますが、社内基幹業務の統合 が ERP、供給の流れの最適化 が SCM です。

その他の主要システム

MES（Manufacturing Execution System）

対象 → 製造現場の作業指示・進捗管理

目的 → 生産スケジュール通りの製造実行

機能 → リアルタイム進捗把握、品質管理、不良検知

PLM（Product Lifecycle Management）

対象 → 製品開発～廃止までの全ライフサイクル

目的 → 製品開発の効率化、品質向上

機能 → 設計情報管理、変更管理、BOM（部品表）管理

KMS（Knowledge Management System）

対象 → 組織内の知識・ノウハウの蓄積・共有

目的 → 知識資産の活用、業務効率化、属人性の排除

機能 → ドキュメント管理、検索、コラボレーション機能

グループウェア・ワークフローシステム

グループウェア

役割 → メール、スケジュール、文書共有、掲示板などで組織内コミュニケーションを支える

効果 → 情報共有の効率化、コラボレーション促進

ワークフローシステム

役割 → 稟議・承認プロセスを自動化、ルートを明確化

効果 → 決裁スピード向上、手続きの透明化、監査証跡の記録

第7部 IT投資の評価

TCO（Total Cost of Ownership）

定義

システムの導入から廃止までの全ライフサイクルで発生する総コスト

TCO に含まれるコスト

コスト要素	説明
導入費	ハードウェア購入、ソフトウェアライセンス、構築費用
運用費	保守委託料、サポート料金
人件費	システム運用・管理人員の給与
管理費	施設費（データセンター家賃）、電力、ネットワーク
教育費	ユーザー研修
隠れたコスト	トラブル対応、ダウンタイム損失

計算例

初期投資 = ハードウェア 500万円 + ソフト 300万円 + 構築 700万円 = 1,500万円
年間運用費 = 保守 200万円 + 人件費 400万円 + 管理費 100万円 = 700万円
5年TCO = 1,500万円 + (700万円 × 5年) = 5,000万円

ROI（Return on Investment）

定義

投資に対する利益の割合。システム導入による経済効果を見える化

計算式

ROI = (年間便益 - 年間コスト) ÷ 初期投資 × 100%

計算例

初期投資 = 1,500万円
年間便益（人員削減、処理時間短縮） = 800万円
年間運用コスト = 700万円

1年目ROI = (800万円 - 700万円) ÷ 1,500万円 × 100% = 6.7%

試験では「3年で投資を回収する」「年間ROI 10%以上」といった目安が提示されることもあります。

NPV（正味現在価値）

定義

将来の現金流を現在価値に割り引いた純利益。投資判断の基準

計算式

NPV = Σ [現金流入 - 現金流出] ÷ (1 + 割引率)^年数

簡単な計算例

割引率 10%で計算

初期投資: -1,500万円（0年目）
1年目: +500万円 → 現在価値 = 500万円 ÷ 1.1 = 454.5万円
2年目: +600万円 → 現在価値 = 600万円 ÷ 1.1^2 = 495.9万円
3年目: +700万円 → 現在価値 = 700万円 ÷ 1.1^3 = 525.9万円

NPV = -1,500万円 + 454.5万円 + 495.9万円 + 525.9万円
    = -23.7万円（わずかな赤字）

→ NPVが負なので、この投資は採算性が低い（割引率を下げるか、便益を増やすか検討が必要）

判断基準

NPV > 0 → 投資の価値あり（現在価値で利益が出ている）

NPV < 0 → 採算性が低い（検討し直す必要あり）

NPV = 0 → 投資と利益が相殺（割引率がIRRと等しい）

IRR（Internal Rate of Return）

定義

NPVが0となる割引率。投資の内部収益率

意味

投資による平均的な年間利益率を表します。IRRが高いほど、効率的な投資です。

判断基準

IRR > 企業の資本コスト → 投資推奨（企業の最低利益率を上回っている）

IRR < 企業の資本コスト → 投資非推奨

比較例

プロジェクトA: IRR 15%
プロジェクトB: IRR 8%
企業の資本コスト: 10%

→ プロジェクトAは資本コスト(10%)を上回るので推奨
→ プロジェクトBは資本コスト(10%)を下回るので非推奨

IT投資評価フレームワーク

実践では複数の指標を組み合わせて評価します。

指標	使い方	判断基準
TCO	全体コストを把握	競合他社・業界平均と比較
ROI	年間採算性を見る	3～5年で投資回収目安
NPV	現在価値で判断	NPV > 0 で推奨
IRR	投資効率を見る	IRR > 資本コストで推奨
ペイバック期間	投資回収の早さ	業界・プロジェクト特性で決定

TCO / ROI / NPV / IRR / ペイバック期間を時間軸で切る

年度別では、費用対効果 投資回収 採算性 といった言い方で、複数の指標がまとめて並びます。ここは 何を見ている指標か と 時間価値を考えるか で切ると崩れません。

指標	何を見ているか	時間価値を考えるか	典型的な使い方	混同しやすい相手
TCO	導入から廃止までの総コスト	考えない	複数案の総費用比較	ROI と混同しやすいが、便益は含まない
ROI	投資に対してどれだけ利益が出るか	通常は考えない	粗い採算性の比較、導入効果の見える化	ペイバック期間と混同しやすいが、年数ではなく利益率
NPV	将来便益を現在価値に直したときの純利益	考える	複数年投資の採否判断	ROI より厳密。割引率が必要
IRR	NPV が 0 になる割引率	考える	資本コストとの比較で採否判断	NPV とセットで使う
ペイバック期間	投資額を何年で回収できるか	通常は考えない	資金拘束期間の短さを見る	ROI と混同しやすいが、率ではなく期間

初学者がよく混同するのは、ROI = 投資回収期間 ではない点です。ROI は どれだけもうかるか、ペイバック期間 は 何年で回収できるか を見ています。TCO はさらに別で、そもそも総額いくらかかるか を見る指標です。

TCO / ROI / NPV / IRR を判断順で切る

設問で数値が並んだら、次の順で見ます。

総コストを比べる問題か → まず TCO を疑う

利益率や費用対効果を聞いているか → ROI を疑う

割引率や現在価値が出ているか → NPV を疑う

資本コストや最低必要利回りと比べるか → IRR を疑う

何年で回収できるかを聞いているか → ペイバック期間を疑う

割引率 現在価値 資本コスト が出たら、単なる ROI 問題ではなく、NPV / IRR の文脈だと考えるのが安全です。

IT投資価値評価ガイドラインの3類型

経済産業省の IT投資価値評価ガイドライン では、投資案件を 何で価値を出すタイプか で分ける考え方が重要です。ここを押さえると、全部を同じ物差しで比べる 誤りを避けられます。

類型	何を狙う投資か	主な評価軸	例
インフラ型	事業の土台を安定させる	可用性、保守性、リスク低減、法令対応	ネットワーク更改、バックアップ基盤、セキュリティ基盤
業務効率型	コスト削減や処理時間短縮を狙う	工数削減、処理件数、エラー削減、TCO、ROI	受注入力自動化、ワークフロー導入
戦略型	売上拡大や競争力強化を狙う	売上増、顧客維持率、シェア、LTV、定性的便益	EC 構築、会員アプリ、CRM 強化

インフラ型 は直接売上を増やすとは限らないため、売上増が見えないから不要 とは切れません。逆に 戦略型 は金額換算しにくい便益も多く、ユーザ満足度や競争優位のような定性的指標も併せて見ます。設問で 全部を金銭だけで測るべきだ と言っていたら疑ってください。

第8部 ITガバナンス

ITガバナンスの定義

経営層が IT投資・運用を統制し、経営戦略を実現するための組織・プロセス・ルール

ITガバナンスとIT戦略の違い：

IT戦略 = 「何をするか」の方針を決める

ITガバナンス = 「方針通りに実行されているか」を監視・統制する

IT戦略と ITガバナンスを役割で切る

どちらも経営寄りの話 なので混ざりやすいですが、問われているものは違います。

観点	IT戦略	ITガバナンス
中心課題	何に投資し、何を実現するか	方針通りに動き、価値とリスクを管理できているか
典型キーワード	優先順位、競争力、投資テーマ、ロードマップ	責任体制、監督、統制、KPI、リスク、COBIT
主な担い手	経営層、CIO、企画部門	経営層、取締役会、監査、IT統制責任者
設問の形	`何を先にやるべきか`	`どう監督・管理するか`

クラウドERPを導入すべきか は IT戦略、導入後に責任分担と評価指標をどう置くか は ITガバナンスです。やる内容 と やった後の統制 を分けると、選択肢の役割が見やすくなります。

COBITは、IT統制の国際的フレームワークです。ISACA（情報システムコントロール協会）が定めています。

COBITの構成（COBIT 2019）

COBITは以下の要素で構成されます：

要素	説明
プロセス	IT部門が実行すべき40のガバナンスおよびマネジメント目標
RACI	各プロセスの責任者・実行者・承認者・相談者を明確化
メトリクス	各プロセスの成熟度を測定する指標
ガバナンス構造	経営層とIT部門の意思決定プロセス

COBITの5つの領域

領域	説明
評価・指示・監督（EDM）	ガバナンスの方向性を設定し、戦略との整合と目標達成を評価・監督
整合・計画・組織化（APO）	経営戦略とIT戦略を整合させ、計画・組織化する
構築・調達・導入（BAI）	ITソリューションの構築・調達・導入と、業務プロセスへの統合を管理
提供・サービス・サポート（DSS）	ITサービスの運用・提供・サポートを管理（セキュリティ・インシデント対応含む）
監視・評価・査定（MEA）	ITパフォーマンスと内部統制の整合性を監視・評価・査定する

試験では「COBITが統制の枠組みである」「RACI等で責任を明確化する」という概念が出題されます。

IT統制の3分類

IT統制は、企業が情報資産を守り、経営目標を達成するための統制です。3つのレベルに分けられます。

1. IT全般統制（General IT Controls）

IT組織全体の管理体制と基盤

統制項目	内容	具体例
組織体制	IT部門の位置づけ、責任分担	CIO設置、IT投資委員会
セキュリティ	アクセス権限、データ保護	システムへのパスワード管理、機密情報の暗号化
システム運用	バックアップ、災害復旧	日次バックアップ、BCPの策定
変更管理	システム改造時の承認・テスト	本番環境への変更は承認後に実施
監視・監査	運用状況の監視、内部監査	ログの記録・分析、年1回の監査

2. IT業務処理統制（Application Controls）

個別システムの処理が正確・適切に行われるための統制

統制項目	内容	具体例
入力統制	データ入力の妥当性チェック	金額の上限チェック、形式の検証
処理統制	計算・処理の正確性	消費税計算の自動化、金種チェック
出力統制	出力データの妥当性確認	試算表の事前確認、異常値検知
ファイル管理	データの完全性・整合性	バージョン管理、更新ログ

3. IT全社的統制（Entity-level Controls）

経営層が全体的な IT目標達成を監視する統制

統制項目	内容	具体例
経営姿勢	経営層の内部統制への関与度	経営会議での IT報告、コンプライアンス体制
リスク管理	IT関連リスクの特定・評価・対応	リスク登録簿の作成、リスク軽減計画
目標設定	IT投資・運用の成功基準	KPI設定、目標達成度の確認
人事評価	IT人材育成、適切な配置	IT部門の教育研修計画

CCSF（共通キャリア・スキルフレームワーク）

CCSF は、IT 人材育成で どの人にどの能力が必要か を整理するための共通の物差しです。ここで大切なのは、フレームワークをそのまま当てはめるのではなく、自社に必要なタスクを先に洗い出す ことです。

観点	CCSF で見ること	初学者が誤りやすい点
出発点	自社の業務や役割で必要なタスク	フレームワークの役職名をそのまま採用すればよいと思う
整理の仕方	タスクに必要な知識・技能をひも付ける	先にスキル一覧を決めてから仕事を当てはめる
使い道	育成計画、配置、評価、採用基準の明確化	試験勉強専用の分類だと考える

設問で CCSF をそのまま自社へ適用する と書いてあれば危険です。まず 自社で何の仕事をしてもらうか を決め、そのタスクに必要なスキルを対応付ける流れで読みます。

第9部調達プロセス

調達プロセスの全体像

情報システムを導入するとき、企業は以下の段階を経て調達を進めます。

RFI → RFP → RFQ → 提案評価 → 契約 → 導入・運用

RFI（情報提供依頼書）

目的

ベンダーから技術トレンド・製品情報を幅広く収集し、市場理解を深める

特徴

対象ベンダー → 複数ベンダー（5社～10社程度）

形式 → 自由回答形式が多い

内容例 → 「クラウドERP導入の成功事例」「リスク対策」

回答期間 → 2～4週間

活用方法

市場理解：導入方法の選択肢を幅広く探索

要件洗い出し：RFIの回答から自社の要件を絞る

ベンダー選定：RFP段階での提案参加ベンダーを決定

RFP（提案依頼書）

目的

自社の要件を詳細に記述して、ベンダーから具体的な提案を引き出す

特徴

対象ベンダー → 限定ベンダー（2～3社程度）

形式 → 自社の要件を詳細に記述、ベンダーに同じフォーマットで提案を求める

内容例 → システム要件、導入スケジュール、カスタマイズ方針、契約条件、サポート体制

回答期間 → 4～8週間

RFPに含むべき項目

項目	説明
背景・目的	自社の経営課題、IT化の目的
システム要件	機能要件、非機能要件、セキュリティ要件
導入計画	スケジュール、フェーズ分割、リスク対応
カスタマイズ方針	標準機能の活用優先、カスタマイズは最小限
総所有コスト	初期投資、運用費、ライセンス形態
契約条件	支払い条件、SLA、ペナルティ
サポート体制	保守期間、対応時間、技術支援

RFQ（見積依頼書）

目的

特定製品・サービスについて、正確な見積金額を取得

特徴

対象ベンダー → RFPで提案を受けたベンダーの中から選定、または複数ベンダーからコスト競争

形式 → 仕様を固定して、見積金額のみを比較

回答期間 → 2～4週間

RFQの活用

比較検討 → 複数ベンダー間の見積をそろえて比較

価格交渉 → 見積を基に値引き交渉を進める

RFI / RFP / RFQ を要件の固まり方で切る

この3つは、全部ベンダーに出す文書 と覚えるだけでは過去問で崩れます。要件がどこまで固まっているか を見ると切り分けやすくなります。

文書	目的	この時点の要件	比較するもの	問題文の合図
RFI	市場や製品情報を集める	まだ粗い	できること、実績、導入パターン	情報収集、事例収集、方向性探索
RFP	提案を受ける	かなり固まっている	機能対応、進め方、体制、提案内容	要件定義、提案依頼、評価基準
RFQ	見積を取る	ほぼ固まっている	価格、費用条件、納期条件	見積比較、価格交渉、仕様固定

迷ったら、まだ何を入れるか探っている なら RFI、何を実現したいかは決まっていて提案を比べたい なら RFP、提案の中身はおおむね固まり価格を比べたい なら RFQ です。

SLA（Service Level Agreement）

定義

ベンダーと顧客間で、サービス品質の基準と責任を定めた契約

一般的なSLA項目

項目	説明	具体例
稼働率	システムが利用可能な時間の割合	99.9%以上
対応時間	トラブル報告から対応開始までの時間	緊急時1時間以内
復旧時間	システム障害から復旧までの時間	4時間以内
サポート時間	技術サポートの受付時間	平日9時～18時
ペナルティ	SLA違反時の補償	稼働率99.9%以下で月額費用5%割引

SLA違反時の対応

サービスクレジット → 顧客に返金・割引で補償

改善計画 → ベンダーが再発防止策を提示

契約解除 → 継続的にSLAを満たさない場合は契約解除も可能

調達プロセスの流れ（詳細）

段階	主な活動	期間
1. 企画・計画	経営課題の整理、IT投資の必要性判定	1～3ヶ月
2. RFI配布	複数ベンダーに市場情報を広く照会	2～4週間
3. RFI回答収集・分析	ベンダー情報から自社要件を洗い出し	1～2週間
4. RFP作成	自社要件を詳細に記述	2～4週間
5. RFP配布	限定ベンダーに提案依頼	-
6. RFP回答収集	ベンダーからの提案を回収	4～8週間
7. 提案評価	技術・価格・実績を総合評価、ベンダー選定	2～4週間
8. RFQ・価格交渉	見積もりを取得、値引き交渉	2～4週間
9. 契約締結	SLA等の契約条件を最終確認、契約	1～2週間
10. 導入・運用	システム構築、テスト、本番運用開始	数ヶ月～1年

典型的なつまずき

EA の4層（BA・DA・AA・TA）を整理できない → 「ビジネス→データ→アプリケーション→基盤技術」の流れで上から順に考える

SOAとESBの関係が不明確 → SOAは設計思想、ESBはそれを実現する技術基盤と整理

BPRと DXを同じと思ってしまう → BPRは業務再設計（手段）、DXは事業変革（目的）と分ける

BPMを知らずにBPRと混同 → BPRは抜本的・全社的、BPMは段階的・局所的と分ける

DXの3段階の違いを説明できない → デジタイゼーション（紙→デジタル）、デジタライゼーション（業務効率化）、DX（事業変革）

RPAを「すべての業務に適用できる」と思う → 定型的で判断ルールが明確な業務のみ適用可能

ERP・SCM・CRM・SFAを全部「システム」と雑にまとめる → 対象範囲と目的で区別する

TCO・ROI・NPV・IRRの計算式を混乱させる → TCO（全コスト）、ROI（利益率）、NPV（現在価値）、IRR（割引率）と整理

ROIとペイバック期間を同じだと思ってしまう → ROI は割合、ペイバック期間は回収にかかる年数

ITガバナンスを「IT部門の管理」と狭く解釈 → 経営層が全体をコントロールする統制体制

調達プロセスでRFI・RFP・RFQの違いがわからない → RFI（情報収集）、RFP（提案比較）、RFQ（見積比較）の順で整理

問題を解くときの観点

「IT戦略」「IT投資」「ガバナンス」のどれを問われているか

IT戦略 → 「経営目標を実現するために何に投資すべきか」

IT投資 → 「投資判断の基準は何か（ROI・NPV・IRR）」

ガバナンス → 「投資後、方針通りに運用されているか」

システム導入を検討する際の観点

その課題は「業務効率化」か「事業変革」か → BPRか DXか

何の「業務」を対象とするか → ERP？SCM？CRM？SFA？

導入後の評価指標は何か → TCO？ROI？NPV？IRR？稼働率（SLA）？

まだ情報収集段階か、提案比較段階か、価格比較段階か → RFI？RFP？RFQ？

リスク・落とし穴を見極める

「老朽システムの更新」と「DX」は別の課題（2025年の崖との関係）

RPAは「便益が高いが、適用業務が限定される」という二面性

ERP導入は「カスタマイズを増やすと失敗リスクが高まる」

調達時に「要件定義が不十分」だと後で手戻りが発生

確認問題

問1：ストラテジックアライメントと IT投資優先順位

問題： 食品製造企業の経営層は、「今後3年間の競争力強化」を掲げています。IT戦略の責任者として、以下の3つの IT投資案が提案されました。

（A）既存販売管理システムの老朽化対策（保守期限が2年後）（B）DX推進として、オンライン販売チャネルの構築（C）営業支援システム（SFA）の導入で営業活動を見える化

経営戦略「競争力強化」との ストラテジックアライメント を考えると、優先順位が最も高いのはどれか？また、その理由を述べよ。

解答：

優先順位：(B) オンライン販売チャネルの構築

理由：

経営戦略「競争力強化」との整合 → 新しい販売チャネルの構築は、競争優位の創造に直結する（DXの定義に合致）
（A）の老朽化対策は「必要な対応」ではあるが、直接的には競争力強化に貢献しない（保守費用の圧縮程度）
（C）のSFAは既存営業体制の効率化であり、新たな競争力源泉ではない
（B）は顧客との新しい接点創造 → 事業変革 → DXの定義

補足： ただし、（A）の老朽化対策が「急務」である場合は、並行実施が必要。全体のリスク管理も見極める必要があります。

問2：ERP導入と BPR 実施の関係性

問題： 製造企業がグローバル展開を進めるため、複数の子会社をまとめる統一 ERP システムの導入を検討しています。現在、各子会社は独自の販売・会計システムを使用しており、統合前には統一的な業務プロセスを構築する必要があります。

この場合、ERP導入前に実施すべきは BPR か BPM か？また、その理由を述べよ。

解答：

実施すべきは BPR（業務プロセスの抜本的再設計）

理由：

BPRが必要な背景 → 各子会社の業務プロセスがバラバラ → 統一ERP導入時には「どの業務プロセスを標準化するか」を抜本的に決める必要がある
ERP の標準機能を活かすため → ERP は統一されたデータベース・業務ロジックを前提に設計されているため、導入前に業務を標準化（再設計）しないと、カスタマイズが増加 → 導入失敗リスク
BPM では不十分な理由 → BPM は既存プロセスの段階的改善であり、根本的な統一にはならない → グローバル統一 ERP には合わない

補足： ERP導入 → 標準機能を活かしながら、段階的に改善（BPM）という流れが理想的です。

問3：DX と 2025年の崖の関係

問題： 地方銀行の経営層は「DX推進による顧客体験向上」を謳い、新しいデジタル施策の投資を考えています。しかし、IT部門から「現在、20年前のメインフレームシステムが稼働中であり、新しい技術（AI・クラウド）との連携が困難」という指摘が上がっています。

この状況は経済産業省の「2025年の崖」の警告とどう関連するか？また、先に対応すべきは何か？

解答：

2025年の崖との関連性：

老朽システムが DX の足かせ → 20年前のメインフレームシステムは、AI・クラウドなどの新技術と統合困難 → DX推進が停滞
この企業は「デジタルトランスフォーメーション予備軍」 → デジタイゼーション・デジタライゼーションの段階で足踏みしており、DXの第3段階（事業変革）に進めない

先に対応すべき順序：

レガシーシステムからの脱却（最優先） → メインフレームのクラウド移行、オープンシステム化
新しい技術基盤の構築 → データを一元化、AI導入の準備
その後、DX施策の推進 → 顧客向けのデジタル体験を構築

理由：「見た目の DX施策」だけを進めても、基盤となる IT インフラが古いままでは、実質的な DX にはならない

問4：BPR / DX / ITガバナンスの切り分け

問題： 次の状況で、最も中心になる考え方を答えてください。

（A）ERP 導入前に、子会社ごとに異なる受注・購買・会計フローをゼロベースで統一したい
（B）既存店舗販売中心の企業が、アプリ会員基盤とサブスクリプションを作り、顧客体験と収益モデルを変えたい
（C）取締役会が、IT投資のKPI、責任分担、リスク管理の仕組みを定期的に点検したい

解答例

（A）BPR
（B）DX
（C）ITガバナンス

解説

A：対象は業務プロセスそのものなので BPR です。
B：顧客接点と収益モデルまで変えるので DX です。
C：やる内容ではなく、監督と統制の仕組みを問うているので ITガバナンスです。

問5：ERP / SCM / CRM / SFA の切り分け

問題： 次の状況で、最も中心になるシステムを答えてください。

（A）販売・購買・会計・在庫のデータを全社で1つのデータベースに統合したい
（B）需要予測と在庫・物流の計画をつなげ、欠品と過剰在庫を減らしたい
（C）顧客属性、問い合わせ履歴、購買履歴を一元化し、離反防止施策につなげたい
（D）営業担当ごとの商談進捗や訪問履歴を見える化し、案件管理を標準化したい

解答例

（A）ERP
（B）SCM
（C）CRM
（D）SFA

解説

A：全社基幹業務を統合するので ERP です。
B：供給連鎖全体の最適化なので SCM です。
C：顧客との関係管理なので CRM です。
D：営業活動の見える化なので SFA です。

問6：TCO / ROI / NPV / IRR / ペイバック期間の切り分け

問題： 次の状況で、最も中心になる指標を答えてください。

（A）クラウド会計システム案とオンプレミス案について、5年間でかかる導入費・保守費・教育費・運用人件費の総額を比べたい
（B）新システム導入で、初期投資 1,000 万円に対して年間純便益が 150 万円見込める。利益率として効果を見たい
（C）3年間のキャッシュフローを 8% で現在価値に割り引いたら、合計が初期投資を上回るかを見たい
（D）プロジェクトの内部収益率が 12% で、企業の資本コストが 9% である。採用可否を判断したい
（E）何年で投資額を回収できるかを重視したい

解答例

（A）TCO
（B）ROI
（C）NPV
（D）IRR
（E）ペイバック期間

解説

A：総コスト比較なので TCO です。便益はまだ見ていません。
B：利益率を見ているので ROI です。回収年数ではありません。
C：割引率で現在価値に直しているので NPV です。
D：資本コストと比べる内部収益率なので IRR です。
E：何年で回収できるかを見るのでペイバック期間です。

問7：RFI / RFP / RFQ の切り分け

問題： 次の状況で、最も適切な文書を答えてください。

（A）自社に合う販売管理システムの方向性がまだ固まっておらず、各社の製品概要や導入事例を広く集めたい
（B）必要な機能、導入時期、セキュリティ要件は整理できたので、各ベンダーの提案内容と体制を比較したい
（C）提案候補を2社まで絞り、同一仕様で見積金額と保守条件をそろえて比較したい

解答例

（A）RFI
（B）RFP
（C）RFQ

解説

A：要件を固める前の情報収集なので RFI です。
B：要件を示して提案を比べる段階なので RFP です。
C：仕様を固めた上で価格と条件を比べる段階なので RFQ です。