システム戦略・2/7・8分

エンタープライズアーキテクチャと業務モデル

ゴール

エンタープライズアーキテクチャ（EA）の4階層を説明文から見分けられるようになる。To-Be（あるべき姿）と業務モデルの定義・目的を問う問題を、後工程の作業とひっかけられても正しく選べるようになる。

EAの4階層は本試験と免除試験の両方で繰り返し出る定番です。名前と説明の組み合わせを覚えれば確実に1問取れます。要件定義で業務フロー・データ定義・機能一覧・インフラ構成を分けて書くのと同じ考え方なので、実務の感覚で覚えられます。

結論：EAは会社全体を4枚の設計図に分ける手法

EA（エンタープライズアーキテクチャ）は、会社の業務と情報システムを4つの階層に分けて整理し、全体最適の観点から見直す手法です。全体最適とは、部署ごとにバラバラに良くするのではなく、会社全体として無駄や重複のない状態を目指すことです。

家を建てるときに、間取り図・配線図・配管図・構造図を別々に描くのと同じイメージです。1枚に全部描くと誰も読めないので、見る人の関心ごとに図を分けます。

4つは上から ビジネス → データ → アプリケーション → テクノロジ の順です。頭文字をつなげて「ビ・デ・ア・テ」と覚えましょう。

部署ごとに同じデータを持つと重複が生まれる。全体最適では会社全体で1か所にまとめる。

最重要：4階層の比較表

階層	何を体系化したものか	選択肢に出るキーワード	要件定義でいうと
ビジネスアーキテクチャ	ビジネス戦略に必要な業務プロセスや情報の流れ	業務プロセス、情報の流れ、ビジネス戦略	業務フロー図
データアーキテクチャ	業務に必要なデータの内容、データ間の関連や構造	データの内容、関連、構造	E-R図・データ項目の定義
アプリケーションアーキテクチャ	業務プロセスを支援するシステムの機能や構成	システムの機能、構成	機能一覧・どのサービスやAPIが何を担うか
テクノロジアーキテクチャ	情報システムの構築・運用に必要な技術的構成要素	ハードウェア、ソフトウェア、ネットワーク、技術的構成要素	インフラ構成図

flowchart TB
  B["ビジネス：業務プロセスと情報の流れ"] --> D["データ：データの内容・関連・構造"]
  D --> A["アプリケーション：システムの機能・構成"]
  A --> T["テクノロジ：ハード・ソフト・ネットワーク"]

上の階層ほど「業務の言葉」、下の階層ほど「技術の言葉」で書かれます。

見分け方：説明文の「主語」を見る

説明文の**最後の名詞（何を体系化したか）**で判断します。「業務プロセスや情報の流れ」ならビジネス、「データの内容や関連」ならデータ、「システムの機能や構成」ならアプリケーション、「技術的構成要素」ならテクノロジです。

注意：アプリケーションの説明にも「業務プロセスを支援する」と業務プロセスという言葉が入ります。ただし体系化している対象は「システムの機能や構成」なので、ビジネスではなくアプリケーションです。

「4つの分類体系に含まれるものはどれか」と聞かれたら、システム／ソフトウェア／バスアーキテクチャはEAの分類にはありません。それらしい名前で迷わせているだけです。

「業務プロセスを支援する」は飾りの言葉。体系化している対象（最後の名詞）が「システムの機能や構成」なのでアプリケーション。

EAそのものの説明問題：似た技法と区別する

「EAを説明したものはどれか」では、他のモデリング技法の説明が選択肢に並びます。

技法	何をするものか	見分けるキーワード
EA	業務と情報システムを4体系で分析し、全体最適化の観点から見直す	ビジネス・データ・アプリケーション・テクノロジ、全体最適化
UML	オブジェクト指向設計の図法を統一・標準化したもの	クラス図、オブジェクト指向
E-R図	概念データモデルをエンティティとリレーションシップで表す	エンティティ、リレーションシップ
DFD	業務プロセスをデータの流れで表す	データフロー・プロセス・ファイル・データ源泉／吸収

**DFDも「4つの基本要素」**なので、「四つ」という数字だけで選ぶと間違えます。中身が4階層の名前かどうかで判断しましょう。

As-Is と To-Be：現状と理想を分けて描く

EAでは、まず現状（As-Is）を描き、次に理想（To-Be）を描きます。その差を埋める移行計画を立てるのが基本の流れです。前のレッスンの業務改善でいえば、「今の業務フロー」と「改善後の業務フロー」を別々に描くのと同じです。

用語	意味
To-Beモデル	業務と情報システムの理想（あるべき姿）
As-Isモデル	業務と情報システムの現状
EA参照モデル	EAを作るときに参考にする分類の枠組み・ひな形
ザックマンフレームワーク	EAを「誰の視点 × 何を」の表で整理するフレームワーク（EAの元祖）

「理想」「あるべき姿」と書かれていれば To-Be を選びます。

現状（As-Is）と理想（To-Be）を別々に描き、その差を埋める移行計画を立てる。

論理モデルと物理モデル

業務の論理モデルは、経営目標の達成に必要な業務機能を定義し、体系化したあるべき姿のモデルです。誰がどの帳票を使うかといった今の実際のやり方（物理的な実装）からは切り離して書きます。

選択肢の書き方	正体
経営目標の達成に必要な業務機能を定義・体系化	論理モデル（あるべき姿） ← 正解
現状の業務機能を分析・体系化	現状分析（As-Is）
現状の業務と情報システムの関係を明確化	現状分析（As-Is）
あるべき姿と現状を比較・評価	差の分析（ギャップ分析）

「現状」という言葉が入っていたら、あるべき姿の選択肢ではありません。

業務モデル：全体計画で作る「業務×情報」の地図

業務モデルは、企業の主要な活動分野ごとに、本来あるべき業務機能を明確にしたものです。全体最適化計画（会社全体の情報化計画）の段階で作ります。目的は、全体業務と使われる情報の関連を整理し、情報システムのあるべき姿を明確にすることです。

表現方法は、ビジネスプロセスとデータクラスを関連付けるマトリクスです。データクラスとは、業務で使う情報を「顧客」「受注」「製品」のように同じ種類ごとにまとめたものです。縦に業務、横に情報の種類を並べ、「どの業務がどの情報を作る・使うか」に印を付けた表をイメージしてください。

全社レベルで作るときの留意点：

ビジネスプロセスには日常業務だけでなく、意思決定活動や戦略計画活動も含める
現行のプロセスをそのまま写さない（あるべき姿を描く）
データクラス間の重複はそのまま残さず、整理する
全社レベルなので、データ項目までは細かくしない（粒度は粗くてよい）

業務モデルは、縦に業務（ビジネスプロセス）、横に情報の種類（データクラス）を並べ、どの業務がどの情報を作る・使うかに印を付けた表。

業務モデルは「最初の工程」：後工程の作業と混同しない

工程	主な作業
全体最適化計画	業務モデルを定義（業務と情報の関連、システムのあるべき姿）
個別のシステム化計画	システム化の範囲・開発規模・期間・工数・費用の見積り
設計	ハードウェア・ソフトウェア・ネットワークなど構成要素の洗い出し
運用準備	利用者マニュアル・運用マニュアルのために業務手順を確認

「業務モデルを定義する目的」を問われたら、見積り・構成要素・マニュアルは全部後工程の話です。「全体業務と情報の関連を整理し、あるべき姿を明確化する」選択肢を選びます。

要点（試験直前に読む）

EAの4階層は「ビ・デ・ア・テ」：ビジネス（業務プロセス・情報の流れ）／データ（データの内容・関連・構造）／アプリケーション（システムの機能・構成）／テクノロジ（技術的構成要素）
EAは4体系で業務と情報システムを分析し、全体最適化の観点から見直す手法。システム・ソフトウェア・バスアーキテクチャは4分類に入らない
To-Be＝理想（あるべき姿）、As-Is＝現状。論理モデルは経営目標の達成に必要な業務機能を定義した、あるべき姿のモデル
業務モデルは全体最適化計画で作る。目的は全体業務と情報の関連を整理し、情報システムのあるべき姿を明確にすること
業務モデルはビジネスプロセスとデータクラスを関連付けて表す。プロセスには意思決定・戦略計画活動も含める

ひっかけ

アプリケーションアーキテクチャの説明にも「業務プロセス」が入る。何を体系化しているか（システムの機能・構成か、業務そのものか）で判断する
「四つの要素」を持つDFDの説明がEAの選択肢に混ざる。4つの中身がビジネス・データ・アプリケーション・テクノロジかどうかで判断する
「現状の業務機能を分析」「現状と比較・評価」は、あるべき姿（To-Be・論理モデル）ではない。「現状」の文字があれば外す
業務モデルの目的として、見積り・HW/SW構成要素の洗い出し・マニュアル作成が並ぶ。どれも後工程の作業なので選ばない
全社業務モデルの留意点で「現行プロセスをそのまま反映」「データ重複もそのまま」「データ項目を詳細に」はすべて誤り。正しいのは「意思決定・戦略計画活動も含める」

用語（15）

エンタープライズアーキテクチャ EA：Enterprise Architecture
業務と情報システムをビジネス・データ・アプリケーション・テクノロジの4体系で整理し、全体最適化の観点から見直す手法。
⚠ UML・E-R図・DFDと混同しやすい。「4体系」と「全体最適化」が出てきたらEA。

ビジネスアーキテクチャ びじねすあーきてくちゃ
ビジネス戦略に必要な業務プロセスや情報の流れを体系化したもの。
⚠ アプリケーションアーキテクチャの説明にも「業務プロセス」が出てくる。体系化する対象が業務そのものならビジネス。

データアーキテクチャ でーたあーきてくちゃ
業務に必要なデータの内容、データ間の関連や構造を体系化したもの。
⚠ 「4つの分類体系」の空欄はこれ。システムアーキテクチャやソフトウェアアーキテクチャはEAの分類に無い。

アプリケーションアーキテクチャ あぷりけーしょんあーきてくちゃ
業務プロセスを支援する情報システムの機能や構成を体系化したもの。
⚠ ビジネスアーキテクチャと混同しやすい。体系化する対象が「システムの機能・構成」ならアプリケーション。

テクノロジアーキテクチャ てくのろじあーきてくちゃ
情報システムの構築・運用に必要なハードウェア・ソフトウェア・ネットワークなど、技術的な構成要素を体系化したもの。
⚠ アプリケーションアーキテクチャと混同しやすい。「技術的構成要素」はテクノロジ、「システムの機能」はアプリケーション。

全体最適化 ぜんたいさいてきか
部署ごとの部分最適ではなく、会社全体として重複や無駄のない業務とシステムを目指すこと。
⚠ 部分最適（部署単位でだけ良くすること）の反対。

To-Beモデル とぅーびーもでる
業務と情報システムの理想、つまりあるべき姿を表すモデル。
⚠ As-Isモデルは現状を表す。「理想・あるべき姿」ならTo-Be。

As-Isモデル あずいずもでる
業務と情報システムの現状の姿を表すモデル。
⚠ To-Beモデルは理想を表す。「現状」ならAs-Is。

EA参照モデル いーえーさんしょうもでる
EAを作るときに参考にする、分類の枠組みや標準のひな形。
⚠ 理想の姿そのものを表すモデルではない（それはTo-Be）。

ザックマンフレームワーク Zachman Framework
EAを「誰の視点か」と「何を描くか」の表で整理する、EAの元祖といえるフレームワーク。
⚠ To-Beのような理想像のモデルではなく、整理するための枠組み。

業務の論理モデル ぎょうむのろんりもでる
経営目標の達成に必要な業務機能を定義・体系化した、あるべき姿のモデル。
⚠ 物理モデルや現状分析は「現状の業務機能」を分析したもの。「現状」とあれば論理モデルではない。

業務モデル ぎょうむもでる
企業の主要な活動分野ごとに本来あるべき業務機能を明確にし、全体業務と情報の関連を整理したもの。
⚠ システムの機能を表す論理モデルや、システムを決めた後に業務を当てはめたものではない。業務が先、システムは後。

ビジネスプロセス びじねすぷろせす
企業が目的を達成するための一連の業務活動。日常業務に加えて、意思決定や戦略計画の活動も含む。
⚠ 全社業務モデルでは日常業務だけに絞らない点がひっかけになる。

データクラス でーたくらす
業務で使う情報を「顧客」「受注」「製品」のように同じ種類ごとにまとめたもの。
⚠ データ項目（個々の列）ほど細かくない。全社業務モデルではデータ項目まで詳細化しない。

DFD Data Flow Diagram
業務やシステムを、データフロー・プロセス・ファイル・データ源泉／吸収の4要素で表す図。
⚠ EAと同じく「4つ」なので混同しやすい。中身がデータの流れの要素ならDFD。

このレッスンの過去問

このレッスンで稽古する

← 業務プロセスの見直しと改善の進め方

IT投資の管理と業績評価（BSC） →