引き継ぎと継続性

オンコールシフトの終わりは、始まりと同じくらい重要です。良い引き継ぎとは、次のエンジニアが成功できるよう準備することです。

引き継ぎとは何か？

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

SSCS の 24x5 ローテーションでは、引き継ぎは以下のタイミングで発生します:

地域間（APAC → EMEA → AMER → APAC）でカバレッジが移る8時間ごと
シフト終了時にインシデントが進行中の場合はその時点

引き継ぎが重要な理由

引き継ぎが不十分だと:

コンテキストが失われ混乱が生じる
問題が見落とされる
作業が重複する
重要な詳細が見逃される
エンジニアがストレスを受ける

良い引き継ぎは:

次の担当者が成功するために必要なことを伝える
作業の重複を防ぐ
見落としを防ぐ
ローテーションへの信頼を築く
タイムゾーンをまたいだ継続性を維持する

引き継ぎに含める内容

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

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

必要な詳細:

何が問題か？ — 明確な説明
どのドメインか？ — 認証、認可、またはパイプラインセキュリティ
影響は？ — 何人のユーザー/サービスが影響を受けているか？
何を試みたか？ — どのような調査ステップを行ったか？
どこで行き詰まっているか？ — ブロッカーは何か？
次に何をすべきか？ — あなたの推奨事項

例:

「SAML ログインで認証失敗率が高い。認証サービスを2回再起動したところ、失敗は正常レベルに下がったが、30分以内に再上昇した。最新のデプロイは4時間前。新しい SAML ハンドラーにセッション状態の問題があると思われる。デプロイの詳細を確認し、改善しない場合はロールバックを検討してください。悪化した場合は認証 EM にエスカレーションしてください」

2. 解決した最近の問題

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

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

例:

「解決済み: 午後3時頃に認可ポリシー評価エラー。Redis 接続タイムアウトによりポリシーキャッシュが更新されていなかった。キャッシュを手動でフラッシュし、Redis 接続プール設定を修正。キャッシュ更新失敗のモニタリングを追加するために Issue #12345 を作成した」

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

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

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

例:

「PipelineSecurityScanTimeout が6回発火したが、常に誤検知だった。スキャンは正常に完了したが、アラートしきい値よりも時間がかかっていた。しきい値を上げるか、予想されるスキャン時間に合わせて調整すべき。緊急ではないが、記録に残しておく価値がある」

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

シフト中にデプロイや変更は行いましたか？

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

例:

「OAuth トークン更新の問題を修正するため、午後8時に認証サービスバージョン2.1.3をデプロイした。今のところ安定しているが、今後1時間は AuthTokenRefreshRate と SessionCreationErrors のメトリクスを注意深く監視してください」

5. ドメインをまたぐコンテキスト

ドメイン間の相互作用について次の担当者が知っておくべきこと:

複数のドメインが影響を受けているか？
サービス間に依存関係があるか？
他のドメインチームと調整したか？

例:

「先ほどの認証の問題により、認可のタイムアウトも発生した。@AuthorizationEngineer と調整した。両サービスは現在安定しているが、認証に問題が再発した場合のカスケード効果に注意してください」

6. 保有しているコンテキスト

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

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

例:

「大規模なパイプラインセキュリティスキャナーの更新が明日午前10時に予定されている。リーダーシップが問題を注視しているので、夜中に何か異常があった場合はすぐにエスカレーションしてください」

引き継ぎの方法

シフト終了前

30分前:

引き継ぎメモを書き始める
進行中の問題を要約する
詳細とリンクを収集する

同期引き継ぎ（推奨）

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

連絡する: 「シフトを終えます。10分ほど引き継ぎの時間をもらえますか？」
説明する: 各進行中の問題について話す
質問に答える: 明確化の質問をさせる
理解を確認する: 理解できているか確認する
連絡先を残す: 「問題が発生したら Slack してください」

特にタイムゾーンをまたいだ引き継ぎでは15〜20分かかりますが、価値があります。

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

直接連絡できない場合（タイムゾーンをまたいだ引き継ぎでは一般的）:

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

引き継ぎメッセージの例

@Sarah、AMERからAPACへの引き継ぎをします。把握しておくべき内容:

**進行中の問題:**

- SAML ログインで HighAuthFailureRate。サービスを2回再起動したが、失敗が再発。
  4時間前のデプロイで新しい SAML ハンドラーにセッション状態の問題がある可能性。
  デプロイを確認し、継続する場合はロールバックを検討してください。
  ドメイン: 認証

**自分のシフト中に解決した問題:**

- 認可ポリシーのキャッシュ更新（Redis 接続タイムアウト）を修正
- 午後3時にキャッシュを手動でフラッシュ
- モニタリング用に Issue #12345 を作成
  ドメイン: 認可

**誤検知:**

- PipelineSecurityScanTimeout が6回発火。実際の問題ではなく、単にスキャン時間が長かっただけ。
  ドメイン: パイプラインセキュリティ

**デプロイ:**

- OAuth 修正のため、午後8時に認証サービス v2.1.3 をデプロイ。今のところ安定しているがメトリクスを注視してください。

**参考情報:**

- 大規模なパイプラインセキュリティスキャナーの更新が明日午前10時に予定
- リーダーシップが問題を注視しているので、何か問題があれば早めにエスカレーション

質問があれば教えてください。もう少しの間オンラインなので、確認が必要な場合はどうぞ。

まだインシデント対応中の場合

問題がシフト終了時に解決していない場合:

すぐに次の担当者に伝える
そのまま消えてはいけない — コンテキストを説明する
コンテキストを説明するための簡単な引き継ぎ会話のために少し残る
助けを申し出る: 「悪化した場合は教えてください、戻れます」

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

引き継ぎ後

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

十分な引き継ぎを受けられなかった場合

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

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

これは不満の原因になるので、他の人にはこうならないようにしましょう。

引き継ぎでよくある間違い

❌ すぐに離脱する

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

❌ 曖昧すぎる

「すべて問題ない」は役立ちません。何を確認し、何が起きたかを具体的に伝えましょう。

❌ 相手がコンテキストを知っていると思い込む

次の担当者は別のタイムゾーン・ドメインにいるかもしれません。すべてを説明しましょう。

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

何かがまだ壊れている場合、引き継ぎでそれを無視しないでください。何を試みたか、何を推奨するかを説明しましょう。

❌ ドメインを明記しない

問題が認証、認可、またはパイプラインセキュリティのどれに関わるかを常に明記しましょう。

❌ 防衛的になる

質問があれば明確に答えましょう。「そこまでデバッグしなかった」は問題ありません。「たぶんその問題じゃない」は役に立ちません。