オンコール当番中も戦略的作業時間を確保する

ルール

オンコール当番のシフト中であっても、少なくとも50%の時間をプロジェクト作業（インシデント対応改善・自動化・ドキュメント整備など）に充てる。

反応的なインシデント対応とToil処理が50%を超えた場合、その状況をマネージャーと共有し、過負荷としてエスカレーションする。

理由

オンコールが「反応的対応だけ」になると：

• エンジニアの燃え尽きと離職が増加
• 「なぜオンコールをやりたいか」という動機が失われる
• Toilが削減されず、翌シフトも同じ状況が続く

プロジェクト時間を確保することで：

• オンコール中に原因となるToilを自動化できる（好循環）
• エンジニアが「今週は改善ができた」と感じられる
• 長期的なサービスの信頼性向上につながる

実践

• 週のオンコール負荷を記録し（インシデント件数・対応時間）、月次でチームに共有
• 負荷が高かった週は翌週のスプリントで「Toil削減タスク」を優先的に割り当てる
• オンコールシフトのレトロスペクティブを月次で実施

例外

SEV1の大規模インシデントが発生した週は、反応的対応が50%を超えることは許容する。ただし翌シフト以降に必ず改善タスクを組み込む。

出典

Google SRE Workbook（Betsy Beyer他）第8章「On-Call」