レガシー刷新を成功に導く「現行システムの可視化」～ 900社近い取引先との連携を支えた、物流企業の取り組み～

レガシーシステムの刷新を検討する企業は、単に古いシステムを新しいものに置き換えるだけでなく、業務そのものを見直し、将来を見据えた新たな仕組みの構築を目指します。

特に、長年にわたって事業を支えてきたシステムには、取引先ごとの個別対応をはじめ、先人たちが築き上げてきた「自社らしさ」や業務ノウハウが詰まっています。こうした顧客固有の強みを失わず、将来に継承していくためには、将来のあるべき姿を描くだけでなく、現在のシステムが担っている役割や、そこに組み込まれた業務上のルールを正しく把握することが重要です。

今回は、900社近い取引先とのシステム連携を行っていた、ある物流企業の事例をもとに、レガシー刷新における「現行システムの可視化」の重要性を紹介します。

業務とシステムの将来を見据えた刷新の決断

この物流企業では、長年にわたり事業を支えてきたレガシーシステムを、新たなシステム基盤へ移行するプロジェクトが立ち上がりました。

現行システムには、業務を支えるさまざまな機能に加え、取引先ごとの連携仕様や個別対応が蓄積されていました。一方で、将来的な事業展開や業務効率化を見据えると、現行システムをそのまま使い続けるのではなく、業務プロセスを改めて整理したうえで、新たな環境へ移行する必要がありました。

そこで同社は、現在の業務やシステムを見直し、新しいシステムを構築する方針を決定しました。これは、現行システムの重要性や、解析・移行の難しさを十分に理解したうえで、将来に向けて新たな仕組みへ移行するという判断です。

同社の情報システム部門には、現行のCOBOLプログラムを理解し、解析できるメンバーも在籍していました。しかし、業務仕様や取引先ごとの個別対応を正確に整理するには、レガシーシステムだけでなく、物流業務や企業間連携に関する専門的な知見が必要でした。そこで同社は、レガシーシステムと物流業務の双方に精通した外部パートナーの活用を検討しました。

レガシーと物流の両方を理解するパートナーを選定

レガシー刷新においては、システムがどのような業務を支えているのか、取引先との間でどのようなデータがやり取りされているのか、現場ではどのような例外処理が行われているのかを、業務の観点から理解する必要があります。

同社がパートナー選定で重視したのは、次のような点でした。

• COBOLなどのレガシーシステムを解析できること
• 既存システムから仕様や業務ルールを抽出できること
• 物流業務や企業間連携に関する知見があること
• 大量のインターフェイスや個別仕様を整理できること
• 社内の情報システム部門と協力してプロジェクトを進められること

これらの条件を踏まえ、同社はレガシーシステムと物流業務の双方に強みを持つパートナーとして、システムズを選定しました。

900社近い取引先とのインターフェイスを整理

プロジェクトで大きな課題となったのが、900社近い取引先とのインターフェイスでした。

取引先ごとに、連携方式やデータ形式、連携のタイミング、授受する項目などが異なります。さらに、長年の取引の中で、特定の取引先だけに適用される個別仕様や例外処理も存在していました。
具体的には、次のような情報を整理する必要があります。

• どの取引先とシステム連携を行っているか
• EDI、ファイル連携、APIなど、どの接続方式を利用しているか
• CSV、固定長、XMLなど、どのデータ形式を使用しているか
• リアルタイム、日次、月次など、いつデータを連携しているか
• 取引先ごとにどの項目を授受しているか
• 個別の変換ルールや締め時間が設定されていないか
• エラー発生時にどのような処理を行っているか

こうした情報は、必ずしも最新の設計書や業務マニュアルに整理されているとは限りません。
実際には、ソースコードや設定情報、データ定義、ジョブ、ログなどに、取引先ごとの仕様や業務上のルールが残されていることがあります。

そこで、現行システムを解析し、プログラムや設定情報などからインターフェイスの仕様を抽出しました。そのうえで、情報システム部門や関係部門へのヒアリングを行い、システム上の情報と実際の業務運用を照合していきました。

現場が日常的に利用している機能を確認

刷新プロジェクトでは、将来の業務プロセスや新システムの要件を検討することが中心になります。
しかし、現場にとっては、現在のシステムで日常的に利用している機能が、新システムでも必要になる場合があります。
例えば、次のような機能です。

• 入力内容を自動的にチェックする機能
• 特定の条件に応じて項目を自動補完する機能
• 業務上のルールに基づいて計算する機能
• 特定の取引先向けにデータを変換する機能
• エラーを防止するための確認処理
• 日次・月次・期末に自動実行されるバッチ処理
• 特定の帳票やデータを作成する処理

これらは、現場にとっては「毎日使っている当たり前の機能」であるため、要件定義の場で改めて説明されないこともあります。
一方で、新システムをゼロベースで検討する場合、そのような機能が要件として明示されないまま、設計の対象から漏れてしまう可能性があります。

現行システムの画面、帳票、バッチ、プログラム、設定情報などを確認することで、こうした機能をあらかじめ一覧化し、新システムでの扱いを検討できるようになります。

「仕様書にない仕様」を明らかにする

長年運用されてきたシステムには、正式な仕様書だけでは把握しきれない情報が含まれています。
例えば、次のようなものです。

• ソースコードやコメントにだけ残っている業務ルール
• 特定の担当者や運用部門が把握している暫定対応
• 特定の取引先にだけ適用される例外処理
• 過去のトラブル対応として追加されたチェック
• システム間のデータ連携を成立させるための変換処理
• マニュアルには記載されていない運用上の工夫

これらは、単純なヒアリングだけではすべてを洗い出すことが難しい領域です。システムのソースコードや設定、ログなどを解析し、そこで確認できた情報を関係者へのヒアリングと突き合わせることで、仕様書だけでは見えにくい業務ルールや例外処理を整理できます。

可視化によって、早い段階で判断できる

現行システムを可視化することで、刷新プロジェクトの初期段階から、より具体的な判断ができるようになります。
例えば、次のような判断です。

• 900社近い取引先とのインターフェイス対応を、計画や見積もりに反映する
• 取引先ごとの個別仕様を、要件定義の確認項目として扱う
• 現行システムに存在する機能を、新システムへ移行するか判断する
• 廃止できる機能と、継続が必要な機能を整理する
• 追加開発やデータ移行に必要な工数を見積もる
• 予算やスケジュールを現実的な水準に調整する

重要なのは、現行システムをそのまま新システムへ移行することではありません。
現行システムが何をしているのかを事実として把握したうえで、残すもの、変えるもの、廃止するものを判断することです。

「業務起点」と「現行システムの把握」は両立できる

レガシー刷新では、「現行踏襲ではなく、業務を起点に新しい仕組みを考えたい」という考え方が重視されます。これは非常に重要なアプローチです。
ただし、業務起点で考えることと、現行システムを確認しないことは、同じ意味ではありません。

業務をゼロベースで見直す場合でも、現在のシステムがどのような業務を支えているのかを把握しておかなければ、意図せず必要な機能を失ってしまう可能性があります。

また、現行システムには、長年の運用の中で蓄積された業務上の工夫や、取引先との関係性を維持するための仕組みが含まれていることがあります。それらを確認したうえで、新しい業務プロセスに合わせて見直すことが、より安全で現実的な刷新につながります。

レガシー刷新の第一歩は、現状と将来像を正しく知ること

パッケージ導入、新規開発、モダナイゼーションなど、刷新の方法はさまざまです。どの方法を選ぶ場合でも、次の2つを明らかにすることが重要です。

• 将来、どのような業務やシステムを実現したいのか
• 現在、どのような機能や仕組みが動いているのか

この両方が揃って初めて、現実的な移行計画やコスト、スケジュールを検討できます。
今回の物流企業の事例では、同社がレガシーシステムの重要性と刷新の難しさを理解したうえで、将来に向けた大きな決断を行いました。

一方で、社内の限られたリソースだけで900社近い取引先との連携や既存仕様を整理することは容易ではありませんでした。そこで、社内の知見と外部パートナーの専門性を組み合わせ、レガシー解析と物流業務の両面から現行システムを可視化しました。

このように、刷新を成功させるためには、現行システムを否定するのではなく、これまで業務を支えてきた仕組みを正しく理解し、そのうえで将来のあるべき姿を描くことが大切です。

私たちシステムズは、これまで他社が構築したレガシーシステムの解析や仕様抽出に加え、物流業務や企業間連携を含めたシステム刷新を支援してきました。「現行システムを残すのか、変えるのか、廃止するのか」を判断する前に、まずは「現行システムが何をしているのか」を明らかにする。その最初の一歩から、私たちがご支援します。