古い業務システムを放置すると起きるリスク5選 その2

前回は、「古い業務システムを放置すると起きるリスク5選」のリスク1~2についてご紹介しました。今回はその続き。ということで、「リスク3:ビジネス機会の損失」について解説してきます。
古くなってしまった業務システムの刷新には、リスクへの十分な検討と対策が必要になってきますので、是非、参考にしてみてください。
では、さっそくはじめていきましょう!
- 1. リスク3: ビジネス機会の損失
- 1.1. 市場変化への対応スピード低下
- 1.2. 新規サービス展開の制約
- 1.2.1. 制約1. API公開の困難性による機会損失
- 1.2.1.1. レガシーシステムにおけるAPI提供の主な課題
- 1.2.1.1.1. アーキテクチャの制約
- 1.2.1.1.2. データ形式の非標準性
- 1.2.1.1.3. リアルタイム性の欠如
- 1.2.1.1.4. セキュリティとアクセス制御
- 1.2.2. 制約2. データ活用の制限による競争力低下
- 1.2.2.1. レガシーシステムにおけるデータ活用の具体的課題
- 1.2.2.1.1. データサイロ化の深刻化
- 1.2.2.1.2. データ抽出の技術的制約
- 1.2.2.1.3. データ品質の問題
- 1.2.2.1.4. リアルタイム分析の不可能性
- 1.2.2.1.5. データ量の制約
- 1.2.3. 制約3. スケーラビリティの欠如
- 1.2.3.1. レガシーシステムのスケーラビリティに関する問題点
- 1.2.3.1.1. 垂直スケーリングの限界
- 1.2.3.1.2. スケーリングの所要時間
- 1.2.3.1.3. コストの硬直性
- 1.3. 競合他社との競争力格差の拡大
リスク3: ビジネス機会の損失
市場変化への対応スピード低下
現代のビジネス環境では、市場の変化に素早く対応できることが競争優位の源泉となっています。
しかし、大変残念なことではあるのですが、レガシーシステムはこの機動性を著しく損なわせます。
まず最初に、システム変更のリードタイムについてご紹介しておきます。
システムを変更する際に発生するリードタイムは作業が伴う為に致し方ないものですが、レガシーシステムであるが為に、新機能の追加やビジネスルールの変更に、数ヶ月から1年以上を要するケースは珍しくありません。
モダンなシステムであれば数週間で実現できる変更が、レガジーシステムでは影響範囲の調査だけで数ヶ月かかることもあるのです。
ある小売業の事例では、競合他社がオムニチャネル戦略を開始してから自社が追随するまでに2年を要し、その間に市場シェアを8%失いました。
事後分析によると、この遅れの主因は基幹システムが複数チャネルからのリアルタイム在庫照会に対応できなかったことだったそうです。
新規サービス展開の制約
次に、新規サービス展開の制約についてご紹介していきます。
デジタル時代の新規ビジネスは、システムの柔軟性を前提としています。
しかしレガシーシステムは、以下のような制約により新サービス展開を阻害します。
制約1. API公開の困難性による機会損失
現代のデジタルビジネスにおいて、API(Application Programming Interface)は不可欠なインフラとなっています。
モバイルアプリ、パートナー企業との連携、サードパーティサービスとの統合など、あらゆる場面でAPIが活用されます。
しかし、レガシーシステムはAPIの提供が技術的に極めて困難です。
レガシーシステムにおけるAPI提供の主な課題
アーキテクチャの制約
レガシーシステムの多くは、外部システムとの連携を前提としない「モノリシック」な設計になっています。特定の画面操作やバッチ処理を通じてのみデータにアクセスできる構造のため、プログラムから直接データを取得する仕組みがありません。
モダンなシステムに慣れていると、え?何故?という疑問が湧いてくるのですが、モノリシックな設計になっているが故に受け入れるしかないのが現状なのです…
データ形式の非標準性
現代のAPIでは、JSON形式やXML形式でのデータ交換が一般的ですが、レガシーシステムは固定長データ、独自のバイナリ形式、またはメインフレーム特有のEBCDIC文字コードを使用しているケースがあります。
これらを標準形式に変換するには、複雑な変換処理が必要になるのです。
リアルタイム性の欠如
レガシーシステムの多くは、夜間バッチ処理を中心とした設計になっており、リアルタイムでのデータアクセスを想定していません。
そのため、顧客がモバイルアプリで「今すぐ」必要とする情報を提供できないという問題が発生します。
セキュリティとアクセス制御
現代のAPI設計では、OAuth 2.0やJWT(JSON Web Token)などの標準的な認証・認可の仕組みが使われますが、レガシーシステムはこれらに対応していません。
独自の認証方式をAPIレイヤーで変換する必要があり、セキュリティリスクと開発コストが増大します。
制約2. データ活用の制限による競争力低下
現代のビジネスにおいて、データは「新たな石油」と呼ばれるほど重要な経営資源です。
AI・機械学習による需要予測、顧客行動分析、パーソナライゼーション、不正検知など、データ活用の巧拙が企業の競争力を左右します。
しかし、レガシーシステムは効率的なデータ活用を妨げる大きな障壁となります。
レガシーシステムにおけるデータ活用の具体的課題
データサイロ化の深刻化
レガシーシステムは、部門ごと、機能ごとに独立したデータベースを持つケースが多く、全社横断的なデータ分析が困難です。
ある製造業では、製造データ、販売データ、在庫データがそれぞれ別のシステムに格納され、統合分析するためには3つのシステムから手作業でデータを抽出し、Excelで結合するという非効率な作業が必要でした。
データ抽出の技術的制約
レガシーシステムからデータを取り出すには、専門知識を持つ技術者が複雑なSQLクエリを書くか、専用の抽出プログラムを開発する必要があります。
そのため、ビジネス部門が「この視点で分析したい」と思っても、IT部門に依頼してから結果が出るまでに数週間を要することも珍しくありません。
データ品質の問題
長年運用されたレガシーシステムでは、データの整合性が失われているケースがあります。
重複データ、欠損値、フォーマットの不統一などが散見され、そのままではAIや機械学習に利用できません。データクレンジングに膨大な工数がかかり、プロジェクトのコストと期間が大幅に増加します。
リアルタイム分析の不可能性
現代のデータ活用では、リアルタイムまたはニアリアルタイムでの分析が求められます。
例えば、ECサイトでの不正取引検知は、取引発生から数秒以内に判定する必要があります。
しかし、バッチ処理中心のレガシーシステムでは、データが分析可能になるまでに数時間から1日以上かかるため、リアルタイム分析が実現できません。
データ量の制約
レガシーシステムは、設計当時に想定されたデータ量を大幅に超えると、パフォーマンスが急激に低下します。
ビッグデータ分析やディープラーニングに必要な大量のデータを扱うことができず、最新のAI技術の恩恵を受けられません。
制約3. スケーラビリティの欠如
ビジネスの急激な成長や、一時的なアクセス集中に対応できるスケーラビリティは、現代のシステムに不可欠な要件です。
しかし、レガシーシステムはスケーラビリティに深刻な制約があり、ビジネスチャンスを逃す原因となります。
レガシーシステムのスケーラビリティに関する問題点
垂直スケーリングの限界
レガシーシステムの多くは、サーバーのCPUやメモリを増強する「垂直スケーリング(スケールアップ)」にしか対応できません。
しかし、1台のサーバーで対応できる能力には物理的な上限があり、また高性能なサーバーは非常に高額です。一方、モダンなクラウドベースのシステムは「水平スケーリング(スケールアウト)」により、サーバー台数を増やすことで理論上は無制限に処理能力を拡張できます。
スケーリングの所要時間
レガシーシステムでは、サーバーの増強に数週間から数ヶ月を要します。ハードウェアの調達、設置、設定、テストという一連のプロセスが必要だからです。
突発的なアクセス増加に対して、リアルタイムに対応することは不可能です。クラウドベースのシステムであれば、数分から数時間でキャパシティを増強できます。
コストの硬直性
オンプレミスのレガシーシステムでは、ピーク時の負荷に合わせてインフラを設計する必要があります。その結果、通常時には過剰なリソースが遊休状態となり、投資効率が悪化します。クラウドの「使った分だけ課金」モデルと比較すると、コスト面でも大きな差が生じます。
具体例として、ある製造業では新たにサブスクリプション型のビジネスモデルを展開しようとしましたが、既存の販売管理システムが一回限りの売り切り型取引しか想定していなかったため、システム全体の再構築が必要となり、市場投入が2年遅延しました。
この間に競合他社が市場を先行し、後発参入となった結果、想定の60%の売上にとどまりました。
競合他社との競争力格差の拡大
マッキンゼーの調査によれば、デジタル先進企業とデジタル後進企業の収益性格差は年々拡大しており、2020年時点で営業利益率に平均で8ポイントの差が生じています….
解説記事「古い業務システムを放置すると起きるリスク5選 その2」の続きは
現在準備中です。
公開までお待ちください。
APPSWINGBYは、最先端の技術の活用と、お客様のビジネスに最適な形で実装する専門知識を有しております。システム刷新(モダナイゼーション)やシステムリプレース、新規サービスの設計・開発、既存システムの改修(リファクタリング、リアーキテクチャ)、DevOps環境の構築、ハイブリッドクラウド環境の構築、技術サポートなど提供しています。
貴社のレガシーシステムの刷新についてご相談されたい方は、お問い合わせフォームからお気軽にご連絡ください。AI開発とSIの専門家が、貴社の課題解決をサポートいたします。

システム開発にお困りではありませんか?
もしも今現在、
- どのように開発を依頼したらよいかわからない
- どのように開発を依頼したらよいかわからない
- 企画や要件定義の段階から依頼できるのか知りたい
- システム開発費用がどれくらいかかるのか知りたい
- 見積りがほしい
など、システム開発に関するご相談・ご依頼がございましたら、お気軽にご相談ください。APPSWINGBYでは、「アプリでお客様のビジネスを加速し、お客様とともにビジネスの成功と未来を形作ること」をミッションとしています。大手SIerやR&D部門で培った経験やノウハウ、高度な技術力でお客様の「やりたい」を実現します。
この記事を書いた人

株式会社APPSWINGBY マーケティング
APPSWINGBY(アップスイングバイ)は、アプリケーション開発事業を通して、お客様のビジネスの加速に貢献することを目指すITソリューションを提供する会社です。
ご支援業種
情報・通信、医療、製造、金融(銀行・証券・保険・決済)、メディア、流通・EC・運輸 など多数

株式会社APPSWINGBY マーケティング
APPSWINGBY(アップスイングバイ)は、アプリケーション開発事業を通して、お客様のビジネスの加速に貢献することを目指すITソリューションを提供する会社です。
ご支援業種
情報・通信、医療、製造、金融(銀行・証券・保険・決済)、メディア、流通・EC・運輸 など多数
監修

株式会社APPSWINGBY CTO 川嶋秀一
動画系スタートアップや東証プライム上場企業のR&D部門を経て、2019年5月より株式会社APPSWINGBY 取締役兼CTO。
Webシステム開発からアプリ開発、AI導入、リアーキテクチャ、リファクタリングプロジェクトまで幅広く携わる。
C, C++, C#, JavaScript, TypeScript, Go, Python, PHP, Java などに精通し、Vue.js, React, Angular, Flutterを活用した開発経験を持つ。
特にGoのシンプルさと高パフォーマンスを好み、マイクロサービス開発やリファクタリングに強みを持つ。
「レガシーと最新技術の橋渡し」をテーマに、エンジニアリングを通じて事業の成長を支えることに情熱を注いでいる。

株式会社APPSWINGBY CTO 川嶋秀一
動画系スタートアップや東証プライム上場企業のR&D部門を経て、2019年5月より株式会社APPSWINGBY 取締役兼CTO。
Webシステム開発からアプリ開発、AI導入、リアーキテクチャ、リファクタリングプロジェクトまで幅広く携わる。
C, C++, C#, JavaScript, TypeScript, Go, Python, PHP, Java などに精通し、Vue.js, React, Angular, Flutterを活用した開発経験を持つ。
特にGoのシンプルさと高パフォーマンスを好み、マイクロサービス開発やリファクタリングに強みを持つ。
「レガシーと最新技術の橋渡し」をテーマに、エンジニアリングを通じて事業の成長を支えることに情熱を注いでいる。