見出し画像

第274回：　「CMMIのすすめ」2　（CMMIの目的）

Kouichi Akiyama

◀前の記事へ　次の記事へ▶︎


≡ はじめに

前回は、CMMIの各種情報へのリンクと私の経験について書きました。

今回は、「どうしてCMMIなんてやるの？」（Duolingoで言えば、「why do you challenge cmmi」）です。「CMMIの目的」について考えてみます。

前回以下に引用した発言を紹介しました。私が2001年に聞いた、今でも尊敬しているソフトウェアエンジニアであるSさんの主張です。
これに対する今の私なりの考えを書きたいから。

「CMMのなかにある方法は優れています。でも、私たちは全ての工数をお客様に対して使いたいんです。レベル4を取るとなるとそちらに工数が取られます。そのなかにはやるべきこともあるけれど、レベル4を取るためだけにやらなければならないこともかなりあります。」

というのは、2001年のときには、上記主張に対して私は肯定も否定も何も言えず、ただただSさんの思いの強さに圧倒されていたから。

そのときには、20年以上も忘れられない発言になるとは思ってもいませんでした。



≡ CMMIの目的　①

「CMMIの目的は組織の能力向上」という答えはどうでしょう。
「どうでしょう」と言われても困ると思うのですが、私は悪くない答えだと思います。試験問題の解答なら丸をつけます。

先ほどTLに以下のツイートが流れてきました。もちろんジョークの一種です。

良品率を100%にすれば品管はいらなくなる、これは新たなソリューションなのでは？

「CMMIの目的は良品率100%」も悪くない答えだと思います。実際に今所属している会社の良品率はほぼ100%（自責本番障害件数：ゼロ）です。さらに、品質管理部もテストのみを行う部門もありません。開発者がテストをしています。

私が所属している事業監査部（CMMIのSEPGの役割も果たす部門）も少人数です。
公開されていないので、確かなことは分からないけれど、CMMIレベル5をとった組織のなかでは最少人数のSEPGなんじゃないかと思っています。

ですから、上記2つをまとめて「CMMIの目的は、開発部門の組織が持つ能力を向上し、スタッフ等の間接要員がいなくても、高品質のソフトウェアやサービスを生産性高く開発し、提供できるようになること」という答えも達成するゴールと戦略が盛り込まれていて良いと思います。

ゴール：　高品質のソフトウェアやサービスを生産性高く開発し、提供できるようになっている
戦略：　開発部門の組織が持つ能力を向上する



≡ CMMIの目的　②

上記の「CMMIの目的　①」に書いた答えで良いと思うのですが、今所属している会社で「本番障害ゼロ」や「スタッフ人数が少なく開発生産性が高い」ことは「CMMIに取り組んだから実現したのか？」と言われたら「だんじて否」です（←元ネタ忘れた💧）

少なくとも私が転職した2001年6月末時点で本番障害どころかテスト時もバグがほとんど出ていなくて、『CMMIのSEPGとして役に立たなかったとしても、テストエンジニアとして貢献できることがあるんじゃないか？』という当初の目論見はガラガラと音を立てて崩れましたし、それどころか、私が転職する前は「私がジョインした今よりも1名少ない人数でSEPGの仕事を回していた」（もっとも、私が入る数カ月前には別の人がいらした）のでした。
それに、漠然と「ソフトウェアの開発力とCMMIは別」なんじゃないかと思っていました。
「GoogleがCMMIに取り組んでいる」とも聞かないしなあと。これについては後（別の回）で「今はどう思っているか」について書こうと思います。

ということで、あらためて「CMMIの目的」について考えてみる必要が生じました。

・・・で、見つけた答えを一言で言えば、「TQCを始めるため」です。
一言ではなく3つで言えば、「予測可能性の向上(Improve Predictability)」、「制御の向上(Improve Control)」、「効率の向上(Improve efìciecy)」です。
（これは、私がまとめた3つではありません。オリジナルが見つからなくて出典を示すことができず、すみません。
私がまとめた3つなら、もっと自慢しちゃうんですけどね～（笑））


■　TQCを始めるため
TQCが何かについての詳しいことは書きません。
たくさんの書籍がありますし、ネットにも情報があります。たとえば、「こちら」は良くまとまっています。


第二次世界大戦後、日本が焼け野原から復興し、製造業において世界一の品質をもつ商品を販売し成功をおさめた要因のひとつがTQCで、その成功のキモは「全員が統計的手法を使用して合理的に考える」でした。


だから、1980年代になって、ソフトウェア産業が大きくなって問題が噴出したときに「ソフトウェアもTQCをしたらよい」という考えが生まれました。例えば日本では、「ソフトウェア工場」が生まれました。

ただし、現在「ソフトウェア工場」を見ることが無いことからも分かるとおり、「ソフトウェアもTQCをしたらよい」という試みは小規模なものから大規模なものまで、ことごとく失敗しました。

失敗した理由は単純で、上に書いたTQCのキモの「全員が統計的手法を使用して合理的に考える」といわれても、「ソフトウェアの開発に統計的手法を適用できなかった」からです。適用できなかった理由は前にツイートしたとおり「通常のソフトウェア開発は毎回創造的で、人依存で、開発言語や開発環境の影響も多く、同質のプロセスなんて無いから統計解析に使えるデータなんて少ししか取れない」からです。

それでも、クスマノの研究によれば、日本は桁違いに良い品質のソフトウェアをリリースしていました。

暫定データによれば、顧客へのシステム導入後12カ月で計測した1000行ごとの不具合報告で、日本は最も高い品質レベルにあった（中央値0.020）。インドのプロジェクト（同0.263）と米国のプロジェクト（0.400）は比較的近いレベルで、過去の基準に照らすと十分高品質と言えるが、日本と比較すると13～20倍のバグ発見率だ。

『ソフトウェア企業の競争戦略』pp. 281-282


「あなたは「バグ」をどう数えていますか？」より

マイケル・A・クスマノは経営学の先生ですから上記の報告も割り引いて考える必要があります。（私は正しい比較ができているとは思いません）

しかしながら、権威も実力も備えた教授の発言は説得力がありますし、当時の日本の製造業の商品の品質から類推して「日本ならきっとそうだよ」と「あのMichael A. Cusumanoの論文だよ」ということから、引用した通り「暫定データ」だったものがいつのまにか「赤文字で強調される事実」として広まったのも、むべなるかな。
本当のこととして広まってしまったのでしょう。

さて、CMMIの生みの親であるワッツ・ハンフリー（Watts S. Humphrey：今回のキャッチイメージの人）ですが、1959年～1986年の間、IBMでプログラム品質とプロセスの管理者をしていました。その後は、カーネギーメロン大学ソフトウェア工学研究所（SEI）においてCMMを創始し、ソフトウェアプロセスプログラムの基礎を築いたエンジニアでした。

そんなハンフリーがクスマノの数字を頭から信じたとは思えません。

しかし、「日本には何かある。その秘密の一つはTQCだ」と考えたようです。

また、当時、品質のコンサルタントの第一人者だったクロスビー（Philip B Crosby）の有名な『QUALUTY IS FREE』（邦題：クオリティ・マネジメント）の「品質マネジメントの発展」も知っていたと思います。

《品質マネジメントの発展》

　睡眠期－どうしてこんなに品質問題が発生するのかまるでわからない
　覚醒期－品質に関する問題は絶対になくならない
　知覚期－問題が明らかにされ解決しつつある
　充実期－欠陥予防は日常業務になっている
　定着期－品質問題が出てこなくて当然だ

『クオリティ・マネジメント』pp. 33-53

そして、この2つ（統計と段階的発展）を結び付けてCMMが誕生しました。

ハンフリーは「TQCをソフトウェアに適用するには、ソフトウェアに統計的手法を適用できる前提が整っている必要がある」と考えたに違いありません。さらに、ソフトウェアに統計的手法を適用できる前提を整えるためには、クロスビーが言うように組織が段階的に成熟する必要がある。よし、その道筋をつくろうとCMMを構築したのだと思います。

そして、統計的手法を使えない理由を「プロセスが安定していない」と考えて、それを解決するために「ソフトウェアではプロダクトのメトリクス管理だけではなく、プロセスのメトリクスを測定する必要がある」という結論となったのだと思います。



≡  おわりに

今回は、「CMMIの目的」をテーマに書きました。

なんでこんなことを長々と書いているかといえばCMMIを作った人の気持ちに近づくためです。
手法はなんでもそうですが、作った過程を理解しないとそれを正しく使いこなすことはできないからです。

ようやく準備が整ったので、次回は、CMMIの目的を実現するためにCMMIが用意した仕掛けについて書きます。さて次回こそ、連載のテーマ「CMMIのすすめ」について書くことができるでしょうか。

この記事が気に入ったらサポートをしてみませんか？