Index: [Article Count Order] [Thread]

Date:  Wed, 19 Dec 2001 14:25:08 +0900
From:  ono@....jp
Subject:  [XP-jp:02914] Re: CMM と XP
To:  extremeprogramming-jp@....jp
Message-Id:  <20011219142508P.ono@....jp>
In-Reply-To:  Your message of "Wed, 19 Dec 2001 10:03:51 +0900"	<200112190103.KAA18814@....jp>
References:  <200112190103.KAA18814@....jp>
X-Mail-Count: 02914

小野です。 CMM を含めた開発プロセス全般と、金銭的利益の話です。
あと Goldratt 話。

>> Regarding [XP-jp:02909] Re: CMM と XP; k-hamai@....com adds:

 > 濱井です。
 > [XP-jp:02862]でこう書いているのですが。

hamai> CMMが箸にも棒にもかからないものなら、これほど推進されないでしょう。
hamai> ある程度の利点はあると思います。ただ、ある程度以上ソフトウェア開発
hamai> 組織を改善しようとしたら、むしろ足枷になると思います。

>>> 手段は目的をかなえるためにどれだけ役立っているかで評価されます。
>>> 目的からの観点のない評価はほとんど無意味です。
>>> CMMには、この「目的からの観点」が抜け落ちています。
>> 
>> 工場がどれ位の品質の商品を作れる可能性があるのか。
>> と、商品がどれ位役立つのか。
>> を比べてどうするのですか?

 > そんなことは言っていませんが?
 > ソフトウェア開発は、その目的のためにどれだけ貢献しているかで
 > 評価されなければならないと言っているだけです。

 > 『ザ・ゴール』の55ページに「どんな会社であっても目標は同じだ。一つ
 > しかない」とあるように、企業の目的(目標)は本質的には一つです。
 > 66ページにあるように「企業の目標はお金を儲けること」です。

余談ですが、『ザ・ゴール』の著者 Goldratt の最新作 "Necessary but not
sufficient" はまさにSCM やERP のパッケージソフトウェア会社が舞台です。

ちょっとネタばれしますが、ストーリーの骨子としては、ソフトウェア開発
部隊の生産性の問題だと思われていたものが、実は使用する側の問題だった
というものです (IT は「必要条件」だが、金を儲けるための「十分条件」
ではないということがメッセージです)

ま、それはともかく


 > お金を儲けることが企業の目的であり、一時的ならともかく、長い期間
 > にわたって儲けることができなければ企業は存続できません。

 > ソフトウェア開発もお金を儲けるための手段にすぎません。パッケージ
 > ソフトとしてどれだけ売れたか。そのソフトを使ってどれだけコストを
 > 削減できたか。そういったことで、まず評価されるべきということです。
 > しかし、CMMはそうなっていません。

「お金を儲けること」と品質との関連について:

品質にも二通りあると思います。プラスの価値を与える品質と、マイナスの価
値が「無い」という品質です。携帯電話を例に取れば、
	- i-mode でWeb が見れる、
	- カラオケができる(?)

などはプラスの価値を与える品質といえるでしょうし、
	- 通話が切れることが「ない」
	- バッテリーがすぐ切れることが「ない」
	- 重くて負担を感じることが「ない」
	- 長く話しても通話代が高くなら「ない」
	- 誤操作をしてもメモリーが消えることが「ない」(ぉぃぉぃ)

といったものは、マイナスの価値がないことが品質となっているわけです。

そして、どちらも売上に貢献する可能性があります。プラスの価値としての品
質は、あたればでかいですが、 (濱井さんの言う「爆発的売れ行きのパッケージ」
などはこれに入るでしょうね)、顧客が気付いていないニーズを喚起しなくては
いけないため、宣伝が大変になります。

マイナスの価値が無いという「品質」は、宣伝に金をかけなくても広まります。
なぜなら顧客自身が問題をすでに認識しているからです(「バッテリーの持ち
が良い」携帯電話の営業と、「カラオケができる」携帯電話の営業では、前者
のほうがラクでしょう)。そのかわり売り上げへの貢献は限定的です。

私は、CMM を含めたソフトウェア・プロセスは、全てこの「マイナスの価値が
無い」という意味での品質に貢献するものであり、それ以上ではないと考えて
います。そしてこのようなソフトウェア・プロセスを導入しようとする組織は、
その「マイナスの価値が無い」ことが、自分達の利益にどれだけ貢献するかを
考える必要はあるでしょう。その意味で、CMM それ自体に、この「目的からの
観点」が抜け落ちていることは濱井さんに同意します。

ただしこれを、CMM を含めたプロセスの瑕疵だとは思いません。自らの適用範
囲を限定しているわけで、謙抑的だといってもよいでしょう。

 > CMMの基準からすると、全く売れないパッケージソフトをコストや開発期間
 > が予定どおりに開発したケースの方が、爆発的売れ行きのパッケージ
 > ソフトをコストや開発期間が予定を大幅に超過して開発したケースより
 > 評価が上ということになります。会社が儲かるかどうかより、開発コストや
 > 開発期間が予定どおりかどうかの方が重要なのです。
 > これでこのまま突き進むと、会社は潰れてしまいます。

「爆発的に売れる」原因は、プラスの価値を創造したことにある場合
が多いと思います。その場合は、CMM を含めた開発プロセスの貢献は
無いし、あったとしても偶然的でしょう。(別のメールにあった Visi
Calc の例など、プラス価値の創造にあたるのでは)

しかし、マイナスの価値が無いという意味での品質が売り上げに寄与
しないと言うこともありません。今でこそ携帯電話は多機能化がアピー
ルポイントになっていますが、初期の頃は、今度の新製品は「重くな
い」「切れない」「高くない」というあたりをアピールしていたと
思います (ヘヴィーユーザーじゃないので、よくわからんですが)

CMM でもなんでも使って、ソフトウェア製品のマイナスの価値 (落ち
る、誤動作する、変更の度にバグがでる) を減らし、その事実を売り
上げに結び付けるスキームを作ることは、そのプロセスを導入する人
達が、CMM とは関係なく自分でやるべきだと思います。
(XP だと「ビジネス側」の人間のやることになるのでしょうか)

----------
ちなみにこのプラスの価値、マイナスの価値という話は Goldratt の
第二小説"It's not luck" からパクったものです。この小説では「ザ・
ゴール」の主人公Alex Rogo が、「マイナスの価値がないこと」とい
う意味での品質を高めることで3ヶ月(またかよ!)で会社の収益を改
善して、ぎりぎりで危機を脱するという話です ^^;;

// Tsuyoshi ONO // 
e-Communications Dept, Telecom & Service Company /  SONY Corporation 
email: ono@....jp
"Be completely flexible on how we get there, but be totally 
 uncompromising on where we are going." -- Martin Fowler