レビューの目的は教育や品質の担保ではない
チーム開発の文脈
koushisa.iconにとってレビューの目的は教育や品質の担保ではない アウトプットに至るまでの考え方やWhyを知る機会の提供 チームの「不安」をコントロールできる
---
https://scrapbox.io/files/6406c0df65e759001b028774.png
https://scrapbox.io/files/6406c0f0213a7b001b4c2669.png
誰かの手や時間を使って品質を担保する仕組みになっていると、そこがボトルネックになる
レビューに力をいれれば入れるほど、リードタイムを長期的に低速化させる 一部の人間に心理的・物理的に負荷がかかり開発を歪にする
---
レビューの空気を読むのは難しい
@jnchito: コードレビューにおいて疑問文が詰問に聞こえちゃうパターンなので「純粋に質問」を冒頭に付けてみた。 「なんでtrueにしたんですか？」が「普通はやらないでしょ！💢」に聞こえてしまう日本語の難しさよ……。
https://pbs.twimg.com/media/Foz_mHWaMAEscsh.jpg
@a_suenami: コードレビュアーとレビュイーは対等な立場が一番いいと思うんだけど、現実的にそうでないこともあって、そうでないならそうでないでそれをはっきり明文化したほうがいいんじゃないかと思う。レビュイーのほうが立場が上のときはもはや何にも寄与してなくて惰性のことさえある。 @a_suenami: レビュアーがシニアエンジニアでレビュイーが相対的に経験が浅いっていうのが一番イメージしやすくてよくあるケースだと思うんだけど、その場合は変に質問するよりも「こういう風に直してください。理由は~」というほうがいいと思うんだよね。お互いに空気読み合うのつらいでしょ。 @a_suenami: レビュアーがシニアでレビュイーがジュニアっていうケースはそもそもコードレビューじゃなくてもっと前の段階で何とかしろとは思う。基本設計がシニアが一人でやるとか、ペアプロやモブプロを取り入れるとか。pull request のタイミングだと遅いし、最悪全部書き直しみたいなことあるじゃん。 @komitsubo: そういうときファシリテーター含めた周りが思うのは”そういう意見はもっと前の段階でそういう段階の時に言ってくれ”である。大抵の場合そういう技術打ち合わせは前にされており、そして大抵の場合優秀な人は呼ばれていたりする。が彼らは忙しいので不参加だったり真剣に聞いてなかったりする。 @komitsubo: ある案件のアーキテクチャ設計のレビューにレビュアとして参加しているのだけど、毎回結構な量の指摘をしているので、その修正対応の結果日程も遅れてきている。なのでレビュイからすると厄介なレビュアなんだろうなという申し訳ない気分で個人的には辛い。 適当レビューは関係性の悪化につながる
主観の押し付けにならないように言葉の節々を気をつけねばならない
精神的に負荷が高い
がっつりレビューした後は小一時間ほど休憩しないと元に戻れない koushisa.icon
---
レビューを教育の一環と捉えることについて
koushisa.iconとしては否定的
教育の成果としてのアウトプットが評価しづらい
全てレビュワーのさじ加減に依存する
レビュワーによりレビューの基準は様々
しっかり時間かけてレビューしたとしても、手戻りやミスは消せない
費やす時間や心理的負荷に対するリターンが少ない
モチベーション低下による惰性レビューと形骸化
複数のことを一度にやるのが難しい
開発者の責務は素早くエンドユーザーに価値を届けることなはず
日々のレビューを通して互いに切磋琢磨するのが理想
レビューの本質は切磋琢磨であり、レビュワーとレビュイーが対等であることが前提である
教育したいならペアプロなどの手段もあるはず
お互いにどうやったら成長できるかを、相応のコストかけて一緒に考えるべし
---
最低ライン(品質)を超えられない作業者がいる場合はどうする？
基本的にソフトウェア開発は"属技能性"があり、このような問題を解決することは難しいことを念頭に置く
一介の開発者がどうこうできる問題ではない
経営判断ミスという「責任」の所在を明確にする
レビューに上がってくる前に対策をするよう提案する
が、最終的には作業者の知識や意識の問題に帰結する。取れうる手段は
リソースの再配置
学習コストをかける
前段で知識がある人とペアプロする
@t_yano: リアルでもオンラインでもいいけど、被レビュー側とレビュー側が一緒に席につき、あとはレビューされる側がひたすら、自分の書いたコードの各処理の意味を、レビュアーがわかるまで説明していく、レビュアーはよく分からないところを質問していていく、みたいなのが良いんじゃないかな koushisa.iconの経験則からコスパのいい対策はワークフローを見直す or リソースの再配置を検討すること
品質に意識を向けたければ、まずはその意味を定義してチームの共通認識をつくる