レッスン5：データ移行と業務プロセス変更

このレッスンで学ぶこと

既存データの整備（棚卸し・クレンジング・マッピング・移行テスト）の型を持てる
業務プロセスの Before/After 図の作り方を持てる
標準化と例外の切り分けの判断軸を持つ
並行運用期間の設計とカットオーバー判断を扱える

前レッスンでは導入プロジェクトのキックオフと WBS を扱いました。本レッスンでは、WBS 5 領域の中でも最も工数と難易度が高いデータ移行と業務プロセス変更を扱います。データが正確に移行できなければ SaaS は使えず、業務プロセスが整理されていなければ SaaS は形骸化します。

データ移行の 5 ステップ

データ移行は、単に古い箱から新しい箱に移すのではなく、「移行前の整備」「マッピング」「移行テスト」「本番移行」「移行後の検証」の 5 ステップで進めます。

graph LR
    A[Step 1<br/>棚卸し] --> B[Step 2<br/>クレンジング]
    B --> C[Step 3<br/>マッピング]
    C --> D[Step 4<br/>移行テスト]
    D --> E[Step 5<br/>本番移行と検証]

Step 1：棚卸し

既存システムに含まれるデータ種類と件数の把握
データ元の担当部門・データオーナーの特定
移行対象・非対象の切り分け

Step 2：クレンジング

重複データの排除
不要データの削除（何年以上前のものは移行しないなど）
データ形式の統一（日付形式・電話番号形式）
欠損データの補完または削除

クレンジングは業務側と共同で行います。IT 側だけの判断でデータを削除すると、業務で必要な履歴が失われる可能性があります。

Step 3：マッピング

既存データ項目と SaaS のデータ項目の対応付け
変換ルールの定義（例：既存の顧客区分「A・B・C・D」を SaaS の「大手・中堅・SMB」に変換）
マスタデータの対応表作成

マッピングは移行スクリプトの設計図となります。ここで抜け漏れがあると、後工程で気付いたときの手戻りが大きくなります。

Step 4：移行テスト

サンプルデータで移行を試行
移行後の SaaS 側でのデータ確認
移行エラーの解消
本番移行のリハーサル（複数回実施）

移行テストは 3〜 5 回の複数回リハーサルが標準です。1 回目では想定していなかった問題が必ず発生します。

Step 5：本番移行と検証

移行実施日の設定（多くは週末や連休を利用）
移行スクリプト実行
移行後の件数確認・サンプルチェック
業務側による受け入れテスト

移行完了後、業務側担当者が実業務で使用し、データが正しく移行されているかを確認します。

業務プロセスの Before/After 図

SaaS 導入は、多くの場合「既存の業務プロセスをそのまま SaaS に移す」だけでは失敗します。SaaS の設計思想に合わせて業務プロセスを再設計する必要があります。

Before/After 図の作り方

現行の業務プロセスと導入後のプロセスを、次の 4 要素で比較します。

担当者：誰がやっていたか vs 誰がやるか
入力：何を入力していたか vs 何を入力するか
処理：どこで判断していたか vs SaaS がどこまで自動化するか
出力：何を出していたか vs 何が出るか

例：受注管理業務の Before/After

Before（現行）：

営業がメールで受注情報を受領
営業事務が Excel の受注管理表に手入力
営業事務が会計システム用の入力データを作成
経理が会計システムに入力

After（SaaS 導入後）：

営業が SaaS の受注入力画面で直接入力
SaaS が会計システムと API 連携して自動転送
経理は SaaS の受注データを検証するのみ

Before/After を可視化することで、「誰の業務がなくなるか」「誰の業務が増えるか」が明確になります。これは社内浸透（次レッスン）の重要な前提情報です。

標準化と例外の切り分け

業務プロセス変更で必ず問題になるのが「例外業務」の扱いです。

例外の 3 分類

本質的例外：顧客との契約上どうしても発生する例外（大口顧客向け特別対応など）
歴史的例外：過去の経緯で残っているが、業務上の必然性が低い例外
属人的例外：特定担当者の判断で行われている、標準化されていない例外

判断の 3 原則

本質的例外は、SaaS のカスタマイズまたは手動運用を継続
歴史的例外は、この機会に廃止するのが原則
属人的例外は、業務プロセスの標準化を進める

例外を全てそのまま SaaS に持ち込むと、カスタマイズが膨らみ、SaaS の設計思想と乖離した「使いにくいシステム」ができあがります。SaaS 導入は業務プロセス整理の絶好の機会でもあります。

並行運用期間の設計

既存システムと SaaS を並行運用することで、切替リスクを段階的に低減します。

並行運用の 3 パターン

完全並行：全ユーザーが両システムに同じデータを入力（1〜 2 週間）
部門並行：一部部門が SaaS に先行移行、他部門は既存システム継続（1〜 3 か月）
機能並行：一部機能を SaaS で先行運用、他機能は既存システム継続（1〜 3 か月）

会社の規模と業務の性質で使い分けます。中堅企業では「部門並行」が最も採用されるパターンです。

並行運用期間の設計原則

期間中の業務負荷増加を許容する（残業代・応援体制の予算確保）
並行運用中に発見された問題を SaaS 側に反映
業務側からのフィードバックを継続的に収集
並行運用終了の判断基準を事前に設定

カットオーバー判断

カットオーバーは、既存システムを停止し SaaS 単独運用に切り替える判断です。買い手 PM が最終判断を下します。

カットオーバー判断の 5 基準

移行データの完全性（サンプルチェックで 99 % 以上の一致）
業務側の習熟度（キーユーザーが独力で運用可能）
未解決課題の重要度（高リスクの未解決課題ゼロ）
ヘルプデスクの準備完了（FAQ 整備・対応体制構築）
経営側の意思決定（ステアリング委員会での承認）

5 基準を満たさない場合、カットオーバーを延期します。焦って切り替えると、業務停止・データ棄損・社内信頼失墜のリスクがあります。

次のステップ

本レッスンではデータ移行と業務プロセス変更を扱いました。次のレッスンでは、SaaS 導入プロジェクトで最も見落とされがちな「社内浸透とチェンジマネジメント」を扱い、導入後 90 日で使われる SaaS にするための型を組み立てます。

確認クイズ

このレッスンで学んだ内容を確認しましょう。