移行計画の概要

Home

📕Arrow icon of a page linkサンエムシステム 上流工程標準(Preview版)

⚖️Arrow icon of a page linkサンエムシステム上流工程 標準規格

📘Arrow icon of a page link要件定義 実践ガイド

📘Arrow icon of a page link基本設計 実践ガイド

📄Arrow icon of a page linkテンプレート集

Get Started

📄Arrow icon of a page link基本設計工程のルール

📄Arrow icon of a page link基本設計書の構成を決める

🚧Arrow icon of a page link基本設計のプロセスモデル

実践ガイド

文書情報
システム方式設計
外部仕様設計
運用設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
レビュー・承認

移行計画の概要

既存システムから新システムへの円滑な移行を実現するため、移行の目的・方式・体制・対象範囲を定義し、関係者間で共通認識を形成します。

🎯 概要


  • 目的: 既存システムから新システムへの円滑な移行を実現するため、移行の全体像・方針・体制を明確にし、関係者間で共通認識を形成する
  • スコープ: 移行の目的、要件、方式、体制、対象範囲(システム・データ・ドキュメント)、前提条件・制約事項をカバーする。個別の移行手順の詳細は各移行計画書で定義
  • 推奨する実施タイミング: 基本設計の中盤〜後半、詳細な移行計画立案の前に実施する
  • 関連するステークホルダー: プロジェクトマネージャー、移行責任者、システムアーキテクト、インフラチーム、業務部門、運用チーム

📥 重要な前提知識・インプット


  • 前提知識: システム移行プロジェクトの基本プロセス、移行方式(一括移行・段階的移行・並行稼働)の特徴、データ移行の基本技法、リスク管理手法
  • インプット: 新システムの基本設計書、既存システムの構成情報・データ構造、要件定義書、非機能要件(特に業務停止許容時間)、業務スケジュール・制約条件

📄 成果物の定義


  • ドキュメントテンプレート: 📄Arrow icon of a page link[テンプレ]移行計画の概要
  • 必須要素: 移行目的、移行要件・予定日、移行方式(全体フロー・パターン)、移行体制・役割分担・連絡体制、移行対象(システム・データ・ドキュメント)、移行対象外、前提条件・制約事項
✅ 品質基準・レビュー観点

品質チェックリスト:

チェック項目 チェック内容
移行対象の明確性 移行対象・対象外が明確に区分され、漏れがないか
移行方式の妥当性 移行方式が要件・制約に照らして適切か
体制の実効性 役割分担が明確で、必要なスキルを持つ担当者がアサインされているか
スケジュールの実現性 移行予定日・マイルストーンが現実的か
前提条件の充足性 移行実施の前提条件が明確で、充足可能か

👁️‍🗨️ レビュー観点:

  • 移行要件との整合性: 業務停止時間、データ損失ゼロなどの要件が満たされる計画か
  • 移行対象の網羅性: システム・データ・ドキュメントの移行対象が漏れなく定義されているか
  • リスクへの対応: 移行失敗時の切り戻し、並行稼働期間など、リスク対策が考慮されているか
  • ステークホルダーの合意: 業務部門・運用部門など、関係者の合意が得られる内容か
  • 実行可能性: 体制・スケジュール・リソースの観点で実現可能な計画か
🧪成果物のサンプル
# 移行計画の概要

## 移行目的

本移行プロジェクトの目的を明確に記述します。

**記述例:**
- 老朽化した既存システムを最新技術スタックで刷新し、保守性・拡張性を向上させる
- 業務効率化を実現するための新機能を導入する
- システム運用コストを削減する
- データの一元管理により、情報の可視化と意思決定の迅速化を図る

---

## 移行要件

### 移行要件

- [要件定義書](./requirements.md)

**主要な移行要件:**
- データ損失ゼロ
- 業務停止時間: 最大XX時間以内
- データ整合性: 100%保証
- 性能要件: 移行後の応答時間がXX秒以内

### 移行予定日・期日

| マイルストーン | 予定日 | 備考 |
|------------|--------|------|
| 移行計画承認 | YYYY-MM-DD | |
| 移行リハーサル1回目 | YYYY-MM-DD | |
| 移行リハーサル2回目 | YYYY-MM-DD | |
| 本番移行作業 | YYYY-MM-DD | 業務停止時間: XX:XXXX:XX |
| 新システム稼働開始 | YYYY-MM-DD | |
| 並行稼働期間終了 | YYYY-MM-DD | |

---

## 移行方式

### 移行方式の概要

```mermaid
graph LR
    A[旧システム] -->|データ抽出| B[移行ツール]
    B -->|データ変換| C[一時領域]
    C -->|データ検証| D{検証OK?}
    D -->|Yes| E[新システム]
    D -->|No| F[エラー処理]
    F --> B
    E -->|並行稼働| G[新旧システム併用期間]
    G --> H[旧システム停止]
```

**採用方式:** [一括移行 / 段階的移行 / 並行稼働]

**記述例:**
本プロジェクトでは、業務への影響を最小化するため「段階的移行」方式を採用します。
機能モジュール単位で順次移行を行い、各段階で動作確認を実施した上で次の移行に進みます。

### 移行パターン

| 移行対象 | 移行パターン | 理由 |
|---------|------------|------|
| マスタデータ | 一括移行 | データ量が少なく、整合性確保が容易 |
| トランザクションデータ | 段階的移行 | データ量が多く、検証に時間を要するため |
| ファイルデータ | 並行稼働後移行 | 業務影響を最小化するため |

---

## 移行体制および役割分担

### 移行体制図

```mermaid
graph TD
    A[プロジェクト統括責任者] --> B[移行責任者]
    B --> C[移行作業チーム]
    B --> D[検証チーム]
    B --> E[運用チーム]
    C --> F[データ移行担当]
    C --> G[アプリケーション移行担当]
    C --> H[インフラ移行担当]
    D --> I[データ検証担当]
    D --> J[業務検証担当]
    E --> K[監視担当]
    E --> L[障害対応担当]
```

### 役割分担表

| 役割 | 氏名 | 所属 | 主な責務 |
|------|------|------|---------|
| プロジェクト統括責任者 | [氏名] | [部署] | 移行プロジェクト全体の統括、最終意思決定 |
| 移行責任者 | [氏名] | [部署] | 移行作業全体の管理、進捗管理、課題対応 |
| データ移行担当 | [氏名] | [部署] | データ抽出・変換・投入の実施 |
| アプリケーション移行担当 | [氏名] | [部署] | アプリケーション設定移行、動作確認 |
| インフラ移行担当 | [氏名] | [部署] | 環境構築、ネットワーク設定 |
| データ検証担当 | [氏名] | [部署] | 移行データの整合性検証 |
| 業務検証担当 | [氏名] | [部署] | 業務シナリオテスト実施 |
| 監視担当 | [氏名] | [部署] | 移行作業中のシステム監視 |
| 障害対応担当 | [氏名] | [部署] | 移行時の障害対応、切り戻し判断 |

### 連絡体制

**通常時:**
- 定例会議: 毎週[曜日] XX:XX- 報告ルート: 担当者 → 移行責任者 → 統括責任者

**緊急時:**
- エスカレーションフロー: 担当者 → 移行責任者(15分以内)統括責任者(30分以内)
- 緊急連絡先: [電話番号、メールアドレス、チャットチャンネル等]

---

## 移行対象

### 移行対象範囲の全体像

```mermaid
graph TB
    A[移行対象全体] --> B[システム・機能]
    A --> C[データ]
    A --> D[ドキュメント資産]
    B --> B1[基幹システム]
    B --> B2[周辺システム]
    C --> C1[マスタデータ]
    C --> C2[トランザクションデータ]
    C --> C3[ファイルデータ]
    D --> D1[運用手順書]
    D --> D2[設計書]
```

### 移行対象システム・機能

| No | システム名 | 機能名 | 移行方式 | 優先度 | 備考 |
|----|----------|--------|---------|--------|------|
| 1 | [システムA] | [機能1] | 一括移行 || |
| 2 | [システムA] | [機能2] | 段階的移行 || |
| 3 | [システムB] | [機能3] | 並行稼働 || |

**記述例:**
- **基幹システム**: 顧客管理、受注管理、在庫管理の3機能を移行対象とする
- **周辺システム**: 帳票出力システム、メール配信システムを移行対象とする
- **連携システム**: 外部APIとの連携設定を新システムに移行する

### 移行対象データ

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

| No | データ種別 | テーブル/ファイル名 | 件数(概算) | サイズ | 移行方式 |
|----|----------|------------------|----------|--------|---------|
| 1 | マスタ | 顧客マスタ | 10,000| 10MB | 一括移行 |
| 2 | マスタ | 商品マスタ | 50,000| 50MB | 一括移行 |
| 3 | トランザクション | 受注データ | 1,000,000| 1GB | 段階的移行 |
| 4 | トランザクション | 売上データ | 5,000,000| 5GB | 段階的移行 |
| 5 | ファイル | 請求書PDF | 100,000ファイル | 50GB | 並行稼働後移行 |

#### データ移行対象期間

```mermaid
gantt
    title データ移行対象期間
    dateFormat YYYY-MM-DD
    section マスタデータ
    全期間対象 :done, 2020-01-01, 2025-12-31
    section トランザクションデータ
    過去3年分 :done, 2022-01-01, 2025-12-31
    section アーカイブデータ
    過去5年分 :done, 2020-01-01, 2025-12-31
```

**記述例:**
- **マスタデータ**: 全期間のデータを移行対象とする
- **トランザクションデータ**: 過去3年分(20221月以降)を新システムへ移行
- **それ以前のデータ**: アーカイブとして別途保管し、参照用に保持

### 移行対象ドキュメント資産

| No | ドキュメント種別 | ドキュメント名 | 移行方法 | 備考 |
|----|--------------|-------------|---------|------|
| 1 | 運用手順書 | 日次バッチ実行手順 | 新システム用に更新 | |
| 2 | 運用手順書 | 障害対応手順 | 新システム用に更新 | |
| 3 | 設計書 | 基本設計書 | 参照用に保管 | 旧システムのまま |
| 4 | マニュアル | ユーザーマニュアル | 新システム用に全面改訂 | |
| 5 | 規程類 | システム運用規程 | 内容確認後、必要に応じて改訂 | |

**ドキュメント移行フロー:**

```mermaid
graph LR
    A[旧ドキュメント] --> B{新システムで<br/>使用可能?}
    B -->|Yes| C[そのまま移行]
    B -->|No| D[更新・改訂]
    D --> E[レビュー]
    E --> F[承認]
    F --> G[新ドキュメント管理システムへ登録]
    C --> G
```

---

## 移行対象外

以下は本プロジェクトの対象外とします:

**システム・機能:**
- [システム名/機能名]: [対象外とする理由]
- **記述例**: レガシー帳票システム: 利用頻度が低く、コスト対効果が見込めないため

**データ:**
- [データ種別]: [対象外とする理由]
- **記述例**: 2020年以前のアーカイブデータ: 法令上の保管義務がなく、参照頻度が極めて低いため

**ドキュメント:**
- [ドキュメント種別]: [対象外とする理由]
- **記述例**: 開発時の議事録: 保管義務はあるが、新システムでの利用予定がないため旧環境に保管

### 対象外項目の管理方針

| 対象外項目 | 理由 | 代替措置 | 担当者 |
|----------|------|---------|--------|
| [項目名] | [理由] | [代替措置の内容] | [氏名] |

**記述例:**
- 旧システムのテストデータは移行対象外とし、新システムで新規作成する
- 廃止予定の機能に関するドキュメントは、参照用として旧環境に1年間保管後、廃棄する

---

## 移行の前提条件・制約事項

### 前提条件
- 新システムの開発・テストが完了していること
- 移行ツールの動作検証が完了していること
- 移行リハーサル環境が準備されていること
- 業務部門の受入テストが完了していること

### 制約事項
- 業務停止可能時間: 最大XX時間
- 移行作業実施可能時間帯: [曜日] XX:XXXX:XX
- 並行稼働期間: 最大XX週間
- ロールバック可能期間: 移行後XX時間以内

---

🔄 設計の進め方・プロセス


🏗️ プロセス1: 移行目的と要件の整理

設計対象:

なぜ移行するのか(目的)、移行で達成すべきこと(要件)を明確にする。

具体例:

  • 移行目的:老朽化対応、新機能追加、コスト削減、保守性向上など
  • 移行要件:データ損失ゼロ、業務停止時間XX時間以内、データ整合性100%保証など
  • 移行予定日・マイルストーン:移行リハーサル日程、本番移行日、並行稼働期間終了日

設計原則:

  • 目的の明確化: なぜ移行するのかを明確にし、関係者で合意する
  • 要件の定量化: 抽象的な要件ではなく、具体的な数値目標を設定する
  • スケジュールの実現性: 業務スケジュールや制約を考慮し、実現可能な日程を設定する
  • ステークホルダーとの調整: 業務部門・運用部門の要望を丁寧にヒアリングし、調整する

文書化の推奨表現:

  • 移行目的の箇条書き: 3〜5項目程度で簡潔に記述する
  • 移行要件一覧: 要件項目ごとに具体的な数値目標を記載する
  • マイルストーン表: 重要な日程を一覧表で整理する
🏗️ プロセス2: 移行方式の選定

設計対象:

どのように移行するか(一括移行・段階的移行・並行稼働)を決定する。

具体例:

  • 一括移行:週末などの業務停止時間にすべてを一度に移行
  • 段階的移行:機能・モジュール単位で順次移行
  • 並行稼働:新旧システムを同時稼働させ、徐々に切り替え
  • 移行パターン:データ種別(マスタ・トランザクション・ファイル)ごとに方式を使い分け

設計原則:

  • 業務影響の最小化: 業務停止時間を最小限に抑える方式を選択する
  • リスクの分散: 一度にすべてを移行するのではなく、段階的に移行してリスクを分散する
  • 検証可能性: 各段階で動作確認・データ検証ができる方式を採用する
  • 切り戻し可能性: 移行失敗時に旧システムへ切り戻せる仕組みを確保する

文書化の推奨表現:

  • 移行フロー図: データ抽出→変換→検証→投入の流れをフローチャートで表現する
  • 移行パターン表: 移行対象ごとに移行パターンと理由を一覧化する
  • 方式選定理由: なぜその方式を選んだのか、メリット・デメリットを記載する
🏗️ プロセス3: 移行体制・役割分担の決定

設計対象:

誰が何を担当するか(体制・役割分担)、どのように連絡するか(連絡体制)を決定する。

具体例:

  • 移行責任者、データ移行担当、アプリケーション移行担当、インフラ移行担当など
  • データ検証担当、業務検証担当、監視担当、障害対応担当など
  • 通常時の報告ルート、緊急時のエスカレーションフローと連絡先

設計原則:

  • 明確な責任分担: 誰が何を担当するかを明確にし、責任の所在を明らかにする
  • スキルマッチング: 各役割に必要なスキルを持つ担当者をアサインする
  • バックアップ体制: 主担当が不在の場合の代理者を明確にする
  • 迅速な意思決定: 緊急時に素早く判断・対応できる体制を整備する

文書化の推奨表現:

  • 体制図: 組織構造と報告ラインを図示する
  • 役割分担表: 役割、担当者名、所属、責務を一覧化する
  • 連絡体制図: 通常時・緊急時の連絡フローを明記する
🏗️ プロセス4: 移行対象の洗い出しと整理

設計対象:

何を移行するか(移行対象)、何を移行しないか(移行対象外)を明確にする。

具体例:

  • 移行対象システム・機能:基幹システム、周辺システム、連携システムなど
  • 移行対象データ:マスタデータ、トランザクションデータ、ファイルデータなど
  • データ移行対象期間:全期間、過去3年分、過去5年分など
  • 移行対象ドキュメント:運用手順書、マニュアル、設計書など

設計原則:

  • 対象の網羅性: 移行すべきものが漏れなく洗い出されているか確認する
  • 対象外の明確化: 移行対象外とするものとその理由を明確にする
  • 優先度付け: 移行の優先度を設定し、段階的移行の順序を決める
  • データ量の把握: データ件数・サイズを概算し、移行時間を見積もる

文書化の推奨表現:

  • 移行対象一覧表: システム・データ・ドキュメントを種別ごとに一覧化する
  • 移行対象範囲図: 全体像をツリー構造やマインドマップで視覚化する
  • 対象外項目リスト: 対象外とする項目と理由、代替措置を記載する
🏗️ プロセス5: 前提条件・制約事項の整理

設計対象:

移行を実施するための前提条件、移行実施時の制約事項を整理する。

具体例:

  • 前提条件:新システム開発完了、移行ツール動作検証完了、移行リハーサル環境準備完了など
  • 制約事項:業務停止可能時間、移行作業実施可能時間帯、並行稼働期間、ロールバック可能期間など

設計原則:

  • 前提条件の明確化: 移行開始前に満たすべき条件を明確にする
  • 制約の現実性: 業務やシステムの実態を踏まえた現実的な制約を設定する
  • リスクの洗い出し: 前提が満たされない場合のリスクを識別する
  • 代替策の検討: 制約が厳しすぎる場合の代替案を準備する

文書化の推奨表現:

  • 前提条件チェックリスト: 移行開始前に確認すべき項目を列挙する
  • 制約事項一覧: 制約の種類(時間・期間・リソースなど)ごとに整理する
  • 充足状況の記録: 各前提条件の充足状況と未充足時の対応策を記載する

🚨 よくある失敗と予防策 


🚧 実例収集後、追記予定

📚 参考資料・関連リンク


  • 参考文献: 『システム移行プロジェクト実践ガイド』、IPA「システム移行計画ガイドライン」、経済産業省「IT システム刷新のためのデータ移行ガイドブック」
  • 関連する他のガイド: データ移行設計ガイド、移行リハーサル計画ガイド、旧システムの扱いガイド、切り戻し計画ガイド
  • ツール・テンプレート: 移行計画書テンプレート、移行体制図テンプレート、移行チェックリストテンプレート


テンプレートサイト: 📄Arrow icon of a page linkテンプレート集