今日の失敗で、緊急時の備えの大事さが思い知らせてくれました。
経緯
昨日と今日、開発メンバーの一人の解析経験者が休みになりました。
そしてバグ解析はその方の下の経験の浅い人が解析することになりました。
そこで顧客からバグ解析の依頼が来て、この開発メンバーに解析してもらったところ、
出来が悪かったです。。
原因
今までの解析経験者の場合、通常2〜３時間ほどで解析結果を出してくれます。
今のメンバーはその倍の時間がかかりました。
しかも、普段の解析結果と異なるフォーマットで来ました。
なぜでしょう。
本来、僕はこのような事態を備えて、ある程度準備できて、対応できてると思いました。
しかし、ちょっと甘かったのようです。
同じことは以前にも？
1年前を思い出しました。
その時他のベテラン開発メンバーが別プロジェクトに移動することになり、自分の所に新人（今のベテラン）が入ることになりました。
その時も最初の２週間は大変でした。
開発メンバーからの成果物提出が遅く、間違いも多かったのです。
僕も自ら全てを解析しました。
その時、知識とプロセスを統一されなければ、同じ品質のものができないことを認識しました。
その時の対策は？
そこでなるべく人的要素を取り除きべく、不具合解析プロセスの標準化・手順化を進めました。
各ユースケースのシーケンスに従ったログのパターンをExcelファイルに整理し、注意点、正常ケースや異常ケースなどを羅列しました。
解析にあたって各現象にどのキーワードのログが出るべきか、合わせて解析の順番のプロセスを手順書にまとめました。
これで数回使ってもらって、開発メンバーから提出してきた解析結果が常に同じフォーマットになれるようになりました。
人それぞれのコメントが異なることがなくなりました。
解析手順書のコメントをそのままコピペで利用するように依頼したからです。
ではなぜまた？
もちろん、今回も、この新しいメンバーは２週間ほども経てば、きっと慣れてもらえて、通常通りに戻るでしょうが、その前に防げなかったでしょうか。
普段、成果物が迅速に提出してもらったので、あまり意識していませんでした。
今回はメンバー入れ替わることによって発覚しましたが、もしそうでなければ、分からないでしょう。
今後はどう対策する？
ではこのような事態、緊急時の備えとして、どうすればいいでしょう。
もちろん常にデュアル体制で作業させるのは現実ではありません。
定期的にチェックの意味で、経験の浅い人に作業させ、ベテランをフォロー側に回るのがどうでしょう。
これで問題があっても、緊急にならないでしょうね。
なんか、避難訓練、軍事演習の大切さが見えてきました。。。
これらも緊急時の備え、ですね。
来週からこのように意識していきましょう。
せめて週1回程度できちんと練習させたいですね。
コメント