既存システムは改修する？それとも刷新する？
長年使ってきたシステムで業務に支障が出始めると、「新しく作り直した方がよいのでは」と考えるかもしれません。しかし、古いという理由だけでは、問題の原因は分かりません。重要なのは、必要な業務に対応できているか、どこまで改修できるか、そして使い続けることでどのようなコストやリスクが生じるかを見極めることです。
例えば、ある企業では倉庫管理システムで入出庫を記録していたものの、拠点の増加に伴って別々の表計算ファイルを使うようになり、毎日データを照合しているとします。システムの刷新が必要な場合もありますが、複数倉庫への対応やデータ連携を追加すれば解決するかもしれません。判断するには、不足する機能を追加できるか、どの業務が現行システムに依存しているかを調べる必要があります。
本記事では、業務担当者や導入を判断する方に向けて、投資前に選択肢を比較するポイントを紹介します。上記は説明のための架空の例であり、Fenixの導入実績を示すものではありません。
1. 対応方法を決める前に、業務上の課題を整理する
「システムが古い」というだけでは、作り直す根拠として十分ではありません。先ほどの流通企業なら、拠点別の在庫が把握できない、集計に時間がかかる、在庫移動の権限を適切に管理できない、といった課題が考えられます。影響を受ける作業と発生頻度に加え、倉庫の追加、取引量の増加、取引先との連携など、今後必要になることも整理します。
そうすることで、業務上必要な変更と、単に画面を新しくしたいという希望を分けて考えられます。帳票の表示が遅い原因も、データ品質、検索処理、インフラ、システム外での手集計など、さまざまです。原因を把握しないまま全体を置き換えても、適切な解決につながるとは限りません。
業務側は改善したい作業を説明し、技術面は専門家が確認します。調査には、仕様書などの資料、ソフトウェアのバージョン、データ構造、連携先、稼働環境に関する情報、必要な権限がある場合はソースコードも使います。重要な情報が不足しているなら、確認できたことと、まだ判断できないことを分けて示す必要があります。
具体的な技術を選ぶ前に、まず解決すべき課題の認識をそろえましょう。日々の不便をどのように要件として整理するかは、次の記事で解説しています。
2. 部分改修から全面刷新まで、選択肢を検討する
課題が明確になっても、現状のまま使い続けるか、すべて置き換えるかの二択とは限りません。技術的な実現性と、変更が必要な業務の範囲に応じて、次の方法を検討できます。
問題のある部分を改修する
保守が継続されており、システムの構成も業務に適していて、課題が一部に限られるなら、その部分の改善や機能追加から始められます。倉庫管理であれば、安定している入出庫処理を残し、在庫帳票を改善する方法です。
ただし、画面上の変更量と、内部の修正範囲は同じではありません。小さな変更でもデータや関連機能に影響することがあるため、簡単に、あるいは安価に対応できると決めつけず、影響範囲を確認します。
全体を置き換えず、システム間を連携する
主要な機能は業務に合っていても、ほかのシステムとデータをやり取りできず、転記が発生している場合があります。その場合は、システムの仕様や利用条件を確認したうえで、補助ツールや連携機能の追加を検討できます。
連携には、データと業務ルールについて認識がそろっていることが欠かせません。倉庫コードが一致していなかったり、元データに誤りがあったりすれば、自動転送によってほかのシステムにも誤りが広がります。接続を依頼する前に、データの流れを明確にしておきましょう。
機能単位で段階的に置き換える
切り分ける範囲を明確にできるなら、一部の機能を先に置き換え、移行期間中は残りを使い続ける方法もあります。どちらのシステムでデータを管理するか、新旧をどう連携させるか、不整合があれば誰が対応するかを決めます。
段階的に変更できる一方で、同期や照合、新旧システムの並行稼働に伴う作業も増えます。メリットは具体的な分割方法によって変わるため、段階移行なら必ずリスクが小さいとはいえません。
別製品へ移行する、または再構築する
現行の基盤では重要な要件を満たせず、改修が難しい、あるいは投資として見合わない場合は、置き換えが適していることもあります。既製品の導入、個別開発、その組み合わせなどが候補です。
どの方法でも、必要な作業は新しいソフトウェアの開発だけではありません。データ移行、連携の再設定、利用者への説明も必要で、移行期間中は旧システムの一部機能を維持する場合もあります。
3. 同じ要件に照らして各案を比較する
各案を比べる際は、共通の必須要件を基準にします。倉庫管理であれば、部分改修でも全面刷新でも、複数拠点の管理や重要な例外処理に対応できるかを確認します。画面が新しくなっても、業務上の問題が残るなら目的は達成できません。
次に、導入後の保守や変更のしやすさを見ます。誰がサポートできるのか、資料は十分か、技術のサポートは継続しているか、変更がほかの機能にどこまで影響するのか。技術名だけで推測せず、調査結果に基づいて判断します。
データの流れや関連システムも比較対象です。直接の利用者が少なくても、複数の部門に情報を提供している場合があります。データの提供先、引き継ぐべき識別番号、照合に使う帳票を把握し、ほかの業務を意図せず止めないようにします。
費用と工数は、調査、開発、新旧システムの並行稼働、切替、その後の保守まで含めて比較しましょう。現行システムの改修費と新規開発費だけでは、予算や業務継続に影響する作業を見落としてしまいます。
各案を一行にまとめ、必須要件への対応、依存関係、確認が必要な費用、リスク、不足情報を並べると、違いを整理できます。ただし、重要な要件を満たせない案を、合計点の高さだけで選ぶことは避けましょう。
4. 判断材料が足りない部分を調査する
どのシステムのデータを正とするか不明、連携資料がない、複数の会社が保守を分担しているといった状況では、見積もりにも不確実性が残ります。全体への漠然とした結論を求めるより、「複数倉庫の管理機能を追加できるか」「連携部分を切り離せるか」「必要な形式でデータを出力できるか」と、確認したい問いを具体化します。
調査結果は、確認済みの事実、前提としていること、追加検証が必要な部分を分けて示します。そうすれば、提案の根拠と、判断前に確認すべき点が分かります。「効率化のために更新すべき」という説明だけでは、その判断材料にはなりません。
データが置き換えの可否を左右するなら、移行方法と移行後の確認まで調べる必要があります。ファイルを出力できるだけでは、新しいシステムで利用できる準備が整ったとはいえません。データの準備と検証は、次の記事で詳しく扱う予定です。
すべてのケースで長期間の調査が必要なわけではありません。判断が業務に与える影響と、本当に不足している情報に合わせて範囲を絞ります。調査量を増やしても、どの案を選ぶかという問いに答えられなければ、意思決定にはつながりません。
5. 次に検証することを決め、移行を計画する
先ほどの流通企業なら、試験環境で複数倉庫への対応を確認する、または一つの倉庫のサンプルデータを照合するといった進め方が考えられます。結果をもとに、現行システムの改修、機能の切り出し、刷新を検討できます。大規模な開発に着手する前に、不確かな点を減らすための検証です。
刷新する場合は、開発計画と合わせて稼働開始の計画も立てます。いつ新しい業務の進め方へ切り替えるか、旧システムのどの機能を残すか、利用者をどう支援するかを決めましょう。開発の最後に少し追加すればよい作業ではなく、別途計画して準備する必要があります。
適切な方法は、使用年数だけでは決まりません。改善したい業務、実現性を確認した改修方法、移行に必要な費用や体制をもとに判断します。開発パートナーに相談する際は、具体的な課題、既存資料、まだ分からない点を共有し、何から評価すべきかを一緒に整理しましょう。
