ソフトウェア開発の現場に限らず、これまで多くの現場で、何らかの「改善」に取り組んで来ました。不良品の割合が多くなってきたとか、作業のやり直しの頻度が昨年よりも多くなっていると言ったデータが示されたり、ソフトウェア開発では、不具合の件数が増えている、といったデータが出てくることで、組織は「改善」に取り組み姿勢を見せます。
そこで先ず行なわれることは、「現状の分析」という行為によって、「問題点」が洗い出されます。ここで指摘される問題点というのは、則ち改善されなければならない「状況」や「現象」であって、殆どの場合「原因」そのものではありません。
たとえば、不具合報告書から、幾つかの状況が拾いだされます。
・データ型のミスなどの簡単なコーディング・ミスが多すぎる
・設計内容に対してレビューが行なわれていない
・いや、その前に設計書と呼べるものがない
・何処をどのように修正したのか本人しか分からない
・仕様が途中で変わるので、まともに設計書を書いて居れない
・外注に依頼した作業の精度が悪い
などという「現状」が報告されます。そしてその結果、これらを改善すべく以下のようなアクション・アイテムが決められます。
・コーディングの後、もう一度見直そう
・関数のインタフェース仕様を早く公開しよう
・インプリメント前に必ず設計書を書こう
・設計書や要求書を書かれた時点でレビューしよう
・修正個所を文書にしてリーダーの承認をとること
・要求は設計に着手する前にＦＩＸすること
・外注に作業の精度を上げるように指示する
残念ながら、これでは「現状の問題点」を改善することには繋がらないのです。改善の取り組みには「順序」が必要で、それが考慮されないままでの取り組みでは実効が上がらないのです。
例えば、コーディングのあともう一度見直そうとしても、思い違いしたままでは、当人がソースコードをもう一度見直しても、効果は上がらないでしょう。かと言って、Ｉ／Ｆ仕様書を早く書くように指示を出しても、作業の段取りが悪ければ、他の人に必要なタイミングで用意できないでしょうし、第一、自分の作業を優先する発想からは、効果的な仕様書は書けません。
要求や設計書を早い段階にレビューすれば、重大な問題を早く発見できることは予想できても、レビューに耐えられるようなドキュメントが書けなければなりませんし、その前に、人のドキュメントをレビューするために、合計で１０時間以上もの時間を用意できなければなりません。段取りの悪い組織に、それは出来ない要求にほかならないのです。
これらは、おしなべて「レベル１」の現象であり、ＣＭＭでは、このようなレベルの組織においては、まず６つの取り組みを提案しているのです。すなわち、レビューを実施すれば、要求の食い違いが早期に発見できることは期待できるのですが、そのためには、ドキュメントが書けなければならず、同時に、自分の作業が約束できる状態になければなりません。そうでない限り、人の書いたドキュメントを真剣に前もって目を通すことなど出来ないのです。
そして、要求仕様書を安易に変更しないようにするためにも、構成管理や変更制御をルールとして確立しなさい、というのです。
改善は、そのための取り組みの順序を間違えると効果は得られません。と同時に、現象は相互に関連しており、幾つかの取り組みを並行して実施することも必要です。もちろん、それらの取り組みは、そのレベルの組織に於て取り組み可能なものでなければなりません。
その意味で、ＣＭＭがレベル１の組織に於いて提案している６つの取り組みは、その何れもが、そのレベルの組織において可能な取り組みであり、そこで求められるスキルも、特にそのためのトレーニングの負担も少ないものです。
本格的に手法や技法のトレーニングに取り組むためには、作業を遅らせることなくトレーニングの時間を確保出来なければなりませんので、どうしてもレベル２以上の組織になっていることが条件となります。この辺も、ＣＭＭは適確に計画されています。
現在、改善が必要だと感じているソフトウェア開発組織のマネージャーやリーダーの方は、この辺をよく考えて、先ずはＣＭＭの提案している６つのプログラムに取り組んでください。