リスクを抑え、成功に導く実践アプローチ
2026年6月
SAP S/4HANA導入プロジェクトが想定外の工期延長・コスト超過に陥る原因を問われたとき、経験豊富なプロジェクトマネージャーはほぼ一様に「データ移行」と答える。要件定義が整い、設計が完了し、開発も終わった——それなのになぜプロジェクトは遅れるのか。答えは単純である。「データ品質が想定より遥かに悪く、移行に想定の3倍の時間がかかった」からである。
データ移行は地味なタスクとして軽視されがちである。しかし現実には、30年分の業務データには「誰が見てもおかしな」品質問題が無数に潜んでいる。品番コードに半角・全角が混在する。顧客マスタに同一顧客が20種類の表記で存在する。在庫の帳簿残高と実在庫が2億円乖離している——。これらの問題を発見し修正するのは、システムではなく人間の判断を要する作業であり、そこに時間がかかる。
本ガイドは、SAP S/4HANA導入におけるデータ移行の全工程を「リスクを抑え、成功に導く」実践的なアプローチで解説する。データ移行を「作業」としてではなく「プロジェクトの中核戦略」として位置づけることが、成功の第一歩に他ならない。
SAP S/4HANAへのデータ移行は、大きく以下の5フェーズで構成される。各フェーズは順次進めるものではなく、プロジェクト全体と並走する継続的な活動として管理する必要がある。
フェーズ | 主要タスク | 成果物 | タイミング |
①データ棚卸し | 移行対象データの全体把握・優先順位付け | 移行対象一覧・ボリューム試算 | 構想〜要件定義 |
②データクレンジング | 旧システムデータの品質問題を特定・修正 | クレンジングルール一覧・修正実績 | 設計〜開発並行 |
③移行プログラム開発 | ETL（抽出・変換・ロード）ツール開発 | 移行プログラム・マッピング定義書 | 開発フェーズ |
④リハーサル（Mock） | 本番カットオーバーを模擬したドライラン | リハーサル報告書・課題リスト | テストフェーズ |
⑤本番カットオーバー | 本番環境への最終データ移行 | 移行完了報告書 | カットオーバー直前 |
SAP S/4HANA移行において、移行するデータは大きく「マスタデータ」「トランザクションデータ」「残高データ」の3種類に分類される。それぞれで難易度・ボリューム・クレンジング工数が異なるため、早期に分類・定量化することが不可欠である。
データ分類 | 代表例 | 移行の難易度 | 特記事項 |
マスタデータ | 得意先/仕入先マスタ・品目マスタ・BOM・勘定科目 | ★★★（高） | 重複・表記ゆれが多く、クレンジング工数が大 |
トランザクション（未完了） | 未完了受注・未完了製造指図・未完了発注 | ★★★（高） | 複数テーブルをまたぐ整合性確保が困難 |
残高データ | 在庫残高・売掛/買掛残高・固定資産残高・WIP | ★★（中） | 金額の整合性確認（帳票照合）が必須 |
履歴データ | 過去受注履歴・仕訳履歴 | ★（低） | 移行するかしないかの方針決定が先決 |
| コンサルタントの視点 | 履歴データの移行範囲は「何年分を移行するか」の判断が必要。全履歴を移行しようとすると期間とコストが跳ね上がる。多くの場合、最低限の法定保管期間（日本は原則7年）のみ移行し、旧システムは参照用に一定期間並行稼働させるアプローチが現実的である。 |
「なぜこれほどデータ品質が悪いのか」と驚くクライアントは多い。しかし考えてみれば当然である。旧システムには「とりあえず入力できればよい」という設計思想のものが多く、入力バリデーションが緩い。担当者が変わるたびに入力スタイルが変わり、部門ごとに「独自ルール」が生まれ、それが何年・何十年と積み重なってきた。ERPとはそのような「妥協の積み重ね」を整理する機会でもある。
問題分類 | 具体例 | 対処方針 |
重複データ | 得意先「株式会社ABC」「(株)ABC」「ABC株式会社」が別コードで存在 | 名寄せルールを定義し、1コードに統合 |
表記ゆれ | 品目名「ステンレスボルト M6」「SUS ボルト M-6」「M6 SUSボルト」 | 命名規則を確定し、一括置換 |
欠損値 | 品目マスタの「調達カテゴリ」「MRPタイプ」が未設定 | 業務部門と協議し、デフォルト値を決定 |
参照整合性エラー | 受注データが参照する品目コードが品目マスタに存在しない | 受注データを業務的に処理してから移行（またはコード追加） |
桁超過 | 旧システムでは品目コード20桁、SAPでは18桁（最大） | コード体系を再設計・変換テーブルを作成 |
数値精度の相違 | 旧システムでは単価4桁整数、SAPでは小数点2桁まで管理 | 変換ルールの業務的確認（四捨五入か切捨てか） |
データクレンジングはIT部門だけで完結できない。「このデータが正しいかどうか」の判断は業務部門にしかできない。しかし業務部門は通常業務を抱えているため、クレンジング作業を「追加業務」として押しつけると抵抗が生まれる。
有効なアプローチは「データスチュワード制度」の設置である。各業務領域（顧客管理・品目管理・購買先管理等）に、データ品質の責任者（データスチュワード）を1名アサインし、そのスチュワードがクレンジング判断の最終権限を持つ体制を作る。ITはツールと分析を提供し、判断は業務が行う——この役割分担を明確にすることが、クレンジング作業の推進に不可欠である。
クレンジング推進の実践的ポイント |
① 「クレンジング率」をKPIとして設定し、週次でモニタリングする（例：品目マスタ クレンジング完了率 現在65%→目標100%） |
② 修正作業はExcelで行い、システムへのロードは自動化ツールで行う（人手による直接入力は品質が下がる） |
③ 「誰がいつ何をどのルールで修正したか」の履歴を残す（監査対応・後工程への引継ぎに必須） |
④ 「修正不能なデータ」は廃棄か手動入力かを早期に経営判断する |
ETL（Extract / Transform / Load）とは、旧システムからデータを「抽出（Extract）」し、SAP S/4HANAのデータ形式に「変換（Transform）」し、SAPへ「ロード（Load）」する一連の処理を指す。データ移行プログラムの本質はこのETLの設計・開発である。
ETL開発の出発点は「移行マッピング定義書」の作成である。これは「旧システムのどのフィールドが、SAPのどのフィールドに、どのような変換ルールで対応するか」を定義した文書であり、業務コンサルタントとITの共同作業で作成される。
定義項目 | 記載内容 | 記載例 |
移行元 | 旧システムのテーブル名・フィールド名 | OLD_CUST.CUST_CODE（顧客コード10桁） |
移行先 | SAPのテーブル名・フィールド名 | KNA1-KUNNR（顧客コード10桁） |
変換ルール | データ変換のロジック | 旧コード（数字）→ 'C'+'旧コード' に変換 |
必須/任意 | 空値が許容されるか | 必須（空の場合は移行エラーとして排除） |
デフォルト値 | 旧システムに値がない場合のデフォルト | 国コード：旧になければ 'JP' をセット |
備考 | 業務的な注意点・確認中の事項 | 廃止コードの扱いを業務部門と要確認（未決） |
SAP S/4HANAへのデータロード手段は複数存在する。ツール選択はデータ種類・ボリューム・複雑さ・スケジュールによって判断する。
ツール | 概要 | 適合するデータ | 注意点 |
LTMC（Legacy Transfer Migration Cockpit） | SAP標準の移行ツール。テンプレートにExcelを流し込む方式 | マスタデータ（品目・顧客・仕入先） | 大量データはパフォーマンスに限界あり |
BAPI（Business API） | プログラミングでSAPの標準ビジネスロジック経由でロード | 受注・製造指図等のトランザクション | ロジックを通すためバリデーションが厳格 |
LSMW | 旧システムのデータ形式を直接SAPに変換するレガシーツール | マスタデータ（BOM・ルーティング） | SAP S/4HANAでは段階的に廃止予定 |
サードパーティ（例：Winshuttle/Precisely） | 高機能移行ツール。大量データ・並列処理に強い | 大量マスタ・複雑トランザクション | 追加ライセンスコストが発生 |
| コンサルタントの視点 | BAPIを使うべき場面でLTMCを使ったために「SAP標準のバリデーションを素通りしてデータが不整合状態でロードされた」という事例がある。ツール選定は「速さ」より「ビジネスロジックを正しく通しているか」で判断すべきである。 |
移行リハーサル（Mock Cutover）とは、本番カットオーバーと同一の手順・同一のデータ（または最新の旧システムデータのコピー）を使い、本番と同じ環境で移行を「事前に演じる」活動である。多くのプロジェクトでこのリハーサルが軽視されるが、経験豊かなプロジェクトマネージャーは「本番カットオーバーで初めて問題を発見するのは許されない」と断言する。
リハーサルを通じて確認すべきことは以下の通りである。
リハーサルで確認すべき5つのポイント |
① 移行プログラムが「本番規模のデータボリューム」で所定時間内に完了するか（パフォーマンス検証） |
② 各手順間の「切り替えタイミング」と「手動作業」の所要時間が見積もり通りか |
③ 移行後の整合性チェック（残高照合・レコード件数照合）が全て合格するか |
④ 移行エラーが発生した場合の「エラーハンドリング手順」が機能するか |
⑤ カットオーバー手順書（RunBook）の通りに実行できるか——すなわち「手順書の品質確認」 |
移行リハーサルを「1回やれば十分」と考えてはならない。第1回リハーサルは必ず予期しない問題が噴出する。第2回でそれを修正した状態を確認し、第3回（直前リハーサル）で「本番と同じ条件・同じスタッフ・同じ時間帯」でのドライランを実施する。このサイクルなしに本番カットオーバーへ進むことは、経験値もなく本番に臨むことと同義である。
リハーサル回 | 目的 | データ | 合格基準 |
第1回 Mock | 移行プログラムの動作確認・大きな問題の洗い出し | 設計フェーズ末時点のデータ（品質低） | エラーの特定・分類ができること |
第2回 Mock | 修正後プログラムの再確認・タイムライン把握 | テストフェーズ末時点のデータ（品質中） | タイムライン内完了・エラー率5%以下 |
第3回（Dress Rehearsal） | 本番同等の最終確認 | 直近の旧システムデータ（品質高） | 全整合性チェック合格・タイムライン通過 |
本番カットオーバーの手順は「RunBook」として文書化する。RunBookとは「誰が・何時に・何を・どの手順で実行するか」を分単位で記載した実行手順書であり、カットオーバー当日のすべての関係者が共通の「台本」として使用するものである。
RunBook必須記載項目 |
① カットオーバー全体スケジュール（開始〜完了までの時系列） |
② 各タスクの担当者・所要時間・依存関係 |
③ 旧システム停止タイミングとユーザーへの告知文 |
④ 移行プログラム実行順序・実行コマンド・完了確認方法 |
⑤ 整合性チェック項目一覧と合格基準（数値） |
⑥ GoサインとNoGoサインの判定基準・判定責任者 |
⑦ ロールバック手順（万一に備えた旧システム再起動手順） |
多くのSAP S/4HANA導入プロジェクトでは、本番カットオーバーを週末（金曜夜〜月曜朝）に設定する。これは業務停止の影響を最小化するためだが、裏を返せば「土日の48〜72時間で全ての移行を完了しなければならない」というプレッシャーを意味する。このプレッシャーに「準備された人間」と「準備されていない人間」では、パフォーマンスが根本的に異なる。
本番カットオーバーに臨む前に、「進む（Go）」と「引き返す（No-Go）」の判定基準を経営と事前合意しておかなければならない。これを怠ると、カットオーバー中に問題が発生した際に「続けるか止めるか」という判断が感情論になる。
判定条件 | Goの基準 | No-Goの基準 |
移行進捗 | 全移行タスクが所定時間+バッファ内に完了 | 重要タスクが2時間以上遅延し挽回見込みなし |
データ整合性 | 全整合性チェックが合格（許容エラー件数以内） | 主要残高データに未解決の不一致が存在 |
システム稼働 | 全重要業務トランザクションが正常動作確認 | 業務上不可欠な機能がカットオーバー後24時間以内に復旧見込みなし |
サポート体制 | ベンダーサポート・SIerオンコール体制が確立 | 主要技術担当者が不在でサポートが不確実 |
本番稼働開始後の最初の2〜4週間を「初期安定化フェーズ」と定義し、通常業務とは別に専任の支援体制を設けることが不可欠である。ユーザーは慣れないシステムで日常業務をこなしながら、多数の問い合わせ・エラー・運用上の疑問を抱える。この時期に手厚い支援がなければ、現場の不満がいつの間にか「SAPは使えない」というレッテルに変わる。
初期安定化フェーズの推奨体制 |
① 各部門にスーパーユーザーを配置し、現場の問合せに即座に対応 |
② SIer・SAP社のサポートデスクをホットライン化（電話番号を全ユーザーに周知） |
③ 日次・週次のインシデント件数をモニタリングし「減少傾向」を確認して安定化を宣言 |
④ データ移行の残課題（Post-migration Issues）を専任チームが対処 |
⑤ 本番稼働後30日以内の振り返り（Lessons Learned）会議を実施 |
リスク分類 | 具体的リスク | 影響度 | 発生確率 | 対策 |
データ品質 | クレンジング完了が遅延し、移行可能状態にならない | 高 | 高 | クレンジングKPIを週次管理・経営エスカレーション基準を設定 |
パフォーマンス | 移行プログラムがカットオーバー時間内に完了しない | 高 | 中 | 第1回リハーサルでタイムライン計測・並列化で高速化 |
整合性エラー | 移行後の残高・件数が旧システムと不一致 | 高 | 中 | 整合性チェックプログラムを事前開発・受入基準を定義 |
ロールバック不能 | 問題発生時に旧システムに戻せない | 高 | 低 | ロールバック手順を文書化・リハーサルで検証 |
マスタ依存関係エラー | 移行順序の誤りにより参照先が存在しない | 中 | 中 | 移行順序（依存関係）を設計段階で明示 |
組織抵抗 | 業務部門がクレンジング作業に協力しない | 中 | 高 | スポンサーによるトップダウンのコミット表明を獲得 |
データ移行のリスクは、発生してから経営に報告するのでは遅すぎる。プロジェクト開始時から「データ移行ステータスダッシュボード」を作成し、週次で経営に報告することを推奨する。ダッシュボードには「クレンジング完了率」「未解決課題件数」「リハーサル合格率」などの客観的指標を並べ、経営が「今データ移行の状況はどこにいるのか」を一目で把握できるようにする。
「問題が起きてから相談する」のではなく「問題が起きる前に相談できる関係」を経営と構築することが、データ移行プロジェクトを最終的に成功に導く最も重要な非技術的要因に他ならないのである。
以上