👀

選択的注意をふまえたレビュー戦略

2025/01/11に公開

今回のゴール

  • 日々のレビューに対するメタ的な視点を得る
  • 「選択的注意」を体感することで、レビューのTipsをよりよく理解できるようになる

まとめ

人間の注意には限界がある。
最大限活用するために「注意を向けさせる」「注意を散らさせない」ことが重要である。

選択的注意

複数の情報があふれているとき、その中から選択的に注意を向けることを選択的注意と呼んでいる。
選択的注意 - 科学辞典

例えば、以下のような動画で選択的注意を実感することができる。
https://www.youtube.com/watch?v=vJG698U2Mvo

注意を向けた白いユニフォームのパス回数は数えられるが、黒いユニフォームのパス回数、そして横切るゴリラ等他の事象は認識をするのが難しい。

他にも間違い探しやアハ体験等においても、答えを知っているときは、違うことや変わっていくことが認識できる。
これは答えを知っていることで、注意を向けることができ、認識ができると言える。

ここから分かる通り、人間は視界にはいるものすべてを認識しているわけではない。

また、人によっては「数えてたけどゴリラにびっくりしてどこまで数えたか忘れた」というようなケースもあると思われる。

認識できても、認識したもののすべてを適切に処理することは難しい。

選択的注意をふまえたレビュー戦略

レビューに置いても同様に、視界に入ったコードすべてを適切にレビューすることは難しい。
では、よりよいレビューを行うためにどうすればよいか。

方針は2つある。

  • 選択的注意を利用する
  • 複数の情報があふれている状況を減らす

選択的注意を利用する

レビュワーの注意をレビューしてほしい部分に向けさせることで、コードの改善点を効率的に洗い出すことができると考えられる。

レビュー観点

「どういった見方・考え方でレビューをするか」を定めたもの。
動画で言えば「白いユニフォームのパス回数を数える」という指示にあたる。

この指示なしに、ただ動画を見るだけで「パス回数」を数えることは難しい。
これだけでも観点の有無がレビューの品質に与える影響の大きさがわかるだろう。

また、他のレビュー系をネタにした記事であまり見ない内容について2点、記載をしておく。

観点の具体性

たとえば、サーバーサイドのAPIのコードレビューをする際に以下の2つの観点について考える

  • 「パフォーマンスに問題がないこと」
    • パフォーマンスに関わること全般に注意がいく。
    • レビュワーの知識・経験により指摘事項が変わる可能性が高い。
    • パフォーマンスに関わる個別の問題に特化した注意は得られない。
  • 「n+1問題を発生させないこと」
    • n+1問題の原因となりやすいDB周りの処理とループに関わる処理に注意がいく。
    • 前者にくらべレビュワーの経験に左右されにくくなる。
    • n+1問題にかかわらないパフォーマンスの問題は見落とす可能性が高まる。

このような形で、具体性によってコードの見方が変わることが期待される。
そして、これは「カバー範囲」と「選択的注意の質」のトレードオフになることが多い。

観点ごとにレビューする

原則、レビューは記載されている観点ごとにレビューするのが良い。

これは最初の動画でユニフォームごとのパス回数を数える指示があった際に、「1回の視聴で2色とも数える」のと「2回の視聴で1色づつ数える」ことを考えれば観点ごとに相当する後者の方が楽だというのは体感できると思う。

個人的に効果が大きいと感じているコツの一つだ。
レビューが苦手だと感じる人は一つずつレビューすることを意識してみてほしい。

もちろん、愚直に実施すると、実質的なレビューの回数が増えるため負荷が大きい。
自動化できるような観点は自動化すると良い。

複数の情報があふれている状況を減らす

動画で言えば、黒いユニフォームのパスや横切るゴリラ、背景等、余計な情報がなくなればなくなるほど、白いユニフォームのパスに集中できるようになる。

また、各ユニフォームのパスがなければなんの指示がなくても横切るゴリラに気づける人がほとんどになるはずだ。

1PRでやっていることを減らす、typo、フォーマット等の些末な問題はCI、セルフレビューで潰す等の工夫がこれに当たる。
注意を逸らす要因を減らすことで、レビュワーがよりレビューすべき内容に注力できる。

ポエム

今回のゴールに加えて、レビューってちゃんとやろうとすると、結構高負荷な作業だなーと感じてもらえると嬉しい。
レビュー負荷を下げることは生産性を上げるうえで大切。

Discussion