なぜ今、EAが必要なのか――社内ITが「管理」から「設計」に変わるべき理由

DX・AI・SaaSの波の中で、社内IT部門はいまだに「管理者」のままでいられるのか。業務部門がSaaSを勝手に導入し、AIツールが現場に乱立し、DXの名のもとにプロジェクトが同時並行で走る時代に、ITを「管理する」だけでは組織は崩壊に向かう。管理者は要件が決まるのを待つ。設計者は要件が決まる場そのものを作る。この違いが、今の社内ITに突きつけられている問いだ。エンタープライズアーキテクチャ（EA）が改めて必要とされる理由を、現場の経験とデータをもとに語っていく。

1. 「出せるものがない」という虚しさ

CIOのコミュニティや1on1の場で、他社のCIOが自社のITロードマップや全体設計を自信を持って取り出してくる場面がある。業務・アプリケーション・データ・技術基盤のレイヤーごとに整理され、経営の言語で語られた資料だ。

そのとき、自分たちには出せるものが何もない。

この虚しさを経験したことがある人には、この記事は刺さるはずだ。「うちはまだそこまで整備できていない」では済まない時代になっている。CIO同士が共通言語でITの全体像を語り合える組織と、語れない組織の差は、経営判断の質に直結する。

設計者として機能するIT部門は、経営層が意思決定に使えるロードマップを持ち、投資の優先順位を自ら提言できる。「このシステムを廃止して、この領域に投資すべきだ」と根拠をもって語れる。これが「出せるものがある状態」だ。EAとは、この状態を作る仕事だ。そしてそれは、管理者ではなく設計者にしかできない仕事だ。

2. そもそもEAとは何か――そしてなぜ問題の答えになるのか

EAを一言で表すなら、組織全体の都市計画を描き、それを実行することだ。設計書を作るだけでも、TOGAFを導入するだけでもない。計画を描き、実行の定義を作り、データに落とし込み、推進する。この繰り返しがEAの仕事だ。

その核心となる3つのアウトプットが As-Is・To-Be・Transition だ。今の街がどういう状態か（As-Is）、10年後にどんな街を目指すか（To-Be）、そのために何をいつ建て替えるか（Transition）——EAがやっていることは、企業規模でこれをやっているだけだ。

この3つを描く前に欠かせない問いがある。「自社のエンタープライズとは何か」だ。グループ会社全体なのか、国内事業会社のみなのか——この範囲定義が曖昧なまま議論を始めると、As-Isの対象も、To-Beの範囲も、Transitionの責任範囲も、すべてが人によって変わる。エンタープライズの定義なくして、EAは始まらない。

EAはこの記事で論じる問題群に対する組織的な解だ。SaaSの乱立、レガシー化、DXの形骸化——これらはすべて「全体を設計する機能」が組織に存在しないことから生じる。EAはその機能を組織に埋め込む仕組みだ。以降のセクションはその論証だ。

3. なぜ「管理」では足りないのか――複雑性の爆発と問題の構造

管理者には根本的にできないことがある。全体を設計することだ。

複雑性の拡大を示すデータがある。世界のSaaS支出は2025年に約3,000億ドル規模に達する見込みであり［1］、日本国内でも80%以上の企業でSaaS利用数が増加傾向にある［2］。日本の大手企業では1社あたり平均207サービスのクラウドサービスを利用しており、65.6%がシャドーIT対策を実施していない実態がある［3］。Gartnerは「2027年までに、従業員の75%がIT部門の監督なしにテクノロジーを取得・改変・作成するようになる」と予測する［4］。この複雑性は今後も加速する一方だ。

これだけのサービスが乱立する中で、個別管理だけで整合性を保つことは不可能だ。あるプロジェクトが前提としているデータが、別のプロジェクトでは別の定義になっている。新しいSaaSを入れたのに古いシステムが残り、同じ機能が複数存在する。商店街をなくしてイオンを作るはずだったのに、気づけばイオンも商店街も両方残っている——誰も全体を設計していないと、こういうことが起きる。

その乱立が積み重なった先に待つのがレガシー化だ。経済産業省は2018年のDXレポートで「既存システムのブラックボックス状態を解消できない場合、2025年以降、最大12兆円／年の経済損失が生じる」と警告した［5］。2025年5月公表の「レガシーシステムモダン化委員会総括レポート」でも、ユーザー企業の約61%でレガシーシステムが依然残存している実態が明らかになっている［6］。SaaSが増え、レガシーが残り、全体設計がない——この三重苦がDXの失敗を生む。

その結果がDXの失敗率だ。投資は増えている。しかし全体設計が追いついていない組織では、投資が成果に結びつかない。Gartnerの2025年CIO調査（3,186名対象）では、デジタル施策の目標を達成・超過できていると答えた企業は48%にとどまる［7］。McKinseyも「デジタルトランスフォーメーション施策の70%が当初目標を達成できずに失敗する」と指摘する［8］。

管理者は個別の案件に答える。設計者は全体の方向性を定め、個別の案件をその文脈に位置づける。この違いが、複雑性が爆発した今の組織ITに決定的な差を生む。

4. EAに取り組んでも機能しない2つの理由

「設計が必要だ」とわかり、EAに取り組んでも機能しないケースが多い。理由は2つあり、根が異なる。

第一の理由：As-Is・To-Be・Transitionが揃わない。

予算構造がTo-BeとTransitionを封じている。日本企業のIT関連予算の約80%が現行ビジネスの維持・運営に割り当てられており、そのうち90%以上を維持運用に費やす企業も40%を超える［5］。攻めの投資に回せる予算がなければ、To-BeもTransitionも描けない。維持管理に追われる構造が、設計者への転換を阻んでいる。

As-Isも「データ」として存在しない。経営層との情報共有がない企業の66%がIT資産の可視化すらできていない実態がある［6］。技術体系・業務体系が整備されていない、ITアセット台帳がない、横断的に把握する組織がない——この3つが重なり、As-Isは永遠に「誰かの頭の中」にとどまる。

予算がなくAs-Isも存在しない状態では、当然Transitionも描けない。その結果をIPAの「DX推進指標自己診断結果分析レポート（2024年版）」が端的に示している。DX成熟度レベル4以上に達している企業はわずか1%にとどまる［9］。Transitionどころか、To-Beすら描けていない組織が大半だということだ。

第二の理由：揃ったとしても形骸化する。

現場でよく見る光景がある。3年前に作ったEAのロードマップが、誰も開かないフォルダに眠っている。なぜこうなるのか。構造的な理由が3つある。更新される仕組みがない——作った時点で止まり、環境変化が反映されない。参照するタイミングが設計されていない——年間計画や予算策定の場でEAを使う慣習がなければ、存在自体が忘れられる。オーナーシップが曖昧だ——「誰が責任を持って維持するか」が決まっていないEAは、気づけば誰のものでもなくなる。

自分が関わってきた現場でも、この壁に何度もぶつかった。資料は作れる。しかし「使われ続ける仕組み」を作ることの方が、はるかに難しい。IPA「DX白書2023」によれば、日本企業でDXに取り組んでいる割合は69.3%まで増加したにもかかわらず、「全社戦略に基づき全社的に取り組んでいる」企業は日米で13.9ポイントの開きがある［10］。取り組んではいるが、全体設計が伴っていない。作ることと使うことは別の問題だ。

機能するEAの条件はシンプルだ。年間計画・長期計画を見直すタイミングで、全員が参照できる全体設計が存在しているかどうか。縦の整合性（経営戦略とITの方向性が一致しているか）と横の整合性（同時並行で走るプロジェクト同士が矛盾していないか）——この両方を保てているEAだけが、機能していると言える。EAは作るだけでは意味がない。使われ続ける仕組みにして初めて価値が出る。

5. 管理から設計へ――2つの障壁

「管理から設計へ」という転換には、現実として2つの障壁がある。

障壁①：人員・予算の壁。設計者として機能するためには、個別案件の対応に追われる日常業務から時間と人員を切り出す必要がある。IT予算の約80%が維持運用に消える構造の中では、その余白はほぼない。「EA推進をやりたいが、人が足りない」——この声を何度聞いたかわからない。構造的な問題だ。

障壁②：組織文化の壁。「ITは言われたことをやる部門」という認識が根付いている組織では、設計者として振る舞おうとするIT部門は「出しゃばり」と受け取られるリスクがある。IPA「DX動向2024」では、IT分野に見識のある役員が3割以上いる企業の割合が、米国65.4%に対して日本はわずか16.9%と報告されている［11］。経営層のIT理解が薄い組織では、EAの価値そのものが伝わらない。自分が「これをやるべきだ」と確信していても、伝わらなければ動かない。これが最も消耗する壁だ。

この2つの壁は、別々に対処するより、連動して崩していく方が現実的だ。

6. 2つの突破口――トップダウンを引き出し、小さく始める

突破口①：トップダウンを引き出す。

経営層が「やれ」と言わない限り、組織は動かない。Gartnerの調査では、CIOとCxOが共同オーナーシップを持つ企業でのデジタル施策達成率は63%に達する一方、CIOが単独でIT部門を抱える企業では43%にとどまる［12］。経営層を巻き込めるかどうかが、EAの成否を左右する。

有効なのが情報セキュリティの文脈だ。「全社のITが把握できていないと、情報セキュリティ上のリスクがある」——この論理は経営層に刺さりやすい。セキュリティ対応としてITアセット台帳の整備を位置づけ、承認を引き出す。自分の経験では、セキュリティという切り口を使った瞬間に、経営層の表情が変わった。「管理のため」では動かなかった人が、「リスク対応」の文脈では動く。これが現実だ。

経営層が動けば、業務部門との「提案がなかったからだ」「業務が決まらないとシステムは決まらない」という責任の押し付け合いも解消に向かう。トップダウンがあって初めて、To-Beを互いに設計し合う場を作れる。ファシリテートできるようになる。これが設計者としてのIT部門の役割だ。

突破口②：小さく始め、トップダウンを引き出すきっかけを作る。

トップダウンを待ちながら、同時に小さく始めることも進める。まずExcelで1枚書く。システム名、対応する業務、担当オーナー、廃止・更改の予定年——この粒度で構わない。APQCやTOGAFといったグローバルスタンダードをベースに業務体系・技術体系のたたき台を作り、そこにシステムを紐づけていく。セキュリティ対応で得たITアセットのデータは、そのままAs-Is基盤として育てていく。セキュリティ台帳で終わらせない。最初からその意図を持っておくことが重要だ。

この1枚が経営層の目に触れたとき、「うちにもこういうものが必要だ」という問題意識を引き出すきっかけになる。小さく始めることは、トップダウンを待つ受け身の姿勢ではなく、トップダウンを引き出すための能動的な一手だ。2つの突破口は連動している。小さく始めることがトップダウンを生み、トップダウンがさらに本格的な動きを生む。この往復運動がEA推進の実態だ。