はじめに
今すぐ使いたいぜ〜というテンションで通知ゲートウェイの Takanawa というツールを作りました。現在、所属している家庭と企業で試運転しながら便利を獲得しています。
https://github.com/june29/takanawa
モチベーション
家庭や勤務先のペパボなど、いくつかの組織で Scrapbox を活用しています。ペパボでの活用の様子についてはいくつか記事があります。
- チーム内コミュニケーションを加速させる、GMOペパボSUZURI事業部のScrapbox活用法 – Scrapbox – Medium
- Scrapboxでリアルタイム共同日報をやってみた - shimoju.diary
ぼくが Scrapbox を活用している現場では、同時に Slack も活用していることが多いです。となると、Scrapbox 上のコンテンツの変化を Slack への通知で知りたくなるのが人情というもの。
Slackに更新を通知する - Scrapbox ヘルプ の通り、Scrapbox には Slack への通知機能があり、Slack 側で発行した Incoming Webhook の URL を設定しておくと、その Incoming Webhook で指定したチャンネルで更新情報を受信できるようになります。
さて、ペパボは複数のプロダクトを有する組織で、ほとんどの場合、プロダクトごとにその開発チームが存在し、Slack のチャンネルも Git のリポジトリもプロダクトごとに用意されています。開発を進めやすくしようと思ったら、自然とそうなりますよね。
「じゃあ Scrapbox も、プロダクトごとにプロジェクトを用意するか？」となるわけですが、ことは Slack のチャンネルや Git のリポジトリの場合ほど単純ではありません。まず、ぼく個人は、誰でも参加できる scrapbox.io/hub というものをつくって個人用の scrapbox.io/june29 から移行するほど、Scrapbox はあれこれをごちゃまぜにして使うほど価値が出るものだ、と考えています。Scrapbox の大きな魅力である「ドキュメント同士がつながる」を最大限に引き出そうと思ったら、なるべくプロジェクトは分けない方がいいはずです。同じように考える人は社内に何人もいました。
しかし、プロジェクトをひとつにすると、通知先の Slack チャンネルはひとつになってしまいます。困りましたね。そこで Takanawa をつくった、というわけです。
Takanawa の概要
2019 年 6 月 1 日現在の Takanawa は「Scrapbox の通知の HTTP リクエストを受け取って、その中身を確認し、条件に合わせて Slack のチャンネルに振り分けるアプリケーション」です。詳細は https://github.com/june29/takanawa をご覧ください。
これによって、Scrapbox ではひとつのプロジェクトにすべてのドキュメントをまとめつつ、トピックごとに通知先チャンネルを切り替えられるようになりました。プロダクト A に関することはプロダクト A のチャンネルへ、プロダクト B に関することはプロダクト B のチャンネルへ、両方に関わることは両方のチャンネルへ、という具合です。
「なめらかな通知」という着想
これが本記事のメインの話。いくつかの組織で Takanawa を試運転してみて、なかなかおもしろい洞察が得られたので書いていきます。
Takanawa を使うと「この通知は、あっちのチャンネルにもこっちのチャンネルにも投稿される」ってことが起きるんですよ。それが新鮮でおもしろくて。通知が Taxonomy 的なものから Folksonomy 的なものに変容していく感じ。これを体験して、Slack などの「チームの場を形成するツール」への通知は、もっともっとなめらかになり得るな〜と感じました。ここでいう「なめらか」というのはもちろん、書籍「なめらかな社会とその敵」から借りています。
関連 : 書籍「なめらかな社会とその敵」を読みました - #june29jp
これまでぼくは「GitHub のリポジトリの更新情報を Slack で受け取れるの便利、ワーイ！」と無邪気によろこんできたわけですが、基本的な連携は「リポジトリとチャンネルを 1 対 1 の関係で紐付ける」ので、図示すると以下のような状態になります。通知設定を多重に施せば「1 対 n」にできることは承知していますが、本筋から逸れるのでここでは置いておきます。
さて、情報の通り道がこのようにパキッと分断されていると、そこで活動するチームの構造も下記のような形状であることが強化されていくでしょう。チーム A の人からチーム B の情報が見えにくくなればなるほど、関心を寄せることが難しくなり、ますます分断が進みます。
これがもし、間に Takanawa のような仕組みを挟むことで「これはチーム A の話題だけれどチーム B のみんなにとっても有益だよ、だからチャンネル B にも通知しておくね」が実現されるとしたら、チームの境界は曖昧になり、チームとチームの間に重なりが生じていくのではないかと考えます。
もう何年も便利に活用してきた「GitHub と Slack の連携機能」ひとつをとってみても、これがぼくらの組織にとって理想的なカタチをした機能なんだっけ？と考えてみると発見がありました。用意されている機能をそのまま使うだけじゃなく、自分たちが考える「これがベター」というカタチにアレンジして使ってみると、今とは違った景色が見えてくるのかもしれません！
おわりに
最初は「とりあえず、これがないと困るから」と思って Takanawa をつくりました。それは「Scrapbox と Slack の間に置く通知ゲートウェイ」として生まれました。
Takanawa を試運転してみると当初の期待はすぐに満たされ、さらに発展的な展望があると気がつきました。今のところは Scrapbox と Slack をつなぐ機能しかなく、文字列の完全一致による振り分け条件しか設定できないので、なめらかなシステムと呼ぶにはずいぶんお粗末です。それでも、よりよい未来に向かうためのプロトタイプとしては十分な働きをしてくれました。
自分としては、思わぬ形で新しいおもちゃが見つかったな〜という感覚です。なめらかな通知システムというソフトウェアからのアプローチで、組織を望ましい方向に変化させられるかもしれないのだから、ワクワクしてしまいます。しばらくは「なめらかな通知」というテーマについてあれこれと考え、Takanawa を育てていくか、あるいはまた別のものをつくるかして、遊んでいくつもりです。
で 99 円を送金する