基幹システムの老朽化は、業界や規模を問わず多くの企業に共通する課題です。長年の継ぎ足し改修で複雑化・ブラックボックス化した結果、保守費用の増大や属人化が進み、問題があっても見て見ぬふりをして先送りされがちです。
しかし、いわゆるレガシーシステムが「塩漬け」になったまま限界を迎えれば、法改正への対応遅れ、データ活用の制限など、経営に直結するリスクが顕在化する恐れがあります。

一方、基幹システムの刷新に手を付け、単なる入れ替えではなく、構造改革ととらえた企業は意思決定が迅速になり、DX推進などに寄与する例も少なくありません。
なぜ基幹システムの限界を見て見ぬふりしてしまうのか。どうしたら業務の見直しにまで掘り下げた「攻め」のシステムリプレイスを実現できるのか。本コラムでは、経験豊かなプロ人材・橋詰 直樹氏監修のもと、最初の一歩を踏み出すための視点を解説します。

▼　関連資料はこちら

多くの企業が抱える「塩漬け」の現状

――社内の基幹システムが老朽化しているにも関わらず、数多くの会社がシステムリプレイスに取り組めない、取り組んでもうまくいかないと悩んでいます。現場で何が起きているのか教えてください。

橋詰氏：多くの企業が、基幹システムの老朽化という課題を「見て見ぬふり」しています。システムの刷新が始まるとしても、そのきっかけは「攻め」ではなく、「やむを得ない限界」がほとんどです。 「やむを得ない限界」というのは、主に「保守期限切れ」「担当者の退職」「法改正の対応」といった状況です。会計・監査の法改正に伴って、会計システムだけ更改するのではなく、この機会に基幹システムの刷新まで進めようという事例がよくあります。

ただ、限界が来るまでシステムリプレイスに取り組まない、取り組めない現状の背景にあるのは、IT問題ではなく、「組織と文化」の問題だと私は考えます。

――IT問題ではなく、「組織と文化」の問題である、とはどういうことでしょうか。

橋詰氏：私は外資系のIT企業で長年勤務してきましたので、日本企業と海外企業の違いを見てきました。もともと日本はきめ細やかな手組のシステムを作る習慣があり、お客様も「すみずみまでうちのやりかたに合ったシステムをつくりたい」と、パッケージをカスタマイズして導入するのが主流です。それに対して海外は圧倒的にパッケージのままが多い。パッケージに合わせて業務も変えていこうという発想になり、新しいパッケージが出たり、バージョンが変わったりする場合も、携帯電話のアップデートくらいで済んだりします。細かいところまでこだわってカスタマイズしている日本企業のシステムでは、載せ替えが困難になるのと対照的です。

もう一点、安定稼働に求める質が非常に高いのも日本の特徴です。銀行のATMが少しでも止まれば報道されてしまいますし、製造業においても絶対にラインを止めないように二重三重四重に設定しています。

求めるものの違いがあり、一から自分たちの業務に合うように作り上げている基幹システムは、それを引き継げるパッケージもなく使い続け、いわゆる「塩漬け」の問題が出てきます。先ほど言った「やむを得ない限界」が来るまで問題は先送りされがちですし、ようやく取り組んでも難航する例が多数あります。

――基幹システムの刷新は、なぜ難航することが多いのでしょうか。

橋詰氏：システムリプレイスのプロジェクトが難航する理由も、技術問題というより、「組織・人・プロセス」と3層の構造的要因に集約されます。
1）組織構造の問題としては、現場の声が大きく「今のままでよい」という心理が支配的になることが、まずあげられます。日本の企業はどうしても営業や経営に近い部署が強い力を持ちますから、情報システム部門は大きい声を発し難い状況があります。社内的な立場の違いにより、非情報システム部門がプロジェクトに協力的でない状況も散見されます。
2）人の問題として典型的なのは、PMの不在です。プロジェクトのリーダーは、課長級でIT に詳しく責任感がある方、または次世代を担う方が就くことが多いのですが、リーダーとITプロジェクトのPMとは役割が異なります。PM経験がない場合、スコープ・品質・コストのマネジメントが機能せず、プロジェクトは停滞する懸念があります。
3）プロセスの問題とは、BPR（ビジネスプロセス・リエンジニアリング）の不在を指します。業務を再構築しないシステムの刷新は、「引越し」にとどまってしまう可能性があります。引越しで済めばよいのですが、きめ細かく業務に合わせた既存システムと比べると、仕事がしにくいシステムになる可能性が高くなります。

部分最適の継ぎはぎが限界を迎える時

――では老朽化したレガシーシステムを放置しておくと、どういうリスクが生じるのか。あらため教えてください。

橋詰氏：技術的な問題としては、負債の連鎖が挙げられます。保守切れで更新プログラムが適用されなくなれば、局所改修を繰り返します。途中でセキュリティ的な問題が出てきたら、もう限界を超えたということになりますが、そうでない場合は改修を繰り返し続けて全体が複雑化し、人がシステムを支える状態になります。
たとえばある一定の取引のときだけ正しい計算結果が出ないとなったら、現場の人たちが自分たちで何とか合わせようと、計算ソフト等による補正をかけて使い始めます。「こうすれば何とかなる」という職人技のような方法があちこちで生まれ、その人が休んだら処理ができなくなる属人化が進む恐れがあります。
また、基幹システムの周りには衛星のように種々の小さいシステムがあるわけですが、そちらが保守切れになって入れ替えたいとなっても、データ連携のルールや設計が不明で入れ替えられなくなります。

こうした技術的負債が重なると、当然、経営スピードは低下していきます。

――経営の影響というと、具体的にどんなことがありますか。

橋詰氏：一つ目は、データ活用が止まり、意思決定が遅延する可能性があります。継ぎはぎだらけの基幹システムは、社内のデータを一元管理できないので、分析に必要とするデータを取り出すことが困難になります。有効なデータがあるのに使えず、経営上の意思決定に悪影響を与えます。
二つ目は、保守費用が固定化し、投資余力が失われる懸念があります。ある程度規模の大きい会社の場合、保守が切れても特別保守延長の形でサービスを受けられることがあります。保守延長が必要な会社がまとまって保守費用を出すのですが、負担する会社が減ってくると費用が増大していきます。無駄にITに資金を割く状態になり、経営を圧迫する要因となります。
三つ目は、IT人材が疲弊し戦略的な業務への注力が難しくなります。情報システムの部の主要な仕事が、古いシステムの保守と、現場からの苦情対応になってしまう状況です。たとえば新しくAIを活用しようとしても、導入を検討するメンバーが不足して実施に至らないことが数多くあります。

古い基幹システムを塩漬けの状態にしておくことは、経営にとってここまで深刻な問題だと、経営層が認識していたとしても、先に申し上げた「組織と文化」の問題もあり、手を打てない現状があると言えます。

システム刷新を成功に導いた「突破の一手」—成功実践例

――システム刷新に取り組もうと思っても手が打てない会社が多い一方、システムリプレイスのプロジェクトを成功させた会社もあります。そこにはどんな違いがあるのでしょうか。

橋詰氏：成功事例でお話しします。

【ケース1】　卸売・商社（売上500億円、従業員400人程度）の成功例
■リプレイスのきっかけ
よくある「保守切れ」と「制度対応」で、既存の基幹システムの限界が来て、システムリプレイスをやらざるを得ない状況になりました。
■「突破の一手」
社長自らプロジェクトに参加したことです。「パッケージに合わせる」「自分たちが使いやすいようにカスタマイズはしない」と社長が意思決定しました。現場からは、今のシステムのまま使いたいという声もありましたが、入れ替えるのは決定事項だと宣言。「使いにくくなるのでは？」といった不安があるのなら、プロジェクトに参加して意見を出すよう方針を示し、組織横断的にプロジェクトがスタートしました。
■成果
結果としてシステムリプレイスのみならず、業務改革も進みました。「パッケージに合わせる」という前提のもと、プロジェクトに参加した各部署のメンバーが技術的な議論にも入り、そこから業務フローの見直しにまで発展。構造的な改革に成功しました。

「経営が旗を振れば、現場は動く」ということです。この事例の場合、社内のIT環境に精通した人物が推進役を担ったこともあり、経営層の説得とプロジェクトの完遂に大きな力となりました。

【ケース2】　サービス業（売上100億円、従業員100人程度）の成功例
■リプレイスのきっかけ
この企業は小規模で、老朽化した既存システムの刷新ではなく、属人化していた個々のシステムを基幹システムとして一本化するというテーマでした。しかしアジャイル開発を用いたために、契約そのものが曖昧となり、プロジェクトが停滞するという課題を抱えていました。この課題は、多くのプロジェクトで共通するものと言えるでしょう。
■「突破の一手」
自社とベンダーの間に立つ第三者として、専門的な知識を持つプロ人材を登用したことです。いったんスタートに立ち返って要件定義書やテスト計画書を策定し直し、プロジェクトを停滞させた要因を確定して責任範囲を可視化させました。
■成果
プロ人材が介入して要件を整理し直したことで、ベンダー側との意思疎通の齟齬が解消されました。曖昧だった責任範囲が明確になった結果、上流での軌道修正に成功し、停滞していたプロジェクトを再び前進させることができました。

「上流の要件精度が命運を分ける」という根本を外しては、プロジェクトを成功に導けません。企業規模・プロジェクト規模を問わない成功要因だと言えるでしょう。

他にも、海外の本社と連携するために、老朽化したシステムを刷新するプロジェクトの成功例などもあります。このケースでは、IT部門がプロジェクトを主導するのではなく、現場部門にIT専門の外部人材が加わってBPRを進めたことが「突破の一手」となりました。
外部から参画したIT人材の目で現状の業務フローを棚卸しして、現場の声を聞きながら無駄な箇所を削り、効率化を進めた例です。 「業務改革ありき」でプロジェクトを進めることも、システムリプレイスを成功させる重要なカギになります。

単なる「入れ替え」ではなく「構造改革」と捉える

――プロ人材として数多くのプロジェクトを支援するなかで、結局、システムリプレイスの本質的な問題とは何だと思われますか。

橋詰氏：システムを変えることより、「変えられる組織を作ること」が本質的な問題であり、最大の成功要因です。
まず、情報システム部が変わるとするなら、現行システムのお守り役で手一杯な状態を棚卸しすることから始めたらどうでしょうか。問い合わせが多いのか、トラブルが多いのか、一番重たい業務を軽くする手段から考え、AI導入や基盤更改の準備に使える時間を生み出す方向に進むことが最初の一歩です。
営業部など非情報システム部門のITリテラシーを上げていくことも一つの方法でしょう。そうした教育の支援も私たち外部人材によく依頼される課題ですが、社内に現場経験10年・情シス部門経験10年といった人がいたら、一番うまくいくと思います。

――「成功の方程式」といえるものはありますか。

橋詰氏：重要な要素をあえて並べて言うならば、

成功の方程式は、「経営主導」×「目的の明確化」×「業務改革」×「プロセスの言語化」です。

トップダウンで方針を示す「経営主導」が最も成功に近づくことは、実践例でも見た通りです。「目的の明確化」は、システムを刷新したことで「何ができるようになるのか」を誰が見てもわかるように示すことです。そのためには「業務改革」を伴うことが必須になります。また、それぞれの現場で「あの人だけが知っている」といった処理をピックアップして明文化する、それが「プロセスの言語化」です。

全体を通して、情報システムとその他部門の間に壁を作らないことも非常に重要です。「現場の声を聞いていたらキリがない」といった言葉をよく聞きますが、そこを切り捨てていたら後で取り返しのつかない事態を招きかねません。私は支援の場で「早く現場を巻き込んでください」とよく言います。全部門を巻き込んで、構造改革を行い、組織が変わる方向でシステム刷新がなされれば、企業も戦略的に変化させることができます。DX推進を阻んでいた足枷も外れるでしょう。

私がいつも考えているのは、技術より人（どんな優れたシステムも、使う人の意識が変わらなければ機能しない）です。
システムより業務（刷新の本質は業務改革。システムは手段であって目的ではない）です。
そして、仕組みより文化（DXは結果、変えられる組織文化を育てることが持続的な競争力に寄与する）です。

本質を見誤らなければ、困難なプロジェクトも成功に導けると考えます。

【プロフィール】

株式会社Mi＆K 代表取締役 橋詰 直樹氏（はしづめ・なおき）
グローバルIT企業に30年勤務。独立後、ITコンサルタントとして活動。業種や組織の状況に応じて、基幹系システム刷新や業務効率化、ツール選定プロジェクトを構想段階から定着まで一貫して支援している。

まとめ

老朽化し、レガシーとなった基幹システムを「見て見ぬふり」することの技術上、経営上のリスクは想定しているより大きなものだと言えます。システムリプレイスを成功に導くための方程式までお聞きしてきましたが、実際に行動に移すことは容易ではありません。

プロ人材の言葉にあったように、システムを変えることよりも、「変えられる組織を作ること」が最大の成功要因であるならば、外部人材の参画は、その「変えられる組織」を作るための出発点となるかもしれません。

「HiPro Biz」には橋詰氏をはじめ、基幹システムの刷新や業務効率化、DXコンサルタントの領域におけるプロ人材が多数登録しています。豊富な実績と高い技術力とを兼ね備え、客観的な視点を持ってご支援に入れる専門家の力を活用し、システムリプレイスのプロジェクトをより有意義なものにしていただければと思います。

▼　関連資料はこちら