旧システムのデータは何を移す？発注前に履歴と確認先を決める方法

移行要件は、残す仕事とデータの境界を決めること

移行要件とは、システムを替えた後にも必要な仕事を続けるために、どのデータを、どの状態で、どこから使えるようにするかを決める要求です。データをコピーする方法だけではなく、対象外にする情報の扱い、確認する人、試す条件も含みます。

たとえば、新側で過去の伝票を検索したい要求と、月ごとの販売傾向を分析できればよい要求では、必要な持ち方が同じとは限りません。分析結果だけで足りるのか、元の取引の内容までたどる必要があるのかでも、頼む作業が変わります。

発注側は、業務で必要な使い方と範囲を説明します。旧新の仕組みを知る担当や提供会社には、その要求を実現できるか、変換・確認・維持に何が必要かを聞きます。発注側だけで技術方式を断定せず、提供会社だけに履歴の業務上の必要性を決めてもらわないことが大切です。

IPAの要件定義ガイドも、要件定義の段階で検討できる移行範囲を整理し、未決事項を管理する観点を示しています。本記事の用途別の分け方や文面は、その観点を架空の販売分析に当てはめた編集上の説明です。自社に必要な年数や方式を、ガイドが一律に指定しているわけではありません。

履歴を何に使うかを、一つの仕事で説明する

最初に、業務分析担当が実際に行いたい分析を一つ選びます。「古いデータが必要」では広すぎます。この例では、顧客別の販売傾向を、切替前から切替後まで比べる分析を対象にします。

IT発注担当は、「誰が、その比較を見て、次に何を判断するのですか」「顧客全体の傾向を見るのですか、それとも一件の販売まで確認しますか」と聞きます。どこまで詳しく見られる必要があるかによって、移す候補の情報が変わるためです。

1. 使う仕事を選ぶ。販売傾向の分析、過去の問合せへの回答、未完了取引の引継ぎなどを、一つの目的へ混ぜずに分けます。
2. 見る内容と、その後の行動を説明する。集計を見て判断するだけか、元伝票を開いて内容を確かめるかを聞きます。
3. 必要な期間と粒度を質問にする。期間や一件の明細までの必要性を、まだ答えがないまま確定値にしません。
4. 答える担当を結ぶ。使い方は業務側、保管先や取得方法は管理担当・提供会社など、確認できる立場へ聞きます。

販売分析のために必要な履歴と、今も処理を続ける未完了の取引は、別に確かめます。分析に使わないからという理由だけで、進行中の注文や後から訂正する取引まで対象外にしてはいけません。反対に、進行中の取引を移すからといって、すべての過去履歴を新側の取引として再現する必要があるとも限りません。

必要な期間と、新旧の記録のつながりを確かめる

次に、いつの情報を、どの条件で比べたいかを整理します。「過去分」という言葉だけでは、開始・終了の時点も、取消や返品を含めるかも分かりません。比較したい業務の期間、切替の境目、後から変わる取引の扱いを分けて聞きます。

期間を決める理由は、仕事に必要な比較範囲です。この記事では何年分とも決めていません。また、分析に使う期間と、会社として記録を保存・参照する期間は、同じとは限りません。使わない履歴の廃棄をこの場で決めず、管理担当へ保存方針を確認します。

名前が似ていても、同じ顧客・商品とは限らない

新旧で顧客や商品のコードが変わる場合は、何を同じものとして結び付けるかを確かめます。名称だけで自動的に同一扱いにせず、旧新のコード対応、統合・分割された区分、対応が見つからない情報を、業務を理解する担当と確認します。

対応表があるとは限りません。存在、管理者、更新のしかたを聞き、ない場合は、誰がどの根拠で対応を決めるかを相談します。技術担当へ「つないでください」と頼む前に、業務上の同一性を判断する人が必要です。対応が決まっていない履歴は、集計に使える状態と扱いません。

この例の新旧記録は、実データではなく確認用の想定

以下は、発注前に聞く内容を具体化するための架空の前提です。販売時点・顧客・商品・売上金額は、分析に必要かを確認する欄の候補であり、製品の確定した項目名ではありません。旧側へ実際に接続したり、記録を抽出したりはしていません。

欄が両方にある想定でも、意味や単位、集計の基準まで一致するとは限りません。分析で同じ意味として扱えるかを確認し、その答えを、対象期間や取り出す情報の説明へ反映します。実際に移した後の件数・金額・関連の照合は、この記事の発注前の決定とは別の作業です。

新側へ移す・旧側で見る・分析用にまとめるを比べる

置き場所の候補は、便利そうな順ではなく、必要な仕事ができる条件で比べます。この例の三つの経路は、すべて未採用・実現可否も未確認です。複数を組み合わせる場合も、どの履歴をどの経路で見るかを明記し、同じ取引を重ねて集計しない条件を確認します。

新システムへ移す案：新側の仕事で扱える必要があるとき

新側で履歴を探して使いたいなら、旧の情報を新側のどの項目へ、どの状態で入れられるかを提供会社へ確認します。古い取引を、新側の取引としてそのまま再現できると決めつけません。元の意味、コード、訂正や関連資料をどう扱うか、必要な変換と確認も含めて相談します。

選ぶ前に確認すること：入れられる情報と入れられない情報、変換の責任、業務側の確認範囲、移行後の使い方、費用に含む作業です。新側で見えることが必要でも、方法が未回答なら、実現済みの機能として見積条件へ書きません。

旧側で参照する案：過去の内容を必要なときに確認する場合

過去の伝票などを調べる用途では、旧側の参照を残す案も考えられます。ただし「データは残っています」だけでは、仕事に使える条件がそろいません。誰が、何を使って、いつまで開けるか、対象の記録や関連資料を探せるかを確かめます。

旧システムを止めた後も同じ方法で見られるとは限りません。参照に必要な環境や契約、運用を維持できるか、停止後に別の参照方法が必要かを担当へ確認します。バックアップがあることだけを、利用者が履歴を検索できる証拠にしないでください。

選ぶ前に確認すること：参照方法、対象の情報、閲覧権限、維持する期間、変更を制限する方法、旧側を止める条件と、その後の確認先です。閲覧条件が未確認なら、新側への移行から外せると結論づけません。

分析用の経路でまとめる案：新旧をまたいで比較したいとき

販売傾向を比べるために、新旧の必要情報を分析用の環境で扱う案もあります。この案でも、新旧のコード対応、取得する時点、更新方法、集計対象が必要です。別の環境へ集めれば意味の違いが自動的になくなるわけではありません。

分析用にまとめた情報で、元の取引を修正したり、出荷や請求を処理したりできるとは限りません。日常の取引処理と分析の役割を分け、分析で見つけた疑問をどの元記録へ戻って確認するかも決めます。

選ぶ前に確認すること：分析に必要な欄と期間、旧新から取得できる方法、対応関係、閲覧権限、更新を保つ担当、費用と運用です。分析に必要な使い方から構成を相談します。この経路の実装可否も未確認です。

図で、履歴と未確認の対応を読み分ける

解説図を原寸で見る

この図を読んだ後の判断：二つの履歴を分析に使う目的は説明できますが、必要期間とコード対応、閲覧条件、経路の可否は未確認です。業務分析担当とIT発注担当は、それぞれ答えられる管理担当・提供会社へ聞き、回答をもとに図と文章を同じ内容へ直します。図の線や紙の配置を、実際の接続・データ移送・分析成功の証拠にはしません。

回答に合わせて範囲を更新し、決められない所を保留する

確認を依頼しただけでは、範囲は確定しません。回答を受けたら、何が必要だと分かったか、何を実現できると確認したか、何をまだ決められないかに分けて更新します。説明の中の「案」を、根拠なく「決定」に置き換えないことが大切です。

業務側から、比較したい期間の答えが得られたら

たとえば「前年の同じ時期と比較したい」という回答が得られた場合は、その比較に必要な開始・終了の時点、対象とする販売、集計の単位を具体化します。これは回答を受けた場合の編集上の分岐例であり、この架空例の必要期間を確定したものではありません。

期間が明らかになったら、その範囲の旧履歴がどこにあり、取り出す対象として説明できるかを確認します。分析の用途だけで、残すべきほかの記録を削除・廃棄する判断へは進みません。

旧側で見続けられるかの答えが得られたら

参照を維持できると確認できた場合は、見る人、対象、方法、維持する期間、運用担当を範囲の説明へ加えます。その条件で業務上の目的を満たすかを業務側に確かめ、対象外にする理由も残します。技術側の回答だけで、業務側も使えると判断済みにしません。

旧側を止める予定があり、その後の参照方法が決まっていない場合は、参照を残す案は未解決です。必要な履歴までアクセスできなくなる条件を避けるため、移す案や別の参照経路を提供会社と比較し直します。回答前に停止や削除を実行する話ではありません。

コード対応や取得方法が分からなかったら

「分からない」は、対応がないことの証明ではありません。元資料の場所、旧新を理解する担当、業務上の同一判定を確認する人をたどります。対応が見つからない情報を、都合のよい値で埋めたり、すべて同じものにまとめたりはしません。

試行と照合で何を確かめるか、発注前に相談する

範囲を決める段階でも、後で何を確かめれば使えると判断できるかを相談します。業務側は、必要な履歴を見つけられるか、同じ顧客・商品として比べられるか、元記録をたどる必要を満たすかを説明します。技術側には、試行できる環境、対象、手順と、必要な準備を確認します。

代表例は、都合よくそろった記録だけに偏らせません。切替の境目をまたぐ履歴、コード対応が難しいもの、後から訂正する取引など、自社の対象にある例外を選びます。ここでは実データを選んだり、試行したりしていないため、試行と照合の結果は未確認です。

データの誤りや重複を直す作業が必要なら、何を誤りと判断するか、誰が確認・修正するか、元の状態と修正履歴をどう残すかを相談します。見た目が似ている記録を自動的に消すことや、本番の取引を思いつきで書き換えることを勧めるものではありません。

移行後には、決めた対象と時点で件数・金額・関連を照合し、差があれば調べる工程が別に必要です。具体的な照合はデータ移行の件数・金額・関連データを確認する記事で扱っています。本稿では、照合対象を決める前提と、確認に関わる担当を発注範囲へ含めるところまでを整理します。

一つの代表例で見られただけで、全履歴の移行完了とは扱いません。確認できた対象と未確認の対象を分け、使い始める判断を誰が行うかを、提供会社と業務責任者へ確認します。

発注先へ渡す説明を、用途と未決事項から書き直す

「旧データを全部移してください」という依頼を、仕事、対象の候補、確認する条件へ分けて書き直します。次の文面は相談用の架空例です。採用経路、期間、責任分担や費用を合意した記録ではありません。

発注前の説明の例（未確定）

当社では、顧客別の販売傾向をシステムの切替前後で比べる分析を検討しています。切替前の履歴は旧側、切替後は新側に保管している想定ですが、必要な履歴期間と、実際の取得・閲覧条件は未確認です。

業務分析担当が比較の目的・必要期間・詳細を確認します。IT発注担当は、新旧の顧客・商品などの対応、旧側の参照方法と維持条件、必要情報を取得できるかを管理担当・提供会社へ確認します。

新側へ移す、旧側で参照する、分析用の経路でまとめる案について、目的を満たす条件、実現可否、対象外の扱い、変換・確認・維持の作業と責任を相談したいと考えています。未回答の条件は未決として分け、試行と照合の対象・確認担当も相談してから、依頼する範囲を決めます。

回答が得られた箇所は、この文面の未確認部分と、図・対象一覧を同じ内容へ更新します。担当名だけを追加して完了とせず、何を根拠に判断したか、どの条件で成り立つか、残った質問は何かも残します。

見積りを比べるときも、データの取り出し、対応の整理、変換、試行、業務側の確認、旧側の参照維持などが、どこまで含まれるかを確かめます。金額だけを比べて、対象や役割の違いを見落とさないようにします。

まとめ：履歴の用途・期間・見る場所をつないで決める

旧データの移行範囲は、保管量だけでは決められません。誰が何の仕事で履歴を使うか、どの期間と詳細が必要かを明らかにし、新旧の情報を同じ意味で扱えるかを確かめます。

新システムへ移す、旧側で参照する、分析用にまとめるという案は、それぞれ使える条件を確認して選びます。移さない対象も、どこで誰がいつまで見られるかを決める必要があります。コード対応や閲覧、方法の可否が未回答なら、未決として確認先をつなぎます。