Webサービスの
原因分析の
Web上の 原因分析に 関する 資料
Web上で
IPAが
作成した 障害分析手法と いう PDFに 手法が まと まって 記載されています。 記載されている
手法は 以下に なります。 - なぜなぜ
分析 - ImSAFER
- RCA
- 総合的インシデント分析
- HAZOP
- FTA(フォールトツリー解析)
- FMEA(故障モード影響解析)
- STAMP(Systems-Theoretic Accident Model and Processes)
- STPA(System-Theoretic Process Analysis)
- CAST(Causal Analysis using STAMP)
IPA的には、
STMAP 推しのような 雰囲気の 記述が あります。 3.IT サービスへの<wbr>原因分析手法の<wbr>適用
の記載が 興味深かったので 引用します。 原因分析には
様々な 方法が あり、 各社で 工夫した 適用が 見られるが、 全般に、 IT サービスでは、 「なぜなぜ 分析」が 広く 活用されている。 これ以外の 手法と して、 製品制御系で 使われている 設計と 危険の 解析や 発生頻度を 調べる 手法(HAZOP, FTA, FMEA)に 相当するような 手法の 活用は あまり 見られな い。 ここは
私個人の 感覚と 一致しています。 - なぜなぜ
STAMPに
関する 文書の リンク なぜなぜ
分析の リンク集 その
他の 原因分析ドキュメント PDFには
なぜなぜ 分析の 分析結果(事例)が 記載されています。 SQiPの
ライブラリを 原因分析
で検索した 結果です。
社会心理学での チームエラー
医療事故と
発見失敗
メンバーの
誰かが ミスや エラーを 犯した ときに、 メンバーが 誰も それに 気づかない 場合が これに あたります。 誰も 気づかなければ、 個人の ミスや エラーは そのまま チームの ミスや エラーに 直結してしまいます。 指摘失敗
他のメンバーが
ミスや エラーを 起こした ことに 気づいた 場合には、 それを 指摘して、 訂正させる 必要が あります。 その 指摘を 行わないのが、 指摘の 失敗です。 気づいたのだから 即座に 指摘すればよさそうな ものですが、 この 指摘の 失敗は 最も 起こりやすく、 チームエラーの 強力な 原因であることが わかっている そうです。なぜ 指摘しないのかと 言うと、 ミスや エラーを 指摘する ことで、 相手の 気分を 害して 人間関係が ぎくしゃくする ことを 避けようとする 意思が 働きます。
例えば、部下から 上司には 指摘が しにくい。 後輩から 先輩には 指摘が しにくいなどが 発生します。 修正失敗
指摘は
したが、 修正に 失敗した ケースです。 修正する 事は それほど 大変であるとは 思われないのですが、 指摘した 人は 指摘した ことで 自分の 責任を 果たしたと 思って 十分に 確認しない こともあり、 また、 指摘された 人が エラーを ごまかしたり、 訂正しなかったりする ことさえ 起こる ことも あります。
この辺りの
ポストモーテム
O’Reilly Japan - SRE
以下は、失敗から<wbr>学ぶ
の
Google では、
プロジェクトの 立ち上げ時や サービスに 重大な 障害が 生じた ときも 同様に、 チームが 再び 集まって 事態の 詳細に ついて 話し合います。 この 「ポストモーテム」は、 うまく いったこと、 いかなかった こと、 そして 改善の ために チームでできる ことに ついて オープンかつ 率直に 話し合う ために 行われます。 全社員の 前で プロジェクトの ポストモーテムの 分析結果を 共有する チームも あります。 失敗とは、 組織全体が 学ぶべきひとつの データポイントなのです。
上記文書から
- 参考
改めて、 なぜなぜ 分析(5W)を 考える
STAMPは
原因分析自体への何故を<wbr>聞く<wbr>こと
自体は
失敗の 種類を 分類して おく
社会心理学での
- 発見失敗
- 何故〇〇の
発見に 失敗したのか ?
- 何故〇〇の
- 指摘失敗
- 何故〇〇の
指摘に 失敗したのか ?
- 何故〇〇の
修正失敗
- 何故〇〇の
修正に 失敗したのか ?
- 何故〇〇の
補足
- あくまで
障害の 根本原因分析に 適用できそうと いう 意味で、 自己改善などの ケースだと 適用が できないように 思います。 - 原因分析者の
視点(開発者視点、 管理者視点)なのか 置かれた 立場で、 発見失敗、 指摘失敗、 修正失敗なのかは 変わる 気が します。
- あくまで
原因分析者の 視点を 意識する
原因分析者の
以下に
- 開発者の
視点 - 管理者の
視点 - 上級管理者の
視点 - パートナー企業の
開発者の 視点 - パートナー企業の
管理者の 視点 - QA担当者の
視点 - 同一チームで
問題を 観察していた 人(オブサーバー)の 視点
開発フェーズに 対して 原因分析を 行う
システム開発では、
フェーズを
障害に
問題を
発見すべき 開発フェーズ 詳細設計、
基本設計等の 問題を 発見すべき フェーズです。 本来発見すべき フェーズが 何処かを 判断して、 その フェーズで 何故問題を 発見できなかったのか 記載します。 問題を
検出すべき フェーズ 問題を 検出すべき テスト工程の フェーズです。 何故テストで 検出が できなかったのかを その フェーズで 何故問題を 発見できなかったのかを 定義します。 障害検知フェーズ
障害検知が
どのようになされたのかを 振り返り、 検知方法に 問題が あればなぜなぜ 分析の 対象と して 問題を 記載します。 以下、
検知方法の 例に ついて 記載します。 - 自社の
監視システムに よる 検知 - DataDog、
Mackerel、 New Relic 等の APMツールに よる 検知 - カスタマーサポート からの
質問 - 社内ユーザーからの
報告 - エンドユーザーからの
問い合わせ
- 自社の
暫定対応フェーズ
障害発生初期の
止血作業です。 問題点が あれば、 なぜなぜ 分析の 対象と して 問題を 記載します。 恒久対応フェーズ
恒久対応時に
問題点が あれば、 分析の 対象と して 問題を 記載します。
5回何故を 聞く 必要は ない
真因に
また、
- 参考
テンプレート
上記の
参考
その他、
- 心理的安全が
もたらす チームパフォーマンスへの 効果 - 第1回 心理的安全性とは 何か|人事の ための 課題解決サイト|jin-jour(ジンジュール) - 社会的手抜き - Wikipedia
- なぜなぜ
分析7つの コツ|個人レベルで 使う 問題解決法の 正しいやり 方 - Web活用術。 - ソフトウェア開発へのなぜなぜ 5 回の
適用~真の 原因を 求めて~
以上です。
コメント