vetteです。
"ichijo" <ichijo@....jp> さんの
"[XP-jp:03095] Re: 生産量 (was CMM と XP)" (at 2002/01/24 1:01:28)について
> 単純にベロシティの値を多くしたいなら、理想日を多めにいえばいいからです。
> それを学習することになんの意味もありません。
見た目の数字だけ良くするというのはお互い（ってだれだろう:-)）
目指してないと思うですが、なぜ反論になるとそういうことを
言い出すのだろう
って人のことはあまり言えませんが。
> ＬＯＣ、人月いずれも請求金額の根拠とすべきではなく、
> そのソフトウェアで得たであろう利益を元に、
> ソフトウェア開発の発注額を見積もるべきだということです。
>
> Ａ社は、あるソフトウェアの開発をすることになった。
> このソフトウェアを完成させることで、およそ１億円の経費削減ができる。
> これにより、このソフトウェア開発に予算が下りることになった。
> ついては、５０００万円で、このソフトウェアをある一定以上の品質条件で
> ある期日までに納入してほしい。
> 手段はお任せするが、追加コストを払う気はないし、
> 期日を過ぎるのであれば、違約金をいただくことになる。
> いかなる効率化を行っても、当社は一定以上の品質さえ確保されていれば、
> 文句はいわないし、値切ることも絶対にない。
>
> こういうお客さん相手じゃないと、ソフトウェアビジネスはつまらないてことなん
> じゃないかな。
> ということで完全出来高払い制のほうが正しいってことですが、これならどうですか
これ、一括請負のきわめて普通のパターンだと思いますが、
こういうケースだと見積もりの正確さを高める努力や規模ベースの
生産性は重要でないという考えで例に挙げてるのでしょうか。
普通というと語弊があって、「一括請負の定義はこうである」という
ことであって、実際には「オーバー分の調整は・・・」というのが
ありますが。
発注側と受注側でどっちの視点に立つかによって違ってくると思います。
（また当該企業内のソフトウェア部門か、請け負ってる会社かどうかでも）
上の例では、その新システムのGOをだす人たちは、目標とする経費削減と
目指す売上げ向上効果から、（償却期間なども考えて）システム化に
投資できる最大予算枠を決めると思います。
ここでは当然、規模に基づく金額の見積もりはしないと思います。
システム化にかけられる予算はそのシステム化によるメリットとの
バランスから決めざるを得ないから。
それで外部のソフトハウスやメーカに見積もり依頼するとしたら、
自分たちが予算枠内で実現できることを考えて提案することになるでしょう。
ある会社は受注額が5000万なら原価2000万の範囲で開発することにして、
これぐらいの機能を持ったシステムを作ります、と提案する。
別の会社は同じ原価2000万でももっといいものを作れるかもしれません。
大手SIなら、強気で、7000万ならちゃんとしたものをつくります。
5000万では受けられませんね。ただし絶対遅れません。といってくるかも。
7000万のところに発注するかどうかは発注元がどの程度まで
妥協できるかによるでしょう。
（遅れたときに違約金もらってもしかたなくて、遅れないことが肝心）
発注側が5000万で出来ないかといっているのに7000万というのが
倫理に反しているとか挑戦する気概がないとか、私は思いません。
売る側（ソフト開発側）は「出来る範囲で出来ることをする」のです。
買う人が1億の節減だから、といっていちいち1億にあわせて値段を
決めたりはしません。
（もちろんもっとシステム部門に食い込んでたり、システム部門を担当している
会社なら別でしょうが）
提示された機能を期間内に実現するには、
「我々のスキルではこれぐらいの原価がかかってしまう」が見えてから
いかに魅力的なシステムにするか、期間・コストを抑えるかに
知恵を絞るものでしょう。
（抑えるっていってるのはもちろん際限なく最小を目指すということでは
なくて社内標準的な採算の損益分岐にちかいようにってことですが）
ここではじき出す金額は、自分たちが出来る能力と原価を見積もって
採算性を加味してだすわけで、ようするにコストがベースです。
原価のコストをそのまま受注金額に反映するわけじゃなくて、
仕様が変わったり（変えないといって変わらないことはない）その他
もろもろのリスクを加味して、赤字にならずガメすぎたりしないような
額にするはずです。
あとは品質や開発速度ををどうあげて、開発コストをどう抑えるかが
提案の差となってくるでしょう。原価を下げられれば受注した会社の
利益率が高くなります。
この金額は「このシステムでユーザが得るはずの利益や効果」は
もとになっていません。自分たちの能力がベースです。
ユーザの欲しているものにあわせてシステムの機能を高めたり
するかもしれませんが、お客さんも喜んだし、開発者も
満足したから原価4000万かかったけど請求は5000万でいいや、
なんてことはありえなくて（ごくたまにあっても続けられない）、
原価2000万で見積もった以上は要件が大きく変わらない限り
2000万に抑えるための工夫がいるわけです。
2000万で行けそう、というからには従来の(有効な)実績値を
ベースにして、今度も同じぐらい、とか、こういう改善で
もっと安く出来そう、とか考えるものでしょう。
そういうときには規模ベースの生産性（「ソフトウェア全体の生産性」
ではなく工程やプロセスべつの生産性）をいかに向上できるか、
いかに安定した速度で（＝予想できる＝見積もれる）開発できるか
が重要でしょう。
（途中で急に開発効率が上がったりすると見積もりしなおさないと
だめですね。開発速度や原価が予測より悪くなっても同じ）
---
なんかくどくど書いてしまいましたが、
要するに、ソフトウェアを受け入れる側は規模あたり生産性は
関心がなくてもかまわない。
でも作る側は請け負ったものを確実に作るためには
規模(なり機能なりストーリーなり）ごとの開発期間と工数を
予測することと、その期間と工数を小さくするための
工夫がいるわけです。
従来ソフトウェアの生産性として論じられていたのは
後者の話だと思っています。
ユーザ利益の視点は必要でしょうが、開発現場の「生産性」って
そことは結びつかないんじゃないでしょうか？
生産性あげることだけ考えてればよくてユーザ利益を考える
必要はないというわけではないです。
おれは創造性の高いことをしてるんだから、単純に人件費に
換算するな、ってのもあるかもしれませんが、そういう人なら
そもそも単価の扱い方も変わるものです。
べつに原価から売値を決めるといっても、単純に原価を
転化して売るわけじゃないし。よそより売りになるところが
あれば高めに売ることも出来るし。
パッケージなら販売本数とかから採算が変わってくるので
「これぐらい売れたらとんとん、あとは利益」でそろばんはじいて
値段決めるんでしょう。
で、こういう話すると「ソフトウェアはそういうものであるべきではない」
とか言うことになるんでしょうか?
別に現場の開発者全員が常にこういうことを考えながら
作業する必要はないと思いますけども。
----------------------------------------------------------
MORIOKA Toru 森岡"vette"徹
E-mail:vette@....jp