なぜなぜ分析まとめ
なぜなぜ分析10則（＝なぜなぜ本）を読んで、気づいたこともあるので、
実際に実施するときのコツなども含めて書いておく。
ちなみにこのまとめはソフトウェア開発に特化して記述している。
【心構え編】
・チームを良くするんだということ
・個人攻撃にならないようにすること
・対策までがなぜなぜ分析ということ
【準備編】
・開発に使ったソースコード、ドキュメント、議事録等をリストアップする
＞これを事前にやらないと、分析のときにものすごい時間がかかる・・・
・開発に関わった人（＝関係者）をリストアップする
＞上司とか、知見者とか、関係あるモジュールを担当していた人など。
準備が終わったら、分析を始める。
【なぜなぜ分析-事実確認編-】
1. 不具合によってどのような不都合がお客さんに発生したのかを確認する
2. 不具合の発生箇所を参加者で確認する
＞設計、コーディング、影響範囲考慮漏れなどはソースコードに出てくる。
＞仕様バグは要求仕様書かな。
＞これがなぜなぜ本でいう『事象』にあたる。
3. その不具合の原因のドキュメントを特定する。
そのときにレビューの議事録でどういう指摘がされていたなども確認する。
4. 以下の絵を描く。
・不具合の発生メカニズム
・開発プロセスと関係者の絵を描く。
＞この絵がとても重要。
＞複雑な不具合になってくるとそのとき分ったつもりでも、スグに忘れてしまうので
＞絵として残しておく。手書きで十分いける。
＞なぜなぜ本でいうと『原因追求すべき対象をしっかり把握する』にあたる。
皆の共通認識が出来上がったところで分析を行う。
【なぜなぜ分析-分析編-】
1. 以下の視点でどうしたら良いかを考える。
・作るときに気づくためには？
・テストでひっかけるためには？
・ソースコードに問題は無いか？
＞一般的には設計書の不備だったり、テスト観点だったり、
＞レビューが不十分だったりプロセス等に落ち着くことが多いが、
＞ソフトウェアの場合はソースがまずいということも多々ある。
＞直ぐに修正できないこともあるかも知れないが、
＞いつか実施するリファクタのために、情報を残しておく。
＞なぜなぜ本の『第9則 再発防止策を見出せるところまで「なぜ」を繰り替えす』にあたる。
2. 考えられた対策について、不具合を作りこんだ担当者に確認し、
対策の有効性を確認していく。ここで、新たな事実が分れば絵に追記していく。
＞出てきた対策を全部やるには時間が足りないので、有効な対策だけに絞る。
＞ここでも個人攻撃は絶対にしないこと
3. なぜなぜに参加していないメンバーに絵を使って不具合と対策を説明する。
ここで客観的な対策になっているのかを確認する。（できればで構わない）
＞なぜなぜ本の『第10則 現場・現物で「なぜ」を検証する』にあたる
4. 対策を実行する。
＞テストの観点に追加だったり、次回起きたときにはこうしましょうと決めたり。
＞大事なことはチームメンバー全員が理解すること。
＞『同じ』不具合だけではなく、『似た』不具合を作らないようにしたい。
【確認編】
1. 開発のスタイルに合わせて、月１などで対策が実施されているか確認する。
＞このチェックがないと、対策がされない可能性がある。
2. 必要なくなったものは確認項目から外していく。
＞対策が肥大化していくのでやらないことも決めていく。
というところで、最後まで行くとなぜなぜしてないじゃないかということに気づく。
そう！気づいたあなたは天才っ！！
が、個人的には事実確認のところで、頭の中ではなぜなぜをしていることと同じだと思っている。
前回のエントリでも書いたが、なぜを一般的にすると、何を書けばいいのか分らなくなってしまうので、少しシステマティックにできるように書いてみた。
