第51回です。
私はたいがいの場合は機嫌がよくて気のいい人間だと見えるように努力しているのですが、必ずしもそれができるわけではありません。まあ、人は怒ることもたまにはあるということです。
なんのことだかちっともわかりませんね。
◆効率化の気もはレビューにあり！
さて。
＞次に行うことは「レビュー」（技術的にな見方では「テスト」）です。
実は効率化はここが肝です。
「レビュー」に参加する人に、「レビュー」の意義をはっきり理解してもらわなければいけません。
- 初稿・再稿では全然内容のチェックをせず、最終的にＤＴＰ作業が終わったあとに、全体の構成変更を言う人がいます。
- 誤字脱字を発見すると、いちいち鬼の首を取ったかのごとく喜んでいい募ってくる人もいます。
正直に言うと、こういった人たちがマニュアルの生産性を下げているのです。
プログラムのレビューに置き換えてみるとすぐにわかると思います。
初稿・再稿あたりは、概要設計から詳細設計に入るあたりに相当します。
ＤＴＰ作業は、実際のコーディングに当たると考えてください。
コーディングがかなり進んだところで、概念レベルの仕様変更を言い出されると、何が起こるか。
「今までの作業結果は全部捨てる」ですね。当然スケジュールを大幅に遅れます。ですが、納品の日は決まっているため、大幅な無理が生じます。
当然ながら、無理な作業を行っているため、品質はそれに伴って低下します。
つまり、初稿・再稿のチェックは「概要設計から詳細設計に入るあたり」のレビューと同じだということを理解してチェックを行ない、後の段階ではフレームの変更を必要とするような修正がないようにチェックするのがチェックする人の役目なのです。
この部分を理解して作業をする必要があります。
2)については、言うまでもありません。
要するにバグ取りです。バグはあるものです。
そんなことでいちいちかさにかかって威張り散らされてもまったく価値はありません。
むしろ作業者のモチベーションをさげるぐらいのことです。
こういったことは事務的にさっと朱を入れて戻すのがスマートなことは言うまでもありません。
続きます。