6.3サービスマネジメントへの移行

プロジェクトが成果物を完成させても、それを安全に本番環境へ送り出し、以後の運用保守に円滑に引き継げなければ、プロジェクトの価値は実現しません。PMには、開発の完了度だけでなく、運用側の受入れ体制やリスクまで踏まえて本番移行の可否（Go/No-go）を判断する役割が求められます。判断基準は開発側の都合ではなく、サービスとして稼働させたときの利用者・運用者への影響を起点に組み立てます。

6.3.1本番移行と移行判定（Go/No-go）

• 本番移行（リリース）＝開発・テスト環境で作られた成果物を、実際の利用者が使う本番環境へ展開する活動。単なるデプロイ作業ではなく、切戻し（ロールバック）手順の用意・移行時の影響範囲の見極め・移行後の監視体制まで含めて計画される。
• 移行判定（Go/No-go判定）＝あらかじめ定めた基準（受入れテストの合格・重大な未解決障害の有無・切戻し手順の準備状況・運用体制の準備状況等）に照らして、予定どおり本番移行を実施するか延期するかを組織として意思決定するゲート。技術的な完成度だけでなく、移行タイミングの妥当性（繁忙期を避ける等）や運用引継ぎの準備状況も判定材料に含める。

6.3.2SLAとITILの観点

• SLA（Service Level Agreement）＝サービス提供者と利用者の間で合意するサービス品質の水準（可用性・応答時間・障害復旧時間等の数値目標）。プロジェクトが本番移行する成果物は、移行前にSLAで求められる水準を満たせる運用体制・監視体制が整っているかを検証しておく必要がある。
• ITIL（IT Infrastructure Library）＝IT サービスマネジメントのベストプラクティス集で、サービスの企画・設計・移行・運用・改善というライフサイクルの観点を提供する。プロジェクトの視点では特にサービス移行（Service Transition）の領域が関わり、変更管理・リリース管理・既知の障害情報の引継ぎ（既知エラーデータベース等）を通じて、開発側の知見を運用側へ確実に渡すことが問われる。

あるPMが、大規模な基幹システム刷新プロジェクトの本番移行判定会議に臨むとします。開発チームからは「受入れテストは全項目合格し、重大な未解決障害もゼロ」という報告が上がっており、開発側は予定どおりの移行を主張します。しかしPMが運用チームに状況を確認すると、新システムの監視ダッシュボードの設定がまだ完了しておらず、障害発生時に運用担当者がSLAで定めた復旧時間（例：重大障害は1時間以内に検知）を守れる体制になっていないことが判明します。加えて、移行予定日が決算処理と重なる社内の繁忙期にあたることも分かりました。PMはここで「テストが全部通っているから移行してよい」と短絡せず、Go/No-go判定の基準は技術的完成度だけでなく運用受入れ体制まで含むという原則に立ち返り、この移行判定をNo-go（延期）と判断します。是正措置として、（1）監視ダッシュボードの設定完了と運用担当者への操作研修を先に完了させる、（2）繁忙期を避けた移行日程に再設定する、（3）ITILのサービス移行の考え方に基づき、開発チームが把握している既知の軽微な不具合や運用上の注意点を既知エラー情報として運用チームへ正式に文書で引き継ぐ、という3点を実施した上で、改めてGo/No-go判定を行うことにします。このように、開発が「完成した」と考えるタイミングと、運用が「安全に引き受けられる」タイミングは必ずしも一致せず、PMはSLAという利用者との約束を起点に、両者のギャップを埋める調整役を担います。

6.3.3この節のまとめ

• 本番移行（リリース）は切戻し手順・影響範囲・移行後監視まで含めて計画する
• 移行判定（Go/No-go）は技術的完成度に加え運用体制・タイミング・知見引継ぎを総合して判断するゲート
• SLAは運用フェーズの合意水準で移行前に充足可能性を検証、ITILのサービス移行は開発知見を運用へ引き継ぐ活動