pixi-nudge 開発エピソード

背景

PRのレビュー依頼に気づかず、そのまま放置されてしまうことがあった。 GitHubの通知は他の通知に埋もれがちで、確認も後回しになりやすい。 そこで、毎朝Slackに「自分宛てのレビュー待ちPR」が届くbotを作ることにした。

なぜ「nudge」か

このbotは「Reminder」ではなく、あえて「nudge（ナッジ）」という名前にしている。

nudgeは「ひじで軽く突く」という意味があり、「おい！早くやれ！」と強制するのではなく、 「忘れてない？（ツンツン）」くらいの軽い気づきを与えるニュアンス。

また行動経済学の「ナッジ理論」にも由来しており、強制せず、選択の自由を残したまま良い行動に導くという考え方をベースにしている。

レビューを義務として押し付けるのではなく、自然と動きたくなる仕組みにすることでチーム全体の生産性向上を狙っている。 …とそれっぽいことを言いつつ、単純に自分が抜け漏れそうなので作った。

なぜGoか

技術選定の理由

• シンプルさ: Goはワンバイナリで動くし、言語仕様がシンプル。この規模のツールにフレームワークや複雑な依存関係は不要で、標準ライブラリ+GitHub SDKだけで完結できる
• GitHub Actionsとの相性: ビルドが速く、GitHub Actionsの実行時間を最小限に抑えられる。Node.jsのように node_modules のインストール待ちもない
• GitHub公式SDKの充実: go-github というGoogle公認のGitHub APIクライアントがあり、型安全にAPIを扱える
• 保守性: 型があるので、メンバーの追加やロジックの変更時にコンパイルエラーで気づける。シェルスクリプトやPythonだと実行するまでミスに気づかない

ぶっちゃけた理由

最近Go触り始めたので練習がてら作った。

やったこと

1. PRレビューリマインダーbotの開発

Go言語で、pixi-teams org配下の全リポジトリからレビュー待ちPRを収集し、Slackにメンション付きで通知するツールを作った。

2. コードのリファクタリング・ファイル分割

もともと1ファイルだった main.go を責務ごとに3ファイルに分割：

• main.go — エントリーポイント
• github.go — GitHub APIからのPR取得・レビュアー判定
• slack.go — メッセージ構築・Slack Webhook送信

3. ガイモン風の挨拶メッセージ（20パターン）

Slackに通知する際の冒頭メッセージを、ワンピースのガイモン（20年間箱に閉じ込められた男）のセリフ風に20パターン用意。PRの放置を許さない熱量で語りかけてくる。

4. GitHub Actions + cronjob.org での定期実行

• GitHub Actionsのトリガーを repository_dispatch に変更
• cronjob.org から毎朝8時にAPIを叩いてワークフローを起動する構成に

5. Slackでチームに周知

背景・仕様・注意点（コメント後はレビューリクエスト再付与が必要）を整理して、「nudge」の名前の由来（ナッジ理論）も添えてチームに共有した。

注意点・今後の課題

• GitHubの仕様上、コメントやApproveをするとレビューリクエストが外れるため、修正後に再度レビューが必要な場合はリクエストの再付与が必要
• チーム宛てのレビューリクエストは現状検知できない（個人宛てのみ対応）