開発の事件簿 業務システム
移行データの重複で二重請求|戻る道は先に決める
あらすじ
切り替え前夜の重複データ
- 全部そのまま移す
- 稼働初日の二重請求
- 移行と戻る道の準備
※ よくある事例をもとにした創作です。台本・ナレーション・映像は AI で作っています。
開発の事件簿 VIDEOS
開発の事件簿 業務システム
あらすじ
切り替え前夜の重複データ
※ よくある事例をもとにした創作です。台本・ナレーション・映像は AI で作っています。
語り本番切り替えの前夜、移行データの最終投入が始まった。
日向真壁さん、取引先が同じ名前で三件あります。
真壁三件……表記が少しずつ違うな。
語り移す中身を、誰もまだ確かめていなかった。
桐島昔の取引先も、全部そのまま入れてください。
真壁使っていない先も、ですか。
桐島いつか使うかもしれないので。
日向コードの付け方も、年ごとに違いますね。
真壁今夜中に、手で直します。
語り古いデータには、重複や表記のゆれが積もっている。
語り直前に気づくと、手作業で埋めるしかなくなる。
語り稼働初日の朝。請求の締めで、金額が合わない。
日向同じ取引先に、請求が二重に立ってます。
桐島旧システムに戻せますか。
真壁戻す手順は……決めていませんでした。
桐島では、続けるしかないと。
語り戻すか続けるか、決める物差しが無かった。
語り条件を決めずに切り替えると、締めに響く。
語り原因は、移行と切り替えを後回しにできると思ったことだ。
語り一つ目。移行の前に、現場と名寄せとコード統一を済ませる。
語り使わない先や廃番は、ここで外しておく。
語り二つ目。テスト移行で、件数と金額を旧データと突き合わせる。
語り三つ目。並行運用を挟み、切り替えの条件を先に決める。
語りテストの合格、初月の伝票の一致、現場が一人で回せること。
日向条件、最初の会議で決めておけば。
語り移すデータと戻る道は、切り替えの前に決める。要件定義から運用まで、一創が一貫して支えます。