既存システムをすべて入れ替えずに連携・モダナイズする方法

なぜ日本企業にとって重要なのか

経済産業省は2025年の「レガシーシステムモダン化委員会総括レポート」で、既存のレガシーシステムが日本企業のDXや新しいデジタル技術の導入を妨げる要因になっていることを指摘しました。同時に、単なるシステム刷新だけではなく、

• IT資産の可視化、
• ITガバナンス、
• 情報システム部門の自律性、
• 事業部門との連携、
• ベンダーとの関係の見直し

などを重要な方向性として示しています。つまり、レガシーモダナイゼーションは、「古いシステムを新しいシステムへ交換する作業」だけではありません。業務、データ、責任、システム構造を見直す取り組みです。

そもそも「レガシーシステム」とは何か

「古い＝悪い」と考えるのは単純すぎます。重要なのは、

• 新しいシステムと連携しにくい。
• 変更に非常に時間がかかる。
• 特定の技術者しか保守できない。
• データが閉じ込められている。
• 大量の手作業が周辺に存在する。
• セキュリティやサポート上のリスクが高まっている。
• 業務を変えるたびに基幹システム自体の改修が必要になる。

といった状態です。つまり、システムの年齢ではなく、事業の変化を妨げているかが重要です。

モダナイズには3つの選択肢がある

「全面刷新」が常に最も進んだ方法というわけではありません。安定しているERPを意図的に残し、周辺を柔軟にモダナイズする方が合理的なケースもあります。

「既存システムをつなぐ」とは何をするのか

連携レイヤーは単にデータをコピーするものではありません。例えば、

• 必要な機能をAPIとして利用する。
• 異なるデータ形式を変換する。
• 複数システムをまたぐ業務を制御する。
• アクセス権を管理する。
• エラーを監視する。
• 既存システムの上に新しいWeb画面をつくる。

といった役割を持ちます。FluyentaのIntegration & Connectivityでは、クラウド・オンプレミス環境、REST/SOAP API、データ変換、企業ネットワーク内のシステムへ接続するための仕組みなどを提供しています。重要なのは、既存システムには得意な仕事を続けてもらい、元々想定されていなかった新しい連携や業務を別のレイヤーで担当するという考え方です。

図1：基幹システムを残したモダナイゼーション

方法1：既存システムの前にAPI・連携レイヤーを置く

既存システムがAPI、Webサービス、データ連携機能などを持っている場合、新しい業務からそれを利用します。例えば、

1. 1CRMで顧客承認
2. 2業務ワークフロー
3. 3データ確認
4. 4既存顧客システム
5. 5結果を返す

利用者が古い画面を直接操作しなくても、新しい業務から必要な処理を行えます。REST APIがないシステムでも、SOAP、ファイル、メッセージ、公式コネクタなどが利用できる場合があります。重要なのは、できるだけ安定し、サポート可能な公式インターフェースを選ぶことです。

方法2：基幹システムの前後をワークフロー化する

例えばERP本体は問題なく動いているものの、購買承認がメール中心だとします。ERPを大きくカスタマイズする代わりに、

1. 1申請
2. 2業務ルール
3. 3上長承認
4. 4経理・調達承認
5. 5ERPへ登録

という流れを外側に構築できます。FluyentaもSAPについて、SAPコアを大きく変更せず、SAPへ入る前の承認・確認を自動化し、周辺システムとのデータ連携やLow-codeアプリを構築する方法を説明しています。この考え方はSAP以外でも応用できます。

方法3：バックエンドを残して画面だけモダナイズする

既存システムへの不満が、

• 「画面が使いにくい」
• 「モバイル対応していない」
• 「取引先に使わせられない」

という場合もあります。その場合は、

• 現代的なWebフォーム、
• モバイル画面、
• ポータル、
• ステータス確認、
• 書類アップロード

などを新しく用意し、裏側では既存システムを利用するという方法があります。

方法4：データの「正本」を決める

システムをつなぐ際には、どのシステムの情報が正しいのかを決める必要があります。例えば、

これはあくまで例です。各企業で独自に決める必要があります。重要なのは、誰も決めていない状態をなくすことです。

データの意味を揃える

システム同士が技術的につながっていても、データの意味が違えば問題になります。

• ERPの「顧客」は法人。
• CRMの「顧客」は担当者。
• ある部門の「承認済み」は商務承認。
• 別部門の「承認済み」は技術承認。

こうした違いを整理する必要があります。デジタル庁の政府相互運用性フレームワーク（GIF）も、行政分野におけるデータ連携を目的に、データモデルや共通構造を整理することでシステム間の相互運用性を高める考え方を示しています。GIFは民間企業に適用を義務付けるものではありませんが、データの構造と意味を揃えることが、システム連携の基盤になるという原則は企業システムにも共通します。

図2：連携スパゲッティを避ける

「連携スパゲッティ」をつくらない

古いシステムを雑につなぐと、むしろ状況が悪化します。

• システムAとB。
• BとC。
• AとD。
• CとD。
• すべて別々の独自連携をつくる。

すると、

• どの担当者が何を管理しているか分からない。
• 同じデータ変換を何度も実装する。
• 認証情報が増える。
• 障害箇所が分からない。
• 一つのシステムを変更すると大量の連携に影響する。

という状態になります。Fluyentaでは、システム連携だけでなく、ワークフロー、データ管理、API管理、モニタリング、ガバナンスなどを共通の管理環境で扱う構成を採っています。重要なのは製品名ではなく、連携を一つ一つのスクリプトとして放置しないという設計思想です。

方法5：すべてをリアルタイムにしなくてもよい

「最新システムならリアルタイムであるべき」とは限りません。業務によっては、

• イベント通知、
• 一定時間ごとの同期、
• 夜間バッチ、
• ファイル連携

でも十分です。例えば、

• サプライヤー承認完了、
• 請求書計上、
• 設備異常、
• 社員登録、
• 出荷完了

などのイベントをきっかけに、必要な処理だけを動かす方法もあります。業務要件以上の複雑さをつくらないことが大切です。

方法6：外部向けポータルで基幹システムを守る

取引先や顧客へ古い社内システムを直接公開する必要はありません。例えば、

1. 1取引先
2. 2外部向けポータル
3. 3ワークフロー
4. 4内容確認
5. 5システム連携
6. 6ERP

という構成にできます。外部の利用者には現代的な画面を提供し、内部のERPは直接公開しない。という分離ができます。

方法7：新しい業務ロジックを段階的に外へ出す

長期的には、古いシステムへ新しい機能を追加し続けないという方針も重要です。例えば最初は、

• 顧客情報、
• 承認、
• 文書処理、
• 通知、
• レポート、
• サプライヤー業務

をすべて既存システム内で行っていたとします。段階的に、

• ポータル、
• ワークフロー、
• 通知、
• AI、
• 外部連携

などを外側へ移していきます。

図3：段階的モダナイゼーション

ここで重要なのは、連携は永続的な最終形にもなり得るし、全面刷新までの移行戦略にもなり得るということです。

つなぐべきか、入れ替えるべきか

一項目だけで判断するものではありません。経営・業務・ITが一緒に判断するための材料です。

つなぐべきではないケース

既存システムを残すこと自体が目的になってはいけません。例えば、

• ベンダーサポートが終了している。
• 重大なセキュリティ問題を解消できない。
• 保守できる人材がほとんどいない。
• 事業上必要な変更ができない。
• 安全なデータ連携方法が存在しない。
• 保守費用が合理的ではない。
• 性能・可用性が事業要件を満たさない。
• 重要なプログラムの内容を誰も把握していない。

という場合は、全面刷新を検討するべき可能性があります。

セキュリティは後付けにしない

連携を増やすということは、アクセス経路を増やすことでもあります。そのため、

• 認証、
• 権限、
• サービスアカウント、
• ネットワーク境界、
• シークレット管理、
• API権限、
• 暗号化、
• ログ、
• 監査、
• 必要最小限のデータ利用

を設計する必要があります。Fluyentaの公開プラットフォームでも、システム連携だけではなく、RBAC、監査、モニタリング、ガバナンスなどを共通の管理レイヤーとして扱っています。

APIがない既存システムはどうするか

珍しいことではありません。利用できる方法としては、

• 公式Webサービス、
• SOAP、
• データベース連携、
• メッセージキュー、
• ファイル連携、
• バッチ、
• 公式コネクタ、
• ゲートウェイ、

などがあります。最も重要なのは、安定していて、サポート可能な方法を優先することです。画面操作の自動化だけで無理につなぐ方法は、保守性を十分に考える必要があります。

連携後は監視が必要

システムをつなぐと、新しい障害パターンも生まれます。

• CRMは動いているがERPが止まっている。
• 認証トークンが切れた。
• 項目形式が変更された。
• ERP側で登録を拒否された。
• 同じ処理が二重送信された。

そこで、

• 障害をどう検知するか。
• 誰に知らせるか。
• 安全に再実行できるか。
• 二重処理を防げるか。
• 何が送信されたか確認できるか。

を考えます。「見えない連携」だからこそ、監視と責任者が必要です。

図4：連携障害時の処理

実務的な進め方

• まず業務課題を決めます。
• 次に関係するシステムを整理します。
• どのシステムがどのデータの正本なのかを決めます。
• 利用できるAPIや連携方法を確認します。
• 既存システムに残す業務と、外へ出す業務を分けます。
• 最初は小さな連携を構築します。
• 監視・権限・監査を加えます。
• 実際に業務が改善したか測定します。

その結果をもとに、

• 次の業務を連携するのか、
• さらに機能を外へ移すのか、
• それともコアシステム自体を刷新するのか

を判断します。

例：既存ERPを残して購買申請をモダナイズする

導入を検討するための構成例であり、Axtonが完了した顧客案件ではありません。

例えば既存ERPが、

• 取引先、
• 発注、
• 会計、
• 財務記録

を安定して管理しているとします。しかし購買申請はExcel＋メール。この場合、ERPを入れ替えるのではなく、

1. 1社員
2. 2Web申請
3. 3業務ルール
4. 4上長承認
5. 5調達・経理承認
6. 6システム連携
7. 7既存ERP
8. 8発注・記録
9. 9申請者へ結果通知

という形にできます。利用者の体験と承認業務をモダナイズしながら、ERPは信頼できる取引処理を続けます。FluyentaもSAPについて同様に、SAPへ到達する前の承認や検証を自動化し、周辺システムと連携しながらコアを残す方法を示しています。

例：既存の生産システムを顧客向けポータルへつなぐ

導入を検討するための構成例であり、Axtonが完了した顧客案件ではありません。

例えば、すぐには入れ替えられない生産データベースを持つ製造会社が、顧客へ受注・出荷状況を分かりやすく提供したい場合を考えます。生産システムを顧客へ直接公開する代わりに、次のようにつなぐ方法があります。

1. 1既存の生産システム
2. 2管理されたシステム連携
3. 3オーケストレーション・データレイヤー
4. 4顧客向けポータル

ポータルには、顧客が閲覧を許可された情報だけを表示し、生産システムは社内で管理します。将来、生産システムを刷新する場合も、ポータルが旧システムへ直接依存せず、連携レイヤーを通じて通信していれば、画面を大きく変えずに済む可能性があります。これが疎結合のメリットの一つです。

従来の進め方と、連携によるモダナイゼーション

右側の方法がどの企業にも必ず優れている、という意味ではありません。異なるアーキテクチャの選択肢を示す比較例です。

Axton Group × Fluyentaで考えるレガシーモダナイゼーション

Axton Group LTD Japanでは、Fluyentaとの提携を通じて、「どの古いシステムを入れ替えるか」ではなく、「現在のシステム構成によって、どの業務が困っているのか」から考えます。Axtonは、日本側での業務理解、関係者とのコミュニケーション、業務プロセス整理、顧客調整などを担います。Fluyentaは、20年以上のエンタープライズ業務自動化の経験を背景に、ワークフロー、システム連携、データ管理、API、ガバナンス、モニタリングなどの技術を提供します。

目的はレガシーシステムを永久に残すことではない

「今すぐ全部入れ替えない」という考え方は、「永遠に入れ替えない」という意味ではありません。連携によって、

• 移行までの時間を確保する。
• 業務を先に改善する。
• システム依存関係を理解する。
• データの責任を整理する。
• 移行リスクを下げる。

ことができます。その結果、既存コアを今後も使うべきと判断する場合もあります。逆に、十分な情報を得た上で全面刷新した方がよいと判断する場合もあります。

良いモダナイゼーションは「依存」を減らす

最終的には、

• 手入力への依存。
• 担当者個人への依存。
• 不明なインターフェースへの依存。
• 複雑なポイント・ツー・ポイント連携への依存。
• 一つのシステムを変更したら何が壊れるか分からない状態。

を減らしていくことが重要です。モダナイゼーションの成功を、「古いシステムを廃止したか」だけで測る必要はありません。より重要なのは、事業の変化に合わせて、システム・データ・業務を安全に変更できる状態になったか。です。全面刷新が必要な場合もあります。必要ない場合もあります。大切なのは、その違いを判断できることです。

よくあるご質問