今のシステムは使いにくいところもあるけど、そのやり方に慣れちゃってるし、新しいやり方を覚えるのも面倒。何よりシステム刷新の時間もコストがない…
古くから使っているシステムを『レガシーシステム』と呼びます。
「レガシー（遺産）」の明確な定義はありませんが、「競合他社の類似システムと比べて古いかどうか」といった相対的な感覚で判断されることが多いようです。
近年、レガシーシステムは企業の「資産」ではなく「負債」になりつつあります。
レガシーシステムは実績がある反面、重大なリスクを多く抱えていて、気づいた時には手遅れになってしまう可能性があります。
レガシーシステムに起こりうる問題を確認し、自社のシステムが「負債」となっていないか、チェックしましょう。
レガシ―システムの問題点
レガシーシステムには、次の問題点が潜んでいます。
- 機能の後付けが多く、操作性が悪い
- 導入当時を知る人がいない
- ITベンダーの担当者も減っていく
- メンテナンス費用が年々上がる
- セキュリティレベルが低い
詳しく見ていきましょう。
機能の後付けが多く、操作性が悪い
システムは、運用開始後に成長していきます。
導入当初には気づけなかった手順や、法や制度改正などにより運用を変えざるを得ない点が出てくるためです。
そのために機能を追加したり、運用を変更したりすることがあります。
これを繰り返していくことでシステムが肥大化し、運用手順が複雑化していくのです。
結果、システム導入当初はきれいに設計されていたシステムも、時間経過とともに実情に合わない使いにくいシステムになっていきます。
時間が経つほど追加変更は多く発生するため、レガシー（遺産）と呼ばれるほどのシステムであれば、問題の量も膨大なものになっていることでしょう。
やっかいなのは、現場がどうにか工夫しながら仕事を回しているため、経営者からは順調に仕事しているように見えてしまい、問題として把握しづらい点にあります。
そのため、ベテラン職員の退職で突然業務が回らなくなってしまう可能性があります。複雑なオペレーションを覚えるために教育コストがかさんでいるケースも考えられます。
導入当時を知る人がいない
システム導入当初に関係していた人は、時間が経つほど異動や退職などでいなくなってしまう可能性が高くなります。
適切に引継ぎされていれば良いのですが、レガシーシステムともなると伝言ゲームさながら、何回もの引き継ぎを通して細かい部分が正しく伝承されていきません。
さらに上述の機能追加や運用変更が重なり、どういう意図で現在の姿になっているか、それを知る人がいなくなってしまいます。
現在のシステムを運用しているうちは良いですが、システム刷新のタイミングではこれが大きな問題となってきます。
システムの導入当時の目的や設計意図などが分からないと、新システムにする場合に必要な機能の取捨選択が困難になります。
そのため「現行システム踏襲」という安全策に走りがちになり、「システムは新しくなったけど使い勝手が変わらない（運用コストが変わらない）」という、ただお金を使っただけの、誰も嬉しくない結果になってしまいます。
ITベンダーの担当者も減っていく
最近はSaaSやPaaSに代表されるクラウド型サービスが定着し、必要に応じて機能を取捨選択できるサービスが普及してきました。
しかし、レガシーシステムはオンプレ型であることが多く、サーバーの管理からソフトウェアのメンテナンスまで、当時契約したITベンダー１社依存しているのが普通です。
さらに言えば、ITベンダーは新商品の開発・普及に投資していきますから、古いシステムであるほど、ベンダー側の運用担当者が徐々に減っていきます。
私が遭遇した事例では、20年以上運用されていたシステムのベンダー側担当者は、当時のプロジェクトリーダー一人だけという状態でした。
その方が定年退職となり、システムのお守りをしてくれる人がいなくなってしまったのです。
ただ、この事例はまだマシな方で、ITベンダーが突然倒産してしまうことだって考えられます。
小さいITベンダーであればあるほど、長期運用にはそのリスクが伴うでしょう。大企業であっても景気悪化の影響などで、最寄りの事業所がなくなってしまうこともあり得ます。
最近のシステムはオープン系の技術が使われているため、そのような場合でも他ベンダーがシステム運用を引き継いでくれる可能性が高いです。
しかし、古いシステムであるほどマイナーなプログラミング言語や廃れてしまった技術で構成されてしまっていることが多いため、引き継ぎが難航します。
高い金額で低レベルの保守サービス
古いシステムは保守を含むメンテナンス費用が高くなりがちです。
ITベンダーは、１会社の１システムのためだけに人員を維持する必要があるためです。
これがクラウドサービスでしたら、複数企業に使ってもらうことが前提のサービスになりますから、複数社で保守費を回収するビジネスが成り立ちます。
しかし１社しか使われてないシステムの場合、その会社で保守費を全額負担してもらわないと赤字になってしまいます。
保守費を安く保とうとすると、投入できる人員の数は限られます。企業としても１社しか使わないシステムのために、貴重なリソースを割く判断をしたくはありません。
そのため、サービスの質が低くなりがちです。
レガシーシステムの保守は、『高いお金を払って低レベルのサービスを受ける』というメリットの小さい契約になってしまいがちです。
セキュリティレベルが低い
ITの進化に伴い、安くて便利なサービスが提供される一方、セキュリティ問題が多発するようになりました。
レガシーシステムは古いOSでしか動かないことが多く、セキュリティホールが放置されている危険性があります。
私が知る範囲でも、いまだにWindows NTが現役で動いているところがあります。
また、セキュリティの考え方はシステム導入当時のまま止まっているため、システムの設計思想自体が脆弱なこともあります。
例えば、次のようなことが考えらえます。
- 長いパスワードや複雑なパスワードを設定できない
- システム内（DBや設定ファイルなど）にパスワードが暗号化されずに格納されている
- ログや更新履歴を最低限しか取得しておらず、情報漏洩などの有事の際の影響調査が困難
セキュリティ面の機能拡充をしてこなかったのであれば、セキュリティの潜在リスクはかなり高いと考えられます。
レガシーシステムのリスク回避方法：お手本は「車検」
ここまでで、レガシーシステムには様々なリスクが潜んでいることが分かったと思います。
できる限り早くシステム刷新した方が良いのは間違いないのですが、システム刷新には多くの時間と費用がかかります。
自社の状況次第では、すぐに着手できないこともあるでしょう。
そこで上述のリスクが発生していないか、とりあえず定期的なチェックから始めるのがおすすめです。
イメージは「車検」です。車は、３年または２年に１回の定期的な安全点検が義務付けられています。
同じように、「毎年１回１月」のようにタイミングを決め、定期的にシステムのリスクチェックを行うのです。
リスクが低いようでしたら、来年の定期チェックまで判断を持ち越し。リスク発生の危険性が高い場合は、「システム刷新の予算組みをする」などの計画を立てます。
まずはリスクを正しく把握し、中・長期的な視点でレガシーシステムのリスク排除をしていきましょう。
最後に、システム刷新の役に立つ書籍をご紹介いたします。ご参考にどうぞ。
