終わったあとに良いレビュー会だったと思えるためにしておくこと


とある日のレビューでファシリテーターを任されたレビューが終わったあとに想像以上に我ながら「良いレビュー会だったなぁ。」と自己満足できたので、そのふりかえりをすることで、みなさんの参考になれば。あーでも、その後のレビューは通常運転というかイマイチで先のレビュー会と比較すると雲泥の差だなぁと感じてしまうこともあったので先は長いかも。


資料は事前に査読する
レビューのお作法を改めて読み返してから、レビューの資料は事前に配布してもらうようにお願いしている。最遅でも1時間前には手元に届くように。レビューイが資料の事前配布は間に合わないと言ってきたら、「直前に差し替えられても構わないから。」と言ってでも途中版を貰うようにしているのです。


資料は複数あることが多いので、まずはzipを開くか、フォルダを作って一旦査読対象の文書を並べて開くのです。だって、ファイル名の付け方が個性的ですからねぇ。レビューによっては提出が必須の文書もあったりするので出欠確認も兼ねていたりします。で、次は印刷です。ワタシの判断基準で必要と思うものは全部印刷してしまう。


揃った資料をレビュー目的に沿って読み、

  • 記述の不足、
  • 解釈の判別が付かない記述、
  • 資料上複数の解釈が出来る記述


を中心に文章の引っ掛かりがあるかないかを探します。いや、違うな。読んでいると勝手に引っかかるんですね。ここオカシイ、と。そう言った箇所があれば、ペンを入れていきます。下線を引いて、「これどっち?」とか「○○の範囲が漏れている。」とか。あとで自分が読むので達筆な筆記で、ですけどね。


大切だ!と思っているのは全体の構成ですね。兎角、エンジニアが作成する資料はボトムアップで積み上げることが多いんですけど、そうすると思いついたところから書いていくし、思いつくだけ強く思い入れがある分そこだけ子細に記述するんですよね。そうした思い入れがある部分と逆に全く思い入れがない部分で記述に差がついて、不整合が生じるんです。そう言ったところも読んでいて引っかかる箇所ですね。


ペン入れをしながら気を付けることは、その指摘をしたあと「どうして欲しいか。」という意思を決めておくことです。「記述がダメ。」なら単なる批評家でしかないのでレビューされる側には迷惑なだけです。レビューアとしての価値はゼロだと思っています。

  • 記述しなければならない項目が抜けているから「○○」を追記してください。
  • 一覧で不整合があるから1行足して抜けている項目を記述してください。
  • 表現が曖昧なので△△と記述を変えてください。


と指摘の意図が伝わるように伝えることで初めてレビューアの価値があると、ワタシは思うんです。


査読結果を事前に伝える
査読したら、レビュー時に伝えればいいじゃない?と思うかもしれないけれど、レビューイとなるエンジニアは様々な経験をもっている人たちだったりします。若手もいればベテランもいる。若手でも要所をわかって書いてくる人もいれば、ベテランでもホントにベテランが書いたの?っていう資料だってある。


だから、レビューの場で査読結果を伝えるとその指摘の理解が期待するように理解してもらえない可能性があるわけです。伝えた後のことは「レビューイの仕事だから。」と切ってもいいんですが、レビューイが理解できていなければ理解できるまでループに入るわけです。それって嫌だなぁ、と思うのです。まだ、「これなんでしたっけ?」と聞きに来てくれればいいのですが、理解不足のまま修正して傷口を広げてみたり、とか。


なので、メールで査読結果を事前にお伝えします。「資料のここを□□に変えて欲しい。」とか。


事前にメールで指摘事項を伝えることでもう一ついいことが。それは、指摘したい思いを文字に変換することで感情の成分が抜けるんですね。で、文字で書くので伝わることを気にすることで悪い、ダメだ、と書くことをしなくなって、こうしてほしい、と伝えわることを優先に書くようになる。これがいいです。変に熱くならなくなるのでね。


レビュー会の要点が絞られる
こうして、事前に査読結果を通知しておくので、レビュー会では指摘事項を中心に運営されることになります。

  • 不明点について記述の意図を説明してもらう。
  • 記述が不足している理由をレビューアから説明して理解してもらい、納得したうえで記述を充足してもらう。
  • 構成上の問題を伝え、再構成を促す。


出来が悪ければ、再構成まで求めることもあるけれど、物は言い方です。「後ろの章の半分を前の章とマージした方が同じテーマがグルーピングされて理解しやすくなるから。」とかね。


レビュー会で運営が事前にメールした指摘を中心に進むから、指摘する側に思い付きで指摘をすることが大分減ります。これも大きいですね。その場で斜め読み、指摘のコンボはその場で指摘をしなければいけない分、指摘自体の抜けも防ぐことができないし、指摘も瑣末なことが中心になって双方がレビューの目的を失ってしまう。これでは意味がないですよね。それを査読の指摘を事前にしておくことで、防止できるんです。


あと、指摘のメールも「どうして欲しいか。」で書いておいて、レビュー対象の文書の不明点を中心にレビューイに説明してもらうと、双方が何について会話しているのか同じ話のテーブルに着くまでが早くなるんですね。で、レビューイが説明する記述の意図も理解はできるし、レビューアが指摘することに対してレビューイも「なぜ」が理解できる。ここでレビューイ側の納得感が生まれるみたいです。


こんなやり方のレビューもいいですよー。