開発から運用への引き継ぎ｜資料・担当・受入条件をそろえる進め方

開発から運用への引き継ぎでは、資料を渡した事実と、運用担当が対応できる状態を分けて確認しましょう。構成図がそろっていても、障害時の判断者や変更権限が曖昧なら、実際の対応で開発担当へ確認が集中します。

この記事では、業務システムの開発担当と運用担当が、引き継ぐ範囲、確認方法、残る課題を合意するための進め方を整理します。特定企業での実施報告ではなく、体制に合わせて調整するための確認案です。

最初に、引き継ぐ責任の境界を決める

「運用を引き継ぐ」という言葉だけでは、監視、問い合わせ、障害調査、修正、公開作業のどこまでを含むか分かりません。作業名ごとに、一次対応者、判断者、実行者、連絡先を確認します。同じ担当が兼ねる場合も、役割は分けて記録しましょう。

GoogleのSRE書籍では、Production Readiness Reviewを、本番運用の準備状況などを確認する工程として説明しています。チェックリストはサービスに応じて作られます。Google SREのPRR

この考え方を参考にしつつ、SRE組織の有無にかかわらず、自分たちの対象業務と担当境界に合う確認項目を選びます。Googleと同じ組織や工程を設ける必要がある、という意味ではありません。

資料の一覧には、ファイル名だけでなく「何をするときに使うか」を添えます。構成図なら依存先の確認、手順書なら対象作業の実行、仕様書なら期待動作の判断、と用途を区別します。

古い版を参照しないよう、現行版の置き場所と更新責任者も決めます。権限が必要な資料は、リンクを渡すだけでなく受け手が閲覧できることを確認してください。秘密情報そのものを引き継ぎ表へ転記せず、組織で定めた管理先とアクセス手続きを案内します。

個々の作業の記載方法は、運用手順書の作り方で整理しています。引き継ぎでは、各手順を誰が使い、使えない場合に誰へ戻すかまでつなげます。

説明会への参加だけを完了条件にせず、受け手が判断の流れを説明できるかを確認します。影響のない検証環境や机上確認を使い、本番で障害を起こして試すことを前提にしません。

たとえば「夜間の定期処理が完了していない」という仮の状況を使い、受け手が確認するログ、二重実行の有無、連絡先、中止条件を説明します。操作できない権限が見つかったら、その場で広い権限を渡すのではなく、必要な範囲と申請方法を確認します。

以下は引き継ぎ項目の仮例です。実案件の検証結果ではありません。

課題が残る場合は「引き継ぎ済み」の一語で閉じず、誰が、いつまで、どの条件で対応するかを残します。

受入条件は、資料、担当、確認結果の三つを対応づけます。たとえば「手順書がある」ではなく、「現行版の手順を運用担当が参照でき、確認用の状況で判断順序を説明できる」と書けば、確認対象が明確になります。

すべての課題がなくなるまで移管できないとは限りません。ただし、未解決事項を受け入れる判断者と、暫定分担が終わる条件は必要です。契約上の責任や対応時間は、既存の合意内容と照合してください。

引き継ぎ後に最初の問い合わせや変更が起きたら、資料だけでは判断できなかった点を確認します。まずは一つの業務について、担当境界、使う資料、受入条件、残課題を一枚にまとめ、開発側と運用側で同じ説明になるか確認しましょう。