システム移行の計画はどう立てるか｜一度に全部変えず、切り戻せる段階に分ける理由

古いシステムを新しい環境へ移すとき、「どうせ手を入れるなら、全部まとめて新しくしたい」と考えるのは自然なことです。費用も期間も一度で済みそうに見えます。それでもFUNBREWは、移行は必ずステップを踏むことを何より大事にしています。この記事では、移行計画で何を最初に決めているのか、どんな順番で進めるのか、そしてなぜ段階に分けるのかを書きます。移行全体のチェック項目はシステム移行のスケジュール目安と注意点にまとめていますので、ここでは計画の考え方に絞ります。

システム移行の計画で、最初に何を決めるのか

最初に決めるのは、この段階で何を変えて、何を変えないかです。移行計画とは、変更をいくつかの段階に分け、その順番を決めることだと考えています。

移行の相談で多い状態

移行の相談を受けるシステムは、多くの場合、次の状態が重なっています。

• システム自体が古い（フレームワークや言語のバージョンが古い）
• サーバーも古い（OSやミドルウェアが古く、そのままでは新しいバージョンが動かない）
• データも古い（構造が今の形に合っておらず、マイグレーションが必要）

この3つが重なっていると、全部を一度に新しくしたくなります。しかし、3つを同時に変えると、問題が起きたときに原因がどれなのか分からなくなります。フレームワークの変更のせいなのか、サーバーの違いなのか、データの移し方なのか。切り分けに時間がかかり、元に戻すにも全部を戻すしかなくなります。

改修は移行に混ぜない

もうひとつ決めておくのは、移行の段階では機能の改修をしないということです。移行のついでに画面や仕様も直したくなりますが、改修を混ぜると「移行で壊れたのか、改修で変わったのか」が区別できなくなります。まずは今と同じ動きのまま、土台だけを新しくします。

どんな順番で移行するのか

FUNBREWの基本は、フレームワークのバージョンアップ、次にサーバーと、一段ずつ今の環境に追いつかせていく進め方です。

データのマイグレーションも、同じようにほかの変更と混ぜずに独立した段階として扱います。データの移し方を確かめる作業はデータ移行のリハーサルは実際に何をしているのかに書きました。

この順番にしているのは、確実にキャッチアップさせていくことが何より大事だと考えているからです。一段ずつなら、それぞれの段階で「今までと同じように動いている」ことを確かめてから次へ進めます。

なぜ一度に変えず、段階に分けるのか

理由の中心は、開発会社はお客さんの業務を最初は完璧には理解していないということです。

開発会社にとって、お客さんの業務は初めて触れるもの

移行を担当する開発会社は、そのシステムを使った業務に初めて触れます。ヒアリングをしても資料を読んでも、お客さんの業務フローを完璧に理解している状態から始まることは、ほとんどありません。画面の裏で何に使われているのか、月に一度だけ使う機能はどれか、といったことは、動かしてみて初めて分かることがあります。

業務を理解しきれていない状態で全部を一度に変えると、想定していなかった使われ方が、移行後にまとめて表に出てきます。段階に分けておけば、出てきた問題はその段階で変えたものの中にあると分かります。

トラブルが起きても、すぐ切り戻せるようにする

段階に分けるもうひとつの理由は、トラブルがあってもすぐに切り戻しができることです。切り戻しとは、移行した変更を取り消して、直前の動いていた状態に戻すことです。一度に全部を変えていると、戻る先は「移行前の古い状態」しかありません。段階ごとに区切っていれば、戻る先は「ひとつ前の段階」で済みます。

移行の「セーブポイント」を増やすという考え方

FUNBREWが移行計画を立てるときに持っているのは、セーブポイントを増やしていくイメージです。ゲームでこまめにセーブしておけば、失敗してもそこからやり直せます。移行も同じで、各段階の終わりが、次の段階で何かあったときに戻れる地点になります。

段階に分けると、全体の期間は一括より長く見えるかもしれません。それでも、移行で怖いのは期間の長さより、業務が止まって戻れなくなることです。こまめなセーブポイントは、そのための保険です。

並行運用との関係

新旧を同時に動かす並行運用も、戻れる状態を保つ方法のひとつです。ただし並行運用には、旧システムでもデータが増え続け、開発が二重になるというコストがあります。並行運用にするかどうかはコストと比べて決めています。詳しくは新旧システムの並行運用は何が大変かをご覧ください。

まとめ

システム移行の計画で最初に決めるのは、一度に何を変えないかです。システム・サーバー・データが同時に古くなっていても、全部を一度に変えると原因の切り分けも切り戻しも難しくなります。

FUNBREWは、まず改修をせずにフレームワークのバージョンアップだけ、その次にサーバー、と段階を踏んで移行します。開発会社は最初からお客さんの業務フローを完璧には理解していないため、各段階の終わりを、トラブル時にすぐ戻れるセーブポイントにしています。

古いシステムをそもそも直すべきか作り直すべきかの判断はシステムを直すより作り直した方が早いと言われるのはなぜかに、他社が作ったシステムを引き継ぐ場合は他社開発システムの保守引き継ぎに書いています。移行の進め方のご相談はお問い合わせよりどうぞ。