移行計画書に日程と作業一覧はある。担当者も決まった。それでも会議で「過去のデータは全部持っていくんですよね」と聞かれ、答えが止まる。計画を読んだ人が、それぞれ違う完成形を思い浮かべている状態です。
作業を細かく並べるだけでは、この食い違いは残ります。何を今回やらないのか。新しく分かったことは誰が判断するのか。着手前に合意したいのは、この二つです。
1. 「移行する」の中身を業務の言葉で分ける
まず、計画書の「データ移行」「切り替え」といった言葉を、業務で確認できる単位に分けます。何年分の受注履歴を移すか、添付書類も対象か、古い画面で見られた帳票を新しい画面でも出すか。発注する側は、普段その情報を使う担当者と一緒に確かめます。
同じ「履歴を移す」でも、検索できればよい人と、以前と同じ様式で印刷したい人では必要な作業が違います。「現行どおり」と書いても、その違いは解消しません。どの画面で何ができれば移行済みと判断するのかを書きます。
たとえば「直近3年の受注履歴を新システムで検索できる」は、対象と確認方法を合わせた書き方です。この年数は例であって、保存すべき期間の基準ではありません。実際の対象期間は、業務上の利用と保存に関する条件を確認して決めます。
2. 範囲外には、残したものの扱いも書く
次に、今回やらないことを独立した節に書きます。古い帳票の再現、重複した顧客情報の整理、社員への操作説明、旧システムを止める作業。対象に含めるかどうかを一つずつ確認し、含めないものを残します。
範囲外と書くのは、依頼を断るためではありません。担当が決まらない仕事を見つけるためです。開発会社が操作説明を担当しないなら、社内の誰が資料を用意し、いつ説明するのかまで決めないと、切り替え日に使い始められません。
「3年より前の履歴は移さない」だけでも不十分です。どこで閲覧するのか、誰が利用権限を管理するのか、いつまで旧システムを維持するのかを続けて書きます。対象外にした結果、別の維持費や担当者の作業が残ることがあります。不要と判断したのか、今回は見送ったのかも区別します。
3. 変更は、費用と日程を確認してから決める
範囲が変わったときの手順は、最初の作業が始まる前に決めます。追加の要望を誰が受け、誰が費用と日程への影響を調べ、誰が承認するのか。発注側と受注側の担当者名を入れ、どこに記録を残すかも指定します。
たとえば、移行の試行中に住所の不備が見つかり、修正まで頼みたくなったとします。担当者同士で「ついでにお願いします」と進めると、当初の作業か追加作業かが曖昧になります。元の合意と照らし合わせ、追加なら見積もりと切り替え日への影響を確認してから依頼します。
判断は、追加費用を払うかどうかだけではありません。別の作業を後に回す、切り替え日を動かす、今回は見送る選択もあります。計画書には回答期限と、期限までに決まらない場合に保留する作業を書きます。返事がないまま追加作業を始める前提にしないことです。合意済みの内容を満たしていない不具合と、新しい要望を同じ扱いにしない確認も必要です。
4. 切り替える条件と、延期を決める人を置く
本番への切り替えは、予定日が来たから実行するのではなく、確認できた結果を見て判断します。件数だけでなく、金額の合計や代表的な伝票を誰が照合するか、どんな差異なら作業を止めるかを計画書に書きます。合格とする条件は、試行の結果が出る前にそろえます。
ここが曖昧だと、開発会社は「移行処理が終わった」、業務側は「数字が合わないから終わっていない」と判断が分かれます。照合の記録を誰に渡し、誰が切り替えを認めるのかまで必要です。
延期する場合の連絡先と判断時刻も決めます。さらに、切り替え後に問題が見つかった場合、いつまでなら旧システムに戻せるのかを確認します。新旧の両方に取引が入った後は、単に元へ戻せるとは限りません。「問題があれば戻す」とだけ書かず、戻せない場合の業務の進め方も確認します。
5. 分からないことは、決める期限を付けて残す
現時点で決められない項目は、無理に範囲内にも範囲外にも入れず、「未決」として分けます。調べる人、必要な材料、決定期限、その判断を待つ作業を書けば、未決のまま全体が進むのを避けられます。
古い履歴の利用者が分からないなら、先に各部署へ用途を確認します。移せる状態か分からないなら、一部のデータで試す作業だけを先に依頼する方法もあります。その結果を見て、対象範囲と費用を決め直します。
最初から全画面の細かな説明をそろえる必要はありません。ただし、未決の項目が金額や切り替え日に影響するなら、その前提を伏せたまま全体を確定しないことです。計画書に残したいのは、分かっていることの多さより、まだ決めていないことと、その決め方です。
