企業ITの「モダナイゼーション」が困難な理由－本当にあった“モダナイ"のコワい話

（3）某大手製造業「ビジネス環境の変化に対応できず事業機会を逸失」

この企業では、法人向けビジネスを中心にサービスを展開していました。システムは、長期間の運用で「ブラックボックス化」が進んでいましたが、法人相手のビジネス自体はうまく回っていたため、特に問題を感じていませんでした。

その後、急激なビジネス環境の変化に見舞われ、その対応として個人向けのサービス展開を企画します。しかしながら、法人向けに最適化されたシステムは、個人を対象とした「クレジット決済」に対応できず、「手動」による契約業務で展開せざるをえなくなりました。システムの硬直化とブラックボックス化への対策を打っていなかったことが原因で、新たな業務にシステムを対応させることができず、業務改善も新規のビジネス創出も難しい状況になってしまっていたのです。

（4）某飲食品企業「事業拡大を急ぐあまり、統合した企業の数だけ基幹システムが乱立」

この企業は、M＆Aを繰り返し急速に成長した企業です。企業統合の際、買収による販売チャネル増による収益化を急ぐあまり、統合先企業のIT環境を精査する「ITデューデリジェンス」が十分に行われず、基幹システムの最適化は後回しになっていました。

この結果、買収元企業の基幹システムに加え、買収先企業の基幹システムも同時に存在する状況が続きました。M＆Aのたび、似て非なる基幹システムが増え、現場では同じ業務であるにもかかわらず、チャネルに応じて複数のシステムを使い分けることを強いられる結果となってしまいます。

• 

  類似システムの乱立による業務　出典：Ridgelinez

さらに、この企業ではM＆Aによる吸収合併だけでなく、事業分離のケースも存在しました。その際、分離事業に対しては全社のマスタ情報を移すのではなく、分離事業に関係する情報のみをマスタから分離するという手段をとりました。前述のとおり、「似て非なるシステム」が複数存在したため、それぞれのシステムが持っていたマスタ間で不整合が発生し、全社横串でのマスタ管理や保守が困難な状況に陥りました。

（5）某企業「IT音痴の経営層が“私の目が黒いうちは何も変えないでくれ”」

ある企業では、経営層のITシステムへの理解が不足しており、既に業務仕様が存在しないブラックボックス化したシステムであるにもかかわらず、開発運用を丸投げしているITベンダーに「これまでと同じものを」という文言のみを“仕様”として、新規システム構築の見積もりを求めました。

現場はモダナイゼーションの必要性を感じているものの、経営者や現行システムの責任者が推進に消極的なケースは少なくありません。経営層が「新しいことはどんどんやるべきだけれども、私が引退するまでは、システムを現行稼働させてくれればそれでいい」と発言して、現場の意欲を削ぐような例も、残念なことに実在しています。

DXを目指すなら業務とシステム双方の「リアーキテクト」を実施せよ

5つの例を見て、暗たんとした気分になったという人もいるのではないでしょうか。こうした困難な状況からモダナイゼーションを進める方法は、大きく2つに分類されます。

一つは「マイグレーション」で、これは現行の業務は変えずに、システムを新しい環境に移す方法です。マイグレーションはさらに、レガシーアプリケーションのコードを機械的に変換する「ストレートコンバージョン」と、ハードウェアやソフトウェアの変更に合わせて部分的な改修のみを行う「リホスト」に分かれます。

もう一つは、システム環境だけではなく、既存業務の整理と見直しを含めて、ビジネスプロセスとシステムの双方を再構築する「リアーキテクト」です。

• 

  モダナイゼーションを進める方法の大分類　出典：Ridgelinez

マイグレーションに含まれる「ストレートコンバージョン」は、喫緊のEOL対応を優先する場合などに選択されることがあります。ただし、現行業務の見直しはスコープ外となるため、全体最適が進まず、付加価値も生みにくい取り組みになります。いわば「問題の先送り」に過ぎず、先送りした問題は、将来的により困難なものになって再び顕在化します。

DXの実現を視野に「モダナイゼーション」に取り組むのであれば、業務の整理と見直しを含む「リアーキテクト」を前提とすることが重要になってきます。次回は、困難な状況から「リアーキテクト」を進めていくための具体的な手法を、実際の事例とともに紹介します。