社内ITの現場で、技術標準という言葉が少しずつ形骸化していると感じていませんか。テクノロジーレビューをやっているのに、実際にはほとんど引っかからない。そんな状況が続いているなら、それは仕組みが時代に合っていないサインかもしれません。

AI・SaaS時代に問う――技術標準はまだ必要か

技術標準とは、もともと自社でシステムを開発・構築する前提で生まれたものです。どの言語を使うか、どのインフラを選ぶか、どのミドルウェアを採用するか。その選択を社内で統制するための制約が、技術標準の本質でした。

かつての社内ITは、自分たちで作ることが当たり前だった。だからこそ、技術標準に従って作ることの意味があり、テクノロジーレビューで「それは標準外だ」と指摘することにも実効性があった。

ところが今はどうか。SaaSの普及により、社内ITの主な仕事は「作る」から「選ぶ・つなぐ・運用する」に変わってきています。セキュリティ対応の高度化、人件費の圧力、開発リソースの限界。これらが重なり、自社開発の比重は確実に下がっている。SaaSを選んで入れていく世界で、「社内標準の言語で作れ」という制約はそもそも適用できません。

テクノロジーレビューが形骸化する理由

実際の現場を見ると、テクノロジーレビューで引っかかるケースは年々少なくなっています。理由は単純で、レビュー対象の案件が自社開発からSaaS導入に移ってきているからです。

SaaSを選ぶ行為に、従来の技術標準はほぼ適用できない。「このSaaSは標準外のデータベースを使っている」と言っても意味をなしません。ベンダーのプロダクトにこちらの技術標準を押しつけることは不可能だからです。

結果として、テクノロジーレビューはあるのに、実質的に何も止められない・何も変えられないという状態になります。レビュー委員会が開かれ、議事録が残り、承認が下りる。でも誰も標準違反を指摘していない。これは仕組みが機能しているのではなく、レビューが儀式になっているだけです。

技術標準がまだ生きている場面――レガシー移行という現実

では技術標準は完全に不要かというと、そうではありません。明確に生きている場面があります。それはレガシーシステムの延命・移行フェーズです。

長年使ってきた業務アプリケーションや基幹システムは、すぐにSaaSに置き換えられるわけではありません。既存のフレームワーク、インフラ、連携している周辺システム。それらが絡み合っている中で「何かを追加する」「一部を入れ替える」という判断が必要になります。

このとき、技術標準は正しく機能します。今使っている技術スタックとの整合性を確認し、「これは既存システムとつながらない」「このインフラ要件は対応できない」という判断ができるのは、標準という軸があるからです。技術標準は、自社の技術的な現在地を把握するための地図でもある。その地図があるからこそ、移行の判断ができます。

「レガシー移行が終われば技術標準は不要になるのか」という問いも出てくるかもしれません。当面はそうはなりません。完全にSaaSだけで完結する企業はほぼ存在せず、新規開発や内製が残る領域では引き続き技術標準が機能します。ただし、その対象範囲は確実に狭くなっていく。その前提で設計することが現実的です。

SaaS時代の技術標準――「製造基準」から「調達基準」へ

ここで一つ反論を先回りしておきます。「SaaSでも技術標準は適用できる。セキュリティ要件やデータ連携方式は標準化できるはずだ」という意見は正しい。ただしそれは、従来の技術標準とは中身が根本的に異なります。

従来の技術標準は「何を使って作るか」の制約でした。SaaS時代に必要なのは「何を満たしていれば選んでよいか」の基準です。たとえば「シングルサインオン（SSO）対応必須」「データ保存先は国内リージョン限定」「APIによる他システム連携が可能であること」といった選定基準がそれにあたります。

これはルールの性質が「製造基準」から「調達基準」に変わったということです。この転換を意識せずに従来型の技術標準をそのまま維持しようとするから、形骸化が起きる。

事務局モデルの限界とセルフチェックへの移行

技術標準の中身を見直すことも大切ですが、それ以上に問題なのは「回し方」です。多くの組織では、技術標準を維持・管理する事務局的な存在がいて、テクノロジーレビューを運営し、承認フローを回しています。人が手間をかけて動かしている仕組みです。

このモデルは、AI・SaaS時代においてコストが見合わなくなってきています。答えは「セルフチェックへの移行」です。

申請者自身がチェックリストに沿って確認し、一定の条件を満たせば自動的に承認される。具体的には、SaaS選定時にGoogleフォームやServiceNowのフォームでセルフ申請させ、セキュリティ要件・接続要件の充足をチェックリストで確認させる。AIを活用すれば、そのチェック項目の大半は自動判定に移行できます。「このSaaSのセキュリティ要件は社内基準を満たしているか」「このAPIの接続仕様は技術標準に準拠しているか」といった確認は、ルールが明確であればAI活用との相性が良い領域です。

ただし「ルールの設計は人がやる、判断の実行はAIに任せる」という分業が前提です。AIが自動判定できるのは、判断基準が言語化・構造化されているからです。その設計を誰かがやらなければ、自動化は始まりません。

移行のリアル――最初は事務局がいないと無理

最初からセルフチェックで回そうとしても、機能しません。チェック項目が整理されていない状態でセルフチェックに移行しても、申請者は何を確認すればいいか分からない。判断に迷った案件が溢れ、結局事務局に問い合わせが殺到します。

最初は事務局ありきで設計する。テクノロジーレビューを回しながら、どの項目が実際に機能しているか・していないかを見極める。引っかかるパターンを蓄積し、チェックリスト化する。その上で少しずつセルフ化・自動化に移行していく。この順番が正しい。

「事務局をなくす」という目標を持ちながら、「今は事務局が必要」という現実を受け入れる。この両立がEA（エンタープライズアーキテクチャ）的な設計の発想です。

AI・SaaS時代の技術標準が残すべき3つのもの

技術標準として残すべきものは以下の3つです。

プロセスの定義。どの承認フローで、どのタイミングに、どんな観点でレビューするかという構造は残す必要があります。「プロセスは残す、人は減らす」が基本方針です。

技術的な現在地の記録。自社が今どの技術スタックに乗っているかという記録と標準は、レガシー移行判断の根拠として機能し続けます。地図がなければどこへ向かうかの判断もできません。

セキュリティ・接続性に関わる調達基準。SaaS選定・API連携・データ保管に関わる最低限の制約は残す。ただしこれも、AI活用による自動チェックに移行できます。人がチェックするのではなく、人がルールを設計してAIが判定する形に変えていく。

逆に捨てていいのは、「人が手間をかけて維持している割に、実際には何も止められていない制約」です。形骸化しているルールを維持するコストは、もう払う必要はありません。

技術標準は死なない――ただし形を変える

AI・SaaS時代において、技術標準の役割は変わります。作るものを統制するための製造基準から、選ぶ・つなぐ・移行するための調達基準と判断の仕組みへ。運営の主体も、事務局が回す中央集権型から、申請者がセルフチェックする分散型へ。

その移行は段階的に行うしかありません。最初から事務局ゼロで設計しようとすると、必ず崩壊します。今の事務局運用の中から「これは自動化できる」「これはセルフで判断できる」という要素を積み上げていく。それがAI時代の技術標準のリアルな進化です。

あなたの現場のテクノロジーレビュー、正直なところ機能していますか？引っかかる案件がほぼゼロなら、それは仕組みを見直すサインです。

関連記事：EAを進めたいなら運用を設計しろ——概念定義だけでは何も動かない

筆者：EAの中の人｜事業会社の社内IT部門にてエンタープライズアーキテクトとしてEA推進・ITガバナンス・データ活用・AI活用に携わって10年以上。
本記事の内容は個人の見解であり、所属組織を代表するものではありません。