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            
無料ブログはココログ

« 2011年4月 | トップページ | 2011年7月 »

2011年5月

2011年5月24日 (火)

【続定量的品質予測のススメ】定量化に対する意識のレベル

P36に「表1 組織の定量化のレベルと企業文化」という段階モデルがある。

この段階モデルというのは、CMM(CMMI)がオリジナルであるが、組織の成熟を何段階のレベルに分けて達成度を評価するという手法。

これに功罪があることはよく言われていることである。
しかし、それらは大抵、確証に基づいた客観的評価をベースにしている。

ところが、「組織の定量化のレベルと企業文化」モデルは、「定量化に対する意識」が段階化されている。
理解できなくはない。しかし、このモデルは、なんとなく理解することは可能であるが、これに基づいた何らかの活動をすることはできないと考える。

特にレベル3とレベル4は、その説明として、
レベル3 : 定量化を行っているが、魂の入っていない組織
レベル4 : 魂の入った定量化を行っている組織
と書かれている。
もちろん「魂」の定義はない。

この表全体の言いたいことは理解できる。
しかし、これは、段階モデルで書く必要などない。
文章で十分書くことができるし、その方が却って内容を理解してもらえると思われる。

そもそも、定量的管理というのは数字に基いてバシバシ判断していくことであり、そういうもののレベルを評価するモデルに「魂」という全く定量化不能の精神世界の言葉を使うのは、潜在意識に訴える面でも逆効果ではないだろうか。

2011年5月20日 (金)

【続定量的品質予測のススメ】定量データの問題を定性的な見解で覆い隠すことの是非

P34「2.2 品質管理を重んじる文化の重要性」にて、「妥当性を主張するために定量データの問題を品質の定性的な見解で覆い隠すことは、避けるべきである」とある。

本当にそうだろうか。

確かに、定量データの基準値があって、それから外れたら有無を言わさず不合格となるのであればこれは正しいだろう。
例えば、PCにおけるUSBの口の大きさ。これは、その企画から一定以上外れると使い物にならないのだから、定性的な見解の出る幕はなかろう。

しかし、ソフトウェア開発における品質を表す定量データは、このような「外れたら有無を言わさず不合格」というようなものではなく、「外れたら、確率的にダメである可能性が高い」という程度の者である。
実際には統計的にも怪しい処理方法で判定しているものが多いように思われる。

このような「外れたら、確率的にダメである可能性が高い」定量データは、管理限界を超えても、一概にダメとは限らないので、その後、検証が必要であるが、その際には、他の補足的定量データとともに、定性的情報も活用すべきであろう。
というよりも、この定性的情報活用がメインになるのではないだろうか。

このように考えると、ソフトウェア開発においては、「外れたら有無を言わさず不合格」ではなく「外れたら、確率的にダメである可能性が高い」と考えるべき定量データの活用の多いので、その場合は、「妥当性を主張するために定量データの問題を品質の定性的な見解で覆い隠すことは、避けるべきである」というのは当たらないと思われる。

これについては、実際本書においても、P110の表の「対策」やP114~P115の「対策」に書かれている内容は、「妥当性を主張するために定量データの問題を品質の定性的な見解で覆い隠すこと」と行っていることからも裏付けられる(私が読み違いをしていなければ)。

2011年5月17日 (火)

【続定量的品質予測のススメ】プロジェクト特性に応じたプロセス選択

P34「2.2 プロジェクト特性に応じたプロセス選択」において「上流工程の定量的管理において特に重要なのは、プロジェクト特性を考慮してプロセスやツールを選択することである」とあるが、これは別に上流工程の定量的管理に限らない・・・ということは別にしても、この「プロジェクト特性を考慮してプロセスやツールを選択すること」は、よく言われているし、メトリクスによる管理について少し真面目に考えれば容易に思いつくことであるが、これの実践は実は容易でないのではないだろうか。

言うは易し行うは難し。

本書では、続いて「どのようなプロジェクトに対しても同じような品質管理負荷をかけていては、結果として適切な精度の品質データを得られない」と書かれている。
更に、「実態を反映していない品質データを分析しても、適切な品質改善策を得ることはできない」とある。

さて、これらは単体ではそれぞれ正しい記述であると思われる。

しかし、それぞれを全て満たすような現実の管理を考えると途端にその難度の高い壁に悩まされるのではないだろうか。

①プロジェクト特性を考慮してプロセスやツールを選択すること

②どのようなプロジェクトに対しても同じような品質管理負荷をかけていては、結果として適切な精度の品質データを得られない

③実態を反映していない品質データを分析しても、適切な品質改善策を得ることはできない

これら全て、それ自体難題であり、かつ定量的管理における大きなバラつき要因になると思うのだが・・・。

2011年5月13日 (金)

【続定量的品質予測のススメ】プロジェクトの定義

P32「2.1品質管理のための組織的準備」において、品質に関する「知識を永続的に蓄積する役割として、ここでは『組織』という言い方をしているが、有志の社員1名でも構わない」と書かれている。

言いたいことは分かるが、これは適切な表現とは言えない。

組織として活動するのであれば、社員1名でもそれは「組織」と言ってよいのは当然である。
逆に、「有志の社員」という表現は、組織的としてではなく、関心のある社員が個人的に行うイメージが強い。

組織内で品質についての活動を行う社員が1名であっても良いと言いたいがために、組織としての活動でなくとも良いと捉えられる可能性のある表現となったのは惜しい。

それとも、著作者は、品質活動は組織的活動でなくとも良いと考えているのであろうか。
まさかそのようなことはないであろう。

2011年5月10日 (火)

【続定量的品質予測のススメ】品質予測精度を見極める必要性

P31「プロダクト品質の評価」において「例えば、検証作業での欠陥密度が低かった場合、インプットの作りこみ品質が高く、プロダクトに混入した欠陥が少なかったのか、それとも検証作業の品質が悪く、欠陥を検出できなかったのか判断できない。よって、上流工程のプロダクト品質を評価するには、製造作業や検証作業のプロセス品質、およびプロダクトの品質予測精度を見極める必要がある」とある。

見極める必要があるのは分かるが、どのように見極めるのであろうか。
本書のそれ以降の部分で、それが書かれているのかもしれないが、少なくともこのP31では単に「見極める必要がある」と言い切っているだけで、ではどうするかが書かれていない。

この見極め方法を提示せずに「見極める必要がある」と語るのは、定量的品質予測を「だれでもできる」であったり「驚くほど簡単」にできるという本書のスタンスからは、言葉足らずであると思われる。

但し、この記述はある意味良心的ともいえる。
つまり、「見極める」ことができなければ、定量的品質予測をあきらめることも可とすると読み取れなくもないからである。

プロダクトに混入した欠陥が少なかったのか、それとも検証作業の品質が悪く、欠陥を検出できなかったのか判断できないというのでは、定量的評価をする必要は全くない。

これは、言い過ぎに思えるだろうし、定量的品質予測推進派からの反論も予想できるが、「検証作業での欠陥密度が低かった場合」1つとっても、実は「プロダクトに混入した欠陥が少なかったのか、それとも検証作業の品質が悪く、欠陥を検出できなかったのか」の2者択一ではなく、非常に難しい見極め力が要求されるのである。

つまり、プロダクトに混入した欠陥が少しだけ少なく、かつ検証作業の品質も少しだけ悪いケースや、プロダクトに混入した欠陥が非常に少なく、かつ検証作業の品質も非常に悪いケース、プロダクトに混入した欠陥が非常に多いにも関わらず検証作業の品質が非常に悪いために欠陥数が妥当になるケースなど、想定されるケースが多すぎて、合理的な判断ができないということもありうる。

更に、「製造作業や検証作業のプロセス品質、およびプロダクトの品質予測精度を見極める」ために用いる方法が、あまりに定性的であると、何のために定量的手法を使うのかわからないケースも生じうる。

とはいえ、「上流工程のプロダクト品質を評価するには、製造作業や検証作業のプロセス品質、およびプロダクトの品質予測精度を見極める必要がある」という記述を敢えてしている点は評価に値する。
定量的品質予測をススメるのであれば、これは避けたい話題であるから。

但し、このような難しい問題は、決して「上流工程のプロダクト品質を評価」する場合に限らないとは思うので、その点は同意できない。

2011年5月 6日 (金)

【続定量的品質予測のススメ】「レビューアが本来のレビューに集中できるようにすることが重要」の意図

P28「1.3(2)設計レビューの要件」の最後に、「要するに、レビューアが本来のレビューに集中できるようにすることが重要である」という記述がある。

まったくその通りである。
全くその通りではるのだが、しかしどうしてこの記述が本書に必要なのであろうか。
定量的品質予測とどう関係があるのであろうか。

また、その次のP28「1.4プロセス品質」の説明においては、レビューに関し「論理矛盾を発見することで、インプットとなる文書の品質を見抜ける可能性がある。内容の詳細にまで踏み込めなくとも、形式的・論理的な矛盾があるということは、要件定義者や設計者が何を記述しているか自分自身でよく分かっていない可能性を示唆する」という記述がある。
定量的品質予測とどう関係があるのであろうか。

「続定量的品質予測のススメ」という書名の本に、なぜこのような、どちらかといえば「定性的品質予測」寄りの記述を、わざわざする必要があるのだろうか。
ここに、著作者の定量的品質予測に対するなんらかの意図があるのではないだろうか。

「レビューアが本来のレビューに集中できるようにすることが重要である」という記述が、定量的品質予測に何の必要があるのか・・・著作者は明示的に書いていないが、この必要性の理由は非常に重大な事項であると考える。

« 2011年4月 | トップページ | 2011年7月 »