new Slack platform でやりたいネタ集 - ツナワタリマイライフ

ここ最近 new Slack platform (この呼び方が正しいかは知らない) でいろいろ作って遊んでいる。

api.slack.com

使い心地や特徴、基本的な使い方は日本語記事でもたくさん出ているのでそちらに譲るとして、これまでやってきた今年含め冬休みに実装したいアイデアを記録しておく。

hanakintro

完全に身内のホビーアプリで、決められた問いかけに対して決められた文言を返すのみ。

github.com

いまオススメの店をサジェストする機能があるが、これをユーザが登録できるようにしたい。現状は conf ファイル的なところに静的に書かれているが、非エンジニアにプルリクを送れというのも無理だと思うので。

これは slack の DB と、Link trigger でできそうである。

api.slack.com

特定のリンクを貼って、ワークフロー的な入力画面を出してオススメの店をユーザが登録すると、DB に登録されるようにできそうである。link trigger 自体は使ったことないので本当かはわからん。

抽象化すると、アイデアやネタをユーザが登録し、botがなんらかのアルゴリズムで返却するということができる。これは今回のような趣味の知見共有もだし、業務のトラブルシューティングだったりオンボーディング支援だったりと、集合知の収集と活用というパターンで幅広く使えると考える。

thanks bot

プロトタイプまで作ったが実用化するのは断念した。

github.com

@thanks @mention message と投稿すると、メンションされた人がこれまで感謝された回数を返信する bot である。

結果は DB に保存して、その総数を返信するところまではできた。DB を使ってみたくてやってみた案件。

実用化できない理由は以下。今回は event trigger (今回だと app_mentioned trigger )であるが、

他の bot へのメンションでも反応してしまう
channel_id を trigger で指定する必要があり、app が動くチャンネルが制限される

いずれも Slack DevRel の瀬良さんからワークアラウンドを紹介いただいたが、

こちらでご報告いただいた問題、まだ直ってはいないのですが、回避策を整理して記事にいたしました。もしまだご興味おありでしたらぜひお試しください。 https://t.co/P7fBM9MIJQ #SlackDevJP #Deno
— Kazuhiro Sera (瀬良) (@seratch_ja) 2022年12月21日

なお、今の挙動が正で filter で自分のアプリのメンションかどうかを判定する必要がある場合、先ほどお示ししたようにトリガーを設定するワークフローを別で作って、そっちで https://t.co/D5qh1quaZ2 を呼び出した上で trigger を生成すれば filter.statement に ID を埋めることが可能です。
— Kazuhiro Sera (瀬良) (@seratch_ja) 2022年12月4日

1 についてはまだフィルターしたり、あるいは本家が治るのを待ってもいいのだが

2 はユーザが登録チャネルを増やすのを link trigger でやる、というのをイチイチやるのは面倒である。いつでもどこでも thanks したい。そのため見送った。

ワークスペースグローバルな event trigger が許容されるといいが、まぁベータだしチャネル制限はするよなというのはわかる。内部構造はわからんがグローバルだといろいろ負荷は大きそうだし。

問い合わせ記録bot

自分のチームはチームへのメンションに特定のリアクションをつけ、reacji で特定のチャンネルに流して、それを daily meeting でおさらいして共有したり、新規で反応できてないものへの対応策を決めたらするという営みがある。

ただしこれでは統計量の収集をしたり、中長期での分析をするのに一手間必要になってくる。

そこで該当チャンネルへの message posted event を使い、spreadsheet に追加する bot を実装したい。

spreadsheet じゃなくても DB 保存でもいいのはいいんだが結果のメンバー共有は楽にしたいので。

emoji_changed event でもいいんだが、前述のチャンネル制限の問題がある。こちらは自分のチームはの問い合わせが起きるチャンネルはある程度限定されるものの、どこで発生するかはわからない。

api.slack.com

そのため現状の reacji 運用を続け、流されるチャンネルでのみ動くようにする。

気になりとしては reaji がついたメッセージだけをフィルターできるかどうかぐらいである。(スレッドに回答サマリーをメンバーが登録している)

message post のデータでフィルターできなくとも、まぁ最悪 emoji ついてるかどうかをファンクション側でフィルターすればいいからなんとかなるかなと思っている。

これは抽象化すると、特定のチャンネルのメッセージを分析可能にする(シートに転送する)という処理になる。native に会話されてるチャンネルでやってもいいかもしれないし、今回のように reacji を活用すれば特定のコンテキストを人間が収集し、それを分析できるようになる。これも活用可能性は広いアイデアだと考える。

display name 変えたら戻す君

所属会社での slack workspace では slack display name と github id と google エイリアスを一致させるという規約がある。yaml でグループが一元管理され、それが CI で同期される。

そのため display name を変えると CI が落ちる。

display name なんて user preference な値をキーにするなよというのはごもっともであるが、これによって ID の強制ができるので、ID のみでコミュニケーションができる。

現状の慣習だと休み予定などのステータスを display name で表現する組織が多いように思う。組織も大きくなってきており、周知だけでなんとかするのも難しくなってきた。

実装だが、残念ながら profile change 相当の event trigger はこの platform でサポートされていない。しかし意地でもマネージド環境で動かしたい。そのため、schedule trigger で定期的に動かしつつ、直近プロフィールを変えたユーザがなんかを api でとってくるか、display name がリポジトリにある yaml 定義と異なるユーザを見つけてきて、強制的に修正しつつ DM で通知する、という機構を作るのかなと思っている。

本当はプロフィール変更イベントをキャッチして戻すというふうにできればより簡単にできるだろう。ただ現状の影響が大きいので実装してしまおうと思う。

このパターンはある静的なパターン(yamlなど)との一貫性を矯正するということになる。が、event 稼働でなくスケジュールというところがラグがあってイケてないよなぁ。プロフィールになんらかの規約を持たせたくて、さらにそれを強制化したいみたいなユースケースがあれば同じパターンとして適用できるかもしれない。