社内ITのシンプル化は急務だ――AIより先に「なくす」を優先せよ

AIに手が出せない。その根本原因は、社内システムが多すぎることにある。EA（エンタープライズアーキテクチャ）の現場に10年以上いる自分から言わせてもらうと、これは特定の企業の話ではなく、日本の事業会社の社内ITが抱える構造的な問題です。

社内ITのシンプル化は、DX推進やAI活用を本気で進めるすべての企業にとって、避けて通れない課題です。

なぜ社内システムはここまで増えたのか

原因はシンプルです。個別最適化の積み重ねです。

各部門、各工場、各グループ会社が、それぞれの業務を良くしようとシステムを作ってきました。2000年代、社内ITの担当者たちが知恵を絞り、現場のために懸命に仕上げたシステムたちです。当時はそれが正解でしたし、むしろ誇るべき成果でした。

ところが今、その「頑張りの遺産」が足かせになっています。

システムとシステムが複雑に連携し、その運用のために人が張り付き、外注先も抱え込み、何かを変えようにも「どこを触れば何が壊れるかわからない」状態になっている。これが今の社内ITの現実です。

「シンプル化しよう」と言いながら進まない理由

「このままではまずい」という認識は、多くの企業で共有されています。だから大規模な基幹システム刷新プロジェクトが立ち上がる。ERPを入れる。全社統合を目指す壮大な計画が動き出す。

でも、ここに致命的な落とし穴があります。

みんな「作ること」しか考えていない。

要件定義の場で交わされる会話は、「新システムに何の機能が必要か」ばかりです。「このシステムを導入したら、何のシステムをなくすのか」という問いを立てている人が、驚くほど少ない。

その結果、何が起きるか。移行したはずなのに、システムが増えています。メインシステムは刷新された。でも旧システムの機能を完全に置き換えられなかったサブシステムが温存され、新しいシステムと並走し続ける。気づけば以前と同じシステム数、あるいは1.5倍に膨らんでいる。

「30あったシステムを10にしよう」と始めたプロジェクトが、終わってみたら28だった。これは笑い話ではなく、現実に起きていることです。

なくせない本当の理由

「このシステムがないと業務が回らない」という声が必ず出ます。これ自体は正直な声です。問題は、「業務がどう変わるのか」という議論が、要件定義の段階でされていないことです。

フィット・トゥー・スタンダード（標準機能に業務を合わせる考え方）で進めましょう、と言いながら、業務変革の合意がないまま移行を進める。すると現場は「この機能がないと今の業務ができない」と言う。その声を拾ってサブシステムを作る。結果、システムは増える。

これは現場が悪いのではありません。「なくすための議論」を設計しなかった側の問題です。

社内ITシンプル化の具体的な進め方

やることは一つです。「作る意思決定の軸」と「なくす意思決定の軸」を分けて管理する。

これは時系列で完全に分離するという意味ではありません。両者を並走させながらも、意思決定の基準を明確に分けるということです。「新システムに何を乗せるか」と「何をなくすか」は、別の問いとして扱う。この意識の違いだけで、プロジェクトの結末は大きく変わります。

具体的には、要件定義書に「廃止対象システム」の欄を設けることから始めてください。ただし、欄を設けるだけでは不十分です。廃止できない理由を、システム単位・拠点単位・グループ会社単位で具体的に洗い出すことが重要です。

たとえば「このシステムは機能的には置き換えられる。でもグループ会社Aは対応できる、BとCはこういう理由でまだ対応できない」という粒度まで落とし込む。「全社対応できればなくせる」という大雑把な整理ではなく、なくせない理由をひとつひとつ名指しで可視化・記録することをルール化する。

ここで誤解してほしくないのは、「名指し」は批判ではないということです。対応できていないグループ会社や部門を糾弾するためではなく、その理由を解消するための支援をEAが担うという姿勢で臨む。そうすることで、社内政治的な摩擦を最小化しながら廃止を前進させることができます。

新システムの稼働が安定した時点を目安に、廃止フェーズへの移行判断を行う。そのタイミングで「廃止できない理由リスト」がきちんと整理されていれば、次のアクションが明確になります。

ただし、ITガバナンスの観点からも、IT部門だけでこれを進めようとしても限界があります。社内システムの複雑さを工数・コストで可視化して経営層に示し、スポンサーシップを得ることが前提条件です。EAがイニシアチブを取り、「なくすことがゴール」だと経営層を巻き込んで明示する。それができて初めて、業務部門が動きます。

すでに稼働中のシステムが多すぎて手がつけられない、という状況なら、ワーキンググループを立ち上げることです。ただし、目的を「なくすこと」に絞り、廃止件数と廃止できない理由の解消件数をKPIに設定する。これをしないと、ワーキンググループはただの会議体になります。

今すぐ動くための3つのアクション

難しく考える必要はありません。明日から始められることが3つあります。

① 要件定義書に「廃止対象システム」の欄を追加する
欄を設けるだけで、「なくす」という視点がプロジェクト全体に通ります。廃止条件を定量的に記述することをあわせてルール化してください。
② 廃止できない理由をグループ会社・拠点単位で一覧化する
「なんとなくなくせない」を「具体的になぜなくせないか」に変換する作業です。これがなければ、廃止は永遠に「検討中」のままです。
③ 社内システムの複雑さをコスト・工数で可視化して経営層に示す
「複雑すぎる」という感覚論ではなく、数字で示す。それが経営層のスポンサーシップを引き出す最短ルートです。

AIとシンプル化は並走できる。ただし足元を直視せよ

今、AI活用への関心が高まっています。「AIで業務を効率化しよう」「DX推進にAIを活かしたい」という声があちこちから聞こえてきます。その方向性は間違っていません。

ただし、複雑に絡み合った社内システムの上にAIを乗せても、効果は限定的です。データ活用の基盤がバラバラ、システム連携が複雑、運用は外注依存。足元の複雑さがAI投資の効果を確実に削ぎます。AIを待つ必要はない。でも、足元の複雑さを放置したままAIに期待するのは、土台のない建物に屋根を乗せるようなものです。

社内ITのシンプル化とAI活用は並走できます。ただし、シンプル化への投資を後回しにするほど、AI活用の効果は薄れる。この認識を持てているかどうかが、5年後の社内ITの姿を決めます。

今まさに要件定義を進めているプロジェクトがあるなら、「このプロジェクトで何をなくすのか」を今日確認してください。それだけで、5年後の社内ITの複雑さがまったく変わります。

あなたの現場では、「なくす」という視点は要件定義に入っていますか？廃止できない理由を、グループ会社・拠点単位で名指しで整理できていますか？