vetteです。
長文注意！
長くなってしまいましたが、CMMについてコメントさせてもらいました。
今回の件は実はあまりXPとCMMの対立というわけでもないと
思っています。
まあ、何を重視したくてなにに同意して欲しいかということの
すれ違いかと・・・って当事者の一人が言うのもなんですが。
"hasegawa" <hasegawa@....jp> さんの
"[XP-jp:03137] ＸＰとＣＭＭ" (at 2002/01/26 13:48:08)について
> 私はその対立の一部が、スレッドの始まりにあたる「CMM vs XP」に
> あるような気がしています。それじゃ、今と何も変わらない
> じゃないか、というと、そうでもないと思っています。
> 少なくとも、このＭＬの主題であるＸＰにもっと関係してきます。
>
> 私は、ＸＰとＣＭＭは全く対立するものと考えています。
> 現場で実践する場合には、両方を同時に採用することなど、
> 到底不可能だとさえ思っています。
>
> ＣＭＭは調査から構成されたものです。つまり、ある種の結果から
> 理想的なプロセスを導出しています。欠如していると感じるのは、
> 生きられた過程/構築過程というものが余りに客観的にしか見て
> いないと思えることです。これは、実際に実践した場合に、
> 様々な副作用とでもいえるものに出会うことになると思います。
いまさらCMMのことを説明するのもなんですが、CMMとXPは
かなりフォーカスが違いますね。
CMMはもともと国防総省が発注するプロジェクトが軒並み予算・期間
ともに超過したり頓挫しているのに見かねて、発注先選定の評価基準を
作ろうとしたのが発端です。
カーネギーメロン大ソフトウェア工学研究所が請け負ってまとめたのが
SW-CMM（ソフトウェア プロセス成熟度モデル）です。
5段階の成熟度モデルについては、クロスビーの「品質はただである」
（逆説的なタイトル）などから採用されたもののようです。
いちおういろんな成功・失敗組織から事例をあつめ、プラクティスも
あつめてきています。ただし、例としてあげてるだけで、CMMが
ポリシーをもって推奨するという改善ガイドではないんです。
ただ、調査結果からは、成熟度が上がると予測も的確になるし、
バグ検出や見直しなども早い段階で対処するので、全体的にスケジュール・
コストも改善される、ということになっています。
コスト改善よりも「ここに任せたら大規模な開発でもスケジュール遅延も
なく予定通り作れるだろう」と判定するための指標となっています。
（国防省から受注するにはCMMレベル3以上でないといけない）
というところまで聞くと
「俺らに関係ないんじゃないの」って感じがすると思うかも
知れませんが、確かにそうです :)
もとが国防省なので5年-10年単位の開発を対象としてますから、
「3ヶ月でカットオーバーしたい！」といった案件に単純に
適用できるものではないと思います。
CMMは開発手法そのものではなく、「プロセス」をチェックするもの
ですから、何が元の仕様・期間・スコープで、仕様変更があったときに
何がどう変わったかちゃんと抑えて顧客合意をとって上司にもつたわって
ますか？とかそういうことを重視しています。
なので、必ずしも変化に対応できないとか柔軟性がないとか
いうわけではないんです。柔軟性があるかどうか、ということも
気にしているわけです。
ただしCMMv1.1やCMMI v1.1のドキュメントを見ればわかりますが、
CMM自体が巨大で、なおかつ「じゃあ今俺は何をすればいいんだ」
という処方箋は書かれていません。
成熟度を上げるために重要なプロセスとゴール、それを達成する
ためのプラクティスの例はあるのですが、あくまでガイドです。
したがって、読んだからといってチームですぐに実践に移せる
わけではなく、全社的にやり方を改善するようなパワーがないと
難しいかも知れません。
CMMのアセスメントを受けようとしたら広範囲にクリアしていく
必要がありますが、現状プロセスで気になるところのプラクティスを
拾い読みするなど、ポイントを突いて読まないと圧倒されるだけです。
また、XPと違って、「現場をやる気の出るようにしよう」という
発想とは皆無ですから、いきおい管理面に圧倒されて、嫌気が
さすわけです:-)
(かといってCMMが締め付けやたくさんの文書を要求している
わけではありません)
即効性を求めず、かつ自発的に取り組む分にはXPと共存でも
問題はないんじゃないかと思います。
経営層から押し付けられた場合にはうまくいかないでしょう。
（XPを押し付ける経営層はいないかもしれないけど、
XPが押し付けられたらこちらも多分うまくいかないでしょう）
◆ ◆ ◆
ワインバーグがここ数年書き続けていた「ソフトウェア文化を創る」
4部作でもクロスビーをベースにした「組織の文化パターン」が取り
入れられています。
CMMでは「成熟度」ですがワインバーグからすると「それは組織の文化」
であり、スキルアップするのではなく文化を変えることだということに
なります。
（ちなみにワインバーグはCMMについては否定的）
「ソフトウェア文化を創る」は「コンサルタントの秘密」などに
比べると面白いエピソードは少なくて章ごとの課題もまじめに
考えると難しいのですが、品質とはなにか、人間関係の難しさ
（サティアの交流モデル）とか役に立つ本だと思います。
> ＸＰの主張の面白さは、これとは対極にあると思います。
> それぞれのプラクティスをそれ自体じっくり考えても、
> すぐに壁にぶつかります。しかし、それを開発の現場に
> 投入したとき、想像の域を越えた何かが起こるように思います。
> これは偶然ではなく、もともとＸＰは、想像では困難な
> 正の副作用を利用することを目論んでいたように思っています。
わたしはXPは「プラクティス」というよりは、マニフェストか
スローガンだと感じています。
テスティングなど、すぐに使えるプラクティスもありますが、
「そんなんじゃおもしろくないだろ、こう考えようぜ」と
言ってるように思えます。
全社的にXPを実践しているようになるとかはまだ想像できないし、
合わない分野や顧客文化もあるとおもいますが、
「当初計画がこうだからそれはできません」
「一番最初に約束したスケジュールに縛られて大変」
「ほんとにいるかどうかもわからない物を急ぎで作らされる」
といった後ろ向きなスタイルを出来るでしょうし、
全員がコミットすることによって参加意識を
高めようとしているのは評価できると思います。
XPがいっていることは、個別には前から実践されていた
ことも多いので、個々の主張については(個人的には）あまり
感銘は受けていないのですが、
１つのアジテーションとしてまとめたところに
意義があるのだと思います。
◆ ◆ ◆
せっかくなのでCMM関連情報：ここはXPのMLなのでCMMに特化した
話題を続けるひつようはないとおもいますが。
・SW-CMM V1.1の日本語訳
「ソフトウェア技術者協会」のSPIN分科会で翻訳したもの
http://www.iijnet.or.jp/sea/CMM/publish/CMM-J99.html
TR24 「ソフトウェア能力成熟度モデル 1.1版」
TR25 「能力成熟度モデルのキープラクティス 1.1版」
さきにTR24だけ読んだほうがよいです。
・CMMI v1.1(CMMI-SE/SW v1.1)
http://www.sei.cmu.edu/cmmi/products/models.html
英語です。CMMIはCMMの新バージョンです。
従来のモデルに合わせたstagedモデルと、SPICE/ISO/IEC TR 15504 に
あわせたContinuosモデルがあります。
ISOって言うだけで堅苦しそうな印象を与えそう :-)
経済産業省が官公庁の発注にCMMIレベルを使うとか言う「日本版CMMI」が
去年話題になりましたが、業界から反発を食らって出直しました。
・SEI著/アクセンチュア訳
「成功するソフトウェア開発 - CMMによるガイドライン」オーム社
書籍です。原題には「成功する・・」って書いてないんですけど。
後ろ半分はCMMの転載みたいなものなのですが、
前半はCMMの考え方やIBMのスペースシャトルの制御ソフト開発で
いかにバグ削減に取り組んだかという事例が載っています。
・Robert B.Grady/古山恒夫・富野壽監訳
「ソフトウェアプロセス改善 - コアコンピテンス獲得への
スパイラルモデル」共立出版
HPで採用しているプロセス改善手法の紹介です。
組織のソフトウェアプロセス改善にあたっては手当たり次第に
弱いところの成績をあげるのではなく、競争力のあるウリとして
なにをコアコンピテンスとするかという経営判断ともあわせて
改善していくべきという趣旨。
割と面白いです。メリハリにかけている気はしました。
PDCA（Plan-Do-Check-Action）の改善の試行〜結果の評価〜
他部門への反映というサイクルをベースに説明しています。
PDCAサイクル自体はここ独自のものではありません。
・Joseph Raynus/富野壽監訳
「CMMによるプロセス改善入門」共立出版
CMMにならった本ですが、もう、計測・計測の嵐です ^^;
CMMレベル4ってのは定量化して改善するのが目標ですし、
「体感」だけではなくほんとに有効に効いてるの?と確認するには
計測が大事なのはわかります。ただ、計測のためにデータを収集するのが
大変なのですが。（ちなみに私は苦手）
いきなりこれ読むとこんなことしたくない！って思いそうな本。
・坂本啓司（故人）
「"CMM" で陥りがちな "罠" を理解せよ」
（日経コンピュータ 2001/7/30号）
CMMに間違った期待をして裏切られたり、レベル認証取得だけが
目的化してしまって、本来社内で自発的にやっていたSPI(ソフトウェア
プロセス改善)活動を阻害してしまうケースがあるので、
「ここを間違うな」と注意を促しています。
----------------------------------------------------------
MORIOKA Toru 森岡"vette"徹
E-mail:vette@....jp