【Slack自動化】休暇表示をミスらない！Bolt×AWSで作る休暇報告アプリ

はじめに

休暇の日って、Slackで「あれ、この人今日いるんだっけ？」ってなりませんか？
弊社ではリモートワーク＆フレックス勤務が基本なので、誰がいつ休んでいるのかが意外と分かりにくいんです。

Googleカレンダーで予定をブロックしたり、勤怠連絡チャンネルに投稿したりはしているのですが、正直すぐ流れます。
結局のところ一番目につくのは Slackの表示名 。
「@山田太郎_8/23休み」 みたいになっていれば一発でわかります。

でも……人は忘れる生き物。
・休みの連絡はしたけど、表示名の変更を忘れる
・休み明け、表示名を戻し忘れて数日経過
・「今日休み」って書いてあるのに既に翌週になっている

…なんてことがしょっちゅう起きていました。

そこで「お願いだから表示名変えてくれ〜！」という願いを込めて、Slackアプリを作りました。

休暇報告アプリの機能

今回作った社内向けSlackアプリ、その名も「休み報告お助け君」。（たぶんもっといい名前があったはず…）
主な機能は以下です。

• 表示名を自動で変更
  • 例：山田太郎 → 山田太郎_8/23休み
• 休暇終了後は自動で元に戻す
• 勤怠チャンネルへの投稿を自動化
  • 定型文でも自由記述でもOK
  • 予約投稿も可能

操作はシンプルで、毎朝6時に送られてくる「ボタン付きメッセージ」からスタート。
あとはモーダルに入力していくだけです。

実際の利用イメージ

▼毎朝ボタン付きメッセージが送られてくる

▼休みの種類と日時を選択

▼休暇取得報告

▼表示名変更と報告の投稿がされる

技術スタックと選定理由

• Slack Bolt for Python
  → 他のBolt SDKと比べ、Lazy listeners が使えるため。

• AWS Lambda & EventBridge Scheduler
  → 表示名を戻す処理をスケジュール管理するため。

Deno SDKも一瞬考えたのですが…

• 表示名を「戻す予約」を組み込みにくい
• Oauthの管理をしっかりやりたい
• 将来的な拡張（Googleカレンダー連携など）が不安

という理由からPythonを選択しました。

【Bolt for Python公式ドキュメント：https://slack.dev/bolt-python】
【AWS EventBridge SchedulerとEventBridge Ruleの比較記事:：https://dev.classmethod.jp/articles/eventbridge-scheduler-and-event-bridge-rule-difference/】

ハマりポイント1：カスタムワークフローとの戦い

最初は「カスタムワークフローステップを使えば皆が使い慣れたワークフローでの開始方法でモーダルの表示できるやん！」と思ったのですが、これが地雷でした。

Bolt for Pythonには interactivity_pointer がのようなものがワークフローから渡されないため、
Deno SDKのように直接 views.open できません。

Slackのサポートにも確認したところ、
「Boltでやるなら一旦ボタン付きメッセージを挟んで trigger_id を取ってください」
との回答。

結局「毎朝ボタン付きメッセージを送る」というアプローチに落ち着きました。
ぜひ今後、ワークフローからカスタマイズされたモーダルが直接表示できるよう機能追加してほしいです。Slackさんお願いします。

【Slackでのモーダルの取り扱い：https://api.slack.com/surfaces/modals】

ハマりポイント2：Oauth権限不足

自分ひとりで開発しているときは、Slackアプリをワークスペースにインストールした人の権限、つまり自分の権限で動けるので問題に気づきにくいんですよね。

つまりどういうことかというと、OAuthで要求する権限が実は足りていなくても、自分では普通に動いてしまう。
ところが他の人にアプリを触ってもらうと、権限不足で想定通りに動かないといった事象が起こります。

今回のアプリは

• ユーザー権限を借りて表示名を変更
• ユーザー権限を借りて勤怠チャンネルに投稿

という仕組みだったので、権限不足は致命的な落とし穴でした。

さらに、Slack APIで as_user=True を付け忘れたときも同様の罠にハマりました。

学びとしては：

• 開発者本人以外にワークスペースにインストールしてもらいテストする
• 他の人にアプリを触ってもらう

この2つを早めにやっておくと、想定外の権限不足にすぐ気づけるのでおすすめです。

【Slack OAuth Scopes一覧：https://api.slack.com/scopes】
【表示名の変更に使用したSlack API：https://api.slack.com/methods/users.profile.set】

良かった点1：表示名を戻す仕組み

休暇終了後に表示名を戻すのは EventBridge Scheduler にお任せ。

Schedulerに

• SlackのユーザーID
• 付け加えた休暇情報文字列

を持たせておき、発火したらLambdaに渡してSlack Apiを呼び出し、元に戻します。

もしアプリよりも先に手動で名前変更されてしまったら？
→ 休暇情報の文字列が一致しなければ何もせず放置。

シンプルだけど壊れにくい仕組みになりました。
日付や時刻をデフォルトで表示名に持っている時短勤務の方からは、間違って削除される心配がないと意外と好評でした。

良かった点2：AWS CDKで本番環境への移行が楽に

今回の開発は、まず社内のサンドボックスAWSアカウントで実装し、その後本番用アカウントに移行しました。

ここで役立ったのがAWS CDKです。

• 環境ごとにスタックを分けられる
  → --profile を切り替えてデプロイするだけで、EventBridgeのスケジュールやLambdaのエンドポイントを環境ごとに分離管理。

• DBとアプリのスタックを分けて管理
  → 消えては困るDBは別スタック管理にし、Lambda更新の際に誤って変更・再作成される事故を防止しました。

• インフラをコード化できる
  → 「コードにどう書かれているか」で再現性が担保される。

CDKを使ったおかげで、開発環境で動いたけど本番で設定不足という事故を防げたのは大きなメリットでした。

実際に手作業でやったのは、Lambda関数のURLをSlackアプリに登録するくらいで、ほとんどの構成はCDKで完結しました。

ちょっとした文言変更やIAM調整も気軽にできて、結果的にCDKを導入して大正解だったと思います。おすすめです。

【AWS CDK公式：https://docs.aws.amazon.com/cdk/v2/guide/home.html】

さいごに

業務効率化＋技術力アップの一石二鳥で、社内ツール開発の楽しさを改めて感じました。
一旦は完成＆公開に漕ぎ着けましたが、Googleカレンダーとの連携や、自動で休暇申請をSlack上で完結させる機能など、まだまだ拡張の余地があります。

今回紹介したハマりポイントは、きっと他のSlackアプリ開発でも共通する落とし穴だと思います。この記事が「同じところでつまずきそうな誰か」の助けになれば嬉しいです。

もし面白いなと思っていただけたら、ぜひいいねやストックで応援いただけると励みになります！