前回の続きで、品質管理(ドキュメント品質)についてです。
納品物である、設計書(基本設計書、機能設計書、詳細設計書など)、試験仕様書などについては、当然のことながらレビューを実施すると思います。レビューの指摘事項は、コメント表というものにまとめていました。コメント表を記述する人が1人居ました。
さて、コメント表ですが、コメント表には、それぞれのコメントに「Q:単なる質問 R:要望 C:一般的なコメント」というのがあり、また、コメントに対する回答を記述する箇所もあります。
仕様の確認や、仕様変更、記述方法の修正、誤字脱字などはレビューで指摘されコメント表という形できちんと整理します。
また、レビューにより、内容の不具合や誤字脱字が多い場合は、途中でレビューを中止し再レビューということにしていました。
内容の不具合が3件以上または誤字脱字が5件以上となった場合に、過去のあるPJでは再レビューということにして実施していました。そのため、レビューを受ける担当者もレビュー前にきちんとドキュメントを確認するわけです。
再レビューはお客様、仕様管理者など再度スケジューリングして日程調整するわけですからあまり、良いことではないですよね。
どうでしょう。最近このようなことは行ってないですよね。
設計書をきちんと記述する力を身につけること、お客様や仕様管理者へ自分の担当分の機能をきちんと確認してもらうことは、自分自身のリスクに回避になります。
最近、設計書のレビューが軽めに行われることにより、設計力が全体的に低下しているのでないかと個人的に思っています。設計書から製造するので、ちゃんとしたものでなければ、プログラム内も間違いだらけということも発生する可能性があるわけです。
プログラムレビューがなければ、結合試験時に設計書バグが発生するわけです。
また、過去のPJではコメントの数も報告対象としていました。(細かかったですね)
ページ毎にどのぐらいのコメントがあったのかによって、あまりにも多いと強制的に再レビューでした。また、担当者のスキルを確認する意味もありました。
1つ1つの作業を数値化して、対策を打つということが品質を高めるためには必要であると個人的には今でも重要だと思っていますし、必要なことではないでしょうか。
担当者の人は前回の数値を参考に次回のPJで品質を高めることも可能となります。
ドキュメントに関しては、お客様ごとにフォーマットも違うのですが、たくさん作成し、たくさんレビューをしてもらい、自分のドキュメント品質を高めてもらいたいと思います。