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

« 2009年4月 | トップページ | 2009年6月 »

2009年5月

2009年5月29日 (金)

【ソフトウェア開発における生産性②】簡単な生産性向上策②

そもそも品質は品質、生産性は生産性と分けて考えると、スパゲッティプログラムを一生懸命レビュー、テストするという沼にはまることは十分ありえる。
なぜなら、生産性は単独で評価されるのであるから、それはそれで向上したくなる。

しかし、品質もコストも開発期間も全部ばらばらに定量的な改善を求めることは欲張りである。
例えば、自動車で、速くて安全で広くて小回りがきいて、安いものを、一気に求めるのは無謀だと思わないだろうか。

どれかを立てれば、どれかを犠牲にする方が定量的管理・改善においては妥当だと思われる。

もちろん、全てを抜本的に改善することはあり得るが、これは、パラダイムシフトであり、定量的管理・改善とは別物である。

やはり、定量的管理においては、品質は品質、生産性は生産性と分けて考えてはいけないのであろう。
どうすればよいのか。
最も簡単なのは、ゾーン分析的アプローチになるのであろうか。

しかし、単純に品質指標と生産性指標を組み合わせたところで、複雑な開発作業を上手く言い表せるとは限らない。
両者を個別に評価するよりマシな可能性があるというだけである。
では、組み合わせる指標を増やして3次元、もしくは4次元で評価すればよいのか。

最初に立ちかえって考えてみる。
生産性にしろ、品質指標にしろ、指標と言うものは、複雑なソフトウェア開発という作業および成果物の状況を、その状況を特徴的に表すと思われるいくつかの基本測定量の組み合わせによって単純化して表すものである。

目的が指標値の改善であるならば、状況を特徴的に表さないと思われるものは、指標値の改善を考えれば、無視してよいことになる。
しかし、指標値の改善が最終的な目的であるとは思えない。

生産性を上げるということがなぜ必要かを考え、そのなぜに答える改善策を定性的に考えることもした方が良いのではないだろうか。
指標と言う単純化のせいで指標値の改善が目的化することは容易に陥る過ちである。

先の①~③の例に対し「なんて、おかしな例なんだろう…」と言う方も多いだろうが、自組織において類似のことを行っていないか詳細にチェックしてみたら、驚きの結果となる組織も多々あるのではないだろうか。

2009年5月26日 (火)

【ソフトウェア開発における生産性①】簡単な生産性向上策①

以下は現実的な生産性向上の話ではないことを予め断っておきます。

生産性を上げるためには何をすればよいか。
それは簡単、生産性指標の構成要素=基本測定量を良く分析することだろう。

とにかく、秘訣は、
①最初の設計段階からスパゲッティプログラムで構わない、もしくは敢えてこれを心がけること
②品質など問わず、設計書類も最低限に絞ってとにかくプログラムを書かせること
③自動化ツール等のプロセスやシステム的な改善策をこっそり導入すること
これに尽きるであろう。

そうすれば、高生産性を上げて評価されるであろう…って本当だろうか。

「安かろう悪かろう」で良ければ、簡単に生産性など上げられる。

「品質が悪かったら意味ないだろう」と言われそうであるが、通常行われている「生産性」の管理手法に品質を評価する測定項目はない。
だから、①の方法を使っても「それで何が悪いのかわからない。だって指標値は改善しているではないか」と言われれば返す言葉が無かろう。

品質も必要であるならば、品質と生産性とを合わせて定量的評価を行う仕掛けが必要である。

品質は品質、生産性は生産性として完全に分けて定量的管理を行っているのであれば、両者を合わせた管理を検討してみると新しい視点が得られるであろう…と言うのは簡単であるが、実際のところどうすればよいのであろうか。

2009年5月22日 (金)

【ソフトウェア開発における定量的管理⑤】あなたは泳ぎ方を知らないときにタイムを測りますか?

そもそも、できるかどうかわからないことをやろうとするのは、余裕のあるときにすべきである。
効果に確信が持てないことを建て直しと称して実施することは、実施してみて効果が無かったときに責任問題になりかねない。
定量的品質管理よりも、定性的品質改善により効果が見込めそうな場合は、迷わず定性的品質改善を実施すべきである。

よく、計測無ければ改善無しとか計測しなければ何も分からないとか言われるが、改善したことを数字で示すことが組織の目的であればそうであろうが、明らかに実施した方が良いことは、改善したことを数字で示されなくとも実施すればよい。

計測しなければ状況が分からない、改善のきっかけがつかめないというところに至って初めて計測無ければ改善無しとか計測しなければ何も分からないと言えると考える。

例えれば、水泳でバタフライを習得するときに、全く泳ぎ方が分からないときから50Mのタイムを計測することに意味があるかということ。泳法をある程度身に付けるまでは、コーチに腕の振りがどうの、全身の使い方がどうのと直してもらった方が、コーチにつかず最初からタイムだけ測って練習するより、上達が早いだろうということと同じだ。
ある程度泳ぎ方が分かってきてから測定を開始すれば、自分の現状のタイムがわかるし、泳ぎ方をどう変えるとどうタイムが変わるか等、泳法改善の指針にもなる。

タイムと言う定量的指標は泳ぎ方を教えてはくれない。
しかし、コーチは泳ぎ方を教えてくれるし、コーチがいなくとも解説本があればコーチには効果で劣るかもしれないが泳法を知ることはできる。

バタ足から始めて、ストローク、バタ足・ストロークのバランス調整、最適化とカリキュラムが進むにつれて、速く泳げるようになるであろう。
しかし、これはタイムを測らなければ分からないものではなくて、体感できるものであろう。
逆にカリキュラムなしでタイムだけを測っても泳法はなかなか身に付かないであろう、

コーチや解説本だけでは十分ではなく、自身で色々試行錯誤する段階に入って初めてストップウォッチが改善に寄与するのではないか。

開発支援ツールを入れる、レビュー方法、テスト方法を変えるといった、定性的な改善を実施する余地が明らかにあるのであれば、まずそちらから取り組むべきであろう。

ツールを導入したら、生産性が○○%上がりましたとかレビュー手法を変えたらテスト時のバグ抽出密度が半分になりましたとか報告したいのであれば、定性的改善の前に計測を初めても良いが、それは継続的改善のための定量的管理ではなく、ツール、手法の導入効果報告のためであって、計測自体が改善をもたらすものではない。

計測無ければ改善無しが、改善策を実施しても定量的に表せないのであればわからないという意味で使うのであれば、それは否定すべきと考える。
定性的改善は、計測しなくとも実施すればよいし、単純な指標で改善がわかるような定性的改善策なら、計測しなくとも効果は実感できるだろうから。

あなたは泳ぎ方を知らないときにタイムを測りますか?

2009年5月19日 (火)

【ソフトウェア開発における定量的管理④】定量的管理を始める前に

作られたもののバラツキが「工程上のちょっとの差」に起因するのであれば、定量的に計測してその差を見つけて改善すれば良い。
「ちょっとの差」だけに定量的に計測しないと見つけることも、改善されたかどうかもできないだろうから。

しかし、実際のソフトウェア開発現場における品質の差は定量的に計測しないとわからない「ちょっとの差」ばかりなのだろうか。

開発者毎もしくはプロジェクト毎の成果物品質のバラツキが「大きな差」であるならば、わざわざ計測して原因推測・改善案検討するよりも、「大きな差」はどうしたら減るだろうと定性的に考えて対策を講じた方が良いのではないか。

また、「ちょっとの差」以上に、定性的にも分かる手順・方法のばらつき、個々人の能力の差による誤差が大きければせっかくの計測値から正しい傾向を把握することは困難であろう。

定量的管理をしなければとあせる前に定性的管理で他にできることはないかと辺りを見渡すことは、顧客や上位経営層等に改善をアピールするためではなく、自分たちのためだけに改善を行いたいのであれば、非常に意義があることであろう。

2009年5月15日 (金)

【ソフトウェア開発における定量的管理③】開発者は指標値を意識すべきか否か

既に述べたように、ソフトウェア開発の定量的管理におては、達成しなければならないバーを定めて行う未達成事項の取り締まりと、開発プロジェクトの健全性を簡易的に把握しようという健康診断がある。

「計測を始めて何件かの実績値が集まったら、3σの範囲で上限下限を決めて管理を始めることができる」と言う考え方は、後者の健康診断的考え方だ。

しかし、一度上限下限の考え方を打ち出すと、その値に開発者が縛られる可能性がでて来る。
そうなると、その後の計測値は、それまでの指標値を睨んだ値となる。
これを積み重ねていった上で、継続的見なおしと称して、指標値をそれまでのデータで見なおしを行っても、最初の段階で定めた指標値に縛られている可能性が捨てられない。

だからといって、自然体で計測したデータを統計的に収束するであろう数だけ集めようとすると、今度は計測された値のバラツキが大きく、指標値が定まるまでにかなりの期間を要するであろう。統計的に確からしい計測値が定まる前に対象ソフトウェアの寿命が来て運用が停止されたというようなことになりかねない。

工業製品における製品品質は、「同じ品質」の「同じもの」をつくるために行うものである。

一方、ソフトウェア開発においては、「同じもの」を作ることはない。
「同じ品質」の「違うもの」を作るのだ。

「同じ品質」の「同じもの」というのは、「同じ品質」なら「同じもの」であり、かつ「同じもの」であれば「同じ品質」が成り立つことである。だから、「同じもの」というものの直接的な特性に対して計測することで定量的管理が可能になる。
長さや重さは一定の範囲内に収まっているか、性能は予め定めた程度を満たすか等を検査し、それから外れたら「同じもの」ではないとするのである。
長さ、重さ、スピード、処理能力、ゆがみの程度等、ものに対して直接観測できる事項を計測するのである。
また、プロセスの品質保証にしても、「同じもの」を作るために同じプロセスを徹底するのである。

工業製品では「同じもの」か否かの検査をすることが、「同じ品質」を保証するプロセスの1つになる。

これに対し、ソフトウェア開発は、「同じもの」を作らないので、「同じもの」か否かの検査アプローチで「同じ品質」を保証することはできない。

以上のことは、既に多くの人に言い尽くされている。
しかし、これを意識してか無意識にか忘れて管理をしているところが多いのではないだろうか。

2009年5月12日 (火)

【ソフトウェア開発における定量的管理②】定量的管理は母集団に共通の「定量的」かつ「妥当」な特徴があってこそ

指標値をどのように定めればよいのか…これはかなりの難題である。
「計測を始めて何件かの実績値が集まったら、3σの範囲で上限下限を決めて管理を始めることができる」と言う方もいらっしゃるようだが…。

確かに、数学的には計算可能でしょう。
しかし、それを元に管理することは妥当な結果をもたらすのであろうか。

ここで突然だが、カレー屋さんを例に考えてみたい。
最初店主一人で切りもりしていた時は、店主自身でご飯やルーを盛っていた。一人前のご飯やルーの量が同じになるようにするのには、店主の勘に依っていた。
しばらくして、店が繁盛してきたのでアルバイトを雇うこととなった。一人前のご飯やルーの量が人によりばらばらにならないようにする必要が出てきた。

そこで次のように定めた。

・ご飯 … ハカリを用意し1人前のグラム数を定めた
・ルー … 適当な大きさのお玉を用意し、すりきり1すくいを1人前とした

これで、改善の余地はないか。
ご飯は、いちいち重さを量りながらでは手間がかかることが分かった。
それで、ルーと同様の考えで、型にご飯を詰めて一定量とすることとした。
一定の容積のご飯は一定の重さであるという前提で、以前と同じグラム数となるようご飯を提供した。

次に改善対象となったのは、ルーである。
お客様からの次のようなクレームが多発していた。
「私のカレーと隣の人のカレーでは肉の量が全然違う」

お玉でのすくい方次第で、このような自体が発生することは十分にありえる。

ご飯はおおよそ均質なので、どこの部分をよそっても「一定の容積のご飯は一定の重さである」と言えるが、ルーはお玉1すくい中の具の内容はバラツキが大きい。

キーマカレーなら比較的均一であるが、ごろごろとした鶏肉の入ったチキンカレーでは大きな差が生じる。
では、どうするか。
チキンカレーの鶏肉は別に煮込み、大きなバラツキの要因となるような具のないルーをお玉でよそった上で、予め何個と決めた鶏肉を乗せることとした。

これで、お客様からのクレームは無くなった。
これは、厳密には個々の鶏肉の量にバラツキはあるが問題視されなくなったということであり、お客様の許容範囲内の誤差に収めたことを意味する。

以上のように、料理をよそうという行為はご飯でもルーでも同じはずであるが、定量的に管理する方法はそれぞれに合わせて異なっていたほうが良く、更には、同じルーといっても内容が異なれば定量的管理方法もまた異なった方が良いことがありえる。

さて、ソフトウェア開発において同様の課題はないだろうか。
ソフトウェアは、上の例で言う「料理」に相当しないだろうか。

どれもソフトウェアだからと同じ物差しで測って良いのだろうか。

ご飯のように、均質かつ重さと容積が比較的小さい誤差で比例するのであれば良いであろう。
しかし、ソフトウェアは均質で誤差が少ないのであろうか。

そもそも、カレーと違って、いつも同じ量を作成するのではない。
加えて、物差しが直接の計測値ではなく、バグ摘出率等といった割合で表されることが多いのであるから、カレーより更に難しい。

定量的管理は母集団に共通の「定量的」な特徴に着目して行うのであるが、しかし、「お玉」でどのプログラムも測れるからといって一律に「お玉」だけで管理しようとしても上手く行かない。

「定量的」かつ「妥当」な特徴があってこそ管理できるのだ。

そしてこの「定量的」かつ「妥当」な特徴を1つのメトリクスに求めることは難しいことが多いであろう。
一つにこだわらず、複数のメトリクスを用いて判断すれば良いのであるが、たくさん組み合わせたからといってよく分かるとは限らないので、数字にこだわりすぎることは止めた方が良い。
厳密には個々量にバラツキがあっても、問題視されなければ良いのだ。
問題視されないということはどういうことか、を考えることが重要である。

« 2009年4月 | トップページ | 2009年6月 »