設計だけじゃない――社内ITアーキテクトの仕事の全貌｜EAのつぶやき～社内IT部門あるある～

「EAって、設計する人ですよね」——この一言が、EAの仕事をいちばん矮小化している。

EA（エンタープライズアーキテクチャ）担当者の仕事は、設計書を書いて終わりではない。戦略立案から組織運営まで幅広く担う。一言では言い表せないほど広い仕事だ。強いて言うなら「企業全体の構造を設計し、動かし続ける仕事」——それがEAだ。現場の体験と客観的なフレームワーク、両方の視点からEAの仕事を語っていく。

この記事では、EAの仕事がフェーズによってどう変わるか、AIの台頭が役割をどう変えるか、推進と提案の現場でどう動くか、EAを動かし続けるために必要な視点、そしてEA側と現場側にどんな勘違いが生まれるかを語っていく。これからEAを立ち上げる人、EA推進部隊に任命されたばかりの人に、まず知っておいてほしい全体感とステップ感を伝えたい。

多くの場合、EA推進の担当者は最初から組織に存在しているわけではない。誰かが「EA推進をやりたい」と言い始めて、気づいたら自分がその担当になっていた——そういう始まり方をする人が多いはずだ。そのときの頭の中にあるのは「設計書を作る仕事」というイメージだけだ。それは間違いではないが、通過点に過ぎない。

そしてこの記事で最も伝えたいことを先に言っておく。EA側の人間でさえ、最初は「EAは設計者だ」と思っている。その思い込みを早く崩すことが、EA立ち上げの最初の仕事だ。

社内ITアーキテクトの仕事は「フェーズ」で変わる
「設計が動かない」からこそ、EA推進担当が動く
経営提案とは「落としどころを見つける仕事」だ
EAを動かし続けるための土台——視点とスキルの話
EA側と現場側、両方の勘違いを正しておく
- 参考文献

社内ITアーキテクトの仕事は「フェーズ」で変わる

EAの仕事は成熟度によって設計・運用・分析へとシフトしていく。立ち上げ初期に「設計だけ」で止まるのは通過点であって終着点ではない。

TOGAFをはじめとする業界標準が示すように、EAの本来の役割は事業の目標とITの投資・設計を一本の線でつなぐことだ^【1】。ビジネス・データ・アプリケーション・テクノロジーという4つのドメインにわたって、組織全体の構造を見通す。最初から「設計だけの仕事」ではない。

しかし現場では、立ち上げ初期は設計の比重が圧倒的に大きくなる。To Be（あるべき姿）を描き、移行計画を作り、現状のAS-IS（現状の姿）を整理する。フレームワークを作り、定義を決め、ルールを引く。この時期は「設計者」と呼ばれても仕方がない。まずはここに注力することが、EA立ち上げの正しい入口だ。

だが、運用フェーズに入ると話が変わる。設計したプロセスが動き始め、申請が集まり、データが蓄積されていく。この段階で初めて「自分たちが設計したものが、本当に使えるデータになっているか」が見えてくる。そして運用が成熟してくると、分析の比重が一気に増す。設計・運用・分析というフェーズの移行は、年度の予算サイクルや組織変更のタイミングと連動しながら、少しずつシフトしていく。

さらにAIの台頭により、データ分析の部分は今後大きく変わっていく。Deloitteの調査によれば、多くのテックリーダーが今後5年以内にAIエージェントがアーキテクチャのモデリングや設計ワークフローに統合されると予見している^【2】。これまでEAが手作業でやってきた「代わりにデータを集める・代わりに分析する」という部分は、AIに置き換わっていく。その分、EAが本来集中すべき仕事——ビジネスとITをつなぐ設計・構造化・組織的な推進——に時間を使えるようになる。現時点では、AIが出力した分析結果を読み解き、経営と現場それぞれに届く言葉へと変換し、To Beの文脈で意味づけするプロセスはAIには代替できない。だからこそ今、EAがその視点を磨く意味がある。

「設計が動かない」からこそ、EA推進担当が動く

EAが動きすぎると現場が依存する——この矛盾を制御する「線引き」がEA推進の鉄則だ。

設計書というのは、スライドが揃った瞬間に完成するものではない。組織の役割定義が少し固まって、コスト管理の仕組みが少し変わって、資産台帳が少しずつ埋まっていく。そういう「少しずつ片付いていく」積み重ねの中で、気づけば形になっている。達成感というものが、正直ない。どちらかというとマラソンを走っている感覚だ。ゴールテープを切る瞬間がなく、ただ走り続けている。

自分の経験上、大きな組織では部門をまたいだ推進がうまく機能しないことが構造的に起きる。各事業部門・システム部門に任せていれば済む話なら、EAは口を出す必要はない。しかし誰もやらないから、部門横断的な立場のEAが代わりにデータを集め、代わりに分析し、代わりに推進の旗を振る役割を担うことになる。

正直に言うと、自分自身もこの「代わりにやってしまう」という罠にはまったことがある。動かないからEAが動く。動いてしまうから現場が依存する。感謝されると思っていたのに、気づけばEAが全てを抱え込む構造になっていた。自分がそう見られていたと気づいたとき、正直ショックだった。「EAがやってくれるから大丈夫」という空気が組織に漂い始めたとき、このままではまずいと気づいた。どうすればいいか悩んだ末に行き着いたのが「線引きの明文化」だ。EAが関われる範囲をプロジェクト開始前に合意しておくことで、依存の連鎖を断ち切れるようになった。

少なくとも自分の経験では、EAが入れるのは要件定義・概要設計までだ。詳細設計・開発・テストという工程には入れない。データの収集・分析は、部門横断の視点があるからこそEAが担える領域だ。しかしシステム開発の工程は役割が違う。「ここまでは一緒にやる。ここからは任せる」——この線引きをきちんとすることが、EAが丸投げされずに機能し続けるための鉄則だ。

経営提案とは「落としどころを見つける仕事」だ

阻害要因を整理し選択肢を並べ、経営と現場の間で落としどころを構造化して示す——それがEAの経営提案だ。

推進を続ける中で、必ずぶつかる壁がある。現場と経営の間に立って、どちらも納得できる着地点を見つける仕事だ。意思決定するのは経営と現場であり、EAはその判断材料を整えるポジションに立つ^【3】。

たとえばグローバル標準システムへの統合を進めているとき、特定リージョンが「うちのシステムにはグローバル標準にない機能がある。だから移行できない」と言い始めることがある。こういう場面でEAがやるべきことは、阻害要因を構造的に整理して落としどころを示すことだ。「なぜできないか」を複数の要因に分解し、それぞれの解消策と現実的な選択肢を並べて経営に提示する。この調整役を誰もやらないと、プロジェクトは静かに死んでいく。だからEAがその役を引き受ける。そのポジションに立つ覚悟がなければ、EAは機能しない。

重要なのは、To Beの理想を守る側でもあり、現場の現実に寄り添う側でもあるというバランスだ。どちらかに倒れてしまうと機能しなくなる。理想だけ語るEAは現場に無視され、現場に迎合するEAはTo Beを失う。

この提案プロセスは、トップマネジメントと現場の両方と丁寧にコミュニケーションを取りながら進める。課題があればトップに上げ、現場の悩みは拾い上げ、その間をつなぎ続ける。複数プロジェクトを横断して目的に向けて調整していく——いわばプログラム管理と呼ぶべき仕事だ。

EAを動かし続けるための土台——視点とスキルの話

EAとして動き続けるには「考え方の枠組みを持ち・事業を知り・対話し続ける」という3つの土台が必要だ。

まず身につけるべきは、考え方の枠組みだ。TOGAFなどのフレームワークや資格はリファレンスモデルとして有用だ^【1】。ビジネス・データ・アプリケーション・テクノロジーの4ドメインという整理の枠組みは、社内の議論を構造化する際に即座に使える。資格そのものが目的ではないが、考え方の地図を持つ手段としては価値がある。

その枠組みを持った上で、第1セクションで述べた通り、事業の目標とITを一本の線でつなぐ——その観点から、自社の事業ポートフォリオを理解しておくことが次の土台になる。自社の中で何が強みなのか、何が売上・利益に貢献しているのか、今後どの方向に進もうとしているのか。上場企業であれば、決算資料・中期経営計画・統合報告書といった公開情報から相当程度把握できる。非上場企業や情報が限られる場合は、経営企画部門や事業部門との対話を通じて理解を深めることが代替手段になる。

そして継続的に磨き続けるべきスキルが、社内外の幅広い人と対話する力だ。EAは設計書を作るだけでなく、経営・現場・ITベンダー・グローバルの関係者と常に対話しながら仕事を進める。言語については、必ずしも流暢な英語力は必要ない。社内の英語話者に頼ることも、AIの翻訳機能を活用することも立派な選択肢だ。英語力そのものより、伝える意志の方がずっと重要だ。

EA側と現場側、両方の勘違いを正しておく

「EAは設計者だ」という思い込みはEA側にも現場側にも根強い。この勘違いを早く崩すことがEA立ち上げの最初の仕事だ。

冒頭で「EA側の人間でさえ、最初は設計者だと思っている」と書いた。これが、EAで最もよく起きる勘違いだ。

日本のEA人材の多くは社内育成で賄われており、既存の思考プロセスを引きずったままEAに配置されるケースが後を絶たない^【4】。設計者からビジネスとITをつなぐ存在へと転換するには、過去の思考プロセスを意識的に手放す「アンラーニング（学びほぐし）」が必要だ。

EA側の勘違い：「EAは設計する人だ」という思い込みで立ち上げに臨むと、運用・分析・推進という本来の仕事が見えなくなる。設計書を作ることがゴールではない。設計した世界観を組織の中で動かし続けることがEAの本番だ。かつての自分も、設計書を仕上げた瞬間に仕事が終わった気になっていた。その後に待っている「動かす仕事」の重さを、当時はまったく理解していなかった。

現場側の勘違い：「EAは事務局だ」「EAに言えば何とかしてくれる」という依存も危険だ。EAは現場の代わりに動く組織ではない。現場が主体となり、EAはその設計と推進を補佐する。EAに丸投げした瞬間、プロジェクトは動かなくなる。

現場の実感として、EAが組織内で十分に機能していると評価されるケースは驚くほど少ない。この現実は、EAという仕事がいかに難しく、いかに誤解されやすいかを示している。URLを一本送るだけで経営の判断材料が揃う。自分たちが積み上げてきたデータが組織を動かす瞬間の手応えは、他の仕事では味わえない。それでも、この仕事が好きだ。