システムの​リプレイス​（刷新）は「今と同じ」を書き出すところから4つの​やり方と​進め方

株式会社bundlyze​（バンドライズ）は、​大阪市北区​（グラングリーン大阪）の会社です。​業務システムの​開発と​既存システムの​改修、​LINE公式アカウントとの​連携を​受託しています。

「保守の期限が​来るので、​システムを​入れ替えたい」。
「作った人が​辞めて、​直せる​人が​いない」。
リプレイスの​相談は、​たいていどちらかの​事情から​始まります。

この​記事は、​業務システムを​入れ替える​計画の​立て方に​絞って​書きます。
データの​移し方の​細かいところは業務システムを​入れ替えるときの​データ移行に、​社内の​サーバーを​クラウドへ​移すときの​手順と​費用は社内の​システムと​サーバーを​クラウドへ​移す進め方に、​出来合いの​サービスに​するか​作るかの​判断はSaaSか、​オーダーメイドかに​まとめています。

システムの​リプレイスとは？​刷新・​マイグレーションとの​違い

リプレイスは、​今​使っている​業務システムを、​新しい​システムに​置き換えることです。
刷新、​再構築とも​呼ばれ、​言葉の​使い方は​会社や​本に​よって​違います。
IPAの​ガイドも、​手法の​名前の​定義は​企業や​書籍に​よって​異なると​断ったうえで、​自分たちの​分け方を​示しています​（IPA：システム再構築を​成功に​導く​ユーザガイド 第2版​（PDF）の​1章の​注意点、​2026年10月30日確認）。
この​記事では、​次の​意味で​使います。

言葉の​違いより​大事なのは、​自社の​話が​どれに​当たるかを、​頼む前に​自分の​言葉で​書いておくことです。
「刷新したい」の中身が、​機械を​替えたいのか、​画面を​使いやすく​したいのか、​業務の​やり方ごと​変えたいのかで、​この​あとの​話が​まるで​変わります。

リプレイスの​やり方は​4つ、​何を​変えるかで​決まる

IPAの​ガイドは、​今の​システムの​どの​段の​設計を​残すかで、​やり方を​4つに​分けています。
業務の​仕様、​動く​土台​（基盤）、​プログラムの​言語の​3つを、​変えるか​変えないかで​選びます​（IPA：システム再構築を​成功に​導く​ユーザガイド 第2版​（PDF）の​「再構築手法選択基本パターン」、​2026年10月30日確認）。

同じ​ガイドは、​リビルドは​保守の​しやすさや​業務への​合わせやすさを、​リホストや​リライトより​高められる​一方で、​費用と、​業務を​よく​知る​人が​関わる​度合いが​より​大きくなる、としています。
リホストと​リライトは、​今の​資産を​使うので​業務の​動きは​再現しやすいが、​保守の​しやすさは​今と​同じ、​とも​書いています。

この​ほかに、​業務に​合う出来合いの​製品​（パッケージやSaaS）に乗り換える​道も​あります。
ガイドも、​パッケージ製品を​使う​場合は、​計画で​決めることの​時期と​中身が​違うとして、​別に​章を​立てています。

1つの​システムを​1つの​やり方で​決めつけないほうが​よい、と​私は​考えています。
ガイドも、​同じ​システムでも​業務や​部分ごとに​合うやり方は​違うことが​あり、​複数を​候補に​してよい、としています。
画面の​入力は​リビルドで​使いやすくし、​夜中に​動く​集計の​処理は​リホストで​今のまま​動かす、といった​分け方です。

いちばん​揉めやすいのは​「今と同じで」という頼み方

リプレイスで​多い​頼み方が​「機能は今と​同じで」です。
IPAの​ガイドは、​この​「現行踏襲」の「現行」が何を​指すかで、​頼む側と​作る​側に​ずれが​生まれやすいと​指摘しています。
頼む側は、​今動いている​システムが​そのまま​引き継がれることを​期待します。
作る​側は、​作るために​「今と同じ」を文字に​する​必要が​あるので、​設計書や​プログラムに​書かれている​中身を​拠り所にします​（前に挙げた​ガイドの​「現行踏襲に関する​問題」）。

長く​使った​システムでは、​この​2つが​合っていないことが​よく​あります。
ガイドは、​仕様を​変えたときに​関わる​業務の​資料を​直し忘れた、​障害の​対応で​プログラムだけを​直して​資料は​直さなかった、といった​例を​挙げ、​資料と​プログラムと​動いている​システムの​間に​ずれが​生まれる、としています。

そのため、​ガイドは、​企画の​段階で、​機能と​機能以外のことの​両方に​ついて、​今から​変えるのか​変えないのかを​はっきりさせ、​その​結果を​提案の​依頼書​（RFP）やシステム化の​計画に​書くよう​勧めています。
はっきりさせられない​部分が​残るときは、​その​部分が​あることと、​要件定義の​段階で​どう​決めるかを、​依頼書に​書いておくことが​大事だ、としています。

書き出すときは、​次の​表を​使うと​抜けが​減ります。

「今と同じで​いい所」と「今のうちに​変えたい所」を分けて​書くだけで、​見積もりの​前提が​そろいます。
要件の​決め方​そのものは要件定義とはに​まとめています。

システムリプレイスの​進め方は？​6つの​段に​分ける

私は、​次の​6つの​段で​考えます。
IPAの​ガイドの​手法の​選び方も、​今の​システムの​調べと、​新しい​システムに​求めることの​整理を​先に​して、​その​あとで​やり方の​候補を​選ぶ順に​なっています。

1. 今の​システムを​調べる：前の​表を​埋める。​資料、​プログラム、​契約の​名義、​保守の​期限を​集める
2. 目的と​求めることを​書く：な​ぜ​今​入れ替えるのか​（期限、​直せる​人が​いない、​業務が​変わった）と、​変えないこと・変えたいこと
3. やり方を​選ぶ：​4つの​やり方と​パッケージ・SaaSから、​部分ごとに​候補を​選ぶ
4. 見積もりと​契約：同じ​前提の​書面で​見積もりを​取り、​作業の​範囲と​契約の​形を​決める
5. データの​移行と​並行稼働：何を​移すかを​決め、​新旧を​並べて​動かして​結果を​比べる
6. 切り替えと​片づけ：戻す手順を​用意してから​切り替え、​業務の​山を​1回越えてから​古い​システムを​止める

段の​1と​2を​飛ばして、​いきなり​見積もりを​取りに​いくと、​会社ごとに​前提が​違う​見積もりが​並び、​比べられなくなります。
見積もりの​読み方は業務システムの​見積もりの​読み方に、​請負と​準委任の​違いはシステム開発の​契約は​「請負」か「準委任」かに​書きました。

段の​5は、​思っているより​手間が​かかります。
画面を​作る​仕事とは​別に​数えておかないと、​使い​始める​日の​朝に、​今日までの​データが​入っていない、ということが​起きます。

リプレイスの​費用は​何で​変わる？

リプレイスの​費用は、​同じ​「入れ替え」でも、​何を​どこまで​変えるかで​大きく​変わります。
私が​見積もりの​前に​確かめるのは、​次の​6つです。

入れ替えた​あとに​毎月かかる​費用も、​作る​費用とは​別に​並べます。
保守の​契約で​決めることはシステムの​保守契約で​確かめることに、​毎月の​費用の​下げ方は業務システムの​運用コストを​下げるに​まとめています。
bundlyzeが​受け持つ​場合の​金額は、​今の​システムを​調べた​結果を​見てからの​お見積もりです。

リプレイスが​失敗しやすいのは​どんなとき？

IPAの​ガイドの​紹介ページは、​再構築で​失敗や​トラブルが​起きる​大きな​原因として、​今の​システムの​仕様が​時間とともに​あいまいに​なったまま、​それを​もとに​新しい​システムの​開発を​始めてしまうことを​挙げています​（IPA：システム再構築を​成功に​導く​ユーザガイド 第2版、​2026年10月30日確認）。
ガイドの​本文も、​長い​保守の​あいだに​業務の​知識が​細かく​分かれ、​ばらばらに​なった​状態のまま​進めると、​工期・費用・品質の​トラブルに​つながる、としています。
ずれは​頼む側と​作る​側の​間だけでなく、​頼む側の​社内でも、​システムの​担当と​実際に​使う​部署の​間で​起きることが​ある、​とも​書いています。

私が​危ないと​考えるのは、​次のようなときです。

• 「今と同じ」の中身を、​誰も​書き出していない
• 今の​システムを​いちばんよく​知る​人が、​計画に​関われない
• データの​移行が、​見積もりにも​日程にも​入っていない
• 入れ替えの​機会に、​業務の​やり方も​大きく​変えようとしているのに、​その​分の​時間を​見ていない
• 古い​システムを、​切り替えの​直後に​止める​予定に​なっている

IPAの​ガイドも、​入れ替えと​同時に​業務の​要件を​変えたり足したりすると、​今と​同じに​する​部分と​変えた​部分との​整合を​取るのが​難しくなり、​品質を​保つ​難しさが​非常に​高くなる、としています。
変えることを​1つずつ​決めてから​進めるほうが、​結果として​早く​終わると​私は​考えています。

作った​会社と​連絡が​取れない・資料が​ないときは

古い​システムで​よく​あるのが、​作った​会社と​連絡が​取れない、​設計書が​見つからない、という​状態です。
この​場合は、​入れ替えの​計画より​先に、​今の​システムの​中身と、​契約や​サーバーの​名義を​取り戻す作業が​要ります。
最初に​やることはシステムを​作った​会社と​連絡が​取れないときに​書きました。

資料が​なくても、​入れ替えは​できます。
ただ、​今の​動きを​画面と​データから​調べ直す​作業が​増えるので、​その​分の​時間と​費用を​最初の​計画に​入れておきます。

私が​リプレイスの​相談で​最初に​聞くこと

bundlyzeは​業務システムを​受託で​開発していて、​受託で​培った​技術で​自社の​サービスも​開発し、​運用しています。
2026年9月には、​自社の​ドメイン​（wwwの付かない​ bundlyze.co.jp）の配信先を​別の​サービスへ​移しました。
システムの​入れ替えではありませんが、​切り替える​前に、​書き換える​値と​触らない​値を​全部​書き出し、​元に​戻す手順を​先に​書いてから​切り替えました。
そのときの​手順はSSL証明書の​期限切れ。
切れたときの​直し方と、​自動で​更新される​仕組みへの​移し方に​書いています。
入れ替えの​作業​そのものより、​何が​今どうなっているかを​書き出す準備のほうに​時間が​かかる、というのが、​そのときの​実感です。

リプレイスの​相談で​私が​最初に​聞くのは、​なぜ​今​入れ替えるのか、と、​入れ替えた​あとも​絶対に​変えてはいけないものは​何か、の​2つです。
前者で、​期限から​逆算した​日程と、​やり方の​候補が​決まります。
後者で、「今と同じ」にする​範囲が​決まり、​それ以外は​変えて​よい​所として​話を​進められます。

bundlyzeは​大阪市北区の​グラングリーン大阪を​拠点に、​業務システムの​開発と、​今の​システムからの​入れ替え・​データの​移行を​受け持っています。
全国から​ご相談いただけます。
打ち合わせは​Web会議でも、​対面でも​可能です。
この​記事を​書いた​津嘉山は、​業務システム開発と​AWSを​専門と​する​エンジニアで、​業務システムの​要件定義から​開発、​保守運用までを​経験しています。

入れ替えの​予定が​まだ先でも、​今の​システムで​「これだけは変えられない」ものを1枚に​書き出しておくと、​いざ計画を​立てるときの​最初の​材料に​なります。