プロジェクトから運用への移行｜引き継ぎの準備ができたかの確認方法

プロジェクトは、いつか終わります。しかし、作った成果物は、その後も長く使われ続けます。移行（トランジション）は、成果物と、それを使い続けるための責任を、プロジェクトから受け取る側へ渡すことです。

受け取る側は、運用チーム、事業部門、保守のベンダー、あるいは次のフェーズのチームなどです。

2026年版の ECO では、Process タスク10「プロジェクトの終結を管理する」のイネーブラーに、移行の準備の確認が挙がっています。「移行の準備ができているかを確かめる（例：運用チームや次のフェーズへ）」です。終結の手順の全体はプロジェクト終結の手順で解説しています。

旧版（2021年版）では、タスク名そのものに「移行」が入っていました（Process タスク17「プロジェクトやフェーズの終結や移行を計画し管理する」）。2026年版でタスク名は変わりましたが、移行の準備の確認は引き続き問われます。

ポイントは、「作り終えた」と「渡せる」は違うということです。システムが完成していても、運用チームが監視の方法を知らない、障害時の手順書がない、問い合わせ窓口が決まっていない。この状態では、移行の準備ができているとは言えません。

移行の準備ができたかは、受け取る側の視点で判断します。そのために、運用側の受入基準（運用の準備のチェックリスト）を、プロジェクトの早い段階で運用チームと合意しておきます。ITシステムを例に、よく使う項目を示します。

これらの項目は、移行の直前に初めて出すと間に合いません。手順書の作成や研修には時間がかかります。プロジェクトの作業として、計画とスケジュールに入れておく必要があります。移行の作業は、プロジェクトマネジメント計画書の段階から組み込みます。

引き継ぎは、資料を渡して終わりではありません。受け取る側が自分で運用できるようになることがゴールです。当サイトでは、次の順で準備することをすすめます。

1. 1受け取る側を早く巻き込む：設計や試験の段階から運用チームに参加してもらい、運用のしやすさの意見をもらう。
2. 2資料を受け取る側と一緒に作る：手順書は、実際に使う人がレビューし、その手順で作業できるかを確かめる。
3. 3研修と実地の練習を行う：説明を聞くだけでなく、試験環境で実際に操作してもらう。障害の練習もしておく。
4. 4暗黙の知識を残す：「なぜこの設計にしたか」「どこでつまずきやすいか」など、資料に書かれにくい知識を話し合いで伝え、記録する。

暗黙の知識は、文書を渡すだけでは移りません。移し方はナレッジトランスファーの記事で詳しく扱います。

移行の直前には、移行の可否を判断する場（go/no-go の判定）を設けるのが一般的です。運用側の受入基準のチェックリストを1つずつ確かめます。満たしていない項目があれば、その影響と対策を検討します。

判断に加わるのは、スポンサー、運用チームの責任者、事業部門の代表など、移行の後に責任を持つ人たちです。プロジェクト・マネジャー（PM）が一人で「移行できます」と決めるものではありません。

満たしていない項目がある場合、選択肢は大きく3つです。

どれを選ぶかは、リスクと事業への影響で判断し、決めた内容を記録します。

本番の運用が始まると、試験では見つからなかった問題や、利用者の戸惑いが出てきます。そこで、移行の後に一定の支援期間を設け、プロジェクトチームの一部が運用チームを支えます。この期間は、ハイパーケアと呼ばれることもあります。

支援期間には、終わりの条件を決めておきます。「重大な障害が2週間発生しない」「問い合わせの件数が一定以下になる」などです。条件を満たしたら、残る課題とその担当を確かめて、運用チームに完全に引き継ぎます。終わりの条件が無いと、プロジェクトのメンバーがいつまでも運用の仕事に縛られ、終結できなくなります。

支援期間に集めた問い合わせや障害の記録は、運用の改善と、便益の測定に役立ちます。便益の追跡を運用側に引き継ぐ方法はベネフィットマネジメントで扱っています。

試験では、次のような場面が考えられます。

• ✓成果物は完成したが、運用チームが「まだ受け取れない」と言っている → 不足している条件を確かめ、解消の計画を合意する
• ✓スポンサーが稼働日を守るよう強く求めている → 準備の不足とリスクを示し、判断の材料を提供する
• ✓移行後に問い合わせが殺到している → 支援期間の体制で対応し、原因を分析して手順や教育を改善する

どの場面でも、「受け取る側が運用できるか」を軸に考えると、正解を選びやすくなります。こうした判断は無料模試30問でも練習できます。