システム更改とは？
リプレースとの違いやレガシーシステムの抱える
問題を解説

システム更改とは、老朽化したシステムを刷新することをさします。イメージとしては、システムの「再構築」や「バージョンアップ」といった認識の方がしっくりくる方が多いかもしれません。旧式の老朽化したシステムを「レガシーシステム」と呼び、主にレガシーシステムを刷新する際にシステム更改を実施します。

また、システム更改にはリビルド（再構築）とマイグレーション（移行）の2つの方針があります。

• リビルド（再構築）

  既存システムの要件をベースにシステムを全面的に再定義し、データのみを変換すること。

  マイグレーション（移行）

  既存のシステムの、別環境やバージョンへの移行・乗り換えのこと。たとえば、オンプレミス環境からクラウドサービスへの移行などが該当する。

  レガシーシステムを刷新せずに運用し続けると、セキュリティリスクの増加やパフォーマンスの低下による事業の停滞といった問題が発生するリスクがあります。このようなリスクを抑えるうえでもシステム更改は重要な役割を持ちます。

• リプレースとの違い

  リプレースとは、システムの一部、もしくはすべてを優れたものに入れ替えることをさします。システム更改の場合、「古いものを新しいものに更新する」といった意味を持ちますが、リプレースはそのような意味を持ちません。そのため、既存の新しいシステムを他の効率的な新システムに交換する場合は、システム更改ではなくリプレースになります。

  システム更改とリプレースは全く異なるわけでは無く、システム更改の中でリプレースを実施することもあります。たとえば、レガシーシステムを更改する際、既存のハードウェア機器やソフトを優れた別の機器への交換もリプレースです。

• マイグレーションとの違い

  マイグレーションとは、既存のシステムを新しいプラットフォームやOSに移行することです。ソフトウェアの部分的な修正や、システムに関与する一部の装置の交換とは異なり、システムを全面的に刷新して新しい環境に置き換えます。たとえば、オンプレミス型のレガシーシステムからクラウド型への移行などです。

  システム更改とマイグレーションは全くの別物ではなく、システム更改の一部にマイグレーションがあると認識しておきましょう。

システム更改によるレガシーシステムの刷新は、なぜ企業にとって必要とされるのでしょうか。その主な理由には「レガシーシステムの残存によるリスクの増加」が挙げられ、深堀すると以下4つの理由に分けられます。

現行のシステムが古いものになればなるほど、最新のシステムと性能が異なってくるだけでなく、法改正への対応や業界のトレンドに合わせた機能の拡張などができなくなります。

また、法改正への対応がシステムの老朽化のために追いつかなくなると、企業自体の成長の鈍化や市場における競争力の低下といった問題を招きます。その結果、経済産業省の参考資料「DXレポート〜ITシステム「2025年の崖」の克服とDXの本格的な展開〜（サマリー）」^＊で言及される2025年の崖（レガシーシステムの残存によって、2025年以降、最大12兆円/年の経済損失が生じる可能性）の問題も現実的なものとなってくるでしょう。

*

出典：「 DXレポート〜ITシステム「2025年の崖」の克服とDXの本格的な展開〜（サマリー） 」（経済産業省）

• （https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/pdf/20180907_01.pdf）

このような問題点やリスクを事前に防ぐためにも、多くの企業にとってシステム更改は必要なものと考えられています。

• 基幹システムの老朽化

  老朽化した基幹システムは、最新の基幹システムの性能と比べて非効率な部分が多いです。特に「システム間の連携」においては、最新のシステムとレガシーシステムではその性能に大きな差があります。

  たとえば、レガシーシステムの場合、他のシステムと連携を取るためにはカスタマイズが必要です。一方、最新のシステムは他のシステムと連携することを前提に作られているため、特別なカスタマイズをせずに他システムと連携できるものが多いです。システムによっては、特定の別システムと連携ができることを強みに提供しているものもあります。

  システム同士の連携が取れれば、それぞれで同じ内容を入力してしまう二重入力などのリスクを回避でき、ムダな作業を削減できます。その結果、入力作業の効率化につながり、空いた時間を他の作業に活用することで生産性の向上も期待できます。

• 属人性の高い管理体制からの脱却

  レガシーシステムを抱えている企業の多くでは、システムを事業部門ごとに構築しているケースが多いです。そのようなケースでは、事業に合わせて何度もカスタマイズが行なわれていることが多いため、そのシステムに精通した人しか管理・操作できなくなっていることも珍しくありません。

  特定の人しかシステムを管理・操作できないような「属人化」が発生してしまうと、万が一その人が病欠した場合や退職した場合にその業務を引き継ぐ人がいないなどの問題が発生します。もし業務の引き継ぎがスムーズに行われなければ、基幹業務のような経営にも影響する業務が進まず、企業に損失を与えるような事態にもなりかねません。

  属人化した現行のシステムを解消するためには、システム更改を実施して汎用性を高めていくことが重要です。たとえば、システム更改によって入力作業を自動化するツールと連携できるようにすれば、入社したての新人でも少しの教育で入力作業を実行できるようになります。

• 働き方改革に対する障害

  レガシーシステムが要因でシステム管理の業務が属人化すると、度重なるカスタマイズによるシステム自体の複雑化・ブラックボックス化といった問題が露呈し始めます。ブラックボックス化とは、限られた人だけが業務プロセスを知っており、他の人では業務内容がわからない状態のことです。

  ブラックボックス化が発生すると業務プロセスを理解している人に業務が偏ってしまい、過度な業務負担や残業が発生します。働き方改革やワークライフバランスの見直しが重視される昨今において、特定の人への業務の偏りは、働き方を改善していく際の障害になるでしょう。

  そのため、システム更改によって自動化ツールの導入や汎用化をはかることで属人化を解消し、特定の人材に業務が偏りすぎない体制を構築することが求められます。

  また、最近ではテレワークの導入が各企業で進んでおりますが、システム更改はテレワークへの移行に対しても柔軟に対応可能です。

  たとえば、オンプレミス型からクラウド型への移行といったシステム更改を実施することで、インターネット上でシステムを利用できるようになるため、自宅からでも操作できます。テレワークへの対応はひとつの例に過ぎませんが、このように働き方改革への障壁をクリアしやすくなるでしょう。

• コンプライアンスへの対応

  システム更改は、コンプライアンスを遵守するためのシステムを構築するうえでも重要な役割を持ちます。コンプライアンスとは、法律や規則といった法令を守ることや、社会的規範や企業の社会的責任を守ることです。

  レガシーシステムのような老朽化したシステムだと、スペックの低さが要因でコンプライアンスを遵守するための新しい機能を追加できないケースがあります。機能を追加できず法令を遵守できないとなれば、リスクを抱えたまま利用すること自体が危険とされてしまうでしょう。

  

  システム更改をすれば、最新のシステムや機能を柔軟に組み込めるように刷新できるため、必要とする機能を整備することが可能です。たとえば、新しい税法に対応した計算システムや個人情報を保護するうえで必要な各システム同士の連携機能などが挙げられます。

  特に個人情報の保護に関しては、万が一情報が流出した場合に企業の信用を大きく低下させてしまうため、システム更改による機能の追加は必須です。

ここまで、レガシーシステムが残ってしまうことによる問題点とシステム更改の必要性について取り上げましたが、根本的な問題として、なぜレガシーシステムが残ってしまうのかを知ることも大切です。その理由を知ることができれば、システム更改を実施した数十年後に再びレガシーシステムへとなってしまう事態を防げるでしょう。

残ってしまう大きな理由として、レガシーシステムを最新のシステムに変更するためのコストが賄えないといったものがあります。また、システム変更をした後の最新システムを利用できるIT人材が確保できない点も、レガシーシステムのまま運用し続けてしまう大きな要因の一つです。

• コストとリソースの問題

  レガシーシステムを刷新するためには移行や開発が必要で、その際に膨大なコストがかかります。導入費や開発費のように一時的な支出であっても、コストの増加は企業運営を苦しめる可能性があり、それが理由でシステム更改に踏み切れない企業も多いです。

  また、人的リソースもシステム更改に踏み切れない要因のひとつです。システム更改で開発を必要とする場合、主体となって動く人材にはある程度のIT知識が求められます。

  仮に、知識が十分ではない人材に開発を任せてしまうと、自社が求めるものと乖離したシステムを開発してしまう可能性があります。そのため、知識のある人材の新たな雇用が求められますが、IT人材の不足が予測されている昨今において、人材雇用は決して簡単ではありません。事実、経済産業省の発表（第1回 「第4次産業革命スキル習得講座認定制度」に関する検討会：参考資料3 IT人材育成の状況等について）^＊では、2014年の時点でIT人材は約1.5万人不足しているとされています。

  *

  出典：「第1回 「第4次産業革命スキル習得講座認定制度」に関する検討会：参考資料3 IT人材育成の状況等について」（経済産業省）

  • （https://www.meti.go.jp/shingikai/economy/daiyoji_sangyo_skill/pdf/001_s03_00.pdf）

  人的リソースを確保できなければ、システム更改を試みることができないため、レガシーシステムが残ってしまう要因になります。また、人材不足の対策として開発を外部に任せる選択もありますが、委託費用が掛かるため、結果的に費用面の問題を解決しなければいけないことは変わりません。

• IT人材不足の問題

  IT人材はレガシーシステムの刷新に必要な開発時だけでなく、新システムを運用していく際にも必要です。そのため、すでに社内に対応できる人材がいる場合は問題ありませんが、いない場合には新たに雇用しなければいけません。

  しかし、IT人材が不足する昨今においてそのハードルは年々高まりつつあり、IT人材の新たな雇用が難しく、それが要因でレガシーシステムから脱却できていない企業も多いです。

  実際、経済産業省の参考資料（第1回 「第4次産業革命スキル習得講座認定制度」に関する検討会：参考資料3 IT人材育成の状況等について）^＊では、「若年層の人口減少に伴って、2019年をピークにIT関連産業への入職者は退職者を下回り、IT人材は減少に向かうと予想されている。」と記載されており、今後もIT人材の新たな雇用は難しくなっていくことも予想されます。

  *

  出典：「第1回 「第4次産業革命スキル習得講座認定制度」に関する検討会：参考資料3 IT人材育成の状況等について」（経済産業省）

  • （https://www.meti.go.jp/shingikai/economy/daiyoji_sangyo_skill/pdf/001_s03_00.pdf）

  IT人材を新たに雇用できる確率を高めるためには、提示する給与のアップや休暇・福利厚生といった待遇面の優遇が求められます。そのため、IT人材の雇用にかかるコストアップを避けることが難しい点も、企業が抱える問題の一つです。

• システムベンダー依存の問題

  システムベンダーとは、システムの構築・運用などの業務を請け負う事業者のことです。企業によってはシステムの運用をベンダーにすべて任せており、それが要因でシステム更改をするべきかが全く分からない状態の企業も少なくありません。

  たとえば、「ベンダーに任せているから安心」といったようにベンダー任せにしてしまうと、システム更改のきっかけに気付けず、レガシーシステムのまま運用してしまうことも珍しくありません。

  また、ベンダー側からシステム更改を提案されたとしても、コストが障害となって刷新への一歩を踏み出せないケースもあります。たとえば、自社のIT人材がシステム更改を実施する場合はその人材の人件費だけで済みますが、ベンダーに依頼した場合はベンダーの委託費用も加算されるため、それ以上の費用を請求されるケースもあるでしょう。

  実際、レガシーシステムから脱却するためのシステム更改ともなれば、開発費用に何百万円といった見積もりが提示されることもあるため、その費用を工面できずにシステム更改に踏み蹴れない企業もあります。

システム更改を実施する必要性があると判断した場合には、以下の「システム更改の進め方」に沿って、システム更改を進めます。

システム更改にあたり、初めは現行のシステムでできていることとできていないことを洗い出したうえで、新システムに求められる要件を明確にします。要件が明確になったら、更改計画を策定し、開発とテストを経て実装にいたります。

大切なことは、「どのような目的でシステム更改するのか」を最後までブラさないことです。刷新する目的を忘れずに、システム更改を進めていきましょう。

• 1.要件の洗い出し

  まずは要件を洗い出します。要件を洗い出すためには、最初に現行のシステムで達成できていることと、達成できていないことの明確化が必要です。たとえば、「生産管理システムと販売管理システムの連携ができていない」「経理システムの自動入力機能は最新のものになっている」などのように挙げて、現行のシステムの詳細を把握します。

  また、明確に把握することで、システム更改に伴って「どのようなシステムを構築すべきか」が明確になります。達成できていないものに「生産管理システムと販売管理システムの連携ができていない」があるなら、それをクリアできるシステム構築が要件になるでしょう。

  もし要件を明確にせずに開発を進めてしまうと、必要な機能が不足して、思うように効率化がはかれない事態にもなりかねません。

• 2.更改計画の策定

  新システムで満たすべき要件が明確になったら、更改計画を策定していきます。システム更改を行なうにあたり、「どのデータ範囲や機能を移行するのか」や「移行するスケジュール」などを決めなくてはいけません。移行するデータ範囲や機能はリストにして、スケジュールは法改正が絡む場合にはその日程をベースに決めます。

  計画に曖昧な部分があると、「想定していた予算では足りない」「システムの運用を必要とする最終期日までに間に合わない」などの問題が発生する可能性があります。曖昧な部分を無くすためには、開発担当者との打ち合わせを複数回にわたって実施し、不明瞭な部分を無くしていくことが重要です。

• 3.開発

  計画が確定したら、実際に開発に移ります。このステップでは、要件や計画をベースに開発目的を明確にし、目的に沿った機能や性能を明らかにしていきます。たとえば、「他システムとの連携のしやすさ」をクリアすることが目的の場合には、「連携機能が必要になる」といったように追加する機能が明確になるでしょう。

  あとは開発担当者が、目的を達成するために必要な機能を追加する作業を実施します。この際、開発担当者と定期的なミーティングを欠かさず行なってください。スケジュール通りに進んでいるか、問題点は無いか、などを確認して工期に遅れが出ないよう管理者はチェックし続けることが重要です。

• 4.テスト

  開発が完了したら、プログラム通りに作動するのかをテストします。テスト実施後、システムに不具合や不足があれば修正を加えていきます。

  この際、新システムに関わる担当者が複数いる場合は、全員を含めた上で不具合箇所などの確認をしましょう。複数の視点で確認することで、関係者全員が使いやすいシステムを作れます。

• 5.実装

  システムの調整を経てテストが完了したら、実際に現場で利用できるように開発したシステムを実装していきます。実装完了後は、現場の運用体制や操作性、性能などを確認しつつ利用していきましょう。

ただ、システム更改を実施するためには、コストの問題やIT人材が不足する問題と向き合わなければいけません。問題と向き合った結果、システム更改に踏み切ることができなければ、他社との競争に負けてしまう可能性もあるでしょう。システム更改の重要性を把握したうえで、企業はシステム更改に踏み切るかどうかの適切な判断が求められます。