Home
Get Started
実践ガイド
外部仕様設計
バッチ処理仕様設計
UAC 仕様設計
データ仕様設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
移行計画の概要
既存システムから新システムへの円滑な移行を実現するため、移行の目的・方式・体制・対象範囲を定義し、関係者間で共通認識を形成します。
🎯 概要
- 目的: 既存システムから新システムへの円滑な移行を実現するため、移行の全体像・方針・体制を明確にし、関係者間で共通認識を形成する
- スコープ: 移行の目的、要件、方式、体制、対象範囲(システム・データ・ドキュメント)、前提条件・制約事項をカバーする。個別の移行手順の詳細は各移行計画書で定義
- 推奨する実施タイミング: 基本設計の中盤〜後半、詳細な移行計画立案の前に実施する
- 関連するステークホルダー: プロジェクトマネージャー、移行責任者、システムアーキテクト、インフラチーム、業務部門、運用チーム
📥 重要な前提知識・インプット
- 前提知識: システム移行プロジェクトの基本プロセス、移行方式(一括移行・段階的移行・並行稼働)の特徴、データ移行の基本技法、リスク管理手法
- インプット: 新システムの基本設計書、既存システムの構成情報・データ構造、要件定義書、非機能要件(特に業務停止許容時間)、業務スケジュール・制約条件
📄 成果物の定義
- ドキュメントテンプレート: 📄
[テンプレ]移行計画の概要
- 必須要素: 移行目的、移行要件・予定日、移行方式(全体フロー・パターン)、移行体制・役割分担・連絡体制、移行対象(システム・データ・ドキュメント)、移行対象外、前提条件・制約事項
✅ 品質基準・レビュー観点
✅ 品質チェックリスト:
| チェック項目 | チェック内容 |
|---|---|
| 移行対象の明確性 | 移行対象・対象外が明確に区分され、漏れがないか |
| 移行方式の妥当性 | 移行方式が要件・制約に照らして適切か |
| 体制の実効性 | 役割分担が明確で、必要なスキルを持つ担当者がアサインされているか |
| スケジュールの実現性 | 移行予定日・マイルストーンが現実的か |
| 前提条件の充足性 | 移行実施の前提条件が明確で、充足可能か |
👁️🗨️ レビュー観点:
- 移行要件との整合性: 業務停止時間、データ損失ゼロなどの要件が満たされる計画か
- 移行対象の網羅性: システム・データ・ドキュメントの移行対象が漏れなく定義されているか
- リスクへの対応: 移行失敗時の切り戻し、並行稼働期間など、リスク対策が考慮されているか
- ステークホルダーの合意: 業務部門・運用部門など、関係者の合意が得られる内容か
- 実行可能性: 体制・スケジュール・リソースの観点で実現可能な計画か
🧪成果物のサンプル
# 移行計画の概要
## 移行目的
本移行プロジェクトの目的を明確に記述します。
**記述例:**
- 老朽化した既存システムを最新技術スタックで刷新し、保守性・拡張性を向上させる
- 業務効率化を実現するための新機能を導入する
- システム運用コストを削減する
- データの一元管理により、情報の可視化と意思決定の迅速化を図る
---
## 移行要件
### 移行要件
- [要件定義書](./requirements.md)
**主要な移行要件:**
- データ損失ゼロ
- 業務停止時間: 最大XX時間以内
- データ整合性: 100%保証
- 性能要件: 移行後の応答時間がXX秒以内
### 移行予定日・期日
| マイルストーン | 予定日 | 備考 |
|------------|--------|------|
| 移行計画承認 | YYYY-MM-DD | |
| 移行リハーサル1回目 | YYYY-MM-DD | |
| 移行リハーサル2回目 | YYYY-MM-DD | |
| 本番移行作業 | YYYY-MM-DD | 業務停止時間: XX:XX~XX: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年分(2022年1月以降)を新システムへ移行
- **それ以前のデータ**: アーカイブとして別途保管し、参照用に保持
### 移行対象ドキュメント資産
| 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:XX ~ XX:XX
- 並行稼働期間: 最大XX週間
- ロールバック可能期間: 移行後XX時間以内
--- 🔄 設計の進め方・プロセス
🏗️ プロセス1: 移行目的と要件の整理
設計対象:
なぜ移行するのか(目的)、移行で達成すべきこと(要件)を明確にする。
具体例:
- 移行目的:老朽化対応、新機能追加、コスト削減、保守性向上など
- 移行要件:データ損失ゼロ、業務停止時間XX時間以内、データ整合性100%保証など
- 移行予定日・マイルストーン:移行リハーサル日程、本番移行日、並行稼働期間終了日
設計原則:
- 目的の明確化: なぜ移行するのかを明確にし、関係者で合意する
- 要件の定量化: 抽象的な要件ではなく、具体的な数値目標を設定する
- スケジュールの実現性: 業務スケジュールや制約を考慮し、実現可能な日程を設定する
- ステークホルダーとの調整: 業務部門・運用部門の要望を丁寧にヒアリングし、調整する
文書化の推奨表現:
- 移行目的の箇条書き: 3〜5項目程度で簡潔に記述する
- 移行要件一覧: 要件項目ごとに具体的な数値目標を記載する
- マイルストーン表: 重要な日程を一覧表で整理する
🏗️ プロセス2: 移行方式の選定
設計対象:
どのように移行するか(一括移行・段階的移行・並行稼働)を決定する。
具体例:
- 一括移行:週末などの業務停止時間にすべてを一度に移行
- 段階的移行:機能・モジュール単位で順次移行
- 並行稼働:新旧システムを同時稼働させ、徐々に切り替え
- 移行パターン:データ種別(マスタ・トランザクション・ファイル)ごとに方式を使い分け
設計原則:
- 業務影響の最小化: 業務停止時間を最小限に抑える方式を選択する
- リスクの分散: 一度にすべてを移行するのではなく、段階的に移行してリスクを分散する
- 検証可能性: 各段階で動作確認・データ検証ができる方式を採用する
- 切り戻し可能性: 移行失敗時に旧システムへ切り戻せる仕組みを確保する
文書化の推奨表現:
- 移行フロー図: データ抽出→変換→検証→投入の流れをフローチャートで表現する
- 移行パターン表: 移行対象ごとに移行パターンと理由を一覧化する
- 方式選定理由: なぜその方式を選んだのか、メリット・デメリットを記載する
🏗️ プロセス3: 移行体制・役割分担の決定
設計対象:
誰が何を担当するか(体制・役割分担)、どのように連絡するか(連絡体制)を決定する。
具体例:
- 移行責任者、データ移行担当、アプリケーション移行担当、インフラ移行担当など
- データ検証担当、業務検証担当、監視担当、障害対応担当など
- 通常時の報告ルート、緊急時のエスカレーションフローと連絡先
設計原則:
- 明確な責任分担: 誰が何を担当するかを明確にし、責任の所在を明らかにする
- スキルマッチング: 各役割に必要なスキルを持つ担当者をアサインする
- バックアップ体制: 主担当が不在の場合の代理者を明確にする
- 迅速な意思決定: 緊急時に素早く判断・対応できる体制を整備する
文書化の推奨表現:
- 体制図: 組織構造と報告ラインを図示する
- 役割分担表: 役割、担当者名、所属、責務を一覧化する
- 連絡体制図: 通常時・緊急時の連絡フローを明記する
🏗️ プロセス4: 移行対象の洗い出しと整理
設計対象:
何を移行するか(移行対象)、何を移行しないか(移行対象外)を明確にする。
具体例:
- 移行対象システム・機能:基幹システム、周辺システム、連携システムなど
- 移行対象データ:マスタデータ、トランザクションデータ、ファイルデータなど
- データ移行対象期間:全期間、過去3年分、過去5年分など
- 移行対象ドキュメント:運用手順書、マニュアル、設計書など
設計原則:
- 対象の網羅性: 移行すべきものが漏れなく洗い出されているか確認する
- 対象外の明確化: 移行対象外とするものとその理由を明確にする
- 優先度付け: 移行の優先度を設定し、段階的移行の順序を決める
- データ量の把握: データ件数・サイズを概算し、移行時間を見積もる
文書化の推奨表現:
- 移行対象一覧表: システム・データ・ドキュメントを種別ごとに一覧化する
- 移行対象範囲図: 全体像をツリー構造やマインドマップで視覚化する
- 対象外項目リスト: 対象外とする項目と理由、代替措置を記載する
🏗️ プロセス5: 前提条件・制約事項の整理
設計対象:
移行を実施するための前提条件、移行実施時の制約事項を整理する。
具体例:
- 前提条件:新システム開発完了、移行ツール動作検証完了、移行リハーサル環境準備完了など
- 制約事項:業務停止可能時間、移行作業実施可能時間帯、並行稼働期間、ロールバック可能期間など
設計原則:
- 前提条件の明確化: 移行開始前に満たすべき条件を明確にする
- 制約の現実性: 業務やシステムの実態を踏まえた現実的な制約を設定する
- リスクの洗い出し: 前提が満たされない場合のリスクを識別する
- 代替策の検討: 制約が厳しすぎる場合の代替案を準備する
文書化の推奨表現:
- 前提条件チェックリスト: 移行開始前に確認すべき項目を列挙する
- 制約事項一覧: 制約の種類(時間・期間・リソースなど)ごとに整理する
- 充足状況の記録: 各前提条件の充足状況と未充足時の対応策を記載する
🚨 よくある失敗と予防策
🚧 実例収集後、追記予定
📚 参考資料・関連リンク
- 参考文献: 『システム移行プロジェクト実践ガイド』、IPA「システム移行計画ガイドライン」、経済産業省「IT システム刷新のためのデータ移行ガイドブック」
- 関連する他のガイド: データ移行設計ガイド、移行リハーサル計画ガイド、旧システムの扱いガイド、切り戻し計画ガイド
- ツール・テンプレート: 移行計画書テンプレート、移行体制図テンプレート、移行チェックリストテンプレート
テンプレートサイト: 📄テンプレート集