関連テンプレ構成
テンプレート
# 移行後のアフターフォロー
本章では、システム移行完了後の安定稼働を確保するためのフォローアップ計画について記載する。
移行直後は予期しない問題が発生する可能性が高いため、集中的なサポート体制を構築し、
早期に問題を検知・対応することで、業務への影響を最小限に抑える。
---
## アフターフォロー期間
### 期間の定義
| フェーズ | 期間 | 主な活動 |
|---------|------|---------|
| 集中フォロー期 | 移行後1週間 | 24時間監視体制、即座のトラブル対応 |
| 初期安定期 | 移行後2〜4週間 | 営業時間内の優先サポート、傾向分析 |
| 通常運用移行期 | 移行後5〜8週間 | 段階的に通常保守体制へ移行 |
### 終了判断基準
以下の条件を満たした場合、通常運用(保守)へ移行する:
- 重大インシデントが2週間以上発生していない
- 問い合わせ件数が想定レベル以下に安定している
- 業務部門から安定稼働の確認が得られている
- 移行起因の未解決問題がない
---
## サポート体制
### 体制図
```mermaid
graph TD
A[利用者] -->|問い合わせ| B[一次窓口]
B -->|業務関連| C[顧客運用部門]
B -->|システム関連| D[ベンダーサポート窓口]
D --> E[アプリ担当]
D --> F[インフラ担当]
D --> G[移行担当]
E --> H[エスカレーション管理者]
F --> H
G --> H
```
### ベンダー側体制
| 役割 | 担当者 | 連絡先 | 対応時間 |
|------|--------|--------|---------|
| サポート窓口 | 山田太郎 | support@vendor.com / 03-xxxx-xxxx | 平日 9:00-18:00 |
| アプリ担当 | 佐藤花子 | app-team@vendor.com | 平日 9:00-20:00 |
| インフラ担当 | 鈴木一郎 | infra-team@vendor.com | 平日 9:00-20:00 |
| 移行担当 | 田中次郎 | migration@vendor.com | 平日 9:00-18:00 |
| エスカレーション責任者 | 高橋三郎 | manager@vendor.com / 090-xxxx-xxxx | 24時間(緊急時) |
### 顧客側体制
| 役割 | 部門 | 連絡先 | 対応時間 |
|------|------|--------|---------|
| 運用部門窓口 | 情報システム部 運用課 | it-ops@customer.com | 平日 8:30-17:30 |
| 業務部門窓口 | 営業部 システム推進担当 | sales-sys@customer.com | 平日 9:00-18:00 |
### 連絡手段
- **通常時**: 専用チケットシステム(Backlog)
- **緊急時(重大インシデント)**: 電話 + Teams通話
- **定例報告**: メール + 週次ミーティング(Teams)
### 夜間・休日体制
**集中フォロー期間中(移行後1週間):**
- ベンダー側: オンコール体制(24時間対応可能)
- 顧客側: 緊急連絡先を事前登録
**初期安定期間以降:**
- 重大インシデントのみ夜間対応
- 中程度以下は翌営業日対応
---
## アフターフォローの対応範囲
### 対応範囲内
- 移行作業に起因する不具合の一次切り分け・対応
- 移行後の設定漏れ・動作不具合の対応
- 利用者からの初期問い合わせ支援
- 業務マニュアル・操作案内の補足説明
- 関係システムとの接続不具合の初期対応
- データ移行結果の再検証
- 性能劣化への対応
### 対応範囲外
- 移行と無関係な既存機能の不具合(通常保守で対応)
- 新規機能追加の要望(別途改修案件として起票)
- 利用者教育・研修(別途トレーニング計画で実施)
- 仕様変更を伴う改善要望(バックログ化し、優先度評価後に対応)
### 緊急性が低い改善要望の扱い
```mermaid
graph LR
A[改善要望] --> B{緊急性・影響度}
B -->|高| C[即時対応]
B -->|中| D[バックログ登録]
B -->|低| E[次期改修で検討]
D --> F[優先度評価会議]
F --> G[開発計画への組み込み]
```
---
## 優先度・対応方針
### 優先度定義
| 優先度 | 影響範囲 | 業務影響 | 対応目標時間 | 対応時間帯 |
|--------|---------|---------|------------|----------|
| P1(重大) | 全社または主要業務 | 業務停止 | 1時間以内に一次対応開始 | 24時間対応 |
| P2(高) | 特定部門または機能 | 一部機能に影響 | 4時間以内に対応開始 | 営業時間内優先対応 |
| P3(中) | 限定的 | 運用代替可能 | 当日中に対応開始 | 営業時間内対応 |
| P4(低) | 個別ユーザー | 影響軽微 | 翌営業日対応 | 営業時間内対応 |
### 対応フロー
```mermaid
graph TD
A[インシデント受付] --> B[優先度判定]
B --> C{P1?}
C -->|Yes| D[即時対応開始]
C -->|No| E{P2?}
E -->|Yes| F[4時間以内対応]
E -->|No| G{P3?}
G -->|Yes| H[当日中対応]
G -->|No| I[翌営業日対応]
D --> J[解決・クローズ]
F --> J
H --> J
I --> J
J --> K[報告・ナレッジ化]
```
### エスカレーション基準
以下の場合、エスカレーション責任者へ即座に報告:
- P1インシデントが発生した場合
- 初動対応から2時間経過しても解決見込みが立たない場合
- 複数の部門・システムに影響が拡大する可能性がある場合
- 顧客責任者からのエスカレーション要請があった場合
---
## 問い合わせ・インシデントの受付方法
### 受付チャネル
| チャネル | 用途 | 受付時間 | 対応SLA |
|---------|------|---------|---------|
| チケットシステム | 通常の問い合わせ・インシデント | 24時間受付 | 営業時間内4時間以内に一次回答 |
| 電話(サポート窓口) | 緊急度の高い問い合わせ | 平日 9:00-18:00 | 即時対応 |
| 緊急電話(オンコール) | P1インシデント | 24時間(ハイパーケア期間中) | 1時間以内 |
| メール | 定例報告・非緊急連絡 | 24時間受付 | 翌営業日対応 |
### 問い合わせ時の必要情報
利用者が問い合わせる際は、以下の情報を提供してもらう:
- **基本情報**
- ユーザー名・所属部門
- 発生日時
- 優先度(利用者の判断)
- **事象詳細**
- 発生した事象の詳細説明
- 操作内容・手順
- エラーメッセージ(スクリーンショット推奨)
- 影響範囲(他のユーザーでも発生しているか)
- **環境情報**
- 使用端末・OS・ブラウザ
- ネットワーク環境(社内・社外)
### 一次対応フロー
```mermaid
graph TD
A[問い合わせ受付] --> B{一次切り分け}
B -->|操作方法| C[運用部門が回答]
B -->|システム不具合| D[ベンダーへ転送]
B -->|業務ルール| E[業務部門へ転送]
D --> F[ベンダー調査・対応]
F --> G[解決・フィードバック]
C --> G
E --> G
```
---
## 初期監視・確認項目
### 監視項目一覧
| 監視項目 | 監視方法 | 確認頻度 | 閾値・異常判断基準 |
|---------|---------|---------|------------------|
| バッチ処理結果 | ジョブ管理ツール | 毎日(処理完了後) | 処理失敗、想定時間超過 |
| 外部連携状況 | ログ監視 | 1時間ごと | 接続エラー、タイムアウト |
| エラーログ | ログ監視ツール | リアルタイム | ERROR以上のログ発生 |
| レスポンスタイム | APM | リアルタイム | 平均3秒超過 |
| CPU使用率 | インフラ監視 | 5分ごと | 80%超過が10分継続 |
| メモリ使用率 | インフラ監視 | 5分ごと | 90%超過 |
| ディスク使用率 | インフラ監視 | 1時間ごと | 85%超過 |
| セッション数 | アプリログ | 10分ごと | 想定ピーク値の120%超過 |
### 日次確認チェックリスト
**毎朝実施(営業開始前):**
- [ ] 夜間バッチ処理の正常完了確認
- [ ] エラーログの確認(ERROR以上)
- [ ] 前日の問い合わせ・インシデント件数確認
- [ ] システムリソース状況の確認
- [ ] 外部連携システムの稼働状況確認
**週次実施(金曜日):**
- [ ] 週間の問い合わせ傾向分析
- [ ] 性能データのトレンド分析
- [ ] 未解決インシデントの棚卸し
- [ ] 次週の想定リスク確認
---
## アフターフォロー期間中のレビュー
### 日次レビュー(集中フォロー期間中)
**実施タイミング**: 毎日 17:00(30分)
**参加者**: ベンダー側サポートチーム、顧客側運用担当
**レビュー内容**:
- 当日発生したインシデントの共有
- 未解決問題の進捗確認
- 翌日の注意事項・予定確認
### 週次レビュー
**実施タイミング**: 毎週金曜日 15:00(1時間)
**参加者**: プロジェクトマネージャー、ベンダー側責任者、顧客側責任者
**レビュー内容**:
- 週間インシデントサマリー
- 傾向分析(問い合わせの多い機能・操作)
- 性能・安定性評価
- 改善アクションの検討
- 次週の重点監視項目の決定
### フェーズ移行レビュー
各フェーズ終了時に実施し、次フェーズへの移行可否を判断する。
**レビュー項目**:
- インシデント発生状況の評価
- 未解決問題の棚卸しと対応計画
- 利用者満足度の確認
- 性能・安定性指標の評価
- 移行判断基準の達成状況
---
## 期間終了後の引き継ぎ
### 引き継ぎ内容
| 引き継ぎ項目 | 内容 | 形式 |
|------------|------|------|
| システム構成情報 | 最新の構成図、設定情報 | ドキュメント |
| 運用手順書 | 最終版の運用マニュアル | ドキュメント |
| 既知の問題 | 未解決問題リスト、回避策 | チケット一覧 |
| 問い合わせ履歴 | FAQ、ナレッジベース | ナレッジDB |
| 監視設定 | 監視項目・閾値の設定情報 | 設定ファイル |
| 改善要望 | バックログ化された要望一覧 | バックログ |
### 引き継ぎスケジュール
```mermaid
gantt
title 引き継ぎスケジュール
dateFormat YYYY-MM-DD
section ドキュメント整備
運用マニュアル最終化 :2025-01-20, 5d
ナレッジベース整理 :2025-01-23, 3d
section 引き継ぎ実施
保守チームへの説明会 :2025-01-27, 1d
実地トレーニング :2025-01-28, 2d
並走期間 :2025-01-30, 5d
section 完了
最終確認・承認 :2025-02-04, 1d
```
### 証跡の整理
以下の記録を整理し、アーカイブする:
- 問い合わせ・インシデント管理記録
- 障害対応記録(根本原因分析含む)
- 変更管理記録
- 定例レビュー議事録
- 監視ログ(一定期間保管)
### 最終報告書
アフターフォロー期間終了時に、以下を含む最終報告書を作成する:
- 期間中のサマリー(インシデント件数、対応時間等)
- 主要な問題と対応内容
- 改善実施項目
- 残課題と対応計画
- 通常運用への移行判断と根拠
- 今後の推奨事項
--- プレビュー
移行後のアフターフォロー
本章では、システム移行完了後の安定稼働を確保するためのフォローアップ計画について記載する。
移行直後は予期しない問題が発生する可能性が高いため、集中的なサポート体制を構築し、
早期に問題を検知・対応することで、業務への影響を最小限に抑える。
アフターフォロー期間
期間の定義
| フェーズ | 期間 | 主な活動 |
|---|---|---|
| 集中フォロー期 | 移行後1週間 | 24時間監視体制、即座のトラブル対応 |
| 初期安定期 | 移行後2〜4週間 | 営業時間内の優先サポート、傾向分析 |
| 通常運用移行期 | 移行後5〜8週間 | 段階的に通常保守体制へ移行 |
終了判断基準
以下の条件を満たした場合、通常運用(保守)へ移行する:
- 重大インシデントが2週間以上発生していない
- 問い合わせ件数が想定レベル以下に安定している
- 業務部門から安定稼働の確認が得られている
- 移行起因の未解決問題がない
サポート体制
体制図
graph TD
A[利用者] -->|問い合わせ| B[一次窓口]
B -->|業務関連| C[顧客運用部門]
B -->|システム関連| D[ベンダーサポート窓口]
D --> E[アプリ担当]
D --> F[インフラ担当]
D --> G[移行担当]
E --> H[エスカレーション管理者]
F --> H
G --> H
ベンダー側体制
| 役割 | 担当者 | 連絡先 | 対応時間 |
|---|---|---|---|
| サポート窓口 | 山田太郎 | support@vendor.com / 03-xxxx-xxxx | 平日 9:00-18:00 |
| アプリ担当 | 佐藤花子 | app-team@vendor.com | 平日 9:00-20:00 |
| インフラ担当 | 鈴木一郎 | infra-team@vendor.com | 平日 9:00-20:00 |
| 移行担当 | 田中次郎 | migration@vendor.com | 平日 9:00-18:00 |
| エスカレーション責任者 | 高橋三郎 | manager@vendor.com / 090-xxxx-xxxx | 24時間(緊急時) |
顧客側体制
| 役割 | 部門 | 連絡先 | 対応時間 |
|---|---|---|---|
| 運用部門窓口 | 情報システム部 運用課 | it-ops@customer.com | 平日 8:30-17:30 |
| 業務部門窓口 | 営業部 システム推進担当 | sales-sys@customer.com | 平日 9:00-18:00 |
連絡手段
- 通常時: 専用チケットシステム(Backlog)
- 緊急時(重大インシデント): 電話 + Teams通話
- 定例報告: メール + 週次ミーティング(Teams)
夜間・休日体制
集中フォロー期間中(移行後1週間):
- ベンダー側: オンコール体制(24時間対応可能)
- 顧客側: 緊急連絡先を事前登録
初期安定期間以降:
- 重大インシデントのみ夜間対応
- 中程度以下は翌営業日対応
アフターフォローの対応範囲
対応範囲内
- 移行作業に起因する不具合の一次切り分け・対応
- 移行後の設定漏れ・動作不具合の対応
- 利用者からの初期問い合わせ支援
- 業務マニュアル・操作案内の補足説明
- 関係システムとの接続不具合の初期対応
- データ移行結果の再検証
- 性能劣化への対応
対応範囲外
- 移行と無関係な既存機能の不具合(通常保守で対応)
- 新規機能追加の要望(別途改修案件として起票)
- 利用者教育・研修(別途トレーニング計画で実施)
- 仕様変更を伴う改善要望(バックログ化し、優先度評価後に対応)
緊急性が低い改善要望の扱い
graph LR
A[改善要望] --> B{緊急性・影響度}
B -->|高| C[即時対応]
B -->|中| D[バックログ登録]
B -->|低| E[次期改修で検討]
D --> F[優先度評価会議]
F --> G[開発計画への組み込み]
優先度・対応方針
優先度定義
| 優先度 | 影響範囲 | 業務影響 | 対応目標時間 | 対応時間帯 |
|---|---|---|---|---|
| P1(重大) | 全社または主要業務 | 業務停止 | 1時間以内に一次対応開始 | 24時間対応 |
| P2(高) | 特定部門または機能 | 一部機能に影響 | 4時間以内に対応開始 | 営業時間内優先対応 |
| P3(中) | 限定的 | 運用代替可能 | 当日中に対応開始 | 営業時間内対応 |
| P4(低) | 個別ユーザー | 影響軽微 | 翌営業日対応 | 営業時間内対応 |
対応フロー
graph TD
A[インシデント受付] --> B[優先度判定]
B --> C{P1?}
C -->|Yes| D[即時対応開始]
C -->|No| E{P2?}
E -->|Yes| F[4時間以内対応]
E -->|No| G{P3?}
G -->|Yes| H[当日中対応]
G -->|No| I[翌営業日対応]
D --> J[解決・クローズ]
F --> J
H --> J
I --> J
J --> K[報告・ナレッジ化]
エスカレーション基準
以下の場合、エスカレーション責任者へ即座に報告:
- P1インシデントが発生した場合
- 初動対応から2時間経過しても解決見込みが立たない場合
- 複数の部門・システムに影響が拡大する可能性がある場合
- 顧客責任者からのエスカレーション要請があった場合
問い合わせ・インシデントの受付方法
受付チャネル
| チャネル | 用途 | 受付時間 | 対応SLA |
|---|---|---|---|
| チケットシステム | 通常の問い合わせ・インシデント | 24時間受付 | 営業時間内4時間以内に一次回答 |
| 電話(サポート窓口) | 緊急度の高い問い合わせ | 平日 9:00-18:00 | 即時対応 |
| 緊急電話(オンコール) | P1インシデント | 24時間(ハイパーケア期間中) | 1時間以内 |
| メール | 定例報告・非緊急連絡 | 24時間受付 | 翌営業日対応 |
問い合わせ時の必要情報
利用者が問い合わせる際は、以下の情報を提供してもらう:
- 基本情報
- ユーザー名・所属部門
- 発生日時
- 優先度(利用者の判断)
- 事象詳細
- 発生した事象の詳細説明
- 操作内容・手順
- エラーメッセージ(スクリーンショット推奨)
- 影響範囲(他のユーザーでも発生しているか)
- 環境情報
- 使用端末・OS・ブラウザ
- ネットワーク環境(社内・社外)
一次対応フロー
graph TD
A[問い合わせ受付] --> B{一次切り分け}
B -->|操作方法| C[運用部門が回答]
B -->|システム不具合| D[ベンダーへ転送]
B -->|業務ルール| E[業務部門へ転送]
D --> F[ベンダー調査・対応]
F --> G[解決・フィードバック]
C --> G
E --> G
初期監視・確認項目
監視項目一覧
| 監視項目 | 監視方法 | 確認頻度 | 閾値・異常判断基準 |
|---|---|---|---|
| バッチ処理結果 | ジョブ管理ツール | 毎日(処理完了後) | 処理失敗、想定時間超過 |
| 外部連携状況 | ログ監視 | 1時間ごと | 接続エラー、タイムアウト |
| エラーログ | ログ監視ツール | リアルタイム | ERROR以上のログ発生 |
| レスポンスタイム | APM | リアルタイム | 平均3秒超過 |
| CPU使用率 | インフラ監視 | 5分ごと | 80%超過が10分継続 |
| メモリ使用率 | インフラ監視 | 5分ごと | 90%超過 |
| ディスク使用率 | インフラ監視 | 1時間ごと | 85%超過 |
| セッション数 | アプリログ | 10分ごと | 想定ピーク値の120%超過 |
日次確認チェックリスト
毎朝実施(営業開始前):
夜間バッチ処理の正常完了確認
エラーログの確認(ERROR以上)
前日の問い合わせ・インシデント件数確認
システムリソース状況の確認
外部連携システムの稼働状況確認
週次実施(金曜日):
週間の問い合わせ傾向分析
性能データのトレンド分析
未解決インシデントの棚卸し
次週の想定リスク確認
アフターフォロー期間中のレビュー
日次レビュー(集中フォロー期間中)
実施タイミング: 毎日 17:00(30分)
参加者: ベンダー側サポートチーム、顧客側運用担当
レビュー内容:
- 当日発生したインシデントの共有
- 未解決問題の進捗確認
- 翌日の注意事項・予定確認
週次レビュー
実施タイミング: 毎週金曜日 15:00(1時間)
参加者: プロジェクトマネージャー、ベンダー側責任者、顧客側責任者
レビュー内容:
- 週間インシデントサマリー
- 傾向分析(問い合わせの多い機能・操作)
- 性能・安定性評価
- 改善アクションの検討
- 次週の重点監視項目の決定
フェーズ移行レビュー
各フェーズ終了時に実施し、次フェーズへの移行可否を判断する。
レビュー項目:
- インシデント発生状況の評価
- 未解決問題の棚卸しと対応計画
- 利用者満足度の確認
- 性能・安定性指標の評価
- 移行判断基準の達成状況
期間終了後の引き継ぎ
引き継ぎ内容
| 引き継ぎ項目 | 内容 | 形式 |
|---|---|---|
| システム構成情報 | 最新の構成図、設定情報 | ドキュメント |
| 運用手順書 | 最終版の運用マニュアル | ドキュメント |
| 既知の問題 | 未解決問題リスト、回避策 | チケット一覧 |
| 問い合わせ履歴 | FAQ、ナレッジベース | ナレッジDB |
| 監視設定 | 監視項目・閾値の設定情報 | 設定ファイル |
| 改善要望 | バックログ化された要望一覧 | バックログ |
引き継ぎスケジュール
gantt
title 引き継ぎスケジュール
dateFormat YYYY-MM-DD
section ドキュメント整備
運用マニュアル最終化 :2025-01-20, 5d
ナレッジベース整理 :2025-01-23, 3d
section 引き継ぎ実施
保守チームへの説明会 :2025-01-27, 1d
実地トレーニング :2025-01-28, 2d
並走期間 :2025-01-30, 5d
section 完了
最終確認・承認 :2025-02-04, 1d
証跡の整理
以下の記録を整理し、アーカイブする:
- 問い合わせ・インシデント管理記録
- 障害対応記録(根本原因分析含む)
- 変更管理記録
- 定例レビュー議事録
- 監視ログ(一定期間保管)
最終報告書
アフターフォロー期間終了時に、以下を含む最終報告書を作成する:
- 期間中のサマリー(インシデント件数、対応時間等)
- 主要な問題と対応内容
- 改善実施項目
- 残課題と対応計画
- 通常運用への移行判断と根拠
- 今後の推奨事項