# データの移行

## 移行対象データの範囲

### 移行対象データ一覧

本プロジェクトで移行対象とするデータの範囲を以下に示します。

| No | データ種別 | テーブル/ファイル名 | 移行対象範囲 | 件数(概算) | 優先度 |
|----|----------|------------------|-------------|------------|--------|
| 1 | マスタ | 顧客マスタ | 全件 | 10,000件 | High |
| 2 | マスタ | 商品マスタ | 全件 | 5,000件 | High |
| 3 | マスタ | 社員マスタ | 全件 | 500件 | High |
| 4 | トランザクション | 受注データ | 過去3年分 | 50,000件 | High |
| 5 | トランザクション | 売上データ | 過去3年分 | 80,000件 | High |
| 6 | トランザクション | 在庫データ | 最新のみ | 3,000件 | Middle |
| 7 | ログ | アクセスログ | 移行対象外 | - | - |

**記述例:**
- **マスタデータ**: 最新の有効データを全件移行
- **トランザクションデータ**: 2022年1月以降のデータを移行対象とする
- **履歴データ**: 過去5年分の履歴を保持

### 移行対象外データ

以下のデータは移行対象外とします。

| No | データ種別 | 理由 | 代替措置 |
|----|----------|------|---------|
| 1 | テストデータ | 新システムで再作成 | 新規作成 |
| 2 | 削除済みデータ | 業務上不要 | 参照用に旧環境保管 |
| 3 | 2021年以前のログ | 保管義務なし | 廃棄 |

---

## 移行方式

### 移行方式の選定

本プロジェクトでは、以下の理由により**一括移行方式**を採用します。

**選定理由:**
- システム規模が中小規模であり、移行データ量が限定的
- 業務停止時間(週末48時間)が確保可能
- 並行稼働によるデータ不整合リスクを回避したい
- コスト・期間の観点から最も効率的

### 移行方式の比較

```mermaid
graph LR
    A[移行方式] --> B[一括移行]
    A --> C[段階移行]
    A --> D[並行稼働]
    
    B --> B1[採用]
    C --> C1[不採用]
    D --> D1[不採用]
    
    style B1 fill:#90EE90
    style C1 fill:#FFB6C1
    style D1 fill:#FFB6C1
```

| 方式 | メリット | デメリット | 判定 |
|------|---------|-----------|------|
| 一括移行 | ・シンプルで管理しやすい<br>・データ不整合が発生しにくい<br>・コストが最小 | ・業務停止時間が必要<br>・失敗時の影響大 | ✅採用 |
| 段階移行 | ・リスク分散可能<br>・業務影響を最小化 | ・複雑で工数大<br>・データ整合性管理が困難 | ❌不採用 |
| 並行稼働 | ・リスク最小<br>・段階的な切替可能 | ・二重メンテナンス<br>・同期の複雑さ<br>・コスト大 | ❌不採用 |

---

## 移行方法(技術的アプローチ)

### データ移行フロー

```mermaid
graph LR
    A[旧システム] -->|①抽出| B[変換処理]
    B -->|②変換| C[検証]
    C -->|③検証| D[新システム]
    D -->|④登録| E[確認]
    
    B -.エラー.-> F[エラーログ]
    C -.エラー.-> F
    D -.エラー.-> F
```

### 移行処理の流れ

#### データ抽出(Extract)

**方法:**
- 旧システムのDBから直接SQL抽出
- またはCSVエクスポート機能を使用

**抽出ツール:**
- 標準: SQL*Loader / mysqldump
- カスタムツール: 移行用Pythonスクリプト

**記述例:**
```sql
-- 顧客マスタ抽出クエリ
SELECT 
    customer_id,
    customer_name,
    email,
    registration_date
FROM customers
WHERE delete_flag = 0;
```

#### データ変換(Transform)

**変換処理内容:**
- 文字コード変換(Shift-JIS → UTF-8)
- 日付フォーマット統一(YYYYMMDD → YYYY-MM-DD)
- コード体系変換(旧コード → 新コード)
- NULL値の処理

**変換ツール:**
- ETLツール: Talend / Pentaho
- スクリプト: Python pandas

**記述例:**
```python
# 日付フォーマット変換
df['registration_date'] = pd.to_datetime(
    df['registration_date'], 
    format='%Y%m%d'
).dt.strftime('%Y-%m-%d')
```

#### データ検証(Validation)

**検証項目:**
- 必須項目チェック
- データ型チェック
- 桁数チェック
- 重複チェック
- 参照整合性チェック

**検証基準:**
| 検証項目 | 判定基準 | 対応 |
|---------|---------|------|
| エラー率 | 0.1%未満 | エラーデータは手動修正 |
| 件数一致 | 100% | 不一致時は原因調査 |

#### データ登録(Load)

**登録方法:**
- バルクインサート(一括登録)
- APIによる登録
- 手動登録(例外のみ)

**登録順序:**
```mermaid
graph TD
    A[マスタデータ] --> B[トランザクションデータ]
    
    A1[顧客マスタ] --> A
    A2[商品マスタ] --> A
    A3[社員マスタ] --> A
    
    B1[受注データ] --> B
    B2[売上データ] --> B
```

---

## データ変換の考え方

### マッピング定義

旧システムから新システムへのデータ項目対応を定義します。

#### マッピング定義例:顧客マスタ

| No | 旧項目名 | 新項目名 | 変換ルール | 備考 |
|----|---------|---------|-----------|------|
| 1 | CUST_ID | customer_id | そのまま | 主キー |
| 2 | CUST_NAME | customer_name | トリム処理 | 前後空白削除 |
| 3 | MAIL_ADDR | email | 小文字変換 | 正規化 |
| 4 | REG_DATE | registration_date | YYYY-MM-DD形式 | 日付変換 |
| 5 | DEL_FLG | is_deleted | 0→false, 1→true | boolean変換 |

### コード変換定義

コード体系が変更される場合の変換ルールを定義します。

#### コード変換例:都道府県コード

| 旧コード | 新コード | 都道府県名 |
|---------|---------|-----------|
| 01 | 13 | 東京都 |
| 02 | 27 | 大阪府 |
| 03 | 14 | 神奈川県 |

### データ変換の例外処理

**NULL値の扱い:**
- 必須項目でNULLの場合: デフォルト値を設定
- 任意項目でNULLの場合: NULLのまま移行

**不正データの扱い:**
- エラーリスト出力
- 業務部門と協議の上、手動修正

---

## 移行・並行稼働期間のデータ同期

### データ同期の必要性

本プロジェクトでは**一括移行方式**を採用するため、基本的に並行稼働期間は設けません。
ただし、以下のケースで一時的な同期が必要となる場合があります。

**同期が必要なケース:**
- リハーサル後の本番移行までの期間(差分データのみ)
- 移行失敗時の切り戻し後の再移行

### 差分データ同期方式

```mermaid
graph LR
    A[旧システム] -->|①変更データ抽出| B[差分ファイル]
    B -->|②差分適用| C[新システム]
    
    A -.タイムスタンプで判定.-> B
```

**同期対象:**
- リハーサル実施日以降に更新されたデータのみ

**同期頻度:**
- 本番移行直前の1回のみ

**同期方法:**
- タイムスタンプによる差分抽出
- 更新日時が最新のデータのみを対象

---

## リハーサル

移行リハーサルの詳細については、**6.5 移行リハーサル**の章を参照してください。

**リハーサルの目的:**
- 移行手順の妥当性確認
- 移行時間の計測
- エラー発生時の対応確認

**リハーサル実施回数:**
- 最低2回(初回リハーサル + 本番前最終リハーサル)

---

## リスクとバックアップ

移行リスクと切り戻し方針の詳細については、**6.3 移行リスク管理・切り戻し**の章を参照してください。

**主要なリスク:**
- データ移行失敗
- 移行時間の超過
- データ不整合の発生

**バックアップ方針:**
- 移行前: 旧システムの完全バックアップ取得
- 移行後: 新システムの初期バックアップ取得
- 保管期間: 最低3ヶ月

**切り戻し判断基準:**
- 重大な業務影響が発生した場合
- データ不整合が許容範囲を超えた場合
- 移行時間が予定を大幅に超過した場合

---

## 移行ツール

### 使用ツール一覧

| ツール名 | 用途 | 選定理由 |
|---------|------|---------|
| Python pandas | データ変換 | 柔軟性・拡張性が高い |
| MySQL Workbench | データ抽出・登録 | 標準ツールで安定性が高い |
| Excel | マッピング定義管理 | 業務部門との共有が容易 |

### カスタムツールの開発

以下のカスタムツールを開発します。

**データ検証ツール:**
- 入力: 変換後CSVファイル
- 処理: 必須チェック、形式チェック、重複チェック
- 出力: エラーリスト(CSV)

**差分抽出ツール:**
- 入力: 旧システムDB
- 処理: タイムスタンプによる差分判定
- 出力: 差分データ(CSV)

---

## 移行データの品質管理

### 品質基準

| 品質項目 | 目標値 | 測定方法 |
|---------|-------|---------|
| データ完全性 | 100% | 件数突合 |
| データ正確性 | 99.9%以上 | サンプリング検証 |
| エラー率 | 0.1%未満 | エラーログ集計 |

### 検証手順

```mermaid
graph TD
    A[移行実施] --> B[件数チェック]
    B --> C{一致?}
    C -->|Yes| D[サンプリング検証]
    C -->|No| E[原因調査]
    E --> F[修正]
    F --> A
    D --> G{OK?}
    G -->|Yes| H[移行完了]
    G -->|No| E
```

**検証レベル:**
1. **全件検証**: 件数、主キー、必須項目
2. **サンプリング検証**: 10%抽出による詳細確認
3. **業務検証**: 業務部門による受入確認

---