Index: [Article Count Order] [Thread]

Date:  Tue, 15 Oct 2002 17:52:54 +0900
From:  hiroki kugimoto <kugimoto@....jp>
Subject:  [XP-jp:03827] (長文) Re:  Re: 無意味なソフトウェア開発生産性の計測
To:  extremeprogramming-jp@....jp
Message-Id:  <20021015174412.6A0C.KUGIMOTO@....jp>
In-Reply-To:  <20021015172308.6A06.KUGIMOTO@....jp>
References:  <20021015143133.15EA.T-HONMA@....jp> <20021015172308.6A06.KUGIMOTO@....jp>
X-Mail-Count: 03827

釘本です。
蛇足自己レスです。


本間さんのおっしゃる「アウトプットの効率を図るための生産性」については、以下の事を考える必要があると思います。
(よく言われることの焼き直しに過ぎませんが)

大雑把に表現してしまえば
「開発するソフトウェアとは、今まで既にある物よりも何かの違いがある」
筈です。
そうでなければ開発自体が経済合理性のない行為、会社に対して不当な不利益を与える行為になるでしょうから。

ソフトウェア開発という人間の活動について考察する場合、「今までと同じ類似部分」よりもむしろ、この、多かれ少なかれ「今までやったのとは違う」部分がある事が非常に大事なのではないかと思います。

今までと違う、という事はそれ自体が問題探索型の活動な訳で、予測不可能であるという事だと思います。
つまりはリスクが把握困難であると。
(リスクが大きいのか小さいのかも事前に判り難い)


#「似ている部分に意味は少ない」と言い切ってしまうと
#結局FP法やCOCOMOの批判になりますので自分自身どうやって見積していいか
#不安にはなりますが、私はFP法的な考え方を否定しません。
#私個人はFP法はすばらしくかつ自然な考え方と思っており、
#「リスク管理」を十分に考慮していない事だけがほとんど唯一の、
#しかし決定的なFP法の欠点と考えています。
#FP法は「全てが予測可能」というラプラスの魔を前提としているような。


生産性の上昇のための方法には一般的に
(売上高−コスト)/従業員数
の公式から、
> 1.売上高を増やす
> 2.コストを減らす
> 3.従業員数を減らす
が3つの方法が考えられますが、それぞれの対処方法を具体的な手順に落としてみた時、必ず確率の問題やリスクの問題が発生すると思います。
いちばん簡単な「従業員の削減」でも、本当に人を減らして売上高もコストも不変かどうか、あるいは予想している範囲内に収まるかどうかなどは「やってみないとわからない」というリスクを含んでいると思います。

経営学の初級教科書ならば
「投資案1での売上高は50%増の実現確率が30%、10%減の確率が70%。案2での売上高は・・・さてどの投資案を採用すべきでしょうか」
などという問題があります。
しかし、現実の経済活動ではこれらの発生確率や結果値の測定方法が判っていませんのでそのような判定方法は意味がありません。
現実の企業活動での問題はAHPや線形計画法のようなOR手法など
http://majesty.umds.ac.jp/study/system/or/ORjava/Operations_research.html
に馴染むものばかりではないだろうと思います。

ソフトウェア開発とは、実はその「ORに馴染まない」代表的な活動ではないでしょうか。

#「ソフトウェアそのもの」にはよくOR手法が劇的な効果を上げるので、
#これらを教育された方々が「ソフトウェア開発」に対してもOR的な
#スマートな解決をしようとしてやや見当ハズレの努力をされたのが
#ソフトウェア工学の歴史の半分以上なのではないかと私は思っています。
#ソフトウェア開発に適用すべきはもっと泥臭い心理学や社会学の範囲に思えます。


昔は経験さえあれば何とか大体のリスクは予測できたので左程問題にならなかったが、最近は外部環境変化の激化とか要素技術の不連続的進化とかなんだーかんだーとか色々とあって「リスクが予測できない」事が一番重要なポイントになってきているのではないでしょうか。

XPは主にこのリスク管理についての手法のように感じます。
ソフトウェア開発は*常に*リスクを伴う賭けなので、賭け事としての必勝法「小さく何度も賭けろ」と言っているのではないでしょうか。
(大雑把過ぎる表現ごめんなさい)

本間さんのおっしゃるように「限定的状況下でのアウトプットの効率」を捉える事も有意義とは思います。
限定的な状況下での開発効率を図るモノサシも、あるに越した事はないでしょう。
しかし、現実問題、「いい風が吹いた条件下でのみ誰が一番速く船を走らせるか」というヨットレースの技術よりも、「風向きが変わったり急に荒れたりするリスクの海をうまく航海する全体的なやり方を知っているかどうか」の方が、実際の航海で難破しないためにはより重要ではないでしょうか。

どうもその後の展開を色々と見聞きしますと(復刊したPeoplewareでのデマルコの皮肉とか)、多くの方が「CMMはヨットレース」とおっしゃっているように思えます。
濱井さんのご発言を拝見する限り、大体似たようなご認識なのかな?と勝手に思っています。

私はCMMを批評するほどCMMをちゃんと学習していません。
かなり前にCMMが注目され始めた時、以前こちらのリンク
http://village.infoweb.ne.jp/~fwgf2942/process/Proc.V1.1Pdf.html
からPDFが手に入るようになった時、内容を印刷して全て読んでみたりぐらいはしてみました。
今は同じくこちらの
http://village.infoweb.ne.jp/~fwgf2942/maim2.htm
このページ
http://village.infoweb.ne.jp/~fwgf2942/process/Proc.CMM-XP.html
も読んだりして、うーんと唸っています。
結局CMMとXPというテーマは私にはよく判っていません。

CMMって、まず型を重視して応用力を得る、と考えると何だか日本的/東洋的な意味合いもありそうな・・・白帯の新人はまず素振り百回!みたいな。
↑コーバーンさんあたりが好きそうな視点かも知れませんね。



=======================================
釘本浩樹 <kugimoto@....jp>
=======================================