GSNや因果ループ図を本番障害のなぜなぜ分析に使うアイデア

GSNや因果ループ図を本番障害のなぜなぜ分析に使えるのでは、と思った。
アイデアをメモ。

【参考】
SysML要求図をGSNと比較する

astah* GSN - Goal Structuring Notation描画支援ツール

astahGSNのメモ: プログラマの思索

astah*の因果ループプラグインがいいね: プログラマの思索

GitHub - snytng/inga: astah* plugin to analyze a usecase diagram as causual loop.

因果ループ図（いんがるーぷず）：情報システム用語事典 - ITmedia エンタープライズ

システムのリリース後に本番障害が出ると、必ず原因分析と再発防止策を作る必要がある。
その時の分析手法として、GSNは因果ループ図を使えないか？

本番障害の原因分析にはなぜなぜ分析を使う時が多い。
5回のなぜで深掘りする。
しかし、実際は使いにくい。
なぜなぜ分析する時の観点、フレームワークが事例ごとに個別なので、どこを切り口として深掘りすればいいかわかりにくい。
原因を洗い出してもそれが因果関係として正しくても論拠として浸かるか、本当に真因なのか、疑問が残る。
たいていは、設計書を残らず書く、テスト漏れをなくす、PJメンバーに経験者を入れる、みたいなありきたりな再発防止策になりやすい。

GSNを使う利点は、障害の原因分析の論点、因果関係を明確にしやすいこと。
論拠とデータがセットになっているのもよい。

因果ループ図を使う利点は、悪循環の構造を明確にしやすいこと。
QCDが悪化した状態は、何らかの悪循環のループがシステムとして埋め込まれて、そう簡単には壊せない。
本番障害が出るということは、原因分析や再発防止策をきちんと行わなければ、必ず二度目も起きる。
その構造を浮き彫りにできる。

一方、これらのツールにも課題はあると思う。
GSN、因果ループ図を扱えるツールが少ないこと。
この課題は、astah GSN、astahの因果ループ図プラグインで解決できる。
あるいは、GSNは所詮、ロジックツリー構造なので、マインドマップでも代用できる。

GSNで描くと、20個以上の要素がたくさん出てきて、複雑化しやすい。
ロジカルシンキングと同じで、因果関係はすごく丁寧に書き出す必要があるから、どうしても要素は細かいレベルになりやすい。
すると、20個、50個と要素が出てきて、整理するだけでもかなり手間取る。

因果ループ図は、悪循環の構造を表現する要素をうまく抽出しないと、肝心の解決策を見出しにくい。
ループになっている要素のどこかを変化させることで、ループを弱めたり、別のループを生み出すように解決させていくので、要素が真因であるように見出すのが大事。
実際はそれが難しい。

この辺りは色々アイデアが浮かぶのでこれから整理してみる。