レビューのつらさを倒したい 2021/11/05 SHIOYA, Hiromu / @kwappa

レビューとはなんじゃ ここでは「仕事の検証、見直し」 エンジニアは「コードレビュー」をよくやる 他の職種でもあると思うのでよしなに解釈してください

用語の確認 レビュアー レビュー「する」人 レビュイー レビュー「される」人 つまり「レビューをお願いする」人

最近よく聞くつらみ レビュー「する」のがつらい PRが来る→レビューしなきゃ レビュー「してもらう」のがつらい レビューお願いしたい＊＊さんが忙しそう

レビューがつらいことによる害 価値を届けるまでのリードタイムが増える とはいえノーチェックで出すのはまずいが…

そのレビュー意味あんの？ トリプルチェックの弊害 #現場猫 実写版 実写版・現場猫その5 トリプルチェック。

レビューの流れ レビュイー なにかコードを書く Pull Requestでレビューを依頼する レビュアー レビューの依頼が届く レビューする Approve する

Approve : 承認？ approve 1.〈…を〉よいと認める，〈…に〉賛成する. 2.〈…を〉(正式に)承認する，認可する. レビューにおける approve は「賛成」 LGTM = Looks Good To Me : 「よさそう」 つい「承認」だと思いがち レビュイー : だってレビュアーが 承認 したじゃん レビュアー : 絶対ヨシ

なぜレビューがつらいのか レビュアーがなんにもうれしくないから レビューの時間は自分のタスクが進まない 承認 する責任がある？ 不具合があったら自分の責任？ うれしくないから後回しにする レビュイーもつらい プロダクトもつらい

こんなのもうイヤだ 仕事のやり方を変えよう

その1 : 責任所在 レビュイー : タスクの責任者 仕事に責任を持つ 不安を解消するためにレビューを依頼する レビュアー : タスクのサポーター レビュイーの不安を解消する手助けをする 知識や経験でタスクの品質向上に 貢献 する 承認 じゃないよ

その2 : 時間配分 レビューは必要 なので業務の時間に織り込む なのでリードタイムに織り込む

その3 : プロセス改善 プロセス改善？ レビューの目的を明確に レビューのサイクルを短く レビュイーが責任を持つ

レビューの目的を明確に レビュイー : 不安を取り除く タスクを説明する 目的は何か、そのために何をしたか、自分で何を確認したか 確認しやすい粒度でレビューを依頼する 不安を言語化する 見てほしい、知恵を貸してほしいポイントを明示 不安を解消する レビューをもとにタスクの品質をあげる →手直し上等

レビューの目的を明確に レビュアー : 貢献する レビュイーの不安を取り除く そのための approve = 賛成 知識・経験からのコメント タスクの品質が向上するために レビュイーが成長するために モヒカンの手斧はいらない

レビューのサイクルを短く レビューが通れば完了 例 : 基本設計→詳細設計→実装→試験→レビュー テストコードまで書いてレビュー依頼 「そのテーブル名いまいちだよね」→ レビューの範囲を小さくする 例 : 基本設計→レビュー→詳細設計→レビュー→… 不安を小さい単位で解消する よりよいやり方を議論する →これがペアプロ / モブプロの原点

レビュイーが責任を持つ タスクをdoneにするのはレビュイーの 責任 レビューの単位を小さくする レビューするべき箇所を明示する そのためのサポートをするのがレビュアーの 貢献 レビューを溜め込まない 当然発生する業務として織り込む 不安を取り除く 知識と経験 態度や言葉遣い

まとめ : レビューをつらくなくしよう レビュイーが責任を持つ レビュアーは貢献する お互い協力する →最適な結果のために