SAP移行が予定どおり本番を迎えられなかった案件を振り返ると、原因はたいてい同じ場所に溜まっている。要件定義でも、アドオン開発でもない。データ移行だ。しかも詰まるのは、日々の伝票のような取引データではなく、その土台にあるマスタ――取引先・品目・勘定科目である。切替の直前になって、ロードが通らない、通っても数字が合わない、という形で表面化する。だが本当の敗因は、そのずっと手前にある。データ移行の成否は、切替直前のロード作業でなく、その半年前に「マスタの品質を誰が持つか」を決めた時点で、ほぼ決まっている。
なぜ取引データでなく「マスタ」で詰まるのか
取引データ（会計伝票、受発注、入出庫）は、実のところ移行の難所ではない。形式が決まっていて、金額と日付と相手コードが揃っていれば機械的に運べる。厄介なのはマスタのほうだ。マスタには意味のゆらぎがある。同じ取引先が「株式会社◯◯」「◯◯（株）」「マルマル商事」と三通りで登録されている。使われていない品目が何千件も残っている。勘定科目に、もう誰も説明できない補助科目がぶら下がっている。これらは形式的には正しく見えるので、機械は素通りさせる。だが人が見れば、明らかに壊れている。
S/4HANAでは、この問題が構造的に炙り出される。ECCで別管理だった得意先マスタと仕入先マスタが、S/4HANAではBusiness Partner（取引先）に一本化される。片方だけに登録されていた企業、両方に別コードで登録されていた企業――ECC時代は分かれていたから顕在化しなかった重複が、統合の瞬間にすべて衝突する。マスタの汚れは、移行が可視化するのだ。移行アプローチをどう選んでも（S/4HANA移行の3つのアプローチをやさしく比較）、この名寄せと重複整理からは逃げられない。
品質を潰す順番――「後ろの工程」から逆算する
多くの現場が、切替が近づいてからマスタに手をつけて破綻する。正しくは逆で、本番ロードという一番後ろの工程から逆算して、やることを前倒しに並べる。順番を間違えなければ、直前の修羅場はかなり避けられる。
出発点はデータプロファイリング、つまり現状の棚卸しだ。マスタが何件あり、うち重複が何割、欠損がどこに、そして「直近◯年で一度も使われていないコード」がどれだけあるか。これを感覚でなく数字で押さえる。使われていないマスタは、直すのでなく移さない判断ができる。運ぶ量を減らすことが、品質を上げる最短路でもある。
ドライランで「フォールアウト率」を測る
品質が本当に上がったかは、リハーサルで測れる。本番と同じ手順で試験的にロードし、何件が正常に入り、何件が弾かれたか――この**フォールアウト率（脱落率）**を指標にする。
弾かれたレコードを「エラーが出た、直そう」で終わらせないことも大事だ。落ちた原因を分類すると、その多くは特定のパターン（この国だけ番号形式が違う、この事業所だけ命名規則が独自）に集約される。パターンを潰せば、同じ原因の脱落がまとめて消える。個別対応でなく、原因の類型で潰すのが速い。
品質の責任者は、IT部門ではない
最後に、最もつまずく論点を一つ。マスタ品質の責任を、IT部門やベンダーに預けてはいけない。彼らはデータを運ぶことはできるが、「このAとBが同じ会社か」「この補助科目はもう不要か」を判断できない。判断できるのは、日々そのマスタを使っている業務部門――取引先なら債権債務・購買、品目なら生産・在庫、勘定科目なら経理――だけだ。
だからプロジェクトの初期に、各マスタの「品質オーナー」を部門名でなく個人名で決める。誰が名寄せの最終判断を下し、誰が代表レコードを承認するか。ここが空白のまま進むと、名寄せの判断が宙に浮き、結局「全部そのまま運ぶ」に流れる。それは汚れをそのまま新システムに引き継ぐことに等しい。移行を機に勘定科目そのものを設計し直すなら、その論点は別稿で詳しく扱う（SAP移行を機にする勘定科目体系（COA）の再設計）。経理財務が移行にどこまで関与すべきかも、工程ごとに整理した（SAP移行プロジェクトに経理財務はどう関わるべきか）。
