システム一覧の前に、
変革の判断原則と、強化すべき企業能力を明確にする。
EA原則は、部門・案件ごとに揺れる設計判断へ一貫性を与えます。企業能力マップ（Capability Map）は、現在の組織図やシステム構成から離れ、「事業として何ができる必要があるか」を共通言語にします。このサンプルでは、原則、企業能力、経営価値、業務・情報・アプリケーションへの追跡を一つの検討構造として示します。
EA原則と企業能力マップは、
投資案を選ぶために使う。
網羅的な図を作ることが目的ではありません。複数部門・複数システムにまたがる変革で、何を標準化し、何を差別化し、どの企業能力へ先に投資するかを判断します。
経営とITの言葉を揃える
戦略テーマを機能要件へ直接変換せず、必要な企業能力と意思決定へ展開します。
投資の焦点を絞る
価値寄与、課題影響、依存関係、準備度から、強化すべき企業能力の優先順位を議論します。
設計判断を統一する
原則、例外条件、決定権を定義し、案件ごとの個別最適と再議論を減らします。
現実的に移行する
TargetだけでなくTransition Architectureを置き、依存関係と段階的な移行を示します。
原則を標語で終わらせず、
具体的な判断基準と例外条件にする。
原則は「常に守る理想」ではなく、選択肢を比較する基準です。適用範囲、理由、実務への含意、例外条件、責任者、見直し条件を一組で管理します。
ツール起点では価値との対応関係が失われ、重複機能、過剰要件、部門最適が生じやすいため。
投資要求に、価値ドライバー、対象となる企業能力、Decision Use Case、効果仮説、依存関係を添付する。
法令・セキュリティ・サポート終了等の期限対応は、リスク根拠と暫定期間を明記して例外審査する。
原則責任者、Architecture Review、投資会議の役割を定義し、案件内だけで例外を確定しない。
戦略・規制・主要プラットフォームの変更、重大な例外蓄積を契機に妥当性を再確認する。
Value before solution
価値、意思決定、企業能力から必要性を説明する。
One meaning, explicit owner
重要データの意味と責任を共有し、暗黙の重複定義を避ける。
Reuse before build
共通能力と差別化能力を分け、再利用の判断を先に行う。
Transition by design
Targetだけでなく、移行中の業務・データ・統制を設計する。
組織図ではなく、
「できる必要があること」で全体を見る。
以下は業種を特定しない説明用マップです。赤は優先議論の想定例、グレーは依存関係の確認対象で、実在企業の成熟度評価ではありません。
方向付け・統制
市場・顧客
供給・実行
経営基盤
サンプルの読み方：色の強弱は成熟度や優劣を表す実測値ではありません。実際には、戦略寄与、顧客・業務影響、現状課題、依存関係、実行準備度を根拠とともに評価し、優先する企業能力を合意します。
経営の言葉を、
実装要件まで切らさない。
各層を別資料にしても、識別子と関係を持たせることで「この要件は何のためか」「この戦略に必要な能力は揃っているか」を追跡できます。
例：継続収益の拡大／意思決定速度／統制リスク低減。
例：顧客インサイト、価値提案、案件管理、データマネジメント。
誰が、どの頻度で、何を比較し、どの行動を変えるか。
End-to-Endプロセス、役割、例外、データ定義、品質責任。
機能配置、連携、標準、セキュリティ、運用、ライフサイクル。
何を先に整え、どのTransition Architectureを経てTargetへ移るか。
点数だけで決めず、評価根拠と依存関係を残す。
評価軸は戦略と対象範囲に合わせて定義します。スコアは議論を置き換える答えではなく、前提の違いを見つける補助線です。
| 評価軸 | 確認する問い | 主な根拠 | 判断上の注意 |
|---|---|---|---|
| 戦略寄与 | 目標とする価値・顧客・リスクにどの程度直結するか。 | 中期計画、価値ドライバー、経営KPI。 | 抽象的な「重要」で揃えず、寄与経路を示す。 |
| 現状ギャップ | 必要能力と現在の意思決定・業務・情報の差は何か。 | 業務観察、KPI、課題、統制、利用者の声。 | システム老朽化だけを企業能力のギャップとしない。 |
| 依存・波及 | 他の施策や企業能力の前提になるか。 | 依存関係図、データ・プロセス・アプリ配置。 | 前提整備と価値実現の順序を分けて考える。 |
| 実行準備度 | 責任者、データ、人材、予算、変更余力があるか。 | 体制、スキル、データ可用性、既存プロジェクト。 | 準備度が低い重要領域を単純に後回しにしない。 |
図が埋まったかではなく、
判断が前へ進むかを確認する。
最終成果物だけでなく、作成途中の論点と反証可能性をレビューします。
粒度と境界が一貫している
組織、プロセス、システム名が企業能力に混在せず、対象範囲とレベルが説明できる。
優先度の根拠を示せる
経営価値、課題、データ、関係者の判断を分け、推定だけで根拠のない評価をしていない。
更新責任が決まっている
原則とMapの責任者、利用会議、変更契機、版、例外、関連成果物を管理できる。
EAの作成自体を目的にせず、
重要な設計判断に活用する。
- 01 / FRAME
経営課題を定義
価値ドライバー、変える意思決定、対象範囲、期限を整理します。
判断：なぜ今変えるか - 02 / MAP
企業能力を可視化
必要能力、現状の課題、責任、依存関係を共通言語にします。
判断：何を強くするか - 03 / DESIGN
原則とTargetを合意
業務・データ・アプリ・技術の設計方針と例外条件を決めます。
判断：どう設計するか - 04 / TRANSITION
段階的な移行計画へ展開
準備度、依存関係、価値実現、リスクを踏まえ段階計画へ変換します。
判断：何から実行するか
掲載方針：確認できない支援実績、顧客名、改善率、案件数、資格、成果保証は掲載しません。本サンプルの適用可否と必要粒度は、対象企業の事実と目的を確認して判断します。
複数のDX施策を、
一つの投資判断と移行計画へ。
既存のシステム一覧、DX施策表、中期計画、RFPがある場合も、まだ構想段階の場合も構いません。強化する企業能力と判断原則から、必要なEA成果物を整理します。