第275回: 「CMMIのすすめ」3 (CMMIが用意した仕掛け 前編)
◀前の記事へ 次の記事へ▶︎
≡ はじめに
前回は、「CMMIの目的」について書きました。
一番大事な箇所を再掲します。
これらの目的を実現するために必要なことは、「ソフトウェア開発で統計的手法を活用できるように土台をつくる」ことです。
「毎回、創造的で革新的なものをつくることがソフトウェア開発である」という意見は正しいものです。だから、ソフトウェア開発は挑戦的でワクワクする仕事です。
しかしソフトウェア開発の全てのアクティビティが創造的な活動かというと、そうとばかりは言えません。例えば「バグ修正前のバージョンに先祖返りしてしまって大変なことになった」経験を多くのソフトウェア開発者は持っています。
ソフトウェアの構成管理は、地味で創造的なアクティビティではないけれど、ソフトウェア開発の活動のなかで重要なものです。
そして構成管理のような安定したプロセスに対しては統計的手法が使える(日々チェックするものを決めて、〇〇のタイミングで構成管理プロセスの監査をすれば先祖返りの問題をほとんど起こさないようにできる)ということは想像できると思います。
「ソフトウェア開発のなかで真に創造的な活動に自分の能力をフル活用するために統計を使うことで楽ができる部分には使っていこう」というのがCMMIの主旨です。
決して創造的でワクワクする活動をよく分からないメトリクスで縛ることではありません。それはCMMIが目指すゴールとは真逆の方向です。
今回のテーマは、上記について具体的にどのような仕掛けをCMMIは提供しているのかです。途中までだけど。
≡ CMMIの仕掛け
❶ ステップアップの仕掛け
TQC(Total Quality Control: 総合的な品質管理手法)を行うためには、「統計」が適用できることが絶対条件です。
というのは、TQCは、その前のSQC(Statistical Quality Control: 統計的品質管理)の拡張版だからです。
上の図は、SQCとTQCとTQMの関係を表したものです。1950年と1980年を区切りとしています。
実際にはそんなにはっきりとした区切りはありません。
まず、TQCの始まりを1950年としていますが、この年にデミングが日本で講義(第1回デミングセミナー)を開いたといった程度の意味です。
その後もSQCとオーバーラップしていますし、当時は単にQC(もしくは品質管理)と呼ぶことのほうが多かったと思います。
TQMの1980年はもっとあいまいで、「アメリカでは、このころからTQMと呼ぶ人が増えた」程度の意味です。
日本では、1996~1998年に日本科学技術連盟のなかでTQM委員会(にしさんの師匠の飯塚先生がリーディングされていました)が活動し『TQM宣言』という小冊子を1997年に発行しました。
TQMの訳語も当時は「総合質経営」でした。この訳語は流行らなかったけれど志は高いですし、日本の品質管理の狙いが分かるので、『TQM宣言』は入手して読まれることをおすすめします。
色々と書きましたが、呼び方がSQCからTQCにそしてTQMに変わって現在に至るという事実のみ抑えておいたらOKです。
上の年表は実感と近いものです。図の下の方にある「MB賞」とは、マルコム・ボルドリッジ賞のことですが、アメリカが日本のデミング賞の成功を真似て作った賞です。日本の企業もとっています。
また、図中の「日本経営品質賞」はCSRとかを含めて、企業活動を網羅的に定義しているものです。日本経営品質賞では、以下の項目が審査されます。
日本経営品質賞については、毎年「アセスメント基準書」が改訂され、販売されていたのですが、今見たらユーザー登録するとダウロードできるようです。
経営コンサルをする機会がある人はよくまとまっているので(と言っても解説が必要だけど)見ると良いと思います。
企業活動のフレームワークとして最もよく出来ていると思っています。ベンチャー企業は特に自社の活動の抜け漏れを「日本経営品質賞のアセスメント基準書」を使用してセルフアセスすると良いと思います。賞の獲得はしなくていいから。
いずれにしても、SQC/TQC/TQMは品質マネジメントの体系的知識です。そしてその核となるものは「統計」です。なんといってもSQCはシューハートの統計的管理図(1924年)に始まるわけですから。
ということでCMMIの仕掛けの1つ目は「統計を使えるようにする」仕掛けです。
ほとんどの統計技術はプロセスが安定していなければ使えません。そこで、CMMIでは、まずは、管理図を使うことで、そのプロセスが安定しているかどうかを調べます。
そして、安定しているプロセスに対して統計を使います。
まとめると、「レベル3を達成するためには標準化を行って、“標準プロセスマニュアル”を作ってそれを使うことでプロセスを安定させる」、「レベル4では、安定したプロセスに対して“統計手法を使用して予測、制御”する」、「レベル5では、レベル4の活動成果がプロジェクトの成果にとどまらず事業成果に結びついている」というように組織能力を段階的に成熟させたら上手くいくとCMMIは言っています。
❷ モデルを使う
「CMMIのレベル〇に組織の能力が成熟したことが認められ、ISACAのウェブサイトにその結果が掲載される」ことを一般に「CMMIのレベル〇を達成した」といいます。
言い換えると、CMMIでは、「組織の能力を向上する」(SPI: Software Process Improvement(ソフトウェアプロセス改善))と「組織の能力が向上したことを評価する」(SPA: Software Process Assessment(ソフトウェアプロセス評価))2つの活動が必要です。
CMMIモデルを実現するとは、モデルに「〜を確立しなさい」と書いてある個所について組織のやりかたを文書として標準マニュアルに追加し、「〜を維持しなさい」と書いてある箇所については、文書化した標準が実際に使われていることの証跡を記録し残すということです。
(アプレイザルではこれらができていることが確認されます)
CMMIでは、具体的に「XXをする」とは書いていません。ここでXXは手段や手法のことです。
そうではなくCMMIには、「YYが出来ている状態になってください」「状態になったかどうかはZZの価値を発揮しているかどうかで判断してください」と書いてあります。ここで、YYは活動(プラクティス)のゴールで、ZZはYYという状態になるための活動(プラクティス)が提供する価値です。
この部分はとても大切なので、次回に丁寧に書きます。
❸ アプレイザル
こちらも次回書きます。
≡ おわりに
今回は、「CMMIが用意した仕掛け 前編」をテーマに書きました。
次回は後半(❷の詳細と❸)を書きます。