情報管理技術士 学習ノート
← 一覧へ
SW工学・管理
#Zachman#엔터프라이즈아키텍처#EA#분류체계#아키텍처프레임워크
最終更新 · 2026-10-04

ザックマンフレームワーク(Zachman Framework)

1. 概要

A. 定義

ザックマンフレームワーク(Zachman Framework)とは、エンタープライズ(企業・組織)を構成する成果物を、「何を・どのように・どこで・誰が・いつ・なぜ」という六つの問い(列)と、「計画者・所有者・設計者・構築者・実装者・利用者」という六つの利害関係者の視点(行)の交点として分類する二次元の分類体系(classification schema, ontology)である。すなわち「何を文書として残すべきか」を規定する正規化された地図であり、「どのように作るか」を規定する方法論ではない。

ザックマンフレームワークはしばしば「エンタープライズアーキテクチャ(EA)の周期表」にたとえられる。化学の周期表が元素の合成方法を教えないが、すべての元素が収まる場所を漏れなく・重複なく規定するように、ザックマンフレームワークも組織のアーキテクチャ成果物を生成する手順を提示しないが、どの成果物がどのセルに入るべきかを完結的に規定する。この点がTOGAFのADMのような方法論と決定的に区別される性格であり、ゆえに両者は競合関係ではなく分類体系(ザックマン)+開発手順(TOGAF)として相互補完される。

中核となる特徴は三つである。第一に、6×6=36個のセルが互いに独立し重複しない正規化(normalized)構造をなす。第二に、各セルは単一の変数のみを扱う原始モデル(primitive model)であり、二つ以上の変数を混ぜた成果物(複合モデル、composite)は当該セルではなくセルの組み合わせとして表現される。第三に、特定のツール・表記法・方法論に中立であり、いかなるモデリング言語(UML・ERD・BPMNなど)でもセルを満たすことができる。

ザックマンフレームワークを正しく理解するには、「フレームワークがアーキテクチャを作ってくれるわけではない」という点を明確にしなければならない。フレームワークはアーキテクチャ成果物が入る「空の分類箱」を提供するのみであり、各箱に何をどう描くかは組織が選択した方法論・表記法・ツールに委ねる。この中立性ゆえにザックマンは特定のベンダー・流行に縛られず三十余年の生命力を保ってきたと同時に、「では今すぐ何から始めればよいのか」という実務者の不満を買うこともある。この両面性は欠陥ではなく、分類体系という本来の正体の自然な帰結である。

B. 登場背景と必要性

ザックマンフレームワークは、1987年にジョン・ザックマン(John A. Zachman)がIBMシステムズジャーナルに発表した「A Framework for Information Systems Architecture」に由来する。当時、大型情報システムが急増する中で、同一の企業を対象としても企画部門・現業・設計者・開発者が互いに異なる言語と成果物でシステムを記述し、意思疎通が断絶する問題が深刻であった。ザックマンは、建築・航空機製造のような成熟した工学分野が数百年をかけて「同一対象を複数視点の図面で体系化」してきた方式を情報システムに移植しようとした。

第一の動因は視点間の意思疎通の断絶である。経営陣が言う「顧客」とDBAが言う「顧客テーブル」は抽象化水準が異なるのに、一つの文書に混在すると、異なる人が異なるものを想像することになる。フレームワークは行(視点)を分離することで、「今われわれはどの抽象化水準を話しているのか」を明示させる。

第二の動因は成果物の欠落・重複の統制である。アーキテクチャ文書が数百種に及ぶと、「何が抜けており何が重なっているか」を判断する基準がない。36個のセルという固定された座標系はチェックリストの役割を果たし、たとえば「Why列(動機・規則)の業務モデルセルが空いている→業務規則が設計に反映されていない恐れ」を早期に露呈させる。

第三の動因は追跡性(traceability)と変化影響分析である。上位行(範囲・業務)の要求が下位行(技術・実装)の成果物へどのように下りてくるかを座標で結べば、特定の業務規則が変わったときに影響を受けるデータ・機能・システムを列と行に沿って追跡できる。韓国も「電子政府法」に基づく情報技術アーキテクチャ(ITA/EA)導入の過程で、ザックマンの分類思想を成果物メタモデルの基礎として広く参照した。

第四の動因は工学としての成熟である。ザックマンは、情報システム構築が依然として職人の経験に依存する未成熟段階にとどまっているとみて、建築・製造が「同一対象を複数の公式図面で体系化」することで再現可能かつ統制可能な工学へ発展したことを指摘した。フレームワークはその成熟の前提条件、すなわち「何をどの視点で記述すべきか」の標準座標を提供する。この志向は今日でも有効であり、デジタル変革で組織とシステムが複雑になるほど、暗黙知に依存したアーキテクチャは統制不能に陥り、明示的な分類体系の必要性はむしろ大きくなる。

2. フレームワークの構造 — 二つの軸と36個のセル

ザックマンフレームワークの本質は、「一つのエンタープライズを二つの独立した軸で完全分解する」という点にある。横軸(列)は抽象化の種類を、縦軸(行)は具体化(実体化)の程度を表す。二つの軸は互いに直交(orthogonal)するため、いかなるアーキテクチャ成果物も「どの問いに答えるか(列)×誰の視点か(行)」という単一の座標で分類される。この直交性が重複と欠落を根本的に防ぐ仕掛けである。

graph TD
    Z["ザックマンフレームワーク<br/>(6 x 6 分類マトリクス)"]
    Z --> COL["横軸: 六つの問い(抽象化の種類)"]
    Z --> ROW["縦軸: 利害関係者の視点(具体化の程度)"]
    COL --> C1["What データ(何を)"]
    COL --> C2["How 機能(どのように)"]
    COL --> C3["Where ネットワーク(どこで)"]
    COL --> C4["Who 組織・人(誰が)"]
    COL --> C5["When 時間・日程(いつ)"]
    COL --> C6["Why 動機・規則(なぜ)"]
    ROW --> R1["範囲(計画者・Executive)"]
    ROW --> R2["業務モデル(所有者・Business)"]
    ROW --> R3["システムモデル(設計者・Architect)"]
    ROW --> R4["技術モデル(構築者・Engineer)"]
    ROW --> R5["詳細表現(実装者・Technician)"]
    ROW --> R6["稼働エンタープライズ(利用者・Enterprise)"]

A. 六つの列 — 六つの根本的な問い

列は、人間が何らかの対象を説明するときに発する六つの原初的な問い(5W1H)に対応する。What(データ)は組織が扱う事物・概念、すなわちエンティティとその関係を扱う。How(機能)は組織が遂行するプロセス・機能の変換論理を扱う。Where(ネットワーク)は業務が遂行される場所と、それをつなぐ通信・物流構造を扱う。Who(組織)は業務を遂行する人・役割・責任と権限体系を扱う。When(時間)は事象の順序・周期・日程など時間的制約を扱う。Why(動機)は、それらすべてが存在する理由、すなわち戦略・目標・業務規則を扱う。

重要な規則は、列の間に順序がない(no inherent order)という点である。WhatがHowより先でなければならない理由はなく、六つの問いは対等な分解軸である。また各列はその列だけの単純で固有な基本モデルを持つ。たとえばWhat列の基本モデルは「エンティティ–関係」構造であり、Who列の基本モデルは「役割–責任」構造として、互いに還元されない。実務ではしばしばデータ(What)と機能(How)のみを詳細に描き、Who・When・Whyを空けておくが、これは組織・規則・時点に対する設計の空白を意味するため、フレームワークはその空欄を可視化して補完を促す。

六つの列がなぜ「完全な分解」なのかは、それ以上の根本的な問いが存在しないという点から来る。たとえばある銀行の与信業務を記述するなら、Whatは「貸付・担保・顧客」のようなエンティティを、Howは「与信審査・実行・回収」プロセスを、Whereは「本店・支店・審査センター」の処理場所を、Whoは「審査役・支店長・与信委員会」の権限を、Whenは「申請→審査→承認→実行」の時点と満期周期を、Whyは「BIS比率規制・内部与信限度規則」をそれぞれ担う。この六つをすべて答えれば与信業務が漏れなく記述され、一つでも空ければその分だけ説明が不完全になる。このように列は「説明のMECE(相互排他・全体網羅)軸」の役割を果たす。

B. 六つの行 — 六つの利害関係者の視点

行は、同一のエンタープライズを眺める異なる利害関係者の視点であり、上から下へ行くほど抽象から具体へと実体化される。第1行 範囲(Scope、計画者視点)は、経営陣が見る事業範囲・中核リスト水準の輪郭である。第2行 業務モデル(Business Model、所有者視点)は、現業が理解する概念水準の業務構造である。第3行 システムモデル(System Model、設計者視点)は、実装技術に独立した論理設計である。第4行 技術モデル(Technology Model、構築者視点)は、特定の製品・プラットフォームに従属した物理設計である。第5行 詳細表現(Detailed Representation、実装者視点)は、プログラム・DDLのような構成単位ごとの詳細仕様である。第6行 稼働エンタープライズ(Functioning Enterprise、利用者視点)は、実際に稼働中の組織・システムそのものである。

核心となる点は、各行が独立した一つの完結した視点であるということである。設計者視点(第3行)は所有者視点(第2行)を単に詳細化したものではなく、所有者の要求を設計者の言語へ「変換(transformation)」した結果である。したがって一つの行のセル六つを横に集めればその視点から見た組織の完全なモデルとなり、一つの列のセル六つを縦に集めれば一つの問い(例:データ)が抽象から具体へ精緻化される全過程となる。下の例は、What(データ)列が六つの行に沿ってどのように実体化されるかを示す。

具体的に、ある公共の民願ポータルを六つの行に下ろしてみると次のようになる。範囲(第1行)では「オンライン民願受付・処理」という事業の輪郭と対象民願のリストが定義され、業務モデル(第2行)では「受付→担当割当→処理→通知」という概念業務フローと民願・担当者の概念が描かれる。システムモデル(第3行)ではこれをユースケース・論理データモデル・サービスインターフェースとして設計し、技術モデル(第4行)では特定のWAS・DBMS・APIゲートウェイ製品に合わせた物理構造へ具体化する。詳細表現(第5行)は画面・プログラム・DDLのような構成単位の成果物であり、稼働エンタープライズ(第6行)は実際に稼働中の民願ポータルそのものである。同じ「民願」という対象が行を下りるにつれ、まったく異なる言語で表現されるという点がこの例で明確に表れる。

行が「詳細化」ではなく「変換」であるという点は、実務でしばしば看過され混乱を生む。詳細化であれば上位の成果物に項目を付け加えるだけでよいが、変換であれば視点が変わるとき責任主体と表現言語がまるごと変わる。たとえば所有者(第2行)が「顧客に月1回請求書を送る」という業務規則を記述すると、設計者(第3行)はこれを「請求バッチ処理+請求エンティティ+送付イベント」という論理構成へ変換し、構築者(第4行)はさらに特定のバッチスケジューラとメッセージキュー製品へ変換する。各段階で情報が加わり仮定が具体化されるため、上位・下位の行の間には必ず「要求が正しく変換されたか」を検証する追跡性リンクが必要である。このリンクが切れると、上位で合意した規則が下位の実装で音もなく消える典型的な失敗が発生する。

graph LR
    D1["範囲: 中核業務データの一覧(エンティティ候補)"] --> D2["業務モデル: 概念データモデル(主題領域ERD)"]
    D2 --> D3["システムモデル: 論理データモデル(正規化されたERD)"]
    D3 --> D4["技術モデル: 物理データモデル(DBMS従属の設計)"]
    D4 --> D5["詳細表現: テーブルDDL・インデックススクリプト"]
    D5 --> D6["稼働エンタープライズ: 実際の稼働データベースインスタンス"]

3. セルの性格とフレームワークの規則

A. フレームワークの基本規則

ザックマンが提示した規則は、フレームワークが任意の表ではなく論理的に閉じた分類体系であることを保証する。中核となる規則を整理すると次のとおりである。

  • 列には順序がない: 六つの問いは対等であり、先後・優劣がない。特定の列を先に描かねばならないという強制は存在しない。
  • 各列は単純で固有な基本モデルを持つ: Whatはエンティティ–関係、Whoは役割–責任のように、列ごとに還元不可能な固有モデルがある。
  • 各行は区別される一つの完結した視点である: 上位行の詳細化ではなく視点を変換した結果である。
  • 各セルは固有である: 36個のセルは意味が重ならず、同一座標に二つ以上の相反する成果物があればガバナンスの問題である。
  • 一つの行のセルの組み合わせはその視点の完全なモデルである: 横の結合が当該利害関係者の統合ビューをなす。
  • メタ概念をセルに入れない: フレームワークを説明する概念はセルの内容になり得ない(正規化の維持)。

B. 原始モデルと複合モデル

フレームワークが単なる6×6の表ではなく「存在論(ontology)」と呼ばれる理由は、厳格な規則にある。

複合成果物をセルの組み合わせとして解釈する訓練は、実務文書の性格を正確に把握させてくれる。たとえばデータフロー図(DFD)はデータ(What)と処理(How)の結合、ユースケース仕様は機能(How)・行為者(Who)・事象順序(When)の結合、業務継続計画は場所(Where)・時間(When)・動機(Why)の結合として分解される。このように分解してみると「この文書がどの問いに答えており、どの問いを落としているか」が露わになるため、フレームワークは成果物の完全性を逆に点検するレンズとしても使える。

原始モデルと複合モデルの区別は再利用の観点からも重要である。原始モデル(単一セル)は変数が一つだけであるため別の文脈にそのまま再利用できるが、複合モデル(複数セルの結合)は特定の結合方式に従属し再利用性が劣る。したがってフレームワークは「可能なら原始モデルへ正規化して蓄積し、複合成果物はその組み合わせで派生せよ」という設計哲学を含意する。これはデータ正規化で異常現象(anomaly)を減らすために重複を除去する考えと同型(同型)であり、アーキテクチャ成果物にも正規化概念を適用したのがザックマンの独創的寄与である。ただし現実にはすべての成果物を原始モデルで維持することは難しく、複合成果物が意思疎通により効率的なことが多いため、「蓄積は正規化・意思疎通は複合」という役割分担で運用するのが現実的である。

この規則がもたらす実務的効用は「成果物の位置判定」である。新しい文書が作られたとき「これは何の問いに答え、誰の視点か」を問えば座標が定まり、同じ座標にすでに別の文書があれば重複またはバージョン衝突を疑える。たとえば金融の次世代プロジェクトで「勘定系データ標準書」と「商品データ辞書」がともに(What、第3行システムモデル)に分類され、二つの組織が相反する論理モデルを運用していることを発見した事例のように、フレームワークはガバナンスの衝突検知座標系として機能する。

区分 列(What ~ Why) 行(範囲 ~ 稼働エンタープライズ)
意味 抽象化の種類(問い) 具体化(実体化)の程度
順序 順序なし(対等) 上→下へ実体化
横の結合 — 一つの視点の完全なモデル
縦の結合 一つの問いの精緻化過程 —
代表的成果物の例 データモデル・プロセスマップ・組織図・日程表・規則集 ビジョン→概念モデル→論理設計→物理設計→コード→稼働

4. 比較と適用事例 — TOGAF・政府EAとの関係

ザックマンフレームワークをTOGAFと対立構図で理解するのはよくある誤解である。両者は扱う問いそのものが異なる。ザックマンは「何を(What artifacts)」記述すれば完全かを規定する分類体系であり、TOGAF ADMは「どの順序で(how-to process)」作るかを規定する方法論である。実際の公共・金融EA構築事業では、ザックマンのセル体系で成果物メタモデル(成果物の種類と座標)を定義し、TOGAF ADMの段階(ビジョン→業務・データ・応用・技術アーキテクチャ→機会・移行計画)で作成手順を運用する混合方式が広く使われる。

観点 ザックマンフレームワーク TOGAF FEA(連邦EA)
本質 分類体系(ontology) 開発方法論(ADM) 参照モデル中心
中核の問い 何を文書化するか どう開発するか 何を測定・共有するか
手順の提供 なし(何をのみ規定) あり(反復ADM) 部分的
強み 完全性・欠落点検 実行手順・ガバナンス 成果・参照モデル
限界 作成法を提示しない 分類の完全性は別途 適用が複雑

数値的な適用事例として、ある公共機関のEA高度化では、36個のセルのうちデータ・応用関連のセルのみ70%以上が満たされた一方、Why(動機・規則)とWhen(時間)列は20%未満しか作成されていなかった。これは「規則と日程が設計に暗黙的にのみ存在する」ことを露わにし、業務規則リポジトリを別途構築する改善課題へとつながった。別の製造業の事例では、Where(ネットワーク)列を工場ライン・物流拠点基準で明示化し、スマートファクトリー転換時のOT/IT統合設計の基準地図として活用した。このようにフレームワークの価値は「完成した36マス」ではなく「空いているマスを発見する診断力」にある。

比較を項目の羅列ではなく「差が生じる理由」として見ると、より明確になる。ザックマンとTOGAFの違いは結局、分類対手順という性格の違いに由来する。ザックマンは静的な座標系であるため「完全性」を判定するのに強いが、「ではまず何をどう作成するか」には答えられない。逆にTOGAF ADMは反復的手順を提供するため実行には強いが、作成した成果物が組織全体を漏れなく覆うかを自ら保証はしない。そこで両者を結合すれば、「ADMで回しつつ各段階の成果物をザックマンのセルにマッピングして欠落を点検する」という相互補完が成立する。ArchiMateはここに表記法を提供し、セルの内容を一貫した図として描かせてくれる。

実務適用の成否を分けるもう一つの変数はガバナンスとの結合水準である。分類座標だけを定義し、成果物の生成・更新・審議を統制するガバナンスがなければ、36マスは一度満たされた後に現実と乖離する「死んだ文書」になる。成功事例の共通点は、セル座標を構成管理・メタデータリポジトリと結び、業務規則(Why)が変われば影響を受けるデータ(What)・機能(How)セルを自動追跡し変更審議を経させた点である。すなわちザックマンは「静的な分類表」で終わらず、変化管理プロセスのインデックスとして生きているときにこそ投資対効果を生む。

5. 深化 — Zachman 3.0とデジタル変革時代の再解釈

ザックマンフレームワークは1987年の最初の発表以後、数度にわたり表記と用語が磨かれた。初期にはデータ・機能・ネットワークの3列、3行から出発したが、のちにWho・When・Why列と詳細表現・稼働エンタープライズ行が加わり、現在の6×6構造へ完成した。この拡張過程自体が「説明の軸を漏れなく網羅する」という志向を反映する。

2011年に公開されたZachman Framework 3.0は用語を整備し、列をWhat(Inventory)・How(Process)・Where(Distribution)・Who(Responsibility)・When(Timing)・Why(Motivation)へ、行をExecutive・Business Management・Architect・Engineer・Technician・Enterprise Perspectiveへと明確にした。特に最下段の行が「実装物」ではなく「実際に機能するエンタープライズ(the operating enterprise)」であることを明らかにし、アーキテクチャが文書ではなく稼働する実体を志向することを強調する。

デジタル変革・クラウド・マイクロサービス時代に「重い36マスをすべて満たすEAは時代遅れだ」という批判があるが、これは分類体系と作成方式を混同したものである。アジャイル・リーン環境でも「何を文書化するか」に対する座標系そのものは依然として有効であり、ただすべてのセルを事前に過度に産出するより必要なセルのみを適時に、軽く満たす適応型活用が推奨される。近年はザックマンのセル分類をデータガバナンス・データカタログのメタデータ分類や、エンタープライズ知識グラフの上位オントロジーとして再活用しようとする試み、そして生成AIが組織文書を自動分類・要約する際のラベル体系として借用しようとする動きも観察される。ただしこうした最新の応用は標準化されていない試みであるため、断定より「方向性」の水準で理解するのが適切である。

マイクロサービス・クラウドネイティブ環境は、ザックマンのWhere(分散)列とWhen(タイミング)列の重要性を逆説的に際立たせる。モノリシック時代には大半の処理が一つの場所で順次起きたためWhere・Whenは単純であったが、数百のサービスが複数のリージョン・可用性ゾーンに分散し非同期イベントで相互作用する今は「どこで実行され、いつどの順序で起きるか」が設計の中核的難題となった。ザックマンの列区分はこの変化に自然に対応し、分散トポロジとイベントタイミングを別個の明示的な設計次元として扱うことを強制する。この点でフレームワークの分解軸は特定の技術潮流ではなく説明の根本構造に基づくため、技術変化に対して堅牢である。

6. 考慮事項および示唆(技術士の観点)

  • 適用戦略 — 完全性点検ツールとして活用: ザックマンを「すべてのマスを満たす義務」として受け止めると文書化コストが膨張する。中核的成功要因は36マスをチェックリストとして欠落した視点(特にWhy・When・Who)を診断し、組織の成熟度に合わせて優先順位の高いセルから選択的に満たす適応型運用である。
  • トレードオフ — 完全性対機敏性: フレームワークの完全性はガバナンス・追跡性に強いが、過度な先行産出はアジャイルの速度を阻害する。分類体系は維持しつつ産出の時点と分量はリーン(lean)に取り、成果物生成手順はTOGAF ADMなどの方法論で補完すべきである。
  • 連携技術 — 方法論・ガバナンスとの結合: ザックマン(何を)は単独で完結しないため、TOGAF ADM(手順)、ArchiMate(表記)、EAガバナンス(原則・審議)、メタデータ・構成管理(成果物保存・バージョン)と結合してこそ実効がある。特に成果物座標を構成管理・データカタログと結べば、変化影響分析の自動化基盤となる。
  • 展望 — 分類オントロジーとしての持続的価値: 開発方法論は流行に従って変わってきたが、「エンタープライズを6×6へ分解する」という分類思想はツール中立であるため寿命が長い。デジタル変革成果物の複雑度が大きくなるほど「何をどこへ置くか」を規定する座標系の価値はむしろ高まり、データガバナンス・AI知識管理へ外延が拡張される可能性がある。
  • リスク — 形式主義化の警戒: EAが「報告用文書の量産」へ変質すると、現実と遊離した死文書になる。稼働実体(第6行)との整合性を周期的に検証し、アーキテクチャを意思決定に実際に用いるガバナンスループを確保すべきである。
  • 組織能力 — 視点別専門性の配置: 六つの行は互いに異なる専門性を要求するため、各視点を担う役割(経営企画・現業・アーキテクト・エンジニアなど)が組織内に実際に配置されてこそフレームワークが作動する。特定視点の人員が空白であれば当該行のセルは形式的にのみ満たされ、これは成果物品質ではなく組織設計の問題として接近すべきである。

参考資料

一言まとめ: ザックマンフレームワークは、エンタープライズ成果物を「六つの問い(列)×利害関係者の視点(行)」の36個のセルへ分解する正規化された分類体系であり、作成手順を提示する方法論(TOGAF)と結合して欠落・重複を診断するEAの座標系の役割を果たす。