EAを進めたいなら運用を設計しろ——概念定義だけでは何も動かない

EA推進の運用設計を後回しにしていませんか？EA（エンタープライズアーキテクチャ）の推進を任された人間が最初にやることは決まっている。ビジョンの定義、ドメイン区分の整理、フレームワークの構築。これは正しい。だが、そこで止まっている組織が驚くほど多い。定義しただけで「あとは現場がやってくれる」と思っているなら、それは幻想だ。

EAは運用設計があってはじめて機能する。この記事では、EA推進の現場で痛感した「運用設計の重要性」と、ステークホルダーを巻き込んで組織に定着させるための現実的なアプローチをお伝えします。

EA推進で運用設計が必要な理由——フレームワークだけでは机上の空論になる

EAを推進する初期フェーズでは、どうしても「上から整理する」作業が中心になる。ドメインを定義し、システム台帳の項目を決め、分類ルールを作る。これ自体は必要な仕事だ。

問題はその先だ。

「こういう定義にしたので、ここにこういう情報を入れてください」と現場に依頼する。現場は動く。データは入る。しかしそのデータが使い物にならない。なぜか。

定義の意味が十分に伝わっていないまま、なんとなく入力された
やらされ感で動いているので、精度より件数が優先される
担当者が変わった瞬間に、前任者の解釈と新任者の解釈がずれ始める

結果として、台帳はあるのにデータが信頼できない、という最悪の状態が生まれる。データガバナンスの観点からも、フレームワークと運用設計はセットでなければ意味をなさない。EA推進においてフレームワークが立派であればあるほど、運用が伴わないときのギャップは大きくなる。

EAチームが運用設計に組み込まれるべき理由——最初は自分たちが汗をかく

「現場に汗をかいてもらう」という発想は半分正しく、半分間違っている。最終的には現場が自律的に動く状態を目指すべきだが、最初からそれを期待してはいけない。

EA推進チームが最初にやるべきことは、自分たちも運用の中に入ることだ。具体的には以下のような役割を担う。

一次データの仮入力：現場に投げる前に、EAチームが叩き台を作る
データ精度のチェックとレビュー：入力されたデータを定期的に確認し、是正依頼を出す
承認ワークフローへの組み込み：ワークフローの中でEAチームがデータの中身を確認する役割を持つ

「最終的には自分たちがいなくても回るように設計する。でも最初は自分たちが汗をかく。」この順番が重要だ。最初から手を離すと、誰も拾わない。共同設計した運用フローの品質を自分たちが担保する、という姿勢がステークホルダーからの信頼につながる。

EA定着を阻む本当の壁——現場ではなく中間管理層だ

ここがEA推進の現場で気づく、面白い逆転がある。

現場の担当者は、目的さえ腹落ちすれば動く。「なぜこのデータが必要なのか」「これが揃うと何が変わるのか」が見えれば、意外なほど協力的になる。

むしろ厄介なのは、現場と経営の間にいる管理層——社内ITのサービスデリバリーを束ねる業務部門だ。大きな組織になればなるほど、この層の存在感は増す。

この層にとって、EA的な運用設計は「今までの仕事のやり方が丸ごと変わる」脅威に映る。現場に依頼を投げる前に、このステークホルダー層がきちんと理解し、自分ごととして動ける状態になっていなければ、EA推進の運用はこの層で止まる。データガバナンスの仕組みがいくら整っていても、この層を通過できなければ現場には届かない。