失敗は怒りと失望、批判合戦を生み出す。しかし、失敗から何も学ばなかったらその失敗は完全に無駄になる。アジャイルチームはどうやって失敗から学習しているのか。
James Shore氏は怒る代わりに、全員がそれぞれできる限りのことをするのを勧めている。
他の人を非難するよりプロセスを非難するべきです。ミスが発生してしまった仕事の過程はどうなのか。より悪くならないようにするには、その過程をどう変えればいいのか。これが根本原因分析です。
失敗の根本原因分析をするための最も効果的な方法のひとつが5-Why技法だ。5-why技法はリーン製造から生まれた。問題の兆候を特定し、“なぜ“という問いを5回繰り返すことで問題の原因を見つけるのが5-why技法だ。解決策は“なぜ“を5回考えてから明確になると言われている。
魚の骨図表を使っているアジャイルチームもある。この表は問題を俯瞰的に見るのに役立つ。実際、この表は5-why技法を視覚化するのにとても便利だ。関連する技法としてJoel Spolsky氏が提唱するのは'Fix it Twice'だ。素早く問題を解決することで、チームを先に進ませて、その上でゆっくりと２つ目の問題解決を適用する。こうすることで問題が再び発生することを防ぐのだ。
根本問題分析を行うための最良の方法は何か。
- 適切な人を部屋に入れる。
- 非難が生まないで問題が解決できる環境を作る。
- 本当の原因と真の解決策を見つけるまでやめない。
- ひとつの原因を見つけただけで満足しない。状況はもっと複雑だ。
- 単なる人的ミスという結論は必要ない。
同じように、Gojko Adzic氏はDouglas Squirrel氏の発言を引用して、失敗に影響を受けた人を集めて問題を特定するための投票をするべきだという。 一度問題が特定できれば、5-Why技法を実行して徹底的に分析する。分析しきれないなら、技法の使い方が正しくないのだ。そして、問題が特定できたとき、問題に釣り合うくらいの利益を明確にすることがとても重要だ。
失敗をうやむやにせずに、“5分のダウンタイムを生み出してしまっただけでも開発チームを再教育する”とSquirreは言います。“しかし、その問題に釣り合うだけのタスクを定義すること”。 “問題を解決する必要はない。しかし、先へ進まなければならない”。とも言います。最良の解決策の代わりに、素早く動くべきだと言うのです。“もしやり方を間違えたら、もう一度問題が発生する”。時間がかかり過ぎる解決策は実行できないでしょう。したがって、Squirrelが言うように1週間でできること、あるいは1時間でできることを考え、次に問題が発生することを想定して解決策を練っておくのがいいでしょう。
Jimも根本原因分析が終わってから本当の仕事が始まると考えている。リリース作業に突入して過去の失敗を忘れるのは簡単だ。しかし、失敗の根本原因分析の結果から得られたタスクはバックログを積極的に管理し追跡するために必要だ。マトリックスの収集も必要であり、開発者も正しい方向に気付かなければならない。
マトリックスと変更を行うためのコストに関するデータを使う必要があります。そして、どの程度変更を行うのか、どのくらいの頻度で行うのかを決めます。変更し過ぎではないか、それともいい加減にやりすぎてはいないか、変更のコストが大きすぎないか、問題の大きさと不釣り合いではないか。
このように、失敗は学習機会として最適だ。重要なのは根本原因を特定して、'問題と釣り合う'解決策を積極的に求めることだ。