オンコール当番中も戦略的作業時間を確保する
ルール
オンコール当番のシフト中であっても、少なくとも50%の時間をプロジェクト作業（インシデント対応改善・自動化・ドキュメント整備など）に充てる。
反応的なインシデント対応とToil処理が50%を超えた場合、その状況をマネージャーと共有し、過負荷としてエスカレーションする。
理由
オンコールが「反応的対応だけ」になると：
- エンジニアの燃え尽きと離職が増加
- 「なぜオンコールをやりたいか」という動機が失われる
- Toilが削減されず、翌シフトも同じ状況が続く
プロジェクト時間を確保することで：
- オンコール中に原因となるToilを自動化できる（好循環）
- エンジニアが「今週は改善ができた」と感じられる
- 長期的なサービスの信頼性向上につながる
実践
- 週のオンコール負荷を記録し（インシデント件数・対応時間）、月次でチームに共有
- 負荷が高かった週は翌週のスプリントで「Toil削減タスク」を優先的に割り当てる
- オンコールシフトのレトロスペクティブを月次で実施
例外
SEV1の大規模インシデントが発生した週は、反応的対応が50%を超えることは許容する。ただし翌シフト以降に必ず改善タスクを組み込む。
関連パターン
- オンコール設計 — オンコール体制の包括的な設計原則
- Toilは測定してから自動化する — プロジェクト時間で取り組むToil削減
出典
Google SRE Workbook（Betsy Beyer他）第8章「On-Call」