通常はこのようにして貯めこまれたノウハウを事前に組織的に間違いやすいポイントとしてまとまっていたりするので、ステップ４のコーディング規約はプログラム作業前に存在することが多いですが、本来は組織的に間違いやすいポイントを潰すために行っているものです。
　以上のステップを良くみると、学校教育などで行われている学習の習熟プロセスと良く似ていることに気付くでしょう。実際、同様な学習プロセスがバグの削減においても有効なのです。そこで、このプロセスはPSP（Personal Software Process）の基本モデルとなっています。
ところで、バグに関するノウハウのまとまっていない組織で手っ取り早くステップ５を実施する方法ですが、市販のバグの百科事典のようなものを利用すると良いでしょう。例えば、バイザーの「ソフトウェアテスト技法」やケイナーの「基本から学ぶソフトウェアテスト」の巻末には一般的なバグの一覧がまとまっているので、これらを利用して勉強会を行うことでバグのパターンを事前に身につけることができます。その際、バグの一覧をただ眺めるのではなく、今までに出会った似たようなシチュエーションについて話し合えば効果が高まります。
　さて、私自身の今までの経験や他の管理者との会話なども含めて考えると、プログラマのプログラミングエラーに対する学習効果は非常に高く、多くの場合、バグやシンタックスエラーを減らす取り組みを行えば、半年程度でほとんどプログラミング関連のバグやエラーを無くせるものと考えています。また、作りこんでしまった場合でも簡単な見直しで、プログラムミスの修正ができるようになります。
　かつて、日本ではプログラミングツールが売れないと海外のツールベンダに嘆かれた時代がありましたが、多くの組織でこのような取り組みがされていましたし、プログラマはプログラミングミスを極限まで減らせて一人前といった風潮がありましたからニーズがなかったという印象があります。また、ほとんどの組織がプログラマ自身がテストまで行うようにしていましたから、テスト結果を自身にフィードバックしやすい環境であったのも確かです。それに、改善活動などで、自らが必要なツールを自分たちのプロセスに作りこんでいたという状況もありました。

　さて、もうひとつの仕様に起因するバグについては、プログラム作業への習熟とは違ったアプローチが必要になります。
　基本的には、仕様検討、仕様実装の漏れですから、いかにシステムを構成する要素（層）について必要な検討を漏らさないか、が大切になります。実は、このために、システム開発のノウハウを設計ドキュメントのテンプレート（帳票）という形で整備してきているのです。
　設計ドキュメントの各項目について検討を行い、その結果を定義することでシステムの全体像を定義する作業を確実化します。
設計ドキュメント自体は過去のドキュメントをコピーして準備しても良いですが、それぞれの項目についての検討は現在構築しようとしているシステムに即して行う必要があるのです。そして、新たに必要となる仕様（システムの層）を追記し、システムの特性に合わせて割愛する仕様について割愛する旨とその理由を書き残します。
　よく、ドキュメントが書けないということを聞きますが、実際にはドキュメントに要求されている仕様が理解できず、その必要性の要否判断がつかず、記載すべき内容が見当つかないということが原因となっているようです。これは指示する側にも問題があり、多くの場合、ドキュメントを書けという指示はしますが、書くべき内容や検討を行うべき仕様について作業者に教えていないことが多いからでしょう。むしろ、教える側の管理者がドキュメントの個々の項目について知らなかったり、誤った情報を覚えているといったことも多いように思います。

　こうした現状に対して、アジャイル技法として、オンサイト顧客のようなプラクティスが提案されたのだと理解していますが、例え顧客であったとしても全ての仕様について明確に考慮しているとは言えないことから、万能な方法だとは思えませんし、よくひとつの仕様が他の仕様に対して関与しているケースもありますから、仕様検討の中途で実装してしまうことの無駄や危険性も考えながら適用する必要があると考えています。

　最近、Ｗモデルとして、仕様検討時や設計作業時にテスト技術者の視点を組み入れる方法が注目されていますが、そもそも、テスト技術者が持っている視点は、システム全体を俯瞰した視点であったり、利用者、運用者としての視点や個々のプログラマの思考の弱点（よく検討漏れを起こすポイント）であったりしますから、これらが漏れなくできるのなら、別にテスト技術者が必須というわけではないと思います。逆に、テスト技術者がこうした視点を持っていないのなら、例え、独立したテスト部門を作っても、Ｗモデルを採用したとしても満足な結果は得られないでしょう。

　また、設計ドキュメントを書かずにいきなりプログラミングを行うことがありますが、これはプログラム対象に対する習熟と作業者のモデリング能力に結果が左右されるため、ホビープログラムでは許されるかもしれませんが、仕事としてプログラムをするのであれば避けるべきだと思います。

　最後に、こうしたＱＭＳ（品質管理システム）を構築してきた原動力について考えて終わりにします。
　クスマノが「日本のソフトウェア戦略」というレポートや米国議会の公聴会で波紋を巻き起こしたかつての日本のソフトウェアＱＭＳについて、そのエッセンスはハンフリーらがＣＭＭとしてまとめています。しかし、段階的に組織レベルを向上させるとしたこのモデルが当時の日本のソフトウェア開発の現場で行われていたかというと疑問のように思えます。これは前述の保田の「ソフトウェア品質保証の考え方と実際」でもそうですが、必ずしも戦略があって、それに従って構築したというよりも、組織の構成員が自主的に積み上げていった手法の集大成という印象を受けるからです。
　これには、当時、行われていたＴＱＣ運動（現在のＴＱＭ活動）が無縁ではないように思います。
　ＴＱＣ運動の実施下では、作業者自身にプロセスを変化させる権利が与えられています。そして、品質を向上させるという目的を達成するために、科学的に因果関係を解析しながらよりよくなるようにプロセスを作業者自身が変更していくのです。こうした学習を行い、動機付けされたチームは自主的に自らの作業の質を高めるために、より効果のある品質プロセスを追加していきます。そして、対象は自らが見出したプロセスに限らず、他者の考案した効果のありそうなプロセスの採用にまで及びます。

　実際にシステムやソフトウェアを開発していくと、対象や環境など様々な要因で開発環境が変化します。変化した環境で硬直したプロセスを実施することは効果がないだけではなく、悪影響を生じることもあるのです。そうした環境変化に対して、常に日本の現場が対応できた背景には、状況に応じて柔軟に変化する現場の対応力があり、その背景にはうまく行かない原因を追求して即座にプロセスを現状に即したように変化させる現場力があったからに違いありません。

　今、ソフトウェアやシステムの品質に悩む組織は、そうした現場力の構築に挑戦する必要があるのではないでしょうか？

　→　ソフトウェア品質向上に関する発表募集中！