プロセス改善活動の勘所
1990年にハンフリー氏が提唱する「プロセス成熟度」に接し、さらに翌年に「CMM」が手に入ったことを機に、仕事の傍ら、それまでの私自身の経験と照らし合わせて「CMM」の研究に数年を費やしてきました。その結果、私自身がそれまで手に入れてきたことが、そして私自身のSEとしての仕事を楽しくやってこれた（拙著「ＳＥの仕事を楽しくしよう」SRC刊、参考）背景にあったのが「CMM」そのものであったことに気付いたわけです。奢った言い方をすれば、私の中に「CMM」があったのです。だから成功し続けることができたし、周囲の人の半分の時間で終わることができたのです。もちろんバグはほんの僅かですので期間中にすべて解決します。家には早く帰ることができますので、家庭人としての努めも果せますし、「次の準備」にも取り掛かることもできました。
「CMM」のお陰で、私のポケットに入っていたものが、多くのソフトウェア開発の現場で使えるものであることに気付いたのです。その後、私自身が実践してきたいろいろなプロセスを当時の客先で実験しながら整理を終えたのが1995年で、そこからプロセス改善のコンサルティング活動に取り掛かったわけです。同時に多くの人に「CMM」の取り組みのヒントになればと思ってホームページに公開したのが1996年の11月です。
あれから１０年という年月が経過しました。あっという間です。この間、私自身が「QCD｣の達成を目指してプロセス改善のコンサルティングを実施したクライアントは２５社ほどに達します。その中にはQCDの達成を目指している途中で、CMMのコンサルタントと交代し、そのまま認証まで進んだケースも数例あります。期間的には１つのクライアントで平均すると３年前後継続しますので、２５社というのは手一杯の状態に近いものでした。その中でクライアントの事情（文化や組織体制など）にあわせてプロセスの改善を指導してきました。中には不十分な結果に終わったケースが数例ありますが、他はほぼ満足できる状態に達しています。一般に効果を表すのが６〜１０ヶ月後で、そこから２，３のプロジェクトを経ることで、プロセスを安定させることができるのです。逆に言うと、プロセスの改善にはそれくらいに時間が掛かるということでもあります。
こうして１０年のコンサルティング活動の中で、プロセス改善の取り組みに対する確信やポイントというものが見えてきましたので、ここに新たに「プロセス改善の勘所」のページを設けることにしました。一般的なプロセス改善の活動はもちろん、CMMへの取り組みも含めて、ソフトウェア開発現場におけるプロセスの改善を推進する立場の人や、プロジェクトを引っ張るリーダー、さらにはSQAの担当者の皆さんにとって、少しでもヒントになればと思っています。
また、最近はCMMを参考にしたプロセス改善のコンサルティングも増えてきました。それを生業とする業者が増えたことが背景にあります。このこと自体は歓迎すべきことなのですが、中には認証取得を指南するコンサルティングも見受けられ、その中には前提とする技術の修得を積み残した状態で強行しために、現場に取り返しのつかないダメージを与えてしまうケースもあるようです。そのような組織では、現場の人たちにこの種の取り組みに対する免疫が残ってしまい、このあと４，５年は抗体反応のために取り掛かれない可能性があるのです。ISO-9001と違って、ソフトウェア開発の現場のエンジニアたちにとって「CMM」は“かわす”ことができないのです。こうしてダメージを受けたエンジニアたちは、時代の列車に乗れない可能性があるのです。そうした危険性に対して警鐘を鳴らす意味からも、新しいページを開くことにします。
私自身は、２００２年ごろから本業のコンサルティングの傍らで本の執筆活動に取り掛かったこともあって、ＨＰの方の更新は滞っていました。そのことに対する読者の皆さんの不満の声も聞こえていました。まだ本の執筆活動はあと２年ほど続く予定ですが、最近になってプロセス改善の取り組みに危機感を覚える状態を何度か目にしたこともあって、もう一度、このＨＰを活性化することにします。ただ、私自身のこのＨＰに投入できる時間が限られていますので、その中で少しでも早く公開するために、最初に全体の体系を示し、その体系の中で原稿ができ次第にアップすることにします。コンテンツごとにアップした日付を付けておきますので、皆さんの方で“新規”の判断をしてください。したがって、体系によっては、なかなかコンテンツが入ってこないこともあると思いますが、その点は御容赦ください。また、体系そのものも途中で変わるかも知れません。
なお、ＨＰの他のコンテンツでも触れていますが、私自身はCMMの公式セミナーを受けていませんし、公認の方の指導も受けていません。この「勘所」でもCMMに触れますが、ここで展開している解釈はすべて私自身の経験にもとづくものです。これまでのコンサルティングの中で確認できたところでは「CMM」の解釈を曲げているところはないと思っていますが、「CMM」の解釈を“越えて”展開するものはあります。「CMM」は活用するものであって、「CMM」に書かれていることに囚われる必要はないという考えに基づくものです。また当然ですが、ここでのCMMの解釈は認証を根拠とするものでもありません。CMMに触れる部分があっても、それはあくまでもQCDの達成を目指す中で、CMMをそのように活用できるという立場で扱っているだけです。私自身が目指すのは、あくまでも「QCDを達成し続ける」ために何をすべきか、ということです。ｋの点は理解していただいた上で、このＨＰを活用して下さい。
（2006年1月1日）
目 次 ●プロジェクト計画の立案
ＰＦＤを忘れている（2006/3/5）仮説の段階でサイズを見積もりと「間に合わないモンスター」の関係（2006/3/5）
●プロジェクトの監視と制御
「進捗管理」という言葉を勧めない理由（2006/3/5）工数しか表示されないスケジュールツールの不思議（2006/3/5）
“フィードフォワード”こそ進捗管理の真髄（2006/3/5）
●計測とその活用について
間違った反省会からの脱却（2006/1/1）
「銀の弾丸」になってしまう仕組み（2006/1/1）