概要
想定読者：
- 中心業務(自分の責務の中ではマネジメント業務)がある中で、レビュー等の依頼を多くいただくような中で業務している方
想定読者ではないかもです😭：
-
マネージャーがレビューをするかどうかの意見を知りたい方：みる前提の記事となっているためでございます🙇
- 過去に頑張って書きました：https://zenn.dev/johndoe/articles/395ac8934fa3d0
-
レビュー改善による数値的変化・開発生産性向上の具体的な内容が見たい方：経緯記載のように、どちらかといえば現在の整理となってしまうため、明確に切り替えタイミングがわからず🙇
- PRレビューと開発生産性に関して：https://techblog.zozo.com/entry/wear-web-development-productivity
-
レビュー依頼をする側で心がけたいこと：あくまでメイン業務と共にレビューの際に意識している点という観点のためでございます🙇
- レビュー依頼をする側で、確かになと思った記事：https://note.com/simplearchitect/n/nb9c7a90f3b78
-
具体的なレビューコメントの際に気にする観点：具体的なコメントスタイル等はスコープ外とさせていただいております🙇
結論：
経緯
- 自分はメイン所の業務としてはマネジメント業務(エンジニアリング組織、プロジェクト、各種コスト等)が中心として業務
- その傍ら、社員規模が大きいわけではないのもあり、自分の記載したコードが多く存在しているドメインでのレビューも業務の一つとして実行している
- そういや一定数の方針を自分の中(一部はチームルールとしても)持ちながらレビューしているな~とふと思ったので整理していた
- 整理すると共に、結局一つに集約されているなと思い本記事のタイトルに
心がけている一つのこと
細かいレビューロジック等はありますが、自分のレビュー方針の9割は以下の一つに集約されます。
PRレビュー依頼がきたらどの仕事よりも早く「リアクション」をするです。
- ここで 「リアクション」としており、「レビュー」と記載していないのに個人的ミソ でございます。
- 本業務であるマネジメント業務とのバランスを保つことは最重要
- レビューが本業務であれば話は変わりますが、レビューを優先するあまりメイン業務が疎かになるという状態を防ぐ
- バランスが保てない場合、それはレビューをしている範囲そのものを見直する必要があります
- 下記表のようにレビュー依頼要素によってとるべき行動が変わると考えているからであります
- ただ、マネジメント云々関係なく使えるミソかなと考えております
- レビューの要素というのは、以下のような複数要素にて構成されていると考えております。
- 誰がレビューするか観点：自分にしか見れない/自分が見た方が良い/他の人でも見れる/他の人が見た方が良い
- いつまでにレビューするか観点：今すぐみるべき/優先でみるべき/通常で見るでいい/お手隙でいい
- レビュー量・質的な観点：重たい内容/通常の内容/軽い内容
- 自己のタスク状況的観点：メイン業務が逼迫している/逼迫はしていないが忙しい/通常通り/通常より余裕がある
- これら複数要素を不確定な時間が長ければ長いほど、カバーができない状態で問題点が発覚する可能性を高める
- 不確実性に関してはこちらを！：https://zenn.dev/activecore/articles/578eaef79aaad2
- また、「レビュー依頼いただいている」ということは自分にボールが来ている状態を示しており、相手の作業を止める可能性を高める
具体どのようなリアクションを！？ということでこれらを表にしてみました。
リアクション表
| 合計スコア範囲 | リアクション | なぜ |
|---|---|---|
| 12点以上 | 今すぐレビューコメントor 他の方に優先で見てほしいと伝える | 高スコアは「自分にしか見れない」「今すぐみるべき」「期限が非常に短い」というケースだったり、「軽めで即判断可能」「自分に余裕あり」というケースだったり、経緯は様々だが自分が早くレビューをした方が良い。どうしても今すぐはメイン業務で見れない場合は明確に他の方に見てほしいと伝える。 --- - 障害発生時hotfixレビュー - コード変更量少数かつ顧客影響発生しない内容だが早くマージしたいレビュー |
| 9〜11点 | 0次レビューだけ行い、「詳細はYYYY/MM/DD HH:MM目処に見ます」と伝える | 一部条件は緊急だが、内容や自分の状況から即全レビューは難しい場合。まず方向性や致命的な問題有無だけ確認し、詳細は後で行うことで相手の作業を止めない。 --- - 新規開発レビュー - コード変更量少数だが顧客影響は発生しうるので、ちゃんとレビュー |
| 6〜9点 | 「YYYY/MM/DD HH:MM目処に見ます」と伝える | 緊急性は中程度。即対応しなくても致命的リスクは低いが、相手は見通しを必要としているため、対応予定を明確にして心理的・進行的な不安を減らす。 --- - スケジュール上、余裕のある内容のレビュー - 自己のタスクが逼迫しており、コードレビューどころではないときのレビュー依頼 |
| 5点以下 | 基本他の方に見てほしいと伝える | 緊急性・重要性ともに低く、今対応しなくても大きな影響がないため。本業務や優先度の高いタスクを先に行うべき。 --- - お手隙レビューで、自分でなくても良いレビュー依頼 -依頼はいただいたが、内容的に自分以外がレビューした方が良いレビュー依頼 |
| 観点 | 要素 | スコア |
|---|---|---|
| 誰がレビューするべきか | 自分にしか見れない | 4 |
| 自分が見た方が良い | 3 | |
| 他の人でも見れる | 2 | |
| 他の人が見た方が良い | 1 | |
| いつまでにレビューするべきか | 今すぐみるべき | 5 |
| 優先でみるべき | 3 | |
| 通常で見るでいい | 2 | |
| お手隙でいい | 1 | |
| レビューの量・質 | 軽い内容 | 3 |
| 通常の内容 | 2 | |
| 重たい内容 | 1 | |
| 自己のタスク状況 | 通常より余裕がある | 4 |
| 通常通り | 3 | |
| 逼迫はしていないが忙しい | 2 | |
| メイン業務が逼迫している | 1 |
補助リスト
- 自動テスト：ciの搭載：具体的なコードレビューの際のレビュー漏れを防ぐ。人が見れる限界はありますので、もちろんテストで全てがカバーできるのが一番であり、それを自動でテストしてくれるciは最強
- 防御線の作成：毎日17時に「ぷるりくリマインド」通知をチームメンション通知
- どうしたって反応できないタイミングはある
- だが反応できなかったとしてもこの毎日のリマインドによる防御線が、「この人は17時には見ようとしてくれる」という状況の補助をしてくれる。
- レビューのムラのなさもレビューのリアクションの速さと同じくらい重要である。
- ルール：cursor rulesを用いたPR提出前のレビューをしていただくこと、cursor rulesを用いたPR提出後の自動レビューをこちら側でもすること。生成aiと仲良くなるようなレビュールールの作成は必須。
- 0次レビュー：PRテンプレに沿っているか
- マージ期日の記載：YYYYmmdd hhmmまでにマージしたいという期日が記載されているかどうか
- PR概要の記載：どのような編集をしたのか、要件リンク等が記載されているか
- チェックしてほしい点：レビューする側の方視点でレビューをどのようにしてほしいかが記載されているか
- チェックした点
- 0次レビュー：方針レベルでの違いが起きていないか
- コードレビュー等の際に、自分のイメージしてたゴールイメージと方針レベルで違うか
- 全部同一内容であるが、修正してほしい点が複数ファイルに渡って存在するかどうか
- slackカスタム絵文字の作成：どうしても他の方に見てほしいとき、「oth」と打てば「ご確認可能な方へるぷ！」という絵文字が出るように作成(:help_other_ご確認可能な方: とかで設定)。打つのに1秒もかからないはず。
- ユーザー辞書設定：approve/comment/レビュー修正してもらった後のcomment/他の方に見てほしい のような複数パターンのユーザー辞書設定を行う。※もちろんケースによっては送信前に適宜微調整します🙏
これから
- レビュー依頼をいただいた際にどのようなリアクションを日々とるかの積み重ねがプロダクトがどうなるかに影響しうる大事な業務だと考えている。
- だからこそ、マネジメント業務との最善のバランスを保つために、「PRレビュー依頼がきたらどの仕事よりも早く「リアクション」をする」ことはこれからも実践していきたいです
- リアクション表に記載させていただいた内容はあくまでレビューの観点ですが、これはあらゆるコミュニケーションにも通ずる部分はあるかなと個人的に思っています
- 引き続き修正しますが、マネージャの方でなくても利用可能にしたい・なるのではと思ってもいます
- 補助リストも、大事な構成要素だと考えており、別記事にて詳細記載できればと考えています！
Discussion