エンタープライズアーキテクチャ(EA:企業全体の業務・データ・システム・技術基盤の構造を可視化し、全体最適の観点から設計する手法)の必要性は、多くの企業で共有されつつあります。それでも立ち上げが前に進まない理由を突き詰めると、方法論ではなく「全体像を描ける人が社内にいない」という一点に行き着くことが少なくありません。
採用市場でもエンタープライズアーキテクトの需要は再び高まっており、外から採る前提では計画そのものが立ちません。本記事では、EAを担う人材に必要な力をどう分解し、社内のどこから見つけ、どう育てるかを、情報システム部門長・IT企画責任者・CIOの視点で整理します。
なぜEAは「人」で止まるのか
原因は採用市場の逼迫だけではありません。多くの場合、その手前に三つの構造的な問題があります。
- 求人要件を書けない。 事業とITをまたいで構造を示す役割は、担当領域で職務を記述する従来の様式に収まりません。
- 経験者かどうかを見極められない。 EAの価値は成果物の分量ではなく意思決定への貢献で決まるため、経歴に「EAの経験」とあっても判断に効く仕事をしてきたかは分かりません。
- 採用しても立ち上がりに時間がかかる。 業務の実態・データの持ち方・部門間の力学まで掴むには、相応の期間が必要です。
外部調達だけに依存させると、人材確保が終わるまで何も始まりません。中核は社内に求める、という前提から考える必要があります。
EAに必要な力を4つに分解する
「EAができる人」という曖昧な括りのままでは、探すことも育てることもできません。必要な力は次の4つに分解できます。
| 力 | 何ができることか | 社内で持っている人 |
|---|---|---|
| 構造化力 | 複雑な現状を、意思決定に使える粒度の図と関係に整理できる | 業務設計・システム企画の経験者 |
| 業務・事業理解 | その業務が何の価値を生み、どこが競争力かを説明できる | 事業部門出身者、業務改革の担当者 |
| 対話と合意形成 | 立場の違う部門と経営の間で、落としどころを作れる | PMO経験者、部門調整を担ってきた人 |
| 技術の目利き | 技術選択が将来の制約になるかを判断できる | ベテランのシステム担当、インフラ責任者 |
重要なのは、4つすべてを備えた個人を探さないことです。そうした人材はほとんど市場に存在しません。構造化力と業務・事業理解を核に持つ人を中心に据え、不足する力はチームで補う設計が現実的です。そしてこれらの力を持つ人材は、すでに社内の企画部門や業務改革の担当者の中にいることが少なくありません。EA人材の確保は、新しい人を探す前に、社内の誰にどの力があるかを棚卸しするところから始められます。
なお、アーキテクト系の役割定義は国のスキル標準でも整理が進んでいます。経済産業省・IPAのデジタルスキル標準ver.2.0ではビジネスアーキテクト類型のロールが見直され、データアーキテクトを含むデータマネジメント類型が新設されました。自社の役割定義の出発点として参照できます。
どこから調達するか——3つの手段の使い分け
| 手段 | 向く場面 | 注意点 |
|---|---|---|
| 社内育成 | 中核メンバーを据えるとき | 育つまで時間がかかる。片手間では育たない |
| 中途採用 | 特定の専門性が明確に欠けているとき | 要件を書けないまま募集すると採用も定着もしない |
| 外部伴走 | 立ち上げ期に進め方の型を作るとき | 引き継ぎ設計がないと、外部に依存が残る |
現実的な組み合わせは、中核は社内育成、立ち上げの型づくりは外部伴走、欠けた専門性のみ採用です。外部の支援を使う場合も、成果物を納めてもらうことではなく、社内メンバーが型を習得することを目的に置きます。描く力が社内に残らなければ、次の投資判断でまた外部を呼ぶことになるためです。
社内で育てる進め方
ステップ1:役割を「関与する意思決定」で定義する
担当業務ではなく、どの意思決定に関与するかで役割を定義します。「刷新順序を決める場に全体影響の分析を出す」「新規システムの起案時に全体整合の観点で意見を述べる」といった形です。これが決まれば、育成のゴールも採用要件も書けるようになります。
ステップ2:研修ではなく実案件で育てる
フレームワークの研修を先行させると、知識はついても判断はできるようになりません。実際の投資判断や刷新の検討に最初から関与させます。EAの立ち上げと同じく、一つの経営課題に絞って可視化し、判断に使われる経験を積むことが最短の育成になります。
ステップ3:時間と評価を確保する
最も多い失敗が、兼務のまま名前だけ付けることです。EAの仕事は緊急性が低く、運用や障害対応に押し出されます。一定割合の時間を明示的に確保し、EAとしての貢献を人事評価に組み込むところまで設計しないと、任命は形だけで終わります。
よくある失敗と回避策
| よくある失敗 | 何が起きるか | 回避策 |
|---|---|---|
| 4つの力を備えた個人を探す | 該当者が見つからず、着手が遅れ続ける | 中核の力を持つ人を据え、不足はチームで補う |
| 要件を固めずに中途採用へ動く | ミスマッチが起き、早期に離職する | 関与する意思決定を先に定義してから募集する |
| 兼務のまま任命する | 日常業務に押し出され、活動が止まる | 時間の確保と評価への反映をセットで設計する |
| 外部に描いてもらって終わる | 社内に力が残らず、次も外部に頼る | 型の移転を目的に置き、引き継ぎを契約時に決める |
まとめ
EA人材の確保は、採用市場から適任者を見つける問題ではなく、役割を定義し、社内の力を見極め、育つ環境を用意する設計の問題です。必要な力を4つに分解すれば、すでに社内にいる人材の多くが中核候補に見えてきます。
中核は社内で育て、立ち上げの型は外部の伴走で作り、欠けた専門性だけを採用で補う。そのうえで時間と評価を与える。この順序を踏めば、EAは人材確保待ちで止まらずに動き出します。当社でも、EAの立ち上げ支援をサービスの中核に据え、社内に力が残る形での伴走を重視しています。
FAQ
Q. エンタープライズアーキテクトは何人必要ですか。 立ち上げ期は少人数で十分です。むしろ先に大きな専任組織を作ると、成果物づくりが自己目的化しやすくなります。中核となる担当を置き、事業部門やシステム担当を案件ごとに巻き込む形から始めることをおすすめします。
Q. TOGAFの認定資格は取得させるべきですか。 共通言語を揃える助けにはなりますが、前提条件ではありません。資格取得を先行させると、フレームワークへの準拠が目的化しやすくなります。実案件と並行して学ぶ方が定着します。
Q. PMO経験者はEA人材の候補になりますか。 有力な候補になります。部門間の調整と合意形成の経験は、EAで最も学習コストが高い力の一つだからです。構造化力と全社の技術理解を補えば、中核を担えるケースが多く見られます。
Q. 情報システム部門と人事部門で、どう役割を分けますか。 求められる力の定義と育成の場づくりは情報システム部門・IT企画が担い、等級・評価・キャリアパスへの反映は人事部門が担うのが現実的です。この接続がないまま任命だけ進めると、処遇が見合わず離職につながります。
参考資料
- 経済産業省「デジタルスキル標準ver.2.0(DSS ver.2.0)を公表します」 https://www.meti.go.jp/press/2026/04/20260416002/20260416002.html
- IPA(情報処理推進機構)「デジタルスキル標準ver.2.0を公開」 https://www.ipa.go.jp/pressrelease/2026/press20260416.html
- The Open Group「The TOGAF® Standard」 https://www.opengroup.org/togaf
- Gartner「Enterprise Architecture」 https://www.gartner.com/en/enterprise-architecture

