レビュー上手になるための8つのポイント

コードでも設計書でも他のドキュメントでも上手に作れるようになるためには、自分一人でいくら頑張ってもぶっちゃけダメです。レビューをするレビューア側もレビューをお願いして受けるレビューイ側もより上手な優秀なレビューアに自分がコテンパンにコメントを付けてもらうのを対面でしてもらうのが一番成長します。

どうしてレビューアもレビューイも同じでいいのかと言うと、レビューアはレビューアとしての責務を果たすためのqualifyとしてのベースとなるスキルとして備わっていることが前提だからです。レビューイは、レビューアはどういった視点でレビューイが作ってきたアウトプットを見ているのかを知ることで、自身が作るアウトプットに対してレビューアになりきって見返すことでセルフレビューの質を上げられるからです。

観点は必要ですから
よく言われるのが「観点を持つ」ということです。文書レビューなら文書に対して何が記載されていれば合格とするか、ということです。観点を持っていない人の指摘の多くは事前に文書を読むという準備をせず、その場で、自分の経験に基づいて、思い付きだけで指摘をします。これでは、文書の深刻な抜け漏れなどには到達できないです。だって、文書の理解をしていないのだから。こうした観点の無いレビューは、見た目ばかりになるので、「てにをは」だったり、ちょっとした言い回しばっかりを指摘することになります。また、経験と思い付きだけで指摘をするから文書の体系的な整合性を見ることはないです。というか、出来ない、ということでしょう。

体裁だけを見るのか、文書の記載事項に対するリスクの識別をするのか、充足性を見るのか。文書を観る前に、観点は決めておかなければなりません。

観点はレビューイ側から言語化して伝えてね
観点はレビューイ側から言葉で伝えた方がいいです。「システム方式が要件を満たしているか技術の観点で見て欲しい。」とか「見積もり条件の充足性や潜在的なリスクの見落としがないか見て欲しい。」とか。「全部の観点でみて。」は散漫になるのでそういった頼みかたは止めた方がいいです。

こうした頼み事は直前であっても資料を送るときに一言文字に起こして伝えておく方がいいです。文字、言語化することで観点の勘違いを見つけられるからです。

思い付きでやらない。いつも同じようにやる
レビューイからのレビュー観点に基づいてレビューしますが、レビューでのファシリテーションはパターン化しておいた方がいいでしょう。それは、観点があるとしても全体や個別のそれぞれで見るものがある程度決まっているからです。

これも思い付きでレビューをしないということの防止でもあります。

モノ言いつけるんだから根拠と説明責任はあるよ
レビューアはレビューイのアウトプットに対して、物言いをするわけです。でも、思い付きでは物言いをしてはいけないし、すべきではないです。きちんと指摘、コメントを付ける根拠が必要です。「前のページと整合性が取れていない。」「前提条件が矛盾している。」などなどアウトプットのコンテンツの中での指摘であるとか、ガイドラインからの逸脱とか、客観的に差異がわかるような指摘の仕方がいいです。

後工程を自分でやるつもりで
レビューイはもちろん、レビューアもそのレビュー対象のアウトプットを次工程のインプットにする作業を「自分でやるつもり」で取り組みましょう。自分が次工程を受け持つなら、俄然、身の入り方が違いますから。そう、自分を当事者にしてください。その意識のないレビューアのいい加減さ、といったらひどいものですから。

キビシイなぁ、と言われるくらいに
「キビシイなぁ。」とレビューイから言われるのは指摘、コメント、ツッコミであって、言い方とか態度ではないです。痛みを感じるツッコミは、本質をついているから。

コードとか文章表現であれば、理解しやすさとか誤謬を招かない書き方とか、サンプルコードや事例と比較してあげるのがいいでしょう。

指摘は押し付けない。理由を聞き指摘の本質を見失わないところに座らせる
レビューをするのはアウトプットに対してですが、そのアウトプットに対しての指摘を受けれいるかどうかはアウトプットのオーナーであるレビューイの判断によります。そこを忘れてはいけません。

だから、指摘やコメントをつけるなら、押し付けるのではなく相手に受け入れてもらえるように必要に応じて説明したりすることが必要になるわけです。ただ、レビューイ側の事情もあって指摘をそのまま受けれられないこともあるので、指摘の本質が失われない程度に落としどころを探す作業をレビューイと一緒にすることも必要な時があります。

やったあとに雰囲気が悪かったら個人攻撃をしていたということ
もし、レビューをした後、雰囲気が悪くなったら、それは、相互にアウトプットに対するレビューをしていなくて、アウトプットを超えて作成したレビューイの個人攻撃と自己防衛になっていたから、です。

レビュー観点は人ではないはずです。