初めに、用語の問題で補足しておきます。
この雑誌の中で、レベル１からレベル２に引き上げるための６つの取り組み（Key Process Area =KPA）として、
要求管理
ソフトウェアプロジェクト計画
ソフトウェア進捗管理
ソフトウェア外注管理
ソフトウェア品質保証
ソフトウェア構成管理
ということで紹介しています。
３番目の取り組みとして「進捗管理」という言葉が使われていますが、原書には「Project Tracking and Oversight」となっています。確かに「Tracking and Oversight」という行為は、日本的に言えば「進捗管理」に相当するのですが、「進捗管理」という概念は、我が国においては非常にあいまいな“もの”として認識されています。つまり、進捗管理とは何をすることなのか、的確に答えられない概念なのです。実際問題として「進捗管理」が機能していないことも、ソフトウェアの開発現場での混乱の要因の一つであると言うことも出来ます。
従って、私はこれを「進捗管理」と訳すのを避け、原書に忠実に「追跡と監視」として、このホームページに紹介してあります。また「Manegement」という言葉も使われていませんので、「進捗管理」ではやり過ぎと思っています。さらに原書のこの取り組みの中で「Activity」というのがあり、その中に、たとえば「The size of software products are tracked,...」というように、個々の追跡対象（サイズ見積もり、マイルストーン、コスト、懸案事項、リスクなど）について「tacking」することを求めています。これらは個々の対象に対する「追跡」と訳すしかなく、結局、全体のバランスを考え、同時にそこでの「行為」をイメージしやすくするために、
「プロジェクトの追跡と監視」
と訳すことにしました。
なお、以下の論では、「進捗管理」を使わずに、「プロジェクトの追跡と監視」で話しを進めます。
「Ｂｉｔ」の記事の中の乗松氏の翻訳記事の中に、ある期間ＣＭＭに取り組んだが、依然としてレベル１から進展していない組織について、もっとも大きな障害を尋ねたところ、「プロジェクトの計画」と「プロジェクトの追跡と監視」の２つであったという統計グラフが紹介されています。
これは、十分予想されるところです。私自身、１９９１年から「プロセス成熟度」や「ＣＭＭ」の研究を進めていく中で、この２つのＫＰＡが、初期のレベルにある組織のレベルを改善する際の最大の障害になると感じ、それを確実にクリアするために「詳細スケジューリング」という方法を考え出したわけです。
ＣＭＭは、何を計画し追跡すればいいかを示してくれています。成果物の見積もりサイズやそこで採用した仮説、見積もりを元に時間軸に編集したスケジュール、想定されるリスクなどを計画し、追跡することになりますが、厄介なことに、この組織が「レベル１」の状態であることから、第一に見積もり能力の不足が問題になります。これは成果物の構成を考え、その「量」をイメージできるような「粒度」にブレークダウンすることで対応していくことになります。
そして、こうした見積もりデータを元にして作られた「スケジュール」も、“無菌”状態であれば、その通りに進んでいくでしょうが、現実には、このスケジュールを崩す要因は次々と発生します。
例えば、必要な作業自体が設定されていなかった。つまり作業の計画モレです。レベル１の組織であるがゆえに、作業項目の設定に緻密さを欠いてしまうのです。次に、割り込み作業が入ることで、折角の計画も台なしにされてしまうことになります。もっとも、その割り込みの大部分は、不具合などの自分たちの以前の開発作業のまずさに由るものです。したがって、優先度が高いことは言うまでもありません。
不具合の割り込みなどは、１件で数日の割り込みとなってしまうこともあり、そうして１ヶ月間で合計１週間という時間が削られてしまいます。こうしてレベル１の組織であるがゆえに、どんな計画をもってしても、その通りに進むことはありえないわけです。多くのレベル１の組織は、これまで何度もこの種の取り組みに挑戦してきたはずです。そしてその度に、折角の「計画」がずたずたに割かれて沈没するのです。
ただ、ＣＭＭの優れているところは、より強固な計画を立てるために、「要求仕様書」のレベルを上げることと、高い「見積もり能力」を手に入れることを合わせて求めていることです。
計画が立たない最大の原因は、その前提となる「要求」が曖昧なまま開発作業に着手していることです。そのため、設計作業を進めていく中で、要求の曖昧さが原因で設計作業が行き詰まり、その段階になって、最初の要求を変更したり追加する事態に陥ります。時には、この段階で顧客との交渉が始まるということも起きてしまいます。当然、顧客は開発姿勢や方針に疑問を感じることになり、その後の相互の交渉に大きな障害となっていくことは容易に想像できるところです。
最初に入念に打ちあわせて、相互に確認しあって共通の認識に達したとしても、要求は変更されます。したがって、途中での変更に耐えるような仕組みや仕掛けが為されていなければ、そのような後から舞い込んだ「気ままな要求」のために、全体のバランスを壊され、そのことによってプログラムに不具合が入り込み、後になって折角のスケジュールが破壊されることになります。
ＣＭＭの「要求管理」では、より優れた計画を立てるために、その前提となる「要求」の精度を上げることを求めています。
もう一つ、計画が立たない理由として、適切な「見積もり」が為されていないことが挙げられます。何の「量」的見積もりもせずに、いきなり「時間」が出てきます。そのような「時間」が、約束されることはありえないことは言うまでもありません。
ＣＭＭでは、ファンクションを正確に把握し、それに基づいて「サイズ見積もり」を求めています。要求を正確に表現することによって、そこで求められている「ファンクション」が正確につかめることになります。あとは、その「ファンクション」に対応する成果物の「サイズ」を見積もることです。
ファンクション・ポイント法があれば、それの出番ですが、そのような手法を手に入れていないときは、過去の実績を参考にしたり、細分化した状態で見積もり、それを積算することになります。これにはトレーニングが必要ですし、「追跡と監視」のＫＰＡを通じてトレーニングを積み重ねていくことになります。
こうした見積もり能力は、実際に見積もっては結果と照合し、その「差」から新たなノウハウを身に付けていきます。「追跡と監視」の中では触れていませんが、ＰＳＰ（Personal Software Process）というトレーニングの中では、不具合の件数も見積もることを求めています。日本では、不具合の数を見積もるといえば不謹慎な奴と思われるかもしれませんが、実際、これは非常に有効な方法です。ここではこれ以上触れませんが、兎に角何でも見積もってしまう。そして結果と一致しなかったとき、どうして外したのかを考えるのです。
「見積もり」は「あてずっぽ」ではありません。不確定な要素は含まれるとしても、出来るかぎり、そして時間とコストの許すかぎり、必要なデータを集め、それを整理していくことで、実現性の高い見積もりが必要なのです。
ところが、こうして見積もられたデータに基づいて立てられた計画も、２週間も経てば、割り込み作業が発生し、中断を余儀なくされるのです。それは、レベル１の組織であるがゆえに、避けられないことでもあるのです。そしてレベル１の組織であるがゆえに、壊されたスケジュールを立て直す方法を持っていないのです。
ちょうど、必死に泳ごうとしているのに、初心者で泳ぎ方が悪いために、自分で立てた波を被って水を飲んでしまうようなものです（自分のこと？）。
したがって、レベル１の組織が、レベル２に上がるためには、この崩されたスケジュールを立て直す能力が必要になってきます。割り込み作業に持っていかれた５日間を、このあと２〜４週間で取り返す方法を持っていなければ、結局は納期の約束を守ることは出来ません。もちろん、６ヶ月のプロジェクトで５日の遅れなら、顧客はそれほど問題にはしないでしょうが、実際には２週間後に新たな割り込み作業が入って、さらに３日の供出が求められるのです。この他、２ヶ月前の自分たちのレビューの甘さから、今ごろになって仕様の変更が生じてしまい、メンバー全員が数日の作業の後戻りが生じることになります。こうして、６ヶ月のスケジュールが１ヶ月以上遅れてしまうのです。
最初の遅れが発生したときに、速やかにその遅れを取り戻すスケジュールを立てなければ、次々と襲ってくる遅延の波に、砂浜に築かれた砂の城はあえなく姿を消すことになります。これが、ＣＭＭの取り組みの最大の障害なのです。そしてこれを打ち負かせない限り、ＣＭＭの城は造れないことになります。
残念ながらＣＭＭにはその方法は示されていません。ＰＳＰも、私の知る範囲では見積もりのトレーニングについて扱っているだけだと思います。