読者です 読者をやめる 読者になる 読者になる

mhlyc -presentation

ソフトウェアテスト、品質に関わること、たまに変なことを書いていくブログです。

初心者が設計書をレビューできるようになるには

ソフトウェア品質 レビュー

初心者が設計書をレビューできるようになるには 

最近、仕事で設計ドキュメントのレビューを行うことがあります。

設計書を渡されて、ドキュメント間で不整合はないか、考慮漏れがないかとかいうことを調べて、指摘します。

しかし、自分はこのドキュメントレビューという仕事が苦手なようで、「読めばなんとなく仕様がわかるし、いっか」と言って不良を見逃してしまうことが結構あります。

最近このことで怒られたので、「どうしたらレビューで指摘を多く出せるのかな?」と考えるようになりました。

 

 

チェックリストを使え、という話には裏がある

ある程度大きな組織であれば、観点リストであったりチェックリストであったり、名前は様々ですがチェック観点をリストアップしたものがあってそれを使おうという教わり方をすることがあります。

ですがこの話には裏があります。

「チェック観点を教えるとは言ったが、チェックの仕方を教えるとは言っていない」

チェックリストを見れば、何をチェックすればいいのかがわかります。書いてあるのですから当たり前です。

しかし、問題があります。それは、「どうやってチェックすればいいのかはチェックリストに書いていない」ということです。僕はこの罠にはまっていることになかなか気づけませんでした。

例えば「ドキュメント間の整合性を見る」というチェック項目があったとします。

これを知ってドキュメントを読むとしても、例えば

 

初心者:設計書を一つずつ開いて読む

ベテラン:設計書を複数見比べながら読む

 

というように、実は読み方が違っています。

同じチェックリストを使っていたとしても、新人君とその隣のベテランさんではドキュメントの読み方が違います。

そして、そういう具体的なやり方については「どうやって見たらいいんですか?」と具体的に質問しないと教えてくれません。

それは先輩が不親切だからなのではなくて、単純に当たり前だと思ってやっているから教える必要があると認識されていないだけです。

チェックリストを通じて教育を受ける

チェックリスト単体でチェックができるようになるわけはありません。そんな簡単だったら先輩方も後輩の育成に苦労していません。

チェックリストの意図と使い方をしっかり先輩に聞きましょう。そして、まずは言われた通りにやってみることです。

「なぜ指摘が出せないんだ」などと怒られた時はむしろチャンスです。怒ってくださった先輩に読み方を聞いてみましょう。「行間を読め」などという曖昧なことを言われても諦めずに、具体的な方法まで聞き出せるとすぐに実践できて良いです。

レビューに関する書籍

下の書籍はレビューについて研究されている森崎先生の著書です。シナリオを用いたレビューについて言及されており、複数の観点で分けてドキュメントを読んでいくというやり方はとても勉強になります。