公式資料
「デジタルオペレーションの現状」独自調査レポート
公式資料 エンジニアの燃え尽きを防ぐ秘訣とは？
一段と信頼性の高いシステムを顧客が求めるようになり、勤務時間外や夜間の対応など、技術チームへの要求も増しています。本レポートでは、19,000 社以上、100 万人を超えるユーザーで構成されるPagerDutyプラットフォームから収集したデータを基にしたシステム運用の”今”を解説！→ PagerDutyの資料をみる（無料）
DevOpsチームの中で、業務としての「オンコール対応プロセス」はよく話題に上ることがあります。では一方で「オンコール対応に従事するチームメンバーが抱える個人的な悩みや問題」についてはどうでしょうか？
- 「オンコールシフト中のストレスや不安にどう対処したらよいか？」
- 「オンコールローテーションと子供の世話といったメンバーの個人的な事情を両立させるにはどうしたらよいか？」
- 「燃え尽きや離職といった問題は、チームメンバー同士の思いやりで解決できるのか？」
オンコール対応のプロセスが適切にマネジメントされていたとしても、オンコール対応チームにおけるこういった悩みは尽きません。そこでPagerDutyでは、2021年11月から12月にかけて、9つのチームからオンコール担当のエンジニアを集め「担当者の現場目線から見たオンコール対応についてのディスカッション」を実施しました。チームメンバーがオンコール対応の中で抱える悩みを共有して議論を交わすことにより、オンコール対応者の目線で特に重要なポイントとして5つの教訓を得ました。この記事では、エンジニアによる議論の中で得られた5つの教訓をご紹介します。「オンコール対応とプライベートの両立に悩むエンジニア」や「オンコール対応におけるストレスを軽減させたい」方にとってヒントになりましたら幸いです。
目次
そもそも「オンコール」とは
「オンコール(On-call)」とは、システム障害をもたらしうる「人による緊急対応が必要なインシデント」に即座に対応するために、インシデント対応者と対応時間をあらかじめ指定し管理する仕組みです。まず、インシデント対応とオンコールの基本についてご紹介します。
1. インシデント対応とは
現代の私たちの生活は、ITサービスやシステムに大きく依存しています。例えば、医療システムの停止は人命にかかわる問題であり、ITサービスやシステムの安定した稼働や早急な障害対応は社会課題の一つとなっています。そんな「システム障害の予防と対応」において重要なのが、インシデント対応です。PagerDutyでは、インシデントを「システム障害に際して何らかの対応が必要な問題」と定義しています。早期にインシデント対応はシステム障害を未然に防ぐことに繋がります。また、適切なインシデント管理はシステム障害が発生した際の迅速なシステム復旧につながります。一般的に、インシデント対応は「インシデントの検知」「トリアージ」「担当者の動員」「協力/解決」「事後分析による学習と予防」の5つのステップで実施されます。インシデント対応の詳しい流れやポイントについては、こちらの記事をご覧ください。
2. オンコールとは
ITシステムの運用管理におけるオンコールとは、勤務時間外も含めて緊急対応が必要なインシデントが発生した場合に即座に対応できるよう、対応者と対応時間をあらかじめ指定しておく仕組みです。現代は「サービスが24時間365日常時稼働していること」が顧客から当たり前のように期待される時代です。たとえ深夜であっても、サービスが使えなかったり重大なバグが見つかったりすれば、「企業イメージの低下」や「顧客満足度の低下」などユーザーに実害を与えて企業の信用を大きく失う可能性があります。それを防ぐため、オンコールによるインシデント対応が求められているのです。
3. DevOps実践におけるオンコールとメリット
システムやサービスの開発チームと運用チームが明確に分かれていた組織では、オンコールを含むインシデント対応は運用チームが担っていました。しかし、DevOpsを実践するチームにおいては、開発しているエンジニアがサービスの信頼性と可用性に対する責任も負うため、エンジニアは通常の開発だけでなくオンコール対応にもあたるのが一般的です。開発したエンジニアがオンコール対応することには大きなメリットがあります。
まず、システムやプログラムを熟知しているため、より早期な課題の把握と最適な対処が可能です。また、オンコール対応で障害対応の経験を積むことは、そもそも障害が起こりづらいシステムの開発にもつながります。DevOpsにおける優れたオンコールとは、単に早急な障害対応を実現するだけでなく、システムの可用性を高めシステム障害発生自体を減らすことにも繋がります。
エンジニアの燃え尽きを予防する「オンコール、5つの教訓」
オンコール対応で論点になることに、不適切なオンコール管理による「エンジニアの負担増大」や「エンジニアの燃え尽き」があります。そのため、適切なオンコール管理のプロセスやスケジューリングについて多くの議論がなされた結果これまでにベストプラクティスが提示されてきました。
しかし、オンコール管理が適切であればすべての問題が解決されるわけではありません。特に、オンコール担当者は「エンジニアそれぞれに異なる個性・スタイル」や「家族などの個人的な事情」がありますが、緊急性と重要性の高いオンコール対応を前にそうした個人的な事情と向き合うことが難しくなるケースが生じます。そこで、PagerDutyでは9つのチームからオンコール担当のエンジニアを集め、オンコール対応について座談会形式でのディスカッションを実施しました。その結果、オンコール担当者が抱えるストレスや悩み、プライベートと向き合い解決策を考えるうえでヒントとなる次の5つの教訓を得ました。
- 教訓1️⃣：「チーム内の思いやり」や「安心できる雰囲気づくり」を重視すべし
- 教訓2️⃣：監視画面を一日中眺めるのではなく、自分ができることに集中しよう
- 教訓3️⃣：インシデントの事後分析は作業量が多く精神的に消耗するため担当や進め方を工夫すべし
- 教訓4️⃣：緊急度が低いインシデントは通知しないようにルールを設定し、夜間の不要な呼び出しを防止しよう
- 教訓5️⃣：「オンコールが1週間続くとエンジニアは燃え尽きやすい」ことを忘れずに
次の章では、今回のディスカッションに参加したメンバーの勤務状況をご紹介ともに、5つの教訓にそれぞれについて詳しくご紹介していきます。
数字で見るオンコール勤務状況
今回の5つの教訓を導き出す前提として、座談会に参加したチームの勤務状況は次のとおりです。
- オンコールローテーションのエンジニアの数は平均で5名
- メンバーの60％がオンコールの2次受け対応も担当している
- オンコールシフトに入る回数は平均で3.5週に1回
- オンコールシフトの長さは平均で1週間（シフトを平日と週末で分けているチームもあり）
- 1週間のオンコール対応時間は平均で4時間。9チーム中2チームが勤務時間のほぼすべての時間をオンコール関連の問題対応にあてている。
以下の棒グラフは、今回の座談会に参加したメンバーの「オンコール対応時間の分布」を表しています。週0-5時間と答えたのがチーム全体の55％。週5-10時間が22％、週30-35時間が11％、週40時間が11％でした。
※オンコール対応時間別チーム数
教訓1️⃣：「チーム内の思いやり」や「安心できる雰囲気づくり」を重視すべし
次に、今回導き出した5つの教訓についてご紹介していきます。
まず、教訓その一。チームメンバーが安心して働ける環境をつくるためには「チームの雰囲気づくりがすべて」といっても過言ではありません。例えば、1週間のオンコール対応で他のメンバーに交代を依頼できるルールがあるとします。この場合、チームの雰囲気づくりにおいて非常に重要なのは「交代が奨励されていることを自らの言葉や行動ではっきり伝えること」です。チームの雰囲気を短時間で変えることは難しいですが、少しずつ変化させ定着させることはできます。そのために、チームに変化を受け入れてもらえるよう上手に働きかけましょう。具体的には「チームの誰かが実際に交代を依頼した場合に、チームのレトロスペクティブでそのメンバーが交代を依頼したこと自体を褒めること」も方法の一つです。チームにオンコールに関する就業ルールがあれば、そこに「交代を依頼できる」と一言書き加えるよう提案するのもよいでしょう。また、オンコール担当者・管理者にかかわらず、オンコール対応のエンジニアが働いている様子を気にかけることも大切です。重要なインシデントが起きた場合などは、特に気にかけるようにしましょう。このような思いやりのあるチーム内の行動こそが、オンコール対応のエンジニアを尊重したインシデント対応のあり方です。
なかでも大切なことは、オンコール対応のエンジニアが抱える個人的な事情に対して、チームメンバーや管理者が共感してあげることかもしれません。ペットや子供、高齢の親がいてオンコール対応が大変であったり、近親者が亡くなったときなど精神的に辛い出来事が起きてオンコール対応中のストレスが高まることは誰にでも起こり得ることです。「プライベートが大変な時期には、オンコール対応のシフトに入らないようにしましょう」といった提案を積極的にすることが大切です。オンコール対応は、「速く問題を解決しなければならない」という緊迫感があるなかで高い集中力を求められる仕事であるからこそ、安心して交代を依頼できたり、個人的な事情に配慮し合えるするチームの雰囲気づくりが重要になるのです。
教訓2️⃣：監視画面を一日中眺めるのではなく、自分ができることに集中しよう
その二。オンコール対応では、いち早く問題に気付き対処することが必要となります。しかし、オンコール対応中だからといって、一日のすべての時間を監視にあてる必要はありません。問題が発生すればシステムが呼び出してくれるので、問題の検知はシステムに任せることで自分がコントロール/制御できないことを忘れて「今できることだけ」に集中することが大切です。シフトの引き継ぎミーティングで前任者から申し送りを受ければ、次に自分が担当するシフトの準備は十分です。また、緊急度の低いインシデントの通知でストレスレベルを上げる必要もありません。通知が多すぎてストレスを感じる場合は、通知設定を見直し、緊急度の低いインシデントの通知を停止するようにしましょう。
今できることに集中したうえで、もし、オンコール対応中に時間があれば次のシフトに入っているエンジニアや未来に向けた改善のためにオンコール対応環境を整えておきましょう。例えば、「ディスクの容量不足」「ローテーションが必要なログ」「アラートノイズ」などの問題が繰り返し起きている場合は、対応を効率化できるように少しでも対策を講じておくのも一手です。
教訓3️⃣：インシデントの事後分析は作業量が多く精神的に消耗するため担当や進め方を工夫すべし
その三。「インシデントの事後分析/レトロスペクティブ」は優れたシステム運用体制構築の基本です。事後分析作業を通じて、失敗点や改善点の発見に加えて、同じミスの繰り返しを回避するための方法を学べます。とはいえ、事後分析やその文書化はとても大変な作業です。特に、複数のチーム間で対応の調整が必要な重大なインシデント対応では、そもそもエンジニアの大きなストレスがつきものですが、それに加えて事後分析の業務量が増えればストレスは増すばかりです。さらにいうと、1件だけのインシデント対応ならまだしも、あと1週間そのストレスが継続するとなればそのエンジニアが抱えるストレスをケアすることが大切になります。こういったケースでは、人的リソースが許す限り「事後分析は最初の対応者ではなく別の担当者が行う」というルールや「大きなストレスを感じるエンジニアは解決後に休憩時間を取れる」といったルールをつくることも考えられます。オンコール対応するエンジニアがクールダウンする時間を設けることで、彼らの業務スケジュールに余裕が生まれます。その結果、エンジニアが休憩時間を確保できるだけでなく、業務増加の影響で後回しにしたプライベートな用事を済ますことが可能になるためストレスの緩和に繋げることが可能になります。
事後分析レポート作成の効率化に興味のある方には、生成AIを使ったPagerDutyの「インシデント事後分析レポート(ポストモーテム)のドラフト作成」機能の利用もおすすめです。機能の詳細は、こちらの記事「DevOpsを推進する生成AIによる3つのPagerDuty新機能ベータプログラム」をご覧ください。
教訓4️⃣：緊急度が低いインシデントは通知しないようにルールを設定し、夜間の不要な呼び出しを防止しよう
その四。オンコールのシフト中は、緊急の呼び出しが発生しうる状況であり、オンコール担当者はインシデント通知に神経を尖らせます。それは就寝中も例外ではありません。しかし一方で、即時の対応を必要としない通知は、エンジニアの睡眠を妨げるだけでなく、大きなストレスに繋がります。そのため、緊急のインシデント対応を必要としない通知は緊急度「低」に設定し、不必要に就寝中のオンコール対応のエンジニアを呼び出さないことが大切です。これを徹底するために、新しいオンコールエンジニアをオンコールに登録する際は、インシデント対応の緊急度が「低い」場合は「通知しない」に設定しておきましょう。また、新しいオンコール対応エンジニアの研修に、通知の設定方法を含めることで、オンコールのローテーションに登録される前に設定状況が適切か確認し、不要な呼び出しを防止できます。
教訓5️⃣：「オンコールが1週間続くとエンジニアは燃え尽きやすい」ことを忘れずに
座談会参加者のオンコールシフトの長さは、先述したとおり平均で1週間でした。しかし一方で、ディスカッションでは「1週間という長さでオンコールシフトに入るエンジニアは燃え尽きやすい」という結論になりました。1週間続けてオンコールシフトに入ることは、「完全にオフではない時間が7日間続く」ことを意味し精神的に大きな負担となります。シフト中は通知を受けていなくてもスタンバイ状態でいるため、それは当然の結果ともいえます。しかし、単純に「オンコールシフトの長さ」だけが問題なのかというと、そうとも言い切れません。オンコール担当者のストレスには、次のような様々な要因があるのです。
例：エンジニアによって望ましい働き方は異なる
エンジニアによって望ましい働き方は異なります。アンケートなどを使い、オンコールスケジュールについてメンバーの希望を聞いてみましょう。
例：シフト後のストレスは管理者の想定よりも大きい
シフトを終えたオンコールエンジニアはどのような心理状態になるでしょうか。対応した内容や体調などはその時々によって異なるため、まずは実態を把握することが大切です。シフトの終了時間に5段階評価ができるツールなどを使用して定期的にアンケートを取ることでその変化を時系列で把握することも一つの手です。現場にとって適切なオンコールシフトを設計するための参考にするのも良いかもしれません。
例：シフト中の集中を妨げるノイズが多い
チームが担当しているシステムやサービスでは、本来気にする必要のないアラートがどれくらい発生しているでしょうか？こうした本来は気にする必要がないアラートはチームにとって「ノイズ」であり、ノイズが多いほど集中を妨げられるためストレスに繋がります。対策としては「オンコール対応のシフト時間の短縮」が考えられます。ここで挙げた以上のような例を考慮しながら、オンコールローテーションのシフトや時間の長さを検討してみましょう。シフトの長さや交代のタイミングは、「1週間」のように一定期間にするだけではなく、「平日と週末」「勤務時間中と勤務時間外」「2日間、2日間、3日間」とする方法もあります。オンコールシフトのスケジューリング方法でお悩みの方は、こちらの記事「エンジニアを燃え尽きから救う『ラウンドロビンスケジューリング』を活用したオンコール管理方法とは？」もぜひご参考にしてください。
PagerDutyでオンコールチームのベストプラクティスを実践しましょう!
オンコール対応はストレスが発生しやすい業務ともいえますが「チーム内の思いやりのある雰囲気」「メンバーの希望にできるだけ沿ったオンコールローテーションスケジュール」を整えることで、エンジニアの燃え尽きリスクを大きく軽減することが可能です。これを機に「オンコール管理におけるプロセスやスケジューリングの最適化」と併せて、チームマネジメントの側面からもオンコール管理を見直してみてはいかがでしょうか。オンコールを含めたインシデント管理でお悩みの方には、PagerDutyがおすすめです。PagerDutyのインシデント管理は、強力なインシデント対応の効率化によってエンジニアのストレスを軽減し、オンコール対応のベストプラクティスを実践するうえ上でも最適です。適切なインシデント対応方法やPagerDutyの導入効果にご興味のある方は、PagerDuty公式ブログでご紹介するベストプラクティスやLINE社のPagerDuty活用事例を基にしたこちらの記事「事例から読み解くあるべきインシデント対応方法とは？」もぜひ参考にして下さい。
この記事が気になったら
PageDuty公式アカウントをフォロー
この記事の著者
PagerDuty
Manager, Solutions Consulting
ソリューションズコンサルティング マネージャー
PagerDuty
Manager, Solutions Consulting
ソリューションズコンサルティング マネージャー
ネットワーク機器メーカーにて、インターネット・データセンターのインフラ構築に従事した後、CDNベンダーにて主に動画・ゲーム・電子書籍サービスの拡張性ならびに信頼性向上・セキュリティ対策プロジェクトを推進。2022年よりPagerDuty株式会社にて、インシデント対応の自動化等、デジタルオペレーションのモダン化・成熟度向上を支援している。趣味は自家製スモーカーを使ったベーコン等の燻製作り。
SNS
関連ブログ記事
人気記事
検索
タグ目次
