みかまま、こと大月＠佐賀大学です。
まず、言っておきますと、
「ソフトウェアの生産性」を「企業の目的」とするのはナンセンスであると思
います。
小さなソフトウェア会社であれば全体の生産性向上になるかもしれませんが、
当然市場制約なども考慮しなければなりません(売れないものを作ってもしか
たがない)から、生産性自体が「企業の目的」であってはいけません。
> ソフトウェアの開発そのものは、「在庫」を増大させるだけで「スループット」
> を増大させません。企業の目標である「お金を儲けること」に直接貢献する
> わけではありません。
それが濱井さんのおっしゃりたいことだと思いますし、それについては賛同致
します。
> ソフトウェアの開発もハードウェアの製造もそれ自体がお金を産み出すわけ
> ではありません。TOCにおける増やすべき指標は、「スループット」であって、
> 「ボトルネックの通過量」ではありません。
ですが、スループットを増大できる状態(市場制約がなく、生産量より受注の
方が大い)においては、ボトルネックを特定しその制約を最大活用しなくては
なりません。そのためには、何らかの形で各処理工程の生産量について定量化
を行い、どこに一番時間がかかっているか判断しなくてはなりません。
いわゆる、物理的制約の改善プロセスの為に、です。
そういう観点から、ソフトウェア開発の生産性を計る必要があるでしょう、と
言っているだけです。
> 「正しい仕事は何かが正しく定義され、評価されなければ、誰も正しい仕事
> などするはずがない。会社に損失を与えてきたのは、人間が正しい仕事を
> 行わない『仕組み』をつくりあげた会社組織そのものである」という考え方
> がTOCの根底にあるのです。
繰り返しになりますが、
「ソフトウェア開発生産性に基づくソフトウェア開発工程の部分最適化が目的に
なってしまう」
のには私も反対です。
しかしながら、ボトルネックの特定という意味でソフトウェア開発工程の生産
性を計る必要はあるのではないか、と思います。
なお、ソフトウェア開発工程の生産性の定量化は難しい課題で、現在提案され
ている計測方法とその運用にはまだまだ課題は残されているかとは思います。
「何を計るべきか」を取り違えて導入すると、それこそ酷い事になるでしょう。
最終的な製品を作り上げるために、ソフトウェア開発工程で何を作るべきであ
るのかを定義して、それが必要量生産されうるかだけを見るべきでしょう。
言い換えるなら、たとえば必要以上に詳細な文書がいかに無駄な仕掛在庫であ
るか、を示すために定量的評価が必要なのではないでしょうか。使われる予定
のまだない仕様・設計・コードも余分な仕掛在庫でしょう。XPの興味深いのは
そのあたりを削減しているですが、現在のところ直観的にそう判断できるに過
ぎません。
実際にどの程度仕掛在庫を減らし、「必要なものを必要なだけ」作っているの
か、が示せると非常に面白いのではないか、と考えます。管理者・経営者を説
得する理論的根拠にもなりうるでしょう。
そういう意味で、FP法は文書化コストも計れるようなので、なんかできないか
なぁ、とつらつら考えていますが、どうなるやら。計り方がなぁ…。
ひとまず以上。
---
***>>> みかまま
***>>> mika@....com
***>>> http://www.mikamama.com/