日本語版に寄せて 　真面目にソフトウェアの開発の改善を推進しようとしている組織や人にとって、ま たは、すでにCMM(R)の概念に沿って非公式に成熟度評価を行ってきた組織にとって、 かねてから期待されていた "Capability Maturity Model for Software(R), Version 1.1 (CMU/SEI-93-TR-24)" 及び "Key Practices of the Capability Maturity Model (R), Version 1.1 (CMU/SEI-93-TR-25)" の日本語への翻訳が、SEI公認の公式日本語 版として完成し、このたび出版の運びとなったことは、大きな朗報でしょう。 　日本の品質意識の高い企業は、まだ、ソフトウェアプロセスという言葉が普及する ずっと以前から、品質という側面から、それぞれの流儀で実質的にプロセス改善をや ってきました。しかし、当時は、ハードウェアで成功した品質管理のやり方をもとに して、それを一部改良したものが多いようでした。 　私は、かつて機械工場で工場挙げての改善に加わり、その後ソフトウェア組織に移 り、ソフトウェア品質・生産性の改善に携わり、現在は、いろいろなソフトゥエア組 織を覗く機会があるコンサルタントという仕事をしています。これらの経験を通して、 ソフトウェア組織には、一般に共通した典型的な現象が見られます。 　例えば、「賽の河原」現象ともいうべき同じ問題の繰返しです。これは、開発に携 わる人たちが、あるプロジェクトでどんなに苦労しても、喉元過ぎれば熱さを忘れて、 次の、またはその後のプロジェクトでも同じ古典的なトラブルを繰り返し、結局何年 経っても状況は変化しない現象です。最も頻度の高い古典的な問題には、要求仕様 がはっきりしないまま開発を開始して後で大量の仕様変更を要求される羽目になる、 チームの編成が必要な数とスキルが充足しないままプロジェクトが走り出して後で混 乱を招く、納期のプレッシャーからテスト不十分のままシステムを出荷してバグの修 正に追いまくられる、外注に依存した部分の品質が悪くて作業の足を引っ張る、など が含まれるでしょう。 　こうしたトラブルは、解決策がチームや組織の経験として学習されていないか、原 因が分かっている場合でも、プロジェクトチームの権限を越える対策が必要なのに、 それをあきらめていることが多いようです。この奥に潜む原因の一つは、組織の上か ら下まで物理的に実在する「物」を通してトラブルや原因の共通認識に立つことが容 易な、従って物に注目すれば改善が容易な、有形物の開発プロセスの改善に慣れ親し んできたハードウェア指向の精神構造ではないかと私は感じています。 　ハードウェアの世界では起こりにくい問題が、ソフトウェアではなぜ繰返し起こる かが、ソフトウェアプロセス改善の原点でなければなりません。ハードウェア指向の 品質システムをソフトウェアに適用することの効果をすべて否定するわけではありま せんが、それには限界があるばかりか、有形物流のプロセス改善でよしとする精神構 造は、組織における人やチームの役割を軽視することで、しばしば害を及ぼします。 ソフトウェアのプロセス改善のためには、ハードウェアで成功したこと以上のことを やらねばならないのです。ソフトウェアプロセスの改善は、チームを構成する人が組 織の仕組みの中で行う活動の改善ですから、組織全体としての取り組みが必要不可欠 です。 　こうしたことは、地道にソフトウェア品質の改善を行ってきた過程である程度分か っていましたが、私を含めて、日本人は個々の組織でよいことをやっても、それを体 系化して広く産業界に普及するのは苦手なので、改善は改善意識の高い組織の内部に 留まっていて、それを産業全体のものにすることはできませんでした。 　幸い、米国カーネギーメロン大学、ソフトウェア工学研究所のWatts Humphreyを始 めとする優れたメンバーの努力によって、ハードウェア指向の品質管理とは異なる視 点で、ソフトウェアの特性に着目したソフトウェアのためのプロセス改善への取り組 み方法がCMMとして体系化されました。その後、最初のモデルは、米国らしいオープ ンな議論からの定期的なフィードバックというかたちで、あるいは、プロセス成熟度 評価の産業への普及の過程で作られた膨大な補助資料や文献の充実というかたちで、 整備された体系として成熟しました。 　かつて私は、頻繁に日本のソフトウェア組織を訪ねたドイツのGMDの研究所長であ ったDr, Gerhard Goosから、「日本のソフトウェア組織は、同じ企業の中でさえ、ソ フトウェアプロセスや開発環境に、なぜ大きな格差があるのですか？また、程度の低 い組織でも、レベルの低さに気づかずに、それを得々として説明するのはなぜでしょ う？」と問われたことがあります。日本の組織の閉鎖性、開発者の非流動性、または、 企業や組織間の技術交流が場はあっても実質的に行われていない、などがそのときの 私の答えでした。しかし、これからは違ってくるでしょう。我々は、CMMという実質的 に世界共通の客観的な尺度を、より利用しやすい形で持ったのですから。 　私が、これを機会に心から期待するのは、これが「点取り」や「レッテル買い」の ために使われるのでなく、現場での地道な改善に有効に利用されることです。 　この文書が、真剣にソフトウェアプロセス改善に取り組んでいる、または取り組も うとしている日本の方々を勇気づけることができれば幸いです。 　最後に、このCMMの翻訳とレビューという膨大な作業をボランタリ−でやってくだ さった方々に、厚く感謝致します。 (R) Capability Maturity Model and CMM are registered in the U.S. Patent and Trademark Office. 1999年1月 フリーコンサルタント 松原友夫 ==================================================== Tomoo Matsubara IEEE Software Soapbox Editor Cutter Consortium Faculty Member ====================================================