はじめに
前回は、エンタプライズ・アーキテクチャ（EA）の4階層モデル（BA／DA／AA／TA）が「理屈としては理解されているのに、なぜ実践されないのか？」という問題を掘り下げました。その背景には、ビジネスアーキテクト不在、モデリング文化の未成熟、分断された開発プロセスなど、構造的な要因があることをお伝えしました。
今回はそれをさらに一歩進めて、「なぜ日本企業ではコードの再利用や、アプリケーションの構造的整合性が保てないのか？」という観点から、EAが活用されないことによって引き起こされる実務上の弊害を探っていきます。　　

再利用が進まないのは「仕組み」がないから
「コードの再利用ができていない」「新しい開発のたびにゼロから作っている」「保守性が悪い」──こうした声は多くの企業で聞かれます。
これらは単なる「技術力不足」の問題ではなく、「アーキテクチャの未整備」が原因であることが非常に多いのです。つまり、「共通化」や「再利用」を意図的に設計する仕組み（≒アーキテクチャ）が存在していないのです。

再利用の前提は「構造の共通理解」である
本来、コードやコンポーネントの再利用を可能にするには、以下の2つの前提が必要です。
1.業務や処理のパターンがモジュール化されていること
2.再利用すべき機能が共通認識として文書化されていること
しかし、日本企業においては、業務ごとに「担当者ベースの設計」がなされ、同じような機能であっても別のシステム・別の開発会社・別の表現で作られることが珍しくありません。これでは再利用しようにも、「何が共通なのか」「何を再利用できるのか」が誰にも分からない状態に陥ってしまいます。

上位アーキテクチャがなければ、共通化は生まれない
共通化・再利用の土台となるのは、ビジネスアーキテクチャ（BA）およびデータアーキテクチャ（DA）です。
•BAで業務プロセスやユースケースの構造を整理し、
•DAで共通のエンティティ（顧客、契約、製品など）を定義し、
•AAでアプリケーションサービスとして分解・配置し、
•初めてコードやコンポーネント単位での共通化・再利用が可能になります。
これを逆に言えば、上位レイヤでの共通設計がなければ、下位レイヤ（コードレベル）での再利用は「偶然」に頼るしかないということです。

「このプロジェクトだけの設計」が繰り返される構造
もう一つ、日本の開発現場で見られる大きな問題は、「プロジェクトベースで最適化された個別設計」が繰り返される点です。
各プロジェクトが自分たちの範囲だけで要件を定義し、画面設計を行い、データ項目を定義し、実装を進めてしまう。このとき、以下のような問題が起こりがちです。
•類似する処理や画面が、プロジェクトごとに微妙に異なる実装で乱立
•共通であるはずのデータ項目（例：顧客ID、ステータス、日時形式など）が統一されない
•APIがプロジェクト単位で閉じて設計され、再利用されない
このような属人化・断片化が、再利用や標準化の妨げとなります。

実装に「再利用性」「保守性」という設計視点がない
EAの最大の価値の一つは、「長期的なメンテナビリティの設計」にあります。
•機能やデータの責務を分け、疎結合にする
•ドメインごとにサービスを分割し、変更範囲を限定する
•将来の追加開発や外部連携を見越して、構造に余白を持たせる
こうした設計思想は、AAやTAの段階だけで考えても実現できません。ビジネス要件やデータ設計を通じて、上流から「再利用可能な構造」を意識的に組み込む必要があります。

「スクラップ＆ビルド」の裏に潜む損失
アーキテクチャ設計がなされていない結果、日本企業では10年に1度の頻度で「全面的なシステム更改」が起こることが多くあります。いわゆる「スクラップ＆ビルド」です。
しかし、本来アーキテクチャがしっかりしていれば、アプリケーション層やインフラ層は段階的・部分的に更新できるはずです。アーキテクチャ不在ゆえに、全体を一括で更改しなければならない構造になってしまっているのです。
これは、金銭的損失だけでなく、組織的な知見の断絶や、技術的負債の固定化にもつながっています。

次回予告：そもそも「要件定義」が誤解されている？

次回第3回では、「要件定義」というフェーズが、日本企業においてどのように誤解され、アーキテクチャ設計のチャンスを失っているのかを掘り下げます。
要件定義を単なる「ヒアリング」と「伝達」にしてしまうことが、どれだけ構造的な問題を引き起こしているのか？　本来の「設計駆動型」の要件定義とは何か？─についてご紹介していきます。

第1回：EAの4階層モデルが「理屈」で止まっている問題

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