旧システムの扱い

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[テンプレ]移行後の旧システムの扱い
  • 必須要素: 旧システム稼働期間・運用方針、役割整理(残存処理の有無)、アクセス管理方針、旧データ参照方法、バックアップ・保管方針、停止・廃棄計画、保守契約・ライセンス終了スケジュール、リスクと対策、ステークホルダー役割分担、停止チェックリスト
✅ 品質基準・レビュー観点

品質チェックリスト:

チェック項目 チェック内容
法令準拠 データ保存期間が関連法令の要件を満たしているか
アクセス制限 アクセス権限の段階的縮小計画が明確か
データ保全性 バックアップ・アーカイブの取得と検証が計画されているか
セキュアな廃棄 データ消去方式が適切に定義されているか
契約処理 保守契約・ライセンスの終了手続きとスケジュールが明確か

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

  • 法令・コンプライアンス: 会社法・法人税法・電子帳簿保存法などの保存義務が適切に考慮されているか
  • 業務継続性: 旧システム停止後も必要なデータ参照が可能な仕組みが確保されているか
  • リスク対策: 急停止や誤利用、データ漏洩などのリスクへの対策が十分か
  • コスト削減効果: 保守契約終了によるコスト削減効果が明確に算定されているか
  • ステークホルダー合意: 法務・監査・経理など関連部門の確認と承認が得られているか
🧪成果物のサンプル
# 旧システムの扱い

本章では、新システムへの移行完了後における旧システムの取り扱いについて定義する。

---

## 旧システムの稼働期間・運用方針

移行後の旧システムを「いつまで・どのように」稼働させるかを明確にする。

### 稼働期間

| 項目 | 日程・期間 | 備考 |
|------|-----------|------|
| 移行完了日 | YYYYMMDD| 新システム本番稼働開始日 |
| 暫定併用期間 | 移行後1ヶ月間 | 並行稼働による安定性確認 |
| 閲覧専用化 | YYYYMMDD| 新規入力・更新を停止 |
| 完全停止予定日 | YYYYMMDD| 旧システムのシャットダウン |

### 運用方針

- **移行直後(1ヶ月間)**: 新旧システム並行稼働
  - 新システムをメインとして運用
  - 旧システムは参照・検証用として維持
  - データ整合性の確認を実施
- **閲覧専用期間(3ヶ月間)**: 
  - 新規入力・更新機能を停止
  - 過去データの参照のみ可能
  - 法務・経理・監査部門の要求に対応
- **完全停止後**:
  - アーカイブデータのみ保管
  - システムは完全にシャットダウン

### データ参照の必要性

| 部門 | 参照目的 | 必要期間 | 対応方法 |
|------|---------|---------|---------|
| 法務部 | 契約書・取引履歴の確認 | 10年間 | アーカイブDB作成 |
| 経理部 | 会計帳簿・証憑の確認 | 7年間 | アーカイブDB作成 |
| 監査部 | 過去取引の監査対応 | 7年間 | アーカイブDB作成 |
| 営業部 | 顧客対応履歴の確認 | 1年間 | 旧システム閲覧専用化 |

---

## 旧システムの役割整理(移行後に残る処理の有無)

### 残存する処理・機能

```mermaid
graph LR
    A[旧システム] --> B[過去データ閲覧]
    A --> C[帳票出力]
    A --> D[履歴検索]
    
    E[新システム] --> F[新規入力]
    E --> G[業務処理]
    E --> H[レポート作成]
```

| 処理・機能 | 実施システム | 理由 | 期間 |
|-----------|------------|------|------|
| 過去データ閲覧 | 旧システム | 移行対象外データの参照 | 移行後6ヶ月 |
| 特定帳票出力 | 旧システム | 旧フォーマットでの出力要求 | 移行後3ヶ月 |
| 過去取引履歴検索 | 旧システム | 検索機能の移行が未完了 | 移行後1|
| 新規取引入力 | 新システム | - | - |
| 日次バッチ処理 | 新システム | - | - |

### 残存業務の責任主体

- **期間**: 移行後6ヶ月間
- **責任部署**: システム運用部
- **担当者**: 旧システム保守担当チーム
- **エスカレーション先**: プロジェクトマネージャー

---

## 旧システムのアクセス管理

### アクセス権限方針

```mermaid
graph TD
    A[移行完了] --> B[全ユーザーアクセス可能]
    B --> C[1ヶ月後: 閲覧専用化]
    C --> D[参照権限者のみアクセス可能]
    D --> E[3ヶ月後: アクセス制限強化]
    E --> F[運用担当者のみアクセス可能]
    F --> G[6ヶ月後: システム停止]
```

### アクセス権限の段階的縮小

| 期間 | アクセス可能者 | 権限内容 | 認証方法 |
|------|--------------|---------|---------|
| 移行直後~1ヶ月 | 全ユーザー | 参照・検証 | 既存ID/パスワード |
| 1ヶ月~3ヶ月 | 参照権限者のみ | 参照のみ | 既存ID/パスワード |
| 3ヶ月~6ヶ月 | 運用担当者のみ | 参照・保守 | 多要素認証 |
| 6ヶ月以降 | アクセス不可 | - | - |

### 参照権限者の定義

- システム運用部(全員)
- 法務部(部長・課長)
- 経理部(部長・課長)
- 監査部(全員)
- プロジェクトマネージャー

### ID停止スケジュール

1. **移行後1週間**: 新システムへの移行状況を確認
2. **移行後1ヶ月**: 一般ユーザーのIDを無効化
3. **移行後3ヶ月**: 参照権限のみのユーザーIDを無効化
4. **移行後6ヶ月**: すべてのIDを無効化

---

## 旧データの参照方法

### 過去データの取り扱い

| データ種別 | 保管方法 | 保管期間 | 参照方法 |
|-----------|---------|---------|---------|
| 取引データ(直近3) | 新システムに移行 | 無期限 | 新システムから参照 |
| 取引データ(3年以前) | 旧システムDB | 7年間 | アーカイブDBから参照 |
| 契約書・証憑 | 文書管理システム | 10年間 | 文書管理システムから参照 |
| ログ・監査証跡 | アーカイブストレージ | 7年間 | 専用ツールで参照 |
| 帳票・レポート | PDFアーカイブ | 7年間 | ファイルサーバーから参照 |

### 閲覧専用DBの構築

```mermaid
graph LR
    A[旧システムDB] -->|データ抽出| B[アーカイブDB]
    B --> C[閲覧専用インターフェース]
    C --> D[権限者のみアクセス]
    
    E[バックアップ] --> B
```

**構築内容:**
- 旧システムDBのスナップショットを作成
- 読み取り専用のレプリカDBを構築
- 簡易検索・閲覧用のWebインターフェースを提供
- アクセスログを記録

### 法令要件による保存期間

| 法令 | 対象データ | 保存期間 |
|------|-----------|---------|
| 会社法 | 会計帳簿・計算書類 | 10|
| 法人税法 | 帳簿書類 | 7|
| 電子帳簿保存法 | 電子取引データ | 7|
| 個人情報保護法 | 個人データ | 利用目的達成後速やかに削除 |

---

## 旧システムのバックアップ・保管方針

### バックアップ方針

| バックアップ種別 | 取得タイミング | 保管期間 | 保管場所 |
|----------------|--------------|---------|---------|
| 最終フルバックアップ | 移行完了日 | 10年間 | オフサイトストレージ |
| 閲覧専用化時 | 閲覧専用化日 | 7年間 | オフサイトストレージ |
| システム停止時 | 停止日 | 7年間 | オフサイトストレージ |
| 月次バックアップ | 閲覧専用期間中 | 3世代 | オンサイトストレージ |

### バックアップ媒体の管理

**暗号化:**
- AES-256による暗号化
- 暗号鍵は専用の鍵管理システムで管理
- 鍵のアクセスは権限者のみに制限

**保管場所:**
- オンサイト: 社内データセンター(耐火金庫)
- オフサイト: クラウドストレージ(冗長化構成)
- 物理媒体: 遠隔地の保管施設

**管理責任者:**
- システム運用部長
- 情報セキュリティ責任者

---

## 旧システムの停止・廃棄計画

### システム停止フロー

```mermaid
graph TD
    A[停止2週間前] --> B[関係者への通知]
    B --> C[最終バックアップ取得]
    C --> D[停止1週間前: 停止リハーサル]
    D --> E[停止前日: 最終確認]
    E --> F[停止当日: システム停止]
    F --> G[サービス停止]
    G --> H[バッチ停止]
    H --> I[DBシャットダウン]
    I --> J[サーバー停止]
    J --> K[停止完了確認]
    K --> L[完了報告]
```

### 停止作業手順(概要)

1. **サービス停止**
   - Webアプリケーションの停止
   - APIサービスの停止
   - ユーザーアクセスの遮断

2. **バッチ処理停止**
   - スケジュールジョブの停止
   - 実行中バッチの完了待機

3. **データベースシャットダウン**
   - トランザクションの完了確認
   - DBの正常シャットダウン

4. **サーバー停止**
   - アプリケーションサーバー停止
   - DBサーバー停止
   - ネットワーク機器の設定変更

### システム資源の廃棄方針

| 資源種別 | 廃棄方法 | 実施時期 | 責任者 |
|---------|---------|---------|-------|
| 物理サーバー | データ消去後、リース返却 | 停止後1ヶ月以内 | インフラ部 |
| 仮想サーバー | インスタンス削除 | 停止後1週間以内 | インフラ部 |
| ストレージ | データ消去、解約 | 停止後1ヶ月以内 | インフラ部 |
| ネットワーク機器 | 設定削除、解約 | 停止後2週間以内 | ネットワーク部 |

### データ消去方式

- **HDD/SSD**: DoD 5220.22-M方式(3回上書き)
- **クラウドストレージ**: プロバイダーの削除機能 + 削除証明書取得
- **バックアップ媒体**: 物理的破壊(保管期間終了後)

---

## 旧システムの保守契約・ライセンスの扱い

### 保守契約の終了スケジュール

| 契約種別 | ベンダー | 契約終了日 | 手続き期限 | 削減効果 |
|---------|---------|-----------|-----------|---------|
| システム保守 | A| YYYYMMDD| 3ヶ月前通知 | 年間XXX万円 |
| データベース保守 | B| YYYYMMDD| 2ヶ月前通知 | 年間XXX万円 |
| インフラ保守 | C| YYYYMMDD| 1ヶ月前通知 | 年間XXX万円 |

### ライセンスの扱い

| ライセンス | 扱い | 手続き | 備考 |
|-----------|------|-------|------|
| OS(サーバー) | 解約 | リース返却時に自動終了 | - |
| データベース | 解約 | ベンダーへ解約申請 | 3ヶ月前通知 |
| アプリケーション | 解約 | ベンダーへ解約申請 | 1ヶ月前通知 |
| ミドルウェア | 新システムへ移管 | ライセンス移管手続き | 可能な場合 |

---

## 旧システム関連のリスクと対策

### リスクマトリクス

| リスク | 影響度 | 発生確率 | 対策 |
|-------|-------|---------|------|
| 旧システムが急停止し参照不可 ||| 必要データを事前にアーカイブDBへ移行 |
| 誤って旧システムに入力・利用 ||| 閲覧専用化、アクセス制限、警告表示 |
| 保守契約終了後に不具合発生 ||| 停止前の安定化チェック、詳細な運用手順書作成 |
| バックアップデータの復旧不可 ||| 定期的なリストアテスト実施 |
| 法令要件を満たさない早期廃棄 ||| 法務部による保存期間の事前確認 |
| データ漏洩(廃棄時) ||| 適切なデータ消去方式の採用、証明書取得 |

### 対策詳細

**1. 急停止対策:**
- 重要データのアーカイブDB移行を完了させる
- 閲覧専用期間中も定期的なヘルスチェックを実施
- 障害時の復旧手順を事前に準備

**2. 誤入力防止:**
- ログイン画面に「閲覧専用」の警告表示
- 入力フォームを無効化
- 定期的な利用状況モニタリング

**3. 保守終了後の対応:**
- 停止前に十分な安定稼働期間を確保
- 詳細な運用マニュアル・トラブルシューティングガイドを作成
- 緊急時の連絡体制を整備

---

## 旧システムに関するステークホルダーの役割

### 役割分担表

| 役割 | 担当部署・担当者 | 責任範囲 |
|------|----------------|---------|
| 停止判断者 | 顧客責任者(システム部長) | 最終的な停止判断・承認 |
| 停止作業実施者 | インフラ部・運用部門 | システム停止作業の実施 |
| データ管理責任者 | システム部・DBA | バックアップ・アーカイブの管理 |
| 監査対応 | 監査部 | 停止プロセスの監査、コンプライアンス確認 |
| 法務確認 | 法務部 | 保存期間・データ廃棄の法的妥当性確認 |
| 経理確認 | 経理部 | 契約終了・コスト削減効果の確認 |
| プロジェクト管理 | プロジェクトマネージャー | 全体スケジュール管理・調整 |

### 意思決定プロセス

```mermaid
graph TD
    A[停止提案] --> B[PM: 関係者調整]
    B --> C[各部門確認]
    C --> D{法務・監査承認}
    D -->|承認| E[顧客責任者: 最終判断]
    D -->|差し戻し| B
    E -->|承認| F[停止作業実施]
    E -->|延期| B
    F --> G[完了報告]
```

### 確認事項(部門別)

**監査部:**
- 停止プロセスが内部統制に準拠しているか
- 証跡が適切に保管されているか
- データ保存期間が法令要件を満たしているか

**法務部:**
- 契約上の保存義務が履行されているか
- 個人情報の適切な削除が行われるか
- ライセンス契約の解約手続きが適切か

**経理部:**
- 保守契約終了による削減効果の確認
- 残存資産の適切な処理
- 予算への影響確認

---

## 旧システム停止チェックリスト

### 停止前チェック

- [ ] 関係者全員への通知完了(2週間前)
- [ ] 最終バックアップ取得完了
- [ ] アーカイブDBの構築完了
- [ ] 法務・監査部門の承認取得
- [ ] 保守契約の解約手続き完了
- [ ] ライセンス契約の解約手続き完了
- [ ] 停止手順書のレビュー完了
- [ ] 緊急連絡体制の確認完了

### 停止作業中チェック

- [ ] サービス停止完了
- [ ] バッチ処理停止完了
- [ ] データベースの正常シャットダウン完了
- [ ] サーバーの停止完了
- [ ] ネットワーク設定変更完了
- [ ] 停止作業ログの記録完了

### 停止後チェック

- [ ] 停止完了の確認
- [ ] アーカイブデータの参照可能性確認
- [ ] 関係者への完了報告
- [ ] 停止作業報告書の作成
- [ ] 資産管理台帳の更新
- [ ] データ消去作業の計画策定

---

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


🏗️ プロセス1: 法令要件とデータ保存期間の確定

設計対象:

旧システムのデータを「どの法令に基づいて・どの期間」保存する必要があるかを法務部門と協議し、確定する。

具体例:

  • 会社法:会計帳簿・計算書類の10年保存義務
  • 法人税法:帳簿書類の7年保存義務
  • 電子帳簿保存法:電子取引データの7年保存義務
  • 個人情報保護法:利用目的達成後の速やかな削除義務
  • 業界固有の法規制(金融商品取引法、医薬品医療機器等法など)

設計原則:

  • コンプライアンス優先: 法令要件は必ず満たし、違反リスクを排除する
  • 最長期間の採用: 複数の法令が適用される場合は、最も長い保存期間を採用する
  • 証跡の確保: 法務部門との協議内容と判断根拠を文書化し、監査対応に備える
  • 余裕を持った期間設定: 法定保存期間に加えて、数ヶ月の余裕期間を設ける

文書化の推奨表現:

  • 法令要件マトリクス: データ種別ごとに適用される法令、保存期間、保存方法を一覧表にまとめる
  • 法務部門確認記録: 協議日時、参加者、確認事項、承認者を記録する
  • 例外事項の明記: 特定のデータに対する特別な取り扱いがある場合は明示する
🏗️ プロセス2: 旧システム稼働期間と運用方針の策定

設計対象:

移行完了後、旧システムを「いつまで・どのように」稼働させるかを決定する。

具体例:

  • 移行直後の並行稼働期間(データ整合性確認用)
  • 閲覧専用化のタイミングと期間
  • 完全停止のタイミング
  • 各期間におけるアクセス権限の縮小計画
  • 残存する処理・機能の洗い出し(過去データ閲覧、帳票出力など)

設計原則:

  • 段階的な縮小: いきなり停止せず、並行稼働→閲覧専用→停止と段階的に移行する
  • ユーザー部門との調整: 各部門のデータ参照ニーズを丁寧にヒアリングする
  • リスクヘッジ: 新システムの安定稼働を確認できるまで、旧システムを維持する
  • 透明性の確保: 各段階のスケジュールと目的を関係者全員に事前通知する

文書化の推奨表現:

  • 稼働期間一覧表: 移行完了日、並行稼働期間、閲覧専用化日、停止予定日を明記する
  • 運用方針の記述: 各期間における旧システムの役割、利用目的、制限事項を説明する
  • 部門別ニーズ表: 各部門が必要とするデータ参照期間と理由を整理する
🏗️ プロセス3: アクセス管理とデータ参照方法の設計

設計対象:

旧システムへのアクセス権限を段階的に縮小する計画と、停止後のデータ参照方法を設計する。

具体例:

  • 移行直後:全ユーザーがアクセス可能
  • 閲覧専用化後:参照権限者のみアクセス可能
  • 停止前:運用担当者のみアクセス可能
  • 停止後:アーカイブDBから参照
  • 閲覧専用DBの構築(スナップショット、レプリカDB、簡易検索UI)

設計原則:

  • 最小権限の原則: 各段階で必要最小限のアクセス権限のみを付与する
  • 監査証跡の記録: アクセスログを記録し、誰がいつ何を参照したかを追跡可能にする
  • 利便性の確保: 停止後も必要なデータは簡易に参照できる仕組みを提供する
  • 多要素認証の導入: セキュリティレベルの高い期間では多要素認証を要求する

文書化の推奨表現:

  • アクセス権限遷移図: 時系列でアクセス権限がどのように変化するかを図示する
  • 参照権限者リスト: 各期間でアクセス可能な部署・役職を明記する
  • アーカイブDB構築仕様: データ抽出方法、レプリカDB構成、検索UIの機能を記載する
🏗️ プロセス4: バックアップ・停止・廃棄計画の策定

設計対象:

旧システムのバックアップ方針、停止作業手順、システム資源の廃棄方法を決定する。

具体例:

  • 最終フルバックアップの取得タイミング
  • バックアップ媒体の暗号化・保管場所・管理責任者
  • システム停止フロー(サービス停止→バッチ停止→DB停止→サーバー停止)
  • データ消去方式(DoD 5220.22-M、物理破壊など)
  • サーバー・ストレージ・ネットワーク機器の廃棄方法

設計原則:

  • 確実なバックアップ: 停止前に複数世代のバックアップを取得し、リストアテストで検証する
  • 段階的な停止: 一度に全てを停止せず、サービス→バッチ→DB→サーバーの順に段階的に停止する
  • セキュアな廃棄: データ漏洩リスクを排除するため、確実なデータ消去を実施する
  • 証明書の取得: クラウドストレージ等では削除証明書を取得し、コンプライアンス対応する

文書化の推奨表現:

  • バックアップ方針表: バックアップ種別、取得タイミング、保管期間、保管場所を整理する
  • 停止フロー図: システム停止の手順をフローチャートで視覚化する
  • 廃棄方針表: 資源種別ごとに廃棄方法、実施時期、責任者を明記する
🏗️ プロセス5: 契約終了とコスト削減効果の算定

設計対象:

保守契約・ライセンスの終了手続きと、削減できるコストを算定する。

具体例:

  • システム保守契約の解約手続きと通知期限
  • データベース・OS・ミドルウェアライセンスの解約
  • 新システムへ移管可能なライセンスの洗い出し
  • 年間削減効果の算定(保守費用、ライセンス費用、インフラ費用)

設計原則:

  • 契約条件の確認: 解約通知期限、違約金、自動更新条項を事前に確認する
  • ライセンス移管の検討: 新システムで利用可能なライセンスは移管し、コストを最小化する
  • 経理部門との連携: 削減効果を正確に算定し、予算計画に反映する
  • 早期通知: ベンダーへの解約通知は余裕を持って実施する

文書化の推奨表現:

  • 契約終了スケジュール表: 契約種別ごとに終了日、手続き期限、担当者を整理する
  • コスト削減効果表: 年間削減額を費目別に算定し、累計効果を示す
  • ライセンス移管計画: 移管可能なライセンスと手続き方法を明記する
🏗️ プロセス6: リスク対策とステークホルダー役割の明確化

設計対象:

旧システム停止に伴うリスクを洗い出し、対策を講じる。また、関係部門の役割を明確化する。

具体例:

  • 急停止リスク:アーカイブDB移行、ヘルスチェック、復旧手順
  • 誤利用リスク:閲覧専用化、警告表示、利用状況モニタリング
  • データ漏洩リスク:データ消去、削除証明書取得
  • 停止判断者、停止作業実施者、データ管理責任者の役割分担
  • 法務・監査・経理の確認事項と承認プロセス

設計原則:

  • リスクベース・アプローチ: 影響度と発生確率に基づいて優先順位を付ける
  • 多層防御: 単一の対策に依存せず、複数の対策を組み合わせる
  • 明確な責任分担: 誰が何をいつまでに実施するかを明確にする
  • 承認プロセスの整備: 法務・監査・経理の確認と最終承認者を定める

文書化の推奨表現:

  • リスクマトリクス: リスク事象、影響度、発生確率、対策を一覧化する
  • 役割分担表: 役割、担当部署・担当者、責任範囲を明記する
  • 意思決定フロー図: 停止提案から承認、実施、完了報告までのプロセスを図示する

🚨 よくある失敗と予防策 


🚧 実例収集後、追記予定

📚 参考資料・関連リンク


  • 参考法令: 会社法、法人税法、電子帳簿保存法、個人情報保護法
  • 参考資料: 『システム移行のベストプラクティス』、経済産業省「システム移行ガイドライン」、IPA「データ保存・廃棄ガイド」
  • 関連する他のガイド: システム移行設計ガイド、データアーカイブ設計ガイド、セキュリティ設計ガイド
  • ツール・テンプレート: システム停止チェックリスト、契約終了管理表、リスクマトリクステンプレート


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