古い業務から、何を残して何を変えるか

旧画面と同じ項目、同じ順番、同じボタンを再現すれば、利用者は迷いにくくなります。一方で、二重入力、担当者しか知らない省略記号、画面幅の都合で分かれた処理まで新システムへ固定します。

逆に、古いものをすべて捨てると、例外処理や監査の手がかりまで消えます。新旧の見た目を比べる前に、各操作が果たしていた目的を一文にします。

ピース・ビズ グループのList Intake Engineでは、受け取った原本、列の対応付け、形式の正規化、重複候補、確認後の反映を分けています。電話番号の全角・半角や区切り記号は規則で整えられます。候補の一致度も計算できます。

しかし、自動では確定できない行を消したり、勝手に既存データへ混ぜたりしません。理由と原本を見ながら人が解決できる状態へ回します。自動化し切れなかったのではなく、確定責任を別に置いたのです。

新しいデータベースへ全件入っても、訂正できない、原本へ戻れない、重複の理由が分からないなら、業務能力は弱くなっています。移行件数の一致に加えて、例外と復旧を試します。

古い値が矛盾するとき、黙って新しい形式へ合わせるのか、未確認として残すのかも決めます。「きれいなデータ」を作ることより、何を知っていて何が分からないかを保持する方が重要な場面があります。

「なぜこの欄を入力するのか」「この判断を間違えると誰が困るか」「例外のとき誰へ渡すか」「後から何を証明するか」。四つを聞くと、残すべき能力が見えてきます。

旧画面をコピーするか刷新するかの二択ではありません。業務目的を取り出し、必要な意味を残し、操作だけを作り直す。Legacy replacementは、古いソフトウェアの交換より、古い仕事の解剖に近い作業です。

古い業務を見ていると、同じ数字を写す、空欄へ補足を書く、一覧を印刷する、といった操作はすぐに消したくなります。しかし、その手作業がどの場面で使われていたかを追うと、形式が崩れた入力を見つける、判断の理由を次の人へ渡す、通常と違う案件を保留にする、といった能力が埋まっていることがあります。

だから移行では、旧画面の項目名を新画面へ写す前に、操作の目的を聞きます。この欄は何を守るためにあるのか。空欄だと誰が困るのか。例外をどこで見分けるのか。不要なら消す。目的が残るなら、より分かりやすい形へ作り直す。この順番なら、旧い制約までコピーせずに済みます。

営業リストの取込でも、原本を残す、表記をそろえる、重複候補を出す、確定できないものを人へ回す、という状態に分けて考えると、古い手入力の意味を一つずつ置き換えられます。移した件数ではなく、例外まで新しい経路で扱えるかで移行の質を見ます。