新しいシステムを作ること自体より、今動いているものからの乗り換えが難しい、
というのは珍しくありません。段取りを整理します。
最初に決める3つ
1. どこまでのデータを移すか
・現在有効な顧客・案件のみ
・過去3年分
・全期間
全期間を移すと費用が跳ね上がります。
古いデータは参照用に旧システムを残す、という判断も有効です。
2. 切り替えの方式
| 方式 | 内容 | 向いている場合 |
|---|---|---|
| 一斉切替 | ある日を境に全面移行 | 規模が小さい、業務が単純 |
| 並行運用 | 一定期間、両方を動かす | 止められない業務 |
| 段階移行 | 機能・部署ごとに順次 | 規模が大きい |
並行運用は安全ですが、二重入力の負担が発生します。
期間を区切ることが重要です。
3. 戻せる状態を作っておくか
切り替えて問題が起きたとき、旧システムに戻せるか。
戻せるようにするには、移行後も旧システムを稼働させておく必要があります。
データが汚れている前提で進める
実データを見ると、ほぼ必ず次が出てきます。
- 表記ゆれ（「株式会社○○」「(株)○○」「○○」）
- 必須のはずの項目が空
- テストデータの混入
- 重複登録
- 使われていないはずの区分値
これは失敗ではなく、長く使われたシステムでは普通のことです。
問題は、これを移行の直前に発見することです。
実データのサンプルを早く渡す
開発の初期段階で、実際のデータを（可能なら匿名化して）渡すと、
移行の難易度が正確に見積もれます。
「仕様書ではこうなっているが、実データはこうなっている」
というズレが、早い段階で分かります。
移行のリハーサルをする
本番切替の前に、本番と同じ手順で試します。
1. 本番データのコピーを用意
2. 移行スクリプトを流す
3. 件数と金額の突合
4. 現場の担当者が実際に触って確認
5. かかった時間を計測 ← 切替当日の計画に使う
リハーサルで初めて分かることが必ずあります。
最低2回は実施することをおすすめします。
突合の基準を決める
・件数が一致すること
・金額の合計が一致すること
・特定の10件を目視で確認
「なんとなく移った」ではなく、数字で確認します。
差分が出た場合の許容範囲も決めておきます（例：意図的に除外した分のみ）。
切替当日の段取り
金曜 18:00 旧システムの入力停止
18:30 最終データの抽出
19:00 移行スクリプト実行
21:00 突合・確認
22:00 判断（GO / 切り戻し）
月曜 9:00 新システムで業務開始
判断の時刻と、切り戻しの基準を先に決めておくのが重要です。
当日に「もう少し様子を見よう」と粘ると、朝までかかります。
切替後にやること
- 旧システムを一定期間は残す（参照用）
- 現場からの問い合わせ窓口を明確にする
- 最初の1週間は毎日、数字を確認する
発注側で準備できること
| 準備 | 効果 |
|---|---|
| 実データのサンプルを早く渡す | 見積もり精度が上がる |
| 移行範囲を決める | 費用を抑えられる |
| 突合の基準を決める | 判断が速くなる |
| リハーサルに現場が参加する | 当日の混乱が減る |
| 切り戻しの基準を決める | 判断で迷わない |
まとめ
- 移行範囲・切替方式・戻せるかどうかを最初に決める
- 実データは汚れている前提で、早めにサンプルを渡す
- リハーサルを最低2回。時間を計測して当日の計画に使う
- 突合は数字で。件数と金額の一致を基準にする
- 切替当日の判断時刻と切り戻し基準を事前に決める