インシデントテックではエンドユーザーがシステムインシデントで困らない世界へ変えることを目的として、企業様との勉強会をスタートしました。今後も定期的に開催していきます。

今回は、レバテック株式会社開発部様向けに、システム障害対応やポストモーテムの進め方に関する社内勉強会が開催され、弊社代表・野村が登壇いたしました。
レバテック開発部様のブログでも参加レポートとして詳細にまとめていただいておりますのでそちらもご参考ください。

本レポートでは、勉強会で紹介した3つの障害対応の改善ポイントについて事例を交えてご紹介します。

システム障害対応改善の3つのポイント

ポイント① システム視点ではなくサービス視点

一つ目のポイントは、「システム視点ではなくサービス視点」です。
障害が起こった時、SIer目線で「システムのデータベースが落ちました」と報告したあるいは報告を受けた経験がある人はいるのではないでしょうか？
しかし、サービスのエンドユーザー視点では、「データベースが落ちた」ということは重要ではなく、「どの機能が使えないのか」ということの方が重要です。

障害対応の改善が進まない最大の課題は、
システム視点では復旧にあたっての情報は足りているが、サービス視点で見た時の復旧の情報が足りていないというズレでした。
システムを復旧させるのはもちろん大事ですが、一番重要なのはサービスの継続です。
ぜひ、システム視点ではなくサービス視点で捉えること意識してください。

ポイント② 事象ではなくアクション起点

2つ目は、「事象ではなくアクション起点」です。
システム障害を長年分析して気付いたことが1つあります。それは「システム障害が発生する事象は無限にあるが、アクションの方法は収束する」ということです。アクションとは例えば、「サーバーを再起動する」「障害情報をWebに掲載する」などです。
アクション候補を思い浮かべてみると、いくつかに収束する傾向があることが分かるかと思います。アクションの判断基準を整備しておくことによって、システム障害対応の質が上がっていきます。

ポイント③ 情報の量ではなく情報の質

最後の3つ目は、「情報の量ではなく情報の質」です。
システム障害が起きて不安になると、「何でもいいから情報が欲しい」と言ってしまったこともしくは言われた経験がある人は多いのではないでしょうか。
実はこの「何でもいいから情報が欲しい」は、現場の負荷が上がったり、経験の浅い人だと情報量が多くなった結果動けなくなってしまうということが起こります。
そのため、ポイント②のアクションを定めた上で、「この情報を得ることができれば障害対応の判断ができる」という情報を集めていくことが重要です。
障害時は情報が多いとかえって動けなくなってしまいます。アクションの選択に必要な質の高い情報を集めるということが重要になります。

改善事例①　3つの改善ポイントの抑え方

3つの改善ポイントの抑え方について、事例を交えて解説します。

システム更改を終えて体制縮小を行うという事例です。この場合、有識者・ベテラン担当者がチームを離れ、経験の浅い担当者が障害対応を行う必要があるという課題が生じます。

この課題に対して、これだけはやりましょうと皆様にお伝えするのは大きく２点です。
「大規模なシステム障害の定義を決めること」と「各パターンで関連する組織を決めること」です。
多くの会社で「大規模なシステム障害の定義」は決められているかと思いますが、それを自チームや自システム目線で落とし込みまでできていることは稀です。
システム障害の定義の明確化とができていないと、障害が発生した時に「これは大規模な障害なのか」と現場担当者が判断できないという事態が生じます。

これらの事態を未然に防ぐべく
・大規模なシステム障害を定義して、それが起きた際に関連する部署を決めておく
・障害が起きた時に関係する（助けてくれる）部署を事前に決めておく
ことをするだけでも障害対応の質は高くなります。第一歩目は”話し合い”です。

ぜひ、定例会議の最後の5分でもいいので、「こういう障害が起きた際にはどのように対処するか？」「どの部署に連絡すればいいのか」ということを話し合ってみてください。

改善事例②　本格対処がなかなか進まない

事例の2つ目は、組織間の思惑のずれから生じる、進まない本格対処ついてです。
気がかりな本格対処を抱えている開発側と売上拡大のために新機能開発を要求するビジネス側との間で思惑のズレが存在し、新機能開発が忙しく本格対処がなかなか進まないという課題です。

この課題の根本的な原因は役割分担のズレにあります。
開発権限の低い開発側（会社によります、）がポストモーテムの本格対処の権限を持っているという役割のズレが本課題の原因となっているケースが大半です。
本質的には、バックログの優先順位もビジネス側で決めるようにすると良いですが、いきなり変えることは難しいです。解決案としては「本格対処と新機能開発を比較可能にする」ということをおすすめしています。

例えば、リファクタリングにより開発コストが50時間抑えられるとすると、
開発コスト50h×単価5,000円＝25万円
利益率が10％の企業であれば、250万円の売上に相当すると考えられます。
そうすると、リファクタリングをやるべきか新機能開発を行うか、比較ができるようになります。

ただし、本格対処と新機能開発を比較することも大変難しいため、
おすすめは、「バックログの一定割合を本格対処とする」と決めることです。
また、この割合もエンジニアとビジネスが話し合いをして納得感を持って上で決めていきます。
やはり、第一歩目に大切なことはエンジニアとビジネスの”相互理解”です。

（まとめ）本日お伝えしたいこと

最後に最もお伝えしたいことは、システム障害対応もポストモーテムも機械損失を防ぎ、会社に莫大な利益をもたらすチャンスということです。
障害対応というと、後ろ向きになったり場合によっては怒られたりしますが、会社に利益をもたらせるチャンスなので、前向きに取り組んでいきましょう！
積極的に取り組むと普段の業務とは違う観点で発見があるはずです。

レバテック様の提供しているサービスは今後より大きくなり、社会の基盤になっていくものだと思います。システム障害対応もポストモーテムも利益をもたらす活動として積極的に取り組んでいただけると幸いです。

参加者の声（抜粋）

• 自分自身障害対応に対してかなり臆病になっていました。講演を聞き、ポジティブに向き合い、ピンチをチャンスに変えていけるということが良くわかりました。まずは一歩踏み出して障害と向き合ってより良いサービス・組織にしていけるように頑張ります。
• ポストモーテムで上がった改善策を適切に推進するためにも、事業側のステークホルダーがポストモーテムに参加するべきという発想がなかったので、非常に参考になりました。
• 「障害の定義」、「恒久対応の優先度が下がりがちな理由」など今までうっすらと感じていたことが言語化された感じがしてとても納得しました。また、それに対してどう解決していくと良いか、実際の事例を踏まえて学べたのが良かった。

インシデントテックはシステム障害対応の改善を支援するパートナーとして、今後も勉強会や交流会を開催していく予定です。