レビューの効果を上げる方法について

経緯

今かかわっているプロジェクトに限らず、自社ではウォーターフォール型の開発でほとんどのプロジェクトが進んでいます。

ウォーターフォール型の開発手法に云々言うつもりは全くないのですが、最近良く感じるのが、可能な限り「手戻り」を発生させることなくプロジェクトを円滑に進めることができないか？という事です。

各工程においてレビューを行ったにもかかわらず、

• 詳細設計の段階で問題が発覚したり、
• 製造が完了した後に仕様変更があったり、
• システムテスト、運用テストにて、運用に耐えることができない仕様であることが発覚したり

と、大小さまざまな問題に遭遇します。

ウォーターフォール型の開発に限ったことではないと思いますが、システムが出来上がってくる後工程になればなるほど、問題への対応が難しくなってきます。
（問題に対応するための他への影響度であったり、納期であったり、人の手配であったり・・・）

そうした対応を余儀なくされる状況を減らし、各工程の本来の業務へ集中することで開発するシステムの品質向上に結びつけることができればと、解決方法の1つとして、「レビュー」に関して着目してみました。

問題点

現在の自社の「レビュー」の問題点として、特にウォーターフォール型で言われるところの「上流」工程において、

1. レビューアが多忙で捕まえずらい
2. レビューのアウトプットがない
3. レビューの観点が明確でない

の3点が上げられますと思います。

解決策

これまでの自身がレビューイとして、

1. 誰が
2. 何を
3. どのような方法で行い、
4. その結果として何が得られるものか（何を得たいのか）？

を明確に意識して、レビューに望んでいなかったことは棚に上げておきます。

また上記1については、そもそもマネージャーがマネジメント業務を行わず、現場よりの業務をメインとしてしまっている！など、今回考える問題点とは別の問題点がありますが・・・。

問題点2について

忙しいレビューアをようやく捕まえ、レビューを実施したにもかかわらず、レビュー後に残っているのは、疲労感とレビュー指摘事項の乱雑なメモ書き（口頭で指摘のあったものをメモしたもの）だけではその後の工程にきちんと望むことなどできません。

ドキュメントとして残しておけるようなものを作成することで、レビュー参加者の共通認識として形に残すことができ、後工程でさまざまな決定を下すための判断材料として利用することも可能だと考えます。

問題点3について

今回、この「レビューの観点」について、特に「詳細設計」　⇒　「製造（プログラム）」の工程で感じた点を記載したいと思います。

これまでのレビューでは、レビューアに詳細設計を披露し、記載内容に対してレビューアが気になった点を指摘する、というようなレビューアに依存するレビューとなっていました。

レビューアに依存するため、指摘される事項はさまざまであり、後工程になってレビュー時には話題にすらならなかった問題点が出てしまうということも出てくる有様でした。

こうしたレビューアに依存するレビューではなく、あらかじめレビューを行うための観点を明確にし、レビューアの意識を分散させることなく後工程へとつながるレビューとすることができるのではないかと考えます。

今後

各工程におけるレビューの観点の明確化をすすめ、アウトプットすべきものを整理し円滑に業務が進めるよう試行錯誤してみたいと思います。