レビュー方法

下書き書いたのに、保存できていなかった（涙）

先日、後輩からレビュー方法について質問されたので、

一般的？なレビュー方法をまとめようと思います。
（自分が経験してきたレビュー方法）

レビューの流れとしては、以下のようなステップで行われます。
　①レビューイ（自分）が、レビュー者にレビュー依頼をする
　②レビュー者がレビュー指摘をして、レビューイに返却
　③レビューイが指摘箇所を修正し、再レビュー依頼
　④レビュー者が修正されていることを確認。

で、レビューの仕方は大きく分けて「書面レビュー」「対面レビュー」の2つがあります。

書面レビューは、レビュー対象物とレビュー記録表をレビュー者にメールなどで送って、書面上でレビューを行う方法。

対面レビューは、レビュー対象物をレビュー者にプレゼン形式で説明し、対面でレビューを行う方法。この方法ではレビューイが説明しながら行うため、レビューイとは別のレビュー記録者がレビュー記録表を作成する。

それぞれのメリットとデメリットについて、記載します。

対面レビューの方が詳細に説明できるが、会議招集するため時的拘束が発生する。

書面レビューの方は詳細な説明はできない代わりに、自由な時間にレビューができ時間的拘束がない。

上記のような特徴があるため、要件定義などは対面レビューで行い顧客としっかりと認識を合わせ、詳細設計書などは書面レビューでレビュー者の任意の時間にレビューしてもらう。というような使い分けをしている現場が多い気がする。

それぞれ補足していく。

①レビュー記録表の準備について

レビューしてもらう際は、レビュー記録表を作成する必要がある。この資料は、いつ

誰がどのような指摘をしたのか、記録するためのもの。レビュー記録表があれば、再レビューする際に、どこを見ればいいかわかるでしょ？

レビュー記録表のフォーマットのポイントは、「いつ誰がどのような指摘をしたのか」「いつ誰がどのように修正したのか」「レビュー者はいつ修正されたのを確認したのか」。現場によってフォーマットがあるので、基本的に気にする必要はない。

②説明する要点をまとめる（対面レビューの場合）について

プレゼンなどする時はやると思うが、プレゼンの中でどこが重要なのか考え、それについてどのように説明したらわかりやすいか、まとめておきましょう。

例えば、「～～のロジックは一見不要に見えるが、－－のために必要なんです。」みたいな感じ。

③レビュー対象物のバックアップを保管について

レビューの指摘事項を修正して、再レビューをお願いする際に、修正前後のファイルがあるとレビューしやすい（特にコードレビュー）。そのため、修正前のファイルはバックアップをとっておこう。

④自己レビューについて

レビュー者（上司のことが多いと思う）の時間を割いてもらってレビューをしてもらので、完成度の低いレビュー物を提出することは失礼。

レビュー前に、誤字・脱字がないこと、資料のフォーマットが正しいことなど、基本的なことは確認が必要。

私が以前いた現場の対面レビューの流れを説明。

※その現場では、コードレビュー・UTのテストシナリオレビューをしてた。

①概要の説明

　どういう機能のレビューをしてもらうのか説明。この際に、作成した画面を実際に動かしたりすると、レビュー者が機能のイメージをつかみやすかったりする。

②コードレビュー

　修正前後のコードをwinMergeで表示して、どのように修正したのか比較しながら説明する。この際は、自分のコードについて正しく理解して、説明する必要がある。わからない場合は長考せずに、「確認しておきます」と伝えてる。

③UTのテストシナリオレビュー

　テストシナリオの説明をする。この際に気を付けることは、テストシナリオを大まか説明してから、詳細のテストシナリオを説明していくこと。テストシナリオの大まかな説明としては、マトリクスを事前に作成しておくとわかりやすい。

　例えば、flg1とflg2の条件文章を追加した場合、以下のようなマトリクスを作成しておき、「このようなマトリクスをベースにテストシナリオを作り、それぞれの商品ごとにテストを実施しています。」みたいな説明。（下手なテーブルですんません）

思ったより長文となったけど、とりあえずレビュー方法はこんな感じ。