現実問題としては、殆どの組織はレベル１の状態にあると思われますので、ここでは、レベル１の組織の取り組みについて、ＣＭＭの提唱する内容に私の考えるところを加味して説明することにします。
この段階でＣＭＭが提唱するのは、次の６つの取り組みです。このなかで、最初の３つ（要求管理、プロジェクト計画、プロジェクトの進捗監視）が特に重要です。
１．要求管理
２．プロジェクトの計画
３．プロジェクトの追跡と監視
４．外注管理
５．品質保証
６．構成管理（変更制御を含む）
要求管理の目的は、顧客との間で要求の食い違いを無くすことにあります。
要求が明らかにされるということは、ソウトウェア開発に関わらず、プロジェクトを成功させるのにもっとも重要なことです。残念ながら、多くの開発組織では、既にこの段階で成功の可能性が失われているのです。
この作業を節約？しても、得られるものは何もありません。逆に多くのものを失うことになります。
また、要求がうまく整理されていないと、詳細な計画が立てられませんし、テスト段階に入って、一体何を確認するというのでしょうか。
「要求」によって、
何を、
どのような状態で、
何時までに、実現すればいいのか
が明らかにされます。つまり、その作業のゴールです。要求を明らかにする文化をもたない組織では、１日程度で出来る簡単な作業でも、求められていた機能が含まれていなかったりして要求を外してしまうことがあります。「今日中に」という依頼だったため、やり掛けの仕事の後に回したところが、３時ごろになって「出来たか？」と求められたりします。これなども、要求を正確に確認しなかったことから生じるのです。作業の順序を変えても、その人の作業の総量は変わりません。でも、その順序を変えることによって、他の人との間で「並行作業」が可能になったり、他の人の作業の進捗に影響を与えることはしばしばあります。その工夫が行なわれなかったために最終期日を外してしまうことになります。ムダなことです。
１．要求をうまく整理し、ドキュメント化すること
２．全ての要求に、グループ化された番号をつけること
３．その番号は、この後、設計から、テストまで引き継ぐこと
４．機能的要求以外に品質的要求も明確にすること
５．まとめられた要求仕様を厳密にレビューすること
６．分かったことを折り返して確認すること→「分かる」の問題
７．設計段階に入ってから、もう一度内容を確認すること
８．要求はテスト（または計測）可能であるように記述すること
９．要求の変更は厳密に管理されレビューされること
１０．変更された内容は速やかに関係者に通知し、ネゴシェーションすること
１１．プロジェクトの取り組みの「目標」を設定すること
なお、プロジェクトの目標、例えば、“今回はインスペクションの精度を上げる”とか、“不具合件数を２０以下にする”とかいう目標を設定し、その実現方法と測定方法を設定しておくことで、プロジェクトの最後で、「総括」が出来ます。
一般に、最初にこのような「目標」が設定されていないことが、プロジェクトの最後で振り返ることが出来ない大きな理由ですし、作業そのものが「無機質」的になってしまいます。
チームの連帯を強化し、一つの目標に向かっているという心の繋がりが持てるような状況を作る事も、いいものを作り続けるために必要な配慮です。
「Software Process」のメニュー に戻る
ここでの目的は、開発関係者とマネージャーに対して、合理的な計画を確立することで、見積もり能力や作業の計画立案能力を確保することにあります。
本来、ここでいう計画とは、所謂開発作業のスケジュール以外に、要員の確保、器材や部材の調達、パンフレットの作成から販売の段取りなどを含みますが、それは以下に簡単に列記するとして、ここでは、話しを分かりやすくするために、開発作業のスケジュールに範囲を限定します。
・各部署（分担）の責任範囲を明確にする
・「約束」に対する関係者の同意を確立する
・開発体制、評価体制を確立する
・構成管理の方法や品質管理の方法が指示されている
・設計の方針が示されている
・開発期間やコストなど開発の制約事項を明らかにする
・開発に便利な支援ツールなどの調達計画が示されている
・初期の段階で把握出来るリスクを確認する
スケジュールは、少なくとも詳細なものと全体が見渡せるものの２種類を用意することが大切です。計画は単に書けばいいというものではありません。「約束」するための段取りを考えたり、予定を外しそうなリスクの発生を予測したり、進捗のトラブルが発生したときに、やりくりを調整できるものでなければなりません。したがって、最初に１度書けばいいというものではありません。計画は、見直せば見直すほど前に詰まってくるものです。それでも、見落としていた作業が湧き出してきたりするものです。見直して、前に詰めておかなければ、簡単に後ろにずらすことになってしまいます。
多くの現場では、１ヵ月の作業すら予定通りに進められないのに、最初に書かれたスケジュールは、不思議にも納期の最後の日に、ピッタリ合わされて策定されています。何時の間にそのようなノウハウを身に付けたのかと思ってしまいますが、実際にその通りに仕上がることはありません。そのようなノウハウを持っていないのに、期日の最終日に仕上がるようなスケジュールを書くのです。しかも、マネージャーもそれを承認するのですから、何をか言わんヤです。おまけに、そのスケジュールは、最初に書かれたまま１度も調整されることはないのです。一体、そのようなスケジュールにどのような意味があるというのでしょうか。当然のことに、そのようなスケジュールは何の役にも立たず、しまいには、“書くだけムダ”ということになり、半年も経たないうちに書くのを諦めてしまいます。
１．概スケジュールと詳細スケジュールは階層関係を維持すること
２．詳細スケジュールはそれぞれの作業の「量」が見えていること
３．“１つの作業”が２日も続くことはない
４．したがって詳細スケジュールに於いて「設計作業」という作業はない
５．「量」が見えなければさらに細分化する
６．詳細スケジュールによって１日の遅れがその日に見えること
７．“マイルストーン”が設定されていること
８．少なくとも、２ヵ月先まで詳細に見通すこと
９．近づくにつれて、もっと具体的にイメージして検証すること
「Software Process」のメニュー に戻る
ここでの目的は、作業の進捗が見えるようにすることと、計画を外しそうな兆候を察知し、効果的な管理ができるようにすることです。そのためには、スケジュールなどの計画の追跡とレビューが欠かせません。
期日の直前になって、要求を外すことが分かっても、その時点では効果的な対応策を講じることは出来ません。したがって、スケジュールの進捗管理、状況の把握は、毎日の作業のなかで行われる必要があります。プロジェクトの期間が短くなった今日では、週に１回の進捗確認も効果的ではないでしょう。
「その日の進捗がその日に分かる」ようなプロジェクトの詳細なスケジュールが書かれれば、厳密な進捗管理を行うことが出来ます。逆に、そのようなスケジュールがなければ、厳密な進捗管理は望めないでしょう。
スケジュールと進捗管理は表裏一体の関係です。それを使って、うまく進捗管理ができるスケジュールが“いいスケジュール”なのです。先ずは効果的な詳細なスケジュールを書くことです。何度も何度も書くことです。
詳細なスケジュールによる進捗管理の目的は、・約束を守るための「工夫」が、必要な時に何時でも湧き出してくるような
「思考パターン」を身に付けること
・“未知の能力”を手に入れることにあるのであって、決して「期日」に間に合わせるための尻叩きの動機を与えるものではありません。「期日」に間に合う、というのは、あくまでも「結果」なのです。
１．一日の作業の遅れがその日に発見できること ←とても重要！
２．１日に数回、詳細スケジュールを見ること
３．予定通りにいかない危険を早く察知すること
４．何時までも遅れっぱなしのスケジュールで仕事をしないこと
５．基準に対して３０％以上の誤差には原因を探ること
６．遅れをそのまま許容せず、必ず挽回の工夫をすること
７．リーダーは毎日、メンバーに声をかけること
８．遅れが期日に影響を与える可能性を察知したとき、責任者は適切な行動をとる
９．予定通りに出来るようになれば、さらにストレッチをかけること
「Software Process」のメニュー に戻る
ここでの目的は、質の高い外注業者を選び、彼らを効率良く管理することです。
ここでは、外注業者の選択から、契約や「約束」の確立、外注業者の作業の進捗の確認（のためのレビュー）などが含まれます。
外注管理がうまくできる組織は、自分たちの作業もうまく出来る組織でもあります。自分たちの作業の段取りと、外注業者への依頼作業の段取りとは共通したものがあります。
にもかかわらず現実には、自分たちの作業の段取りが悪く、納期に間に合わないというので外注業者に作業を依頼します。これでは非常に高い確率で失敗することは目に見えています。
外注業者に対して的確な「要求」が出されているか？
効率的な進捗の確認や指導が出来るのか？残念ながら、現実はこれらに悉く失敗してしまうのです。
もっとも、作業を依頼する際に、外注業者の状況や能力を確かめておくことも重要です。実績を確認することも有効でしょう。ちなみに、ＤｏＤ（米国防総省）では、ソフトウェア開発の入札条件として「レベル３以上」を義務づけています。
１．外注業者を知る ― 外注業者の選択
２．先方の開発能力と開発体制を確かめる
３．成果物を含めて、こちらの「要求」をしっかり伝える
４．納入基準を明らかにしておくこと
５．こちらの要求に対する折り返しの「確認書」を求める
６．契約内容を把握しておく
７．外注業者の開発体制を確認する
８．連絡窓口を明確にしておく
９．作業の進捗を確認する方法やタイミングを明確にしておく
１０．詳細の作業の管理の責任を明確にする
１１．こちらの窓口には「責任ある人」を充てる
１２．進捗の確認をこまめにやる（フォロー）
１３．こちらのプロジェクトの進め方に対して理解を求める
「Software Process」のメニュー に戻る
ここでの目的は、開発プロセスと成果物（製品を含む）の状況を目に見えるようにして管理することにあります。
そのため、レビューと監査が頻繁に行われます。もちろん、レビューし、監査するためには、プロセスや作業の成果物が確実に文書化されていなければなりません。
しかしながら、この段階（プロセス・レベル１）で出来る品質保証は、当然それ程高度なものは望めません。いわゆる「ソウトウェア・メトリクス」というような、成果物に関する測定データやプロセスの測定データをベースにした品質保証、あるいは欠陥予防というレベルが実現するのはもっと先の話しです。
ただし、その時にスムースに事が運ぶように、「測定」することに対する心理的抵抗を和らげておく狙いから、このレベルでも出来る簡単な「測定」を取り入れることは可能ですし、同時に有効です。それでも、まだプロジェクトを約束出来るレベルになっていませんので、あまり測定に負荷を掛けないように注意が必要です。
「品質保証」というとき、多くの人はテスト工程の充実をイメージするかもしれませんが、そのようなスタンスからはコストが掛かりすぎ、効果的な保証は実現しません。この段階での品質保証は、開発の工程全体の中で実現することが大切です。前工程をいい加減にしておいて、後工程で品質保証など出来るわけがありません。それでもやろうとすれば相当なコストが掛かってしまいますし、たとえそこまでやったとしても、満足のいく保証のレベルには届かないでしょう。
レベル２に向かって「約束出来る」ことを目指している以上、開発工程全体で約束出来る体制にもっていくことが、もっとも近道ですし、このレベルの品質保証が最終目標ではありませんので、組織の水準を引き上げることに重点を置くべきでしょう。
こういう作業手順、工程間の調整が行われていれば、結果として品質が悪くならないはずだ、という状態を目指してください。
１．漸次、作業手順を確立していくこと
２．効果的なレビュー（インスペクション／ウォークスルー）の実施
３．成果物の内容が保証できること（レビューと併用）
４．評価（テスト）体制を整備すること（設計者とは別）
５．不具合（クレームを含む）への対処手順を持っていること
６．変更管理を持っていること
７．当該組織内で情報のフィードバック・システムを持っていること
８．市場のクレームを入手し、設計に反映出来ること
９．組織内でスキルを平順化するプログラムを持っていること
１０．メンバーの生産性のデータを手に入れるための測定が行われること
「Software Process」のメニュー に戻る
ここでの目的は、ソフトウェアのライフサイクルに亙って、成果物の完全性を確立し、維持することにあります。
一般にソウトウェアの構成管理というとき、製品を構成する多くのソフトウェア・モジュールのバージョンが、直ちに分かるような管理体制を意味します。また、そのような管理を支援してくれるソウトウェア・ツールも出ているようです。
製品を出荷した後で、不具合が発見されたとき、そのトラブルを含んでいる製品はどれかということが分からなければなりません。例えば自動車の「リコール」を想像してください。「何時から何時までの間に生産された製品がリコールの対象です」という形で発表されます。これと同じことができることが基本です。
その為には、プログラムの変更行為が放任されていては叶いませんので、「変更管理」と合わせて実現される必要があるのです。逆にいうと、変更管理が出来ておれば、構成管理は難しくないはずです。ソフトウェアの開発環境は日々変化しますが、トラブルは過去のものに対して発生するわけですから、その時点で、開発環境が変化してしまっている可能性があります。この結果「確認する方法がない」という事になりかねません。勿論、２０年も３０年も保存しておくことは難しいと思いますが、製品のライフに応じて、何時までその環境を保存するか、あるいは再現できる手だてを確保しておくかということは方針として決定されなければなりません。このような事は、「構成管理マニュアル」の中に記述されることになります。
このような体制が整っていることで、保守開発時にベースをなるモデルが設定されると、速やかに必要なソースやドキュメントを調達することが出来ます。
１．製品とそれを構成するソフトウェア・モジュールの関係を整理しておくこと
２．派生関係も目に見えるようにしておくこと
３．対応するＯＳやmakefile など再現するためのものを全て確保しておくこと
４．そのためのチェックリストや構成管理マニュアルを用意すること
５．ドキュメントや成果物に対して“ベースライン”を設定すること
６．ドキュメントの更新を制御する仕組みを持つこと
７．ソース・モジュールの変更を制御する仕組みを持つこと
８．「構成管理グループ」の組織を確立し、必要な権限を与えること
９．不具合の影響を追跡出来る体制をもつこと
以上の６つの取り組みは、プロジェクトの最初から最後までの工程が関わっています。注目すべきことは、この中に、分析手法や設計手法に対する取り組みが含まれていないことです。もちろん、それらが不必要というのではありません。既に手に入れているのなら、それらは一層効果を上げることに貢献するでしょう。
しかしながら、この時点で手に入れていないとしたら、それらに対する取り組みを脇に置いて、先ずはここに挙げた６つの取り組みに着手することです。この６つに取り組む前に、そのような分析・設計手法に取り組もうとしても実効が上がりません。
私自身、コンサルタントを始めた頃、この問題に直面したことがあります。分析手法や設計手法を教えようとしても定着しないのです。個別には積極的に取り組んで来る人もいましたが、組織に広がっていかないのです。
その後、この「プロセス成熟度」や「ＣＭＭ」に出会ってから方針を変更しました。先ずは、その時点で出来る方法を駆使して、「約束」出来るようになるところから始めたのです。その結果は、大変満足な結果が得られました。
このような経験から、皆さんの組織でも、先ずはこの６つの取り組みに挑戦することをお勧めします。