■プロジェクトマネジメントの応用 １１（ソフトウェア開発編）
◆レビューを徹底する
①レビューはなぜ必要なのか？
プログラミングが終わってテストを始めて，その段階で設計漏れが見つかったと云う経験は誰しも経験済みのことである。自分ではこれで良かれと思って進めていても，１００％完全な設計ができることは先ず無い。そこで少しでも設計漏れなどミスを少なくする目的で，早め早めに実施するのがレビューであり，これを徹底することで品質を確実なものにし，後戻りの工数を少なくしようとするものである。
②レビューの進め方
レビューと言ってもいろいろなやり方があり，プロジェクトの実情などを十分考慮したやり方をするのが良い。しかし，目的はプロジェクトの成功を目指した品質向上や工数削減にあり，あまり人数が多く，発言しない人が大勢いるレビューは勧められない。それは，発言しない人の工数的なムダであり，よく見られるのがレビューか，内容説明か判らない会合である。内容説明が全く要らないことはないが，レビューとのバランスで考えるべきである。
プロジェクトの状況にも依るが，当該プロジェクトに関連するステークホルダーなど設計の早い段階で，参画して貰うことは必要で，基本設計から覆させられるような事態にならないように心掛けねばならない。設計工程が詳細な部分になれば，ステークホルダーよりも，同様のプロジェクト経験者など先輩諸氏の知恵を拝借してレビューの機会を設けるなども効果的である。ただ，レビューの目的をよく理解して貰い，注文を付けるだけの人，上から目線で建設的な意見を言わない人などレビューに相応しく無い人は，リーダが予め選定時点で排除しておくとよい。
ピアレビューと称して，詳細な部分はメンバー同士でレビューをすることは効果的である。お互いが部分的に知っている知識をぶつけ合いながら，建設的に改善を図ろうとするものであり，実質的なレビューが実施できることが多い。特に，プロジェクトを一緒に成功させようとする仲間同士であり，お互いが切磋琢磨しながらレビューを進めることは非常に有効である。
③レビューの効用１：品質向上
レビューの目的は，自分一人ではなかなかミスに気づかないところを，先輩の経験者やメンバーに見て貰うことによって指摘・修正されることにある。即ち，設計の早い段階でバグをできるだけ潰すことになる。そのままにしておくと，後工程のテストで発見され，バグを修正しなければならない場合や，さらにはバグがテストでは見つからず，市場でみつかり品質問題に発展するリスクがある。即ち，設計の早い段階で確実にレビューを行い，品質確保に務めることが重要である。
④レビューの効用２：工数削減（後戻り削減）
バグが後工程で（市場も含む）発見されることは，そこから設計段階に戻って修正することを意味しており，後戻りの工数が発生する。よく知られているように，後工程へ行けば行くほど，バグ対策の工数が増加する。レビューを確実に行うことは，こうした後戻りの工数を無くすことであり，費用面，日程面でも効果があるやり方である。
⑤レビューの効用３：設計ポイントの習熟（若手技術者育成）
レビューの形式はいろいろあるが，先輩経験者或いはリーダが参画することで，新人などが侵しやすいミスは確実に指摘を受ける機会が多い。そのことは，先輩としての経験で，どのようなミスが多いのか判っているからであり，言い換えれば設計のポイントを心得ているからでもある。こうしたレビューの機会の場面で，若手技術者は先輩から学ぶことが多く，同じようなミスを繰り返さないようになって行く。ＯＪＴとして，若手技術者を育成する機会として捉えると良い。
⑥レビューの注意点
- 計画に盛り込むこと（レビューが計画に組み込まれないと実施されないことが多い）
- 個人攻撃をしないこと（レビューはプロジェクトをスムーズに完成させるためで，ミスで個人を攻めることは弊害になる）
- 事前準備をすること（レビューする前には，事前にドキュメントを配布するなど，効率よく実施できるようにすること）
- ２H程度に区切ること（長々とやることは集中力が欠けることにもなり，時間を区切って集中するのがよい）
- バグや欠陥抽出に集中すること（バグの原因や解決方法まで論じ始めると時間がどれだけあっても足りず非効率）
- 上司の評価基準にしないこと（レビューでのミスなどの数値を評価などに用いると，レビューがし辛くなる）
- 形式的な実行にしないこと（ルールでレビューが決まっているので，形式的にやった振りをするなどは無意味，ムダ）
⑦記録を残しておく
レビューは上述したような効用があり，バグ発見にはテストよりも効果が大きい場合がある。したがって，レビューした記録を残しておくことが望ましい。レビュー記録のテンプレートを作って，品質向上に役立てることが大切である。バグのフロントローディングには，大いに役立つことになる。指摘内容には，バグの指摘だけでなく，質問のような内容もあり，事前にテンプレートなど整理できるシートがあると便利である。
テンプレートの例を次に示す。（６～８はレビュー終了後の整理段階で活用）
- 実施日時・時間・場所
- 実施メンバー
- レビュー対象・機能・範囲
- 指摘内容
- バグ対策の必要性の有無
- ミスの事象（どのような事象か，予め分類表を決めておくと効果的）
- 発生の原因（なぜ発生させたのか，これも分類表があるとよい）
- 流出の原因（どうして漏れてしまったか，これも分類表があるとよい）
[Reported by H.Nishimura 2011.08.26]
Copyright (C)2011 Hitoshi Nishimura
