オンコール従業員: 報酬ポリシー キット

重要ポイント

• オンコール従業員には、混乱や不満、離職率の上昇を避けるために、明確な報酬ポリシーが必要です。

• 資格と期待値を事前に定義しておく必要があります。そうすれば、従業員はいつ対応可能か、どの程度迅速に応答できるか、何が稼働時間と待機時間に該当するかを把握できます。

• 報酬モデルは現地の労働法に準拠する必要があるため、オンコール手当ての計画を展開する前に法務顧問に相談してください。

• 大量のアラートを報酬の対象とし、適切に処理された少量のインシデントを評価しない報酬体系は、システムの信頼性を損ねる逆効果のインセンティブを生み出します。

• 燃え尽き症候群は離職につながり、それがローテーションの人員不足を招くため、公正なオンコール慣行は従業員とビジネスの両方を保護します。

オンコール作業は、IT、DevOps、エンジニアリング、サポートの各チームにとって現実です。システムが通常の営業時間外にダウンした際には、誰かが対応できる状態でなければならず、その役割を担う人には、プライベートな時間の中断を反映した報酬計画が与えられるべきです。

このガイドでは、オンコール従業員が何を期待すべきか、公正な報酬ポリシーを構築する方法、そして誤った行動を偶然に報酬の対象として扱ってしまう給与体系などの一般的な落とし穴を回避する方法について説明します。組織に合わせて調整できるポリシー テンプレートも用意されています。

Service Collection の Jira Service Management を使用すると、オンコール スケジュールのローテーションの構築と管理、エスカレーション ポリシーの設定、報酬ルールの文書化をすべて 1 か所で行うことができます。つまり、オンコール手当てポリシーは、チームがインシデント対応に使用するツールと密接に関連して適用されます。

オンコール従業員向け報酬ポリシー テンプレート

オンコール従業員とは

オンコール従業員とは、通常の勤務時間外にインシデントや緊急リクエストに対応する人です。通常、IT 運用、DevOps、サイト信頼性エンジニアリング、カスタマー サポート、インフラストラクチャ管理などの役割が該当しますが、時間的制約のある課題を扱うチームであれば、オンコールの責任を負う場合があります。

期待値は、通常、対応可能性と応答時間の 2 つに集約されます。オンコール シフトの従業員は所定の時間内 (重要度に応じて 5 分から 30 分の間であることが多い) に連絡が取れて稼働できる状態にあることが求められます。ほとんどの組織では、待機時間 (積極的に作業しておらず対応可能な状態) と稼働時間 (インシデントの解決に実際に取り組んでいる状態) を区別しています。

チームが「オンコール対応」で実際に何を求めるかを明確にしていない場合、期待値にばらつきが生じ、従業員の不満につながります。このような曖昧さがあると、「対応可能」の意味について誰も合意していないために応答時間が変動し、インシデント管理にも問題を引き起こします。

オンコール従業員の報酬の権利

公正なオンコール報酬計画がないと、多くのことが誤った方向に進む可能性があります。インシデントによるストレスが強い環境下でその場で要請されて、通常業務に加えて残業することを期待されても、報酬が追加されなければ従業員は憤慨して、燃え尽き症候群に苦しむことになるでしょう。

また、オンコール モデルに従業員がオンコールに対応することが求められる場合について明示されておらず、オンコール報酬計画が正式なものではなく伝達もされていない場合、チーム内に余計な緊張と混乱を招くリスクがあります。

検討して正式化した計画がない場合は、実質的に従業員に無償で働くように要請していることになります。それによってオンコール勤務を望む従業員が減って、公平とは言えない形でオンコール シフトにおいて他の従業員により多くの仕事を任せることになり、燃え尽き症候群や従業員の定着率の低下につながるでしょう。

勤務地によっては特定の法律があり、その法律によって、組織向けに選択できるオンコール報酬モデルが左右される場合があります。オンコール報酬計画を正式化する前に、弁護士に相談して連邦政府のガイドラインを調べるようにしてください。

オンコール従業員の報酬ポリシーと要件

どのような企業でも、公正で一貫したオンコール手当てポリシーを必要とします。従業員が自分の時間に対して公平に報酬を受け取っていると感じられれば、燃え尽き症候群に陥る可能性が低くなり、健全で持続可能な労働文化を構築できる可能性が高くなります。

従業員ハンドブックなどの他のポリシーを伝える際には、必ず自社のオンコール報酬ポリシーも明確に文書化する必要があります。このポリシーは、オンコール職務に対応する従業員に説明する必要があります。これは、入社前の面接プロセスの一環として行うのが理想的です。

導入する計画のタイプは、会社の規模、チームが一般的に直面するインシデントのタイプと重大度、従業員の報酬と評価に関する企業文化によって決まります。

会社またはチーム向けのオンコール手当てモデルを選択する場合は、検討しているモデルが現地の労働法に従っていること、および適切な文書が従業員に提供されていることを常に確認するようにします。

オンコール手当てにおける逆効果のインセンティブの防止方法

オンコール報酬体系は、設計に注意を払わないと、誤った行動を意図せず助長してしまう可能性があります。最も一般的な例は、アラート量に基づく報酬です。インシデントごと、またはページごとに支払うというものです。表面的には、これは公正であるように見えます。しかし実際には、ノイズの多いシステムを修正したり、オンコールを改善したりすることで給与が減ってしまうため、エンジニアがそうした取り組みを行うことを阻害します。

未処理のアラート数を基準とするよりも、システムの信頼性と応答品質に報酬を結び付ける方が優れたアプローチです。定期的に発生する課題を自動化したり、誤検知を調整したりしても給与が下がらないことがオンコール従業員に周知されていれば、実際にシステムを改善する意欲が湧きます。

ここでは、報酬計画で逆効果のインセンティブを特定し、回避するためのいくつかの方法を紹介します。

• アラート対報酬比率を監査する: オンコール従業員がインシデントの多い週により多くの報酬を得ている場合、報酬体系が安定性よりも混乱を報いている可能性があります。

• オンコール手当てをインシデント ボーナスから分離する: ローテーションに参加することに対する定額料金を設定し、それに加えて実際の稼働時間に対する追加報酬を与えることで、アラート量を多く保とうとする動機を取り除きます。

• アラートによる疲弊のパターンを確認する: 頻繁で優先度の低いアラートは、IT インシデント アラート ルールに作業が必要であることを示しており、チームにより多くのオンコール手当てが必要であることを示しているわけではありません。

適切な行動に対して報酬を与える

逆効果のインセンティブを取り除いたら、より良い結果につながる行動を積極的に報酬で評価します。オンコール従業員が詳細な事後分析を作成したり、繰り返し発生する課題に対する自動化を構築したり、インシデント通知を改善したりする作業は、全員にメリットをもたらすものであり、報酬モデルにはそれが反映されるべきです。

次のような行動を認識し、報酬を与えるのが妥当です。

• 繰り返し発生するアラートの削減: 単にページを認識して次に進むのではなく、根本原因を解決しようと努力した人は、パフォーマンス レビューやボーナス制度において評価されるべきです。

• ランブックの文書化: 優れたランブックは、後に続くすべてのエンジニアの時間を節約します。ランブックへの貢献に評価を結び付けることで、ナレッジ共有が促進されます。

• 応答時間と解決品質の向上: より迅速で確実なインシデント解決により、ダウンタイムを削減できます。これらのメトリックをオンコール パフォーマンス評価の一環として追跡します。

実用的なセーフガードを実施する

公正なオンコール手当ては、スケジュール自体が持続可能である場合にのみ機能します。最高の報酬計画でも、同じ人が回復時間なしに連続でシフトを担当していれば、燃え尽き症候群を防ぐことはできません。

報酬ポリシーに含めるべき実用的な制限は次のとおりです。

• 連続オンコール シフトの制限: 従業員がオンコールを担当できる最大日数を設定します。この日数に達した時点でローテーションから外れなければなりません。ほとんどのチームでは、これを 7 日間に制限し、合間に休息期間を必須としています。

• 最大稼働時間の制限: 夜間に数時間にわたって積極的にインシデント対応を行った従業員に対して、翌朝のフルタイム勤務を期待すべきではなりません。代休のトリガーとするしきい値を定義してください。

• 繰り返し発生するアラートに対するランブックの必須化: 同じ課題が 2 回以上発生するような場合のために、文書化したランブックを用意しておく必要があります。これにより、オンコール従業員が既知の修正方法がある問題に対して時間を浪費しなくてすみます。

オンコール従業員の信頼性に応じて報酬を調整する

オンコール手当てポリシーの目的は、どんな犠牲を払ってでもより多くのインシデントを処理することではなく、少なくてもインシデントをより適切に処理することです。インシデント管理ツール (Service Collection に用意されている Jira Service Management など) を使用して、オンコール スケジュールの追跡、インシデントのログ記録、ポリシーに照らしたパフォーマンス測定を行うことができます。すべてが 1 つのシステムに集約されていると、パターンを見つけやすくなり、燃え尽き症候群が発生する前にローテーションを調整できます。

本当に信頼性を反映する指標、つまり平均解決時間、アラート件数の推移、ランブックの整備状況、そして実際に対応が必要なアラートとノイズの比率に注目しましょう。オンコール担当の従業員が、組織がそうした成果を評価していると実感できれば、オンコール体制を全員にとって持続可能なものにするための先を見据えた取り組みに、より積極的に投資するようになります。