Digital Transformation

レガシーシステムとは?DXコンサルの私が刷新方法を徹底解説

  • このエントリーをはてなブックマークに追加
  • Pocket

「あなたの会社のシステムが古いことが原因で、業務上の問題を抱えていませんか?」

ここで紹介する内容を読んで頂くと、レガシーシステムの問題点から、刷新向けたステップまで学んで頂くことができます。

私は、DXコンサルタントとして、2019年から活動を始め、複数のレガシーシステムを刷新するプロジェクトを経営トップに近い立場から支援してきました。

DXコンサルタントを始めた2019年、当時を振り返ると、レガシーシステムを刷新する案件で、大きな失敗をした経験があります。

紙メディアのクライアントで、販売システムをMSaccessからWebシステムへと刷新するプロジェクトでした。

MSaccessの中身を調査し、いざシステム刷新をするぞというときに、業務全体の見直しやデジタル紙面の拡張などビジネス要件の変化に伴い、本来半年ほどで、完了するプロジェクトが、1年ほどかかってしまいました。

経験を積んだ今であれば、レガシーシステム刷新への最適な手順や方法を選択できたと思っています。

そんな自分の経験から、レガシーシステムの7つの問題点の要約を紹介するとともに、レガシーシステムを刷新するための4つの方法と具体的な事例をまとめています。

この記事を読んでいただければ、現状にあったシステムを構築し、システムが原因となっている会社の課題を解決する糸口を見つけることができます。

レガシーシステムとは何か?

レガシーシステムというのは、端的にいうと「古くなったシステム」と言えます。

ITシステムとしては、一世代前の規格や言語で書かれていて、現代のスピード感にあわなくなったシステムを総称して、「レガシーシステム」と呼んでいます。

具体的には、以下のような場合が当てはまります。

  • 10〜30年前後に多く企業が導入したシステム
  • 日本電気、富士通、日立などの独自仕様で構築された基幹システム
  • 中小企業で使われているマイクロソフトのaccessによる顧客管理
  • COBOLなどの言語で書かれたアプリケーション

などは、レガシーシステムに該当します。

銀行などの金融系のシステムは、独自のセキュリティで固められた独自仕様のシステムを今も、便宜上使い続けているので、古いからすべてダメという訳ではありません。

レガシーシステムの7つの問題点

では、なぜ、レガシーシステムがこれほど今、問題となっているのか。

それは、2018年、経済産業省から発表された「DXレポート」にて、レガシーシステムが存在することで、日本経済全体の損失が、2025年以降で、年間12兆円にもなると発表されたことに起因します。

一企業においても、レガシーシステムを使い続けることで、様々な問題点が浮き彫りになってきますので、それを7つほど解説していきたいと思います。

ブラックボックス化

ブラックボックス化とは、企業の一部の人しか、全容がわからない状態を指します。

システム内部でどのような処理が行われ、データはどこに保存されているのかが、全くわからない、まさにブラックボックスとなっている状態です。

過去に弊社で実際に起こった事例です。

2019年にマイクロソフトアクセスで管理システムを運用していた中規模企業から依頼があり、管理システムをWebシステムにリプレイスする作業を実施することになりました。

社内のシステムに詳しいが、ITエンジニアではない担当者が、10年以上前に作ったシステムが、今も稼働していました。

現役で動いているので、画面上から、顧客管理機能、決済管理機能、請求書発行機能があることはわかりましたが、実際にデータベース側でそれがどのようにデータを管理していて、処理をどうしているのかは、実際にソースを読み解かないとわからない状態でした。

結果的には、まだ製作者がいたので、ヒアリングをして、なんとか進めることができましたが、10年以上使われていて、且つ機能を追加しながら作ったものなので、思い出してもらいながら、通常の倍以上の時間がかかってリプレイスをした経験があります。

このように、レガシーシステムは、作った本人ですら思い出せず、且つドキュメントも存在しない場合がほとんどなので、製作者がいなくなった場合は、より大きな時間と工数と費用がかかってしまうことになります。

属人化

ある担当者しかシステムの状態が把握できていないという状態が属人化です。

ブラックボックス化を回避するために、システムの全容を調査し、把握に務めなければ、運用はできません。

それ自体をマニュアル化して、誰でもシステムを触れれば良いのですが、それが出来ていないと、属人化された状態が起こります。

事例では、社内にIT部門がないため、ベンダー企業にシステム開発を丸投げしていたところ、ベンダーの担当者しかシステムの全容がわからず、ちょっとした変更でも、数万円、数十万円を請求されたということがありました。

社内の担当者もしくはベンダー頼りになっていたため、新しい施策をしたいと思っても、システム的に勝手がわからず、そこがボトルネックになるケースが多々あります。

システムに変更を加えたい時に、その人しかできない。または、そのベンダーしかできないという状態のことを指します。

データを活用できない

データ活用は、これから企業成長に欠かせないものですが、レガシーシステムでは、その考え方で作られていないことが多く、データを持っていても活かせない状態になります。

なぜ、データ活用ができないかというと、そもそも、社内にあるデータを横串でまとめる発想で作られていないからです。

例えば、ある会社の経理システムの変更を担当したときの話です。

それまでは、「お金を管理すること」が、経理部の仕事だったので、お金の管理をするためのシステムで十分でした。

しかし、経営者から求められたのは、「財務データを経営に活用すること」

つまり、レガシーシステムとなった古い経理システムでは実現できないことでした。

財務データを経営に活用できるシステムを導入することで、財務データをダッシュボードで閲覧することができ、以下のような指標もわかるようになりました。

  • 取引先別の交際費
  • 交際費をいくら使ったら、受注ができるか

など、わかりやすい例をあげましたが、費用とパフォーマンスの関係性を示す指標として、財務データを活用することができました。

セキュリティリスクが高まる

レガシーシステムが、抱える大きなリスクが、セキュリティ問題です。

企業が、保有するデータ資産に対して、最新のセキュリティ対応ができずに、顧客データなどの企業の大事な情報が流出する可能性が高まっていきます。

レガシーシステムを使い続けることは、企業の信用面においても、一瞬で崩壊するリスクを抱えていると言えます。

少し古い事例には、なりますが、2014年にベネッセコーポレーションは、顧客情報漏洩の対応に200億円がかかったとも言われていますし、2011年に起きたソニーの顧客情報漏洩では、2兆円の被害総額になったとも言われています。

最近でも、情報漏洩事例を閲覧できるサイト「サイバーセキュリティ.com」によると、株式会社ユピテルで40万件以上、株式会社中日新聞社で14万件以上の被害が、不正アクセスによって起きています。

レガシーシステムを使い続けることで、これらの被害が起こるリスクを常に抱えている状態と言えます。

今後、維持管理費が高騰する

次のビジネス上の問題点は、維持管理するための保守費用が増大することです。

レガシーシステムの維持管理は、高額です。

SAPやOracleといった代表的な基幹システムだと年間保守費用が数億円ということも珍しくありません。

2025年に上記のSAPのERPシステムは、保守を取りやめることを宣言していますし、Oracleも同様の措置を取ることが考えれます。

Oracleのケースでは、AWSを始めとするクラウドサービスとの併用を考えると、保守費用が2倍になる可能性もあると警告を受けた事例も過去に発生しています。

保守費用を払い続ければ、もちろん動き続けますが、時代の流れとも、合わなくなり、無益なものにお金を払い続けているとも言えます。

こういった古いERPシステムは、今後サポートもなくなっていきますし、保守できる人員も限られてきますので、保守費用は増大していきます。

管理体制の維持が困難になる

システム刷新の際に弊社にお問い合わせ頂く声で、多いのが、管理維持が難しくなってきたという声です。

「システムが分かる人が退職してしまって・・・」

「ベンダー企業からのサポートが年々悪くなって・・・」

主にシステム部のある一部の人や特定のベンダーに依存した管理体制が、原因で起こります。

では、その分を補えるかというと難しい問題に直面します。

DXレポートによると、2025年にIT人材は、43万人不足すると言われていて、更にレガシーシステムに対応できる人材と言ったら、ほぼ新規採用は、不可能といえます。

更に、ベンダーも新しいサービスに注力していきますから、古いシステムに人員を割くことはまずありません。

その結果、あなたの会社で使っているレガシーシステムは、管理ができなく、更に不便になっていくことになります。

スピード感をもった経営が困難に!

上記の内容を総合すると、

『スピード感を持った経営が困難になっていくこと』

が、最大の問題になります。

・どこにどのデータがあるかすぐに取り出せずに、社内の正しい情報が把握できない。
・データ管理が各部署に複数にまたがり、連携していないので、業務効率があがらない
・最新の決済手段に対応できず、新たな顧客サービスを作れない
・リモートワークを初めとした働き方の多様性が出せない
・業務が効率化できず同じ仕事の繰り返しが起こる
・タイムリーに会社の状態が把握できず経営判断のスピードが落ちる

などなど、

顧客側の視点で見ても、従業員側の視点で見ても、経営者としてやりたいこと、やるべきことが、レガシーシステムが足かせになり、実現が遠のいてしまいます。

モダナイゼーションの4つの方法

レガシーシステムを刷新することを「モダナイゼーション」と呼びます。

モダナイゼーションには、以下の4種類があり、それぞれ、特長がありますので、解説していきたいと思います。

方法ラッピングリホストリライトリプレース
レガシーシステム残す撤廃する撤廃する撤廃する
ソースコードそのまま活かすそのまま活かす書き直す書き直す
業務フローそのまま維持そのまま維持そのまま維持見直しが必要

ラッピング

古いシステムを維持しつつ、機能や役割ごとに新しいシステムで補完をする方法です。大型の予算を持たなくても、必要に応じて、システムを増強していくことが可能です。

メリット:

大きな投資がなくても、使い勝手などを改善できる。

デメリット:

レガシーシステムが残るため、運用コストなどが下がることがない。

リホスト

レガシーシステムを撤廃して、中身をオープンシステム上に移行する方法です。いわゆる「ハコ」だけを新しくする方法になります。

メリット:

古いシステムが撤廃できるため、それに起因するセキュリティなどの問題が解消されます。中身が変わらないので、基本的に、同じインターフェースで作業を実施することが可能です。

デメリット:

既存のシステムをそのまま移管するため、システム的な改善点がそのまま残ってしまいます。

リライト

レガシーシステムを撤廃し、ソースコードを完全に書き換える方法です。

メリット:

古いソースコードを維持することは、保守費用や一部機能追加などで、大きな費用がかかります。それを書き換えることで、重複していたプログラムやブラックボックス化していた部分を明らかにして、機能追加・修正の効率化や品質向上を期待できます。

デメリット:

システムで足りない部分を業務で補っている場合に、その部分が改善されないので、システムの機能追加の余地を残すことになります。

リプレース

既存の業務に合わせて、システムを全面的に刷新する方法がこの方法になります。

メリット:

業務を見直し、システムを1から作ることになりますが、今から会社の成長戦略に合わせたシステム構築が可能です。ビジネスモデルの刷新などに非常に効果的です。

デメリット:

1から作り直すことになるので、工期と予算が大きくなります。また、業務の改善が必要となるため、利用する社員へのトレーニングも必要となります。

4つのタイプから自社のモダナイゼーションの方法を選択しよう!

上記にモダナイゼーションに合わせて、4つのタイプで、それぞれ導入における、私自身が実際に経験した事例を紹介しています。

当時のお客様が抱えていた「検討事項」に対して、私の「提案内容」そして、「結果」の順番に説明します。

自社で実施する場合は、どのパターンが当てはまるか具体的にイメージできると思います。

目の前の課題をクリアしたい会社は、ラッピング法

レガシーシステムでの業務への関与度が非常に高く、また、大幅な刷新をするには、リスクが高い場合に、ラッピングは活用できます。工期も短くなり、切り替えの際に、通常業務が止まる期間も限りなく短くなるという利点があります。

大幅な刷新ではなく、まずは、業務に不足している点は、大きな課題をクリアしたいという企業には、おすすめの方法です。

[導入事例:物流会社の倉庫システム刷新]

検討事項

 2000年代に作られたレガシーシステムにて、業務管理をしていました。工場のモダナイゼーションを検討をされていて、納品、品出し、配送までを専用の端末で管理。

 レガシーシステムを残しながら、工場の専用端末を最新化して、データを精緻に管理できるようにしたい。ただし、レガシーシステム自体は、活かしていきたい。

提案内容

 レガシーシステムを活かしつつ、古いシステムと通信を取れるように、クラウドシステムで、ラッピングを提案。これにより、通信端末を最新のスマートフォンに変更して、出退勤管理や品出しの精緻化、端末側からの設定変更などを用意することを提案。

結果

 レガシーシステムで管理している項目が大変多かったので、すべてをリニューアルすると段階的に1年以上かかる予定のプロジェクトが、半年で完了。スマートフォン端末への変更により、管理費用も下がり、機能も拡張しやすい環境ができました。

クラウドの環境に切り替えるなら、リホスト法

ERPシステムで、財務会計、人事、顧客管理、生産管理など一貫して利用している企業は、リホストもおすすめできる方法ではないかと思います。

業務に関わる人員が多いので、1からシステムを構築するとなると、教育コストも含めて、膨大になることが予測されます。

既存のコンピューター上にあるデータ資産を活かしつつ、クラウドに切り替えることで、従業員や関わる協力会社にとっては、そのままのインターフェースで利用することが可能となります。

[導入事例:製造業クラウド化支援]

検討事項

これまでホストコンピューターで、財務会計、人事、生産管理などの基幹業務を行ってきたが、業績が順調に伸び、生産量や人も増えたこともあり、月の繁忙期には、システムのレスポンスが著しく遅くなることがあり、業務が進まない事態となっていた。

これを解消したいが、単にシステムを変えるだけはなく、ホストコンピューターにあるデータを経営にも活用したい。

提案内容

今かどうしているシステムの中身までは、解析できず、財務会計、人事、生産管理が、密接に連携しているため、リライトやリプレイスでは、かなりの期間がかかることが判明した。

ホストコンピューターにある膨大な業務データを活かすためにシステムのオープン化を提案。

結果

レガシーシステムと同等の環境をオープン環境へ構築し、同等のデータ移行を実施。

それでも、レガシーシステムの環境とオープン環境での差分は発生するので、そこをどう埋めるかが課題となりました。

事前のシステム設計段階で、差分を吸収できるように何度も検証を行い、環境の移設に成功。

また、業務を止めずに実施する必要があったので、工場が休みの日で移設が完了するように2週に分けて移設を実施しました。

利用者の環境が大幅に変わるのが心配ならリライト法

システムを利用するユーザーが多くいる(目安:数千以上)場合に、大幅なリニューアルで懸念がある企業には、この方法が有効です。

[導入事例:IT企業の顧客利用システムの刷新]

検討事項

 10年以上、お客様の利用しているITサービスのセキュリティに不安を覚えてきたのでなんとかしたい。大幅リニューアルをしたいが、数千件の中小企業が利用しているため、大幅なアップデートは混乱を招く可能性があり、不安がある。

提案内容

 システムの中身を調査すると、COBOLで書かれていて、ソースコード自体は、丁寧に読みやすいものであった。利用者側へのインターフェースが変わるなど、心配をされていたので、ソースコードをJavaで書き直すことを提案。

結果

 書き直したところから、順番にシステムテストをして、ソースコードを当てていったので、お客様には、全く心配をかけることなく、移行に成功。

業務を抜本的に見直したいならリプレース法

管理部門だけではなく、会社全体が、大きく変革の舵を切った会社には、この方法がおすすめです。

例えば、

  • 上記の会社のように本業でこれまでの紙面からデジタル紙面を販売する。
  • 新たな工場を稼働する
  • 地方拠点、支店をすべて結んでネットワーク化を進める

など、一部門のみにとどまらず、企業全体の業務フローがかわるようなときに、リプレースはおすすめです。

[導入事例:出版社の販売システム刷新]

検討事項

4万件の会員データを持っていて、これまでは、紙面で発送をしていただけだったので、古いシステムでも問題なく実施ができた。

このご時世で新たに、デジタル紙面を創刊することになり、販売品目が増え、決済方法も多様化してきた。販売品目の増加に柔軟に対応しつつ、決済方法の多様化にも対応できる販売システムの構築が求められている。

提案内容

古いシステムが、マイクロソフトaccessで構築されていて、専任担当者もいないので、都度分かる人が直して使っている状態でした。

販売品目やシステム外のエクセルで管理している業務、また決済方法の多様化にも対応するために、業務フローを見直し、それに合わせたWebシステムの構築を提案

結果

業務フローの見直しを一緒に考えることに十分な時間を割き、さらに分析や集計業務などのプラスアルファの要素を追加していきました。

ユーザーインターフェースが、大きく変わるので、そこを先に提案し、実際に疑似環境で触ってもらえるように進めていきました。

システム構成については、先方の開発部の状況に合わせて、PHPのlaravelで構築。

保守管理も引き継げるようにして、要件定義から販売計画も加味した上で、1年近くかけて、リプレースを実施し、成功しました。

モダナイゼーションを成功させるためのステップ

私の経験上、レガシーシステムを刷新するためのモダナイゼーションをすべて社内で実施するということは、非常にまれなケースであると思います。

実施する場合には、どうしてもベンダーに頼らなくてはいけないケースがあり、また、プロジェクト予算も決して安くはありません。実際にレガシーシステムの刷新に向けて、失敗しないためにどのようなステップが必要かをお伝えします。

STEP1: 社内合意

会社に規模に関わらず、理想を言えば、経営トップが、システム刷新に合意して頂く必要があります。少なくとも担当役員を責任者とした社内体制を構築することが必要です。

その理由としては、私の経験上、『経営陣が、最初から合意しているプロジェクト』と、『現場がリードして、都度、経営層に合意を得るプロジェクト』では、圧倒的に前者の方が、いいものが出来上がるからです。

特に、経営トップから一定程度の権限移譲を受けている場合には、実際にシステムを利用する現場の方々も巻き込みつつ、プロエジェクトがグッと推進できます。

とはいえ、このタイミングで全体像を提示するには、なかなか難しい場合もあるので、個人的には、この社内合意を得るプロセスの時点から、コンサルタントやITベンダーの中でも企画ができる業者を活用することをおすすめします。

STEP2: 社内外チームの形成

次に社内合意を取りながら、社内チームの形成も必要になります。

これは、社内の推進だけではなく、外部ベンダー、業務パートナーをうまく推進するためにも重要な工程です。

主な役割は以下の通り。

レガシーシステム刷新プロジェクト体制

【社内】

  • プロジェクトオーナー:社長や役員の名前が入れておくと、いい緊張感が生まれます。
  • 統括マネージャー:実質的なプロジェクト推進を統括する立場
  • 推進チーム:社内の調整やベンダー等を統括するチーム
  • 開発(情シス)チーム:社内システムの開示やベンダーのシステム提案を検証するチーム

【社外】

  • プロジェクトマネージャー:開発プロジェクトの責任者。全体統括する役割
  • 開発責任者:開発に関しての責任者。会議に出席するかは適宜
  • 開発者:開発を行うスタッフ
  • デザイナー:開発に必要なUI(画面、ロゴ等)をデザインするスタッフ

上記を参考に社内外に必要なメンバーを選定するところから、まずは始めましょう。

STEP3: 業務パートナー(ベンダー)選択

業務パートナーとなる開発ベンダーをどのように選ぶかも大きな課題です。

技術的にクリアできるかという点は、もちろん大切ですが、私の経験上、最も重要なのは、

『あなたの会社のリクエストをきちんとシステムに落とし込める翻訳力』

です。

エンジニアと業務をしていると、前提としている常識やそもそもの言語が違うことがあります。

そこで重要なポジションが、社外のプロジェクトマネージャーです。

技術的な知識もあり、あなたの会社の業務を深く理解する業務知識も必要になります。

このポジションの人が、優秀であれば、開発的な事故が起こる確率は、ほとんどなくなります。

有名な会社に依頼しても、プロジェクトマネージャーが、若手とか、スキルが足りないと思ったら、思い切って、中堅や小さい会社でも、プロジェクトマネージャーが優秀な開発パートナーに依頼することをおすすめします。

STEP4: ベンダーを仕切りながらのプロジェクト推進

数ヶ月から長いと1年以上の期間を経て、レガシーシステムの刷新が完了するので、ベンダーをうまく仕切りながら、プロジェクトを推進していく必要があります。

ここでは、以下の通り、プロジェクト推進に際に気をつけるポイントを記載します。

業務設計、システム設計

業務設計や要件定義のフェーズでは、ベンダー側が知りたいのは、『あなたの会社の業務の全容』になります。

この段階で意見を出し惜しみせず、開発パートナーとよくよく話し合ってください。

予算との兼ね合いになりますが、システムの耐用年数は、5年を基準に考えてみると、どれぐらい、稼働工数や人員を削減できるかを具体的に割り出すことができます。

その上で、一番簡単なのは、Googleスプレッドシートなどで、課題管理票を共有して進めるのがいいでしょう。

構築

構築を進めるのは、ベンダーですが、何がどのように進んでいるかは、工程表に合わせて、構築していく必要があります。

何を構築するのか見えないのが、不安になると思います。

できるだけシステム画面を先に提出してもらって、その画面をもとに構築に関する設計や定義を勧めていくことが、一番間違いのない方法です。

また、ベンダーの開発部門と使っている言葉のニュアンスが違う場合があるので、プロジェクトマネージャーを通して、一つ一つすり合わせをする必要があります。

システム切り替え

 構築が完了すると、システムの切り替えが必要になります。

 必ず、テスト環境で移行の手順を実施して、確認してから本番の切り替えを実施してください。

 業務フローが大幅に変わる場合には、並行稼動期間を設けることが必要ですので、その期間を最低2ヶ月は、持つ必要があります。

まとめ

レガシーシステムは、「企業の負債」となる可能性が高いものです。

これまでの業務を支えてくれたシステムであるという一面がありますが、今後の市場環境の変化やDX化の流れを考えた時に、待ったなしで刷新をすることを強くオススメします。

刷新のためのSTEPは、決して、簡単ではありませんが、経営トップや関係部署を巻き込んだ意思決定をすすめることで、企業全体の利益に貢献することができる取り組みになります。

大きなチャレンジではありますが、負債をこれ以上、増やさないためにも、早めのレガシーシステムの刷新を検討してください。

  • このエントリーをはてなブックマークに追加
  • Pocket

コメントを残す

*