「全員インシデント コマンダー」の、その先へ 〜 全員障害対応の文化をつくる NewsPicks流Failure Fridayのご紹介

「全員インシデントコマンダー」 の、その先へ 〜 全員障害対応の文化をつくる NewsPicks流Failure Fridayのご紹介 株式会社ユーザベース 執行役員 NewsPicks CTO 安藤裕紀 2026.9.29 PagerDuty Tech Hub 2026 COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 1

自己紹介 安藤 裕紀 / Yuki Ando 株式会社ユーザベース 執行役員 NewsPicks CTO 2011年新卒で野村総合研究所に入社。10年以上エンジニア/アーキテクトとしてアプリ ケーション開発/インフラ構築/クラウド活用コンサルティングなど大企業の技術支援を 行った後、2021年10月に株式会社ユーザベースに入社。 以来プロダクト開発組織のSREチームでインフラや開発基盤を担当。 シニアエンジニア、チームリーダー、シニアEMを経て、 2025年1月から執行役員NewsPicks CTOに就任。 @integrated1453 10歳・5歳・0歳の三児の父として、ちょっと疲れたお父さん（CTO）でもある Incident Response Meetupという障害対応のコミュニティを運営しています。 次回は11月下旬に開催予定！ COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 2

ユーザー‧会員数 国内最⼤級の 経済ニュース プラットフォーム 1200 13 突破 万⼈ サービス開始より 年 ※2026年9月30日現在 COPYRIGHT© 2026 Uzabase, Inc. ALL RIGHTS RESERVED. 3

01 「全員インシデントコマンダー」導入の経緯 COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 4

NewsPicksの障害対応体制は「全員プライマリオンコール」 約60名でチームに関係なくNewsPicksサービス全体のプライマリオンコールを24x7で交代 ユーザーからは「どのチームのエンジニアが対応するかは関係ない、一つのアプリの障害」 ● モバイル1名、サーバー2名の3人一組がPagerDutyのオンコールシフトに入る3.5日交代制 ● 2ヶ月に1回程度、「運用当番」としてオンコール担当・プロダクトへの問い合わせ担当になる NewsPicksプロダクト開発エンジニア (10チーム約60名) XXX事業 開発チーム YYY事業 開発チーム ZZZ事業 開発チーム 横断技術チーム Platformチーム SREチーム モバイルチーム 検索/推薦チーム COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 5

入社当時の障害対応の流れ 運用当番がアラートを受けて、暫定復旧まで「よしなに」対応するフローだった システムのアラート Bugsnag → PagerDuty New Relic / CloudWatch ? 障害撲滅委員会 開催 （ポストモーテム） 運用当番（オンコール担当） が一次切り分け・ 担当チームアサイン・ ビジネスサイドからの 緊急呼び出し Slack → PagerDuty 暫定復旧作業 担当チームで開発の バックログとして対応 COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 6

「全員インシデントコマンダー」導入の経緯 ● 運用当番の役割は一次切り分けとされていたが、障害発生時の動き方はフワッとしていた ● 障害が起きると、運用当番に電話やSlackで連絡が入る ● しかし、どこまで手を出していいかわからず、担当チームに連絡して終わる人もいた ● 運用当番へのメンションを見た別の人が、先に解決してしまい関係者に報告まですることもあった ● 主体的に動けていたのはいつも固定の数人で、その人たちに負担が偏っていた ● それでも回っていたので、限られたメンバーでなんとかする状態が2年ほど続いた(私も100本ノックした) ● 2023年頃、開発者体験・開発生産性の改善でデプロイ頻度が月200回以上まで増えた(現在はAIで更に加速) ● NewsPicksのコンテンツが記事から動画にシフトするなどワークロード・運用の変化もあった ● 属人化したまま障害が増え、いよいよ回らなくなった COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 7

インシデントコマンダーとの出会い 書籍『サイトリライアビリティワークブック』に登場する Googleも採用するインシデントコマンドシステムを参考にする インシデントコマンドシステム における3Cs Coordinate インシデントコマンダーは ● 対応作業の調整(Coordinate) 3Csの調整に集中する ● インシデント対応者間、組織内、外界との Incident Commander(IC) コミュニケーション(Communicate) ● インシデント対応に対するコントロール Communicate Control (Control)の保持 Communication Lead(CL) Ops Lead(OL) インシデントコマンドシステムは山火事を管理する方法として1968年に消防士によって確立されたフレームワーク https://en.wikipedia.org/wiki/Incident_Command_System COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 8

• https://en.wikipedia.org/wiki/Incident_Command_System

「全員インシデントコマンダー」を仕組み化すれば、誰でもできると考えた ● 入社当初、新入りだからこそ価値を発揮しようと、障害発生時に主体的に動いていた ● 障害の調査は自分が知らないシステムの勉強になり、解決すると感謝もされて嬉しかった ● これをやる人を組織に増やしたいと調べる中で、「インシデントコマンダー」を知った ● 障害対応を指揮官として主導し、情報を整理して、意思決定を担い解決に導く役割 ● インシデントコマンダーには、深い技術理解やドメイン知識は必須ではないとされている ● 思い返せば、入社したばかりの自分でも障害対応の旗振りはできていた まさに、自分が障害発生時にやっていたことだった ● それならば、仕組み化すれば誰でもできるようになると考えた ● 必要なのは、ログ調査や復旧作業ではなく、障害を解決に導く「動き方」だった COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 9

やってきたこと（1）動き方をドキュメントにまとめた ● まず、インシデントコマンダーがやるべきことと全体の流れをドキュメントにまとめた ● 問題が起きたら、関連チームのエンジニアをGatherの障害対応スペースに集め、通話でやりとりすること ● 並行してSlackに障害対応スレッドを立て、ビジネスサイドを含む関係者をメンションし状況共有すること ● 進捗や調査状況、会話で得た情報をまとめてテキストで流し、必要な意思決定は自ら行うこと ● 対応が完了したら、ポストモーテムの開催を判断してクロージングすること COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 10

やってきたこと（2）すぐ見られるようにした ● オンコールに入った人に読んでもらえるよう、シフトイン時のSlack自動通知にドキュメントを表示した ● 緊張の中でも手軽に参照できるよう、「障害対応」絵文字を押すとURLが自動で返るようにした COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 11

やってきたこと（3）全体に呼びかけた ● 何度か実際の障害時に現場で型を見せた後、プロダクト開発組織全体の月例会でも発表した ● なぜ障害対応が重要なのかを説明し「全員インシデントコマンダー」をやろうと呼びかけた ● すぐ全員ができるとは思わず、「これならできるかも」と思う人が少しでもいればいいと考えていた ● 「入社したばかりの自分でもできた。思っているほど難しくない。インターン生にもできる！」と伝えた https://response.pagerduty.co.jp/training/incident_commander/ COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 12

• https://response.pagerduty.co.jp/training/incident_commander/

やってきたこと（4）自発的な挑戦から、連鎖が生まれた ● 呼びかけの後、何人かのメンバーが自発的にやってみてくれた ● 型を示したことで、「じゃあその通りにやってみるか」と思ってもらえた ● 一度ハードルを越えた人が現れると、連鎖的にやる人が増えていった ● 「システムを全部把握していなくてもできた」「学びが多い」という投稿が流れ、一気に加速した COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 13

そうは言ってもハードルは高く、シニアなメンバーが中心だった インシデントコマンダーを初めてやる人にとって大きな2つのハードル 指揮官として障害対応の中心に立つこと チーム横断でオーナーシップを発揮すること ● 「このエラーが出ているからこのチームと コミュニケーションを取るべき」と判断して 関係者に声をかけ、自分から障害や対策状況 を集めにいって状況を整理してSlackに流す ● スピード感が求められる緊迫した状況の 中、口頭とテキスト、両方のコミュニケー ションを同時に進めていく必要がある ● NewsPicksのプロダクト開発組織には、10 以上の開発チームがあり、ビジネスサイドも 含めたらさらに多くのチームがプロダクトに 関わっている ● 在籍期間の長いメンバーであれば、他チー ムに対する働きかけや連絡もしやすいが、参 画してから日が浅いメンバーが自主的に他 チームを巻き込んでいくのはなかなか難しい COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 14

やってきたこと（5）つまずきを拾って、仕組みを足した ● 実際にやってもらうと、つまずきやすいところが見えてきた ● 誰が関係者かわからず、最初の「関係者を集める」で戸惑うケースがあった ● そこで、システムごとの担当チームと関係事業部の一覧を作り、メンションされると同時に表示した 例えば「ニュース記事入稿・配信」の システムで問題が発生し、広告事業の 顧客に影響が発生した場合、インシデ Aチーム ニュース記事入稿・配信 個人課金事業 障害発生箇所 ントコマンダーは作業担当にAチーム Bチーム 法人管理機能 法人事業 を、コミュニケーション担当にCチー Cチーム 広告管理・配信機能 広告事業 ムのメンバーをアサインして対応作業 影響する事業部門 を調整することになる システムの運用と事業部の対応表のイメージ チーム 運用担当システム 担当事業部門 COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 15

やってきたこと（6）AIで障害状況の要約を効率化した ● 特定の絵文字メンションで障害の状況やポストモーテムに記録する内容を障害対応スレッドから要約 ● チャットの対応記録から議事録に文書化する手間を省き、ポストモーテム開催のハードルを下げる ● ユーザー影響の有無など、ポストモーテムの実施基準が要約時にリマインドされ、開催判断が明確化した COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 16

やってきたこと（7）インシデントコマンダーを称賛しまくった ● インシデントコマンダー、手助けした人、対応に携わった人を称賛するべく、Slackで地道にお礼を流した ● 全員に見える場所で成果を褒めちぎり、メンバーからの称賛スタンプも集まるようにした COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 17

やってきたこと（8）属人化に後戻りしないために、言い続ける ● 対応に慣れた他の人が率先して解決して、インシデントコマンダーをやる機会を逃すこともある ● ユーザーのことを考えれば、障害は早く解決すべきなので、手を出せる人がすぐに対応するのは良いこと ● 状況が許せばなるべく「運用当番の○○さん、インシデントコマンダーをお願いします」と指名している ● 手挙げで「インシデントコマンダーやります」の宣言も増えている。新卒2年目メンバーからも！ ● 障害の発生はプロダクトの改善点が見つかるきっかけにもなり、インシデントコマンダーとして動くことは コミュニケーションや情報整理のスキルアップや、普段触らない部分のシステムの仕組みを知る機会になる CTOが心血注いでインシデントコマンダー 言い続けてみんなで回す文化を作ってます 文化は一日にしてならず COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 18

02 「全員インシデントコマンダー」の、その先へ COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 19

「全員インシデントコマンダー」の普及後も残った課題 仕組み化できたこと 仕組み化の対象外に残ったもの 障害対応の指揮を執る（3Csの調整） ログ確認・動作確認 関係者を集め、状況を整理し周知する 影響調査・データ確認 根本対策の要否判断とポストモーテム開催 暫定対策の判断と実行 インシデントコマンダーの仕事ではないから、 詳しい担当チームをアサインすればいいのでは？ COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 20

「システムを知らなくてもできる」は半分は本当で、半分は嘘。難しい インシデントコマンダーとして情報を整理して、意思決定を担い、解決に導くためには 「このチームが関係するのでは」「こういう影響が起きているのではないか」「これで直る かもしれない」と推論しながら仮説検証の判断を繰り返す必要がある 書籍『サイトリライアビリティエンジニアリング』より ❝形式的には、トラブルシューティングのプロセスは、❞ 仮説演繹法の応用と考えることができます。 システムに関する一連の観察結果と、システムの挙動を把握する 理論的な基盤を基に、障害の原因についての仮説を立て、 その仮説を検証するというプロセスを繰り返します。 COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 21

実践的な仮説検証の繰り返しには、一定のシステム知識が必要 インシデントコマンダーとして仮説形成・仮説検証を高速に行い、障害を解決に導くには、 「ログ調査や復旧作業」は任せるとしても障害の要素や復旧パターンは知っておくと良い トラブルシューティングのプロセス(SRE本より) 問題の報告 回復 ● トリアージ ● 検証 ● 診断 ● テスト／対処 トリアージ：どこで問題が発生しているかを特定する ○ スマホアプリ・Web・バックエンド・DB・データ基盤 まで一気通貫で切り分け、特定していくやり方を覚える 検証：コンポーネントの動作を検証する ○ 広告や検索バックエンドなど、普段の開発チームでは触 らないシステムの箇所の動作検証の方法を覚える 診断：正常に動作しているかを判断する ○ ユーザー視点でQA方法・動作確認手段について、 担当チームに依頼しなくてもできるようになる テスト／対処：可能性が高い順番に、復旧作業を実行する ○ 実際の復旧作業は担当チームに任せるが、 ○ ワークアラウンドのパターンを覚えることで 暫定復旧策を立案できるようになる 「前も似たようなことがあったな」「あの時のやり方で 直るかも」「あの時の調査方法で原因わかるかも」は、 かなり重要・・・！ COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 22

Failure Friday という「障害対応のシャドーイング会」を開催している ● 「前も似たようなことがあったな」「あの時のやり方で直るかも」は障害対応の仮説形成推論に超重要 ● にも関わらず、障害対応に居合わせたメンバーにしか復旧手順の詳細、調査方法の詳細が共有されない ● 障害対応に駆けつけてくれたジュニアメンバーも、シニアの対応を落ち着いてキャッチアップできない ● 復旧作業手順を追いかけて復習し、仕組みを理解することを主眼にした勉強会としてCTO自ら立ち上げた COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 23

Failure Friday のオリジナルはPagerDutyだが、内容は異なる 共通点は、失敗を学習の機会として扱い、実際の障害の緊張感がない場で練習すること 本家のFailure Fridayはカオスエンジニアリング的でハードルが高いため自己流にアレンジ 観点 PagerDutyのFailure Friday 10年以上続く実践 NewsPicks流のFailure Friday 始まり 2013年〜 2025年1月〜 隔週開催で第35回まで 題材 意図的に注入した障害（本番環境） 実際に起きた障害（障害連絡チャンネルから選ぶ） やること 注入した障害を重大インシデントとして扱い、 インシデントコマンダーを立てて対応する 当時の対応手順をリプレイしながら、コミュニケーショ ンの状況や技術的原理を解説する「障害対応の感想戦」 狙い システムの回復力を確かめ、 本番の緊張がない状態で対応を練習する 暫定対応〜復旧に必要な手順とシステム知識を共有し、 手を動かす側の属人化を解く 時間軸 これから起きうる障害に備える すでに起きた障害から学ぶ 実施する作業も調査やデータ参照系のみで、本番での復旧手順やコマンド実行方法は紹介に留めるため、環境整備やリスクがない COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 24

Failure Friday のやり方（1） 2025年1月から隔週で開催し、35回実施。 ● 2週間ごとにGatherで開催・たまに参加でもOK ● 障害問い合わせチャンネルで発生した障害のうち、司会が学びになりそうなものをピックアップ COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 25

Failure Friday のやり方（2） 準備は不要。障害対応スレッドを読みながら、当時の対応メンバーに再現してもらうだけ ● インシデントコマンダーには、いつどこで連絡を受けて、ヒアリング/エラーメッセージから何を判断して、 誰に声をかけたのか、最初に何をしようと思ったのかを聞く。判断や関係者とのやり取りに困ったかなど ● 復旧作業担当者には、具体的な調査方法をログやテーブルのデータ状態を画面共有してもらい、 実際にツールを使ったりコマンドを実行して実演してもらう(本番の変更操作はしない) ● 参加メンバーは、それを聞きながら仕組みについて質問したり、 自分でもツールやコンソールを使って同じ操作を確認する ● 加えてシニアメンバーが、そもそもの仕組みの実装解説や 補足の説明をして、より詳細な理解を深める手助けをする ● Failure Fridayはワークアラウンド(暫定対応→復旧)に必要な 具体手順・調査方法・システム知識の知見共有をするため、 根本原因や対策については別の場(ポストモーテム)で議論する COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 26

Failure Fridayの実例：取り込み記事の表示崩れ ● メディアパートナーシップの強化で、記事を取り込んでNewsPicks上で配信するメディアも増えている ● 外部メディアは記事をRSS経由で受信して取り込み・配信するが、メディアごとに記事のHTMLタグのエス ケープ処理や字下げなどの文体が統一されていないため、NewsPicksアプリで表示すると崩れるケースがある ● 今後も起きる前提で、こういう時に暫定復旧させる手順を全員で理解しようとFailure Fridayの題材にした 一部のメディアは記事を取り込んで ネイティブ表示することができる 新しい配信メディアは順次拡大中 新 し い 配 信 メ デ ィ ア を ご 紹 介 し ま す https://newspicks.com/news/17271671/ COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 27

• https://newspicks.com/news/17271671/

取り込み記事の表示崩れが起きる構成 記事を開く HTMLを取得 HTMLを保存 RSS 配信メディアA ユーザー NewsPicks S3上の サーバー 記事HTML 取り込み処理 配信メディアB 配信メディアC … 症状 原因 記事の表示が 崩れる メディアごとに HTMLがバラバラ COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 28

取り込み記事の表示崩れの暫定復旧手順 記事を開く HTMLを取得 HTMLを保存 RSS 配信メディアA ユーザー NewsPicks S3上の サーバー 記事HTML 取り込み処理 配信メディアB 配信メディアC … 復旧② 復旧① 管理画面から キャッシュを削除 HTMLを修正して 再アップロード 取り込まれた記事がS3の◯◯というバケットに置いてあるからそれを修正すればいい、ということを知る必要がある 根本対応は取り込み処理の改善だが、暫定復旧にはHTMLファイルを直接書き換えれば良い COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 29

その後、取り込み記事の障害は「誰でも対応できる障害」になった ● レイアウトや表示崩れ、画像の問題など、取り込み記事関連の障害はその後も繰り返し発生した。 ● Failure Fridayをきっかけに、特定の担当チームに頼らず多くのエンジニアが対応できるようになった 複数メディアの記事を、快適なユーザー体験で一つの サービスとして届けるのがNewsPicksの価値。 新しい配信メディアが増えるたびに、表示崩れは 不具合に敏感な CEOもご機嫌に☺ 起こりうる、ゼロにするのが難しい障害 「前も似たようなことがあったな」「あの時のやり方 で直るかも」「あの時の調査方法で原因わかるかも」 の仮説を思いつくスピードは、障害復旧速度に重要 COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 30

Failure Fridayを1年半、続けてきた結果 ● 毎回10〜20人参加 × 35回分の障害対応の経験知が組織で共有されている効果は侮れない ● 「あの時のやり方で直るかも」を思いつくエンジニア×事象のパターン数が500程度増えているということ ● エスカレーションが減り、障害対応をエンジニアに任せられるようになった ● CTOの私がインシデントコマンダーをすることは、ほとんどなくなった ● 障害対応チャンネルを見なくても、知らない間に問題が解決している日が多くなり、 インシデントコマンダーが上手くいったこともFailure Fridayで全体に共有できる相乗効果に 障害対応を100本ノックした 立場から見て、間違いなく組織 的な障害対応の練度が上がった COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 31

まとめ：属人化を解くための打ち手の土台は、障害対応を当たり前にする文化の醸成 🔽障害対応の属⼈化を解きたい、マネージャーのよくある打ち⼿🔽 手順書・ Runbookの整備 オンコールの 当番制 研修・ トレーニング ツールの導入・ AI自動化 ポストモーテムの 制度化 判断までは 自発的に動ける人に 現場の緊張感を 仕組みの保守が 復旧手順の詳細は 書けない 仕事が偏る 再現できない 新たなコストに 伝わらない 障害対応を当たり前にする文化 全員インシデントコマンダー Failure Friday 全員が障害を解決に導く 復旧手順と知識を、全員に共有 打ち手はすべて間違いではないが、単体では属人化を解かない。文化という土台が醸成されて、上手く機能する COPYRIGHT© Uzabase, Inc. ALL RIGHTS RESERVED. 32

ご清聴ありがとうございました！ ©Uzabase, Inc. All Rights Reserved.