「システムが増えすぎて、全体像を誰も把握できない」「新しい施策を打つたびに、既存システムとの整合でつまずく」——こうした課題に直面したIT部門長やDX推進責任者が、解決策として行き着く言葉が EA（エンタープライズアーキテクチャ） である。近年はレガシー刷新やDXの文脈でEAが再び注目され、標準フレームワークであるTOGAFの最新版（第10版）が扱いやすく整理し直されたこと、EA人材の需要が再燃していることも、その追い風になっている。
一方で、EAには「壮大な絵を描いたものの、現場で使われないまま棚に眠った」という失敗の記憶がつきまとう。実際、2000年代にEAブームが起きたとき、多くの日本企業や官公庁が大規模なEAプロジェクトに着手し、そして少なからずが形骸化した。
本稿は、これからEAを立ち上げようとする企業に向けて、同じ失敗を繰り返さずにEAを「使われる仕組み」として根づかせるには、どこから・どこまで手をつけるべきか を整理する。想定読者は、情報システム部門長、IT企画・DX推進の責任者、EA立ち上げの担当者、そしてCIO・経営層である。フレームワークの用語解説ではなく、意思決定と推進の立場から何を決め、何を捨てるか に焦点を当てる。
そもそもEAとは何か ― 4つの層で「全体像」を揃える
EA（エンタープライズアーキテクチャ）とは、企業のビジネス・情報システム・技術基盤を一貫した視点で捉え、あるべき全体像（To-Be）と現状（As-Is）を可視化し、その差を計画的に埋めていくための考え方と方法論である。しばしば「企業の都市計画」にたとえられる。個々の建物（システム）を最適化する前に、道路や区画（全体の構造）を設計する、という発想だ。
EAは一般に4つのアーキテクチャ層で全体像を整理する。
| 層 | 何を扱うか | 主な問い |
|---|---|---|
| ビジネスアーキテクチャ（BA） | 業務プロセス・組織・機能 | どんな業務を、誰が、どう回すか |
| データアーキテクチャ（DA） | データの構造・流れ・管理 | どんな情報を、どこで持ち、どうつなぐか |
| アプリケーションアーキテクチャ（AA） | システム・アプリ群の構成 | どの機能を、どのシステムが担うか |
| テクノロジーアーキテクチャ（TA） | インフラ・基盤・技術要素 | どの基盤の上で動かすか |
重要なのは、この4層は「上から下へ」つながっているという点だ。ビジネス（BA）で何をしたいかが決まって初めて、必要なデータ（DA）、それを扱うアプリ（AA）、動かす基盤（TA）が導かれる。EAが機能しない組織では、この順序が逆転し、技術基盤やツール選定の議論が先行して、ビジネス上の狙いが後づけになっている ことが多い。
なぜ日本企業のEAは形骸化するのか
EAを立ち上げる前に、まず「なぜ過去のEAは失敗したのか」を理解しておく価値がある。失敗パターンには共通の構造があるからだ。
1つ目は、成果物づくりが目的化すること。 全社のシステムを網羅した膨大な構成図や台帳を作り上げること自体がゴールになり、完成した頃には現状が変わっていて、誰もメンテナンスしなくなる。EAの本来の目的は「意思決定を速く・正しくすること」であって、ドキュメントを揃えることではない。
2つ目は、“全体を一気に” 描こうとすること。 4つの層を全社・全システム分、最初から精緻に描こうとすると、着手から成果が見えるまでに長い時間がかかる。その間に経営の関心が離れ、予算が細り、プロジェクトが宙に浮く。
3つ目は、現場から切り離された “専門家集団” になること。 EAチームが事業部門や開発現場と接点を持たないまま「あるべき姿」を描くと、現場は「実態に合わない理想論」として受け取り、従わない。ルールだけが残り、実務は別で回る——これが形骸化の典型である。
4つ目は、経営の意思決定と結びついていないこと。 EAが「IT部門の中の活動」にとどまり、投資判断やプロジェクトの承認プロセスに組み込まれていないと、EAを無視しても誰も困らない。使われない仕組みは、必ず形骸化する。
これらはいずれも、「壮大に、網羅的に、正しく描けば価値が出る」という前提から生まれる失敗だ。EAを立ち上げるうえでの出発点は、この前提を捨てることにある。
EAをどこから始めるか ― 課題ドリブンのスモールスタート
形骸化を避ける最大のコツは、全社網羅から始めないこと である。「いま経営やIT部門が本当に困っている問い」を起点に、その意思決定に必要な範囲だけを可視化することから始める。
具体的な始め方は、おおむね次のステップになる。
- 目的を1つに絞る。 「基幹システム刷新の優先順位を決めたい」「重複した業務システムを統廃合したい」「新規事業のシステム構想を描きたい」など、EAで解きたい経営課題を1つ選ぶ。目的が定まると、描くべき範囲と粒度が決まる。
- その課題に関係する範囲だけをAs-Is（現状）で可視化する。 全システムではなく、対象領域の業務・データ・システム・基盤に絞る。ここで「どのシステムが、どの業務を、どのデータで支えているか」の関係が見えると、それだけで議論の質が変わる。
- To-Be（あるべき姿）と、その差分（ギャップ）を描く。 現状のどこに問題があり、理想とどれだけ離れているか。差分こそが、次の投資やプロジェクトの対象になる。
- 差分を埋めるロードマップに落とす。 ギャップを一度に埋めようとせず、優先順位をつけて段階的な計画にする。
- 1つの意思決定で成果を出し、横に広げる。 最初の課題でEAが役立ったという実績を作ってから、次の領域へ範囲を広げる。
この進め方の要点は、「描く」こと自体を成果にせず、必ず1つの意思決定に接続する ことだ。可視化した結果として「この順番で刷新すべき」「このシステムは統合できる」という判断が下せて初めて、EAは価値を持つ。
なお、現状（As-Is）の可視化は、EA立ち上げで最も工数がかかり、かつ最も陳腐化しやすい部分でもある。台帳や構成図を手作業のドキュメントで抱えると、更新が追いつかず形骸化を招く。この領域は、システム・業務・データの関係を継続的に管理できるEAツール（当社の「Portist」もこの領域の製品である）を活用し、最新の状態が保たれる仕組み として持つことが望ましい。
TOGAF などのフレームワークをどう使い分けるか
EAを立ち上げる際、必ず「フレームワークは何を使うべきか」という問いが出る。代表的なものを整理すると、次のようになる。
| フレームワーク | 特徴 | 向いている場面 |
|---|---|---|
| TOGAF | The Open Groupが策定する、最も広く使われるEA標準。ADM（構築の反復手順）を中核に、成果物・体制まで体系化 | 標準に沿って本格的にEAを組織化したいとき |
| Zachman Framework | アーキテクチャを分類する「マトリクス」。手順ではなく整理の枠組み | 情報を体系的に分類・整理したいとき |
| 独自の軽量フレームワーク | 自社の実態に合わせて要素を絞った簡易版 | 小さく速く始めたいとき |
実務上のポイントは、TOGAFを「全部やる」必要はない ということだ。TOGAFの中核であるADM（Architecture Development Method）は、ビジネス構想から実装・移行、運用まで反復的に回す一連の手順を定義しているが、これを最初から全フェーズ厳密に適用しようとすると、前章で述べた「壮大すぎて頓挫する」失敗に近づく。
TOGAFの最新版（第10版）は、こうした反省も踏まえ、基本部分（Fundamental Content）と追加のガイダンスを分けたモジュール構造に整理され、必要な部分だけを取り出して段階的に使える ようになっている。フレームワークは「準拠すべき規範」ではなく「先人が整理した部品箱」として捉えるのが実践的だ。自社の目的に必要な考え方・成果物・手順を取り出し、要らないものは使わない。
The Open Group によれば、TOGAF Standard, 10th Edition はモジュール構造を採用し、組織の種類やアーキテクチャのスタイルに応じてフレームワークを適用しやすくすることを狙いとしている。 出典：The Open Group「The TOGAF® Standard, 10th Edition」 https://www.opengroup.org/togaf
「TOGAFを導入する」と考えると身構えてしまうが、実際に必要なのは、共通の用語と考え方をチームで揃え、成果物のテンプレートを流用すること である。フレームワークはそのための道具であって、目的ではない。
推進体制 ― 誰がEAを担い、PMOやIT企画とどうつなぐか
EAは「描く人」だけでは機能しない。描いた全体像を意思決定に反映させる体制が要る。立ち上げ期の現実的な体制は、次のように整理できる。
- EA推進の責任者（オーナー）： IT企画部門長やCIO配下に置く。EAを「IT部門内の設計活動」に閉じず、投資判断とつなぐ責任を持つ。
- アーキテクト（少数の中核メンバー）： 全体像を描き、標準・原則を整備する。立ち上げ期は少人数で十分。むしろ大人数の専任組織を先に作ると、成果物づくりが自己目的化しやすい。
- 事業部門・開発現場の窓口： 各領域の実態を持つ人を巻き込む。現場と切り離さないための生命線である。
- PMO・IT企画との接続： EAが描いた「あるべき姿」とロードマップを、実際のプロジェクト起案・予算承認・進捗管理につなぐ。
とりわけ重要なのが、最後の PMO・IT企画との接続 だ。EAが「あるべき全体像」を示し、PMOが「個々のプロジェクトの推進」を担う——この2つが分断されていると、EAは絵に描いた餅で終わる。逆に、新規プロジェクトの起案時に「EA上の位置づけ」と「全体整合」をチェックする関門を設ければ、EAは自然と意思決定プロセスに組み込まれ、使われ続ける。
EAとプロジェクト推進をどう連携させるかは、当社のサービスでも中核に据えている観点である。EAで全体の地図を描き、PMOでプロジェクトを走らせる——この両輪が揃って初めて、EAは投資判断を変える力を持つ。
よくある失敗と回避策
| よくある失敗 | 何が起きるか | 回避策 |
|---|---|---|
| 全社を一気に網羅しようとする | 成果が出る前に関心と予算が尽きる | 経営課題を1つに絞り、必要な範囲だけ描く |
| 成果物づくりがゴールになる | 完成時には陳腐化し、誰も使わない | 「1つの意思決定に接続する」ことをゴールにする |
| EAチームが現場から孤立する | 実態に合わず、現場に無視される | 事業・開発現場の窓口を必ず巻き込む |
| フレームワークを厳密に全適用する | 手順が重くなり頓挫する | 必要な部分だけ取り出す（部品箱として使う） |
| 投資判断とつながっていない | 無視しても困らず、形骸化する | 起案・承認プロセスにEAチェックの関門を組み込む |
| As-Isを手作業で抱える | 更新が追いつかず古くなる | 継続管理できる仕組み・ツールで最新状態を保つ |
いずれの回避策にも共通するのは、「網羅性」ではなく「意思決定への接続」を評価軸に置く、という発想である。
FAQ
Q. EAを始めるのに、まずTOGAF認定資格を取るべきか？ A. 立ち上げの必須条件ではない。資格は共通言語を身につける助けにはなるが、資格取得を先行させると「フレームワークに従うこと」が目的化しやすい。まずは解きたい経営課題を1つ決め、その範囲で小さく描いてみることを勧める。フレームワークの学習は、実務と並行させたほうが定着する。
Q. 小さく始めると、結局「部分最適」になってしまわないか？ A. 出発点は部分でも、常に「全体像の中での位置づけ」を意識して描けば、部分最適には陥らない。むしろ全社を一気に描こうとして頓挫し、何も残らないほうが、部分最適以前の問題である。最初の1領域で共通の型（用語・成果物・原則）を作れば、横展開のたびに全体の一貫性は高まっていく。
Q. EAとDX推進は何が違うのか？ A. DXが「変革の目的・打ち手」だとすれば、EAは「変革を全体整合の取れた形で進めるための土台」である。DXの施策が既存システムとの整合でつまずくのは、多くの場合EAが不在だからだ。DXを掲げる企業ほど、その足場としてEAが要る。
Q. EAとPMOはどう役割分担するのか？ A. EAは「あるべき全体像とロードマップ」を描く役割、PMOは「個々のプロジェクトを計画通りに推進する」役割である。EAが地図を描き、PMOがその地図に沿って走らせる、という関係になる。両者が連携していないと、EAは意思決定に反映されず形骸化する。
まとめ
EAは、DXやレガシー刷新で「全体が見えない」課題に直面した企業にとって、有効な処方箋になり得る。ただし、その価値は「壮大で網羅的な絵を描くこと」からは生まれない。過去のEAが形骸化したのは、まさにそこに力を注ぎすぎたからだ。
これから立ち上げるなら、押さえるべきは次の点である。
- 全社網羅から始めず、経営課題を1つに絞る（課題ドリブンのスモールスタート）
- 「描く」ことをゴールにせず、必ず1つの意思決定に接続する
- TOGAF等のフレームワークは “部品箱” として必要な部分だけ使う
- EAを投資判断・プロジェクト起案の関門に組み込み、PMOと連携させる
- 現状の可視化は、最新状態が保たれる仕組みとして持つ
EAは、正しく小さく始めれば、次のシステム投資の優先順位を変える力を持つ。逆に、大きく始めれば棚の肥やしになる。立ち上げの成否は、最初に「何を捨てるか」を決められるかにかかっている。
なお、生成AIやAIエージェントを前提としたレガシー刷新をEAの視点からどう進めるかは、生成AI時代のレガシーモダナイゼーションでも扱っている。あわせて参照されたい。
参考資料
- The Open Group「The TOGAF® Standard」 https://www.opengroup.org/togaf
- The Open Group「The Open Group Announces Launch of the TOGAF® Standard, 10th Edition」 https://www.opengroup.org/open-group-announces-launch-togaf-standard-10th-edition