# 移行のステークホルダー調整

## 移行のステークホルダー

| 分類 | 組織・部門 | 役割 | 主な関与フェーズ |
|-----|----------|------|---------------|
| 顧客側 | 事業部門 | 業務オーナー、業務確認担当 | 計画、リハーサル、本番 |
| 顧客側 | システム部門 | システム責任者、技術レビュー | 全フェーズ |
| 顧客側 | 運用部門 | 運用リーダー、監視担当 | 本番、移行後 |
| 顧客側 | 管理部門 | 承認者、意思決定者 | 計画、本番GO判断 |
| ベンダー側 | 開発チーム | 移行作業実施、技術支援 | 全フェーズ |
| ベンダー側 | 移行担当 | 移行計画策定、作業指揮 | 全フェーズ |
| ベンダー側 | 品質保証 | テスト実施、品質確認 | リハーサル、本番 |
| ベンダー側 | インフラ | 環境構築、インフラ対応 | 準備、本番 |
| 外部 | クラウド事業者 | インフラ提供、技術サポート | 準備、本番 |
| 外部 | 関連システムベンダー | 連携調整、停止・再開対応 | 計画、本番 |

---

## ステークホルダーの役割・責任

### 役割・責任マトリクス

| 役割 | 作業実施 | 作業確認 | 判定・承認 | 指揮・意思決定 | 障害対応 |
|-----|---------|---------|----------|--------------|---------|
| PM | - | ○ | ◎ | ◎ | ◎ |
| 移行担当 | ◎ | ○ | ○ | ○ | ◎ |
| 開発チーム | ◎ | ○ | - | - | ◎ |
| インフラチーム | ◎ | ○ | - | - | ◎ |
| 業務オーナー | - | ◎ | ○ | ○ | ○ |
| 運用リーダー | ○ | ◎ | - | - | ◎ |
| 事業責任者 | - | - | ◎ | ◎ | ○ |

**凡例**: ◎=主担当、○=副担当・支援、-=関与なし

### 詳細な役割定義

#### 作業実施(データ移行、設定作業)
- **主担当**: 移行担当、開発チーム、インフラチーム  
- **責任範囲**:
  - データ移行スクリプトの実行  
  - システム設定の変更作業  
  - 環境構築・切り替え作業  
  - 作業手順書に基づく正確な実施  

#### 作業確認(業務確認、スモークテスト)
- **主担当**: 業務オーナー、運用リーダー  
- **副担当**: PM、移行担当、開発チーム  
- **責任範囲**:
  - 移行後のデータ整合性確認  
  - 業務機能の動作確認  
  - スモークテストの実施・判定  
  - 確認結果の記録・報告  

#### 判定および承認
- **主担当**: PM、事業責任者  
- **副担当**: 業務オーナー、移行担当  
- **責任範囲**:
  - 移行成功/失敗の判定  
  - 次フェーズへの移行承認  
  - 切り戻し判断  
  - 最終GO/No Go決定  

#### 移行当日の指揮・意思決定
- **主担当**: PM、事業責任者  
- **副担当**: 移行担当、業務オーナー  
- **責任範囲**:
  - 作業全体の進行管理  
  - イレギュラー発生時の判断  
  - ステークホルダー間の調整  
  - タイムライン管理  

#### 障害発生時の対応・連絡系統

```mermaid
graph TD
    A[障害検知] --> B[一次対応: 移行担当/開発/インフラ]
    B --> C{復旧可能?}
    C -->|Yes| D[復旧作業実施]
    C -->|No/判断困難| E[PM へエスカレーション]
    D --> F[動作確認]
    E --> G{影響範囲判断}
    G -->|軽微| H[継続判断]
    G -->|重大| I[事業責任者へエスカレーション]
    F --> J{正常?}
    J -->|Yes| K[作業継続]
    J -->|No| E
    I --> L[切り戻し判断]
    H --> M[対策実施]
```

---

## 調整が必要となる事項

| No | 調整事項 | 調整先 | 調整期限 | 優先度 | 
|----|---------|--------|---------|--------|
| 1 | 移行日程の確定 | 事業部門、関連システム | 本番2ヶ月前 | 高 |
| 2 | 業務停止の許容範囲 | 業務オーナー、事業責任者 | 本番1.5ヶ月前 | 高 |
| 3 | 関係システムとの止め方・再開方法 | 関連システムベンダー | 本番1ヶ月前 | 高 |
| 4 | データ移行範囲・方式 | 業務部門、システム部門 | 本番1.5ヶ月前 | 高 |
| 5 | 本番移行当日の立会体制 | 全ステークホルダー | 本番3週間前 | 中 
| 6 | 移行後の確認項目 | 業務オーナー、運用部門 | 本番3週間前 | 中 |
| 7 | 切り戻し判断基準 | PM、事業責任者 | 本番1ヶ月前 | 高 |

---

## コミュニケーション計画

### コミュニケーション体制図

```mermaid
graph TD
    A[定例会議] --> B[進捗報告]
    A --> C[課題・リスク共有]
    D[日常連絡] --> E[メール]
    D --> F[チャット Teams/Slack]
    G[移行当日] --> H[専用チャットルーム]
    G --> I[電話連絡網]
    G --> J[対策本部]
```

---

## 承認プロセス

### 承認フロー図

```mermaid
graph TD
    A[移行計画書作成] --> B[移行担当レビュー]
    B --> C[PMレビュー]
    C --> D[業務オーナー承認]
    D --> E[事業責任者承認]
    
    F[リハーサル実施] --> G[結果報告書作成]
    G --> H[PM評価]
    H --> I[業務オーナー確認]
    I --> J[事業責任者承認]
    
    K[本番移行判断] --> L[PM判定]
    L --> M[業務オーナー確認]
    M --> N[事業責任者GO/No Go決定]
    
    O[切り戻し判断] --> P[PM判断]
    P --> Q[事業責任者承認]
```

---

## 合意事項の記録方法

### 合意事項の記録・管理場所

移行に関する合意事項は、以下の場所に記録・管理する。

- **移行管理台帳(Excel/スプレッドシート)**: 合意事項の一覧、変更履歴、承認状況を一元管理
- **議事録(Word/Notion/Confluence等)**: 会議での合意内容、決定事項、アクションアイテムを記録
- **変更管理システム(Jira/Redmine等)**: 変更要求の起票、承認フロー、実施状況を追跡
- **共有フォルダ/ドキュメント管理システム**: 承認済み文書(移行計画書、作業手順書等)のバージョン管理
- **メール/チャットログ**: 日常的な確認事項や軽微な合意のエビデンスとして保管

**記録時の注意事項:**

- 合意日時、合意者、合意内容を明確に記載する
- 変更が発生した場合は、変更前後の内容と変更理由を記録する
- 承認者の署名または電子承認の証跡を残す
- 関係者がアクセス可能な場所に保管し、最新版を常に参照できるようにする

### 移行計画の変更管理
```mermaid
graph TD
    A[変更要求発生] --> B[影響範囲分析]
    B --> C{再承認必要?}
    C -->|Yes| D[関係者へ変更内容通知]
    C -->|No| E[軽微な変更として記録]
    D --> F[再承認プロセス実施]
    F --> G[合意履歴更新]
    E --> G
    G --> H[変更管理台帳に記録]
```

---