Webサービスの開発をしていると、システム障害が起こることがあって、この原因分析や再発防止策等を立てることがあるのですが、少しこの原因分析や再発防止策に至る流れが最近面白くなってきました。
原因分析の手法などは調べてみるとたくさんあって、興味を持ちましたので調べた結果を記載します。

Web上の原因分析に関する資料

Web上で見つけた原因分析に関する資料のリンクを記載します。

社会心理学でのチームエラー

医療事故と病院組織における人間関係とコミュニケーション に記載されていますが、エラーの種類として以下の3つが記載されています。

  • 発見失敗

    メンバーの誰かがミスやエラーを犯したときに、メンバーが誰もそれに気づかない場合がこれにあたります。誰も気づかなければ、個人のミスやエラーはそのままチームのミスやエラーに直結してしまいます。

  • 指摘失敗

    他のメンバーがミスやエラーを起こしたことに気づいた場合には、それを指摘して、訂正させる必要があります。その指摘を行わないのが、指摘の失敗です。気づいたのだから即座に指摘すればよさそうなものですが、この指摘の失敗は最も起こりやすく、チームエラーの強力な原因であることがわかっているそうです。なぜ指摘しないのかと言うと、ミスやエラーを指摘することで、相手の気分を害して人間関係がぎくしゃくすることを避けようとする意思が働きます。
    例えば、部下から上司には指摘がしにくい。後輩から先輩には指摘がしにくいなどが発生します。

  • 修正失敗

    指摘はしたが、修正に失敗したケースです。修正する事はそれほど大変であるとは思われないのですが、指摘した人は指摘したことで自分の責任を果たしたと思って十分に確認しないこともあり、 また、指摘された人がエラーをごまかしたり、訂正しなかったりすることさえ起こることもあります。

この辺りの内容は、チームワークの心理学―よりよい集団づくりをめざして (セレクション社会心理学) | 山口 裕幸 |本 | 通販 | Amazon に詳しく記載されています。

ポストモーテム

O’Reilly Japan - SRE サイトリライアビリティエンジニアリング を読んでいたらポストモーテムという言葉が出てきて、原因分析と関係がありそうに思いましたので記載します。
以下は、Google re:Work - ガイド: イノベーションが生まれる職場環境をつくる　の失敗から学ぶ のポストモーテムについての記述を引用します。

Google では、プロジェクトの立ち上げ時やサービスに重大な障害が生じたときも同様に、チームが再び集まって事態の詳細について話し合います。この「ポストモーテム」は、うまくいったこと、いかなかったこと、そして改善のためにチームでできることについてオープンかつ率直に話し合うために行われます。全社員の前でプロジェクトのポストモーテムの分析結果を共有するチームもあります。失敗とは、組織全体が学ぶべきひとつのデータポイントなのです。

上記文書からダウンロードできるテンプレートは障害報告書というよりも振り返りのテンプレートに近いもので、比較的ライトに問題分析をしたい場合使用できそうなテンプレートに思いました。

改めて、なぜなぜ分析（5W）を考える

STAMPは実施すると効果がありそうですが、手法を覚えるのが大変であると考えます。

原因分析自体への取り組みを実施していないという状況であれば、何故を聞くこと 自体は難しいことではなく、なぜなぜ分析(5W)は実施がしやすいと思いました。実際に実施して、思ったことを記載します。

失敗の種類を分類しておく

社会心理学でのチームエラー に基づいて、発見失敗なのか、指摘失敗なのか、修正失敗なのかを分類します。これで最初の質問以下のようになると考えます。

  • 発見失敗
    • 何故〇〇の発見に失敗したのか?
  • 指摘失敗
    • 何故〇〇の指摘に失敗したのか?

  • 修正失敗

    • 何故〇〇の修正に失敗したのか?

  • 補足

    • あくまで障害の根本原因分析に適用できそうという意味で、自己改善などのケースだと適用ができないように思います。
    • 原因分析者の視点(開発者視点、管理者視点)なのか置かれた立場で、発見失敗、指摘失敗、修正失敗なのかは変わる気がします。

原因分析者の視点を意識する

原因分析者の立場により問題の見え方が変わります。開発者視点でしか見えない問題、管理者視点でしか見えない問題、立場により問題の見え方が違うケースがあります。

以下に視点の例を記載します。

  • 開発者の視点
  • 管理者の視点
  • 上級管理者の視点
  • パートナー企業の開発者の視点
  • パートナー企業の管理者の視点
  • QA担当者の視点
  • 同一チームで問題を観察していた人(オブサーバー)の視点

開発フェーズに対して原因分析を行う

システム開発では、開発工程が分かれています。

フェーズを分けて分析を行うことで、MCMEとなる分析ができると考えます。

障害に関してだと、以下のようなフェーズに分かれます。

  • 問題を発見すべき開発フェーズ

    詳細設計、基本設計等の問題を発見すべきフェーズです。 本来発見すべきフェーズが何処かを判断して、そのフェーズで何故問題を発見できなかったのか記載します。

  • 問題を検出すべきフェーズ 問題を検出すべきテスト工程のフェーズです。 何故テストで検出ができなかったのかを そのフェーズで何故問題を発見できなかったのかを定義します。

  • 障害検知フェーズ

    障害検知がどのようになされたのかを振り返り、検知方法に問題があればなぜなぜ分析の対象として問題を記載します。

    以下、検知方法の例について記載します。

    • 自社の監視システムによる検知
    • DataDog、Mackerel、New Relic 等のAPMツールによる検知
    • カスタマーサポート からの質問
    • 社内ユーザーからの報告
    • エンドユーザーからの問い合わせ

  • 暫定対応フェーズ

    障害発生初期の止血作業です。問題点があれば、なぜなぜ分析の対象として問題を記載します。

  • 恒久対応フェーズ

    恒久対応時に問題点があれば、分析の対象として問題を記載します。

5回何故を聞く必要はない

真因にたどり着いたら、何故を聞くのをやめ、真因に対しての対策を立てます。
また、まず個人レベルで基本的ななぜなぜ分析の実施方法について知っておくのは有用に思います。

テンプレート

上記の個人的な考えを反映したなぜなぜ分析(5W)のテンプレートをGoogle スプレッドシート で、 作ってみました。参照モードでパブリック公開していますので、興味ある方は使ってみてください。

参考

その他、文書作成時に参考にした情報です。

以上です。

コメント

カテゴリー

最近の投稿