この暑苦しい中で - are you happy?

それなりの経験を経て、ドキュメントとかコードとかをレビューする場面が多くなった。レビューの目的はその成果物の品質向上が目的だと思う。『思う』と書いたのは、レビューの際に目的として『教育（むしろ指導？）』も含まれる場合が多々あるからだ。過度な指導は、品質向上にならずにむしろ隠蔽体質方向になると感じている。ここ最近過度な指導を見かける場面が多いので、少し考えてみたい。（コードレビュー特有の事は書いてませんし、意見がかける自信が無い）

1. レビューの基礎知識

システム開発の中でレビューと言うと以下の２つに分類できる。

プロジェクトを推進するためのレビュー
品質に主眼を置いたレビュー

１は『プロジェクト』全体がどうだったかとかをポイントごとに確認しあったりする事だろう。そのポイントは規模によって変わってくるものになる（進捗会議的なもの含む）。

2に関してが、今回色々振り返りたいレビューについてだ。参加者や記録の取り方などで複数の方法がある。

インスペクション
ウォークスルー
チームレビュー
パスアラウンド
ピアレビュー
ピアデスクチェック
ペアプログラミング
アドホックレビュー

こんなにあるんですね。。。これまで『なんとなく』会話していた事が”ピアデスクチェック”だったりしたんですね。

インスペクションが一番高コストで、アドホックが一番低コストとなっている。ここで言うコストとは、参加者の人数、事前準備が必要かどうか、実施中に記録をとる必要があるか、指摘事項を追跡する必要があるかどうかと言った、関係者がかける”時間”の事を言っている。

まずは同じチームで開発するにあたって、この辺りのレビュー手法についての基礎知識は合わせておく必要があるのだろうな。用語が与えられて初めて意味を理解するようなイメージである。

2. 実際のところは？

今回、いくつかレビューを紹介しているサイトを読んでいると割と『表現の良し悪しをレビュー時に指摘しない』と書かれているものがあった。まずはこの事について、私自身が感じている対処をかいておきたい。

・誤字、脱字

　人によって、この指摘が多い場合が存在する。これが多い場合はレビュー時間が長くなり、指導の側面が強くなる。多いメンバーには自覚してもらい、全員を集める前に一度マメな人間にチェック、指摘、修正してもらう方が良いのだろう。

・体裁

　これも多くなると指導の側面が強くなる。個別の成果物の構成とか表現とかには工夫の必要性が無いはずだ。ある程度共通化しておく必要性があるし、チーム共通の暗黙的な約束事はルール化しておく必要があるのだろう。ちょっとした図を書く際でも、左から右への構成をとるのか、上から下への構成をとるのか、強調する際の色合い、表形式の場合とか。こう言ったルールを守れない場合には、もう少し噛み砕いて説明し、練習させる場面が必要なのだろう。

・伝え方は？

　つい自分も乱暴な言い方をしてしまう場合がある。それに自分が正しいと言う前提で言ってしまう場合がある。厳しい言い方をして通じる場合もあるように見えるが、結局は相手が萎縮してしまい、その後のコミュニケーションコストが上がってしまうと感じている。

・修正されているかの確認は？

　これが１番の悩みどころだ。最低限の本質的なところだけを指摘していても、伝わっておらず、次回確認したら修正されていないって事が度々ある。その時のNGワードが『以前言ったよね？』、『２回目やで！』とかである。やはりもう一度、指摘の意図を丁寧に伝える必要がある。その場で、相手がしっかり理解できているかの確認が大事なのだろう（それもあるので軽微な指摘をしないようにするのが有効なのだろう）。どうしても度々起こるようであれば、まずは『記録する』文化を持っていない可能性がある。これが出来ない方は、ほぼ100%修正される事は無い。記録もできていないようであれば、逆に指摘事項をまとめて記載したものを渡して、ひとつづつ指摘を潰して行く経験を一緒に積むのが良いと思う。こう言った段階を踏んでいけば、良い意味でのあうんの呼吸がチームでも生まれてくるのだろう。

・場所、時間

　自席でする場合も多いが、集中するためにもやはり打ち合わせスペースでした方が良いだろう。あと、始める時間も多少余裕を持って進める時間にしておくべきだし、集まってするのは長くても１時間以内にすべきだ。そこまで時間をかけるなら、事前に各自資料を読み込む時間をとる事や、軽微な指摘をまとめて後で共有すると言った事にした方が良い。また、重い指摘事項は記録に残して、後で個別に対応する事にした方が良い。時間が解決してくれる場合も多々ある。

3. 大事な事は

やっぱりメンバーの成長を促す事は過度な指導は良く無い。それならば決まり切ったレビュー作法（原則）を共有して、それを守ってもらうように合意していく事が大事なのだろうな。完全に要件を満たせていない、設計書、コードの部分的な事に疑問を呈すぐらいのレビューが一番理想なのだろう。その指摘事項は後から必ず担当者が解決する前提として。大きく方向性に誤りがある場合には、そのような場面になる前に仕事を依頼する側がこまめに大枠をチェックするべきなのであろう。また、どうしても大方針の誤りが続く場合には、前向きな教育を十分にすべきだろうな。