では、どういう方法でいいソフトウエアを作るかということになりますが、CMMでは手続きを重視します。Aを行い、Aが確実にできたのでBの作業を始めます。それが完了し、Cに移った時、何か問題が発生したとします。原因を突き止めたところ、Aの時の作業に問題がありました。となると、Aの作業に戻り、Bの作業を経てまたCを再開する。これを確実に行えるような仕組みを作ります。そして、その仕組みが確実に実施されていれば、できあがったソフトウエアの品質も良い、ということにしましょう、というのがCMMです。

A→B→CでCで問題が見つかり、C→A→B→Cというのは、別に目新しいことではなくて、どこのソフトハウスでもそれなりにやっているはずです。ここでは、どうやってそれをしっかり行えるかが問題です。どのソフトハウスでもそれなりにやっていると述べたのは、設計書にミスがあった場合、そのミスの部分を例えば口頭で説明して、まずは実装作業を先に進め、設計書の修正は後回しにするということがあるからです。

この場合、口頭の説明を誤解したり、作業をしているうちに解釈がずれてきたり、はいやります、と答えた後、別のトラブルがあって作業を忘れ単あまにしてしまったり、結果的に正しく反映しないことがあります。

このような例をCMMは許しません。とはいってもCMMの考え方に、そういう取り決めがあるわけではないです。CMMを実施する上で、いろいろ考えていくと、こういうやり方はよくないから、どんな人が担当しても、同じようにきちんと作業が進んでいくように組織を作り、良くないことがあればさらに組織全体で仕組みを見直していきましょうということがCMMです。

もう少し、詳しく述べますと、Aの作業の後、その作業のレビューをします。レビューで問題が見つかれば、重要度に応じて、再レビューをするか、修正後にドキュメントを関係者に再配布するだけで良し、とする場合もあります。重要な作業の場合、レビューではなくインスペクションだったりします。Bの作業でも同じ、Cの作業でも同じで、Cで見つかった不具合についてもやはり同じようなことをします。つまり「不具合発見→対処方法検討→戻り作業実施→戻り作業終了とレビューかインスペクション→戻り作業完了」が確実に進めます。これを怠ると、どういう問題になるかというと、不具合が解決されていないというステータスがずっと残ることになります。それは、定期的に開催されるプロジェクト会議で問題にされるのでプロジェクトリーダーとしては、いつまでも放っておくことができません。

なぜなら、プロジェクトリーダーの他に、そのプロジェクトを実施する部署以外に属する、プロジェクトをチェックするための担当者が存在するからです。

そして、このさらに上に、チェックする担当者が属する委員会があります。もしチェックを怠ったり、いい加減に実施して、後から問題が出た場合、そのチェック担当者は委員会から糾弾されることになります。ですから、「時間がないっていうならドキュメント修正は後回しでいいですよ」なんて口が裂けても言えない仕組みにしてるんですね。

こいうった仕組みは、CMMが決めているのではなく、CMMを実践することを考えると、こういう仕組みにするのがいいだろう、といった考えで作っているということになります。

チェックする人の名前もきちんとしたものがあるんですが、その名前が一般用語なのか、筆者のいた会社で考えた名前なのかよくわからないので、なんだか回りくどい説明になってますが、その辺はご勘弁を。とにかく、逃げ場をなくせばいいのです。