考え方 エンジニアリング

一括移行はしない

四つのシステムを九か月で置き換え、出荷は一日も止めませんでした。可能にしたのは綿密な計画ではなく、「切り替え」という行為そのものを手放したことです。

「切替日」は仮定である

多くの移行計画は一つの日付を中心に組まれます。その晩、旧が止まり新が動き、あいだに全員が緊張する時間帯がある。問題はリスクが高いことではありません。プロジェクト全体のリスクが一晩に圧縮されていること、そしてその晩への備えが、誰も実行したことのない切り戻し手順書だけであることです。

両方が正しい状態にする

海豊の案件では、初週から新旧のシステムが同時に正しいことが前提でした。各貨物を両方に書き込み、深夜に自動比較を走らせ、差分を毎朝一覧で配信します。切替日は存在せず、代わりに毎日答えられる問いがありました —— 今日は何件が一致しなかったか。

本当の成果物は差分一覧である

最初の六週間、一覧が空になった日はありませんでした。そして一行ごとが、仕様書に抜けていた規則です。ある顧客だけが使う通関区分、月末にしか現れない併合、誰も書き残していないが全員が知っている例外。これらはヒアリングには出てきません。データにしか出てきません。

収束そのものが進捗報告になる

七週目に一覧が短くなり、十週目に一桁になり、十四週目に五日続けて空になりました。旧システムの停止を初めて議論したのはその日です。公開日は決めたのではなく、証明されたものでした。この違いは、役員会議の場で想像以上に効きます。

工数はおよそ三割増える

明確にしておきます。並行運用は無料ではありません。維持する書き込み経路がもう一本、読むべき照合レポートがもう一種類、そして変更のたびに両側で成立させる必要があります。全体で工数はおよそ三割増でした。優雅な手法ではなく、リスクを支払える価格に変換しているだけです。

この方法を採らない場合

旧データを誰も読んでいない場合、二時間の停止で困る人がいない場合、社内ツールである場合 —— 一度に切り替えて、その三割を節約すべきです。並行運用は工数と停止リスクの交換であり、停止が本当に高くつくときだけ割に合います。この判断は提案の段階で終えるべきもので、障害報告の場で行うものではありません。