『3カ月で改善！システム障害対応 実践ガイド』の著者 野村浩司さんに社内勉強会を開催していただきました！1 参加者として学んだことや感じたことをまとめていこうと思います。
登壇者
野村浩司さん（@nomurakuj）
株式会社インシデントテック代表。某大手SIerで金融システムの開発保守運用改善を12年担当。2023年9月19日に『3カ月で改善!システム障害対応 実践ガイド』を出版。
書籍は私も拝読しましたが、3ヶ月で障害対応の基盤を整える具体的な方法が書いており、実践しやすい内容でとてもおすすめです。
勉強会実施の背景
2月に開催されたDevelopers Summit 2024で弊社のかわうそ（syoryu89）さんと話をしたことがきっかけでした。
レバテック開発部内で障害対応やポストモーテムの進め方に課題を感じているチームが多かったこともあり、開催に至りました。
障害対応の改善ポイント
障害対応の改善ポイントを3つのポイントで説明していただきました。
- システム視点ではなくサービス視点
- 事象ではなくアクション
- 情報の量ではなく情報の質
1. システム視点ではなくサービス視点
障害が発生した際、開発者は実装した機能のどこに不具合があるのか、どんな修正を行えば復旧するのか、といったシステム視点で事象について考えがちです。しかしユーザー企業が知りたいのはユーザーにとってどんな影響があるのか、というサービス視点での共有を必要としているため、障害時のコミュニケーションはサービス視点で行いましょうという話をされていました。
「システムを直すことも大事だけど、サービスの継続の方が大事。」
障害対応で焦っている時ほどこの言葉を忘れてはいけないし、サービス継続のためにどんな共有をするべきか考えて障害対応を行うべきだと感じました。
2. 事象ではなくアクション
障害の事象は技術の移り変わりなどにより無限に出てくるものですが、アクション候補（どのようなシステム障害が起きたらどのような行動を取るのか）は限られているため、アクション候補を整備しておくことで障害対応の質が上がっていくという話をされていました。
私自身が障害対応を行う際によく悩んでいたのが「どのような観点で影響範囲の調査を行うべきか判断に迷う」ということでした。アクション候補が整備されているとアクションを決めるための材料が必要となり、必要な材料を調査するという動きが影響範囲の調査に繋がると感じました。
3. 情報の量ではなく情報の質
調査項目によっては影響範囲を特定するのに時間がかかることもあるが、アクションを決める判断基準として細かな情報を必要としない場合があるという話です。
例えば「復旧に2時間かかるか2.5時間かかるか悩んでいるが、30分以上復旧に時間がかかる場合はWeb掲載をする」というルールがある場合です。
詳細な情報よりも復旧に30分以上の時間がかかることを先に伝える方が迅速にアクションの決定を行うことができるため、アクションの選択に必要な「質の高い情報」を優先的に共有していくべきという話をされていました。
質の高い情報を共有するには、アクション候補とその判断基準を把握しておく必要があるため、これは 2.事象ではなくアクション の延長の話だと思いました。
また、アクション候補や判断基準の認識合わせを障害対応以外の時間で行っておくことで、障害時の対応を円滑に行うことができると感じました。
改善例
次は具体的な改善方法について例を交えて紹介していまいした。2つ例が紹介されていましたが、今回は私が特に印象に残った例を紹介します。
本格対処が進まない：組織間の思惑のズレ
ビジネスサイドは新規開発を優先したいと思っているのに対し、エンジニアは負債の解消にも時間を割きたいと思っているため、本格対処が進まない事例を紹介していました。
弊社はオールインハウス体制でマーケティング、デザイン、開発、営業全て社内に在籍していることで各職種の専門性が発揮できる反面、組織間の優先度判断が一致しないこともあります。この時の優先度判断に私は悩むことが多かったため、まさにドンピシャな事例でした。
解決案は、本格対処と新機能開発を比較できる状態にすることを紹介していました。リファクタリングやバージョンアップは一見ビジネス側に優先度判断してもらうことは難しいものに思えますが、リファクタリングの場合は開発コストの増加による開発速度の低下、バージョンアップの場合は開発速度の低下に加えて障害発生による機会損失を元に売上換算して優先度判断を行うことができる、という話でした。
例） リファクタリングを行わないことにより開発コストが50時間増加する場合
→ 時給5000円の場合、50時間で25万円。利益率が10%の場合は250万円の売り上げに相当
運用保守の優先度判断は開発が行うべきだと思っていたので、優先度判断を1箇所にまとめ、各タスクを比較可能な状態にすることで思惑のズレを無くしていくという話を聞いた時は衝撃を受けました。
締めの言葉
- 障害対応もポストモーテムも、機会損失を防ぎ会社に莫大な利益をもたらせるチャンス
- 積極的に取り組むと、普段の業務とは違う観点で新しい発見があるはず
- 開発以外の小さなミスも積極的に振り返りを行っていくべき
避けたいと思われがちな障害対応やポストモーテムをとてもポジティブに捉えており、私も積極的に行っていこうという気持ちになれました。
おわりに
今回は社内で実施した障害対応、ポストモーテムに関する勉強会の概要をまとめてみました！
サービスの保守運用に携わる人は障害対応は必ず行うものだと思うので、参考になる点があれば幸いです。
Discussion