CMM/CMMI導入・成功と失敗の分かれ目
http://www.atmarkit.co.jp/fembedded/special/cmmi/cmmi01.html
メモ．
例えば、工数と費用を精緻に見積もろうとすると、それなりの工学的な手法が必要になる。それまでカンで見積もっていた現場へそうした手法を押し付けても負担になるだけだ。
この書き方だとカンで見積もる方式よりも，より高い精度で予測できる工学的手法が存在するかのように見える．しかし，現実には未だに「精緻に見積もる工学的手法」などというものは実用化されていない．また近い将来においても実用化される可能性もまずない．
つまり実質的にCMMIの内容は空っぽなのである．
徹底したレビューが手戻りを防ぎ、QCDを向上させることは、開発経験者なら誰でも知っていることだ。
嘘ではないが，正しくもない．
まず第一に，十分に優れたコードでなければレビューの意味はない．優れたコードにさらに磨きをかけるなら意味があるが，スパゲッティプログラムに対してはレビューは無力なのだ．
第二に，コストパフォーマンスの問題がある．ソフトウエア的にコンパイルエラーで除去できればコストはほとんどかからないが，優秀な開発者を一定時間拘束すると，それなりの人件費がかかる．これが行きすぎると人件費は二倍にも三倍にも跳ね上がる．数倍の開発者をレビューに割くのなら，その開発者で開発したりやユニットテストを作ったりした方が遙かに生産性は高まる．なにが悲しくて時代錯誤な人力デバッグに逆戻りせねばならんのだ．*1
第三に，たとえ一定レベルまで作られた後でレビューして問題が分かったとしても，既に手遅れであることが少なくない．細部の修正で済むなら良いが，そうでない場合は問題が判明しても選択肢は作り直すかそのまま進むかの二つに一つ．多くの場合は作り直すのはコスト面でも納期の面でも現実的でないため，後者を選択せざるを得ない．しかも問題が本質的且つ重大なものであるほど，そうなる可能性は高くなる．
第4に，社内の政治的／マネジメント的な問題がある．たとえ問題が明らかで多くの技術者がそれを指摘していたとしても，その失敗を認めることは時として管理職の失態となる．管理職としては自分の失敗を認めるよりは，問題を先送りにして責任を有耶無耶にするという方を選択する者もいるだろう．
さらに悪いことに、「決裁者」はその状態でも彼を信じていました。当時の内部レビューで激しくプロジェクトに問題があることを追及されたにもかかわらずです。
実は、この光景もよくあることなのかもしれません*2。決裁者にとっても、自分の推薦した人物（会社）が結果を残せないのは、直接的ではないにせよダメージ（責任）となります。またすでに終了してしまった作業の「価値」に目をつぶり、捨ててしまうのも容易ではありません*3。ですからその人物なり会社なりを簡単に「切る」わけにはいかず、対策は「ハッパをかける」にとどまってしまうのです。顧客も異変には気付いていました。顧客が営業に強い不満を漏らしたこともありました。その際には「営業」は彼の「黄金のスキルシート」を片手に取りあえず「その場だけ」は、事態を収めたのです。
http://www.atmarkit.co.jp/farc/rensai/heaven03/heaven03b.html
本来ならこのような会社に対する背任行為は許されるものではない．しかし実際には，個人の利益と会社の利益が矛盾する評価制度を採用していることは少なくない．
開発生産性は500step／人月に達していない。800step／人月はいくエンタープライズ系の6割程度しかなかった。
ナンセンス．全く異なる性質を持つ異なるものの開発を字面だけで比較することには，なんら意味はない．*4
それでも最近、組み込み業界から「CMMIは使えない」という声が強まっているのも事実である。
それは最初からだろ．
正確には「やっぱりCMM/CMMI/PMBOKは使えなかった」というべきだ．
現場の開発者は、CMMIによるプロセス標準化と聞くと、決まり事や提出文書が増えると考え、嫌がるものだ。
「プロセス標準化」？一定品質，且つ最低品質に標準化されることを，エース開発者が喜んで受け入れるとでも？最低開発者にとっては痛くも痒くもないかもしれないけどね．
開発者がCMM/CMMI/PMBOKのような画一的管理手法を嫌悪する理由は，CMM/CMMIによって生産性や品質が下がるからだ．それこそ劇的に．ほとんどの開発者にとっては足枷でしかないものを，喜んで受け入れるわけがない．
その半面、プロジェクトの立ち上がりは確実に速くなる。必要な資料やテンプレートがリポジトリ化され、WBS（作業分割構成）も定義される。開発者の負担を減らす面もあるのだ。
ウソをつけ．
役にたたないし使いもしない書類を量産することに何の意味がある．作業分割にしろ意志決定にしろ，真に求められているのは最適な作業分割であり最善の判断だ．ただ単に決めるだけならバカでもできる．
CMMIに取り組んだ開発者の多くは、『もう前のスタイルに戻りたくない』と話している。
エース開発者が全員辞めて，最後には最低開発者が残ったからでしょ．時給幾らで働くなら，生産性が低ければ低いほど開発者は儲かる．*5
ちなみに，私は「金輪際二度と御免だ」派です．おそらく真っ当な開発者ならほとんどがそうだろう．
CMMIそのものが組み込みソフトウェア開発に向くか向かないかという議論は、あまり意味がない。
ある意味ではその通り．
「CMMIは組込みに限らずソフトウエア開発全般に向いていない」．組込みにむくか向かないかという議論をするまでもない．
*1:これはほとんど拷問．賽の河原の石積みと同じ．それが何も生み出さない無意味な作業ほど，人のやる気を削ぐものはない．
*2:おそらくそうだろう．私も実際に見たことがある．
*3:この問題は，コードも満足に読めない管理職が廃棄されない限り無くならないだろう．財務諸表も読めない経営者が論外なのと同様に，コードも読めない管理職はソフト開発の現場には必要ない．
*4:「遙か昔から米国の戦闘機は超音速を出していた．これに比べて我が国の自動車は一部の例外を除き時速100km程度しか出ない．これは我が国の自動車産業の開発プロセスが米国より劣るからだ．」というのが，いかにナンセンスであるか言うまでもあるまい．
*5:あなたの会社で優秀な開発者が辞めていく現象が見られるとしたら，この可能性を検討してみることをお奨めする．もちろん業績悪化など他の理由で辞めていく場合もあるが，会社の業績自体が好調であるにも関わらず辞めていくとすれば，疑ってみるべきだ．
開発者自身はCMM/CMMIが役に立たず，開発者の生産性を下げる足枷であることを知っている．しかし一般的に言って管理職にはそれが理解できない．理解するだけの技術力がない．書類が沢山作られて，「これが科学的な手法だ」と言われれば，それを信じる愚か者もいるだろう．まるで「裸の王様」のようにね．そうなると開発者にできることは限られてくる．黙って辞めるか．上司に逆らって首になるか．だいたいはそんなところだ．
