多くの企業がDXの推進を行っていますが、問題となるのが既存システムの老朽化です。古い技術や仕組みで構築された基幹システム(レガシーシステム)を放置しておくと、DX推進の妨げとなるだけではなく、メーカーのサポート切れにより大きな問題が生じるでしょう。
こうした問題を解決してくれるのが基幹システムの刷新です。しかし、現在稼働中のシステムの刷新となると乗り越えるべき課題も多く、解決は簡単ではありません。今回は「レガシーシステムのままだとどうなるの?」「基幹システムとDXってどんな関係があるの?」そんな疑問を持つ方に向けて、基幹システムとDXの関係性、レガシーシステムを放置した場合のリスク、基幹システムを刷新する流れなどについて解説します。
目次
システム開発会社選びはプロにお任せ完全無料で全国5000社以上からご提案
基幹システムとDXの関係性とは
「DX」とは「Digital Transformaiton(デジタルトランスフォーメーション)」を略した言葉で、進化したデジタル技術を浸透させ人々の生活をより良いものへ変革することをいいます。DXを実現するためには、既存システムを適応できるように見直すことが必須です。しかし、実際には事業部ごとにシステムが構築され、全社で横断的なデータ活用ができていない企業が多く存在します。また、経営側がDXを推進しようとしても、現場サイドの抵抗により実現が難しい場合もあります。
こうした理由から、経済産業省は平成30年の「DXレポート」で「DXを本格的に実現するためには、老朽化・複雑化・ブラックボックス化した基幹システムが障壁になっている」と警鐘を鳴らしました。企業がDXを実現できない場合、2025年以降最大12兆円もの経済損失が生じる「2025年の崖」と呼ばれる問題が起こる可能性があります。日本企業がレガシーシステムを放置した状態のままだと、2025年にはデジタル競争の敗者になってしまうでしょう。今からすぐにでもレガシーシステムを刷新し、海外企業との競争に勝てる仕組みづくりをする必要があります。
基幹システムを刷新しない(レガシーシステム)のままだとどうなるのか
企業が、古い技術や仕組みで構築された基幹システム(レガシーシステム)を刷新しないとどうなるのでしょうか?
レガシーシステムを放置した状態の場合、下記のようなリスクがあります。
●システムが複雑化する
レガシーシステムを放置したまま新技術を導入したり顧客への対応を推進したりすると、部分的なカスタマイズの繰り返しとなります。そうした繰り返しをするとシステムが複雑になりブラックボックス化するでしょう。その結果、システムは手遅れとなり、誰も手をつけられない状態になってしまいます。
●業務プロセス・周辺システムとの関係がわからない
レガシーシステムを放置するとデータのサイロ化が起きます。サイロ化とは会社の様々な場所にデータが散在していることです。メインフレームは、ほかのシステム・ツールとの連携を考慮せず設計されており、新たなシステムと統合できない場合が多くあります。
●問題が見つかりづらくなる
レガシーシステムを放置しているとほかのシステムにも影響を及ぼし、システム環境のパフォーマンスも低くなるでしょう。ブラックボックス化したレガシーシステムは改善も難しく、問題が見つかりづらくなります。
●運用費や保守費が高騰化する
レガシーシステムの運用を続けると、ブラックボックス化したシステムに対応しなくてはならず、運用費や保守費が高騰するでしょう。経済産業省の「DXレポート」によると、レガシーシステムの継続的な運用によりIT予算の9割以上をシステムの維持管理費に費やす必要があります。
基幹システムに求められているもの
基幹システムとは、企業にとって主要な販売管理・生産管理・在庫管理・人事給与管理などの基幹業務を管理するためのシステムです。2025年までの間に廃棄・塩漬けするものを区分しながら、必要な基幹システムは刷新すべきでしょう。刷新とは「それまでの悪い面を一掃してまったく新しくすること」です。基幹システムの刷新により、ブラックボックス化を解消し、基幹システムのデータを活用した本格的なDXが可能です。
基幹システム刷新には下記のメリットがあります。
●事業変革にシステムを適合させられる
基幹システムの刷新で、既存事業を活かし新しい事業を立ち上げる際にほかのシステムとの連携が可能です。業務ごとにバラバラなシステムを一元化ができるため、運用・保守コストの削減にもつながります。また、事業に合うシステムを活用することで新しい企画の立案や開発も迅速にできるでしょう。
システムの一元化によるメリットは下記の通りです。
-
機能の追加が簡単にできる
-
保守・開発コストを減らせる
-
生産性がアップする
●属人化を避けられる
COBOLのようなレガシー言語に対応できるエンジニアは限られており、人材獲得は容易ではありません。COBOLを扱えるエンジニアを確保できない場合、レガシーシステムは完全にブラックボックス化してしまうでしょう。早めに基幹システムを刷新し、属人化を避けることをおすすめします。
●教育コストの削減
基幹システムを刷新することで新人教育にかかる時間を削減できます。また、離職者が出た場合の欠員補充・補充による教育もスムーズに行うことが可能です。レガシーシステムの場合、操作方法が複雑なためシステム操作習得に時間がかかりました。システムを刷新すると直感的な画面操作が可能となり、研修コストの削減にもつながります。
基幹システムを刷新する流れ
基幹システムを刷新する場合、どのような流れになるのでしょうか?
具体的に刷新を進める場合の流れは下記の通りです。
●プロジェクトチームの結成
基幹システムを刷新する場合、最初にプロジェクトチームを結成します。
プロジェクトチームを結成する際は、システム部など特定の部署だけではなく、関連する部署からそれぞれメンバーとして参加してもらいましょう。メンバーは厳選し特定の部署に人数が偏らないようにします。
プロジェクトチームを結成するメリットは下記の通りです。
-
全部署へシステム刷新を定着できる
-
特定の部署に負担がかからないようにする
-
全社の意見を聞ける
●要件定義
基幹システム刷新について適切な要件定義を行うために、現状システムを把握し現状のシステム状態をチェックします。要件定義の際には以下を行ってください。
現場のスタッフへヒアリングする
プロジェクトメンバーがシステムの問題点について、各部署のスタッフにヒアリングします。ヒアリングの目的は、ほかの部署との連携に時間がかかる業務などシステムの問題点を吸い上げることです。
現状のシステム状態をチェック
ハードウェア・ソフトウェア・パッケージソフトウェアのライセンスなど、基幹システムの状態を確認します。システム資産の漏れをなくし、ブラックボックス化をチェックすることが重要です。
●課題の洗い出し
収集した情報から課題の洗い出しをします。現場の要求に沿ったシステムだけではなく、長期的な利用を見据えたシステムの刷新を考えなくてはなりません。
「担当者が退職した場合にも対応できる仕組み」「ツールとの連携」なども考慮します。また、業務変更に伴うシステム改修にも対応できるようにするのが重要です。
課題を洗い出したら下記のポイントをクリアにしましょう。
-
DXに対応できる
-
保守・運用の人材を確保できる
-
業務上の課題を解決できる
-
ほかのシステムと連携できる
-
業務・状況の変化に合わせる
●システム刷新方針を検討
システム刷新方針には以下の3種類があります。
リビルド
「リビルド」とは基幹システムを一から新しくする方法です。リビルドは、現在のビジネスモデルから移行したい場合や、新しいやり方を始めたい場合に向いています。
リビルドには下記の特徴があります。
-
作業が大がかりになる
-
コスト・導入時間がかかる
-
システムをすべて刷新できる
-
現システムとの差異をピックアップする必要がある
-
新しいプラットフォーム・システム・プログラミング言語で構築する
-
業務と並行して移行するのが困難である
リビルドは規模が大きく移行が難しいため、失敗した時のデメリットが大きい手法です。システムに問題がある場合を除き、コスパが良い方法とはいえないでしょう。リビルドには以下の2つの開発方法があります。
開発方法 | 内容 |
---|---|
スクラッチ開発 |
|
パッケージ開発 |
|
マイグレーション
「マイグレーション」とは既存のシステムを活かし新環境に移行する方法です。
マイグレーションには下記の特徴があります。
-
既存システムの課題を解決できる
-
移行が比較的容易である
-
リスクが少ない
-
費用を抑えられる
-
業務の中断をせずシステム環境のみ刷新できる
マイグレーションには下記の3つの種類があります。
種類 | 内容 |
---|---|
ライブマイグレーション | ハイパーバイザーを利用している仮想サーバー同士が機能を移動できる |
データマイグレーション | 古いハードウェアから新しいものにデータを移行する |
レガシーマイグレーション | レガシーシステムやオンプレミスサーバーなどを新システムに移行する |
改修・バージョンアップ
予算が限られ、基幹システムの細かな問題点を重視しない場合「改修・バージョンアップ」も方法の1つです。
改修・バージョンアップの特徴は以下の点です。
-
予算を安くできる
-
業務に影響を与えない
-
将来的に大規模な刷新をする必要がある
改修・バージョンアップを繰り返すことで対応しても、オンプレミスは時間の経過とともにサポートが切れてしまいます。しかし、サポート切れ直前の刷新ではうまくいかない可能性があるでしょう。DXを推進する場合、既存システムの刷新も合わせて考えることをおすすめします。
●システムを開発・移行
自社の条件に合った刷新方法を選んだ後、システムを開発します。マイグレーションを選んだ場合、「既存の基幹システムがどのような状態なのか」「利用状況がどのようになっているのか」について社員への説明が必要です。開発が完了したら機能ごとにテストを実施し、本番の運用に備えます。
●動作テスト
移行後に、実際に運用する前にシステムが正式に稼働するかどうかテストします。動作テストでは品質目標を明確にしておきましょう。プロジェクト計画でテスト品質のチェックをします。注意すべきはマイグレーションを選んだ場合です。自動変換できない部分は手動で変換する必要があるため、余裕を持って移行スケジュールの設定をしなくてはなりません。
●運用開始
動作テストが完了したら運用開始です。運用開始後はサポートが必要なため、プロジェクトチームのメンバーがサポートを行います。
運用開始後の注意点は下記の通りです。
-
改善点を事前に知らせる
-
現場の担当者にシステムに触ってもらう
-
問い合わせ内容を共有化する
刷新を進める時のポイント
システム刷新を進める時のポイントは下記の通りです。
●現状把握を徹底する
失敗のない刷新をするには、現状の問題点を洗い出し「効率の悪い作業を整理する」「柔軟に移行する」などが重要です。現状の問題点を把握しなかった場合、特定の部署のみで扱っていた機能を削除したり、現状の問題点を先送りしてしまったりするリスクが生じます。このような問題を回避するためにも、プロジェクトチームによる徹底的な問題の洗い出しが必要です。
●適切な刷新方法を決定する
基幹システムの刷新方法については、ベンダー任せにするのではなく社内のニーズに合わせた最適な方法を選ぶことをおすすめします。リビルドとマイグレーションのメリット・デメリットを踏まえながら検討しましょう。
例)
・リビルドは高コストであるが、基幹システムの問題をすべて刷新できる
・マイグレーションは既存システムを活かせるが、すべての課題を解決できない
●品質・費用・納期も念頭に入れる
基幹システムを刷新する場合、品質・費用・納期についてバランスを考えましょう。3つの項目はバラバラではなく、それぞれが影響し合っています。特に重要な指標は品質です。
品質 | 特徴 |
---|---|
良い |
|
悪い |
|
自社でのDX推進が不安な場合は外注も検討して
DXを実現するためには、新システムへの適応に向けた既存基幹システムの見直しが必須です。レガシーシステムを放置した場合、「システムが複雑化する」「運用費や保守費が高騰化する」「属人化してしまう」などの問題が生じます。レガシーシステムの問題を解決してくれるのが基幹システムの刷新です。システム刷新により、ブラックボックス化が解消され、データ活用によるDXの実現を可能にします。
刷新には「リビルド」「マイグレーション」など様々な方法があります。プロジェクトチームを作り問題を明確にし、自社に合った方法で基幹システムを刷新しましょう。DXの推進を外部の開発会社とともに進める企業が増えています。外注でのDX推進を検討している場合は、ぜひ発注ナビにご相談ください。最適な開発会社とのマッチングをサポートいたします。ご相談からお見積りまで完全無料で対応していますので、お気軽にご相談ください。
システム開発会社選びはプロにお任せ完全無料で全国5000社以上からご提案