私のホームページでもご案内しましたが、２０００年６月１６日に早稲田大学の大隈講堂にて、Ｗ．ハンフリー博士の講演が実施されました。参加者が１２００名近くに達するという盛況振りで、ソフトウェアの開発現場で抱える問題の深刻さを感じさせます。
テーマは、ソフトウェアの開発が“エンジニアリング”に成りうるかということで、ＣＭＭを支援するためのＰＳＰとＴＳＰについての説明と報告が中心でした。このようなトレーニングが行われていることが、“エンジニアリング”に成りうる前提条件である、ということと理解しました。ここで、講演の内容を詳しく報告することはしませんが、講演の最後に会場での質問に応じた際、最後の質問者とハンフリー氏の回答との間にズレがあったと認識しています。会場の皆さんはどのように受け取られたか分かりませんが、あとで何人かの人に確認したところでは、やはりすっきりしていないようでしたので、ここで私なりの判断をまとめることにします。なお、これは私個人の意見であり、ハンフリー氏に確認したものではありませんので、誤解の無いようにお願いします。
質問者の主旨、およびハンフリー氏の回答の要旨は、以下のようであったと理解しています。（注意：詳しく再現するものではありません）
質問者：「資料の３１ページのグラフでトレーニング実施後のテスト期間が、その前と比べて２８日から、わずか４日に減少しているが、これは必要なテストは実施したのか。バグの対応などを考えると、４日間でできるとは思えない」（“資料”のない方、ご免なさい）
ハンフリー氏：「テストはきちんと実施した。省いたわけではない」「トレーニングを実施した後では、バグは減少するので、テスト期間は少なくて済む。テストは、主に品質を保証する意味で実施された」
ハンフリー氏にしてみれば、必要なトレーニングを実施した後では、多くのバグは出るはずが無いということなのですが、この“仕掛け”が、実際にはなかなか理解されないのかなという気がします。ＰＳＰやＴＳＰのトレーニングでバグが減るという仕組みが理解しにくいかもしれません。そこで、私がこれまで進めてきた経験から、なぜバグが出ないかということについて、僭越ながら、ここで説明することにします。
ここで問題なのは、バグの（本当の）原因は何かということです。多くの場合、仕様モレや変数の判断ミス、なかにはケアレスミスなどが原因として認識されているのではないでしょうか。しかしながら、それらは本当の原因ではありません。というより、本当の原因を「プロセス」に求めないと改善されません。
この考え方によれば、プログラムに入り込むバグは、“ケアレスミス”も含めて、ほとんど全てが「プロセスの欠陥」として説明できます。仕様モレを防ぐためのプロセスが組み込まれていることで、仕様モレのバグは大きく減少します。ケアレスミスは言語のトレーニングプロセスを組み入れたり、特定の人に対して、他の人とは別に成果物のレビュープロセスを増やしたりすることで、バグが減少します。
今回のハンフリー氏の報告では、当事者は、ＰＳＰやＴＳＰで、仕様の表現能力を向上させ、見積り能力を高め、プロセスを定義するスキルも手に入っていますし、実際のプロジェクトでは、適切なプロセスが定義されていることが、資料からも読み取れます。
資料では、ここで「defining the process」という表現が使われていますが、私は、自分の経験から、これは、プロセスと成果物が合理的に連鎖するようになっていて、それらが具体的に定義されているものを指すと、判断しています。
これによって、基本的にバグは発生しません。一気に「０」に成るわけではありませんが、進め方によっては簡単に１／１０から１／２０にも減ってしまうことを、私自身のこれまでのコンサルティングの経験の中で何度も確認しています。
それは「プロセスの欠陥」が解消されて（または減少して）いるからです。最初に定義されているだけでなく、途中からも定義されます。要求内容を見積もる過程で、事前に予備調査が必要と判断されたなら、そのような項目に対しては、「事前に調査する」というプロセスを挿入します。スケジュールの追跡の中で、新たなリスクの発生が認められれば、それを適切に拾い上げるプロセスも用意されているはずです。これが省かれてしまうために、Ｉ／Ｆの確認が行われずにバグと成ってしまうわけです。
要求仕様が「検証可能な表現に成っているかチェックする」というプロセスも入っているでしょう。このように、要求に相応した適切なプロセスが設定されているだけで、特に「バグ」を退治するような手だては講じるわけではありません。というより他に、バグを入り込ませない方法というものはありません。もちろん、何度も言うように、これでバグが「０」になるわけではありません。プロセスの定義だってまだまだ抜けているでしょうし、判断のタイミングも遅いかも知れません。これを追及するのは、ＣＭＭのレベル４への取り組みのテーマであり、プロセスの測定のところで、シックスシグマと組み合わせることで、より効率良くプロセスの定義の精度上げることができるはずです（まだ私自身、実際にはシックスシグマとの合体はやったことがありません）。
もしかすると、バグはテストによって取り除くものと思われているかも知れません。「テストで品質を向上させる」という間がえ方が根強く残っている状況を考えると、バグがそれまでのプロセスで取り除かれるとは思えないかも知れません。
でも、テストは、それまでのプロセスに於て仕込まれたバグを取り除く行為に過ぎません。成果物を定義し、プロセスを適切に定義するということは、テスト工程以前では、バグが入り込む余地を狭めることであり、テスト工程ではバグを見逃さないに繋がります。そのため、バグはプロセスの定義の甘さやプロセス事態がモレた分だけしか発生しないわけです。
この結果、テストは、最小限のサイクルで終了することになります。バグがあっても、それによって予定されたテストデータが流せなくなるという致命的なバグはほとんど無くなり、結果的に、品質を保証するために必要なテスト日数だけで終了することになります。
これが、「バグの原因はプロセスにある」という所以です。
講演会の資料のデータは、もともと４日ぐらいのテストで終わるものが、それまでは、プロセスが適切に定義されていないことで多くのバグが発生し、その対応のために６倍もの日程が費やされていたと解釈できます。
それでは、どの程度までプロセスを定義するかということになりますが、ＣＭＭのレベルが低い組織では、このようなプロセスの定義に依って一気にバグを減少させようとすれば、無視できないコストが掛かってしまいます。バグによっては、テストで簡単に発見できたり、修正するにも他に影響の少ないものもあります。そのようなバグは、テストで発見するほうが安くつく可能性があります。
プロセスを定義して行く中で、このようなコントロールは、それほど難しいものではりません。どの部分のプロセスの定義の精度を上げれば、どのようなバグが消えてくれるかは見えていますので、修正時の混乱が大きいと思われるバグを出さないで済むところのプロセスの定義にコストを投下すればいいわけです。その結果、プロセスの定義が甘い部分も見え見えですので、その部分はテストでカバーすることになります。
今回の、ハンフリー博士の話しには、このような背景があるものと考えています。
以上、少しでも、皆さんのお役に立てば幸いです。