完成したシステムへ、なぜ業務を移せないのか

開発側は、実装済み項目の数を数えます。利用側が必要なのは、一件の仕事を入口から出口まで終えられることです。ここで完成の物差しがずれていました。

業務基盤では、コードに入った状態、本番で動くと確認した状態、実際の条件で現場が受け入れた状態を分けています。分けると数字は厳しく見えます。しかし「本番にあるから使えるはず」という推測で移行を進めるより、残った仕事が見えます。

利用者受入テストでは、「使いやすいですか」と聞くより、実際の一件を通します。通常の登録だけでなく、差戻し、重複、担当変更、締め処理、通信断、復旧まで追います。

日本の中小企業でよく起きるのは、SaaSを導入してもExcelの集計が残り、最後はLINEや電話で補足しないと進まない状態です。そこに必要な情報や承認が埋まっているなら、画面の機能追加だけでは仕事は移りません。

新旧を一定期間並べると、結果を比較し、戻る余地を持てます。ただし終了条件がなければ、二重入力が新しい標準になります。数字が違ったときにどちらを正しいとするかも曖昧になります。

並行期間には、何件を比較するか、どの差を許さないか、誰が最終判定するか、いつ旧運用を止めるかを置きます。期限だけで切るのではなく、観測した証拠で切り替えます。

会社全体の正本を同時に変える必要がある処理では、一括切替が適する場合があります。一方、部署や業務単位で独立し、戻せるなら、限定した範囲から移す方が学びやすくなります。

完成したかを聞くときは、機能数ではなく「明日から、旧い方法を使わずに誰がどの仕事を終えられるか」と聞く。その答えに例外、復旧、引継ぎまで入ったとき、Software completionがBusiness completionへ近づきます。

新しいシステムは、画面を開ければ使えるように見えます。実際の業務では、前の人から情報を受け取り、例外を判断し、次の人へ渡し、月末には集計や説明もします。画面上の一つの機能が完成していても、この流れのどこかが旧い方法に残っていれば、人は二重入力や口頭確認へ戻ります。

並行運用は、最初は安全策です。新旧の結果を比べ、欠けた例外を見つけ、戻れる経路を残せます。しかし終わりを決めない並行運用は、二つの正本を作ります。片方だけ直されたデータ、どちらを見ればよいか分からない担当者、二倍の確認作業が生まれます。いつ、誰が、どの仕事を新しい経路だけで終えられたら切り替えるかを、機能完成とは別に決めます。

利用者テストで見るのは、画面の感想だけではありません。普段の代表例を最後まで進められるか、例外で止まったとき誰に渡るか、途中で離席しても再開できるか、同僚へ説明できるかを確かめます。実装が終わった日より、旧い手順を使わずに仕事を終えられた日が、業務移行の節目です。