----- Original Message -----
From: "MORIOKA Toru" <vette@....jp>
To: <extremeprogramming-jp@....jp>
Sent: Friday, January 25, 2002 1:12 AM
Subject: [XP-jp:03114] Re: 生産量 (was CMM と XP)
> vetteです。
>
>
> "ishvar" <ichijo@....jp> さんの
> "[XP-jp:03110] Re: 生産量 (was CMM と XP)" (at 2002/01/24 23:17:03)につ
いて
>
> > 一條です。
> > 私が言ってもあれなんで、
> > デマルコのピープルウェア 新版のＰ．２４３の上段に書いておることをお読み
くだ
> > さい。
引用してよいのかどうか迷ったのですが、
お持ちじゃないのなら仕方ないですね。
「顧客によって最も価値のある製品を作る会社が競争に勝つ。
世界中の人があくびをするような退屈な製品を作る組織は、
これらを猛烈に効率良く作ったとしても、競争に負ける。
つまづきながら開発しても高い価値がある製品を作った
組織がたいくつなものを効率よく作る組織に勝つ。
プロセスはそれがやる価値があるプロジェクトじゃない
限りなんの意味もない。」
トムデマルコ ピープルウェアP.243上段より引用。
> >
> > また、整理しなおしますが、濱井さんが言っていたのは、
> > 「コスト削減を生産性向上というな。」
> > これだけであって、コストを計るなとも、
> > 見積もるなとも言ってないわけですから、
> > 手戻って議論を仕切りなおしてください。
> >
> > 少なくとも、効率化だけで生産性向上を図るべきではなく、
> > 必ず価値を伴って判断すること。
> > 価値のほうが優先順位が高いこと。
>
> たとえばどういうことを言われているのでしょうか？
> 現場の取捨選択については価値判断が必要でしょう。
> 常識の範囲です。
> 定量化（わたしは苦手ですが）や開発生産性を
> あげることを考えているからといって
> 「生産性マイナスになる作業は受け入れない」という現場があれば
> それはその組織の問題だと思います。
> もっともそういうのと頃では幸い仕事で出会ったことがありません。
>
> > この主張を認めるのならば、別に認識の相違はないことになります。
>
> 「一條さんの」生産性って何をさしてるのかわかりません。
> 相違以前に。
すでに数式で示したはずですが？なぜ？
生産性＝価値／コスト
ひょっとしたら期間で割ったほうが良いかも知れません。
受託組織だとするならば、
価値＝受託価格＊他部門控除率
他部門控除率は、社長の給料、愛人のお手当て、
総務、営業その他部門の費用、および家賃相当額などを
払うための一定の掛け率とします。
コストには、所属メンバー全員の給料。コンピュータ、ソフトウェアの購入費用、
書籍購入費用などが入ります。
>
> > 少なくともソフトウェア開発組織のテーマが
> > 開発効率の向上。
> > あと１０％ソフトウェア開発を効率化しよう。
> >
> > こういうテーマで部門全体が運営されていない場所にいることが重要です。
> > 大丈夫ですか？
>
> なんでこういう極論で反論したがるのでしょう？
> （顧客クレームの例も同様）
あなたの論理のテストケースだと思ってください。
テストでエラーが出るなら、論理に問題があるのは明らかでしょう。
>
> ほかの事は何でもいいから「生産性の数値をあげることが目的」
> だとだれがいっているんでしょうか。
>
> そして、価値が大事でないと言っているのは誰ですか？
少なくともあなたは、価値を単価と置き換えた発言で、
これは他部門の仕事で、私の所属する組織の仕事ではないと言いました。
少なくとも私の改善すべき指標ではないとね。
再度尋ねますが、価値を評価するのは誰ですか？
そしてそのフィードバックとして、
開発組織は、どういうアクションをとればよいのでしょうか？
開発組織が、そのフィードバックを改善するための
指標を持たず、生産性向上のための指標だけは
あるとするならば、おかしな組織に
なっているのは自明ではないのですか？
ちなみに単価・価値をあげるための方策の一例は、
教育投資を行うだったり、
得意分野に徹底集中だったり、
ヤバイ仕事に手を出すだったり、
顧客満足度をあげて単価をあげるようにするだったり、
世紀の発明に部門としてチャレンジするだったり、
開発組織側で解決できる方法はいくらでもあります。
あなたの仕事ではないかも知れませんけどね。
ただまぁ、あなたのいらっしゃる環境は比較的健全らしいので、
おそらくひどい目にあったことがないだけなのでしょう。
ＣＭＭが入ってきても変わらないことをお祈りだけしておきます。
>
> わたしは、「生産性を規模ではかるのではなく金額ベースで測るべきべき」
> というテーゼに対して、
> 「各工程生産性は規模ベースで考えないと制御できないでしょう。
> 全体の見積もり（売値じゃないですよ。原価の見積もり）も
> それの積み上げがベースになるでしょう」
> といっているのです。
ちなみに、濱井さんはそれを行うための尺度として、
いつ正しい意味の生産性を使うべきだといったのですか？
「ソフトウェア工学の世界に持ってくるために、
生産性の定義をねじまげたのが問題なのだ。」
そういう主張に対して、なぜそのような疑問が出るのでしょうか？
わたしにはさっぱりわかりません。
>
> これに対して是とも否ともコメントをいただいていません。
>
> たとえば例の1億の価値のための5000万の案件提示に対して
> （私が書いたのは多くのやり方のうちの1つですが）
> 「価値が一番大事」といわれる一條さんは
> どのような見積もりと提案をされるつもりでしょうか。
> 価値、ではみつもれねーだろざまーミロというのではなく
> どういう見積もり根拠になるんだろう、というのが気になります。
というより、正確な話としては、
あれは、ＣＭＭ向けに書いた例題にすぎません。
単なるゲームの構図を示しているだけなのです。
つまり、あの問いかけの真の意味は、あなたが
どういう態度でゲームに挑んでいるかがわかる
リトマス試験紙でしかないんです。
（約一名完全に落ちこぼれましたけどね（爆笑））
グリーディな発注者なら、５０００万円ではなく、
もっと値切るでしょう。原価ギリギリまで、買い叩くでしょう。
あるいは、ほとんどの機能ができた版を、受け取り、
一定品質を満たさないというケチをつけて支払わないでしょう。
グリーディな受注者なら、５０００万円で、
体面がぎりぎり保てるラインまで作り、
残り５０００万円のギリギリまで、搾り取ろうとするでしょう。
ＸＰとＣＭＭのポジションの違いというのは、
ゲーム理論における共生プレイヤーを目指す戦略をとるか、
どうかの違いであり、すなわちスピリットの違いだというのが、個人的な結論です。
さて、金額で見積もれないのかについてですが、
各機能要件ごとに個別に値段をつければ一緒でしょ。
総予算を超えているなら、オーバーコミットです。
機能を削らせないとだめですね。
各機能要件の値段つけは、開発参加者で
入札ゲームでもやれば、もっと怪しい感じでよいでしょう。