レビューの目的を設定して、レビューを建設的にしよう

最近レビューについては、どのようにやっていけばいいのかなーと思うことがあって、 本を読んでいくことにしたところ、 ある本にとても良いアイデアがあったので、紹介したいと思います。


今回読んだ本はこちらです。


そのアイディアとは、レビューの目的を『修正工数を減らすこと』とすることです。

この本は設計に関するレビューの話ですが、一般的なレビューについても応用できると思います。

レビューの目的とは?

まずこの本では明確にレビューの目的を定義しています。
これが大変すばらしいと思い感銘を受けました。

この本で記載されているレビューの目的とは

修正工数を減らすこと

です。


なぜ目的を定義することがすごいと思ったのか?

レビューの目的の言語化自体がすごい



レビューの目的を明確に定義されている人は多くないのではないでしょうか?
つまり、それを言語化しただけでもとても意味があることだと私は感じました。


例えば、レビューをするときにこれは本当にここで指摘することなのだろうか? とためらった経験はありませんか?
ほかにも、指摘はしたのだけれど、レビューされる側の指摘に 何となく迎合してOKをだした経験もあるのではないでしょうか?
私はあります。
そのため、レビューの目的を明示したということ自体に意味があり、
それについて考えるきっかけとなったり、
レビューの目的をきちんと設けようという議論ができるようになるため、
このレビューの目的を提示したというはすごいことだと感じました。


建設的な議論ができそうな目的だから

このレビューの目的を『修正工数を減らすこと』としたことで、
建設的な議論ができそうだと感じたため、
この目的の選択に非常に感銘を受けました。


このように、レビューの目的が『修正工数を減らすこと』だとすると、
いつ、誰が行う、なんの修正工数を減らすことになるのか?という点が議論の焦点になり
建設的な話ができるようになります。


少し、具体的ではないなと自分でも思うので、 この文言を読んだときに頭の中に浮かんだシミュレーションを言語します。


どのようにレビューの議論が建設的になるのか?



レビューの状況

具体的なイメージがないと、どういう話なのかイメージしずらいため、
具体的な状況を設定しておきます。


  • 状況
    分かりやすくするため、Google のツール類に例えます。
    • 50人ほどであるコラボレーションプロダクト(例えばGSuiteみたいなもの)を 開発している会社(例えばGoogleみたいな)である
    • ある5人ほどのチームでメモ機能(例えばGoogle Keepみたいな)を担当するチームである。
    • 今回開発するものは、メモ機能にリマインダーを付ける機能を開発することになった。
    • リマインダーを追加するとメールにも通知されるし、カレンダーにも予定が追加される
    • ただし、カレンダーの通知は将来開発予定である。
  • この機能を開発する際にどんなPullRequestをうけとったのか?
    • 通知はキューを使うことにした。
      これまで、このコラボレーションプロダクトでキューを初めて導入することになる。
      イメージとしてはこんな感じ。
      キューのメッセージ管理モジュールが破線となっているのは完全に分離できていなくて、
      メモ機能、メール機能、カレンダー機能にべた書きになっているから


レビューの目的が明示されていない状況でのやり取り



よくあるアンチパターン的なやり取りを記載してみます。


  • レビューする側 >
    • キューのメッセージ管理モジュールがべた書きされているんだけど、 これはモジュール化したほうがいいんじゃないかな?
  • レビューされる側 >
    • これは今回これで動くからいいんです。
  • レビューする側 >
    • 将来同じコードコピペすることになるんだから、今やっといたほうがいいでしょ?
  • レビューされる側 >
    • いや、今回はこれで動くからいいんです。社長がさっさと出せと言うとるんで、 今回これで行かせてください。
  • レビューする側 >
    • (とりあえず、機能は動くみたいだし、まぁええか。 将来同じコードをカレンダー側にもコピペするのかなぁ)LGTM!!


どうでしょう?
割とよく見る光景だと思います。
上記のやり取りを見ると、お互いが最低限動くことは大事だとの認識はあるように思います。
一方で、それ以上の合意はないため、動くことさえ認められると、
レビューする側はそれ以上は指摘できなくなっています。


しかし、あまり建設的な印象は受けません。
片方があまり納得せず、押し切られただけのように見えるからです。


レビューの目的が『修正工数を減らすこと』とした場合

では、上記のやり取りが、レビューの目的は『修正工数を減らすこと』とした場合、 どのように代わるのか考えてみました。
私の想像ではこんな感じで、代わるのではないかと感じました。


  • レビューする側 >
    • キューのメッセージ管理がべた書きされているんだけど、 これはモジュール化したほうがいいんじゃないかな?
  • レビューされる側 >
    • いや、これは今回これで動くからいいんです。
  • レビューする側(ここから変わっている箇所) >
    • 将来同じコードをカレンダーに移植することになると思います。
      カレンダー側に移植した後は、 キューのメッセージ管理に変更が必要になった場合、 コピペだと同じ変更をカレンダーにも入れることになると、 修正工数が大変じゃないですか?
  • レビューされる側 >
    • 確かに、カレンダーに通知機能を実装以降に修正工数が増えそうですね。
      ただ、今回はメールへの通知だけで、かつリリース期限も迫っているので、 これで行かせていただきたいです。
      代わりに、カレンダーに通知機能を開発する前に、 キューのメッセージ管理をモジュール化するタスクを上げておきます。
  • レビューする側 >
    • なるほど、それなら将来の修正工数も多くならなそうですね。
      このPRはこれでよさそうです。
      LGTM


レビューする側も、レビューされる側も いつどんな問題が起こるのかということに焦点を合わせて、 会話ができるようになっていると思います。
すると、先ほど見た片方だけが押し切られたような形ではなく、 お互いが納得した上での合意が形成できると感じました。


終わりに

当たり前ですが、現実はこんなにうまくはいかないのだろうなと思います。


当然レビューの目的そのものがチームによって、違うこともあるでしょうし、 問題に対してどれだけお互いが共感できるかも変わってくると思います。


しかし、この目的を『将来の修正工数が増えること』というのは、 『将来困ること』と読み替えることもできます。


そうすると、将来困ることという課題をチームで考え、 その認識合わせをすることによって、レビューを建設的にできると思えるようになりました。


また、この本はレビューの目的が明示されているだけではなく、 レビューで行ってはいけないことや、レビューを効率的に行うTipsなどもありますので、 ほかの部分も参考となるところが多いです。


おすすめです。

0 件のコメント :

コメントを投稿