情報セキュリティはEA推進の突破口だ――トップダウンが通りやすい唯一の文脈を使い倒せ

EA（エンタープライズアーキテクチャ）推進は、なぜいつも組織の壁にぶつかるのか。答えはシンプルで、「なぜやるのか」が現場に刺さらないからです。そこで私が強くすすめるのが、情報セキュリティを突破口として使う戦略です。セキュリティは、EA推進の中でほぼ唯一、トップダウン指示が素直に通る文脈です。この文脈を使わない手はありません。

この記事はNotebookLMで音声化しています。移動中や作業中にもどうぞ。

EA推進がいつも組織の壁にぶつかる理由

EA推進担当者が「システムの全体像を把握したい」「台帳を整備したい」と言っても、現場の反応はだいたい同じです。「なんでそれをIT部門に報告しなければならないのか」「自分たちはちゃんとやっている」という抵抗です。

EA担当者の立場から言うと、全社のシステムを一元管理したいという動機は正当です。しかしそれを「管理したいから」という理由で現場に依頼しても、協力は得られません。管理される側にとって、メリットが見えないからです。

ここで視点を変えます。「情報セキュリティの観点から、社内システムを統一的に把握・管理する必要がある」という言い方をした瞬間、話の構図が変わります。これに正面から「いや、管理しなくていい」と言える人は、社内にほぼいません。

セキュリティ名目でシステム棚卸しを正当化する

現状把握の第一歩は、社内にシステムがいくつあるかを知ることです。これはEA推進の根幹ですが、「EAのため」という名目では現場は動きません。

では何の名目で動かすか。答えは情報セキュリティです。

「社内システムを統一的に管理できていない＝セキュリティが担保できていない」という論理は、誰にでも理解できます。経営層はなおさらです。毎日のようにセキュリティインシデントのニュースが流れる中、「自社は大丈夫か」という意識はどの組織にも存在しています。

この意識を活用します。自社でセキュリティインシデントが発生していればそれを材料にする。なければ他社事例を使います。IPAが毎年公開している「情報セキュリティ10大脅威」や経産省のガイドライン、業界団体のインシデントレポートは、説得材料として使いやすい信頼性の高いリファレンスです。セキュリティ事故のなぜなぜ分析をたどると、根本原因の多くは「システムが誰に管理されているかわからなかった」「台帳が整備されていなかった」という管理の不備に行き着きます。そこを丁寧に示すことで、「だから管理しましょう」という提案が自然に通ります。

重要なのは、コスト削減や効率化という文脈で話さないことです。「これだけのリスクとインパクトを軽減できる」という言い方が、経営層には圧倒的に刺さります。

セキュリティ推進にEAの設計思想を組み込む方法

ここが最も重要なポイントです。

情報セキュリティ部門がシステム管理を推進すると、彼らの目的に合った管理項目だけが集まります。それはそれで正しいのですが、EA推進として必要な設計思想が抜け落ちます。何をどのレイヤーで管理するかという設計が先に必要です。

私が実践している管理レイヤーの設計はシンプルです。概念レイヤーと物理レイヤーに分けます。

概念レイヤーはアプリケーション・サービスとしてのシステムを管理します。そのシステムが何のサービスを提供しているのか、ライフサイクルはどうなっているのか、業務オーナー・システムオーナーは誰か。これがEA視点の管理領域です。

物理レイヤーはインフラ・環境・構成情報を管理します。どのサーバーで動いているか、ネットワーク構成はどうなっているか。これが情報セキュリティ視点の管理領域です。

この2つのレイヤーを分けた上で、概念レイヤーの登録なしに物理レイヤーが登録できない仕組みを作ります。「まずEAとしてシステムを定義しないと、セキュリティ管理もできない」という順番を制度として作り込むわけです。セキュリティ推進を入口にしながら、EA的な設計思想が自然にプロセスに組み込まれます。

なお、現場の緊急対応時にこの順番がボトルネックになるケースも想定されます。例外フローとして「物理登録を先行し、概念登録を一定期間内に後追いで完了させる」という運用ルールを設けておくことで、現場の柔軟性と管理の整合性を両立できます。

EA担当とセキュリティ担当の役割分担

この仕組みを機能させるには、役割の線引きが重要です。そしてその前提として、セキュリティ部門との関係構築が先に必要です。両部門が対立している状態でこのアプローチを取ると逆効果になります。まず「一緒に進める」という合意を作ることが出発点です。

情報セキュリティ部門の役割は、システムのセキュリティを担保することです。ネットワーク管理、インシデント対応、セキュリティチェック。物理レイヤーの管理が主戦場です。

EA担当の役割は、共通サービスをいかに活用させるか・標準化するかです。社内に乱立するシステムを整理し、共通化できるものを共通化する。概念レイヤーの管理と設計が主戦場です。

アセット管理という観点では、「共通サービスとして使わせる」か「セキュリティとして管理を止める」かという2軸でシステムをマネジメントします。この2つの視点が揃うことで、全体最適に近づきます。

現場の抵抗とその対処法

セキュリティ名目が経営層に通っても、現場の抵抗は別の形で出てきます。「なぜ登録しなければならないのか」「業務が増える」という声です。

ここで有効なのが、前述の管理レイヤー設計です。「物理登録の前に概念登録が必須」という仕組みにしておくと、セキュリティ担当が「物理情報を入れてください」と依頼した際に、EA側の概念登録が自動的に促されます。現場からすると「セキュリティのために入れる」という動機で動けるため、抵抗が格段に下がります。

申請フォームがレイヤーごとに増えるという課題は確かにあります。ただし、適切な粒度で管理するためには適切な数のプロセスが必要です。「増えた」ではなく「適切な管理ができるようになった」という認識に現場を導くことが、EA担当の仕事です。トップダウンで繰り返し目的を伝え続けることが、定着への近道です。

このアプローチが有効な組織の規模とツール選定

このアプローチが最も効果を発揮するのは、システム数が100を超えてきた規模の企業です。それ以下であれば、Excelによる管理でも現実的に対応できます。システム数が数百以上になり、グループ会社・リージョンをまたいだ管理が必要になってきたとき、情報セキュリティという文脈は圧倒的な推進力になります。

ツールについて言えば、最初はExcelで十分です。ただしグローバル展開や組織横断での管理を本気で進めるなら、ServiceNowの活用を検討すべきです。ServiceNowの基盤となるのはCSDM（Common Service Data Model）という標準データモデルです。このデータモデルの上にITSM・ITAM・APM・PPM・ITOM・IRMといった各モジュールが乗る構造になっており、セキュリティガバナンスからEA推進まで一気通貫で管理できます。ただしライセンスコストは相応に高いため、システム数・組織規模との見合いで投資判断が必要です。

あなたの現場はどうですか？

EA推進を「EAのため」という名目だけで進めようとして、壁にぶつかっている担当者は多いはずです。情報セキュリティという文脈は、組織の中でほぼ唯一、正面から反論されない文脈です。一人で抱え込まず、セキュリティ部門と一緒に推進する。その戦略的な連携が、EA推進を現実に動かす最短ルートだと私は考えています。

あなたの現場では、情報セキュリティをEA推進の文脈として活用できていますか？ぜひコメントで教えてください。