はじめに
前回は、「要件定義＝ヒアリング」ではなく、「構造を設計するプロセス」であるという観点から、アーキテクチャ駆動型の要件定義の重要性をお伝えしました。
しかし、こうした構造的アプローチを実践するためには、当然ながらその「設計者」が必要です。そしてそれこそが「アーキテクト」という職種です。
ではなぜ、日本の多くの企業では、このアーキテクト人材が十分に育っておらず、存在していないのでしょうか？
今回は、エンタプライズ・アーキテクチャ（EA）導入を阻んでいる最大のボトルネックとも言える、「人と制度」の問題に焦点を当てます。

アーキテクトとは何をする人か？
まず、整理しておきたいのは「アーキテクトとは誰か？」という問いです。
IT業界では「インフラアーキテクト」や「ソフトウェアアーキテクト」など、専門技術に強いエンジニアを指すこともありますが、本稿でいう「アーキテクト」とは、以下のような役割を持つ人を指します：
•経営戦略・事業方針を理解し
•業務プロセスや組織構造を抽象化し
•必要なデータとアプリケーション構造を設計し
•技術的制約や全体整合性を踏まえてシステム全体を構想する
つまり、単なる技術者ではなく、「ビジネスとITの橋渡しを構造的に設計できる人」です。
欧米企業では、「エンタプライズアーキテクト」や「ビジネスアーキテクト」など、この領域を専門に担う役職が制度化されています。

業務部門は「あるべき構造」を言語化できない
現場からの要望をそのまま聞き出して実装するのは、一見「ユーザー志向」のように思えますが、実際には大きな落とし穴があります。
なぜなら、業務部門自身が「業務の構造」や「理想的な業務設計」を十分に把握しているとは限らないからです。現場の方が語るのは、多くの場合「現在の運用の不満」や「過去のシステムとの比較」です。
つまり、業務部門のヒアリングだけでは、
•業務全体の整合性
•組織横断の再利用設計
•データとプロセスの連動性
といった、アーキテクチャ的視点が抜け落ちてしまうのです。

日本でアーキテクトが育たない理由
1. 制度上の役職が存在しない
日本企業の職位体系の中には、「ビジネスアーキテクト」や「エンタプライズアーキテクト」に該当するポジションがほぼ存在していません。
多くは「情報システム部」「業務企画部」などの枠に分かれており、その間を設計的に橋渡しする職種が空白となっています。
これにより、アーキテクチャ設計が「誰の仕事でもない」まま放置されがちです。
2. キャリアパスが断絶している
アーキテクト的なスキルは、業務ドメインの理解 × IT設計 × 経営的視座 という3つの視点の掛け合わせが必要ですが、日本ではそのようなキャリアパスを歩める仕組みが整っていません。
•業務部門からIT部門に異動する機会は少ない
•エンジニアが業務構造を学ぶ場も少ない
•横断的プロジェクトを通じた育成機会も乏しい
その結果、業務側とIT側の「二項対立」が続き、橋渡し人材が生まれないのです。
3. プロジェクト型業務と請負構造の弊害
日本では、SIer（システムインテグレーター）への請負委託が前提になっているケースが多く、「設計」の責任と主導権が社内に残らない構造になっています。
発注者側（ユーザー企業）は「要件を伝える人」、受注者側（SIer）は「言われた通りに作る人」と役割が固定化されており、「全体構造を自ら設計する文化」が育ちにくいのです。
4. 経営層のIT理解不足と関心の欠如
アーキテクチャの設計は、本来「経営戦略と業務の整合」を目的とするものですが、経営層の多くがITを「コスト」としか見ておらず、「構造設計に時間と費用をかける意味」を理解していません。
これにより、アーキテクチャ設計の工数や予算が認められず、「設計しないまま開発に突入する」体質が続いてしまいます。

海外の成功事例に見る「アーキテクト制度」の効能
米国や欧州の企業、あるいはシンガポール政府などでは、EAの導入とともに「アーキテクト制度」が制度化され、DX・業務改革・システム再構築のあらゆる場面で効果を上げています。
たとえば：
•デンマーク政府：全省庁のアーキテクトが共同で「データ構造と業務フローの標準化」を推進
•マイクロソフト社：社内の全ビジネスプロセスに対して「ビジネスアーキテクト」が設計責任を持ち、再利用・展開のための構造設計を行う
•シンガポール政府：EAフレームを国家戦略に取り入れ、全省庁にアーキテクト配置を義務化
いずれも共通するのは、「戦略の実装手段としての構造設計」に対して、責任ある人材が制度的に設けられている点です。

では、日本企業は何から始めればよいのか？　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
以下のステップが現実的かつ効果的です：
1.アーキテクト人材の社内発掘と育成
・業務とITを横断的に理解している人材に、モデリングや設計の研修を実施
・キャリアパスに「アーキテクト」という専門性を組み込む
2.役割の明確化とミッション定義
・「ビジネスアーキテクト」としての役割を明文化し、権限と責任を持たせる
・単なる「PM（調整役）」と区別する
3.設計フェーズに予算と時間を割く文化の醸成
・開発フェーズだけでなく「設計投資」に経営層が理解を示すよう働きかける
4.EAに基づいた業務改革・DXの全体設計
・DX＝新規システム導入ではなく、「業務構造からの再設計」と再定義する

次回予告：アーキテクチャが企業にもたらす本当の価値とは？
いよいよ次回は全5回の最終回。エンタプライズ・アーキテクチャを導入することで、実際の業務改革・DX・再構築プロジェクトにどのような効果があるのか？
「絵に描いた餅」ではない、実践的な価値と変革の可能性についてまとめていきます。

第1回：EAの4階層モデルが「理屈」で止まっている問題
第2回：アーキテクチャ不在が、再利用性・保守性の低下を招く構造
第3回：「要件定義」の誤解と、設計不在のプロジェクト構造

合同会社タッチコア　代表　小西一有