コンサルティング完全解説｜グランドデザイン・EA

1コンサルティングの全体像

コンサルティングとは：企業が抱える経営・業務・IT上の課題に対して、専門知識と客観的な視点で分析・提言・実行支援を行うサービス。「課題の発見→解決策の立案→実行支援」が基本構造。

コンサルティングの3大領域

戦略コンサル

経営戦略・事業ポートフォリオ・M&A・市場参入。CEOレイヤーに提言。

McKinseyBCGBain

業務コンサル（BPR）

業務プロセス改革・組織設計・人材・コスト削減。COO・業務部門が対象。

DeloittePwCKPMG

ITコンサル

IT戦略策定・システム化計画・EAの構築・DX推進。CIO・情報システム部門が対象。

Accenture富士通NTTData

現実の境界は曖昧：大手コンサルファームは3領域すべてをカバーする「総合コンサル」になっている。特にITコンサルと業務コンサルは「DX」という文脈で一体化している。

コンサルが扱う「課題の階層」

レベル	問い	アウトプット	主な担い手
L1 経営戦略	「何をやるか」「どこで戦うか」	中期経営計画・事業ポートフォリオ	戦略コンサル
L2 グランドデザイン	「将来の姿をどう描くか」	全体構想・IT中期計画・ロードマップ	ITコンサル・業務コンサル
L3 EA（アーキテクチャ設計）	「業務・システムをどう構造化するか」	エンタープライズアーキテクチャ文書	ITコンサル・SIer
L4 要件定義・設計	「具体的に何を作るか」	要件定義書・基本設計書	SIer・ベンダー
L5 開発・実装	「どう作るか」	システム本体・テスト報告書	SIer・ベンダー・内製

IT営業としての位置付け：L2〜L4が最も商談に直結する。グランドデザインやEAの話ができると「下流の実装だけ請け負うベンダー」ではなく「上流から議論できるパートナー」として認知される。

2コンサルティングファームの種類と特徴

主要ファーム分類

分類	代表企業	強み・特徴	IT営業での関わり方
MBB（戦略トップ3）	McKinsey / BCG / Bain	経営層への影響力が絶大。IT実装は基本やらない	彼らの提言が「IT投資のトリガー」になることが多い。報告書を読んで動向を把握する
Big4系	Deloitte / PwC / EY / KPMG	監査法人起源。戦略〜業務〜ITの一貫支援。グローバル案件に強い	グランドデザイン・EA策定フェーズで競合になることも。パートナーシップの可能性もある
ITコンサル専業	Accenture / CapGemini	IT実装まで一気通貫。デジタル・AI領域に注力。大規模SIも担う	直接競合になるケースが多い。差別化ポイントを明確にする必要あり
国内系	野村総研 / 日本総研 / 富士通コンサル	日本企業の商習慣・規制に詳しい。公共・金融・製造に強い	国内大企業向けは競合・協業両面。業界特化の知識で差別化

3グランドデザイン（Grand Design）詳解

グランドデザインとは：企業の将来あるべき姿（To-Be）を、業務・組織・ITシステムの全体にわたって描いた「最上位の構想図」。中期経営計画と現場の実装計画の間に位置し、両者を繋ぐ役割を持つ。「何を・いつまでに・どの順番で実現するか」の全体ロードマップ。

グランドデザインの構成要素

① 現状分析（As-Is）

現在の業務フロー・組織・ITシステムの実態を可視化。問題点・非効率・重複を洗い出す。

主な成果物：現状業務フロー図・システム構成図・課題一覧・IT資産棚卸し

↓

② 将来像の設計（To-Be）

3〜5年後に実現したい業務・組織・ITの姿を定義する。経営戦略と整合させた「あるべき姿」。

主な成果物：将来業務フロー図・将来システム構成図・KPI目標・データ活用構想

↓

③ ギャップ分析

As-IsとTo-Beの差（ギャップ）を明確化。「何が足りないか」「何を変えなければならないか」を特定。

主な成果物：ギャップ一覧・課題優先度マトリクス・システム廃棄・新規構築リスト

↓

④ ロードマップ策定

ギャップを埋めるための施策を、優先度・依存関係・予算・体制を考慮して時系列に並べる。

主な成果物：中期IT計画・プロジェクトポートフォリオ・予算概算・実行組織設計

グランドデザインが必要とされる場面

トリガー	具体例
中期経営計画の策定・改訂時	新社長就任・事業戦略の大転換・3カ年計画の更新
基幹システムの老朽化	レガシーシステムの2025年問題・ERP刷新の検討開始
M&A・組織統合	買収後の統合計画（PMI）・グループシステム統合
DX推進の号令	「DX戦略を立てよ」という経営層の指示を具体化
規制・コンプライアンス対応	サイバーセキュリティ強化・個人情報保護法改正対応

グランドデザイン vs IT中期計画 ── 違いは何か

観点	グランドデザイン	IT中期計画
視点	業務・組織・ITを横断した全体構想	IT部門が実行する計画
期間	3〜10年の長期スパン	3年程度の実行計画
抽象度	高い（「こうあるべき」）	低い（「何をいつまでに」）
オーナー	経営層・CDO・CIO	CIO・情報システム部
役割	方向性を定める「羅針盤」	グランドデザインを具体化した「実行計画」

現場では「グランドデザイン≒IT中期計画」として使われることも多い。厳密な区別より「上位概念（Why・What）と実行計画（How・When）を分けて考える」習慣を持つことが重要。

グランドデザインの典型的な構成（成果物）

章立て	内容
エグゼクティブサマリー	全体の要点を1〜2ページで経営層向けに整理
経営環境・外部要因	市場トレンド・競合動向・規制変化（PESTLE分析等）
現状分析（As-Is）	現行業務フロー・システム構成・課題・IT資産の可視化
将来構想（To-Be）	3〜5年後の業務像・デジタル活用ビジョン
移行計画・ロードマップ	優先プロジェクト・フェーズ分け・依存関係
投資計画・体制	概算コスト・ROI試算・推進組織（CDO室等）
リスク・ガバナンス	リスク一覧・管理体制・KPI設定

4Enterprise Architecture（EA）詳解

Enterprise Architectureとは：企業（Enterprise）全体を「ビジネス・アプリケーション・データ・テクノロジー」の4層で体系的に整理し、全体最適なIT投資と組織設計を実現するためのフレームワーク。1980年代にIBMのジョン・ザックマンが提唱し、米国政府（FEAF）や民間（TOGAF）を通じて世界標準となった。

EAの4つのアーキテクチャ（4ドメイン）

EAは「上から下へ」の階層構造。上位のビジネス（業務）の要求が、下位のテクノロジー（インフラ）の選定を決定づける。逆方向（技術ありき）で設計すると全体が歪む。

🏢 BA：ビジネスアーキテクチャ（Business Architecture）

「企業が何をする組織か」を定義する最上位レイヤー。業務プロセス・組織構造・役割分担・ビジネスルールを可視化する。

含む内容：業務フロー図（BPMN）・組織図・機能分解図・業務機能モデル・バリューチェーン
問い：「この会社はどんな業務をどのような流れで行っているか？」

↓

💻 AA：アプリケーションアーキテクチャ（Application Architecture）

「どんなシステム・アプリケーションがあり、どう連携しているか」を定義するレイヤー。BAで定義した業務をどのシステムが担うかをマッピングする。

含む内容：システム構成図・アプリケーション一覧・システム間連携図（インターフェース一覧）・パッケージ vs 自社開発の判断
問い：「どのシステムがどの業務を支えているか？重複・空白はどこか？」

↓

🗄️ DA：データアーキテクチャ（Data Architecture）

「企業の情報（データ）がどこにあり、どう流れ、誰が管理しているか」を定義するレイヤー。DX・AI活用の基盤となる。

含む内容：データモデル（ERD）・マスタデータ管理（MDM）・データフロー図・データ品質基準・データレイク・DWH設計
問い：「顧客データはどこに何個あるか？データの正本はどこか？」

↓

⚙️ TA：テクノロジーアーキテクチャ（Technology Architecture）

「上記を動かすインフラ・ネットワーク・プラットフォームをどう構成するか」を定義する最下位レイヤー。クラウド・オンプレ・ネットワーク・セキュリティが対象。

含む内容：インフラ構成図・クラウド選定方針・ネットワーク図・セキュリティアーキテクチャ・技術標準（ガイドライン）
問い：「アプリケーションを動かすサーバー・NW・クラウドは何か？標準化されているか？」

EAを導入する目的（なぜ必要か）

IT投資の全体最適化
部門ごとのバラバラなシステム調達をなくし、重複投資・サイロ化を解消。限られたIT予算を戦略的に配分できる。

システム複雑度の管理
大企業では数百〜数千のシステムが乱立しがち。EAで全体を可視化することで、廃棄・統合・更新の計画が立てられる。

変化への適応力向上
M&A・組織改編・新規事業など変化が起きたとき、EAが整備されていれば「何をどう変えればよいか」が素早く判断できる。

コンプライアンス・セキュリティ強化
「どこに何のデータがあるか」「どのシステムがどのリスクを持つか」が可視化でき、監査対応や規制準拠に有効。

EA成熟度モデル（どのレベルにあるか）

レベル	状態	特徴
Lv.0	なし（場当たり）	システムは存在するが設計思想なし。部門ごとに勝手に調達。全体が把握できていない
Lv.1	文書化	既存システムをリストアップ・図化した段階。As-Isが可視化されている
Lv.2	標準化	技術標準・購買ガイドラインが整備。新規調達はルールに従う
Lv.3	最適化	4ドメインが整合して管理。投資判断にEAが活用されている
Lv.4	ビジネス主導	EA組織が経営戦略と連動。変化に即座に対応できる動的アーキテクチャが実現

日本の大企業の多くはLv.1〜Lv.2に留まる。「EA整備のプロジェクト自体」がIT投資として重要なテーマになっている。

5TOGAF（EA標準フレームワーク）

TOGAF（The Open Group Architecture Framework）とは：世界で最も普及したEAフレームワーク。The Open Groupが策定・管理。EA策定の「手順書＋成果物テンプレート」として機能する。資格試験（TOGAF Foundation / Practitioner）も存在する。

TOGAFの中核：ADM（Architecture Development Method）

ADMはEAを「どの順番でどう作るか」を定義した反復型プロセス。フェーズA〜Hを循環させながらアーキテクチャを継続的に進化させる。

前提

予備フェーズ

Phase A

アーキテクチャビジョン

Phase B/C/D

BA → AA → DA → TA

Phase E/F

機会・移行計画

Phase G/H

実装ガバナンス・変更管理

フェーズ	内容	主な成果物
予備フェーズ	EA推進体制・原則・スコープを定義する	EA原則・ガバナンス体制
Phase A：ビジョン	EA策定の目的・ステークホルダー・スコープを定める	アーキテクチャビジョン文書
Phase B：BA	現状・将来のビジネスアーキテクチャを設計	業務フロー図・機能分解図
Phase C：AA/DA	アプリ・データアーキテクチャを設計	システム構成図・データモデル
Phase D：TA	技術アーキテクチャを設計	インフラ構成図・技術標準
Phase E/F：移行計画	ギャップ分析・移行プロジェクトの特定・優先付け	ロードマップ・移行計画書
Phase G：実装ガバナンス	プロジェクト実行中のアーキテクチャ準拠確認	アーキテクチャレビュー記録
Phase H：変更管理	EA自体を変化に合わせてアップデート	変更要求・更新版EA文書

TOGAF vs その他のEAフレームワーク

フレームワーク	概要	特徴
TOGAF	The Open Group策定。企業向け標準	最も普及。ベンダー中立。資格あり。プロセス中心
Zachman Framework	IBMのJ.ザックマンが1987年提唱	「誰が・何を・どこで・いつ・なぜ・どうやって」×「レイヤー」の6×6マトリクス。分類整理ツールとして優秀だがプロセスは示さない
FEAF（米国政府）	米国連邦政府のEA標準	官公庁・公共系案件で参照される。行政DXの文脈で日本でも注目
SAP EA Framework	SAP導入前提のEA	SAP中心のアーキテクチャ設計に特化。ERP刷新案件で使われる

6グランドデザインとEAの関係

2つの概念の位置関係

上位 ←→ 下位

経営戦略・中期経営計画

「何のためにどの事業で成長するか」— 経営レイヤーが決定

↓

グランドデザイン

「経営戦略を実現するために業務・ITをどう変えるか」の全体構想とロードマップ

↓

Enterprise Architecture（EA）

グランドデザインのTo-Beを「BA→AA→DA→TA」の4層で構造化・詳細設計する

↓

個別プロジェクト（要件定義・設計・開発）

EAの設計に従って実装する個別システム

グランドデザインとEAの違い

観点	グランドデザイン	EA
目的	将来の全体像と方向性を示す	構造を体系的に設計・管理する
詳細度	粗い（方向性レベル）	細かい（設計レベル）
期間	プロジェクト単位（数カ月）	継続的に維持・更新
成果物	構想文書・ロードマップ	4ドメインの体系的な設計図群
主な使い手	経営層・事業部門への説明	IT部門・アーキテクト・SIer

実務での使われ方（典型パターン）

Step 1：コンサルがグランドデザインを作成 → 経営陣が承認
Step 2：EAチームがグランドデザインのTo-BeをBPMNで業務設計（BA）
Step 3：BAに基づきどのシステムが何を担うかを設計（AA）
Step 4：データの持ち方・流れを設計（DA）
Step 5：インフラ・クラウド構成を設計（TA）
Step 6：各システムの個別プロジェクトを発注・開発

現実のよくある失敗：グランドデザインを作ったが、EAで構造化されないままプロジェクトが走り始め、気づいたら個別最適のサイロが再生産される。

7コンサルティングの進め方・プロセス

標準的なコンサルプロジェクトの流れ

フェーズ	内容	期間目安	主な成果物
①提案・スコープ定義	課題のヒアリング・提案書作成・契約	2〜4週間	提案書・SOW（作業範囲定義書）
②アセスメント（現状調査）	インタビュー・文書調査・ベンチマーク比較	1〜2カ月	現状分析報告書・課題一覧
③グランドデザイン策定	To-Be設計・ギャップ分析・ロードマップ	2〜3カ月	グランドデザイン文書
④EA設計・詳細化	4ドメインの詳細設計・技術標準策定	3〜6カ月	EA設計文書一式（BA/AA/DA/TA）
⑤実装支援・PMO	プロジェクト管理・ベンダー管理・進捗監視	1〜3年	議事録・課題管理表・変更管理

コンサルの職位と役割

職位	役割	IT営業での関係
パートナー / MD	案件責任者・クライアント経営層との関係管理	キーマン。彼らの信任が予算執行を左右する
マネージャー	プロジェクト運営・品質管理・中間報告	実務の意思決定者。提案の詳細を詰める相手
シニアコンサルタント	実作業リード・後輩指導・クライアント窓口	日常のコミュニケーション相手。技術的な議論ができると差がつく
コンサルタント / アナリスト	調査・分析・資料作成	現場実務担当。データや事例を共有するとスムーズ

8IT営業としての商機と活用方法

コンサル・グランドデザイン・EAをIT営業に活かす

グランドデザインが走っているタイミングは「大型IT投資の意思決定前夜」。一番刺さる時期
EAの話ができるだけで「下請けSIer」ではなく「上流から考えるパートナー」として認知される
顧客のシステムがLv.0〜Lv.1（場当たり状態）なら、EA整備自体を提案テーマにできる
コンサルファームと競合するのではなく「コンサルの後工程を請け負う」ポジションを取るのが現実的
グランドデザインで特定されたギャップ（課題）がそのまま「プロジェクト発注リスト」になる

フェーズ別の商機マッピング

コンサルフェーズ	商機	刺さる提案	優先度
グランドデザイン策定中	情報提供・技術調査支援	PoC・技術検証・事例提供。「我々はこんな支援ができる」を提示	種まき
EA設計（BA〜TA）	設計支援・ツール提案	EA管理ツール（LeanIX等）・BPMN設計支援・アーキテクト派遣	中
ロードマップ確定後	個別プロジェクト受注	優先度の高いプロジェクトへの提案。EAと整合した設計ができることをアピール	最高
実装・PMOフェーズ	開発・運用・保守受注	EAに準拠した実装。アーキテクチャガバナンスへの継続参画	最高

商談で使えるEA・グランドデザインの切り口

「御社の現状システムはAAレベルで見ると、□□と△△が重複機能を持ちコストが二重に発生しています。グランドデザインを描く前に、まず現状のシステム構成図を一緒に可視化しませんか」

「中期経営計画でDXを掲げていらっしゃると思いますが、EAが整備されていないと個別プロジェクトを積み重ねても全体最適になりません。弊社はEA策定のご支援も含めた提案ができます」

「グランドデザインで描いたTo-Beとシステム実装が乖離するリスクがあります。弊社がEAのTAレイヤーを担うことで、設計から実装まで一貫して整合性を担保できます」

注意事項・やってはいけないこと

「EA整備しましょう」だけでは刺さらない
EA整備は目的ではなく手段。「EA整備によって何が解決されるか（コスト削減・意思決定スピード向上・DX加速）」を経営層の言葉で語ること。

コンサルファームと正面衝突は避ける
グランドデザイン策定フェーズはコンサルが主役。「その後の実装を請け負う」ポジションを明確にした方が関係が築きやすい。コンサルとの協業関係を積極的に構築する。

EA用語は誤用に注意
「アーキテクチャ」「EAの4層」を間違って使うと、相手（特にコンサル出身者）に即座に見抜かれる。使うなら正確に。自信がない場合は「システム全体の設計」と言い換えた方が安全。