放置PRを許さない、 レビューを加速させるアプリの 実装と設計の道のり

放置PRを許さない、
レビューを加速させるアプリの
実装と設計の道のり

ペパボ & GO 〜 夏のGo祭り2025、あの夏〜
での登壇資料です
https://pepabo.connpass.com/event/363869/

Transcript

1. 1 放置PRを許さない、 レビューを加速させるアプリの 実装と設計の道のり はるおつ @haruotsu_hy 2025.09.16
2. 2 ⾃⼰紹介 ロリポップ‧ムームードメイン事業部ムームードメイングループ 横⼭ 遥⼄ はるおつ • GMOペパボ新卒2年⽬エンジニア • @haruotsu_hy/@haruotsu • 三度の飯よりゾウが好き • Go、Rubyをよく触ります。 • SQL芸⼈ • 呼吸をするようにドメインを買っています。
4. ⽇々開発⽣産性は上がっていく 4 ⽇々開発⽣産性は上がっていく！ https://claude.ai/ https://developers.openai.com/codex/cli https://www.cursor.com/ https://github.com/features/copilot
5. ⼀⽅でこんなことはありませんか? 5 • このPR誰かレビューしてください！ • だれも引き受けてくれない‧‧‧！？ • (2時間後...) 〇〇さん可能であれば‧‧‧！ • 修正 → レビューのサイクルが遅くて全然merge できない‧‧‧ • 私ばかりレビューしているな‧‧‧ ⼀⽅でこんなことはありませんか？
6. 実際 6 実際 コードを書く テストする レビューする 開発生産性が上がりめっちゃ早くなった 大AI時代、超高速な仮説検証 を行う上で、 レビューがボトルネック になっていた。 遅い！ 超少人数のチームや、距離感の近いチームの方が、 PR作成からデプロイまでのリードタイムが早かった (Forkeys)
7. どんなアプリがほしかったか 7 • ラベルをつけたら発⽕ • レビューしていないと、お尻が叩かれて後ろめたい • うるさすぎない • ユーザーが意思表⽰できる • 均等にレビューする機会を与えたい どんなアプリが欲しかったか
8. slack-review-notify 8 • GitHubにラベルが付くと通知 • レビュワーのランダムアサイン • スレッドで定期リマインド • レビュワー変更 • レビュー後⾃動通知 • 定期リマインド • 営業時間考慮 • スラッシュコマンドでの設定変更 slack-review-notify https://github.com/haruotsu/slack-review-notify
9. 実装の際に考えていた機能要件 9 • 管理が楽、誰でも建てられる • メンション、アサイン、完了の⾃動化 • Slackで完結する、だれでも使える設定の容易さ • ⾒ている、交代できる、などの意思表⽰UI • ラベルをつけるタイミングで気まずくならない、 うるさくない 実装の際に考えていた機能要件
10. Let’s 実装 10 技術紹介の中で 「Goならこうやってやるんだ！」「便利！」 を持ち帰ってくれたらわいわいです。 「もっといい方法があるよ」とかも大歓迎 !
11. 技術スタック • Go ◦ 定期実⾏easy! • Gin ◦ ルーティングeasy! • SQLite + GORM ◦ 外部DBいらない ◦ ⾃動マイグレーション最⾼! ◦ インデックス&ユニーク制約easy! • Slack API • GitHub Webhooks 11 技術スタック 単一バイナリでデプロイ楽ちん 外部DB不要 超シンプルイベント駆動
12. 作りたい機能とそれを実現するGo実装 12
13. 実現したいこと 実現したいこと 13 全てをアプリで完結したい
14. SlackやGitHub Webhookとの連携 SlackやGitHub Webhookとの連携 14 いい感じにpost受け取って、いい感じにパースする！署名検証忘れずに！ slack-go/slack, google/go-githubに全部ある！
15. 定期実⾏処理 定期実⾏処理 15 他の処理に関係なく、正確な時間間隔を図るために backgroundで処理する必要がある → Tickerによるgoroutine処理 • goroutineを起動する、Ticker構造体のインスタンス返却 type Ticker struct { C <-chan Time // 受信専用チャネル // ... } go func() { for { time.Sleep(duration) // 60秒待機 select { case ticker.C <- time.Now(): // チャネルに現在時刻を送信 default: // チャネルがフルなら送信しない } } }() case <-taskTicker.C: // チャネルから時刻を受信 • goroutineを起動する、Ticker構造体のインスタンス返却 cronなど外部依存なしで、リマインドを定期的に送信したい • チャネルでselect (他非同期処理と競合しない )
16. 営業時間対応 営業時間対応 16 レビューしていないと、お尻が叩かれる → ありがたいけど、業務時間外はうるさい 営業時間外にラベルをつけるとメンションがなる → 迷惑かも、見れる時に見て速デプロイ 営業時間に応じてタスクステータスを変更
17. 営業時間対応 営業時間対応 17 Tickerでタスク状態のチェック チャネルでselect
18. Slackボタンの作り⽅ Slackボタンの作り⽅ 18 GoでSlackボタンってどうやってつくるの？ → slack-go/slackで気合いのjsonを書く • 見づらい！&エラーの温床 • 呼ぶ場所各所で定義しないと で、コード長くなりがち
19. 再利⽤ 再利⽤可能なものは共通化する！ 19 レシーバで自身を返すことで、メソッドチェーン化 • きれいきれい • 複雑なオブジェクト生成を段階表現 • 型安全
20. DB設計 DB設計 20 第1世代: 1チャンネル1設定 • エンジニアはhoge-devチャンネル、 デザイナーはhoge-designチャンネルにい る想定 • タスクごとにチャンネルを分けている想定 • 同じ名前のラベルを識別するためにチャン ネルをキーにする 実際に運用してみたら・・・
21. DB設計 DB設計 21 第1世代: 1チャンネル1設定 • エンジニアはhoge-devチャンネル、 デザイナーはhoge-designチャンネルにい る想定 • タスクごとにチャンネルを分けている想定 • 同じ名前のラベルを識別するためにチャン ネルをキーにする うちのチャンネル、デザイナーもエンジニアもいるのですが ... needs-reviewだけでなく、bugなどで人によって分けたいのですが ...
22. DB設計 DB⼤改変の決意 22 第2世代: 複合ユニーク制約で柔軟性と制約のバランスを取る • チャンネルとラベルで一意性を担保 • 過度な正規化はしない • GORMでピッとgorm: “index”を貼るだけ • GORMのAutoMigrateで対応 db.AutoMigrate(&models.ChannelConfig{}, &models.ReviewTask{})
23. 23 完成！
24. どうなったか 24
25. レビューサイクルの改善 レビューサイクルの改善 25 時期 平均対応時間 中央値 導入前 10時間54分 9時間22分 導入後 1時間51分 25分 とあるチーム • レビューせずに1日放置することが なくなった • だれがレビューするかに迷いが 生じない お客様の声 爆爆爆改善！
26. まとめ 26
27. まとめ まとめ • 単⼀バイナリで外部依存を最⼩に抑えた設計 • 定期実⾏など⾮同期処理にgoroutineは便利 • Slackボタンのjson管理はしんどいから メソッドチェーンなどでパターン化しよう！ • 複合ユニーク制約で柔軟性と制約の両⽴ 27
28. 28 Thank you! スター⭐、コントリビュートお待ちしています。