お盆休みのためか、道路の車や町の人がずいぶん少なくなっていました。
ただ、今年は例年に比べるとずいぶんと涼しいように感じます。
もっとも、去年までの暑さが異常だったのだとも思いますが。
さて。
◆マニュアルのレビューとソフトウェアのレビュー
前回の続きです。
「マニュアルのレビューはソフトウェアのテストと同じ」
こう考えるべきというところのまででした。
そして「テスト仕様書」に相当するものが必要であり、レビューをする人は全員それを知っておく必要があると書きました。
しかし、それだけではまだ十分ではありません。
仕様書があっても、それを読む人の責任範囲が正しく規定されている必要があります。
最初のレビューの仕様書には「1.主な機能がすべて盛り込まれている」と書かれているとし（本当はこんな曖昧なものでは役に立たないのは言うまでもありません）、とりあえず最初のレビューはこれで通ったとします。
しかし第２回目のレビューの時に「主な機能のひとつが入っていないじゃないか」というクレームが来たとします。普通であれば、マニュアル制作では担当者が怒られてそれで終わりです。
しかしそれではマニュアルの制作工程はいつまでたっても改善されません。
レビューに参加する人が責任感をもって参加してもらわないと、意味がないのです。
仕様自体が変わって、主な機能が追加されたのならば仕方がありません。こうした場合には開発セクションから情報が追加され、マニュアルの２稿で対応といった形になります。
しかしそうではなく、仕様が変わらず、初稿では「問題なし」として通していたチェックを後から覆すのであれば、それはマニュアル制作部門のみの責任ではなく、チェックをした部門にも同等の責任があるということを明確化する必要があります。
こういったレビューの失敗による手戻りの発生、スケジュールの遅延、予算のオーバーなどは「レビューした人がレビューの結果に責任を持たなかったがために発生した。」ということとがあると参加者全員に理解してもらう必要があります。
続きます。