少人数のプロダクトチームでオンコールがつらくなるのは、当番制度そのものより、最初の5分を特定の人しか動けない状態が残っているからです。オンコール体制は、頑張れる人を支える仕組みではなく、頑張りが要らない方向へ寄せる仕組みとして作るべきです。
当番表をつくっても、一次切り分けが人に依存していれば回らない
小規模チームでは、「詳しい人が結局起きる」状態が起きがちです。通知を受けた人が何を見ればよいか分からず、結局ドメイン知識のあるメンバーを呼ぶからです。
この状態では、当番がいてもオンコール体制とは言えません。重要なのは、専門家でなくても最初の切り分けだけは進められるようにすることです。
誰でも動ける最初の5分を決める
障害対応の最初の5分は、調査の深さよりも、サービスへの影響を把握することが重要です。小さなチームでは、この初動を定型化するだけで負担が大きく下がります。
最初の5分でやることを固定する
- どのサービス・画面・ジョブに影響が出ているかを確認する
- エラー率や主要メトリクスが継続して悪化しているかを見る
- 直前の変更、デプロイ、設定更新があったかを確認する
- ユーザー影響の大きさを、広い・限定的・不明で一旦分類する
この4つが見られるだけでも、「本当に起こすべき人」を選びやすくなります。
夜間対応の条件を決めておく
すべてのアラートに夜間対応する前提は、少人数組織では持続しません。どの障害が夜間即応の対象で、どこからは翌営業日対応でよいのかを事前に決めておく必要があります。
決めておきたいこと
- 売上や主要業務が止まる障害だけを夜間起床対象にする
- 一時的な性能劣化は自動復旧や翌朝確認に回す
- 通知先を全員同報にせず、当番とエスカレーション先を分ける
夜間に人を起こす基準が曖昧だと、チームは通知そのものを信用しなくなります。オンコール設計は、通知ポリシーとセットで考えるべきです。
障害メモを“感想”ではなく“次の人が使える記録”にする
少人数チームでは、振り返りが後回しになりがちです。しかし、障害記録を残さないと、同じ失敗が別の人の当番で繰り返されます。
記録は長文でなくてもよく、少なくとも次の項目が残っていれば機能します。
- 何が起きたか
- ユーザー影響はどこまでだったか
- 最初に何を見て判断したか
- 再発防止として何を直すか
この情報があるだけで、次の当番はゼロから状況を推測しなくて済みます。オンコールの改善は、手当の話よりも記録の質の話であることが多いです。
実務上の目安: 週に1回でも「障害メモの棚卸し」をやると、オンコール負担の元が見えてきます。よく起きる通知、分かりにくい通知、専門家しか判断できない通知を分けるだけでも改善テーマがはっきりします。
まとめ
小さなチームのオンコールは、根性で回すものではありません。誰でも初動できるようにし、夜間対応の条件を決め、障害記録を次の改善へ繋げることで、少しずつ属人性を減らしていくものです。
「詳しい人がいれば回る」状態から、「詳しくない人でも最初の判断までは進められる」状態へ寄せることが、持続するオンコール設計の第一歩です。