もう『誰かレビューして〜！』って言わなくていい！ 放置PRと戦うSlackアプリの開発とその設計思想プロセス by haruotsu

近年、Claude CodeやCursorやClineなど各種開発支援AIツールの登場によってコードを書く速度が格段に上がり、開発者は以前の数倍のペースでプルリクエストを作成できるようになった一方で、レビュープロセスがボトルネックになっていないでしょうか？
それと同時に、レビューがボトルネックになって、開発速度がなかなか上がらない。なんてことはないでしょうか？
例えば、

• 「このPRだれかレビューして！」
• 「レビュー依頼したけど、誰も引き受けてくれない・・・」
• 「レビューリクエストしたのに一向に進まない・・・」
• 「私ばかりレビューしてる・・・」

こういった悩みをSlack Botで解決する、Slack Review Notifyというツールを開発しました。
https://github.com/haruotsu/slack-review-notify

今回の発表では、実際に導入してチームの声を聞きながら改善を重ね、辿り着いた効果的な設計パターンとSlack block kit builderの実装ノウハウを体系的に解説します。
具体的には以下を発表します。

技術面:

• 失敗から学んだWebhook処理の堅牢な実装パターン
• GitHub→Slack連携における署名検証と非同期処理のベストプラクティス
• Slack Block Kit Builderの書き方と実践的な活用テクニック

設計・運用面:

• 運用データから導いたDB設計の大幅リファクタリング判断基準
• チームワークフローを考慮した機能設計の思考プロセス
• 定量的な効果測定と継続的改善のアプローチ

Slack統合は単なるAPIコールの組み合わせではありません。 適切なアーキテクチャ設計、運用を見据えたDB設計、そして実際のチームワークフローを理解した上での機能実装が必要です。
今回の開発経験から、技術はもちろんのこと、実際の運用体験を踏まえた設計パターンを体系的にお伝えします。

私が悩み抜いた、チーム開発の課題を技術で解決するための思考プロセスをお持ち帰りいただき、自身のチームの課題解決をする際の一手となれば幸いです。