アーキテクチャレビューとは何か――IT投資を止め、方向を揃え、方針を維持するEAの核心

EA（エンタープライズアーキテクチャ）を推進していると、必ず出てくるのが「アーキテクチャレビュー」という言葉です。でも、これが何をするものなのか、きちんと説明できる人は意外と少ない。

私の定義はシンプルです。アーキテクチャレビューとは、予算削減以外の観点でIT投資を止め、組織の向かうべき方向に揃え、方針に沿った状態を維持するための仕組みです。

「投資を止める」と聞くと、ネガティブに聞こえるかもしれません。でも現場の実態を見ると、止める力がないことこそが問題の根源なのです。

「安ければいい」がIT資産を壊す

アーキテクチャレビューがない組織では何が起きるか。一言で言えば、個別最適の積み重ねが全体最適を破壊します。

ITデマンドが上がってきたとき、レビューの仕組みがないと判断軸は自然とコストに寄っていきます。「こっちのほうが安い」「予算削減になる」という理由で、技術選定が進んでいく。一件一件を見れば、それは正しい判断のように見えます。

しかし横断的に見ると何が起きているか。技術標準が乱立し、セキュリティリスクが上がり、ライセンス管理が複雑になり、気づいたときには運用コストが爆発しています。そして誰も「あのときの判断が悪かった」とは言えない。なぜなら、個々の判断はそれぞれ「合理的」だったからです。

これが怖い。劇的な失敗ではなく、小さな逸脱の積み重ねが、気づかないうちに複合的な技術負債になっていく。問題が顕在化するのは数年後で、そのときには原因の追跡すら困難になっています。気づいたときには手遅れ、というのがIT資産劣化の典型的なパターンです。

TOGAFの4レイヤーで何を見るか

アーキテクチャレビューをきちんとやっている組織は、TOGAFの4レイヤーを意識してレビューします。

ビジネスレイヤー：そのシステムはビジネスケースが書けているか。業務に本当に必要なのか。
アプリケーションレイヤー：既存のアプリケーション構成と整合が取れているか。
データレイヤー：SalesforceやSAPのような標準的なプラットフォームを使っているなら、データ管理はある程度担保される。そこを意識した設計になっているか。
テクノロジーレイヤー：自社の技術標準に沿っているか。逸脱する場合、その理由は説明できるか。

重要なのはこの順番です。ビジネスレイヤーが最上位で、テクノロジーレイヤーは最後です。にもかかわらず現場では、テクノロジーレイヤーの話ばかりが先行しがちです。

正直に言うと、現場で一番軽視されるのはビジネスレイヤーです。「なぜこのシステムが必要か」を問うと、途端に議論が止まります。ビジネスケースを書けないまま予算申請が通ってしまう案件が、驚くほど多い。テクノロジーレイヤーは皆さん熱心に議論するのに、そもそもそのシステムが必要かという問いは、なぜか誰も深掘りしない。これがEA現場の現実です。