今回は、毎月購読している日経SYSTEMSからの読書メモを載せてみる。
レビューはどんな形であれ、必ず一度はやるものだが、如何せんこれといった教書もない。そんな中でなるほどなと思ったことを記事からピックアップしてみた。ちなみに、現在、レビューに関する講座が連載中（筆者はこちら検証ラボの人）なので、こちらも中々面白い。
意味のあるレビューにするには？
- 誤字脱字を無視すれば重要な指摘に注力できる
- 表記に関する指摘の多くはテスト工程で見つけたとしても修正コストはほとんど膨らまない
- レビュー実施前にレビュー観点を絞り込む
- プロジェクト固有のものにする
- 定量的な観点の絞り込み
- 過去の不具合出現ルールを分析しておく
レビューで指摘することは？
問題検出に入る前に、レビューの観点を設定し、レビュアー全員で共有しておく。さまざまなレビューに共通する着眼点として、漏れ、誤り、曖昧さなどがある
- 漏れ：記述漏れと検討漏れ
- 誤り：他の箇所や対象ドキュメント以外で定義した内容との矛盾や不整合
- データ定義の不整合など
- 曖昧さ：読み手によって解釈が異なる記述
- 性能記述は数値を明確化
- 最新の・・・→どの時点で最新のものかを明記 ドキュメントの内容を事前にイメージしておくことで、漏れに気づきやすくなる
レビューでやってはいけないこと
- 人間関係を持ち込む
- 問題検出に人間関係を持ち込むとドキュメントを見る目が厳しくなったり、甘くなったりする
- 対策
- 繰り返しレビューの目的を再確認する
- 作成者気分でやる
- レビュアーがドキュメントを作りなおすと問題検出がおろそかになりがち
- 対策
- 優れた代換案を提案するより、重大な問題を見逃さずに検出することの方がレビュアーにとっては優先度が高い
- 二兎追い
- レビューの観点が複数あるとき、それらの観点で一度にまとめてドキュメントをチェックしようとするとうまくいかない
- 対策
- 類似する観点は一度でもOKだが、基本的に何度か分けてチェックする
- 時間切れ
- 問題検出の序盤に時間をかけがちで終盤は時間切れになることがある
- 対策
- 前工程や後工程の視点でチェックしてみる
効率よく問題を検出するには？
- レビュー会議は日中の時間帯に開催する
- 日中の方が集中力を維持しやすい
- レビュー会議がダラダラと長時間化しない対策 → 長くても３時間程度
- レビューが長くなりそうな場合、予備日を設けておくのもアリ
- 感情的な議論になった場合は放置しない
- 進行役はもちろん、他のレビュアーも事態の収拾をはかる
- 意見の対立点を整理したり、休憩したりするのがよい
- レビュー会議を終了する際、指摘された問題を基に関連する問題を見逃していないかどうかを調べる
- レビューの最後に、指摘された問題一つひとつを振り返り、対応方針を決めた上で、修正作業を割り当てる
間違ったレビューの指摘
- 間違いその１ 意地の張り合い
- レビュー会議はレビュアー同士が意地を張り合う場になりがちである。技術的な補足情報を話す場合は、会議終了後に関係者だけ集めたい。
- 間違いその２ 人格攻撃
- 人格攻撃はレビューの目的から外れている。ドキュメントの内容や作成者の態度がひどくてもレビュアーはドキュメントの問題を指摘したい。
- 間違いその３ 意図的な見逃し
- 見つけた問題の修正によるスケジュール遅れなどを気にして、意図的に問題を見逃せば、修正工数が膨らんでいくだけで逆効果である。
- レビューされる側の駄目な態度
- 他人ごとのように受け流さない
- 感情を高ぶらせて反論する → 逆切れ厳禁
- レビュアーの指摘内容を論評する → 瑣末な問題ですね、等
レビュー技法
- ウォークスルー
- 作成者が主役のカジュアルな相談会
- レビューの主導権はドキュメント作成者
- チーム内の意識合わせにも利用できる
- テクニカルレビュー
- 技術リーダ主導のチェック
- 進行役と技術リーダが主導
- インスペクション
- ルールに従う厳格チェック
- ドキュメントから網羅的に問題検出をするのに大きな効果を発揮する
- 進行役が主導
- ルールを定義し、対象ドキュメントは予め査読してもうう必要がある
レビューの意外な検証結果
- 検証の結果、ベテランの方がレビューにかかる時間は少なかった
- ただ、指摘品質レベルにはさほど差はつかなかった
- レビュー対象にあわせて方法を変えると効果的
- 変更箇所が多い場合（ファイル数が多数）はPCの方が速くて正確
- 変更箇所が少ない場合は紙の方が効率が良い
- チェックする箇所は、新旧ソースコードの差分に関連する周辺部分までチェックすると品質レベルが高まる → しかし時間はかかる
参考資料
2011.5月号 こちら検証ラボ 意味あるレビューに改善できる？
2011.5月号〜9月号 間違いだらけのドキュメントレビュー
2011.12月号 こちら検証ラボ 開発経験が長いとレビューは速く正確か
