こんばんは、一條です。濱井さんじゃないので残念ですが、
----- Original Message -----
From: "Katsuya Higuchi" <bugbear@....nu>
To: <extremeprogramming-jp@....jp>
Sent: Wednesday, January 23, 2002 12:03 AM
Subject: [XP-jp:03069] Re: 生産量 (was CMM と XP)
> 樋口です。
>
> 結局のところ、「生産性を上げる」ということは、
> 「最小のコストで最大の効果を上げること」
> ですね。
>
> 「最大の効果を上げる」のを目指すのには、効果の計測が必要です。
> 「最小のコストで」というのを目指すためには、コストの計測が必要です。
最小のコストでというところを目標としないのが、ザゴール、ＸＰ流です。
また、計測も最低限にするのが理想なんです。
ぜひというのなら計測してもいいけど、それで生産性向上とかは言わないんです。
最大の効果だけを狙いコストは一定の枠を超えなければＯＫとするんです。
理想はほうっておきましょう。
いまさら、１００ｍ１０秒切るのは私には無理です。
ＸＰ本の記述を確認してください。
開発効率にあたるものは、ＸＰではベロシティにあたります。
ベロシティだけとってその数値が多いのが生産性が高いと判断するのは
間違いだとはっきり書いてます。
それは単に最初のストーリー時点での見積もり基準が違う傾向を
示しているだけかも知れないし、本当に開発効率が高いのかも
知れないからです。ただ、生産性向上の指標には絶対にするべきでは
ないんです。
単純にベロシティの値を多くしたいなら、理想日を多めにいえばいいからです。
それを学習することになんの意味もありません。
>
> 私は「効果」を「要件が満たされること」と考えています。
> そこで「要件の規模」で計測しようと考えています。
>
> しかし、濱井さんは、これを「売り上げ」で計測しようと考えているようです。
>
> 私は「売り上げ」はソフトウェア工学とは別のスコープだと考えています。
>
> 濱井さんは、
> 「コストを『生産量』と計測しているのはおかしい。」
> 「コストを計測すべきではない。」
> 「要件からはコストを推測するべきではない。」
> と考えているようです。
コストを生産量としているのはおかしい。−＞当然。
＞コストを計測すべきでない。
これは濱井さんは言ってないはずですね。
計測してもいいし、見積もりに役立ててもかまわないはずです。
ただし、請求する金の根拠にすることには、反対しているはずです。
ＬＯＣ、人月いずれも請求金額の根拠とすべきではなく、
そのソフトウェアで得たであろう利益を元に、
ソフトウェア開発の発注額を見積もるべきだということです。
Ａ社は、あるソフトウェアの開発をすることになった。
このソフトウェアを完成させることで、およそ１億円の経費削減ができる。
これにより、このソフトウェア開発に予算が下りることになった。
ついては、５０００万円で、このソフトウェアをある一定以上の品質条件で
ある期日までに納入してほしい。
手段はお任せするが、追加コストを払う気はないし、
期日を過ぎるのであれば、違約金をいただくことになる。
いかなる効率化を行っても、当社は一定以上の品質さえ確保されていれば、
文句はいわないし、値切ることも絶対にない。
こういうお客さん相手じゃないと、ソフトウェアビジネスはつまらないてことなん
じゃないかな。
ということで完全出来高払い制のほうが正しいってことですが、これならどうですか
？
> 私は
> 「現実にコストは必ずかかるものであり、測定が必要である。」
お好みでどうぞ。
> 「コストは要件(効果)の規模に自然と比例する。」
> 「以前の類似する開発の要件とコストの記録に基づき、
> 要件の規模からコストを推測できる。」
ご自由に。
> 「コストを減らすためにも、コストの測定が必要である。」
> と考えています。
コスト削減はセカンドな指標です。プライマリじゃないです。
コスト測定やるまえに、品質保証をやってください。
それよりなにより、使いやすさのような目に見えない価値を
きっちり作りこんでください。まぁ、そういうことです。
>
> 私の理屈で行くと
> 「物を作る前に、要件(効果)に対してコストを予測できる。
予測は予測です。危険率ちゃんと入れてますか？
もし余ったらお金返しますか？
超えたら、追加で貰いますか？
危険率大目じゃないと、受注自体危険な行為じゃないですか？
そもそも、一点で見積もれるのですか？
予測するのはいいんですがギャンブラーですね。
危険率大目ってのはつまりぼったくっているってことですよね。
機能仕様が流動的なのに、一点ですか。
すごいな、予知能力者だね。
僕なんて、車で吉祥寺から渋谷移動する時間さえ一点で予測できないです。
見積もり自体を危険行為だと判断する人は、
より小さい範囲のギャンブルを選ぶということです。
ＸＰのように小さい要件でということですが。
> これを元に事前に開発費用を予測できる。」
> 「開発費用に対して、予測される最終利益と比較をして、
> 開発すべきかどうかを判定することができる。」
総予算を提示するから、できるかどうか、
検討してくれってのが、望ましいスタイルでしょう。
開発コスト削減できるなら、がんばったね。
少ないけど報奨金だよというのが、正しい
ソフトウェア受注ビジネスだろうってことです。
> （ただし、要件がもたらす利益（最終利益)を予測するのは
> ソフトウェア工学とは別のスコープです。)
> 「同一の要件(効果)に対して、
> よりよいコードを書いてコストを削減することで、
> 生産性が上がったことが測定できる。」
> ということになります。
リファクタリングは、ＬＯＣベースでは、マイナスの生産性なのですが、
コスト計測でどういう扱いを受けるのでしょうか？
>
> 濱井さんの理屈で行くと、
> 「物が出来上がってから、やっと要件がもたらす利益が計算できて、
> 利益を開発費用として支払ってもらえる。」
これは違いますね。
先に予想利益をもとに総予算を出してもらって、
あとは、報奨金か罰金になるモデルでないとはまらないでしょう。
> 「どんなに物を作っても、売り上げ予測が外れてまったく売れなかった場合には、
> 生産性が非常に低い。」
同一会社では、そうなるでしょう。
開発組織の効率が十分で、企画サイドがだめだというのは、
お互いの責任転嫁以外のナニモノでもないですね。
保身のための数字遊びが必要だというのなら、
別にやるなとは言いませんけど。
> 「同じコストでも、もっと儲かる要件を見つければ、生産性が上がる。」
> という、なにやらおかしな事しか測定できません。
おかしくはないです。
たとえば、同じ原価５００円のＴシャツでも、
プリントする柄がちょっと違うだけで、
原価ワレから、高級ブランドまで幅広い値段で
売られています。
ソフトウェアって、そういう知的なものでなければならないと
思わないのですか？
> 要件が決定できる立場にある人（企画、営業）としては
> 売り上げですべて決定できる
> (しかも、売れなかったら開発者に赤字をかぶってもらえばよい。)
> というのはとってもうれしい指標なのかもしれませんが、
> ソフトウェア開発者の立場から見て、
> それがソフトウェア開発のどこに役に立つのかさっぱり分かりません。
先に総予算を提示してもらうモデルだと思うので、
開発効率あげればあげるだけ、稼げるはずです。
問題ありますか？
お得意の予測がうまく機能すればもっと稼げるでしょう？
あなたにとっても魅力的ではないですか？