データ項目を段階移行する——新旧区分の併存・書き込み経路・元に戻す手順（ロールバック）の設計

区分を増やしただけで集計が変わる

社内申請の種類が「購入」と「経費」の二つだったところへ、「定期契約」を加える場面を考えます。入力画面に選択肢を足すだけなら小さな変更に見えます。しかし月次の集計、承認の順番、部署別の一覧は以前の二種類しか知りません。定期契約が経費へ混ざる、未分類として消える、承認先が決まらないといった問題が起こり得ます。項目の追加では、入力画面と後続の集計・承認が同じ区分を理解することを確認します。

変更前に把握したいのは、どの画面が項目を読み、どの処理が項目を書き、どの判断が値に依存するかです。保存する表だけを見ても影響範囲は分かりません。申請から承認、支払、報告へ進む流れをたどり、区分が使われる箇所を列挙します。新しい種類を受け入れる前に、後続が理解できる状態へ整える必要があります。小さな見た目の変更ほど、意味の変更を隠しやすいことに注意します。

戻せる更新とは、変更前の状態へ技術的に戻せることだけではありません。新しい区分で受け付けた申請をどう扱うかまで含みます。画面を以前へ戻しても、新しい値を含む申請は残ります。何を取り消し、何を保留し、何を旧区分へ対応させるかを決めないと、復旧後に処理できない仕事が生まれます。更新と差戻しの双方を、実際のデータの動きとして設計します。

新旧の意味を対応させる

最初に新しい区分の目的を文章にします。「契約の更新時期と継続費用を別に管理したい」なら、単に名称を増やす以上の情報が必要です。契約期間や更新日も加えるかを検討します。旧データのどこまでを新しい区分へ移すかも決めます。摘要に「月額」とあるだけで定期契約と推測すると、単発の分割払いを誤分類するかもしれません。移行の対象は確認できる条件に限ります。

対応が確定しない過去申請は旧区分のまま残し、新しい入力だけに新しい区分を使う方法もあります。全件を移し替える方が見た目は整いますが、根拠のない再分類は報告の意味を変えます。未移行の件数と範囲を示せば、段階的な更新でも利用者は理解できます。新旧が併存する期間にどの集計を使うかを決め、古い申請が消えたように見せないことが重要です。

区分の対応は一方向とは限りません。旧経費の一部が定期契約へ移るなら、旧区分だけから新分類を復元できません。復旧時に全て経費へ戻す場合、契約の情報まで消す必要はないかもしれません。業務上の分類と新しい補足情報を別に保持する方法を考えます。対応を文章で定めれば、どこまで自動で戻せて、どこから担当者の確認が必要かを明確にできます。

書き込む入口を揃える

申請区分を更新する入口が入力画面、担当者の一括登録、AIによる分類の三つに分かれている場合、それぞれで検査が違うと混乱します。どの入口からでも共通の確認を通し、許可した区分、必要項目、版を同じ規則で確かめます。画面の選択肢だけを直しても、別の経路から旧い形式が届くことがあります。変更時に書込みの入口を揃えることは、日常の運用にも役立ちます。

共通の入口は、全ての利用者へ同じ権限を与えることではありません。通常の申請者は自分の申請だけ、管理者は許可した一括修正だけという範囲を保持します。区分の設定を変える操作は、申請内容を書く操作と分けます。規則の変更を日常入力に混ぜると、担当者が意図せず全体の挙動を変える可能性があります。誰がどの変更を行えるかと、どの規則で検査するかを別に定めます。

更新中の依頼には、新しい規則を使うのか、開始時の規則を使うのかも必要です。承認の途中で区分の意味が変わると、以前の判断がそのまま有効とは限りません。変更の影響を受ける依頼を抽出し、再確認が必要なものだけを戻します。全件を止める方法は簡単ですが、関係しない申請まで止まります。影響の根拠を残せば、再確認の範囲を合理的に絞れます。

先に読めるようにしてから受け入れる

段階的な更新では、後続の集計と承認画面が新旧の区分を読める状態へ先に整えます。その後、新しい入力を受け付けます。新しい区分を先に保存してから後続を直すと、その間の申請が処理できません。読み手が新しい値を知らないときには、無言で除外せず要確認として残すようにします。更新順序は作業の効率だけでなく、処理できないデータを生まないために決めます。

過去のデータを変換する工程は、通常の申請処理と分けて行います。対象件数、変換前後の区分、変換理由を確認できる形にし、試しの結果を見てから採用します。新しい値が作れたことだけでなく、件数の増減や承認先の変化も比較します。後続の画面が動いても、報告書の合計が変わる場合があるため、主要な出力まで含めて確認する必要があります。

併存期間には、いつ新しい形式へ切り替えるか、旧形式をいつまで受け付けるかを決めます。「しばらく両方」だけでは、古い入力が永久に残ることがあります。受付期限を設ける場合も、その直前に進行中だった申請の扱いを決めます。期限を過ぎた旧形式は、新形式へ変換できるなら理由を示して変換し、できないなら具体的な不足項目を返します。変更の都合だけで利用者の仕事を消さないようにします。

戻す条件を更新前に決める

差戻しの判断は、更新後の気分で決めないようにします。新しい区分が後続で読めない、承認先が誤る、集計件数が説明できず変わるといった条件を事前に定めます。単に画面の見た目が好みでないことと、業務の結果が違うことは対応の重さが異なります。重大な結果の誤りは新しい受付を止め、既に受け付けた対象の状態を確認してから戻す方法を用意します。

戻す際には、以前の規則、画面、保存済みデータの関係を確認します。設定だけ戻しても、新しい区分の申請を読めないなら復旧は完了していません。新しい申請を保留一覧へ移し、元の内容を残したまま旧区分で処理可能かを確認します。実際に承認や支払が行われた申請は、データを巻き戻すだけで取り消せません。戻せる範囲と、別の訂正手続きが必要な範囲を分けます。

差戻しを試すときは、更新直前の状態だけでなく、新しい申請を数件受け付けた後の状態を使います。これにより、新旧データが混ざった場面で復旧できるかを確かめられます。戻す処理も元の内容を失わず記録を残す必要があります。一度試せたことは、全ての本番条件で戻せる保証ではありませんが、手順だけ書いて一度も実行しない場合より、具体的な不足を見つけられます。

検証は変えない部分にも置く

新しい区分の入力試験だけでは、以前から使う購入申請が変わっていないかを確認できません。従来の入力、承認、集計の代表例を残し、新旧の出力を比較します。変更してよい差と、変えてはいけない差を事前に分けます。新機能の結果が良いから従来の誤りを許すという判断は避けます。利用者がいつも行う仕事を維持することも更新の完了条件に含めます。

入力の不備も試します。新しい区分なのに契約期間がない、旧形式なのに新しい項目だけ届く、知らない区分が届く、同じ申請の修正が同時に届くといった場面です。形式の不備を画面で説明できるかと、後続へ流さず止めるかを別に確認します。どちらかだけでは、利用者が直せないか、不正な入力が処理されるかの問題が残ります。具体的な修正方法を返せる検査が必要です。

比較する資料は、変更後の都合に合わせて選び直さないようにします。事前に決めた代表例と、実際に見つかった問題を分けて残します。独立した確認者には、変更の狙い、許容する差、元の入力と出力を渡します。作者の「小さな変更」という感覚を評価基準にしないことが大切です。範囲が小さくても承認や支払に関わるなら、結果に対する検査の重さは必要になります。

版と依存関係を更新の順序へつなぐ

変更の影響を追うには、作業項目、依存関係、制約、版を同じ計画へ結び付けます。計画エンジンのヤクモ提供の実装には、それらを専用サービスで扱い、書き込み経路を一つへ限定する構成があります。申請区分の更新では、どの版の規則を各画面が読んでいるかを記録する設計が考えられます。保存先の変更が済んだことだけで後続の準備完了にはせず、承認先の決定と集計の出力をそれぞれ確認します。更新対象の一覧と、先に直す読み手の対応を計画へ残します。

段階的な受付変更や差戻しは、対象のデータを使って確かめる必要があります。版を保存し書込みを限定しても、旧画面が新しい区分を理解できるとは限りません。新しい申請を数件受け付けた状態で、旧形式へ戻すと何が残るかを確認します。区分の名称は戻せても、承認済みの通知や支払は別の訂正が必要かもしれません。利用者が行う仕事と保存済みデータを基に、許す差、止める条件、自動で戻せない範囲を定義すれば、更新後の判断を具体化できます。

計画の依存関係という考え方は、更新の作業順にも使えます。後続の読み手を整える前に新しい入力を始めない、比較が終わる前に旧形式を削除しない、といった条件を工程へ置けます。ただし依存関係を描くことだけで実際の準備が済むわけではありません。各工程が何を提出し、何を確認したら次へ進めるかを決めることで、図を実行可能な更新計画へつなげます。

TypeScriptで入力の契約を定め、PostgreSQLへ保存し、Vitestで新旧の挙動を検査する構成が考えられます。移行とロールバックを手順化する場合も、手順があることと対象データで戻せることは別です。申請区分では、従来の申請を読める条件と新しい申請を戻す条件をそれぞれ定めます。新旧が混ざる保存データを用意し、件数、分類、承認先を比較します。変換前の値と理由も保持し、戻した際に元の契約情報まで失われていないかを確かめます。

完了は旧い仕事まで通して決める

更新の完了には、新しい申請が使えること、従来の申請が使えること、集計の差を説明できること、問題時に戻す手順を確認したことを含めます。古い形式をやめる場合は、未処理の申請や外部の入力経路が残っていないかも確認します。新しい画面を公開した時点だけを完了にすると、後から旧形式の仕事が止まるかもしれません。残した互換の範囲と期限も記録します。

この設計は顧客区分、商品分類、勤怠の項目変更にも応用できます。一方、既に外部へ確定した取引や通知は、保存データを戻しただけでは取り消せません。戻せる更新という言葉で外部操作の不可逆性を隠さないことが重要です。技術的な復旧と業務上の訂正を分ければ、何を自動化でき、何を担当者へ残すかを具体的に判断できます。影響範囲が大きい場合は段階を増やして検証します。

仕様を変えるたびに全てを作り直す必要はありません。変える意味、残す意味、変換の根拠、復旧の範囲を明確にすれば、対象を絞った更新ができます。戻す道を事前に用意することは、変更を躊躇するためではなく、必要な変更を説明可能な形で進めるためです。新旧の結果を比べ、想定外の差があれば立ち止まれる工程を持つことで、更新の成功を画面の完成以上の条件で確かめられます。