はじめに
こんにちは。
Rehab for JAPANでレセプトの開発マネージャをしている マサキ です。
Slackでレビュー依頼をやり取りしていると、「これ、もう誰か見てるの？」「終わった？まだ？」といった“取りこぼし”が発生することはありませんか？
特にレビュー対象が増えたり、関係者が多いチームでは、ちょっとした情報の見逃しがチーム全体のスピードや信頼感に影響してくることがあります。
今回は、私たちのチームが直面したレビュー依頼の見逃し問題と、それに対して試した運用改善についてお話しします。
せっかちな人向け：改善策の画像
この記事で伝えたいこと
Slackで行われるレビュー依頼の「滞留・取りこぼし」を、無理のない運用の中でどう可視化するか？
JIRAやスプレッドシートといった定番の“管理”手段とは違う、チーム文化に馴染む軽やかな仕組みとして、Slackの「リスト」機能を取り入れてみた経緯と考え方を共有します。
前提知識
- 本記事で扱う「レビュー依頼」とは、開発ドキュメントやQAのテストケース表の確認依頼を指します。
- 開発チームはGitHubでコードレビューを、QAチームはテストケースをスプレッドシートで管理しています。
- チームはスクラム開発に取り組んでおり、PBI単位でのアウトプットが増えたフェーズにあります。
ターゲット
- Slackを主なコミュニケーション手段として使っている開発・QAチーム
- レビュー依頼がSlack上で流れてしまい、何が未対応なのか見えづらくなっていると感じている方
- JIRAやスプレッドシートによる“管理”には限界を感じており、もう少し自然に続く仕組みを探している方
内容
1. 課題に気づいた背景
1.1 QAチームから上がった悲鳴
開発チームにもドキュメントレビューはありますが、設計以降はコードやテスト実装に比重が移るため、レビュー依頼の滞留が目立つことはあまりありませんでした。
一方、QAチームでは、スクラム導入によりPBIごとに細かなテストケースを作るようになり、レビュー依頼の数と頻度が急増。Slackで送られるレビュー依頼が、どこまで完了しているのか、誰が見ているのかが不明確になり、「レビューが流れていく問題」が顕在化しました。
2. 試行錯誤と選んだ解決策
2.1 JIRAもスプシも、ちょっと違う
ある時、「レビュー依頼もJIRAでチケット化したい」という提案を受けました。
見える化の一歩としては理解できるものの、JIRAがレビュー用チケットだらけになり、運用負荷が高くなることが懸念されました。
次に検討したのは、スプレッドシートでの管理。
でも、更新やチェックの習慣が根づかず、「気づけば誰も見ていない表」になる可能性も高い。
「管理しよう」と思えば思うほど、運用が重くなってしまうジレンマがありました。
2.2 Slackリストで“今の文化”に乗せる
そこで試してみたのが、Slackのリスト機能です。
- レビュー依頼は、従来通りSlackで送る
- その依頼をSlackリストに追加し、「依頼者」「対応者」「期日」だけ記入する
という非常にシンプルな運用です。
Slackの中でかんばん形式で可視化されるので、何が滞留しているかがすぐ分かるようになりました。
また、新しいツールやルールを持ち込むことなく、「今あるSlack文化の中で完結」するのも定着しやすい理由です。
まとめ
レビュー依頼を「きちんと管理しよう」とすると、どうしても新しいツールや運用が必要になり、その運用自体が形骸化するリスクを伴います。
私たちが今回大事にしたのは、
運用は変えず、コストも増やさず、それでも見える化する
という姿勢でした。
Slackのリスト機能は、まだ運用し始めたばかりですが、チームの自然な流れに沿った形でレビュー管理を始めるには、良い選択肢だと感じています。
今後も振り返りやメンバーの声を取り入れながら、継続的に改善していくつもりです。
Discussion