引き継ぎと継続性

オンコールシフトの終了は、始まりと同様に重要です。良い引き継ぎによって、次のエンジニアが成功できる環境を整えます。

引き継ぎとは何ですか？

引き継ぎとは、あなたから次の担当者へのオンコール責任の正式な移譲です。

シフトの境界で発生します。通常は：

24時間×5日のローテーションを行っている場合は毎日（各日の終わり）
シフトが終わるときにインシデントが進行中の場合はいつでも

引き継ぎが重要な理由

引き継ぎが不十分だと：

コンテキストが失われ、混乱が生じます
問題が忘れられます
作業が重複します
重要な詳細が見落とされます
エンジニアがストレスを抱えます

良い引き継ぎは：

次の担当者が成功するために必要な情報を提供します
作業の重複を防ぎます
何も見落とされないようにします
ローテーションへの信頼を構築します

引き継ぎに含める内容

1. 現在のインシデント（進行中の問題）

進行中の問題がある場合：

必要な詳細情報：

何が問題か？ — 明確な説明
影響は？ — 何人のユーザー・サービスに影響しているか？
何を試みたか？ — どんな調査手順を踏んだか？
どこで行き詰まっているか？ — 何がブロッカーになっているか？
次に何をすべきか？ — あなたの推薦事項

例：

「Payment Service のメモリ使用量が高い。2回再起動したところメモリは通常に戻ったが、30分以内にまた上昇した。最新のデプロイは4時間前。新しいトランザクションハンドラーにメモリリークがあると思う。デプロイの詳細を確認し、ロールバックを検討してほしい。悪化したら Marcus にエスカレーションして。」

2. 解決済みの問題

シフト中に何を修正しましたか？

何が問題だったか？
根本原因は何だったか？
どう修正したか？
フォローアップ作業が必要か？（チケット、モニタリング変更など）

例：

「解決済み: 午後3時頃の API レート制限エラー。毎日のリセットを実行するはずの cron ジョブがスケジューリングエラーで動いていなかった。カウンターを手動でリセットし、cron スケジュールを修正した。追加対応は不要。」

3. 発火したアラート（ノイズ）

発火したが実際の問題でなかったアラートは？

何のアラートが発火したか？
なぜ実際の問題でなかったのか？
何をすべきか？

例：

「DiskSpaceWarning が6回発火したが、常に誤報だった。古いログを削除したところ、1時間以内にまたアラートが発生した。しきい値を上げるかログローテーションを実装するかのどちらかが必要。急ぎではないが、記録しておく価値がある。」

4. 保留中の変更またはデプロイ

シフト中に何かデプロイまたは変更されましたか？

何が変更されたか？
いつ？
なぜ？（ホットフィックス、計画的な変更など）
何に注意すべきか？

例：

「接続プールの問題を修正するためバージョン 2.1.3 を午後8時にデプロイした。今のところ安定しているが、次の1時間はデータベース接続数と PoolSize メトリクスを注意深く監視してほしい。」

5. 持っているコンテキスト

次の担当者が知らないかもしれないこと：

顧客が進行中の問題を認識しているか？
リーダーシップが何かを追跡しているか？
エスカレーションした未解決のインシデントがあるか？
彼らが知っておくべきミーティングや決定があったか？

例：

「大きな API リデザインが明日午前10時に暫定的にリリースされる予定。午前9時半に全社集会がある。リーダーシップが問題を監視しているので、夜間に何かおかしなことがあれば、遅らずにエスカレーションしてほしい。」

引き継ぎの方法

シフト終了前

30分前：

引き継ぎメモの作成を始めます
進行中の問題を要約します
詳細とリンクを集めます

同期的な引き継ぎ（推奨）

可能であれば、次の担当者と直接話します：

連絡する： 「もうすぐシフトが終わります。10分ほど引き継ぎのお時間をいただけますか？」
説明する： 各進行中の問題を順に説明します
質問に答える： 確認の質問に答えます
理解を確認する： 内容が伝わったか確認します
連絡先を伝える： 「問題が出たら Slack でご連絡ください」

15〜20分かかりますが、その価値があります。

非同期な引き継ぎ（必要な場合）

直接つながれない場合：

詳細なメモを書く — Slack または共有ドキュメントに
オンコールチャンネルに投稿する — 次の担当者が見つけられるように
ダイレクトメッセージを送る — 「@NextEngineer、引き継ぎメモをオンコールチャンネルで確認してください」
具体的に書く — 推測したり探したりしなくて済むように

引き継ぎメッセージの例

@Sarah、引き継ぎします。以下が必要な情報です：

**進行中の問題：**

- Payment Service の HighMemoryUsage。2回再起動したがメモリが再び上昇中。
  4時間前のデプロイに含まれる新しいトランザクションハンドラーのメモリリークと思われる。
  デプロイを確認し、続く場合はロールバックを検討してください。

**私のシフト中に解決した問題：**

- レートリミットリセットの cron ジョブを修正（動いていなかった）
- 午後3時にカウンターを手動でリセット

**誤報：**

- DiskSpaceWarning が6回発火。実際の問題ではなく、ログの蓄積によるもの。

**デプロイ：**

- 接続プールの修正のため v2.1.3 を午後8時にリリース。今のところ安定しているが、メトリクスを注意深く監視してください。

**FYI：**

- 大きな API リデザインが明日午前10時に暫定リリース予定
- リーダーシップが問題を監視中なので、何かおかしなことがあれば早めにエスカレーションしてください

質問があれば知らせてください。少しの間は対応できます。

インシデントが進行中の場合は？

シフトが終わるときに問題が解決していない場合：

すぐに次の担当者に伝える
そのまま消えずに 次の担当者に引き継ぐ
コンテキストを説明するための簡単な引き継ぎ会話に留まる
行き詰まった場合の支援を申し出る： 「悪化したら知らせてください。助けに入れます」

次の担当者が謎を引き継ぐべきではありません。

引き継ぎ後

次の担当者が情報を受け取ったことを確認します
あなたは公式にオフコール（ただし30分ほどラップトップの近くにいます）
質問があれば連絡できます
必要であれば助けられます（必ずしも対応に戻る必要はありません）

良い引き継ぎを受けられなかった場合は？

コンテキストなしにシフトを引き継いだ場合：

Slack で確認する — 「この問題のコンテキストを教えてもらえますか？」
最近の MR を確認する — 何が変わったか？
Incident.io を見る — チケットやログがあるか？
前のオンコール担当者に連絡する — たとえオフであっても、すぐに助けてもらえます

これは苦痛を伴うことなので、他の人にこれをしないようにしましょう。

避けるべき一般的な引き継ぎミス

❌ すぐに消える

シフト終了時にすぐにオフラインにならないでください。まずコンテキストを伝えましょう。

❌ 曖昧すぎる

「すべて問題ありませんでした」では不十分です。何を確認し、何が起きたかを具体的に伝えましょう。

❌ コンテキストを知っていると仮定する

進行中のプロジェクト、最近の問題、チームの優先事項を知らないかもしれません。説明しましょう。

❌ 進行中の問題を無視する

何かまだ壊れている場合、引き継ぎでそれを無視しないでください。試みたこととおすすめの対応を説明しましょう。

❌ 防衛的になる

誰かが質問したら、明確に答えてください。「そこまでデバッグしませんでした」は問題ありません。「おそらくその問題ではない」は役に立ちません。