ローテーションへの参加と離脱

ローテーションへの追加はどのように行われますか？

SSCS チームに参加したとき

マネージャーは、ローテーションに人を追加する必要がある場合にオンコールの期待事項についてあなたと話し合います。すべてのチームメンバーがローテーションに入るわけではありません。ローテーションに追加のチームメンバーやプロダクトカバレッジが必要な場合、マネージャーがチームメンバーをローテーションに推薦します。

SSCS Tier 2 On Call ローテーションを構築する際に考慮する事項:

各地域（APAC、EMEA、AMER）に適切なカバレッジがあるか？
3つのドメイン（認証、認可、パイプラインセキュリティ）すべてにカバレッジがあるか？
ローテーション頻度はチームメンバーにとって持続可能か？

流れ:

あなたとマネージャーが準備ができていることに合意する
ローテーションリーダーが Incident.io（スケジューリングシステム）にあなたを追加する
最初のシフトがカレンダーに表示される
初めてのシフト準備チェックリストを実施する

チームまたはドメインを変更するとき

別のチームに移動したり、新しいサービス領域を担当する場合、別のローテーションに追加されることがあります。これも同様に機能します — 新しいマネージャー/ローテーションリーダーが準備ができたら追加を処理します。

ローテーションからの除外はどのように行われますか？

計画的な除外

チームを離れたり、サービスをサポートしなくなる場合:

マネージャーとローテーションリーダーに伝える
オフボーディングプロセスが始まる
最後のシフトを担当してからスケジュールを外れる
進行中の責任を後任に引き渡す

ローテーション期間中

一時的に一歩引く正当な理由がある場合（長期休暇、重要なプロジェクトなど）、ローテーションリーダーに相談してください。以下の選択肢があります:

ローテーション間の休息を取る
同僚とスワップする
オンコール頻度を減らす

オンコール負荷の追跡

ローテーションリーダーは以下を追跡します:

各エンジニアがオンコールを担当した回数
各人が処理したアラートの数
公平な割り当て以上を担っている人

なぜか？ 公平性を確保し、バーンアウトを防ぐためです。誰かが常にページを受けているなら、それはチームがアラートのチューニングとワークロードの分散に活用すべき重要なデータです。

オンコールの頻度はどれくらいですか？

頻度は地域とチームの規模によって異なります。SSCS 24x5 ローテーションの現在の配分:

地域別（24x5 平日カバレッジ）

APAC（アジア太平洋）

カバレッジ: UTC 23:00 - 07:00（ベストエフォート方式）
1人あたり年約6〜7週
チーム規模: 7名（認証: 2名、認可: 3名、パイプラインセキュリティ: 2名）
地域チームが最小のため頻度が高い

EMEA（欧州/中東/アフリカ）

カバレッジ: UTC 07:00 - 15:00
1人あたり年約5〜6週
チーム規模: 10名（認証: 6名、認可: 1名、パイプラインセキュリティ: 3名）
中程度の頻度

AMER（南北アメリカ）

カバレッジ: UTC 15:00 - 23:00
1人あたり年約4〜5週
チーム規模: 12名（認証: 3名、認可: 5名、パイプラインセキュリティ: 4名）
地域チームが最大のため頻度が低い

この差異は、3つの地域にわたる 24/5 カバレッジを提供するためにスタッフを配置していることと、地域によってチームの規模が異なるためです。APAC はチームが最小なので最も頻繁なローテーションになり、AMER はチームが最大なので最も少ない頻度になります。

目標: バランスと成長

シフト頻度の格差は認識しており、以下に積極的に取り組んでいます:

新しい APAC チームメンバーが参加した際にローテーションに追加する
負荷をより均等にするためのクロスステージカバレッジオプションを検討する
ローテーション頻度を監視して持続可能性を確保する

最大ローテーション頻度

持続可能性を確保するためにオンコール義務に上限を設けています。4週間に1回以上オンコールになることはありません。この上限を超えていると感じた場合は、すぐにマネージャーに伝えてください。それはスタッフを調整するか、アラートボリュームを減らす必要があるサインです。

ローテーションリーダーがあなたの具体的な頻度を伝えます。この情報は少なくとも1ヶ月前に Incident.io で公開されるはずです。

最小・最大チームサイズとは？

ローテーションリーダーは以下を計算しています:

誰も燃え尽きることなくカバレッジを提供するために必要な最小人数
ローテーションが頻度が低くなりすぎる前に追加できる最大人数

誰かが追加または削除された場合、これらの数字が変わることがあります。ローテーションリーダーはこのバランスを保つ責任があります。

ローテーション頻度を理解する

例: AMER に8名のエンジニアがいて、週ごとにローテーションする場合:

各エンジニアはおよそ8週間に1週間オンコール
AMER 時間内に常に誰かが対応できるよう継続的にカバレッジ
誰も頻繁すぎるオンコールにならないのでバーンアウトを最小化

例: APAC に7名のエンジニアがいて、週ごとにローテーションする場合:

各エンジニアはおよそ7週間に1週間オンコール
カバレッジは継続しているが負荷がやや高い
APAC の頻度を下げるため、より多くの APAC エンジニアの追加に積極的に取り組んでいます

スタッフィングモデルと公平性

SSCS ローテーションは、すべての地域にわたって公平で持続可能であるよう設計された構造化されたスタッフィングモデルを使用しています。

ターゲットチームサイズ

各地域の Tier 2 ローテーションには目標人数があります:

最小: 地域ごとに6名（欠勤があってもカバレッジを確保）
目標: 地域ごとに8〜10名（バランスの取れたワークロードと柔軟性）
現在: APAC: 7名、EMEA: 10名、AMER: 12名

地域の人数が不足している場合（6名未満）は、採用または再配分に取り組みます。過剰の場合は、全員が適切な頻度を得られるよう調整することがあります。

公平性の原則

スタッフィングモデルは以下の原則に基づいています:

地域内で全員が同等の割り当てを担う — ワークロードのパーセンテージは地域のチームメイトと一致するはず
地域への配慮 — タイムゾーンの違いとチームサイズの差異を考慮する
予測可能性 — 事前通知なしにローテーション頻度が突然変わることはない
持続可能性 — 4週間に1回以上のオンコールにならない
ドメインバランス — 認証、認可、パイプラインセキュリティにわたるカバレッジを確保する

公平性のモニタリング

四半期ごとに以下を確認します:

各人が何回オンコールを担当したか？ — 地域内で均等か？
シフトは公平に配分されたか？ — 幸運にも忙しい週を外れた人はいないか？
バーンアウトした人はいないか？ — 人々は頻度に満足しているか？
カバレッジ目標を達成したか？ — 各地域に必要な人数がいたか？
ドメインカバレッジはバランスが取れているか？ — 3つのドメインすべてが適切にカバーされているか？

配分が不公平になった場合は再調整します。

公平性について懸念がある場合

以下に気づいた場合:

地域のチームメイトよりも大幅に多かったり少なかったりするオンコール
地域のスタッフが不足または過剰に見える
ローテーション頻度が伝えられた内容と一致しない
1つのドメインが他より多くの負荷を担っている

声を上げてください。 ローテーションリーダーまたはマネージャーに話してください。私たちはこれを積極的に監視していますが、人為的ミスは起こります。あなたのフィードバックが問題を早期に発見するのに役立ちます。

ドメイン固有の考慮事項

1つのドメイン（認証、認可、またはパイプラインセキュリティ）を専門としていても、ローテーションでは以下が期待されます:

すべての SSCS 問題に対する初期トリアージ
主要ドメインでの深い専門知識
他の SSCS ドメインの基本的な知識
必要な場合にドメインスペシャリストにエスカレーションする意欲

クロスドメインのトリアージを助けるランブックを構築中です。