森崎さんのブログに興味深いエントリがありました。
設計ドキュメントのうち、実装時に生まれたバグがテスト工程で発見された場合に修正コストが大きくなりそうなものから優先的にレビューしていってはどうか?ということが考察されているようです。
設計ドキュメントのうちどこからレビューしていくかということについて、以前自分はこのようなアイデアを思いついたことがあります。
ドキュメントを作った時の集中度合いはひょっとしたら誤字脱字(またはオートシェイプのズレや表記ゆれ、段落など体裁の不均整)などに現れるのではないか?
もしこのとおりであるならば、全体を適当なブロックに分割した上でドキュメントの誤字脱字を集計することがレビューの最初の作業になります。ブロック内の文字数における誤字脱字の割合などを数値化し、「やる気の無い箇所」を発見して優先的に処理する(もしくは処理せずに差し戻す)という対応をとることができるのではないでしょうか。
これは以前に森崎さんが案内されていたアジャイルインスペクションの勉強会に参加した際にソニーの永田敦さんと森崎さんから教えていただいたことがヒントになっています。また、私自身の実体験として
- レビューの参加者が多いと誤字脱字などの枝葉末節は指摘しづらい(しかし指摘しないといつまでも残っていることがある)
- 誤字脱字の多い箇所はまずいことが多い(反面、素晴らしいアイデアが生まれたノリで書き進めた場合もある)
- (目上の人の誤字脱字は口頭だと意外と指摘しづらい。多いと一層。)
ということがあります。よって実際に行う場合は
- できるだけ多くの人で誤字脱字をパラパラーっと探す(重複するように)
- 検索結果を集計する
- スコア毎にレビューの優先順位を決める
という形になるのではないかと思います。これにより事前に資料を読ませることができます。「どうせバレないので資料を読まない」という状態でレビューに参加する人を減らせるかもしれません。また、誤字脱字の指摘からレビューに入るまでに文字の校正だけ先行して行っておけば、設計ドキュメントの内容に集中できると言うメリットもありそうです。
ひょっとすると上席者や学校の先生などは自然にやっていることなのかもしれません。文章を書くのが仕事である記者の方はどうなのでしょうか?
Special
- PR -| 森崎 | 2010/01/10 02:41 |
|
山口さん 言及いただいて、ありがとうございます。 ソースコードだとコーディング規約に違反している部分は、バグが出やすいというような調査結果は他所で論文になっています。 | |
| yohei | 2010/01/12 23:48 |
|
森崎さん、コメントありがとうございます。 | |

富士通元社長の山本卓眞氏が残した次代へのメッセージ
Facebook就活はもう古い?
東北をコットンの生産地としてブランディングしたい──リー・ジャパン・細川取締役
東北から始まるイノベーション
貧困国の雇用を創出する印刷屋、丸吉日新堂印刷の挑戦