公式資料
「デジタルオペレーションの現状」独自調査レポート
公式資料 エンジニアの燃え尽きを防ぐ秘訣とは？
一段と信頼性の高いシステムを顧客が求めるようになり、勤務時間外や夜間の対応など、技術チームへの要求も増しています。本レポートでは、19,000 社以上、100 万人を超えるユーザーで構成されるPagerDutyプラットフォームから収集したデータを基にしたシステム運用の”今”を解説！→ PagerDutyの資料をみる（無料）
「システム運用上の小さな問題が、実はのちに起こる深刻な問題の前兆だった…」ということ、経験ある方もいらっしゃるのではないでしょうか。それでは、「問題を小さいうちに解決して大きな問題への発展やチームと顧客への影響を避ける」ためにはどうしたらよいでしょうか？
中には、DevOpsやSREの導入により、エンジニアがシステム運用面にも参加し、積極的に運用の問題解決に取り組んでいる方もいらっしゃるかと思います。エンジニアがオンコール対応に携わることで、システム運用における問題を早期に認識し、根本解決に向けて開発にフィードバックすることが期待できます。
しかし一方で、エンジニアが運用面の問題解決に取り組もうとも、マネージャーなどの意思決定により新しい開発が優先され、運用面の改善が後回しになってしまうことも少なくありません。そこでシステム運用面での問題に取り組むために、まず見直したいのが「オンコールの引き継ぎミーティング」です。
引き継ぎミーティングをうまく活用すれば、エンジニアが気づいたシステム運用上の問題をチームメンバーに共有し、解決策について話し合い、それを行動に移す習慣をつくることが可能です。また、引き継ぎミーティングはオンコールへの理解や、対応の負担に対する共感を得る際にも有効です。この記事では、オンコール対応の引き継ぎミーティングを効果的に行ない、システム運用上の問題を解決に導くためのポイントを紹介します。
目次
オンコールとは
システム運用における「オンコール」とは、「インシデント対応が必要になった際に迅速に対応できるよう対応者と対応時間を事前に決めておく仕組み」を指します。オンコール対応には、休日や夜間といった勤務時間外の対応も含まれます。
現代のWebサービスは「24時間365日のサービス提供が当たり前」としてユーザーは考えるため、システムも常時稼働することが求められています。たとえ深夜であっても、システムの停止に伴うサービス提供の停止は「企業イメージや顧客満足度の低下」につながりかねません。そのため、24時間体制の運用・保守対応が必要とされます。その24時間体制のシステム運用を支える仕組みの一つがオンコールです。
開発エンジニアがオンコールに参加するメリット
ウォーターフォール開発をはじめとした従来型の開発では、運用チームと開発チームが独立して存在しています。システム運用面の問題は運用チームが対処しますが、改善のために開発に取り組むことは基本的にありません。また、開発チームも新機能の開発を優先するため、運用面の改善活動は後回しになってしまう傾向があります。
技術が著しく進化し、新機能が次々と開発される現代において、このようなサイロ化した体制では運用チームが運用負荷の増加に対応しきれず、不安定なサービス提供になってしまいます。インシデント対応が手に負えなくなれば、重大なインシデント発生により甚大な損失へとつながることも考えられます。システムの運用面に課題を抱えた状態では、いくら良い機能を開発したとしても、ユーザーの元に高い品質のサービスをで安定的に提供できません。そのため、現代ではシステム運用の側面も重視した開発体制が求められ、DevOpsやSREといった概念・手法に基づく開発体制では積極的にエンジニアが運用にも関わる形態をとることが増えています。
開発エンジニアが運用に関わる中でも、特にオンコールは、その場での迅速な対処を実現するだけでなく、システム運用上の問題がどれほどチームやサービス提供に影響を与えるのかを理解するという点で非常に重要です。例えば、夜中に発生したインシデントが、比較的容易に解決できたとします。この場合、従来型のサイロ化した体制だと、開発エンジニアはこのインシデント対応について関心がないかもしれません。
しかし、実際にオンコール対応に携わり、夜中に呼び出された経験のあるエンジニアは「コードを修正して再発防止できないだろうか」と考えるのではないでしょうか。システム運用における小さな問題は、状況によってはオンコールメンバーに大きな負担を与え、放っておけば重大なインシデントにつながるリスクにもなります。そのため、エンジニアがオンコールに参加してより早い段階で運用面の小さな問題にも気づき、改善を実施することが大切です。
オンコール対応の引き継ぎを改善する五箇条
現実には、開発エンジニアがシステム運用上の問題点に気づいていても、改善の実施は容易ではありません。その理由の一つとして、マネージャーやビジネス側のステークホルダーはめったにオンコールシフトに入らないため、呼び出されたときの大変さを理解していないことが挙げられます。この場合、マネージャーは「オンコールメンバーが抱える悩みやストレスへの共感」や「運用のレジリエンスに対する責任感」がないまま、業務の優先順位を考えることになります。
その結果、一時的に解決したシステム運用上の問題を気にすることなく、新しい機能の追加をエンジニアに指示してしまうことなどが生じえます。このような状況では、目の前に取り組むべき運用上の問題があっても、エンジニアは解決する気力が起きないでしょう。そうして、開発エンジニアがオンコール対応で把握したシステム運用上の問題は、放置されてしまうことが生じます。放置された運用上の問題は、はじめは小さな問題だったとしても、システム停止のような大きな損害を引き起こし、チームやビジネス、さらには顧客への悪影響につながるおそれがあります。
では、エンジニアがオンコールで見つけた運用上の問題を放置せず、改善するためにはどうすればよいでしょうか。このときにおすすめなのが「オンコール対応の引き継ぎ」を見直すことです。オンコール対応の引き継ぎの時間と内容を活用すれば、オンコール業務への共感を深め、より問題の解決に取り組みやすくなります。また、オンコールへの認識自体を改めることで、オンコール業務の負担を減らせるでしょう。具体的に、オンコール対応の引き継ぎを活用してシステム運用上の問題を解決するための「5つのポイント(五箇条)」を紹介します。
- 1️⃣ オンコール対応の引き継ぎを習慣化する
- 2️⃣ オンコール引き継ぎに非エンジニアを招いて共感を得る
- 3️⃣ オンコール引き継ぎでメトリクスを確認し運用状態を把握する
- 4️⃣ 改善に向けて具体的に行動する
- 5️⃣ オンコール対応の「あるべき姿」の意識強化
次章から、それぞれのポイントについて詳しく解説します。
1️⃣ オンコール対応の引き継ぎを習慣化する
エンジニアがチャットルームで業務上の問題について話しているだけでは、オンコール対応で見つかった問題は見逃されてしまうかもしれません。そうした事態を避けるためにも、オンコールの引き継ぎに特化したミーティングを定期的に開催しましょう。新しい問題や、まだ解決していない問題を定期的に確認することで、問題解決に積極的に取り組もうと思える環境づくりにつながります。例えばPagerDutyでは、オンコールシフトを通常1週間単位で設定しており引き継ぎのミーティングも同じ頻度で行ないます。
2️⃣ オンコール引き継ぎに非エンジニアを招いて共感を得る
オンコール中のインシデント発生によって就寝中に叩き起こされるのは、本当にストレスを感じるものです。特に、非エンジニアでオンコール対応の経験がなく、この状況のつらさやストレスへの共感が乏しければ、リーダーであっても適切な意思決定を下すのは難しいでしょう。
そこで、「オンコールチームへの仲間意識」や「オンコールメンバーが抱える悩みやストレス」に共感を持ってもらえるよう、エンジニアチーム以外のステークホルダーにも引き継ぎのミーティングに参加してもらいましょう。これにより、組織全体のより良い意思決定につながります。
具体例を挙げます。あるPagerDutyのプロダクトマネージャー（PM）は引き継ぎミーティングに参加したことで、オンコール業務の大変さが、エンジニアと顧客にどれだけ大きな影響を与えるかを理解でき、さまざまな気づきがあったと言っています。引き継ぎの様子を見ることで、PMは自分たちが決めた優先順位がどのようにオンコールメンバーに影響を与えているのかを確認でき、その結果、次の企画会議からは、製品チームと技術チーム間で満足度のバランスがうまくとられているかを気にかけるようになります。例えばこうすることで、運用の問題を無視して新機能の開発にだけ注力するような事態は少し減るかもしれません。
また、技術/エンジニアチームのリーダーにとって大切なのは、チームメンバー一人ひとりが働きがいを感じ、モチベーション高く当事者意識を持ってクリエイティブな発想ができるチームカルチャーを醸成することにあります。技術チームのリーダーがオンコール対応の引き継ぎミーティングの内容を注意深く観察すれば、普段のチームミーティングや1on1ミーティングでは出てこない問題点が見つかるかもしれません。引き継ぎミーティング後にリーダーがすべきことは、チームが必要とするサポートとリソースの提供です。例えば、遠慮せずに休暇をとるように伝えることや、技術面・運用面に関するチームの意見が組織全体で尊重されるように働きかけること、などが挙げられます。
3️⃣ 引き継ぎでキーとなるデータを確認し運用状態を把握する
インシデント発生により混乱する状況が何度も起きると、やがてチームはその状況が当然だと思うようになります。そして「誰も全体像を把握しようとしない」「同僚の不安に気づかない」といった事態が発生するのです。このような場合、引き継ぎミーティングでオンコールのキーとなるデータ・数値を確認しましょう。メトリクスの値を確認することで「インフラの健全性」と「メンバーの健康状態」について、実際の状況を把握できます。運用状況の可視化や、引き継ぎミーティングで役立つデータとツールをいくつか紹介します。
✅インシデントの発生数
インシデントの発生件数が多いほど、チームが混乱する状況が訪れます。そのため、まずはインシデントの発生傾向を掴むことが大切です。例えば、PagerDutyでは「サービス」「チーム」「ユーザー」ごとに、インシデント数を数値とグラフで提供します。毎回の引き継ぎミーティングでチームやサービスでのインシデントの発生数を比較して傾向が見つかれば、解決策を検討する際のヒントとなるでしょう。
✅チャット履歴
インシデント対応の状況やエンジニアの気づきは、チャット履歴に残されていることがあります。そのため、引き継ぎミーティングでチャット履歴を確認すれば、引き継ぎ内容の抜け漏れを防げます。このようにチャット履歴を活用するためには、SlackやMicrosoft Teamsといったチャットを統合し、すべてのインシデント通知を1つの専用チャンネルに集約するのがおすすめです。PagerDutyのエンジニアは、インシデント通知を常に同じチャンネルで行っています。これは、スレッドの識別と分析をスムーズに行ない、トピックや問題の傾向を見つけやすくするためです。
✅カスタムレポートの作成
振り返りや今後の検討に役立つのが、カスタムレポートです。PagerDutyのAPIを使えば、ビジネス向けにカスタマイズされたレポートやアプリを作成できます。例えば、PagerDutyの機能拡張では、オンコールメンバーが勤務時間外にどれほどインシデント対応をしているかを確認できます。引き継ぎミーティングでこのデータを共有できれば、チームは自分たちの業務環境を一目で把握でき、次のアクションにつなげられるでしょう。
4️⃣ 改善に向けて具体的に行動する
✅タスク化→実行→振り返り→調整
引き継ぎミーティングで表面化した問題には、具体的な行動で対応しましょう。例えば、PagerDutyとJiraの統合により、インシデント対応で発生した想定外の業務を簡単に追跡できます。そして、その作業をタスク化すれば、オンコール対応のエンジニアに割り当てることが可能です。
このように、問題に対して具体的なアクションとの紐付けができれば、改善される可能性がさらに高まります。アクションの結果や得た学びは次の引き継ぎミーティングで振り返り、より良いアプローチ方法の検討につなげましょう。
5️⃣ オンコール対応の「あるべき姿」の意識強化
オンコール業務を保守業務の単なる一部として捉え、「業務内容や働き方がはっきり決められていない仕事」という考え方をしているチームが多くみられます。この状態では、システム運用上の問題が放置されて甚大な損害につながったり、過度な労働やストレスでエンジニアが燃え尽きてしまったりしかねません。では、こういった思考から抜け出すには、どうしたらよいでしょうか？それには、オンコール対応業務のあるべき姿を次のように明確化することが大切です。
A. オンコール対応の技術者は「運用上の問題の調査」「原因の追究求」「解決」に徹する。
B.「新機能を使う」といった仕事は本来の業務とは異なり、やって当然の仕事ではない。
C. 大変なオンコール対応業務が続いた夜や週末のあと、エンジニアは休憩をとって疲労回復に努める。
オンコール対応の引き継ぎミーティングではこの「あるべき姿」を確認し、そのうえで、次のようなメッセージをはっきりと伝えることが大切です。
・運用の改善には努力が必要であり、その改善に取り組むには、ふさわしい時間と場所が必要
・オンコール対応の業務量は持続可能な範囲でなければならず、対応者には休憩時間が必要
オンコール対応業務のベストプラクティスやオンコール業務継続のヒントを知りたい方は、こちらの記事『燃え尽きエンジニアを救う「オンコール最適化、5つの教訓」』をご覧ください。また、「The On-Call Survival Guide（英語）」も役立ちます。
オンコール業務への共感を得てシステム運用の問題解決に取り組もう
エンジニアにオンコール業務を任せることは、「継続的改善」と「システムの安定性」の維持に有効です。しかし一方で、DevOpsを担うエンジニアは、システム開発に加えて運用という負荷とストレスを抱えることになるのを忘れてはいけません。
システム運用面の問題解決を進める上でまず必要なのは、技術チーム以外を含む社内のステークホルダー全員が、エンジニアのオンコール業務について正しい理解と共感を持つことです。理解と共感が乏しければ、技術チーム以外のリーダーが下した決定が、エンジニアの健康や彼らが開発したシステムに予想外の影響を与えることがあります。組織全体で最適な意思決定となるように、技術チームのリーダーやその他のチームリーダーも、オンコール対応の引き継ぎミーティングに参加しましょう。これは、チームの業務環境や製品を改善する上で必要なことです。ここで紹介した内容をもとに、ご自身のチームでも「どうすればチーム全員に共感をもってもらえるか」についてアイデアを出し合ってみることをおすすめします。
そして、オンコールへの理解や共感と共に欠かせないのが、エンジニアの負荷軽減です。PagerDutyは、監視ツールからのアラートノイズを低減して自動診断を実行するなど、強力な機能でインシデント対応を効率化し、エンジニアの負荷とストレスを軽減させます。オンコール対応のベストプラクティスを実践する上でも最適なサービスです。適切なインシデント対応の方法やPagerDutyの導入効果にご興味のある方は、LINE社のPagerDuty活用事例を基にした、こちらの記事「インシデント対応とは？事例から読み解く対策方法」もぜひ参考にしてください。
この記事が気になったら
PageDuty公式アカウントをフォロー
この記事の著者
関連ブログ記事
人気記事
検索
タグ目次
