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

« 2010年8月 | トップページ | 2010年10月 »

2010年9月

2010年9月24日 (金)

【ソフトウェア開発品質】レビューチェックシートの活用

ソフトウェア開発における品質メトリクスの効用には、定められた基準値を開発者が意識することで開発時点での品質を高めることができるというものがある。
最低限これだけはやらないと品質保証チェックに引っかかるからやらなければという動機づけである。

基準値というものは、単純に数字で表され、分かりやすいため、定められれば誰でも容易に理解可能であるので効果が高いだろう。

では、同様の試みを、定性的な管理においてはできるのだろうか。

「○○を作成しなければならない」という定めとその確認というものもその1つであろうが、ここではレビューの観点について考えてみたい。

レビューにおいては「レビューの観点をまとめたチェックシートを用いて行うべし」と言われている。

このチェックシート、品質向上に効果があるのであれば、レビューの時に使うだけではもったいない。
開発者が、レビュー対象成果物を作成する際に、意識、もしくは都度確認するようにすべきである。

もちろん、セルフチェックなので甘くなることは仕方がない。
甘くはなろうが、だからといって、しない方が良いとは言えまい。
客観的な厳しいチェックはレビュー本番で行うことは仕掛けとしてあるのだから。

しかし、チェック項目について開発者が意識すべしというのは、メトリクスの基準値においてもそうだが、あまり声高に言われていないような印象である。成果物作成やテストの品質を正しく確認するためには、その手の内を明かさない方が良いという考えなのだろうか。

実際にはメトリクスについては、数字という分かりやすい基準があるので、声高に言わなくとも現場において意識されやすいが、レビューについてはそれほどではないのではないだろうか。

しかし、チェック項目は品質に重要な影響を与える項目だから挙げられているはずである。
よって、その項目を意識して開発することは、効率良く品質を向上させる1方法である。

レビューチェックシートは、レビュー時ではなくレビュー対象成果物を作成する時にこそ重要な意味を持つものであり、実際のレビューは、確認作業をしているにすぎないと考えるべきである。

2010年9月21日 (火)

【ソフトウェア開発のメトリクス】必然のデータと偶然のデータ

定量的データに基づく・・・と言われると、客観的に正しい判断ができそうな印象を受ける。

しかし、客観的に正しい判断(に近づくこと)を行うのであれば、データ提供側による恣意的な計測値の誘導だけでなく、そもそもデータ自体が内包する堅牢さも意識しなければならない。

定量的データには、例えば科学実験の結果のようにある条件であれば必ずこのようになるという必然のデータと言えるものがある。
一方、企業の財務データのように、多くの要因が絡み合って生まれるために因果関係を示すことは実質的に困難であるが、計量自体は可能で、かつ因果関係を意識しないでも意味を持つ
偶然のデータと言えるものもある。

また、その両者の性質をもつ中間的データもある(ソフトウェア開発を含めた現実社会においては、この中間的データが多いと思われる)。

さて、ソフトウェア開発の品質管理においては、ほとんどの場合、必然のデータでないと原則使えないと考えられる。
どのような結果になるかの因果関係があいまいでは、出てきた結果から品質の良しあしが判断できないからだ。
たとえば「この数字は基準値対比かなり大きいのですが、これは品質が良い時も悪い時にも見られる傾向です」と説明されてもデータを受け取る側は判断できないだろう。

一方、生産性等のソフトウェア開発のマネジメント/財務管理では、必然も偶然も中間も重要なデータとなる。
期毎の財務指標の算出においては、どうやって稼いだかや損を被ったかの具体的内容に関わらず、数字のみで金銭の収支は判断される。

このように定量的データには、必然のデータと偶然のデータがあり、それぞれ意味するもの、活用法は異なるはずである。
しかし、実際の運用においては、これらデータの素性を気にしないことが多い。

どちらかというと、全て必然のデータとして取り扱われているのではないか。
しかし、偶然のデータもしくはその要素の強い中間的データを用いて財務データの感覚でソフトウェア開発における品質の定量的評価を行うのは、避けるべきであろう。

ソフトウェア開発における品質が、何か1つのロジックで決まるのではなく、様々な要因によって組成されるものであり、偶然の要素が強いデータから単純に判断することは難しいと思われるからである。

2010年9月17日 (金)

【ソフトウェア開発のメトリクス】計測自動化の必要性

【今回はいつも以上の「戯言」度です。その旨ご承知の上お読みください】

ソフトウェア開発におけるメトリクスの計測に自動化は必須と言われるのはなぜであろうか。

計測に手間暇をかけたらリターンを求めたくなるのが人の性である。
しかし、ソフトウェア開発におけるメトリクス管理は、なかなかこの手間暇に報いてくれる結果が得られない。

そうなるとイライラしてしまうもの。

しかし、自動で採れているならば、一瞥して「ふーん」なるほどという程度の使い方もできる。

ソフトウェア開発の品質メトリクスではそれくらいが丁度良いのではないだろうか。
だからソフトウェア開発におけるメトリクスの計測に自動化は必須と言われるのではないだろうか。

メトリクス関連の記述で、「一つのメトリクスのみを信じてはならない」とか「メトリクスで基準値外となっても直ちにダメだと判断するのではなく原因をよく調査する」等を見るが、これは「ふーん」なるほどという程度の使い方を、まじめに表現したもので、同じことを言っていると考えている。

ソフトウェア開発の定量的管理に多くを期待するべきではない・・・と考える(現時点では)。

但し、マッケーブのサイクロマチック数やネストの深さといったコーディングルール的な定量管理は、賛成する。

2010年9月14日 (火)

【ソフトウェア開発のメトリクス】定性的なものと定量的なものの融合

例えばテスト密度。
これは定量的管理の一つとして使われている。

では、このテスト密度はどのように活用されいるのであろうか。

極論的に活用のケースを整理してみよう。

1.テスト対象に対し、知恵を絞ってテストケースを挙げた上で数え、それをテスト対象の規模で割り、基準値と比べる。
2.テスト対象に対し、定義された方法でテストケースを挙げた上で数え、それをテスト対象の規模で割り、基準値と比べる。
3.テスト対象に対し、基準値に合うまでテストケースを挙げる。

どれがあるべき姿だろうか。そして、実態はどうだろうか。

視点を変えてみよう。

「テスト対象の規模で割り、基準値と比べる」は、定量的と言えよう。というかこれを前提に多くの組織はテスト密度の管理を行っている。
「知恵を絞って」は、定性的とも定量的とも言い難い。
「定義された方法で」は、定性的と言えよう。
「基準値に合うまで」は、定量的と言えよう。
以上を用いて先の1から3を整理すると、以下のように言えるのではないか。

1.定量的でも定性的でもない方法でテストケースを挙げ、定量的にその妥当性を検証する。
2.定性的にテストケースを挙げ、定量的にその妥当性を検証する。
3.定量的にテストケースを挙げ、定量的にその妥当性を検証する。

さて、このように整理すると、それぞれの長所短所が浮かび上がる。

1.は、テストケース数の面では一定水準を保持できるが、テスト内容という質の面では「知恵を絞って」という努力目標的なものであり人に依存する。

2.は、テストケース数の面で一定水準を保持できるとともに、テスト内容という質の面でも人に依存する程度を抑えようとしている。

3.は、テストケース数の面では一定水準を保持できるが、テスト内容という質の面は放棄している。

このように考えると、ならば2が良いかということになろう。
単純化された理屈の上ではその通りだと考える。

しかし、実際にはそうとも言えないという考えもあろう。
「定義された方法で」から、テストケースを機械的に挙げようという考えをテストケース立案者が持ってしまっては定性的管理が逆効果となる可能性があるからである。

テストケースを挙げることは、機械的作業であってはならない。
全件テストを行うというのならば、機械的に行うことは可能であろう。しかし全件テストは現時点では不可能である。
それに、全件テストを行うのであれば、そもそもテスト密度という考え自体不要である。

「定義された方法で」テストケースを挙げることは必要であるが、それを進めても、知恵を絞ってという人に依存した行為がやはり重要なのではないだろうか。

定性的な基準を元に、人の知恵を絞って挙げたテストケース数に対し、定量的に評価する・・・これができて初めて、テスト密度の定量的管理を行っていると言えると考える。

2010年9月10日 (金)

【ソフトウェア開発のメトリクス】ソフトウェア開発におけるデータ鮮度

ソフトウェア開発におけるデータの鮮度はどのように考えればよいだろうか。

例えば、
当社では
20年にわたる蓄積データを元に生産性も品質も管理しています
というのは、良いことなのであろうか。

この言は、極端に捉えれば、次のいずれかの意味といえよう。

A.20年にわたるデータ蓄積によって得た知見を元に、直近の数年(または数か月)のデータに基づいて管理していることを自慢している

B.20年分の膨大なデータを全て使うことを自慢している

恐らく多くの顧客がAであれば感心するが、Bについては「えっ?」と感じるのではないだろうか。

上の例では20年としたが、これが5年であったらどうであろうか。

SI会社は、日々プロセス改善に努めていると言う。
一方で過去何年かの蓄積データを誇る。

開発プロセスが変わった場合、各種定量データの取り扱いはどうしているのであろうか。
20年前の定量的データが問題なく使用できると公言することは、それに関係するプロセスもしくはプロダクトの品質・生産性等が20年前と変わっていないということを言っていることになるのではないだろうか。

ここに、実運用上の悩ましい問題が潜む。

2010年9月 7日 (火)

【マネジメントと現場のための定量的管理②】

ヒトの観察力は凄い。

但し、観察で感じたことは、残念ながらそのまま伝達できない。
絵画を見たり音楽を聴いて感動しても、その感動をその場にいなかった者に伝達することは非常に難しい。
観察力に伝達力が追い着いていないのである。

だから、人は、定量化という手法を編み出したのかもしれない。
見える化とかいうが、最初から見えている人には不要で、見えない人のために見えるようにしてあげているだけとも考えられる。

全部とは言わないが、ソフトウェア開発の現状を鑑みると、定量的管理や見える化と呼ばれるものの多くがこれに当てはまるのではないか。

しかし…、
定量的管理は、本質的には計測しないと分からないことを知るために実施されるべきで、定性的に分かることは、本来わざわざ測る必要は無いはずではある。
しかし一方、上位マネジメント層および顧客は、プロジェクトマネジャーが定性的に分かることを一々見ることはできない。
だから、本質的な定量的管理とは別に、報告のための定量的管理があると考えるべきであろう。
そして、プロジェクトマネジャーは、この2つの意味と意義を理解の上、管理を行うべきである。

だから、定性的に分かることなのにプロジェクトマネジャーが必死にメトリクスを追いかけるというのは愚かなことなのである。
しかし、それが実際の開発現場では、「ちゃんと管理を実施している」と錯覚されている気がする。

プロジェクトマネジャーのメトリクス過多は、プロジェクトマネジャーが、上位マネジメント層に説明責任を果たすことに仕事の重点を置いていることによるのではないだろうか。
しかしこれは、プロジェクトマネジャーがプロジェクト成功のために責任と権限を与えられたマネジャーではなく、中間管理者にしか位置づけられていないことを意味しているように思われるし、そもそもどっち向いているのだという違和感を覚えざるを得ない。

2010年9月 3日 (金)

【マネジメントと現場のための定量的管理】医者と肝臓の比喩

肝臓は沈黙の臓器と呼ばれ、健康診断等しないと状態が悪化していても自覚症状が現れにくく、外からはなかなか分からないという。
しかし肝臓自体は、診断の有無に関係なく日々異常を検知し修復しようと頑張っている。

医者と肝臓自体では検知の能力もスタンスも違う。
医者は肝臓が悪いかどうか肝臓を直接見るのではなく、血液検査等の間接的データをもって評価し治療方針を立てるのに対し、肝臓それ自体は現に悪化しているか否かを自身で判断して必要ならばさっさと修復を開始する。

さて、ソフトウェアメトリクスの世界における検知の能力とスタンスはどのように状況であろうか。

ソフトウェア開発における定量的管理は、マネジメント(≒医者)用と開発現場(≒肝臓)用とに区別されて定義・活用されているだろうか。

それとも、医者と肝臓の比喩は、ソフトウェア開発における定量的管理には当てはまらないのだろうか。
肝臓と違い、開発現場が、定量的にも定性的にも何かを検知したら直ちにマネジメントに上げるような風通し良い環境/関係が構築されていれば当てはまらないと言えるかもしれない。

« 2010年8月 | トップページ | 2010年10月 »