はじめに

エンタプライズ・アーキテクチャ（EA：Enterprise Architecture）という言葉を耳にしたことがある方は、業務やシステムに関わる方であれば少なくないでしょう。特にEAが掲げる「4階層モデル」（BA／DA／AA／TA）は、IT部門や経営企画部門を中心に、教科書的にはよく知られている概念です。
しかし、実際に「この通りに設計している企業を見たことがあるか？」と問われると、答えに窮する方が大半ではないでしょうか。とりわけ最上位のBA（ビジネスアーキテクチャ）を、明確に設計し、それに基づいてデータ設計（DA）、アプリ設計（AA）、インフラ設計（TA）へと分解していく──という体系的なアプローチを採っている事例は、日本国内ではほとんど見られません。
なぜこのような状況が続いているのでしょうか？　本連載では、「EAが実践されない構造的な理由」を掘り下げながら、どうすれば本来あるべき設計主導のシステム開発・業務改革が実現できるのかを、5回に分けて紐解いていきます。

なぜ、理屈としては理解されているのに、実践されないのか？
EAの4階層モデルは、多くの書籍や研修、セミナーで紹介されています。以下の4層が有名です：
•BA（ビジネスアーキテクチャ）：戦略や業務プロセス、組織構造などを設計
•DA（データアーキテクチャ）：業務に必要なデータモデルやフローを設計
•AA（アプリケーションアーキテクチャ）：アプリケーション群の構成・連携を設計
•TA（テクノロジーアーキテクチャ）：ネットワーク・基盤などのインフラを設計
このように「上から下に論理的に分解される」設計思想は、情報システムの構造設計としては極めて妥当かつ、メンテナンス性や拡張性の点でも有効です。しかし、実際にはこのモデルに沿って設計されることは稀です。その理由は、単に「理解されていないから」ではなく、「制度的・文化的・構造的に実践しづらい」からなのです。

ビジネスアーキテクトという職種が日本に存在しない
本質的な原因の一つは、最上位のBAを担う専門職「ビジネスアーキテクト」が日本にはほとんど存在しないことにあります。
欧米では、ITアーキテクトとは別に、戦略と業務を橋渡しする「ビジネスアーキテクト」という役割が確立されています。彼らは、経営戦略を読み取り、業務プロセスの構造に落とし込み、そこから必要なデータ構造や業務ロジックを導出する──いわば「構造化された翻訳者」です。
一方、日本企業では「戦略」は経営層や企画部門、「業務設計」は現場や情報システム部門、と分担されがちで、その中間に「アーキテクチャ」を意識する人材が不在です。結果として、戦略が業務に落ちず、業務がシステムに反映されず、場当たり的な個別最適が横行してしまうのです。
モデリング文化の未成熟
日本企業では「ドキュメント文化（報告書、稟議書、仕様書）」は根強い一方で、「モデルで考える文化」は育っていません。
たとえばUMLやBPMNといった業務・システムの構造を可視化するモデリング手法は、本来、業務部門とIT部門の共通言語として有効です。しかし現実には「ITの専門ツール」と誤解され、業務側が参加しないまま、IT部門だけで作られる形骸化した設計資料になってしまっていることが多々あります。
「絵に描かれたモデリング」は残るが、それが実装や業務に活かされない──という状態が繰り返され、結果としてモデルベースのアプローチそのものが信頼されなくなるという負のスパイラルも起こっています。

なぜ今、EAを見直すべきなのか？
現代のシステムは、単に「自動化」や「省力化」の道具ではなく、事業構造そのものの変革を支える基盤です。にもかかわらず、アーキテクチャのないまま開発を進めるというのは、設計図のないままビルを建てるようなものです。
•DXを進めようとしても、全体設計がないために部分最適に終わる
•データ活用を目指しても、業務とデータが対応していない
•システム再構築のたびに「ゼロベースでの要件定義」が繰り返される
こうした問題の根源には、BAが定義されず、上からの整合的な設計がないことがあるのです。

次回予告：なぜ「コードの再利用」や「開発効率の向上」が起こらないのか？
次回の第2回では、アーキテクチャ的な設計が欠如することで生まれる「非効率」や「属人性」の問題に焦点を当て、プログラムコードの再利用が進まない理由や、メンテナンス性が低下する構造について掘り下げていきます。


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