レガシーシステムを、
止めずに移行する進め方

長く使ってきた業務システムほど、「仕様が分からない」「作った人がいない」「止められない」という悩みを抱えがちです。一度にすべてを作り直そうとすると、時間もリスクも大きくなります。この記事では、業務を止めずに段階的に移行するための進め方を、5つのステップと図解でご紹介します。

なぜ、レガシーシステムの移行は止まりやすいのか

長く使ってきた業務システムには、その会社の業務の工夫が積み重なっています。一方で、年月がたつほど、作った人が異動や退職でいなくなり、仕様書も実際の動きと合わなくなっていきます。「どこを触ると何が起きるか分からない」状態になると、改修も移行も手を付けにくくなります。

さらに、業務システムは止められないことがほとんどです。止められないから触れない、触れないからさらに分からなくなる、という悪循環に陥りがちです。そこで有効なのが、一度にすべてを入れ替えるのではなく、確かめながら少しずつ移していく進め方です。

この記事では、業務を止めずに段階的に移行するための進め方を、5つのステップでご紹介します。

移行を始める前に確認したいこと

最初に、今のシステムがどう使われているかを把握します。ここを飛ばすと、移す順番を決められず、移行の範囲も膨らみがちです。次の項目を、業務の担当者と一緒に確かめておきましょう。

• 毎日使われている機能と、ほとんど使われていない機能

  使われていない機能は、移さずにやめるという選択肢もあります。移行は、機能を整理するよい機会です。

• 止まったときに、業務への影響が大きい部分

  影響が大きい部分ほど、移行の後半に回し、進め方が固まってから取りかかります。

• 外部のシステムやファイルとのやりとり

  取引先とのデータのやりとりや、ほかのシステムとの連携は、見落とすと切り替え後に大きな問題になります。

• 移行の期限や、動かせない制約

  年度の切り替えや法令への対応など、動かせない日程があれば、そこから逆算して計画します。

移行計画の立て方

移行の計画は、最初から細部まで決めきる必要はありません。最初に決めておきたいのは、次の3つです。

• ゴール：移行が終わった状態を、業務の言葉で決める（例：今の画面で行っている業務が、新しい環境でも同じように回る）
• 順番：どの機能のまとまりから移すかと、その理由
• 確かめ方：移した機能が正しいことを、何をもって確かめるか

期間は、ステップ1の仕様の見える化が終わった時点で見積もるのが現実的です。仕様が見えていない段階での見積もりは、どうしても大きくぶれてしまいます。まずは見える化に取り組み、その結果をもとに全体の計画を立て直す、という二段構えで進めると、無理のない計画になります。

移行を進める体制

移行は、開発の担当者だけでは進められません。業務を知っている人の協力が欠かせないため、最初に役割を決めておきます。

業務の担当者は、日々の仕事と並行して移行に関わることになります。確認をお願いする量とタイミングを、あらかじめ相談しておくとよいでしょう。

ステップ1：今の仕様を見える化する

まずは既存のコードやデータを解析し、何がどう動いているかを整理します。生成AIを使えば、古いコードの読み解きや、処理の流れの洗い出しを短い時間で進められます。画面ごとの役割、データの項目、計算のルールなどを、読める形の資料にまとめていきます。

ただし、コードから分かるのは「どう動いているか」までです。「なぜそうなっているのか」「今もその動きが必要か」は、業務を知っている人に確かめる必要があります。AIがまとめた内容をもとに、業務の担当者と人が確認しながら、仕様として残します。

ステップ2：移す順番を設計する

すべてを一度に移すのではなく、機能のまとまりごとに順番を決めます。基本は、影響の小さいところから始めて、進め方と確かめ方を固めてから、業務の中心となる機能へ進むことです。

順番を決めるときは、機能どうしのつながりにも注意します。たとえば、受注と在庫のようにデータを共有している機能は、片方だけを先に移すと、新旧のシステムの間でデータをやりとりする仕組みが必要になります。どこで区切るのがいちばん安全かを、人が設計します。

ステップ3：まとまりごとに新しい環境へ移す

決めた順番に沿って、新しい環境へ機能を移していきます。そのまま引き継ぐべき部分と、この機会に見直す部分を分けて考えることで、移行の範囲が膨らみすぎるのを防ぎます。

見直したい点が見つかっても、移行の途中ではまず「今と同じ動き」を優先し、改善は移行後に回すのが安全です。移行と改善を同時に進めると、問題が起きたときに原因を切り分けにくくなるためです。

ステップ4：新旧の結果を比べて確かめる

移した機能が正しく動いているかは、同じ入力に対して、新しいシステムが今と同じ結果を返すかで確かめます。計算結果や帳票の内容、画面に表示される値などを比べます。

比べる作業を自動テストにしておくと、移行の途中で変更を加えても、すぐに確かめ直せます。違いが見つかったときは、新しいシステムの誤りなのか、今のシステムに隠れていた不具合なのかを人が判断します。

ステップ5：段階的に切り替え、育て続ける

確かめた機能から、順に切り替えていきます。切り替え方にはいくつかの選択肢があり、システムの性質や業務の状況に合わせて選びます。

どの方法でも、問題があれば元に戻せる手順を用意しておくことが大切です。移行が終わったら、そこからは改善を続けられるシステムとして育てていきます。

よくあるつまずきと対策

どれも、最初に仕様を見える化し、確かめながら少しずつ進めることで防ぎやすくなります。

EVOLOOPでの進め方

EVOLOOPのレガシー移行では、AIが既存のコードとデータを解析して今の仕様を見える化し、人が業務への影響を見ながら移行の順番を設計します。機能のまとまりごとに新しい環境へ移し、新旧の結果を比べて確かめたうえで、段階的に切り替えます。

解析した仕様や変更の記録はドキュメントとして残るため、移行が終わったあとも、同じ体制のまま改善を続けられます。

よくある質問

まとめ