"わたし"がレビューを後まわしにすると何が起こると思いますか？

はじめに

これは、

レビュワーである"わたし"がレビューを後まわしにしてしまうと何が起こるのかを知り、
レビューは最優先で対応すべきもの、と認識しよう

を伝えるための記事です。

---

私の所属する開発チームでは、チケット¹に対して1人を開発担当者にアサインするのが基本で、その人が主体となってリリースしています。

主体は開発担当者ですが、ソースコードを書いてテストしてリリースするためには、その随所でチームメンバーによるレビューが入ります。

自分がそのレビュワーになったとき、レビューを後回しにしてしまうとどうなるでしょう？

を、ケーススタディなどを交えながら考えていきます。

なお、私自身もレビューを滞留してしまうシーンはまだまだあります。
そのため、これから書くことは、自省の意味を大いに含みます。

もくじ

お忙しい方は"わたし"がレビューを後まわしにすると何が起こるのか（まとめ）を読んでいただくと、レビュー遅延によるさまざまな弊害を思い知ることができ、レビューを後まわしになどできなくなると思います。

1. 前提
2. １つの不具合修正をするために必要なタスクは？
3. 数あるタスクの1つであるレビュータスク、どう優先順位づけしていますか？
4. "わたし"がレビューを後まわしにすると何が起こるのか（ケーススタディ）
5. "わたし"がレビューを後まわしにすると何が起こるのか（まとめ）
6. 「まだ開発／評価締めまで時間があるし、とりあえず自分の実装に集中しよう」とかはナシ。レビュータスクを優先させよう
7. チームでの作業スタイル共有会がおすすめ
8. おわりに：まとめ

前提

今回のケーススタディは私たちのチームおよび開発サイクルをベースとしています。
具体的には以下です。

• チーム編成
  • 1つの開発チームで大きく2つのサブシステム²を担当する
  • 各サブシステムの担当者は3人ないし4人
• 開発サイクル
  • 3ヶ月単位での商用リリース
  • 約1ヶ月1サイクルで社内リリース
  • 1ヶ月の中で開発締め（第3週）、評価締め（第4週）のマイルストーンが設けられている
  • 開発のみならず評価も同じ開発チーム内で行う（開発担当者とは別に評価担当者をたてる）
• レビュー形式
  • いずれのレビューもチームメンバー全員がレビュワーであり、全員のApproveが必要³
  • PRレビューは基本的にPR画面をメンバーが各々見てレビューする形式⁴
• そのほか
  • 機能開発や不具合修正のほかに、フロント部門等からの問い合わせ対応や部署横断タスクなどが差し込みで入る場合こともしばしば・・・

１つの不具合修正をするために必要なタスクは？

例をシンプルにするため、今回は不具合修正を例に挙げます。

1つのチケットをリリースするためのタスクはこんな感じです。
なお、これは私たちのチームで実際に利用しているBug Issueテンプレートから抜粋しています。

- [ ] 実装し、Pull Request（以後「PR」と記載）を提出する
- [ ] PRを確認し、マージする
- [ ] 開発者テスト、評価者テストを作成し、レビュー依頼を出す
- [ ] テストケースを確認し、承認する
- [ ] 開発者テストを回し切る
- [ ] 評価者テストを回し切る
- [ ] リリースノートを記載し、レビュー依頼を出す
- [ ] リリースノートをレビューし、承認する

この中で、自分が進めるタスクと誰かに依頼するタスクは以下の通り。

• ★：開発担当者自身が担当するタスク
• ☆：他のメンバーに依頼するタスク

- [ ] 実装し、PRを提出する                                 <- ★　開発担当者のタスク
- [ ] PRを確認し、マージする                               <- ☆　レビュワーのタスク
- [ ] 開発者テスト、評価者テストを作成し、レビュー依頼を出す  <- ★　開発担当者のタスク
- [ ] テストケースを確認し、承認する                        <- ☆　レビュワーのタスク
- [ ] 開発者テストを回し切る                               <- ★　開発担当者のタスク
- [ ] 評価者テストを回し切る                               <- ☆　評価担当者のタスク
- [ ] リリースノートを記載し、レビュー依頼を出す             <- ★　開発担当者のタスク
- [ ] リリースノートをレビューし、承認する                  <- ☆　レビュワーのタスク

自分が開発担当者でないチケットでもかかわる機会は多いです。

特にレビューに関して、私たちのチームでは担当者全員によるレビューを必須としているため、チームでリリースするチケットには多かれ少なかれ関わることになります。

数あるタスクの1つであるレビュータスク、どう優先順位づけしていますか？

エンジニアって、日々とても忙しいですよね。

日々のお仕事、あげだしたらキリがないので一部だけ抜粋しましたけど、それでも多いので折りたたんどきます。

自分が開発担当者になっているものは当然実装したりレテストケース書いたりテストしたりしなきゃいけませんよね。
レビュワーが円滑にレビューをできるように、追加のコメントをPRに書いたり資料作成したりもしますし。
そんな中で、他のメンバーのPR等のレビューもこなさなければいけません。
評価担当者になったものは評価者テストを実施する必要もあります。
加えて私たちのチームが担当しているサブシステムはありがたいことに多くの利用ユーザーや新たに導入してくださるユーザーがいらっしゃり、フロント部門からの問い合わせも対応しなければいけません。
それ以外にも部署横断タスク、1on1、研修、人事評価、講座受講などなど・・・
差し込みタスクはそこそこかなりあります。

忙しくても身体は1つなので、タスクに優先順位をつけて対応していく必要があります。

• 自分の開発担当チケットの実装
• 他メンバーからのレビュー依頼
• 期限の近いタスク
• 催促されているタスク

など、いろいろありますよね。

どれから対応していきましょう？⁵
それを判断する際に、念頭に置いておくべきだと思うことがあります。

レビュワーである"わたし"がレビューを後まわしにしてしまうと何が起こるのかです。

"わたし"がレビューを後まわしにすると何が起こるのか（ケーススタディ）

「で実際"わたし"がレビューを後まわしにすると何が起こるの？」を具体例を挙げて想像してみます。

ケーススタディ：1サイクルで3件の不具合修正をする

前提条件

チケットの規模と優先度

• チケット１：S-3
• チケット２：S-3
• チケット３：M-5

優先度はチケットに振られた番号順

登場人物と作業スタイル⁶

• Aさん：1チケット集中型（チケットを優先度をつけて1件ずつ終わらせていくスタイル）
• Bさん：全実装先行型（まずはすべてのチケットの開発を終わらせて一気に後続作業をする）

以降のスケジュール例の凡例

理想

Aさんの場合

• 作業スタイル：１チケット集中型
  • 3件の大まかな作業見積もりをしたうえで、優先度をつけて1件ずつ終わらせていく
• ひとこと：マルチタスクまじ無理。１つのことに集中させてくれ！

そんなAさんの作業の理想形はこちら。

チケット単位で綺麗な階段状になっています。

Bさんの場合

• 作業スタイル：全実装先行型
  • 3件ともまず開発を終わらせて一気に後続作業をする
• ひとこと：実装の見通し立たないの超不安。CFまでに確実に辻褄合わせていきます！

そんなBさんの作業の理想形はこちら。

フェーズ単位で綺麗な階段状になっています。

レビュー遅延が起きたらどうなるか

Aさんの場合

理想形

レビュー遅延の結果

• 最終的に評価締めに間に合ってはいます
• が、実装完了＝レビュー依頼からレビューフィードバックまでにかなり期間が開いており、思い出しコストが相当かかっていると思われれます（実際フィードバック反映が理想だと1営業日だがレビュー遅延の結果2営業日かかっている）
• Aさんの作業スタイル的に、全てのチケットから手を離せず同時並行で進めざるを得ない状況が大きなストレスになっています⁷

Bさんの場合

理想形

レビュー遅延の結果

• もともと3件の実装を一気にすすめるスタイルなので、進め方に大きな変化はありません
• が、Aさんと同様FB修正時の思い出しコストは相当かかっています
• 当然レビューが遅延しているので評価者による評価期間は圧倒的に減ってかなりバタバタしているように見えます

"わたし"がレビューを後まわしにすると何が起こるのか（まとめ）

対開発担当者と対評価担当者、それぞれに対しての弊害は以下の通りです。

開発担当者への弊害

• レビュー完了までの間、開発担当者がチケットのマルチタスクを余儀なくされる
• 後回しにされたうえでソースコードの修正が必要な場合、PR作成から期間があいているため、実装内容を思い出すコストがかかる
  • 別チケット等を対応していた場合、ブランチの切り替えやデータ整備などが必要になる
• 修正内容が固まるまでに時間がかかり、テストケースの書き始めが遅くなる
  • テストケースを書く際に再度修正内容を思い出すコストがかかる
• マージを待たずにテストケースを書いていた場合、テストケースの修正コストがかかる
• チケット１が終わらないとチケット２に着手できないといった制約があった場合、チケット２はレビュー遅延によってリリース延期を余儀なくされる可能性がある
• 開発者テストの着手が遅れる
  • 不具合検出が遅れて修正が間に合わず、リリースできなくなる可能性がある
• 開発担当者以外が修正後のソースベースで画面を触る機会が減る
  • （これに頼っちゃいけないとわかりつつも）別メンバーが開発担当者の想定外の設定方法や操作方法で画面を操作した場合、思わぬ不具合が見つかることってある
  • が、それが見つかる機会が失われたままリリースされてしまう可能性がある

評価担当者への弊害

• 評価者テストの着手が遅れる
  • 評価が間に合わず、リリースできなくなる可能性がある
    • 評価担当者は「自分の評価が終わらないせいでリリースできないかも」というストレスを抱えながら必死に打鍵することになる
  • 間に合ったとしても評価者による評価期間がすり減り、ヒューマンエラーが起きやすくなる可能性がある
    • 結果的に品質の低い状態で出荷される可能性がある

「まだ開発／評価締めまで時間があるし、とりあえず自分の実装に集中しよう」とかはナシ。レビュータスクを優先させよう

自分がレビューをため込んだせいで誰かのスケジュール・メンタル・その他諸々に想像以上に負荷がかかっていると思ったらめちゃくちゃ申し訳なくないですか？

ましてや別の誰かの担当チケットがつぶれるリスクに晒されている・・・ってめちゃくちゃ怖くないですか？

たとえば開発サイクルの早い段階で出されたPRやテストケースレビューに対して、「まだ開発／評価締めまで時間があるし、とりあえず自分の実装に集中しよう」というのもナシです。

いついかなるタイミングでもレビュータスクが優先です。⁸

（おまけ）チームでの作業スタイル共有会がおすすめ

今回のケーススタディはあくまでサンプルですし、差し込みタスクのことはあまり考えずに記載しました。
ここは、チーム内で「あなたはどっち派？むしろ第三派？」というワークをやると、みんなが日々の開発をどう進めていくのが理想なのか／現実はどうなのかなどが見えてきます。

実際に以下の流れでメンバーおのおのの作業スタイルを共有しあいました。

ワークの流れ

1. 【5分】[個人ワーク] 適当なツール（スプレッドシートやMiroなど）自分の作業スタイルを考えて名前とコメント（あれば）を書いてもらう
   • 私のチームではGoogle Spread Sheetを利用しました。記載イメージは以下のような感じです
     
2. 【10分】チームメンバーがどんな作業スタイルなのかをみんなで見てみる

作業スタイルの例（再掲）

１チケット集中型

全実装先行型

弊チームでの実施結果

個人ワークは5分の予定でしたが、全員1分程度で書き終わっていました。
コメントはその他以外は促してはいなかったものの、予め書いてくれているメンバーもちらほらいました。
また、他のメンバーの話を聞いたうえで追記してくれたり、口頭で話した内容を転記してくれたりと、最終的にほぼ全メンバーがコメントしてくれました。

内容については少し意訳も含みますが、たとえば以下のような意見が出ました。

• 1チケット集中型が理想ではあるんだけど、差し込みなどの関係でなんだかんだ全実装先行型に寄ってしまう
• 思い出しコストを払うのが嫌なので基本的には1チケット集中型
• 特に大きめの機能強化案件を担当するときは先に実装目途立てたくて全実装先行型になる
• まだ開発に慣れていないので1つ1つ着実に終わらせていかないと頭パンクする

どのメンバーの意見も「あ～～～たしかにその側面あるよね～～～」と思う内容でした。
同時に、担当するチケットの粒度やカテゴリによってスタイルが変わるという人も多かったです（し、私自身もそうだな、と感じています）。

でも、弊チームは私の想像以上に1チケット集中型のメンバーが多く、やっぱりレビューの滞留は悪だな、と再認識しました。

おわりに：まとめ

• "わたし"がレビューを後まわしにしてしまうと何が起こるのかを知り、肝に銘じておこう
  • 誰かのレビューを後まわしすることが、その"誰か"にさまざまな負荷をかけているかもしれませんよ
  • その"誰か"の案件が"わたし"のせいでつぶれるリスクに晒されていますよ
  • 「まだ開発／評価締めまで時間があるし、とりあえず自分の実装に集中しよう」はナシ。レビュータスク優先です
  • そうは言っても優先順位づけに悩んだら周りの人に相談しよう
• 自分のチームメンバーがどんな作業スタイルなのかを認識しあうと、レビュー滞留の結果何が起こるのかの解像度が高くなるのでおすすめ

1. 私たちのプロダクトでは、不具合修正や機能強化をリリースする最小単位としてRedmineのチケットで管理しています ↩

2. 弊社では1つの業務機能を「サブシステム」と呼んでいます ↩

3. 2025年1月の開発サイクルから、レビュー滞留を減らすための策として、Approveの必要数やレビュー開催形式などを見直し、改善版のレビュー体制で運用していく予定です。半年ほど運用してみて記事化したいと思います ↩

4. ここ半年ほど、諸々の背景により、基本的に担当者全員がPRベースで個別にレビューしています。それ以前はこの記事で記載しているとおり、すべてのレビューをモブレビュー形式で開催していました。モブから個別にレビュー形式を変えた経緯については別記事で書きたいです ↩

5. 数あるタスクの優先順位のつけ方については今回は言及しません。が、アイゼンハワーマトリクスなどに照らし合わせてつけている方もいらっしゃるかと思いますし、他のやり方を実践されている方もいらっしゃると思います ↩

6. 作業スタイルの良し悪しについては今回は言及しません ↩

7. 作業スタイルに関わらず、コンテキストスイッチがどれだけムダかという話は古くからあります。こちらの記事や「ワインバーグ コンテキストスイッチ」などで検索してみてください ↩

8. そんなこと言われてもタスクが溢れてしまってレビューが回らない、配属したてで優先順位の判断ができない、などの場合は、周りのチームメンバーやマネージャーに相談しましょう ↩