オルタナティブ・ブログ > 一般システムエンジニアの刻苦勉励 >

身の周りのおもしろおかしい事を探す日々。ITを中心に。

誤字脱字でドキュメントの品質を測る

»

森崎さんのブログに興味深いエントリがありました。

http://blogs.itmedia.co.jp/morisaki/2010/01/--d282.html

レビューの優先順位を決める技法:森崎修司の「どうやってはかるの?」:ITmedia オルタナティブ・ブログ via kwout

はてなブックマーク livedoor クリップ Yahoo! ブックマーク

 

設計ドキュメントのうち、実装時に生まれたバグがテスト工程で発見された場合に修正コストが大きくなりそうなものから優先的にレビューしていってはどうか?ということが考察されているようです。

設計ドキュメントのうちどこからレビューしていくかということについて、以前自分はこのようなアイデアを思いついたことがあります。

ドキュメントを作った時の集中度合いはひょっとしたら誤字脱字(またはオートシェイプのズレや表記ゆれ、段落など体裁の不均整)などに現れるのではないか?

もしこのとおりであるならば、全体を適当なブロックに分割した上でドキュメントの誤字脱字を集計することがレビューの最初の作業になります。ブロック内の文字数における誤字脱字の割合などを数値化し、「やる気の無い箇所」を発見して優先的に処理する(もしくは処理せずに差し戻す)という対応をとることができるのではないでしょうか。

これは以前に森崎さんが案内されていたアジャイルインスペクションの勉強会に参加した際にソニーの永田敦さんと森崎さんから教えていただいたことがヒントになっています。また、私自身の実体験として

  1. レビューの参加者が多いと誤字脱字などの枝葉末節は指摘しづらい(しかし指摘しないといつまでも残っていることがある)
  2. 誤字脱字の多い箇所はまずいことが多い(反面、素晴らしいアイデアが生まれたノリで書き進めた場合もある)
  3. (目上の人の誤字脱字は口頭だと意外と指摘しづらい。多いと一層。)

ということがあります。よって実際に行う場合は

  1. できるだけ多くの人で誤字脱字をパラパラーっと探す(重複するように)
  2. 検索結果を集計する
  3. スコア毎にレビューの優先順位を決める

という形になるのではないかと思います。これにより事前に資料を読ませることができます。「どうせバレないので資料を読まない」という状態でレビューに参加する人を減らせるかもしれません。また、誤字脱字の指摘からレビューに入るまでに文字の校正だけ先行して行っておけば、設計ドキュメントの内容に集中できると言うメリットもありそうです。

ひょっとすると上席者や学校の先生などは自然にやっていることなのかもしれません。文章を書くのが仕事である記者の方はどうなのでしょうか?

Comment(2)