リリース判定基準・プロダクト品質はまずは設計品質を確認する
リリース判定ではプロダクト品質とプロセス品質も見る
グータラ親父がソフトのリリース判定を行う時に使ってきた４つの基準のうちの１つがプロダクト品質という事はリリース判定のための４つの基準前の記事で紹介しました。
プロダクト品質とプロセス品質とは、ソフトの品質を考える上で大切な考え方ですが、何に重点をおくかは市場や組織によって様々です。グータラ親父が使ってきプロダクト品質という言葉の指す具体的な内容については、プロダクト品質についての別の分類を作って何件かの記事で詳しく紹介していますので、詳しくはそちらをご覧ください。
この記事では、リリース判定の時にどうやってプロダクト品質の善し悪しを判定するのかについて、グータラ親父の経験を元に紹介していきます。
プロダクト品質は設計品質とコード品質に分け考える
プロダクト品質は大まかに分けると以下の２つになるので、これらの良否が判ればプロダクト品質の良否を判定できそうです。
- 設計品質
- ソースコード品質
じゃ～この２つの各々の品質の良し悪しをどうやって判定するか？ と考え始めるとまた色々と考えないといけない事が溢れだしてくるのですが、グータラ親父は単純に間違いが少ないならば品質が良いというという判断の仕方をしてきました。
設計品質は設計レビューの結果で測る
ではまず１つ目の設計品質です。 設計品質の良否、言い換えると設計の間違いが多いか少ないかは、何を見れば判るでしょうか？ グータラ親父は、以下の３つの情報を見て設計品質の良否を判断していました。
- 設計レビューの指摘密度＝指摘件数 / レビュー対象設計書ページ数
- 設計レビューの密度＝設計レビュー工数（人時）/ レビュー対象設計書ページ数
- レビューチーム力量＝設計リーダの参加人数
最初の指摘の密度が、設計の間違いが多いか少ないかの指標です。 後の２つのレビューの密度とチームの力量とは、指摘の密度が適切な値を示しているかどうかを判断するための補助的な情報です。 では、順番にみていきましょう。
設計レビューの指摘件数は設計間違いの件数
設計レビューで指摘があったという事は、設計の内容に何らかの間違いがあってそれが見つかったという事です。ところで、設計の間違いを見つけるのは２つの場面です。 １つめは設計レビュー（デザインレビューとか DR とか呼ぶ事も多いですね）の時ですね。設計レビューは設計の間違いを見つけて指摘する事を目的に実施する活動なので、設計間違いの多くはここで見つかります、見つかるはずです、見つかるといいですね、、見つかるかな、、、（いかん、つい本音が漏れだしてしましました） 設計レビューで見逃した設計の間違いは、テストでバグとして見つかります。 見つかって欲しいです、いや見つけましょう！！
そして、設計レビューでもテストでも見逃したバグは。。。 そうですね本番運用の時にヒョコッと顔を出して私たちを嘲笑います。 ちょっと話がそれましたが、設計の間違いは設計レビューとテストの２つのば場面で見つかるという事です。ですので、設計の間違いの数を調べるなら、この両方を足さないといけません。
しかし、リリース判定でプロダクト品質の良し悪しを判定するために設計の間違いが多いか少ないかを判定するには、設計レビューで見つけた間違いの件数だけを数えるだけでも良いと思います。 言い換えると設計レビューの指摘件数を数えるだけで、テストで見つけたバグの原因となっている設計間違いの件数までは、数えなくても良いと思います。
もちろん、テストで見つけたバグの原因が設計間違いだと判明した物は、設計間違いの件数に加えたほうが良い、というのは正しい考えです。でも皆さんの会社では、ソフトのリリース時までにバグの原因分析が終わっていて、バグの混入原因が判っていますか？
テストで見つかった設計間違いは数え難い
リリース直前のデバッグフェーズが当初の計画どおりに淡々と進むような良いソフト開発プロジェクトなら、リリース時にはバグの混入原因も判明していると思います。でもグータラ親父が仕事をしてきた組み込みソフトの世界では、残念ながらその様な良いプロジェクトに巡り合った経験は殆どありません。 このページを読んでいる皆さんも、そんな良いプロジェクトの経験ってあまり無いんじゃありませんか？
リリース直前の デスバレーを、息も絶え絶えになって渡る事が多いソフトの開発プロジェクトがまだまだ多いと思います。そんな普通の開発プロジェクトでは、リリース判定の時期にバグの混入原因まで判明しているという事はあまり望めません。なので、グータラ親父は望めないものはサクッと諦めて、リリース判定の時には設計レビューで見つかった指摘件数だけを見ていました。
設計品質の判定には指摘件数と同時に設計レビューの量と質も大切
ただし、設計レビューで見つけた指摘件数で設計の品質の良否を判断すると言っても、指摘が何件有った？ という絶対数のみを見ていても、設計品質はあまり良く判りません。指摘件数が多いと設計品質が悪くて指摘件数が少ないと設計品質が良い、という単純な判断ができないのが一品開発物のソフトウエアの悩ましいところです。そもそも、設計レビューを１回も実施しなければ、当然の事として指摘事項はゼロになります。また、設計レビューを実施してもレビューをする人の設計経験が少ないと、他人の設計の間違いに気付く事も少なく、指摘件数は少なくなります。
ですので、設計レビューの指摘件数を見るときに、設計レビューの量とレビューチームの力量も合わせ見ておかないと、設計の品質が良いか悪いかの判断が出来ません。
レビューの指摘件数は設計の規模で正規化して判定に使う
そしてもう一つの注意点としては、設計の規模です。設計の規模が大きければ指摘件数も多くなりますよね、１ページの設計書のレビューと１００ページの設計書のレビューとで、指摘件数が違うのは当然です。なので、設計レビューの量と指摘件数とは、設計の規模で正規化してから見る必要があります。 設計の規模といっても漠然としているので、一番数えやすいレビュー対象の設計書のページ数で割って、レビュー率や指摘率に換算して設計品質の良否を判断する情報に使っていました。
レビューチームの力量は指摘密度に影響するが良し悪しを判定し難い
最後のレビューチームの力量ですが、こればかりは数値化は難しいです。 なので、ザックリとリーダクラスの設計者がレビューに何人参加しているか、でレビューチームの力量を判断していました。と言っても、個々の設計レビューで何人のリーダクラスの設計者が参加しているかをレビュー毎に細かく数えても、リリース判定の時には余り意味もないので、設計レビュー全体では平均すると何人のリーダクラスの人が設計レビューに参加していたのか？ という見方をしています。
設計品質の良し悪しを判断する基準値はどうする？
なるほど、設計の品質の良否を判定するための３つの項目は判った、じゃ～値がいくらなら良いくて、幾らだったら悪いの？ というのが最後の疑問ですよね。これについては、判りませ～んというのがグータラ親父の考えです。実際のところ、何を１件と数えるのかという粒度とか、設計書１ページの記述の密度とか、要求される設計書の記述レベルとか、設計レビューの方法とかで、レビュー密度や指摘密度は大きく変わってしまいます。ですので、この値を境にして良否を判断したらいいという標準的な判定基準を作るのが難しいのです。
では、グータラ親父はどうして設計品質の良否を判定していたか？ というと、レビュー密度と指摘密度については、以前の同じような開発で品質がそこそこ良かったソフトウエアと比較して、今回が多いのか少ないのか、という経験を元にした相対的な比較で判断していました。
要するに前と同じ程度なら悪くはないだろう、という判断です。また、設計レビューチームの力量については、リーダクラスの参加人数として最低１人は入っていて欲しいですね。まあ平均で 1.5人～2.0人程度のリーダクラスの人が入って設計レビューをしていれば、まあ安心だろうと考えて、その程度の値を判断の基準に置いていました。
ざっくり纏めてしまうと、過去の品質が良かったソフトウエア開発と比べてだいたい同じ程度なら、設計品質としてはまあリリースしても大丈夫だろう、というのを、指摘密度、レビュー密度、リーダの平均参加人数 で判断していた、という事です。
さて、次のソースコード品質ですが、少し記事が長くなってきたので、続きは次の記事に書きますので、引き続きそちらもご覧ください。 （単に書くのに疲れただけです、ハイ。 ちょっと style.css でも弄って気分展開しようかなと。。。）