データ移行は要件定義で決める。上流が押さえる論点

基幹システムの刷新で、要件定義のチームに参画したときの話です。業務フローや画面の議論は進んでいます。ところが「移行はどうしますか」と聞くと、会議の空気が止まります。「それは移行チームが後で考える」「ベンダーに任せる」。そう言われて、そのまま次の議題に進む場面は少なくありません。

移行は、設計が終わってから手を動かす作業に見えます。実際には、移行で何を決めるかによって、新システムのデータの持ち方も、テストの組み方も、切替の日程も変わります。後回しにした分だけ、設計の手戻りとして返ってきます。

この記事では、要件定義に参画する上流の担当者が、移行について早めに押さえておきたい論点を整理します。移行チームの代わりに全部を決める話ではありません。上流の段階で「決めておかないと後で困る判断」を見つけて、持ち主を付けるための話です。

移行が後回しになると、何が起きるか

移行の判断は、新システムの設計を縛ります。たとえば、過去の取引履歴を新システムに持っていくなら、新しいテーブルは旧データの形も受け止められなければいけません。持っていかないなら、過去データをどこで見るのかを別に決める必要があります。どちらに転んでも、設計に影響します。

よくあるのは、設計がほぼ固まったあとに、業務部門から「過去の実績も新しい画面で見たい」という声が出る場面です。旧システムでは自由に入れられた項目が、新システムでは必須になっている。旧システムにはない区分が、新システムでは必要になっている。こうした差を埋める方法が決まっていないまま、移行の開発が始まってしまいます。

もう一つは、コード体系が変わるのに、変換の表を誰が作るのか決まっていない場面です。品目コードや取引先コードを新しい体系に振り直す。その方針は要件定義で決まっています。しかし旧コードと新コードの対応を、どの部署が、いつまでに、どこまで責任を持って作るのかは、誰も書いていません。

気をつけたいのは、移行を「データを運ぶ作業」としてだけ扱うことです。移行は、業務の判断がたくさん詰まった束です。どのデータを残すか、どの値をどう読み替えるか、いつ業務を止めるか。どれも業務部門が決めることで、ITの担当者が勝手に決めてよいものではありません。上流の担当者の役目は、その判断を早めに表に出すことです。

最初に決めるのは「何を持っていくか」

移行範囲は、データの種類ごとに分けて考えると整理しやすくなります。マスタ、残高や未完了の取引、そして過去の履歴です。マスタと残高は、新システムで業務を続けるために必ず要ります。迷うのは履歴です。

業務部門に聞くと、多くの場合「全部持っていきたい」と返ってきます。そこで理由を聞きます。たとえば、こんなやりとりです。「過去の実績は、どんなときに見ますか」「監査で聞かれたときや、取引先から問い合わせがあったときです」「新しい画面で加工したり、集計したりしますか」「いや、見られれば十分です」。この場合、履歴を新システムに移す必要はないかもしれません。参照用の仕組みに置いておく、旧システムを参照専用でしばらく残す、といった選択肢が出てきます。

範囲を決めるときに、業務部門と一緒に確かめておきたいことを挙げます。

• そのデータを、新システムで更新するのか、見るだけなのか
• 見るだけなら、どの画面で、誰が、どのくらいの頻度で見るのか
• 過去のどの時点までさかのぼって必要なのか。その根拠は何か
• 新システムで集計や分析に使うのか。使うなら、旧データと新データを同じ軸で並べる必要があるのか
• 旧システムを止めたあと、そのデータを誰が保管し、誰が問い合わせに答えるのか

履歴の範囲は、保存の義務と関わることがあります。会計や取引の記録には、法令や社内規程で保存が求められるものがあります。ここは上流の担当者が思い込みで決めてはいけません。経理や法務の担当者に確認し、必要なら専門家の見解を取ってもらうよう依頼します。資料には「保存要件は確認中。確認先と期限」と書いて、未決として残しておきます。

切替の方式は、業務の止め方と一緒に決める

新システムへの切替には、大きく分けて、全体を一度に切り替える方法、拠点や機能ごとに順に切り替える方法、旧と新をしばらく並べて動かす方法があります。どれを選ぶかは、システムの都合だけでは決まりません。業務をどれだけ止められるか、現場がどれだけの負担を受け止められるかで決まります。

一度に切り替える方法は、移行の日に業務を止める時間が必要です。月末や繁忙期を避けると、候補の日は限られます。工場や物流の現場があるなら、出荷や生産を止められる時間帯は、業務部門にしか分かりません。この確認は要件定義の段階で始めておきます。

順に切り替える方法は、リスクを分けられる一方で、見落としやすい点があります。切替の途中は、旧システムと新システムが同時に動いているということです。たとえば、ある拠点だけ先に新システムに移ったとします。本社の集計は、新システムの拠点と旧システムの拠点のデータを合わせて扱う必要があります。そのための一時的なデータの受け渡しが要ります。

この一時的な連携は、最終形の設計書には出てきません。切替が終われば捨てる仕組みだからです。そのため、誰も設計せず、誰も見積もっていない、ということが起きます。順に切り替えると決めた時点で、「切替期間中だけ要る連携」を一覧にしておくと、後で慌てずにすみます。

旧と新を並べて動かす方法は、安心に見えます。ただし現場から見ると、同じ伝票を二つのシステムに入れることになります。業務部門の担当者が「並行稼働なら安全ですね」と言ったときは、その期間に誰がどの入力を二重にするのか、具体的に話しておきます。負担の重さが分かると、並行稼働の範囲を絞る判断につながることがあります。

データの品質は、移行の前に現行で直す

旧システムのデータには、長年の運用のくせが残っています。同じ取引先が別のコードで何件も登録されている。もう使っていない区分が残っている。本来は区分で持つべき情報が、備考欄の自由記述に書かれている。こうしたデータを、そのまま新システムに入れると、新システムでも同じ問題が続きます。

たとえば、取引先マスタの重複を整理する場面を考えます。ITの担当者は、名称や住所が似ているものを抽出して、候補の一覧は作れます。しかし、その二件が本当に同じ取引先なのか、支店として分けて管理しているのかは、営業や経理の担当者でないと判断できません。名寄せの判断をする人を決めないまま進めると、移行の直前に判断が集中して、結局そのまま移す、ということになりがちです。

データ品質の改善について、役割を分けておくと話が進みやすくなります。

1. IT側は、現行データを抽出し、重複や不整合の候補を一覧にする
2. 業務部門は、候補ごとに「統合する」「残す」「廃止する」を判断する
3. 判断の結果は、可能な限り旧システムの側で直す
4. 旧システムで直せないものだけ、移行の変換ルールで扱う

気をつけたいのは、「移行のプログラムで直せばいい」という話になることです。変換の処理に業務の判断を埋め込むと、その判断がどこにも記録されず、プログラムの中に隠れてしまいます。リハーサルのたびに直し方が変わる、担当者が替わると理由が分からない、という状態になります。直すのはできるだけ現行で、変換で扱うのは最後の手段、という順番を、早めに関係者と合わせておきます。

コードと項目の対応は、誰が決めて誰が承認するか

移行の中で、いちばん業務の判断が詰まっているのが、旧と新の項目やコードの対応づけです。旧システムの一つの項目に、実は複数の意味が混ざっていることがあります。たとえば、ある区分の項目が、部署によって違う意味で使われていた。新システムでは二つの項目に分ける。この場合、旧データの一件一件を、新しいどちらの区分に振り分けるのかを決めなければいけません。

ここで起きやすいのは、移行チームの担当者が、旧データを眺めて「たぶんこうだろう」と対応を決めてしまうことです。善意の判断ですが、業務部門の承認がないまま本番に入ると、切替後に「この区分は違う」という指摘が出たとき、直す根拠がありません。

対応づけを決めるときは、次のことを資料に残しておきます。

• 旧の項目やコードと、新の項目やコードの対応
• 対応先がないもの、対応先が複数あるものの扱い
• 空欄や想定外の値が入っていたときの扱い
• その対応を決めた人と、承認した人
• 決まっていないものと、決める期限

上流の担当者として意識したいのは、対応表を作る作業と、対応を決める判断を分けることです。作業は移行チームやベンダーに任せられます。判断は業務部門の担当者に持ってもらいます。会議では「この対応表は、どなたに承認をいただけばよいですか」と、最初に聞いておくと、後で承認者が見つからない事態を防げます。

リハーサルと検証の基準を、上流で言葉にしておく

移行のリハーサルは、本番と同じ手順を事前に試すものです。何回やるかより先に決めておきたいのは、何をもって「移行できた」とするかです。この基準があいまいだと、リハーサルのたびに「なんとなく大丈夫そう」で終わってしまいます。

検証の基準は、技術の言葉と業務の言葉の両方で持っておきます。技術の側では、移行前と移行後の件数が合っているか、エラーで落ちたデータがないか、を確かめます。業務の側では、取引先ごとの売掛の残高が合っているか、在庫の数量が合っているか、業務部門の担当者が普段見ている画面で違和感がないか、を確かめます。件数が合っていても、金額や数量が合っているとは限りません。業務部門が納得できる照合の方法を、早めに一緒に決めておきます。

もう一つ、上流で言葉にしておきたいのが、切り戻しの判断です。切替の当日、深夜に照合を進めていて、ある勘定の残高が合わないことが分かったとします。原因を調べて直すのか、旧システムに戻すのか。その判断を、その場で誰が下すのかが決まっていないと、関係者に電話をかけ続けて時間だけが過ぎます。

事前に決めておきたいのは、どの程度の差なら進めるか、どの差が出たら戻すか、何時までに判断するか、判断するのは誰か、です。これは移行チームだけで決められる話ではありません。業務部門の責任者と、プロジェクトの責任者が合意しておく必要があります。要件定義の段階では細部まで決められなくても、「切り戻しの判断基準と判断者は、いつまでに誰が決めるか」だけは、未決として資料に載せておきます。

参画したら最初に、移行の「未決一覧」を作る

ここまでの論点を、要件定義の期間中に全部決めきるのは難しいことです。業務の議論が先に進んでいて、移行に時間を割く余裕がない場面も多いでしょう。それでも、決まっていないことが見えていれば、後で慌てずにすみます。

参画して要件定義の議論に慣れてきたら、移行に関する未決を一覧にしてみてください。移行の範囲、履歴の扱い、保存要件の確認、切替方式、切替期間中の一時的な連携、データ品質の改善の進め方、コードの対応づけの承認者、照合の基準、切り戻しの判断者。それぞれに、決める人と期限を付けます。持ち主が決まらない行は、それ自体が論点です。

一覧ができたら、定例の会議で少しずつ触れていきます。毎回一行でも、「移行の未決で、今週動いたもの」を確認するだけで、移行が後回しになり続けることを防げます。移行の判断を、業務の議論と同じ机に載せておく。上流の担当者が最初に取れる行動は、この一覧を作り、会議の場に出すことです。