※この記事はAgileStudioに掲載した記事の転載です。
元記事：「実装は終わっているのに、タスクが完了にならない」プルリクエストが溜まり続けたチームが、仕組みを重ねるまでの試行錯誤（トナリノ）

「実装は終わっているのに、タスクが完了にならない」

あるチームのメンバーが、プルリクエストのレビュー待ちについてそう振り返りました。

今回ご紹介するのは、4〜5人で1スプリント2週間を回しているバックエンドのスクラム開発チームです。プルリクエストのレビューが溜まり続けることが、ふりかえりのたびに話題に挙がる悩みでした。

この記事は、そんなチームの試行錯誤の記録です。

トナリノは、隣のチームの泥臭い試行錯誤をそのまま届けるコミュニティです。

様々なチームの「うまくいかなかったこと」「試してみたこと」「今の現在地」を記録しています。正解やTipsではなく、あるチームのリアルな試行錯誤をお届けします。

👉 トナリノの詳細を見る

タスクが完了にならないから、進んだことにならない

実装は終わっている。あとはレビューさえ済めば、そのタスクは完了にできる。なのに、それができない。

レビュー待ちのタスクが残っていると、その分はスプリントで消化したことになりません。 実装がどれだけ進んでいても、レビューが済まなければ「完了」にはならない。 積み残しは、そのままスプリントの成果から差し引かれていきます。

スプリントゴールが達成できないこともあれば、ぎりぎりのタイミングでなんとか滑り込むこともありました。

これは、ふりかえりのたびに繰り返し挙がる問題でした。

「誰か一人が見れば完了」が、抜け穴になっていた

このチームには、レビューについて一つのスタンスがありました。

「レビューを属人化させたくない」

特定の誰かをレビュー担当に固定するのではなく、チームの誰が見てもいい。誰か一人が見れば、そのプルリクエストは完了。それが、このチームが最初から持っていたルールでした。

ただ、担当を固定していないぶん、 「自分が見なくても、誰かが見てくれる」 と思われやすい面もありました。その構造が、レビューを後回しにしていました。

急いでいるものは、ちゃんとリマインドしよう

ふりかえりで繰り返し挙がるこの問題に対して、最初に試してみたTryは「急いでいるものは、プルリクエストを出した人がちゃんとリマインドしよう」というものでした。

とはいえ、これはまだ意識の話でした。リマインドの仕方もタイミングも、結局は人それぞれのままでした。

人任せのリマインドを、Botに任せた

次にチームが作ったのは、プルリクエスト通知Botでした。

きっかけは些細なことでした。チームの主な連絡手段はMattermost。「チームのチャンネルに通知が届けば、みんな見るから嬉しいよね」という話が出たとき、あるメンバーが「Botならすぐ作れますよ」と言いました。他のサービスを探すこともなく、それで決まりました。

Botがやることはシンプルです。始業前（8:40）と昼（13:00）の1日2回、今溜まっているプルリクエストの一覧をチャンネルに流す。1週間放置されているものは、強調して表示します。

意識に頼っていたリマインドが、ここで初めて仕組みに変わりました。 チームの反応も「いいね！」でした。

ただ、この時点ではまだ、各自が通知を見て、非同期にプルリクエストのレビューを対応するというスタイル自体は、変わっていませんでした。

夕会で、プルリクエストを確認する時間を作った

メッセージでの通知は、読み飛ばされてしまうこともあります。だからチームは、夕会（デイリースクラム）の中に、プルリクエストを確認する時間を作りました。

同期的な場でチーム全員が状況を確認することで、「今どんなプルリクエストがあるか」の共通認識を持てるようにしたのです。このタイミングで、Bot通知にデイリースクラム直前（17:00）の回を追加しました。夕会の直前に、最新のプルリクエスト状況をBotがアウトプットするようにしています。

優先度を、絵文字で見える化した

ここまでで、「溜まっていること」は見えるようになりました。けれど、どれからレビューすればいいかは、まだ見る人任せのままでした。

そこでチームが決めたのが、プルリクエストのタイトルに優先度の絵文字をつけるルールです。

🔴 ： 最優先。すぐに見てほしいもの
🟡 ： 今のスプリント中、2〜3日以内には見てほしいもの
🟢 ： 来スプリントに回っても構わないもの

ルールを決めること自体に、大きな対立はありませんでした。「みんなでやってみよう」という空気で決まっていきました。ただ、単純な緊急度ではなく「スプリントゴールを達成できるか」を基準にしたことは、きちんと話し合って決めました。

どれをつけるかは、この基準をもとにプルリクエストを出した本人が判断します。まだ先のスプリントで使う予定のタスクは、最初は 🟢 がついていても構いません。期限が近づいたら、本人が絵文字を更新します。夕会では、放置されている 🔴 がないかを確認します。

優先度が見えるようになったことで、レビューする側は「どれから見ればいいか」に迷わなくなりました。通知Botの一覧にも絵文字がそのまま表示されるので、 🔴 が溜まっていることをチーム全員が認識できます。 早く見てほしいプルリクエストに、いちいちリマインドのコメントをつける必要もなくなりました。

運用を始めたばかりの頃は、うまくいかないこともありました。絵文字をつけ忘れたプルリクエストがあり、夕会で「ついてないけど、このプルリクエストは優先なんだっけ？」と確認が入ることもたびたびありました。運用開始からしばらく経った今は、つけ忘れはなくなっています。

ルールを厳格に守ろうとするあまり、タスクの前後関係を考慮した柔軟な優先度付けができていなかった時期もありました。これも、今はある程度できるようになっています。

絵文字とBot以外にも、小さなことを試した

プルリクエストが溜まるのは、サイズが大きいからではないか。そんな仮説から、なるべく小さく出すことも意識するようになりました。実装とテストを分けてプルリクエストを出す、ということも試しています。

優先度の高い順に、片付いていく感覚が生まれた

ここまでの仕組みを重ねたことで、プルリクエストの滞留でスプリントゴールが達成できない、という事態は起きにくくなりました。

優先度の高い順に、プルリクエストが片付いていく感覚がチームに生まれました。🔴 と 🟡 は、スプリントの中で目を通せるようになっています。 🔴 と 🟡 が片付き、かつ実装に余裕があれば、 🟢 まで見られる。今はそんなペースで回っています。

この仕組みは、このチームの中だけでは終わりませんでした。 動いているBotを見た他のチームが、自分たちでも同じような仕組みを取り入れるようになったのです。

あなたのチームの「誰かが見るだろう」は、どこにありますか？

「レビューを属人化させたくない」というこのチームのスタンスは、間違ってはいませんでした。ただ、そのままでは「誰かが見てくれるだろう」という抜け穴を生んでしまう。

だからこのチームは、個々のリマインド、Bot通知、夕会での確認、優先度の可視化と、一つずつ仕組みを重ねていきました。最初から完成形が見えていたわけではありません。 一つの仕組みがうまくいっても、しばらくすると別の問題が顔を出す。 その穴に、また一つ仕組みを重ねる。その繰り返しでした。

その意味では、この試行錯誤に終わりはないのかもしれません。

あなたのチームの「誰かが見てくれるだろう」は、今どこにありますか。そして、それを意識で何とかしようとしていませんか。

このチームの試行錯誤が、皆さんのチームへの「問い」になれば嬉しいです。

この記事は、「トナリノ」から生まれた試行錯誤の記録です。
様々なチームの泥臭い試行錯誤を、定期的に届けています。

他のチームの話も気になった方は、フォローしてもらえると嬉しいです。
Xでも同じテーマで発信しています → X（@はんそで）