みかまま、こと大月＠佐賀大学です。
先日、良く分からないままにTOCについて1時間半程度喋って来ました。
http://www.cs.is.saga-u.ac.jp/lecture/others/TOC20021010.pdf
に資料のPDFを転がしてあるので、どうぞ。単に以下の解説本のダイジェスト
なんですが。
「在庫が減る！利益が上がる！会社が変わる！ 会社たて直しの究極の改善手
法TOC」ISBN4-8061-1595-9
で、本題、ソフトウェア開発の生産性をどう定義するかですが、たとえばソフ
トウェア工学のファンクションポイント法では、「仕様に基づくソフトウェア
の複雑さ」をファンクションポイント(FP)とし、これをどのくらいの人月で処
理できたかを生産性とみます。
つまり、インプットとしての仕様を「ソフトウェアの複雑さ＝ファンクション
ポイント(FP)」で計量しておき、アウトプットとしての製品が出てくるまでの
時間で割ることにより、その処理の生産性をFP/時間とするわけです。
一般にエンドユーザアプリケーションだと、平均35FP/人月、軍需ソフトウェ
アなどだと1〜5FP/人月などと言われています(アメリカで)。
詳しくは、「ソフトウェア開発の定量化手法 第二版」ISBN:4-320-09722-Xを
ご覧下さい。
From: Toshihiko Honma <t-honma@....jp>
Subject: [XP-jp:03823] Re: 無意味なソフトウェア開発生産性の計測
Date: Tue, 15 Oct 2002 15:32:19 +0900
> 私が言いたいのは、他部門に影響を与えないような生産性向上も可能だし、ソ
> フト開発の生産性が向上したか確認するためには、ソフト開発のみに注目した
> 生産性の測定も必要ではないですか？というものです。
私はむしろ、TOCでいうところの制約条件の改善のためにこそ、正確な生産性
の現状把握が必要ではないかと思います。どこがボトルネックになっているか、
把握することなしには、改善することができません。ソフトウェア開発がボト
ルネックになっていなければ、その時点では改善する必要がないかもしれませ
んが、それはまた別の話です。
> XP（とかCMM）を導入し、今までより短時間で、正確に、（今までと）同程度の
> 開発（機能）量を実現できた、といった場合、「生産性が向上した」と表現す
> るものとばかり思っていましたが、これは違うということでしょうか？
ソフトウェアの生産性は計りにくい面があるので、却って誤った計測をしてし
まい、その弊害の方が大きくなる(方針制約になってしまう)というのは確かに
あります。正しい計測法を選ぶのは非常に重要です。
たとえば上にあげたFP定量化手法として妥当かどうか、というのはもちろん検
討されるべきです。個人的には悪くはないと思ってるんですけどね。
とりあえず、つらつら眺めていてコメントしたくなったのは以上です。
さて、今日こそ「チェンジ・ザ・ルール」が買えるかなぁ。
地方都市は入荷が遅い…
---
***>>> みかまま＃入門CVS 第２版：11月初旬発売！よろしく〜
***>>> mika@....com
***>>> http://www.mikamama.com/