Slack App 開発をする上での権限問題の回避の仕方

こんにちは。CDOの @sawa-zen です。

Topotal では Waroom(ワルーム) という SaaS を作っており、Waroom は Slack App を使った機能が数多くあるため Slack App の実装をする上での知見がだいぶ溜まってきました。中でも予想外だった Slack Workspace の権限周りからおこる問題について共有したいと思います。これから Slack App を開発したいという方に届くと嬉しいです。

前提: Slack App の種類

Slack App は2つの種類に大きく分けられます。

• A: Bot Token を用いて認証を行う Slack App
• B: User Token を用いて認証を行う Slack App

一般的にBotを使った Slack App の開発をしたい場合は A の Bot Token を用いて認証を行う形式になります。Waroom のような SaaS としてボットを作成し、ユーザーと対話させたり、自動化されたタスクを実行させたい場合はこちらのタイプになります。B の User Token を用いるパターンに関しては後ほど説明します。

Bot Token が持つ権限範囲により発生した課題

Bot Token の Slack App は Bot としての権限に絞られており、実はあまり強い権限を持ち合わせていません。そのため当初 Bot Token のみで開発していた Waroom では以下のような問題が発生しました。

1. Slack チャンネルの作成権限が一部のユーザーに絞られると Slack App からチャンネルを作成できない
2. Bot によるマルチチャンネルゲストのチャンネルへの招待ができない

1. Slack チャンネルの作成権限が絞られると Slack App からチャンネルを作成できない

Waroom ではインシデントが作成されると Bot によって「インシデント対応専用 Slack チャンネル」が自動的に作成する機能があります。ただ、Slack Workspace の設定で「Create public channels」の権限が一部のアカウントに絞られたものになっていると Bot がチャンネルを作成できなくなるということがわかりました。

Slack のチャンネル作成権限

2. Bot によるマルチチャンネルゲストのチャンネルへの招待ができない

ゲストをパブリックチャンネルに招待できるのはワークスペースオーナーまたは管理者に制限されています。そのため Bot が持つ権限では招待できません。Waroom では作成された対応チャンネルに自動的に対応チームを招待する機能があるのですが、マルチチャンネルゲストとなっているメンバーが招待できないというお問い合わせをいただいたことがありました。

slack.com

解決方法: User Token 版 Slack App の提供をする

ここで先程説明にでてきた B の User Token を用いた Slack App が活躍します。Bot Token の Slack App との大きな違いは Slack App をインストールした User アカウントの Token を用いるため、その User の権限で Slack App が API を実行することができます。

先の２点の問題に遭遇されてしまったお客様に対しては、権限の強い User アカウントから User Token 版の Slack App をインストールしていただくことで解決しました。

ちなみに他の方法は無いのか Slack に直接問い合わせたところ、設定を変える以外だとこの方法しかないと回答もいただいているので他に手はなさそうです。

Slack からのメール

User Token 版の Slack App を提供する上での注意点

ただ、この方法で Slack App を提供する場合は以下の点について注意が必要です。

1. Slack App からのメッセージの投稿元が Token に紐づいた User から来たように見える

先ほど説明した通り User Token 版はインストールをしたUserアカウントに紐づいた Token で Slack API を実行することになります。例えば postMessage API を実行すると、そのユーザーから送られたような見た目になります。また、該当のユーザーは自分が送信したメッセージとして扱われるためそのメッセージの投稿の通知に気づくこともできません。

以下は Owner という名前のアカウントで User Slack 版のインストールをした場合の例です。インシデント作成の通知が Waroom Bot ではなく Owner アカウントから通知されています。

解決策

解決策としては、Slack App 用に新しく Slack アカウントを一つ新設してもらいそのアカウントでインストールをしてもらう方法があります。そうすることで通知もすべての人に届くようになり、見た目の問題から混乱をうむこともありません。ただし、1アカウント分の Slack での課金が発生してしまうため、お客様に提供する場合はアカウントの新設を許容いただけるか確認する必要があります。

2. 実装面での複雑さが増す

Bot Token と User Token とで持つ Token の種類も異なれば、持ち合わせている Scope も異なります。一つの機能を開発するうえで両 Slack App の機能が正しく動作するかの QA を行う必要もありますし、コード上には分岐がふえるので慎重に行いましょう。

まとめ

今回紹介したケースを想定していないと実際に実装したときに予想以上の工数がかかってしまったり、インシデントを引き起こしたりしかねません。 もし周りに Slack App をつかった SaaS を提供しようとしている人がいましたら是非紹介してあげてください。

最後に宣伝

インシデント発生時に Slack から離れること無く、効率よく対応するための SaaS、 Waroom（ワルーム） を提供しています。AI を用いて Slack の情報から自動的にインシデント概要をまとめる機能や、ポストモーテムを生成する機能など Slack を用いた機能が盛り沢山なので是非お試しください。 waroom.com

カジュアル面談も募集しています！ゆるくお話しましょう！ youtrust.jp

SRE NEXT 2024に参加しました

こんにちは。CEOの@nari_exです。2024年以降、一番おいしかった食べ物は岩崎農園のとちあいかです。

Topotal（トポタル）はSREを主軸にした会社であり、国内でも有数のSREカンファレンスであるSRE NEXTには毎年積極的に参加しています。前年に引き続き、今年も多岐にわたって活動することができました。この記事では、カンファレンス当日のTopotalの活動をざっくりお伝えしたいと思います。

ブース出展

今年もGOLDスポンサーとして協賛し、ブース出展を行いました。ブースでは、Topotalが提供するインシデントマネジメントSaaSのWaroom（ワルーム）のグッズの配布とデモによる機能紹介を行いました。

ブースの様子

また、来場者アンケートを集計したところ、インシデントマネジメントに関するツールがまだまだ普及していないこと、ドキュメントの自動生成とトレーニング機能について多くの期待が寄せられていることがわかりました。

この他にも、デモ後のディスカッションを通じて、オンコール機能への関心が全体的に高いこと、Waroomの既存機能にまだまだ改善点があることも認識できました。

アンケート結果

カンファレンスが行われた2日間ともブースは大盛況となり、今年もたいへん貴重な意見をたくさんいただくことができました。ありがとうございます。フィードバックをもとにWaroomをよりよいプロダクトにしていきたいと思います。

スポンサーLT

GOLDスポンサーの特典として、スポンサーLTの機会をいただいたので、CTOの@rrreeeyyyが「An Efficient Incident Response Training with AI」というタイトルで発表を行いました。

speakerdeck.com

この発表の前半では、インシデント対応のむずかしさに言及し、その1つの解決策であるインシデント対応訓練の実践には多くのコストがかかる問題を指摘しています。

そして後半では、課題の解決策として「AIを活用したCost-Effectiveなインシデント対応訓練」を提案した上で、Waroomのインシデント訓練機能とより発展的な訓練のアイディアを紹介しています。

補足: Waroomではインシデント訓練機能として、サービスのコンテキスト（システム構成やサービス特性）を加味して訓練シナリオを自動生成する機能とシナリオに基づいたロールプレイ型の訓練をSlack上で進行する機能の2つを提供する予定です。

Waroomは単に効率化するためのツールではなく、使い続けることでインシデントマネジメントを漸進的に改善できるツールにしたいと考えています。その一手として、Topotalは発展途上である訓練領域の課題に着手し、インシデント対応の民主化を後押しするための機能を考案しました。

本LTが好評だったこともあり、ブースではトレーニング機能のデモ依頼をたくさんいただき、良いフィードバックを得ることができました。

来年のSRE NEXTでまたブース出展ができれば、今年のようになにか良い発表ができればと思っています。

セッション

Topotalからは @rrreeeyyy、@yuuk1、@nari_exの3名がセッションやパネルディスカッションを行いました。

セッション: 工学としてのSRE再訪

Topotalのテクノロジアドバイザーであるyuuk1さんによる発表です。SREに関する学術的な専門知識を踏まえた上で、未発見課題へつながる問いについて考察を深める本講演は、ベストスピーカー賞を受賞したことからもわかる通り、すばらしい発表でした。当日参加されていない方はぜひご覧ください。

資料

speakerdeck.com

ブログ記事

blog.yuuk.io

セッション: 組織的なインシデント対応を目指して〜成熟度評価と改善のステップ〜

本記事の著者である私の発表資料です。SRE as a Serviceの担当SREとWaroomのPdMを兼務する日々の過程で生まれた「インシデントレスポンスを段階的に改善するための道標はないだろうか」という悩みに対して、インシデントレスポンスの成熟度モデルを構築しながら対処した経験や知見を発表しました。

本発表の背景や裏話などはまた別の機会に書きたいと思います。不運にもyuuk1さんの発表時間帯と丸かぶりしてしまった本セッションでしたが、おかげさまで会場もほぼ満席でAsk the Speakerでは時間いっぱいまでディスカッションを行うことができました。

資料

speakerdeck.com

インシデントレスポンスの成熟度評価

インシデントレスポンスの成熟度評価

パネルディスカッション: SREの技術トレンド2024

@katsuhisa__、@rrreeeyyy、@yuuk1、@deeeet の4名によるパネルディスカッションです。

Waroomのブースが大盛況だった影響で私は参加できなかったのですが、立ち見が出るほど盛り上がったようです。

オフライン限定の北野 勝久 さん、rrreeeyyyさん、yuuk1さん、deeeetさん によるパネルディスカッションは、立ち見が出るほどの盛況です#srenext #srenext_c pic.twitter.com/8O5YMMQFVj

— SRE NEXT (@srenext) 2024年8月4日

感想

今年のSRE NEXTも非常に楽しかったです。それがなにより良かったと思っています。今回、私は参加者・スピーカー・ブース担当者の3つの立場で関わりましたが、いずれも不自由なく目の前のことに集中することができました。懇親会も大盛りあがりでしたね🍺

運営のみなさま、SREコミュニティのみなさま、すばらしいカンファレンスをありがとうございました。

まとめ

Topotalは今年もさまざまなシーンでSRE NEXTに参加・貢献しました。その結果、TopotalやWaroomをより多くの人に知っていただくよい機会になりました。本記事では大きく取り上げていませんが、COOの@kenta.hiがSRE NEXTのCo-Chairを務めたこともコミュニティに対する大きな貢献の一つでした。

これからもTopotalはSREを主軸にしたスタートアップとして、Site Reliability Engineeringを加速させるサービスの提供はもちろん、コミュニティへの貢献も積極的に行いながら、業界の発展に貢献していきたいと思います。

今後ともTopotalをよろしくおねがいします🙏

最後に

おかげさまで、カンファレンス直後からさまざまな企業さまからWaroomのトライアルのお申し込みやデモの依頼をいただいています。この記事を読んでご興味が湧きましたら、以下のリンクから気軽にリクエストをしてください。

waroom.com

また、TopotalではSRE as a Serviceをともに提供するSREやWaroomを開発するバックエンドエンジニア（Ruby on Rails）を募集しています。SREのプラクティスを用いて世の中の開発・運用の現場を一緒に変革していきましょう。ご応募お待ちしております。

jobs.topotal.com

Waroom ロゴができるまで

こんにちは Topotal CDO の @sawa-zen です！2020年から Waroom の開発をはじめて四年が経ち、おかげさまで Waroom を使ってくれているお客様や知ってくれている方がだんだんと増えてきました。そこで皆さんにさらに Waroom について知ってもらおうということで、 CDO っぽい記事第一弾として Waroom のロゴができるまでについて語ろうと思います。

実は Waroom ロゴは僕が開発初期に勢いよく作ってしまったので社内メンバーも完成までの経緯をよく知りません。そのためこの記事は社内メンバーに向けての記事でもあります。

一般的なロゴの構成について

Waroom のロゴの説明に入る前に一般的に用いられるロゴの構成について説明します。 ロゴは「シンボルマーク」と「ロゴタイプ」の2つで構成されていることが多いです。

なぜこの2つで構成されるかというと、シンボルマークを見れば会社を連想できるし、連想できない場合でもロゴタイプを読めば社名やプロダクト名がわかるといった合理的な構成になっています。ロゴタイプのみの場合もありますが、スマホの登場でアプリアイコンとしてのシンボルマークの用途が増えていきたことで、最近ではシンボルマークのある構成を多く見るようになりました。

Waroom ももちろんその構成に則っています。

なぜ「青」を使ったのか

「war room」や「インシデント」と聞いてまず連想するのは炎上している様子です。つまりは炎 🔥 です。そのため最初は赤色やオレンジ色などの暖色をイメージしていました。他にも緊急事態感を出すために黄色と黒の構成も考えていました。

ただ、インシデント対応をする場面はただでさえストレスのかかる場面にもかかわらず、使うサービスのロゴマークも黄色や赤でストレスをかけるのはいかがなものかと思い、暖色を使うのをやめました。

そこから「Resolved」を表す「緑」か、消化する「水」を連想させる「青」どちらかにしようと考えました。ただ、緑をロゴに使用してしまうと、そのプロダクトのプライマリーカラーとして使用することになります。緑は UI 上では「成功」や「決定」のような意味のあることが多いです。Waroom はインシデントのステータスを表現することを想定すると緑をプライマリーカラーとして使用するのは難しいと判断しました。

結果として青に落ち着こうとしていたところで、弊社代表の高村が「青が好きなのでプロダクトのロゴは青にしてほしい」と言われて完全着地しました。（本人覚えてるのかな）

具体的になぜあのカラーコード(#1765C1)になったかは当時のフィーリングで選んでいます。ただ、明度や彩度はWebサービスとして扱いやすそうなラインになるように選んだ覚えがあります。

シンボルマークになぜ消火栓を選んだのか？

正直シンボルマークはかなり悩みました。「war room」というプロダクト名なので「部屋っぽさ」や「チームで集って対応している感」を表現しようと四苦八苦しました。その痕跡を貼っておきます。

↑右下のやつは僕の中で仮決定したシンボルマーク

この時点ではまだ暖色にこだわっており、マークとしてもどれもしっくり来ることがなかったので考え直し始めました。

そこで、Waroom を使って対応している人たちの僕の中のイメージを絵に描いて眺めてみてみました。そのときの絵がこちら。

燃え広がっている炎に果敢に立ち向かう人々

コマンダーが指揮をとってレスポンダーが消火作業していてかっこいいですね。でも、ここに Waroom があるとしたらどこにあたるだろうか？と眺めていて気づきました。

このあたりじゃない？

あくまで対応者は人間であり、Waroom は消化活動になくてはならないインフラ的存在になっていてほしい。あのホースの先にあるとしたら消防車や消火栓なのでそのあたりをモチーフにしたいと考えました。ただ、消防車も消火栓も赤色ですが、消火栓はシルエットとしてシンプルでわかりやすく青にしてもさほど違和感が無いことに気づいたのでそっちの方向で詰めていきました。

最初はロボットの頭だったけどそれはボツに

だんだんできてきましたね。あと少し。

ロゴタイプは？

ロゴタイプは結構適当でした。出来上がったシンボルマークに対してマッチしそうなフォントを選んだ結果 Solway というフォントになりました。この時点ではバランスを整えるために文字詰めだけは行っています。

シンボルとフォントをそのままのロゴタイプを合わせた様子

最後の味付け

やや野暮ったい感じがあったので細かいラインを直しつつ、もう少しギーク感を出したく監視ツールなどでよく見る六角形を盛り込んで今のロゴが完成です！全体的に統一感が生まれましたね。

完成！

Topotal のロゴとテイストが違い会社全体で統一感が無いのはやや課題ですが、ロゴの商標登録もしているし、個人的には気に入っているのでしばらくは大きく変えることは無いと思います。以上が Waroom のロゴができるまでの流れでした！ありがとうございました！

最後に宣伝

インシデント発生時に Slack から離れること無く、効率よく対応するための SaaS、 Waroom（ワルーム） を提供しています。AI を用いて Slack の情報から自動的にインシデント概要をまとめる機能や、ポストモーテムを生成する機能など Slack を用いた機能が盛り沢山なので是非お試しください。

https://waroom.com/

youtu.be

Waroom Meetup #1 を開催しました

はじめに

こんにちは！ Topotalのkenta_hi です。

このブログは、6月4日に行った Waroom Meetup #1の開催レポートについて書きます。 想定している読み手は次のとおりです。

1. Waroom Meetup #1に参加した方に向けて、Topotalがどんな思いで開催したのか知りたい人
2. Waroom Meetup #1に参加できなかった方に向けて、どんなイベントの雰囲気だったか知りたい人

それでは、始めます！

Waroom Meetup#1を開催しようと思った背景

Webサービスの広がりとともにSREが普及し、さまざまな企業のSREの活動内容は勉強会やイベントを通じて発信され、SREの活動のプラクティスを知る機会が増えました。

Topotalのメンバーも発信を行っています。

その中でインシデントレスポンスの領域だけは、各社が模索しながら改善を進めておりプラクティスの共有が徐々に増えてきたものの、発表の場がまだまだ少ないと感じていました。

インシデントレスポンスを共有する場が少ないのは、インシデントレスポンスの特性にあると思います。 過去は障害が起きないこと・起こさないことが重視されていましたから、ネガティブな発信になってしまう可能性があります。また、そのシステムごとの背景もあるため、仔細な説明が難しいのではないでしょうか。

しかし、昨今ではSREのプラクティスが浸透しエラーバジェットの概念が理解されたことで、インシデントの取り扱いが変わってきました。 こういった背景とTopotalはSREコミュニティへの貢献を1つの軸として活動していることも相まって、イベントを開催することに至りました。

Waroom Meetup#1 の内容

今回は第1回ということもあり、すべてのセッションを招待制で行いました。社内で登壇いただきたい方の候補をあげ、発信している情報を確認しました。

そこから考えた今回のテーマは、インシデントレスポンスの始め方から改善のプラクティスを集めることにしました。

この理由は、これからインシデントレスポンスを始める方にも、すでにインシデントレスポンスのツールを使っている方にも有益な情報になると考えたからです。また、インシデントマネジメントSaaSを展開するWaroomとも適していました。

このテーマにぴったりなWaroomを導入と共にインシデントレスポンスの整備をしたLuup @gr1m0hさん、内製Slack Appでインシデントレスポンスの改善を進めている10X @sota1235さんのおふたりにお声がけしました。

おふたりの発表資料は、インシデントレスポンスを現場で実践したとても興味深い内容でした。

資料は以下のURLからご確認いただけます。

Luupの開発組織におけるインシデントマネジメントの変遷 @gr1m0h

speakerdeck.com

内製したSlack Appで頑張るIncident Response@Waroom Meetup #1 / Incident Response with Slack App in 10X @sota1235

speakerdeck.com

ほかには、SREに関する論文の紹介を@yuuk1tさんに共有いただきました。

#SRE論文紹介 Detection is Better Than Cure: A Cloud Incidents PerspectiveV. Ganatra et. al., ESEC/FSE’23

speakerdeck.com

Microsoftがアラーティングに対して実地で調査して問題提起した内容になります。解説をいただきながら、共有いただくとより理解が進みました。このような論文紹介は、定期開催してもらいたいなぁ〜と思っています。

最後は、TopotalからWaroomの開発秘話と今後のアップデートについて@nari_ex から共有しました。

Waroomの開発モチベーションと今後のロードマップ / Waroom development motivation and roadmap

speakerdeck.com

「つらい」インシデント対応を無くすというワードがいいなと、私は思っています。

インシデントがなくなることはありませんが、言語化した課題（質と量、連携の課題）は解決できる問題です。

この課題が少しでも減っていくことで、インシデント対応から学びを得られる機会が増えていくと私は信じています。

最後の懇親会は、皆さんが思い思いに交流できていたように見えました。お酒を飲みながら、Waroomのデモをつまみに話が盛り上がったり、開発秘話を話したり、お互いの仕事の悩みを共有したりしていました。その後、2次会には14名の方が参加し、より深い話ができたのではないかと思います。

人と人とのつながりを生み出せたと感じ、開催して良かったなと思える瞬間でした。

次回にむけて

みなさま、アンケートにお答えいただき、いろいろなご意見をいただきました。アンケートの内容も加味しWaroomMeetup#2 を企画していきたいと思います。 次回は、今回できなかった公募の発表も募集したいと考えています。インシデントマネジメントの活動の知見がある方は、ぜひお声がけください。 次回の開催は、2024年9月〜10月頃の開催を予定しています。

最後に

イベントを運営するぞ！に注力しすぎて、Blogに載せられるような写真がない問題が深刻ですね。みんなで最後に集合写真撮るかとかできなかったのが個人的にはちょっと悲しいです。

次回は、司会進行かフォトグラファーをアサインしようと思っています。

jsx-slack で Slack App を開発すると幸せになる話

こんにちは。CDOの @sawa-zen です。

Topotal では Waroom(ワルーム) という SaaS を作っており、 Slack App を使った機能もあるため Slack UI を構築する場面が頻繁にあります。

ただ Slack UI の開発は Web UI などの開発と比べると開発しづらく、なんとか解決できないかと悩んでいた中で見つけたのが jsx-slack でした。 結果として劇的に開発体験が向上したので今回は jsx-slack を使用するといかに幸せになれるかをご紹介します。

https://github.com/yhatt/jsx-slack

Block Kit のつらさ

まず jsx-slack の魅力を伝える前に現状の「つらさ」をお伝えします。 Slack UI を構築するには Slack が提供してくれている Block Kit という UI フレームワークを使用するのですが、これがなかなかにシンドい。。。

• 1️⃣ 非直感的な JSON で UI を構築する必要がある 😢
• 2️⃣ Block Kit Builder がやや使いづらい 😢

https://api.slack.com/block-kit

1️⃣ 非直感的な JSON で UI を構築する必要がある 😢

Block Kit は JSON 形式で UI を構築します。例えばこんな UI を構築したい場合の Slack API に渡さなければならない JSON データはこちら。

構築したい UI に対して記入する JSON の量が多く感じます。また JSON のままでは直感的にレンダリングされる UI のイメージが湧きづらいです。このサンプルはかなり簡素なものなのでまだギリギリイメージできますが、フォーム系のUIが加わるとより複雑化します。このJSONをメンテナンスしていくのはかなり骨が折れます。

2️⃣ Block Kit Builder がやや使いづらい 😢

1️⃣のペインを解消すべく Slack は Block Kit Builder というエディターを用意してくれています。Block Kit Builder を使えば、API Document を確認することなく Web UI からボタンを押すだけで JSON を生成できます。生成された JSON を右側に用意されているエディターから編集もでき、作成したUIを実際に自分の Slack Workspace に送る事ができるため便利です。

ただこのエディターの挙動があやしく、意図しないタイミングでコードが消えてしまったり、UNDOができなくなるタイミングがあったりと、使っていると「キィーーーー！」と叫びたくなる事が多々あります。ここに関しては今後の改善に期待です。

ここまでで現状の Slack UI 開発のペインがざっくりわかっていただけたと思います。

jsx-slack という名の救世主

これらを解決してくれるのがこの jsx-slack です。その名の通り jsx を使ってこの JSON を作成できます。この jsx-slack を使って記述することで多くのメリット享受できます。

UI をイメージしやすい 👍

百聞は一見にしかず。先程の例で言うと以下のようなコードになります。

JSON で書いたものと比較すると圧倒的に記述量が少なく、また自分のようなフロントエンドの開発に長く携わってきた身からすると jsx で記述されているだけで出来上がる UI がイメージしやすいです。

ただ、この「イメージしやすい」というのにはもうひとつ理由があります。

HTML ライクに書ける 👍

jsx-slack はなるべく HTML ライクに書けるように設計されおり、 p や img、 blockquote などの HTML タグをいくつか使用できます。そのため、より親しみ深いコードで記述できイメージがよりしやすくなっています。またHTMLの知識があるだけで構築できるため学習コストも少なく感じました。

REPL が用意されている 👍

jsx-slack にも Block Kit Builder のような、ちょっと試したい時のエディターが用意されています。こちらはプレビューやボタンからUIを追加する機能はありませんが、シンプルで使いやすいエディターと Block Kit Builder でプレビューするためのボタンも用意されているため快適に構築できます。

基本的には VSCode などでコードを書くことになると思いますが、ちょっと確認したい時にはかなり重宝します。

https://jsx-slack.netlify.app/#message

まとめ

もし既に　Slack App の開発をされている方であれば jsx-slack の良さが分かっていただけたかと思います。TypeScript 以外の言語で Slack App を開発されている場合でも UI の構築だけ jsx-slack に切り出すだけでも開発体験が絶対に良くなると思うのでおすすめです!

是非 jsx-slack を使って楽しい Slack App 開発をしていきましょう！

最後に宣伝

インシデント発生時に Slack から離れること無く、効率よく対応するための SaaS、 Waroom（ワルーム） を提供しています。AI を用いて Slack の情報から自動的にインシデント概要をまとめる機能や、ポストモーテムを生成する機能など Slack を用いた機能が盛り沢山なので是非お試しください。

https://waroom.com/

youtu.be