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

« 2008年12月 | トップページ | 2009年2月 »

2009年1月

2009年1月30日 (金)

【ソフトウェア品質の定量的管理における想像力②】想像力を働かせる上で注意すべき点

ここで間違いやすいのは、データがたくさん集まれば、全体としては収束するであろう、という考えだ。
考え方としてはその通りだと言えるが、収束すると言えるほど実測データは取れるのだろうか。
加えて、管理図の下限上限の値の差が2倍かそれ以上担ったとした場合に、それで生産性を定量的に管理していると言ってよいものなのだろうか。
数学的にその通りということと、それが実際の管理上、何に役立つかは別である。

組織のカルチャーとして、「計測してみたけど、有意な結果が得られなかったのでこの品質評価モデルは捨てて、別のモデルをやってみよう」と言える組織であればよいが、やってみたけど、有意な結果が得られなかったとなったら経営層を始めとして周囲から集中攻撃されるような組織では、計測値に対する深い想像力がなければ上手く進められない。

もう一つ間違いやすいのは、では計測項目を増やせばよいのではないかという考えだ。
先の生産性のケースでは、生産量と工数だけでなく、難易度や担当者の能力も係数として加味した上で導出した値で評価しようという考え方や、生産性は、難易度別・担当者の能力別に定めようという考え方だ。

前者の考え方には、難易度や担当者の能力を数値的に表すことができるのかという問題がある。
前者では、難易度や担当者の能力を5段階にランク付けする等は行われがちであるが、これは、あくまでそうみなすと言うことであり、客観的厳密性に欠ける。しかし、ひとたびランク付けされたら、それ以降はなぜか厳密な数値として取り扱われてしまうことになりがちである。
しかし、ランク付けという乱暴な補正係数を含んで導出された値は、そもそも管理精度が高いとは言えない。

後者の考え方には、それだけ細かく分類して、それぞれの分類において有意な数のデータが集まるかという・問題がある。

仮定やみなしに基づいた補正係数等を施して導出された値は、見積もりの上では顧客もしくはユーザに、納得させると言う意味で有用ではあろうが、開発が進んでいるときの定量的管理指標値としては、通常は妥当ではない、もしくは精度はそれなりであると考えるべきである。

2009年1月29日 (木)

【ソフトウェア品質の定量的管理における想像力①】一段深く想像力を働かせる必要性

定量的管理を行うためには計測される値およびそれらの組み合わせから導出される値に対する深い想像が必要となる。

そもそも、予め計測した値を元に定めるにしろ、予め相関関係を推定してから計測するにしろ、定量的管理をするにあたっては、 「それを測れば何が分かるのか。それは何故か」や「それを知りたければ何を測るべきか。それは何故か」を考えた上で、評価するための評価モデルを定めているはずである。

しかし、その程度の想像力で充分のか否かということを考えてみたい。

計測した値をモデルに基づいて評価する場合に、集まったデータの相関関係はどの程度なのかについては、算数的に相関の強弱を見ることは簡単であろう。
しかし、それだけでメトリクスとして使えるかどうか判断してしまうのは危ない。

さらに想像を働かせて、個々の実測データを生みだした背景も考慮して、考えるべきである。
例えば生産性を見るなら、難易度や担当者の能力が開発によって異なるわけで、
   非常に簡単なプログラムを新人が開発したときの生産性
と、
   非常に難しいプログラムを熟練者が開発したときの生産性
が、近い値になったからと言って、
   このシステムにおける生産量と工数には非常に強い相関がある、
として指標値を定めた場合に、
   非常にプ難しいログラムを新人が開発したとき や 非常に簡単なプログラムを熟練者が開発したとき
の生産性予測を行っても上手く行くであろうかと考えてみる。

2009年1月28日 (水)

【ソフトウェア開発における計測と改善③】指標に引きずられる可能性の考慮

定量的管理を行う場合、指標に引きずられる危険も考えなければならない。

「指標となる基準値は毎年見直しされ、実績が毎年上回るため毎年基準値も向上している」という組織があったとする。

これは良いことなのだろうか。
実績が毎年上回るため毎年基準値も向上しているということは、毎年改善されているということなのであろうか。
PDCAが回っていると胸を張って良いのだろうか。

そもそも指標となる値は毎年向上できるものだろうか。
「継続的改善」と「目標」「業績評価」とが結びつくと、「一度にあんまり改善すると来年のネタがなくなるので今年はここまで」と、改善スピードを調整するといったとんちんかんな事態が発生する懸念を考えた方が良い。
また、最初に異様に低い基準値が設定されたため、逆にそれに合わせるように開発が調整されている可能性もある。

指標は一度定めると、それを意識した開発を行うことになる。
開発者が指標を意識して開発を行うことは両刃の剣である。
マッケーブのサイクロマチック数やコメント率等は、開発者が指標を意識しこだわるべき指標であろうが、純粋に統計的な数値においては、開発者の指標への意識過剰は真の意味の品質・生産性の向上には結びつかないことも生じよう。

但し、毎年の指標値改善がお客様との契約上の合意事項であれば、それもやむをえない面がある。
お客様が「刈り取れる成果は前倒しで取る変わりに毎年改善することは望まない」のか「毎年必ず改善することを望むのか」で、受注側はビジネス的振る舞いを変えることはあって良い。

2009年1月27日 (火)

【ソフトウェア開発における計測と改善②】定量的管理の限界を知ること

定量的管理が出来ていないと自称する組織が「障害が多い」と言うのはどのような理由によるのであろう。
「うちのシステムは障害が多いから、品質を上げなければならない。その一施策として定量化を行いたい」というような話は普通に聞かれるのであるが、「うちのシステムは障害が多い」という判断自体がすでに定量的管理がなされているからこそできるはずである。

実際、手順化・文書化されていないだけで定量的管理をしているのである。
ただ、どうしてそういえるのかが整理できていないから、説得力がないだけであるのだ。
しかし、「うちのシステムは障害が多い」と言う者に、「どうしてそう言えるのか」をしつこく質問すれば、説得力のある理由が明らかになるだろうし、その説明の過程は定量的なロジックに基づくであろう。
管理が定義されていないということは、計測と評価のプロセス・ロジックに客観性が無く、評価が個人の思い込みで評価されるリスクは高くなる、評価の共有も難しいという面がある。

以上を元に、組織だった定量的管理とは何かを考えると、これは、定量的な計測と評価のプロセス・ロジックを予め定めておき、実際のプロジェクト進捗に合わせてデータを当てはめ妥当性を確認することが、計測者・評価者によらず行えることと言える。

故に、それぞれの指標が何を説明するのかの意味を忘れ、数字だけ見て「結合テストでの発見バグが少ないですね、あとXX個出るまでテストしてください」と言うのは愚の骨頂である。

なぜなら多くの指標が、単なる確率・統計の話なのだから。
色々な事項をはしょって、計測した項目のみに着目して管理していることの限界を考えるべきである。

サンプル数が少ないときや特殊なケースは、直感の方が良いことさえある。というより、「うちのシステムは障害が多い」と言うなどという組織では、直感でカバーできる改善余地がまだまだいくつかあるであろう。

サンプル数が3ケースでも統計処理して指標化せよという者もいるが、乱暴だ。
算数としてサンプルが3つあればσも出せるというだけの話である。
プログラマにより生産性は10倍以上違うと言われるのに、単純に算数を信じることは愚かである。

定量的品質管理は算数ではない。

また、定量的品質管理が目的化してもいけない。
定量的品質管理がSLA等でお客様との契約事項になっているのでなければ。

2009年1月26日 (月)

【ソフトウェア開発における計測と改善①】何が何でも定量的管理をすべきか

ソフトウェア開発において、計測と改善はどのような関係にあるのであろうか。

測るからこそ、改善されたかどうかわかるのであると言うことはできる。

しかし、改善したい個所は、計測にしなければ見つからないと言うわけではない。

改善策は定性的、感覚的に生みだされることは多々あるだろう。
改善されたことが、測ることなしに定性的・感覚的に分かると言うのは、余ほどの改善でないとありえないかもしれないが。

では、計測によらずに考えられた改善策の成果を、改善策の実施前後で計測・評価することに意味があるであろうか。

例えば、新しい開発支援ツールの導入前後で不具合発生率がどう変わったかを計測で示す意義はあるであろうか。
無いのではないだろうか。
新しい開発支援ツールが定性的に見て品質・生産性に寄与すると分かれば、わざわざ事後的に定量的に示しても本質的な意味は無い。
意味があるとすれば、新しい開発支援ツールのための予算を負担してくれた組織や顧客に対して「これだけ効果がありました」と示すことくらいである。

障害が多いシステムの開発プロセスを見直す場合に、定量的管理以前に定性的にみて改善する余地が大きいのではないかと自問することは重要である。
障害が多いから定量的管理を始めようと短絡的に発想する必要は無かろう。
定量的管理、定性的管理の両面から見直しをかけることが良いと考える。

2009年1月23日 (金)

【ソフトウェア品質の定量的管理とは⑤】まずつべこべ言わず測ってみようよ、どこでもやっているから・・・と言う前に

お客様を納得させるために定量的管理をすると言うケースであるが、これは突き詰めればSLA締結に行き着く。SLAまで行かなくとも、「われわれはこのような基準で管理しています」と顧客に言うときに、定量的管理というキーワードは有効である。

この場合に設定する数値は、開発側が自主的に定めることとすると、既存の開発プロセスで実現が容易なものが定められ、決して「がんばって改善しなければ達成できない」ようなものは定められないであろう。
「顧客が納得すれば」実際に改善余地があろうとなかろうと「低い目標」で良いのである。

そんな品質管理指標に何の意味があろうかという考えもあろうし、一定水準を維持すること自体に意義があると考えることも可能である。

以上のように、「なぜ、何のために品質・生産性の維持・向上を目的とした計測が必要なのか」に対する答えの違いにより、何をどのように計測するかが変わってくるのである。

定量化手法や計測手法が巷間色々あるが、自らが計測に何を求めるかを深く考えた上で適用すべきものを選択すべきである。

まずつべこべ言わず測ってみようよ、どこでもやっているから・・・というのも考え方として間違ってはいないと思うが・・・それが品質・生産性の維持・向上を目的とした計測といえるかという観点から考えるとお勧めできない。

2009年1月22日 (木)

【ソフトウェア品質の定量的管理とは④】定量的管理と言っても大掴みができる程度と考えよ

計画精度を上げ計画と実績のズレをなくし計画通りプロジェクトを進めたいという目的に対しては、定量的管理が本来力を発揮するはずである。

しかし、なかなかそうはいかないのが現実である。
なぜこのようなことになるのだろう。

定量的管理に厳密さを求めすぎているのではないかということが、理由の一つであると思える。
ソフトウェア開発は、まだ人手の介する割合が多いのだから基準値に対し10%以内とかなんとかの精度で行うことは難しいことが多い。2倍や2分の1を超えなければ問題ないという割り切ったスタンスで考えれば良いのではないか。

コーディングの生産性は人により10倍以上の差があると言われているのに、生産性を5%、10%の精度で管理して何か良いことがあるのであろうか。

もちろん、統計的に収束すると言えるほどのプロジェクト規模、過去データがあれば多少は精度が上がるだろうとはいえる。

一番気をつけなければならないのは、数字が出るからといって、それを鵜呑みにしないことである。
たとえば、生産性をSLCP/人日で測るとして、大抵の場合割り切れないのですごい桁数が計算機上に現れるが、生産性の有効数字はいくらまでとすべきか意識して考えなければならない。
小数点以下切捨てだとして喜んでいては最悪であるし、そもそも人手作業であることの誤差もあるから、算数的な有効桁数で考えるべきでもないだろう。
通常の組織であれば、せいぜい有効数字2桁で考えるべきであろう。

指標に対する下限が80%だからといって、80.18%で良かったと安堵し79.89%で大騒ぎする必要はないであろう。

このように記せば誰もが納得するであろうが、現場ではえてしてこのような茶番劇が起きうるから注意が必要である。
指標を評価に使うとなるとこれが高い頻度で発生するであろうし、それに伴う悪しき数字操作も行われるであろう。

2009年1月21日 (水)

【ソフトウェア品質の定量的管理とは③】定量的管理が最も業務上の効果を発揮するのは・・・

さて、先に、なぜ、何のために品質・生産性の維持・向上が必要なのかとして次の3つを例示した。

  ・お客様を納得させるため
  ・利益率を上げるため
  ・計画精度を上げ計画と実績のズレをなくし計画通りプロジェクトを進めるため

この中で、色々と建前はあろうが、実際のところ、ソフトウェア品質の定量的管理が最も業務上の効果を発揮するのは、1番目の「お客様を納得させるため」ではないだろうか。

ソフトウェア開発は、様々な不確定要因から、データのばらつきが大きく、また個々のプロジェクトの特殊要因も多いため、なかなか収束しないと言われる。

利益率を上げたいのであれば、開発プロセス、手法などを見なおした方が地道に何かを測って改善するより良いのではないか・・・という意見に抗えるほど定量的計測の精度が高いと言い切ることは難しかろう。

定量的管理手法は、開発プロセス、手法などを見なおした結果を確認したり、なぜばらつくのかなぜ低下してきているのかといった開発プロセス、手法などの見なおしの契機となることに否定はできないが、それは、定性的に観点からの開発プロセス、手法などの見なおしが既にある程度行われている段階での話であり、定性的な視点からの改善余地がある組織にとっては、定量的視点の改善に手を出さなくとも、利益率を上げるための方法は他に色々あるのではないか。

まさにCMMIはその建てつけになっており、定量的管理を始めようとする組織は、まずCMMIの段階モデルにおけるレベル2、3のプロセスを自組織が達成できているかどうかを確認してから定量的管理を考えても無駄ではないだろう。
もちろん、CMMIのレベル3を達成するまで定量的管理を始めるべきではないというわけではない。

ただ、利益率を上げたいのであれば他の方法も色々あるので定量的管理にこだわる必要がないというだけである。

故に、

  ・お客様を納得させるため
  ・利益率を上げるため
  ・計画精度を上げ計画と実績のズレをなくし計画通りプロジェクトを進めるため

の中で、ソフトウェア品質の定量的管理が最も業務上の効果を発揮するのは、1番目の「お客様を納得させるため」であると考えるのである。

「御社ではソフトウェア開発品質についてどのような取り組みをしているか」という問いに、「・・・というように定量的に管理しています」と言えることは現在のSIerでは、必須条件のようになっている。

で、そう言った会社の実体を見てみると・・・どうなのであろうか。

2009年1月20日 (火)

【ソフトウェア品質の定量的管理とは②】戦略的な視点をもった定量的管理

戦略的な視点をもった定量的管理とはどういうものか。

例えば、生産性を維持向上しているということを示すにしても、「お客様を納得させるため」と「利益率を上げるため」では、異なる精度・視点で計測されるべきである。

「お客様を納得させるため」であれば、生産性指標データが、
   予めお客様と合意した設定値を達成していると言えること
もしくは、
   これだけの値であれば、世間で言われる指標値対比十分な生産性とお客様に言えること
が重要であり、そのためにどうするかが重要となる。

一方、「利益率を上げるため」であれば、
   現状対比、より高い生産性にするために測定以外の改善活動の評価とリンクづけた活動となること
が重要となる。   

両者の違いを端的に表すと、
   「お客様を納得させるため」では、自組織のソフトウェア開発がちゃんとできていると示すことが重要であり、
   「利益率を上げるため」では、何が原因で生産性は変わるのかもしくは変わったのか、どうすればより改善できるかもしくは一定値に維持できるのかの契機を発見することが重要であるという点にある。

これは、
   「お客様を納得させるため」では、「生産性はプロジェクト間で基本的には同じで、改善活動を行えば、それ以降のプロジェクトでは全て生産性データは改善されるはず」 を前提としているが、
   「利益率を上げるため」では、「生産性は個々のプロジェクトで変わりうるが、その変動を一定の範囲内に収める手段が何かあるはず」を前提としている。
これは、両者が正反対の前提を置いているということもできる。

この視点の違いは、測定方法や評価方法、測定精度の選択に影響を及ぼす。

「生産性が一定に保たれていることの確認」のための定量的管理と、「生産性の変動を一定の範囲内に収める手段発見」のための定量的管理とは異なる。

これを区別せず「生産性を維持向上するため」とひと括りに考え、安易に他社事例等を持ってきたりしても、利益率を上げたいのに「生産性が一定に保たれていること」を確認するための定量的管理をしてみたりということが生じうる。

2009年1月19日 (月)

【ソフトウェア品質の定量的管理とは①】何のために計測するのか

ソフトウェアの開発にあたり、計測は何故必要か。
何のために計測するのか。

この問いに正面から向き合ったことはあるか。

この問いには、品質・生産性の維持・向上のためと答えて終わりとされることが多い。
品質・生産性の維持・向上というのは大きな括りであるから正しいといえば正しいであろう。
しかし、そこからいきなり「では何をどう計測しようか」と具体的に考えるのは難しいし、おかしな話ではないだろうか。

なぜなら、計測の理由が品質・生産性の維持・向上ということはわかるが、品質・生産性の維持・向上には計測しか手段が無いわけではないからだ。

だからといって、計測が無意味だと結論付ける必要は無い。

一歩進めて、なぜ、何のために品質・生産性の維持・向上を目的とした計測が必要なのかと考えてみると、先が見えてくるように思える。

・お客様を納得させるため
・利益率を上げるため
・計画精度を上げ計画と実績のズレをなくし計画通りプロジェクトを進めるため
他・・・

この「なぜ、何のために品質・生産性の維持・向上を目的とした計測が必要なのか」に応じて、「品質・生産性の維持・向上」のためのデータ計測と活用方法が変わってくるはずである。

ソフトウェア開発においては、「製品品質を上げたいから教科書に書かれている何々を計測しよう」「生産性を上げたいからA社で測っている何々を我々も計測しよう」というような戦術的計測ではなく、「お客様を納得させるため」「利益率を上げるため」「計画精度を上げ失敗プロジェクトをなくすため」といった、もうひとつ掘り下げた戦略的計測が本来は必要だと考える。

品質・生産性の維持・向上は、何のために測定されるのかという問いの答えではない。
品質・生産性の維持・向上はなぜ必要なのか、までさかのぼって考えなければならない。

« 2008年12月 | トップページ | 2009年2月 »