というわけで、ソフトウェア・レビュー技術ー基礎から実践までのノウハウ寸評

ソフトウェア・レビュー技術―基礎から実践までのノウハウ

レビューを重視する身としては、自分のレビュー技術を磨くことが重要なわけで、買ってみました。前半は、「そうだよね」という感じで、目新しいことは特にありませんでしたが、後半に進むにつれて、刺激の多い一冊でした。特にレビュー実施後の定性的、定量的な分析の方法は、プロとしてのノウハウが披露されていて、非常に参考になります。また、当たり前のことですが、レビュー記録を何故付けるのか、障害票を何故管理するのか、という点について、再度思い起こさせてくれました。来週からの業務でのアクションプランとして、実践しようと思うことが幾つか含まれていました。本書ではじめて知った言葉があります。「品質会計制度」です。恥ずかしながら、これまで知りませんでした。勉強はこの後するつもりですが、一番のポイントは、ソフトウェアに潜むバグの数をあらかじめ見積り、それを全て摘出した時点で、品質目標を達成した、とする点です。(製造業の分野などでは、もしかしたら、当たり前の概念なのかもしれません)確かに、レビューやテストは、何時終えれば良いのか？という点で迷います。あらかじめ見積もっておけば、客観的な判定基準が出来るので、次工程へ進んでよい、という判定が出来ます。この点は重要です。数字で根拠を示せるのですから。ただ、私のプロジェクトで直ぐに全てを実践するには、多少問題があります。今まで気にしていなかった幾つかの項目を、定量化する必要があるからです。しかも、過去のことについてです。バグの見積りをするのに、過去実績データが必要です。バグ数見積りの根拠は、「過去の実績」と、本書ではしているからです。確かにテスト時に発覚したバグの記録はありますが、基本・機能・詳細を含む設計段階でのバグ記録がありません。完全にいい訳ですが、アドホックなレビューが多かったのと、レビューにかけられない品質のものをレビューしたために、時間切れになってしまったのとで、ドキュメントに紙ベースでコメントして、電子ファイルに記録していないのです。困りました。が、ただ何もせず、このまま続けるわけにも行きません。今回は、過去のテスト時のバグ記録を元に、設計工程を含む全体のバグ数を想定して、見積もることにします。想定値は、完全に経験と勘ですが…。実践にあたり、不安もあります。数値を出すだけ出して、管理のアリバイで終わってしまわないか、という点です。ですが、こういうことを一度もせずして、心配するのも馬鹿げています。一度徹底的に実践するという経験を経て、成熟していくのでしょうから。まずは、バグ数の見積りからはじめます。