2015年5月
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
無料ブログはココログ

« 2012年3月 | トップページ | 2012年5月 »

2012年4月

2012年4月30日 (月)

【続定量的品質予測のススメ】 レビュー指摘件数を元に評価すること

P108「表6.1-2 品質の測定項目別の評価指針」の測定項目として、「レビュー指摘件数」が挙げられている。
ちなみに他には、レビュー指摘密度、レビュー工数密度が挙げられている。

この「レビュー指摘件数」の評価指針として「指摘件数が少ないときは、『プロダクトの品質が良い/レビューが不適切』と予測し、レビュー実施内容を調査する」と書かれている。

さて、密度の弊害はこの場合置いておいて、絶対値の「レビュー指摘件数」で指摘件数が少ないと評価するのはどのようにすればよいのだろうか。

これは、後に続くレビュー指摘密度、レビュー工数密度についてもいえるのであるが、件数や密度が大きい、小さい、多い、少ないは、簡単に言えないのではないだろうか。

ある意味、それを割り切る代わりに、メトリクスの分析結果を一方的に信じないみたいなことを言われるのであろうが、ソフトウェア開発における品質指標の多寡評価は本当は非常に難しく繊細なものだと思える。

根源的な問題はともかく、レビュー指摘件数だけみて多い少ないと言えるのはどのような論理なのかを説明すべきであろう。

これで多寡が言えるならば、わざわざレビュー指摘密度など導出する必要がないと思われる。
その意味では、レビュー指摘件数とレビュー指摘密度の二段評価を行う理由が分かれば良いのであろう。

このように考え、「レビュー指摘密度」の評価指針の記述を見てみよう。

「密度が大きいときは、『プロダクトが悪い』と予測し、指摘内容を分析する。密度が小さいときは、『プロダクト品質が良い/レビューが不適切』と予測し、実情を調査する」と書かれている。

レビュー指摘件数と類似性があるのはこのうち後半部分である。
改めて引用して比較してみよう。

【レビュー指摘件数】
指摘件数が少ないときは、『プロダクトの品質が良い/レビューが不適切』と予測し、レビュー実施内容を調査する

【レビュー指摘密度】
密度が小さいときは、『プロダクト品質が良い/レビューが不適切』と予測し、実情を調査する

両者は、予測する内容は「プロダクト品質が良い/レビューが不適切」で同じ。しかし、調査内容が微妙に異なる。

【レビュー指摘件数が少ないとき】レビュー実施内容を調査する
【レビュー指摘密度が小さいとき】実情を調査する

調査するのは、指摘件数の場合「レビュー実施内容」であり、指摘密度の場合「実情」である。
この違いが、レビュー指摘件数とレビュー指摘密度を二段評価を行うべき理由であろう。

・・・しかし、この違いは何であろうか。
「レビュー実施内容」は「実情」に比べて範囲が限定的に読めはするが、どう限定的なのかはわからない。せめてこの違いが分かるようには記述してほしかったと言える。

2012年4月23日 (月)

【続定量的品質予測のススメ】 ピアレビューと公式レビューとが同程度の指摘密度で収束するとは

P107「6.1 管理図分析」の「●分析手順」の同ページ下段において、サンプルプロジェクトのレビュー工数密度、レビュー指摘密度の管理図と指摘分類から、分析が行われている。

その「レビュー指摘密度」において、「公式レビューがピアレビューと同程度の指摘密度で収束していない」とある。

これはどのような意味であろうか。
この文は、2つの解釈が可能である。

「公式レビューがピアレビューと同程度の指摘密度であるべきなのに、そのように収束していない」

というのと、

「公式レビューがピアレビューと同程度の指摘密度になってしまっていて収束していない」

という解釈。

それはグラフを見れば自明・・・と言いたいところであるが、グラフだけ見てもどちらとも言い切れないように思える。

「公式レビューがピアレビューと同程度の指摘密度で収束していない」とは、どのような思いで何をフィードバックしたいのであろうか。

2012年4月19日 (木)

【続定量的品質予測のススメ】 密度から分かるもの

P107「6.1 管理図分析」の「●分析手順」の同ページ下段において、サンプルプロジェクトのレビュー工数密度、レビュー指摘密度の管理図と指摘分類から、分析が行われている。

この内、【レビュー工数密度】において、「No.19とNo.22は、ユーザのレビューが広範囲にわたって上限値を超えている」とある。

ここでいう「広範囲」とは何であろうか。

実際にレビュー工数密度のサンプル図を見ると、No.19は上限値の約20%超、No.22は、上限値の5%超程度に見える。
考え方の問題であるが、20%、5%の超過自体を「広範囲」とは言いづらいだろう。

では、広範囲はどのような意味であろうか。
レビュー対象であるドキュメントの一部ではなく全体にわたってと理解するのが正しいように思われる。

しかし、レビュー工数密度からそのようなことが分かるのだろうか。
上限値を超えているケースでは、100ページのドキュメントの内、20ページがどうしようもなくボロボロということはありえないのだろうか。

特に、No.22は、ほんの5%しか上限値を超えていないので、上限値内のページもそれなりの範囲で存在している可能性があると思われるのであるが。

密度から分かることは限定的であり、抑制的に評価しないと誤ることが多いと考えるべきではないだろうか。
レビューのような人の能力・姿勢に依存するものの評価は特に注意が必要だと考えている。

本書において、どのようなロジックでこのような密度から範囲の評価分析ができるのか書いてほしかったと言うのが率直な気持ちである。

2012年4月16日 (月)

【続定量的品質予測のススメ】 上限値・中央値・下限値と目標値

P106「6.1 管理図分析」の「●分析手順」において、レビュー工数密度とレビュー指摘密度の管理図例が挙げられている。

レビュー工数密度には上限値、中央値の線が引かれ、レビュー指摘密度には上限値、中央値、目標値の線が引かれている。

このケースでは、下限値は管理しない考えであるが、これは別に構わない。
考慮すべきは、目標値の線である。

この目標値は何故存在するのであろうか。
しかもレビュー指摘密度のみに目標を張っている。

目標はそれを目指すもの。
それならば達成しなければ即アウトではないのだろうか。

ところが事例を見る限り、このプロジェクトでは目標を達成するつもりは無いようである。
29ドキュメント中で目標を超えているのはわずかに3例であるのだから。

また、理解を難しくしているのは、目標値を張っているのが、レビュー指摘密度であって、レビュー工数密度では無い点である。

「これだけのボリュームのドキュメントであるから、これだけは指摘を出せよな」と言われても、よく書けたドキュメントには指摘を出しようがないかもしれないと思うのだが。
一方で「これだけのボリュームのドキュメントであるから、これくらいの工数はレビューにかけろよ」というのはあまり違和感を覚えないのであるが、本書では逆なのである。

このあたりは色々な考え方があってしかるべきなので構わないとは思うが、敢えてレビュー指摘密度に有って、レビュー工数密度には無いという特徴を持たせているのであれば、その理由を付記した方が読者は悩まないだろう。

この目標値というものは、実際のところ、どのように定義され、どのように運用されているのであろう。
非常に興味があるところだ。

2012年4月12日 (木)

【続定量的品質予測のススメ】 顔がないレビューチーム

【今回は、かなり揚げ足取り気味な話ですので、そのつもりで・・・】

P105「6.1 管理図分析」の「前提条件」において、

・設計の難易度に対して、レビューチームの能力に大きな差がなかった。
・レビューチームの構成がほぼ一定であった

とある。

「レビューチームの能力に大きな差がない」、「レビューチームの構成がほぼ一定」とはどのような意味なのだろうか。

この記述の切り口は良いと思われる。
ここでは、レビューチームの能力が想定されており、それはレビューチームに属するレビューア個々の能力の総和であると考えられている。

現実にはレビューアは個々の人間でありその能力にばらつきがあるのであるから、これは間違った考えではないだろう。

ここで問題になるのは、
レビューチームの能力に大きな差がない
とどのように示すかである。

レビューチームの構成が一定ではなく、ほぼ一定と書かれているように個人差を考慮しなければならない。
これはどのように行っているのだろうか。
この部分は、レビュー工数密度、レビュー指摘密度の精度に大きな影響を及ぼすものであると考えるべきではないのだろうか。

さらっと、
・設計の難易度に対して、レビューチームの能力に大きな差がなかった。
・レビューチームの構成がほぼ一定であった
と書かれても、これから定量的品質予測を行う組織では、困惑するか勘違いするかのどちらかであると思われる。

最初に今回は揚げ足取りと書いたが、レビュー能力などというのは、個人差どころか同一人物の中でもレビュー対象や本人の精神状況により大きな能力差が生じると思うのだけれど。

2012年4月 9日 (月)

【続定量的品質予測のススメ】 品質保証のためにプロセスの品質管理で欠陥を減らす

P100「欠陥密度と残存欠陥数の関係」において「外部仕様書の作り込み欠陥数が多いと、レビューによる品質保証が難しくなるため、設計プロセス自身の品質管理も重要になる」とある。

この文は分かりづらい。

外部仕様書の作り込み欠陥数が多いと、レビューによる品質保証が難しくなるため、(レビューによる品質保証が難しくならないように)設計プロセス自身の品質管理も重要になる

としか読めないのであるが・・・。

設計プロセス自身の品質管理の重要性は、レビューによる品質保証を容易にするためではなくて、単純に外部仕様書の作り込み欠陥数を減らすことではないのだろうか。

元々の文は、
設計プロセス自身の品質管理も重要なのは、外部仕様書の作り込み欠陥数を少なくし、レビューによる品質保証を容易にするためである
というように読んでしまうのはうがった見方過ぎるのだろうか。

まあ、しかし、設計プロセス自身の品質管理も重要なのは、外部仕様書の作り込み欠陥数を少なくするためであるというのは、別に新味はないのであるが。

2012年4月 5日 (木)

【続定量的品質予測のススメ】 QCDのバランスって・・・

P93の「表5.2-6 対策6:プロジェクトの環境改善・条件変更」において、データ上の現象例として「QCDの予定と実績の乖離が大きい」とあり、その対策を取る理由の例として「QCDのバランスが悪い」とある。

QCDのバランスというのはよく聞く話である。
しかしこれを言う組織は、QCDバランス定量的に示せているのだろうか。

「今回は、Qを35、Cを35、Dは30で行くぞ」とか「うーん、Qが5%下回っているため、QC変換式によりCが10%増えると予想される」とか、そんな管理をしている組織がどれくらいあるのだろうか。
まあ、この辺りは突っ込むと自身の無知をさらけ出す可能性があるので早々に逃げるが、少なくとも定量的品質予測をススメられている読者の組織でこれが出来ている可能性は低いのではないだろうか。

何が言いたいか。
組織はプロジェクト実施において計画を立てる。
品質、コスト、スケジュールそれぞれの計画も。

しかし、どのように見積もるにしろ、品質<=>コスト、コスト<=>スケジュール、スケジュール<=>品質における定量的関係を定義した計画など立てていない組織が多いはずである。

ならば、品質、コスト、スケジュールは、それぞれ独立したパラメータであり、QCDのバランスという言葉は、何か起きた時の後付け理由でしか登場機会がないのではないだろうか。

もちろん概念上の話としては理解できる。
安普請で高品質を望むなと。
それでも、QCDのバランスが悪いと言うからには定量管理が必要になるはずで、それはどうやって行うのかというのは別な話である。

「無知にもほどがある。QCDのバランスは定量的に示せる」と言ってほしいと思ってはいるが。
但し、「いやいや、精緻にはできなくとも大まかには掴めれば良いのだよ」みたいな実質的には何の意味をなさない主張は、定量的管理と違い、ことQCDバランスにおいては、認められない。QCDのバランスが大掴みで崩れているというのは、そりゃあ大事で、そのような事態はQCDバランス指標以前に把握していないといけないわけだから。

2012年4月 2日 (月)

【続定量的品質予測のススメ】 定性的管理の本

まあ、仕方がない面はあるのだが・・・。

P89の「表5.2-4 対策4:体制調整とスキルアップ」のデータ上の現象の例として、定性情報が挙げられている。

この部分に限らないのだが、定性情報についてページを割くのは、本書の題名からしてふさわしくないと思われる。

もちろん、定量的管理を行うには、定性的な管理がカチッとできていなければならないことは当たり前で、CMMIの段階モデルでもそのような構成になっているわけだが、しかし、それは当たり前のことであるがゆえに、「続 定量的品質予測のススメ」という名称の書籍にわざわざ書かれるのは違和感を覚える。

もちろん、定量的管理の前提には定性的な管理ができていることがあるよ、というのを頭に持ってくることは構わない。

しかし、具体的内容の記述に入っても延々と定性的管理の重要性を説かれるのはおかしい。

書籍名を「品質予測のススメ」としているのであれば構わないとは思う。

元々の「定量的品質予測のススメ」を出した後、著作者は、定量的管理の前提には定性的な管理ができていることの重要を言うべきと考えたであろうことは推測できる。

そのため、「続 定量的品質予測のススメ」ではこの辺りについての記述が施されている。
この点は非常に良いことだと思う。
しかし、その出し方が中途半端に感じる。

なぜここにしつこく絡むかというと、これは完全に個人的な見解であるが、ソフトウェア開発における定量的品質管理を「ちょっとやってみるか」と取り組むことには意義があると思えないどころか害悪すらあると考えるからである。

本書は実際に開発に取り組む組織のニーズが高い内容を取り扱っているのであるから、ちょっとやってみるかと気楽に考えて取り組む組織が火傷しないようにする注意義務があると思うのだが・・・。

話は短文にして既にぐにゃぐにゃに崩れたが、言いたいのはこれ =>
とにかくやってみよう・・・という世界ではない(と思うのだけれどなあ)。

« 2012年3月 | トップページ | 2012年5月 »