変更要約: 初版
4.2エンタープライズアーキテクチャ（EA）
全体最適化を実現する代表的手段であるEA（エンタープライズアーキテクチャ）を、ビジネス（BA）／データ（DA）／アプリケーション（AA）／テクノロジ（TA）の4体系として理解し、現状のAs-Isから目標のTo-Beを描き移行計画でつなぐ手順、参照モデルの役割、そして「ある課題がどの体系（層）の問題か」を切り分ける判断を学びます。
前節の全体最適化方針を、実際の設計図として体系化する代表的な手法がEA（エンタープライズアーキテクチャ）です。EA は企業の業務とシステムをビジネス・データ・アプリケーション・テクノロジという4つの体系（層）に分けて可視化し、現状（As-Is）と目標（To-Be）の差を明らかにして、移行計画でつなぎます。ITストラテジストにとって EA の実務的な勘所は、「今直面している課題が4体系のどの層の問題なのか」を正しく切り分けることと、「To-Be を一気に実現するのではなく、移行計画として段階的にどう到達するか」を設計することです。この節では、4体系の役割分担と As-Is/To-Be/移行の関係を、全体最適を主導するストラテジストの判断として学びます。
4.2.1EAの4体系（BA/DA/AA/TA）
- ビジネスアーキテクチャ（BA）＝業務・組織・機能・業務プロセスの体系。「何の業務を、どんな流れで行うか」を表す。業務プロセスそのものの非効率や重複はこの層の課題。
- データアーキテクチャ（DA）＝業務が扱うデータの構造・体系・相互関係。データの重複・不整合、マスタが部門ごとに分かれている、といった問題はこの層の課題。
- アプリケーションアーキテクチャ（AA）＝業務を支援する個々のアプリケーション（システム機能）とその連携。同じ機能のシステムが乱立している、システム間連携が困難、といった問題はこの層。
- テクノロジアーキテクチャ（TA）＝アプリケーションを稼働させる技術基盤（ハードウェア・ネットワーク・OS・ミドルウェア・クラウド基盤等）。老朽インフラ、性能・可用性の基盤的制約はこの層の課題。
4.2.2As-Is・To-Be・移行計画と参照モデル
- As-Is（現状）とTo-Be（あるべき目標像）を各体系で描き、両者の差（ギャップ）を分析する。ギャップをどの順で埋めるかを示すのが移行計画で、To-Be を一足飛びに実現せず、リスク・投資・業務影響を踏まえ段階的に到達する道筋を設計する。
- 参照モデル＝各体系の設計を標準化・再利用するためのひな型（ビジネス参照モデル・データ参照モデル・サービスコンポーネント参照モデル・技術参照モデル等）。ゼロから設計せず参照モデルを土台にすることで、全社での一貫性と設計効率を高める。
「EAはBA/DA/AA/TAの4体系」「As-Is→To-Be→移行計画で全体最適へ段階的に到達」「課題がどの体系（層）の問題かを切り分ける」が最頻出です。4体系の対応（業務＝BA／データ＝DA／アプリ＝AA／技術基盤＝TA）を取り違えないこと、そして「To-Be を移行計画なしで一気に実現する」という記述は誤りである点に注意しましょう。
あるITストラテジストが、EA の観点で複数の課題を層ごとに切り分けています。現場から挙がっているのは、（ア）受注業務で同じ入力を営業部門と出荷部門が別々に二度行っている、（イ）顧客データが販売系・保守系・会計系の3システムで別々に持たれ、住所変更が全システムに反映されず不整合が起きている、（ウ）機能のよく似た受注システムが事業部ごとに3つ乱立し、連携のたびに個別のインタフェース開発が必要になっている、（エ）基幹サーバが老朽化し、繁忙期にレスポンスが基盤性能の限界で悪化する、という4つです。ストラテジストは、これらを闇雲に「システムの入れ替え」で解こうとせず、まずどの体系の課題かを切り分けます。（ア）は業務プロセスの重複そのものなのでビジネスアーキテクチャ（BA）の課題であり、二重入力をなくす業務プロセス再設計が本筋です。（イ）はデータの構造・持ち方の問題なのでデータアーキテクチャ（DA）の課題で、顧客データの全社共通化・マスタ統合で解きます。（ウ）は同一機能アプリの乱立と連携困難なのでアプリケーションアーキテクチャ（AA）の課題で、受注機能の共通化・連携基盤の整理が方向性です。（エ）は技術基盤の性能限界なのでテクノロジアーキテクチャ（TA）の課題で、インフラ更改やクラウド移行で解きます。層の切り分けを誤ると、たとえばデータ不整合（DA の問題）を高性能サーバの導入（TA の施策）で解こうとして、投資しても不整合は解消しない、という的外れが起きます。次にストラテジストは、各層の As-Is と To-Be を描き、そのギャップを一度に埋めようとせず移行計画を設計します。たとえば「まず顧客マスタを DA として統合し（第1段）、次に各受注システムを共通基盤参照へ AA として再編し（第2段）、最後に老朽基盤を TA として更改する（第3段）」というように、投資・リスク・業務影響を踏まえた段階的な到達順序を決めます。To-Be を一足飛びに実現しようとすると、移行中の業務停止リスクと投資の一極集中を招くため、移行計画による段階化こそが EA の実務の要になります。
| 体系 | 対象 | 典型的な課題の例 |
|---|---|---|
| ビジネス（BA） | 業務・組織・業務プロセス | 業務の重複・二重入力 |
| データ（DA） | データの構造・体系・相互関係 | マスタ分散・データ不整合 |
| アプリケーション（AA） | 個々のアプリと連携 | 同一機能システムの乱立・連携困難 |
| テクノロジ（TA） | ハード・NW・OS・基盤 | 老朽インフラ・基盤性能の限界 |
ひっかけ： 「データの不整合（DA の課題）を高性能なサーバの導入（TA の施策）で解決する」のように、課題の属する体系と施策の体系がずれた対応は的外れです——どの層の問題かを正しく切り分けないと、投資しても本質は解消しません。また「To-Be を移行計画なしで一気に実現する」も誤り＝As-Is から To-Be へは、投資・リスク・業務影響を踏まえた移行計画で段階的に到達するのが EA の実務であり、一足飛びの実現は移行中の業務停止リスクと投資集中を招きます。
4.2.3この節のまとめ
- EAはBA／DA／AA／TAの4体系で業務とシステムを可視化する全体最適化の手段
- 課題がどの体系（層）の問題かを正しく切り分ける（データ不整合はDA、基盤性能はTA 等）
- As-Is→To-Be→移行計画で、投資・リスク・業務影響を踏まえ段階的に全体最適へ到達する
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 顧客データが販売系・保守系・会計系の3システムで別々に保持され、住所変更が全システムに反映されず不整合が生じている。EA の観点でこの課題が属する体系と、方向性として最も適切な組合せはどれか。
Q2. EA における As-Is・To-Be・移行計画の関係の説明として最も適切なものはどれか。