「運用エンジニアは“燃え尽き予備軍”をやめるべし」 PagerDuty会長が語るインシデント対応“進化論”：システム障害時に本当に守るべきものは何か

ひとたび起きたシステム障害で信頼を失墜し、さらには復旧後にも残る影響で多大な損失を招きかねない時代だ。AIによる自動化も広がる今、運用プロセスやエンジニアはどうあるべきか。インシデント管理ツールベンダーPagerDutyのジェニファー・テハダ会長（前CEO）は、エンジニアの燃え尽き症候群を生む体制から脱却し、全員が「ビルダー」になるべきだと語る。その真意とは。

[遠藤文康，＠IT]

　ITシステムの運用管理は、コストを抑えながらいかにサーバを止めないかという「守り」の視点に重きが置かれることがある。だが、ビジネスプロセスがシステムに強く依存している今、そしてAIによってさまざまなプロセス自動化・自律化が現実のものとなっている今、その前提は根本から変わりつつある。

　「10年前、企業のCEOがインシデントを気にすることはほとんどなかった」。そう語るのは、インシデント管理ツールを提供するPagerDutyの取締役会会長（取材当時は会長兼CEO）、ジェニファー・テハダ氏だ。同氏が2016年に同社CEOに就任した当時、ビジネス全体を止めるようなシステム障害が目立って発生することはなかったが、デジタル化によってさまざまな業務やビジネスがシステムやデジタルサービスに依存するようになり、社会に大きな影響を与えるシステム障害が相次いでいる。

PagerDutyの取締役会会長、ジェニファー・テハダ氏（インタビュー当時は会長兼CEO。2026年5月11日＜米国時間＞に取締役会会長に就任）

　ビジネスに与える被害は、その瞬間の売り上げ減少や復旧コストにとどまらない。真に恐ろしいのは、一度の失望をきっかけに顧客が競合へと乗り換え、二度と戻ってこない『信頼の喪失』というロングテールな損失だとテハダ氏は指摘する。エンジニアの燃え尽き症候群（バーンアウト）も無視できない。現場の疲弊や優秀な人材の離職は、イノベーションの停滞やレジリエンス（回復力）の低下を招く深刻な問題になり得るからだ。

　ましてやAIが各種運用プロセスを自動化できる今、「限られたコストの中でシステムを維持する」だけの運用は、もはや価値を失っていく。「これからは全員がビルダー（作り手）になるべきだ」とテハダ氏は強調する。では、具体的にAIはシステム運用やインシデントにどう影響するのか。その中で運用エンジニアは“作り手”としてどうあるべきなのか。同氏に話を聞いた。

システム停止で生じる3つの隠れたコスト

　システムが停止した際、まず直面するのはダウンタイムによる直接的な損失だ。顧客との接点であるフロントエンドや商取引のバックボーンが止まれば、わずか数秒の停滞が多大な機会損失に直結する。場合によっては規制当局からの厳しい罰金の対象となることもある。こうした直接的なコストだけでも、その規模は往々にして莫大（ばくだい）なものとなる。

　ただしテハダ氏は「これらは見積もることのできるコストだが、それだけでは不十分だ」と断じる。インシデントの真のコストは、むしろ復旧した「後」に、より高い代償として現れることがある。まずは同氏が指摘したコストとして次の3つのポイントを念頭に置いておきたい。

1．顧客心理に刻まれる「ロングテールの影響」

　直接的な影響を測定しにくいが重大な問題の一つが「顧客の離反」だ。「1回だけの失敗なら、顧客は『たまたま運が悪かった』と許してくれるかもしれない。だが2回、3回と繰り返されれば、彼らは冷静にビジネス上の決断を下し始め、他のブランドへ乗り換えれば二度と戻ってこなくなる」（テハダ氏）。そのため、重大なインシデント後の中長期的な顧客への影響は、ダウンタイム中に生じた直接的なコストよりもはるかに高いものとして捉えなければならない。

　特に、一度の操作ミスや遅延が致命的な体験につながる金融やEC（eコマース）などの分野では、システム障害は単なる不便ではなく、ブランド価値そのものの崩壊を意味する。一部の国では、ダウンタイム中に消費者が企業に対して補償を請求できる「消費者保護プログラム」も強化されており、法的な賠償リスクも高まっている。

2．ビジネスをむしばむ「後処理」コスト

　システムが復旧した後も高額な後処理が続くこともある。「例えばシステム障害によって搭乗券の発行や航空券の購入が妨げられれば、その瞬間の損失だけでなく、その後の払い戻し対応、再予約のためのオペレーション、さらには顧客満足度を回復させるための投資が必要になる」

　インシデントそのものよりも、その「後片付け」にかかるコストやリソースの方が、はるかに肥大化するケースも少なくない。

3．「バーンアウト」（燃え尽き症候群）のエンジニア

　現場を支える「エンジニアへの影響」も考慮しなければならない。インシデント対応のために深夜や勤務時間外の対応を強いられることは、身体的・精神的な負荷を蓄積させる。テハダ氏は、燃え尽き症候群はエンジニアにとっての真のコストだと指摘する。

　「絶えず障害対応に追われることで、エンジニアは本来取り組みたかった有意義なプロジェクトを完遂できなくなる。これが続けばバーンアウトを招き、優秀な人材の離職につながる」

インシデント発生時に本当に守るべきもの

　事業およびシステムのレジリエンスについてはCEOやCFOといった経営層が意識していることはもちろんだが、今変わりつつあるのは、「システムとビジネスの成果は密接に結びついているという認識が、従業員レベルでも広がっている」（テハダ氏）ことだ。大規模な障害が発生していることが市場からも見えるようになれば、ビジネスに悪影響が生じ得るということが当然のように理解されるようになる。

　「何が起きているのか分からない状態が長引くと、顧客はその空白を自分たちの想像で埋めてしまう。そしてそれは往々にしてネガティブなものになる」。解決に向けてどのような対応を進め、いつ復旧する見込みなのかを簡潔かつ明確に伝えること。テハダ氏は「透明性は信頼の失墜を抑止する上で非常に大きな効果がある」とする。情報を適切に伝えること自体が、人と人の信頼関係を構築する上で重要だからだ。

インシデント対応中の報告書作成

　しかし、現場のエンジニアにとって、刻一刻と状況が変わる緊急事態の中、外部向けの報告書を作成することは極めて重い負担になる。こうした現場で発生している負荷を軽減して本来の目的を達することに迅速に近づけるようにするのが、AIの使いどころの一つだろう。AIがリアルタイムで会議の文字起こしやチャットログを解析し、状況報告のドラフトを自動生成する、というのはインシデントの現場でこそ生きてくる使い方だ。

　例えばPagerDutyの『Scribeエージェント』は、過去の履歴や現在の対応状況を学習し、経営層や顧客向けにそのまま提示できるレベルのステータスアップデートを自動生成する。「従来、担当者はインシデント対応を一度止め、30分から1時間かけて声明文を作成する必要があったが、その作業をわずか1〜2分にまで圧縮される」

SREにおけるAIの活用

　テハダ氏はAIをSREの領域に取り込んでいく上では、まずは人のガイダンスや許可の下でタスクを実行するアシスタント型、支援型のエージェントが出発点として重要だとする。「PagerDutyの『SREエージェント』の初期のバージョンも、まずは『次に取るべきステップはこれだと思います。実行しますか』といったように確認を求める」。こうした手続きを踏むことで人間はAIエージェントの行動を追跡できるし、特にまだ不慣れな従業員などはその手順から学ぶこともできる。

　他の業務プロセスにおけるAIと同じように、AIに対して安心感や信頼感を抱くようになれば、判断やより多くの作業をAIに任せるようになるだろう。実際、「多くのユーザーはエージェントによる作業代行を歓迎している」とテハダ氏は話す。インシデント対応は本来の仕事の流れを妨げるものだからだ。

「NoOps」は現実を言い表していない：運用の消滅ではなく、責任の分散

　こうしてインシデント対応の領域にもAIが深く入り込んでくる段階になると、AIによる自動化が進む中で過去にも話題になった「NoOps」という言葉が再び現実味を帯び始めている。しかし、テハダ氏はこの言葉の捉え方に釘を刺す。

　「NoOpsという言葉から連想されるのは『運用担当者がいなくなる』とか『運用部門が不要になる』といったイメージだが、実際に起きていることは違う」。実際に起きているのは、中央集権的かつ手作業で行われていた運用を、自動化しながら分散させていく流れ。「責任は上流へ、シフトレフトしている。つまり開発者自身が、自分たちがデプロイしたコードに責任を持つということだ」

　開発者がコードを書き、運用チームがその維持を担うという分業が一般的だった時代よりも、コードの品質を高めることへのインセンティブがより強く働くようようになる。「結果として、運用チームがダッシュボードを眺めながら手動で問題をエスカレーションするようなモデルから脱却し、その製品をよく理解している人へ責任を分散していけるようになる」

　「これは、健康管理を医者に任せ切りにするのではなく、日々の生活習慣を整えて病気そのものを防ぐプロセスに似ている」とテハダ氏は例える。

責任の分散が「チームの健康」を守る

　責任の分散は、エンジニアを深刻な「バーンアウト」から守る防波堤の役割を果たすだろう。一部の優秀なエンジニアや特定の運用チームにインシデント対応が集中すれば、その人は疲弊し切ってしまう。

　現在では過去の類似イベントの知識も踏まえたAIエージェントの機能を活用することも可能だ。初動や報告業務の責任を分散させ、また問題に応じて適切な担当者へ自動で責任を振り分け、属人性を排除することは、誰もがより健康な状態でシステムに向き合うことにつながるはずだ。

　こうして属人性や個人の「自己犠牲」から脱却すると同時に、開発の品質そのものを高めるサイクルを回していく。これこそが、AIエージェントをレジリエンスに取り込んでいくことの本質と言えるだろう。

全員が「ビルダー」として価値を創る時代へ

　「これからは全員が自分自身を『ビルダー』だと捉える必要がある」とテハダ氏は語る。AIの進化によってコーディングの障壁は下がり、誰もがアイデアを形にできる手段を持つ時代になった。

　要は何かを構想したり、プロトタイプを作ったり、顧客向けの製品やサービスをより良く提供する方法を考えたりすることを踏みとどまらせる障壁は取り払われたということだ。

　「これからより重要になるのは、コーディング能力よりも、会社のミッションを理解し、主体性を持って『もっと良いサービスにするにはどうすればいいか』を考え続ける力だ」という。

　運用エンジニアにも「もっと良いやり方はないか」を常に考える存在であってほしいとテハダ氏は話す。「PagerDutyをもっと有効活用する方法はないか、運用をさらに自動化できないか、システムヘルスをもっと分かりやすく可視化できないか――そうした改善の余地を探し続けてほしい」

---

　こうして「運用の民主化」が進む中で、論点になり得るのが外部の運用ベンダーへの依存と「内製化」のバランスだ。社内の負荷を減らすためにアウトソーシングされてきた一面もあった運用に対して、テハダ氏は「運用そのものが企業のコアコンピタンス（中核能力）であるという認識が強まっている」と指摘する。

　今回の話の中でも、システム運用が収益に直結する存在だという認識が広がってきたという動きに触れたが、それを前提にしても、過度な負荷集中は避けながらも、より迅速に状況を把握し、問題を解決する体制を構築する重要性は高まっている。それは必ずしも外部の運用ベンダーとの決別を意味するわけではなく、外部の運用ベンダー側でもより高付加価値なパートナーへと変革するチャンスでもある。

　最後に、テハダ氏は「私たちは運用チームのことを『サイレント・ヒーロー（静かなる英雄）』と呼んでいる」とした点に触れておきたい。「その仕事は単なる維持管理ではなく、商取引のバリューチェーン全体の流れをスムーズにし、最大限の収益を取り込むための、極めて戦略的な活動だ」