スキルの標準化
作業プロセスや設計ドキュメントを見直すことで、ソフトバグを減らし、品質を良くしていく活動を継続して実施してきている。定期的に発生したバグを分析して、バグを直すだけではなく、設計書への記載事項を追加したり、レビューのチェック観点を見直したりと開発工程全体での課題としてリファインを続けている。しかし、行き過ぎた作業プロセスや設計ドキュメントの見直しは時に、生産効率を下げるだけでなく、さらに新たなプロセスを生む要因となる。
つい最近のことだが、ある協力会社の方がバグを一件ずつ分析して、その対処として設計ドキュメントの見直しとか、レビューの観点の追加等の見直しについて意見をいただき議論をしたのだが、バグがかなりの件数があり、資料は数十ページに及ぶ大作であった。一件ずつのバグに対して、分析と分析結果から作業プロセスの改善までを記載しているものだった。良くやったと思われる方もおられるかも知れないが、私自身は納得できないものだった。バグという実際に起こった個々の事例に対して、分析をする場合、どうしても技術的な観点での分析とか、トレーサビリティによる確認とか、言葉がうまく伝わるかわからないが“きれいな分析”になりがちである。作業者のスキルレベルとか、開発グループのコミュニケーション上の課題とか、開発グループの中でしかわかりにくいことが、品質を落とす原因であることも多いのに、そういうことを考慮せず、結果として設計ドキュメントの記載方法まで変えてしまっているのであれば、問題ではないか？と思ってしまう。
本来、作業プロセスやドキュメント体系は、ある一定のスキルレベルを想定した上で、規定されるべきものだと思う。一定のスキルレベルをスキルの標準化と呼ぶことにするが、スキルの標準化から外れたメンバーがバグを出した場合に、作業プロセスや設計ドキュメントまで見直しをかけるのは正しいのか？スキルの標準化を見直すことになるのでは？ということである。
スキルの標準がきれいに定義されていないとしても、作業プロセスとか設計ドキュメントを見直す営みをするときは、見直す原因が標準的なスキルという視点で見たときに至っているかどうかは考えてみる必要があると思う。
