障害対応を属人化させない。「全員インシデントコマンダー」体制を根付かせた、山本五十六の格言【NewsPicks SRE 安藤裕紀】

障害対応は、率先して動くエンジニアに負担が偏ってしまいがち。そうしたメンバーの負担が次第に大きくなっていき、他のメンバーのスキルは上がらない…。そんな課題に対して、全員が「インシデントコマンダー」として動ける組織を目指して動き出したのが、ユーザベース NewsPicks事業のSREチームリーダー、安藤裕紀さんです。

「障害対応はつらいしやりたくない」と感じるメンバーも少なくない中で、「全員インシデントコマンダー」の体制をどうつくり、どのように受け入れてもらったのか？　そう聞くと安藤さんは「私がやってきたことを振り返ると、山本五十六の言葉に近いのかなと思います。あの有名な、“やってみせ、言って聞かせて、させてみせ…”という」と語ります。具体的にどう進めてきたのか、詳しく聞きました。

• keyboard_arrow_down 少人数での障害対応はもう限界。「全員インシデントコマンダー体制」の構築を決意
• keyboard_arrow_down 仕組みづくりは「やってみせ、言って聞かせて、させてみせ…」のステップで
• keyboard_arrow_down 難所は「障害対応のスピードとの両立」地道な意識づけこそが肝要

――「全員インシデントコマンダー」の体制をつくろうと思ったきっかけを教えてください。まず、安藤さんが入社した当時、「障害対応」においてはどんな課題がありましたか？

安藤：私が入社した2021年当時、NewsPicksのプロダクト開発組織では、障害対応を「運用当番」として行っていました。エンジニア約70名で24時間365日のプライマリーオンコールのシフトを組んで回していたんです。

ただ、運用当番の役割は明文化されておらず、障害発生時の対応もフワッとしていました。

障害が発生すると、運用当番には電話やSlackで連絡が入ります。しかし人によっては、運用当番としてどこまで手を出していいかわからず、障害発生箇所のシステムを担当している開発チームに連絡するだけで対応を終了してしまったり、はたまた、運用当番へのSlackのメンションを見た他の人が先に問題を解決してしまったり…。障害対応のために主体的に動けていたのは数人で、その人たちに負担が偏ってしまっていたんです。

このような「障害対応を限られた数人でなんとかする状態」は、2年ほど続きました。それでも回っていたからです。しかし2023年頃から、開発者体験や開発生産性の改善に伴ってデプロイ頻度が月200回以上に増え、それに比例して障害発生件数が増えていました。

障害対応が属人化している中で、障害の数が増えてしまっていよいよ回らなくなり、これは早急にどうにかしなくてはと考えるようになったのです。

――この課題の解決方法として、なぜ「全員インシデントコマンダー」の体制をつくろうと考えたのでしょうか。

安藤：障害対応について学ぶ中で「インシデントコマンダー」という役割と出会い、これはまさに今自分がやっていることだ！と感じたからです。

安藤：私は入社当初から「新入りなのだからこそ、何か価値を発揮しなくては」と、障害発生時に主体的に動くようにしていました。障害の調査をするとシステムの勉強にもなるし、解決したら感謝もされて嬉しい。これをやる人を増やしていけたらいいな、と新参者ながら感じていました。この動きを組織全体に広められないかと調べていた時、「インシデントコマンダー」という役割を知ったのです。

「インシデントコマンダー」とは、障害発生時の対応を「指揮官」として主導する役割です。障害対応のための意思決定を一手に担い、関係各所とのコミュニケーションをとりながら情報を整理し指示を出すことで、障害を解決に導きます。これはまさに、障害発生時に私が行っていたことでした。

また、インシデントコマンダーを務める際に、深い技術理解やドメイン理解は必須ではないとされています。思い返せば、入社したばかりの私でも、障害対応の旗振りはできていた。それならば、仕組み化すれば誰でもできるようになるだろうと考えたんです。

――具体的に、どのように仕組みづくりをしていったのですか？

安藤：「やってみせ 言って聞かせて させてみて 誉めてやらねば 人は動かじ」という有名な言葉があります。かつて太平洋戦争で日本軍の連合艦隊司令長官だった山本五十六が残した言葉で、人を動かす真髄が詰まっていると言われています。私がこれまで、インシデントコマンダーの仕組みづくりのためにやってきたことを改めて整理すると、まさにこの言葉のステップを踏んでいました。

インシデントコマンダーの役割は障害を解決に導く指揮を執ることで、ログ調査やコードリーディングをしてほしいわけではない。いわば「動き方」ですから、まずは実際に、私がインシデントコマンダーとして動いているところを見せる必要があると考えました。

――なるほど。ではまず「やってみせ」たということでしょうか。

安藤：そうです。しかし、インシデントコマンダーとしての動きをただ「やってみせ」るだけで伝えようとしても、見る人にとってのキャッチアップコストが高く、今までと状況は変わらないでしょう。キャッチアップコストを抑えながら、私がやっていることを伝えていくために、まずはインシデントコマンダーがやるべきことや、全体の流れをまとめたドキュメントをつくりました。

具体的な流れとしては、問題が起きたらまず関連チームのエンジニアをGatherの障害対応スペースに集め、音声で同期的にコミュニケーションをとります。並行して、Slackに障害対応スレッドを立て、ビジネスサイドを含む関係者をメンションし、対応の進捗や調査状況、コミュニケーションの中で得られた情報をまとめてテキストで流します。意思決定が必要であれば自ら行い、指示を出す。障害対応が完了したら、ポストモーテムの開催判断をして、必要であれば会議を設定してクロージング。

こうした内容をドキュメントにまとめ、オンコールシフトに入った人に読んでおいてもらうために、障害発生時のSlack通知に表示させました。また、障害対応の緊張の中でも手軽に参照してもらえるよう、「障害対応」のSlack絵文字スタンプを押せば、ドキュメントのURLが自動応答されるようにもしておきました。

こうして「インシデントコマンダーの動き方」をドキュメントで網羅的に示した上で、実際の障害対応時に「やってみせ」たのです。

――まずは型を明示化し、さらに「やってみせ」たのですね。次は「言って聞かせて」でしょうか。

安藤：はい。何度か実際の障害の際に型を再現して動きを見せた後、開発組織全体の月次ミーティングで、改めて口頭で説明し、「全員がインシデントコマンダーとして動けるようになろう」と呼びかけました。これが、今からちょうど半年ほど前のことでしたね。

この段階では、すぐに全員が「できる」とは思わないにしても、「これならできそう」だと思ってくれる人が少しでもいればいいなという感覚でした。というのも、インシデントコマンダーを初めてやる人にとっては、ハードルが高く感じることが大きく2つあるからです。

1つ目は、指揮官として障害対応の中心に立つこと。「このエラーが出ているからこのチームとコミュニケーションを取るべき」と判断して関係者に声をかけ、自分から障害や対策状況を集めにいって整理してSlackに流す。スピード感が求められる緊迫した状況の中、口頭とテキスト、両方のコミュニケーションを同時に進めていかなくてはなりません。こうしたハードな状況を初めて経験することになるのですから、尻込みするのも当然です。

2つ目は、インシデントコマンダーとして、チーム横断でオーナーシップを発揮すること。NewsPicksのプロダクト開発組織には、10以上の開発チームがあり、ビジネスサイドも含めたらもっとたくさんのチームがプロダクトに関わっています。在籍期間の長いメンバーであれば、他チームに対する働きかけや連絡もしやすいですが、参画してから日が浅いメンバーが自主的に他チームを巻き込んでいくのは、なかなか難しいでしょう。

これらのハードルがある中で「やってくださいね」と言われて、素直に「はい、やれます！」と思える人はそう多くないはず。だからまずは「簡単ではないけれど、入社したばかりの僕でもできたから、みんなが思っているほど難しくはないよ」と伝え、「自分ももしかしたらできるかも」と自己効力感につながるきっかけをつくれたら、と考えていました。

――この時点ではまだ、高い主体性を求めてはいなかったのですね。次は実際に「させてみて」の段階ですか？

安藤：そうですね。ミーティングで呼びかけた後、ありがたいことに、何人かのメンバーが自発的にやってみてくれました。ユーザーが困っている状況を解決したいのに、何をすればいいかわからず動けなかったメンバーたちに一定の型を示したことで、「じゃあその通りにやってみるか」と思ってくれたようです。

そうして、一度自分でやってみるというハードルを越えたメンバーが数人現れると、「じゃあ自分もやってみよう」と連鎖的に人が増えていき、いい流れが生まれました。次第に、一度やってみたメンバーが「システムをすべて把握していなくてもできました」「すごく勉強になるのでおすすめです」といった投稿をSlackに流してくれて、流れが一気に加速しました。

安藤：実際にやってもらうと、メンバーがつまずきやすい部分も見えてきました。

例えば「関係者を集める」という最初のステップに踏み出そうとしても、誰がこの障害の関係者なのかわからなくて戸惑ってしまう場合がありました。そこで、システムごとにどの開発チームが開発を担当していて、どの事業部が関わっているのかをまとめた資料を作成し、これも、オンコールシフトに入ったときのSlack通知と一緒に表示されるようにしておきました。するとメンバーも、障害発生の通知を見てから資料を参照し、誰を呼ぶべきかをざっくりと判断できるようになりました。

また、障害対応が目まぐるしく進んでいく中では、次のステップを見失ってしまうときもあります。そのため、インシデントコマンダーを中心とした障害対応の流れをフロー図でまとめました。慣れないメンバーもそれを見て「今ここまでやった」「次はこれだ」と、ネクストアクションを自分で定められるようになっていってくれました。

今後は障害の影響を判断できるようなシステム構成図もつくりたいですね。型やドキュメントはだいぶ整備しましたが、随時アップデートを続けています。

――最後の「誉めてやらねば」は、どのように実践していますか？

安藤：メンバー同士の称賛によって、インシデントコマンダーをやるためのモチベーションを育てられるのではないかと考え、まずは障害対応アクティビティのわかりやすい可視化と称賛から始めています。

最近やり始めたのが、インシデントコマンダーを務めた人、その声に反応して手助けした人、実際の障害対応に携わった人などをレポート化して、Slackでお礼を流すこと。全員に見えるところで成果を可視化することで、メンバーからの称賛も集まります。これにより、障害対応に関わった人に「また頑張ろう」と思ってもらえているようです。今は私が人力でやっているのですが、今後自動化したいと考えています。

また、一時はモチベーションアップのために、インシデントコマンダーとして主体的に動くことを人事評価に組み込めないかとも考えました。実際、障害を解決に導くことは、エンジニアの評価基準であるコンピテンシークライテリアの1つにもなっています。ただ、障害対応の場合、打席に立つ回数は人によってバラバラなので、対応回数と評価を直結させるのはフェアじゃない。この結びつけが望ましくないのであれば、今のようにメンバー同士やチーム内で支え合いながら、インシデントコマンダーの存在意義や障害対応の重要性を呼びかけ続けるのが、実は一番の近道かもしれないと考えています。

――半年ほど前にメンバーへの呼びかけを始めたとのことでしたが、ここまでの手応えはいかがですか。

安藤：ここ2～3カ月の間でようやく、成果が出始めているように思います。一定の型をつくってドキュメント化し、呼びかけただけにしては、うまく進んでいる気がしますね。

安藤：もちろん、全員が完璧にこなせているわけではありません。私がやるべきサポートにも、まだまだ改善の余地はあります。いくらドキュメントを用意していても、事前にそれらをくまなく読んでおくのは難しいでしょう。いざインシデントコマンダーをやることになってから読み始めても、その間に他のエンジニアが障害を解決して、機会を逃してしまうこともあります。

――インシデントコマンダーとしての経験を積んでもらうことと、障害対応を素早くやりきることの両立は、どのように捉えていますか？

安藤：インシデントコマンダーをやってみる機会が失われるのは確かに損失です。でも、ユーザーのことを考えれば、そもそも障害はできるだけ早く解決するべき。他の人が手を出してはいけないというルールはないし、早く解決できるのであれば、むしろ手を出せる人が率先して対応した方がいいでしょう。その積極性は評価されるべきものですしね。

ただやっぱり、どうしてもいつも同じ人が対応するようになり、偏りは出てしまいます。こうして偏り続けた結果が、私が入社した当初の状態だったわけです。この偏りに甘んじていたらすぐに、後戻りしてしまうでしょう。

そうならないよう、最近は状況が許せば、「運用当番の○○さん、インシデントコマンダーお願いします」と指示を出して、経験を積んでもらうようにしています。そうやって地道に「誰もがインシデントコマンダーになりうる」という意識を醸成していくしかないかなと思っています。

――通常の開発も忙しい中、インシデントコマンダーを持ち回りでやることに躊躇するチームはないのでしょうか。

安藤：確かに、インシデントコマンダーとして対応するメンバーは、多くのリソースをそれに割くことになります。特に忙しいタイミングでは、他のチームメンバーが大変な思いをしているときもあるでしょう。

とはいえ、「障害対応はやるしかないものだ」という意識はチームリーダーなら強く持っているし、メンバーも受け入れていると思います。誰かが障害に対応しなければ、プロダクト自体の価値が下がり、やがては売り上げや自身の報酬にも関わってきますから。

それに、捉え方を変えれば、障害の発生はプロダクトの改善点が見つかるきっかけにもなります。さらにその際インシデントコマンダーとして動くことは、コミュニケーションや情報整理のスキルアップや、普段触らない部分のシステムの仕組みを知るチャンスとも捉えられます。

――誰でもインシデントコマンダーができるような仕組みづくりは、負荷を分散するだけでなく、プロダクトの改善やメンバーの育成にも効果があるのですね。

安藤：私はそう思っています。今後さらに社内にインシデントコマンダー文化が浸透すれば、今よりもプロダクト改善のきっかけが生まれやすくなり、開発のモチベーションも向上するだろうと考えています。そう信じて、私自身も障害対応に全力であたりながら、メンバーのサポートをしていきたいですね。

取材・執筆：古屋 江美子
構成・編集：光松 瞳
撮影：赤松 洋太