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年9月 | トップページ | 2009年11月 »

2009年10月

2009年10月30日 (金)

【定量的管理雑話】定量的管理を信じない人が定量的管理推進を命じられたら

Q:
定量的管理を信じないのですが、上司にやれやれ言われています。どうすればよいでしょうか?

A:
簡単です。
有名どころのコンサルに頼みましょう。アドバイス業務として。
そして自分の疑問を徹底的にぶつけましょう。質疑はすべて記録してください。録音しておくことがベター。

で、あなたが納得できたら…、
おめでとう、あなたは定量的管理を始められますね。
納得できなかったら…今迄の記録をまとめて、上司に報告しましょう。もしくはコンサルの終盤に入る頃に上司も一緒に参加してもらいましょう。

しかし残念ながら定量的管理実施が自分の上司レベルではなくもっと上からの「命令」ならば頭を使うしかない。
きっと活路は見出だせる。

自分で解決できなければニーズを満たすコンサルを探せ。
先のコンサル結果を示した上で受けてくれるコンサルを。

こういう課題を提示した時に「具体的に見ないとわからない」というコンサルとそんなことに言及しないコンサルがいると思う。
前者は慎重であり信頼できるというよりも、汎用的な解を持っていないと「明言」していると考えた方が良いです。
後者は汎用的な解を持っている可能性もあるし、逆に何も分かっていない可能性もある。

そして、コンサル料は、先のコンサルより格段に高いでしょう。
・・・というより、これを受けることができるコンサルは日本に何人いるのだろうか。

2009年10月27日 (火)

【定量的管理雑話】言い訳のネタ集めとしての定量化

定量的管理は言い訳のネタ集めとして割り切ると先が開けてくる。

散々仕様変更飲まされたのに期限にバグが多かったり間に合わなかったりしたら叩かれる。しかしその変更依頼日や内容、プロジェクトへの影響が記録されていれば大丈夫。対抗できる。

しかし実は定量的データ集めの実務メリットはそれだけではない。

次からの見積もり時に、仕様変更の多さ等のプロジェクトに影響を与える特性を最初から加えることができる点だ。ここを平和的にまとめることができれば、次からはプロジェクト中の説明さえ減らすことができよう。

しかし、これはおそらく「便宜上」の定量管理であって、真の意味での改善につながる定量化ではないだろう。

2009年10月23日 (金)

【定量的管理雑話】「測る企業は成功率が2倍に」をもう少し考える

「測る企業は成功率が2倍に」で重要なのは組織文化と大括りで言えると考えたが、個別にみると、定量的管理をすれば説明責任を果たしやすくなるという面は確かにある。

600ケースもテストしたんだよと言うより今回のテスト密度はこれこれなので過去データから見て十分と言った方が顧客や上位管理層も納得する=つまり「成功」に近づく。
何かあっても、でも今まで通りちゃんとやったんだから不可抗力だよとなる可能性も高まる。

プロジェクトの成功とは失敗の烙印を押されないことである。だれに?顧客や上位管理層に。ならば口頭の定性的説明だけでは失敗の烙印を押される場合でも、信頼度成長曲線みたいな手法を使って相手が納得すればそれは失敗ではなくなる。「測る企業は成功率が2倍に」はそういう意味なら納得できる。

この場合相手が納得することが一番重要。厳密であるが難しい式見せても納得しないような人でも、直感的に納得できる説明なら満足するケースは多い。例えば信頼度成長曲線。これは開発現場では賛否両論あるが上記のような人には抜群の効果を示す。その理論と結果の両方が直感的かつ簡単に理解できるから。

しかし、直感的に理論が理解できて適用結果判断も直感的にできるようなものは、開発現場ではわざわざグラフ化しなくとも体感しているはず。いや、そう思っているだけで厳密には違うかもしれないからグラフ化は必要という方もいよう。しかし信頼度成長曲線に限れば体感の方に軍配をあげたい。

しかし説明責任を果たす場で抜群の効果を発揮するならそれは「有効」である。テスト密度も一緒。品質の維持改善に使う分にはこのような定量的管理は意味があると考える。

2009年10月20日 (火)

【共通フレーム2007第2版】マイナーバージョンアップ

新しい共通フレーム2007について見て行きます。どこがどう変わり、どう変わらなかったのかを中心に考えていければと思います。
11月より更新していきます。

それにしても、これはマイナーバージョンアップというのだろうか。
共通フレームとしてはマイナーバージョンアップでも、共通フレーム2007としてはメジャーバージョンアップといえそうであるし。

共通フレーム2009としなかった点からみればマイナーともいえるが、2009年も終わりに近づいた今、2007というのもインパクトに欠けるのではないだろうか。

【定量的管理雑話】測る企業は成功率が2倍に・・・これ自体定量的にいかがなものか

「測る企業は成功率が2倍に」という日経コンピュータの記事(2008年12月1日号)
http://itpro.nikkeibp.co.jp/article/COLUMN/20090128/323651

これの意味するところは何か。
「そうか・・・では我々も定量的管理をしよう。しかし負荷をかけたくないしよくわからないから上手くいってる組織の管理項目を聞いてそれを実践しよう」という考えは是か否か。

もうひとつ記事を。
子供の学力は親の年収に比例する傾向にあるそうだ。ただ年収が低くとも、ニュースについて語りあったり読み聞かせしたりする家庭の子は学力が高いらしい。
http://www.yomiuri.co.jp/kyoiku/news/20090805-OYT8T00352.htm

それでどこかの教授が、「低所得でも親の心がけ次第で学力向上につながる」とかなんとか間抜けなコメントをしていた。なぜ間抜けか。

持たざる者は工夫で乗り切れと言っているのだ。
所得による教育格差が小さな差であればそれは可能であろう。
しかし、本当に工夫で乗り越えられるのであろうか。
敵戦闘機に対して竹やりで頑張れみたいなことを言っていないか?

まあ、確かに大学受験のために塾に行ったり家庭教師を雇うのにお金はかかる。
だからそれをお父さんお母さん方が代わりに教えれば金はかからない・・・というのならば納得はできる。しかし、大学受験のための勉強を教えられる父母がどれだけいよう。

読み聞かせしたりニュースについて語りあったりする家庭は、それだけしているわけではない。親が子に何をすべきかを考えて色々行っているのだ。その一例が読み聞かせ等であるにすぎない。だから読み聞かせやニュースについて語り合うことだけすすめても意味がない。

ポイントは、読み聞かせたりニュースについて語り合う家庭環境にあるのかだ。この環境が家庭内になくても、親の年収があれば塾や習い事で補われるということではないだろうか。逆に親が今の生活に精一杯ならば、読み聞かせ等はしたくてもできない。結局、一義的には親の年収が重要だと思われる。

しかし年収はそれほど多くなくとも読み聞かせやニュースについて語り合うことができる家庭はあろう。ここで間違えてはいけないのは読み聞かせとニュースについて語り合うことだけ実践すれば良いと考えることだ。この二つは親の年収に関係なく成績が良い子をあぶり出す単なるパラメータに過ぎない。

これが必要十分条件ではない。要は読み聞かせやニュースについて語り合おうという家庭内の文化があるか否かがポイントなのだ。しかしこの文化をマニュアル化することは難しい。勢い読み聞かせをすすめる某教授みたいなことになってしまう。

教育の専門家ではないのでこの件はこれくらいにして、ソフトウェア開発組織の定量的管理に戻る。ポイントは同じ。定量的管理を行う組織のプロジェクト成功率が高いのは定量的管理を行っているからと短絡的に考えるべきではない。定量的管理を行おうと思える組織文化が成功率を上げていると考えるべき。

だから開発が上手くいかない組織が定量的管理を始めたからといって成功率が上がる保証はない。というか個人的には必ず下がると言いたい。定性的にやることやらずして定量的管理はできないだろうから。定性的に見つけられることをわざわざ定量的に発見して嬉しい組織は別だが。

長々と書いたが、要は定量的管理を行う組織の成功率が高いからといって定量的管理を始めるのはナンセンスだということ。そんなことを言い出す上位経営層がいたら「花さかじじい」を読み聞かせると良い。表層的な形だけマネた隣りのじいさんがどうなったか教えるために。舌切り雀でも可。

以上のように考えれば、この「測る企業は成功率が2倍に」という記事自体が、定量的に怪しいのではないかと検証されるべきだと思う。
詳細に分析したら、「測る企業は、測らない企業より多く成功率向上のための他の施策を行っていることが多い。このため、実は測ることは成功に何の因果関係もないが、他の様々な施策の結果により成功する確率が高いのである」という結果になったりして・・・個人的にはこれは十分あり得る話であると考えている。

まあ、雑誌の記事なのでキャッチーな方が良いとも言えるが、これを見て「測る企業は成功率が2倍だそうだからうちも測ろう」という人が周りにいたら、「ちょっと待て」と言ったほうが良い。昔の記事だし、もう始めているかもしれないが。

バナナダイエットでバナナだけしか食べなかったらきっと病気になります。
一方、神に感謝する生活をしていれば、本当は神などいなくとも幸せに暮らせるでしょう。
何か変なたとえ。

2009年10月16日 (金)

【定量的管理雑話】パラメータ追加でメトリクスの精度を上げることについて

品質系カンファレンスの経験発表においては、今後の改善策として、測定するパラメータの追加でより詳細に計測し制度を上げていく…というパターンが昔からある。

このパラメータ追加でメトリクスの精度を上げようという試み。
気持ちは分かる。
しかし、そもそもなぜメトリクス管理を行うか振り返るべきである。
複雑で混沌としたソフトウェア開発プロジェクトの状況を、特徴的に表すパラメータに着目して人が認識できるようにしようというのが、定量的管理の元々の目的のはず。

なのにパラメータ増やしたらまた混沌とするのではないか。
バグ密度測るのに100個のパラメータ計測するか?
所詮は、発見バグ数を開発規模で割るだけならその程度のものと文字通り割り切るべき。

まして1つのメトリクスだけで評価するのではなく複数のメトリクスを見て判断すべきだとか、管理限界を超えた値も一概にダメと決めつけずその原因を追求すべきと予防線をはる定量的管理などは、労多くして…となりかねない。

大量のパラメータからなるメトリクスデータをこれまた大量に手に入れたとして、それをどうするのか。
結局はプロマネやチームで総合的に判断することになるのでしょう。しかし、その判断は恐らく定性的に行われる。ではわざわざ計測した意味はどこにあるのか。

定量的管理の使い方を間違っているのではないだろうか。
定量的管理は何をするために行うのか今一度よく考えるべきである。

「レビュー指摘率が高いけれど○○○の理由から問題なし」「レビュー指摘率が低いけれど△△△の理由から問題なし」というような定性的分析を都合よくくっつけることで、全ての定量的アラームが、問題なしとして何も対応されないのであれば、手間をかけて定量的にデータ収集をする意味がない。

2009年10月13日 (火)

【定量的管理雑話】ロジックの理論的裏付けの弱さを収集・管理ツールで補うことはできない

工業製品の製造は組立ラインの速度といったペースメーカーがあるので人の作業が関与しても生産性を把握しやすい。逆に、如何に人の作業を速くするかで速度が決まる面もある。
究極は全自動化。

一方ソフトウェア開発にはこのようなペースメーカーはない。
計画はあるが流れ作業ではないので緻密な管理はできない。
やはりよく言われるようにソフトウェア開発には直接測れる物差しが今のところ発見されていないことと人起因およびプロジェクト毎の要件のバラツキが大きくかつ避けられないことが、定量的管理手法を難しくさせる、というかうさん臭くさせる。

このあたりを解決しようとする場合に、現行の管理ロジックはそのままで、早く・精緻で・簡易に算出するような改善を考えることよりも、開発手法自体や管理ロジック自体を論理的裏付けに基づいて変えないとダメなケースが多いのではないかと思う。

自動で欠陥密度が分かり過去データとの統計的比較からプログラムの品質がわかるようになりました…っていわれても、そもそも欠陥密度の算出方法はどうなの?それで良いの?…ということを考えた方が良いことがあると考える。

2009年10月10日 (土)

【定量的管理あれこれ①】ソフトウェアの定量的管理とPMBOKとの両立

ソフトウェアの定量的管理とPMBOKというかプロジェクトマネジメントは両立するか。
マネジメント能力に開発の成否が左右されるなら定量的管理など意味がなくなるはず。

このあたり整理が必要。

プロマネは計画を立てて管理するのであるが、実際のところソフトウェア開発において失敗プロジェクトがあとをたたない。ここに定量的管理を持ち込めば成功するのか。
それとも定量的管理を既にしていてダメなのか。定量的管理ができない分野があって、かつそこが成否のキーなのか。おそらく一面では全てが正しいであろう。

生産性…、頑張る時もあればサボるときもある人の特性を含むこの活動を、定量的に把握するためにはどのような統計的?もしくは算術的?処理をすべきか。

考慮すべきパラメータはざっとみても沢山ある。やる気、残業時間、個人差、プロジェクトの状況や時期、要件変更の頻度や時期…キリがないが、どれも生産性に大きな影響を及ぼすように思える。

そして一番厄介なのはやる気。プロジェクト初期は余裕持って臨んで、末期に徹夜してなんとか間に合ったなどという組織に生産性のメトリクス管理は早い(とはいえ現在の多くの組織がそうである気もするが)。

まずは定性的管理をしっかり行う。
PMはこのあたりに重点を置いて作業を平準化してメンバーを導くことがプロジェクト管理と定量的管理の共存点かもしれない。

以上のような書きぶりでは、全然うまく伝えられていないと思うが、このあたり既にどなたかが整理されているのだろうか。

2009年10月 6日 (火)

【定量的管理と定性的管理に優劣はあるのか②】定量的管理の先にあるもの

定性的管理より定量的管理の方が高度だと思いがちだが・・・。
より良い定量意的管理を行うにはどうすればよいのだろう。ツール類の進歩で定量的データが簡単に得られるようになってきている。このトレンドは今後も続くであろう。
将来的にはデータの洪水に見舞われるのではないだろうか。ここで我々はどうすべきか。定量的データを選別し、使いたい条件・精度での活用を行うのに必要なのは・・・定量的データを元に定性的に考える力ではないだろうか。

結局、定性的管理と定量的管理のどちらが高度かと考えることは意味がない。

2009年10月 2日 (金)

【定量的管理と定性的管理に優劣はあるのか①】CMMIの進化は定量的管理と共に

定量的管理と定性的管理では、どちらが高度な管理なのであろう。

ここでどちらが優れているのかと考えると変なことになる。
CMMIでは「定量的に管理された」がレベル4なのだから定量的管理の方が優れているに決まっていると即答できれば良いのであるが、そういうわけにはいかない。

どちらも重要であるが、導入の順序でいうと定性的管理から入ることが普通…というのが模範回答と考える。

そもそもCMMIでは、マチュリティレベル4は「定量的に管理された」となっているが、マチュリティレベル2は「管理された」であって「定性的に管理された」とはなっていない。単に「管理された」だけである。

ここ、実は奥が深い。

CMM時代は、レベル3は「定義された」で、レベル4が「管理された」であった。

つまりCMMIでは、CMMのレベル4を分断し、レベル3を間に入れたのだ。

CMMが公開されて、10年経過した時の話だ。
そのCMMI登場から更に10年が過ぎた。

再度大きな波が来るか…と思いきや、来年出る予定のCMMI v1.3は、一応マイナーバージョンアップということらしい。
但し、マチュリティレベル4が大きく加筆されるとのこと。

これは、CMMからCMMIへ変化したときに似た行為、つまりレベル4をイジる行為に思える。
定量的管理が10年前に比べ高度化してきていることを示すのではないだろうか。

10年前なら「定量的管理ができている」となりえた管理手法が、今後は「レベル2の管理ですね」となってしまうということ。

さて、話は元に戻って、定量的管理と定性的管理。どちらが高度な管理なのであろうか。

難しい数式やツールを使うという点では定量的管理の方が高度といえそうな気もするが、少し考えてみたい。

例えば、信頼度成長モデル。
実績値を元に最適と思われる曲線を自動で選んでくれるなんていう便利なツールまである。
理論を何も知らない品質保証担当者が、テスト実施結果の内、数字だけしか見ずにPCに打ち込んだ後、「このツールによると、あと7件のバグを発見すべきなので、発見するまでテストを継続してください」と言われたらあなたはどう思うか。

これは、定められたツールによって数学上の処理を行っているわけで、特別なトレーニングも要らずツールに組み込まれた高度なロジックにより自動処理されるため、だれがやっても同じ結果がでるので、外形上は、標準化されかつ定量的な管理としては理想系と絶賛されるべきもののはずだ。

しかし、実際問題、なかなかそうは思えないであろう。
では、この管理において何が足りないのだろうか。

« 2009年9月 | トップページ | 2009年11月 »