SlackでDMを受け取るとパブリックチャネルに優しく誘導してくれるDM警察というBOTを作って公開しました

この記事はLAPRAS Advent Calendar 2019の9日目の記事です

f:id:rocky_manobi:20191210010511p:plain

概要

  • LAPRASに入る前、業務の内容をDMでたくさん受け取って辛いという課題があった
  • DMを受け取るとパブリックチャネルに優しく誘導してくれるDM警察というBOTを作ったがLAPRASに入ったら需要がなかった
  • なんでや?じゃあLAPRAS関係ないやろ!?
  • まとめ

課題 - 業務の内容をDMでたくさん受け取るのは辛い

このような内容をDMで受け取ると少し困ります。

f:id:rocky_manobi:20191210010546p:plain

パブリックチャネルの発言であれば、僕がこの質問に答えられない場合でも「@知っていそうな人 さん、わかりますか?」とメンションするだけで事が足ります。たまたま会話を見ていて知っている人が能動的に答えてくれる事もあるでしょう。また、後々一連の会話をシェアしたくなったときでも、この会話へのリンクを貼れば経緯を伝えることができます。DMではいずれも叶いません。

本当に秘匿したい情報のやりとりを除いた殆ど全ての場合において、情報はパブリックでやりとりする方が良いはずです。良いはずですが、この手のやりとりをDMで行う人の割合は決して少なくありません。

以前の僕も、そういったDMを受け取るたびに上記の説明をしつつ、なるべくパブリックチャネルにポストしてもらうよう促していました。そして、これはおそらく日本のあちこちで行われている事でしょう。

DMを送る方には悪意がない

一方でDMを送る方としては、単純にパブリックチャネルに発言するメリットを理解していなかったり、使い方を知らなかったり、オープンな場所に投稿することをためらってしまうような空気があったりと、必ずしも悪意があるわけではありません。そこが悩ましいところです。

丁寧に啓蒙していくしかないのですが、やはり続くと辛い。そして言い続けているうちに、段々と「うるさいやつ認定」されていくのもまたつらい。

DM禁止は筋悪(だと思っている

一律禁止はしたくない、というスタンスです。有用なシチュエーションでは普通に使うべきだと思います。

なにより、大事なのはDMをしない事ではなく、パブリックに情報をやりとりすることです。その大切さを伝える方向で解決したいところです。

DM警察を作って公開しました

というわけで、諸問題を解決するBOTを作りました。ざっと特徴は以下の通りです。

  • DMを受け取ると、BOTがパブリックチャネルに誘導してくれる
    • コミュニケーションは職質風。パブリックチャネルに投稿する意義を啓蒙してくれる
    • ゴネれば10分黙ってくれる
  • 簡単に使える
    • Slackワークスペース公式サイト からインストールできる
    • Botにメンションする事で、DMの監視を依頼できる(監視してほしい人だけが使うことができる)
  • 権限が気になる人は、Herokuボタンで独自環境を構築することができる

DMを受け取ると、BOTがパブリックチャネルに誘導

DMを受け取ると、DM警察が現れてDM送信者に職質をかけてくれます。無視をしてもDMを受け取るたびに起動するので、あまりのウザさに流石に無視はされません。

f:id:rocky_manobi:20191210010511p:plain

拒否すると、パブリックチャネルに投稿する意義などを教えてくれます。「我々も仕事でやっているのですみません」という感じで、とてもウザい感じに仕上がっています。

f:id:rocky_manobi:20191210010836p:plain

ゴネ続けると、最後には諦めて許してくれます。10分離脱してくれるので、その間に会話を済ませることもできます。

f:id:rocky_manobi:20191210010417p:plain

Slackワークスペースに公式サイトからインストールできる

こちらが公式サイト です。動画やマニュアル、注意事項などが書いてあります。

「dm警察をslackにインストールする」ボタンを押すとSlack Appがインストールされます。インストール時にAppのWebhookを送るチャネルを聞いてくるので、あらかじめ「#DM警察」などを作っておくと良いでしょう。

また、誤ったワークスペースにインストールしないようにご注意ください。

Botにメンションする事で、DMの監視を依頼できる(監視してほしい人だけが使うことができる)

こんなふうに「パトロールよろしく」とメンションすると、パトロールしてくれます。

f:id:rocky_manobi:20191210010341p:plain

Herokuボタンで独自環境を構築することができる

DM警察のサーバはDMの内容を記録していませんが、DMを読めるという強めの権限を渡すこと自体がネックになるという方もいらっしゃると思い、ソースコードを公開してHerokuボタンも設置しました。コチラを参考に独自の環境を構築する事ができると思います。やってみてね。

あと、リポジトリにスターつけて頂けるとメンテ続ける意欲が強化されるので、気に入った方は是非ぜひ。

github.com

運用TIPS: 口うるさいのは人ではなくDM警察

DM警察がきたからには、もう口うるさく啓蒙する必要はありません。警察を呼んだのです。任せましょう。

たまにBOTを無視して会話する猛者も現れますが、そのときは「BOTがうるさいので、パブリックチャネルいきましょうよ」「DMめちゃ送ってくる人がいて(あなたなのだけど)、その人対策でDM警察いれたんです。すみません警察がうるさくて」などといって、DM警察という共通の敵を作りながら、パブリックチャネルに誘導してしまいましょう。

言いにくいことは機械に言わせる。社会性フィルタを通した言い回しも、一度考えればそれで終わりです。繰り返していいんです。DM警察は機械ですから。

と、このように運用をした結果、以前よりDMを受け取ることが減りました。

なんでや?LAPRAS関係ないやろ!?

そうおっしゃらずに、まずはこちらをご覧ください。

ご覧の通り、弊社LAPRAS株式会社のSlackは発言の殆どがパブリックチャネルにポストされており、全社的に非常にオープンな状態であるといえます。業務をしていてDMを受け取ることは稀で、その内容もパスワードなどの秘匿すべき情報や、休日の遊び関係の会話(子供どうしで遊ばせる会のために集合場所を決めたりetc)などであり、なんら違和感を覚えることはありません。

もうお気づきかと思いますが、このような環境ではDM警察に活躍の場はありません。オープンな組織では、DM警察は生きていけないのです。4ヶ月前にLAPRASに入社した僕はそのことに気づき、そして...DM警察のDynoを「0」に設定しました。当時のDM警察は僕だげが使えるレベルにしか整備がされていなかったため、その日がDM警察の命日となりました。

それから...

DM警察を止めてから数ヶ月が経ったある日、平和なSlack生活を送っていた僕はTwitterであるものを目にしました。それは「Slackで業務連絡がDMで送られてきて辛い」というツイートでした。多くの共感を集めたそのツイートは拡散され、議論の火種となり、一定の周期で僕のTLに「Slack DM辛いネタ」を届けるようになりました。

「僕は解放されたけど、世の中にはまだまだ苦しんでいる人がいるんだ。解決策を持っているのに、自分が救われたからといって電源を落として満足している、こんなことで良いのか?DM警察にも申し訳ないのでは?」TLをみるたびにそんな気持ちになりました。そしてこの「うしろめたさ」こそがDM警察を公開した動機です。

もしLAPRASに入らず、あのままDM警察が稼働していたら、きっと僕はある程度の満足感を持って過ごしていて、DM警察を公開することはなかったでしょう。DM警察を一度はリストラしたという後ろめたい気持ちが、制作の原動力になったのです。その意味で、DM警察を公開するにあたってLAPRASは大いに関係していると言えるでしょう。

まとめ

かくして、色々なところで運用しながら育ててきたDM警察でしたが、LAPRAS入社と同時に晴れてお役御免となりました。これからは僕のためにではなく、世の中の同じ悩みを持つ人のため、組織のために働き、LAPRASのようなオープンな文化の組織が増えていくことに貢献してほしいと願っています(若干自社を褒めすぎたかとも思いましたが、そこはまだ入社4ヶ月で、作り出したものよりも既存の枠組みに乗っている割合の方が多い今だからまだ許されることでしょう。とはいえそろそろ「これは俺がやったったで!ドヤァ」という成果を出したいものですね)。

それでは、快適なSlack Public Channel ライフを!

そして最後に

最後に 「それから...」の下りは全くの嘘です 。DM警察を公開したのは、MushupAwardsもといヒーローズリーグ2019に応募するネタを考えていたら「そういえばDM警察があったやん!あれでいこう!もったいないから公開しよう!」と思ったからです。嘘をついた上にLAPRAS本当に関係なく、誠に申し訳ありませんでした。

つまるところ「オープンな文化はいいですよね。LAPRASのそういうところが僕は好きです」というエントリだったと受け取って頂ければと思います。はい。申し訳ありませんでした。

それでは、快適なSlack Public Channel ライフを!

宣伝

反響いただいたのと、ちょくちょくご利用いただいているっぽいので、少しは役得を...ということで、宣伝を!させてください! LAPRAS株式会社は現在 WebAppエンジニアを絶賛募集中でございます。

DM警察は稼働していませんが、ご興味ありましたらこちらをご覧ください。

t.co

こういったものを作っています

lapras.com

こんな組織を目指しています

www.wantedly.com

LAPRAS株式会社に入社しました

私ごとですが、2019年8月にLAPRAS株式会社に入社しました。

転職エントリ的なものを書くつもりはありませんでしたが、転職以後も以前の立場としてのお仕事のお話を頂いたり、何よりしれっと立場だけが変わっていると「何があった!!!!?」となってしまうよなとも思い、ここでも告知をさせていただきます。事実中心エモ成分少なめで書いていきます。

(あと、一旦バチっと所属を明らかにしないと記事シェアとかしたくてもステマになってしまうという心のブレーキが辛かったというのもあります)

以前の所属/立場との変更点

自分を知っている方としては「入社した?ってことはNextremerは?」というのが当然の流れだと思いますので、まずは変更点から。主要なものは以下の通りで、いずれも2019.04 ~ 2019.09の間の変化です。(注:改めて字面だけを見ると衝撃的な内容ですが、Nextremerとしてのお仕事も引き続き継続しています)

  • 株式会社dataremer代表取締役を辞任しました (株式会社Nextremerの100%子会社)
  • フリーランスエンジニアとしてのお仕事を開始しました
  • 株式会社Nextremerを退職しました
  • 株式会社Nextremerとアドバイザリー契約を締結しました
  • LAPRAS株式会社に入社しました
  • (生活拠点を関東に移しました(埼玉です))

変更理由

事実成分重めと言っても、背景ゼロで辞任や退職をお伝えするのは少々重すぎるので、簡単に記述しますと...

会社全体のフェーズや方向性の変化に伴って、以前とは異なるスキルや性質が求められるようになったという背景があり、対処方法を検討した結果、Nextremer/dataremerの事業や組織運営についてはより今のフェーズにおいて必要な能力のある方に担っていただき、自身は強みを活かせる領域に集中することが、お互いにとってプラスになると判断した、というのが主な経緯です。

この路線をベースに、必要な関わり方や稼働の量、僕自身の嗜好性、制度や運用など諸々を相談した結果、正社員という立場とは異なる形で業務に携わることになりました。

もちろん、厳密にはもっと複雑で細かいお話や、葛藤、お気持ちなどたくさんありますが、文章として公開するつもりはありませんので、興味のある方はご飯でも食べに行きましょう。

現状のお仕事状況

ここからは、前述の変化の結果どうなったのか、いま何をやっているのかについて書いていきます。

LAPRAS株式会社

corp.lapras.com

改めて、2019年8月にLAPRAS株式会社に入社しました。稼働割合としてはもっとも大きなもの(80%以上)となるので、bioなどもこちらを主として更新しています。動機などについてはまたの機会に書きますが、意気込みとしては「喜んでもらえるサービスを作ることに貢献しつつ、みんなで勝ちたい!」という気持ちでいっぱいです。

VPoEという肩書きをつけていますが、2019.11.01時点ではスクラムチームの開発者の一員として、必死でコードを書きつつプロダクトの技術的/ビジネス的/文化的な歴史等諸々を追いかけています。プロセスの改善や組織を強くすることなどなどについては、色々と思案していたものをそろそろ動かしていくぞ、という段階です。成果が出せた暁には何かしら新しいセオリー的なものを生み出せるような予感がしているので、まずはそちらを乞うご期待といった具合です。

WebAppチームのエンジニアの募集もしていますので、興味ある方はぜひ!

株式会社Nextremer/dataremer

立場的には株式会社Nextremerの社員ではなくなりますが、前述の通り引き続きお仕事をさせていただいています。アドバイザリー契約という高尚な響きのする契約ではありますが、実際の業務としては引き合い案件の技術的な要素検討、プロトタイプの実開発、SaaSプロダクトの内部情報提供やドキュメント化など、稼働は減りこそするものの、実務レベルでは業務の形はさほど変わりません。高知AIラボについても、私自身は高知AIラボ代表という立場ではなくなりますが、引き続き運営を継続しています。

現状の体制等については会社Webサイトをご覧ください。

また、個人としても高知でのお仕事はさせていただいており、時々足を運んでいますので、高知関係で僕の貢献できそうな事であればお声かけいただければと思います。

株式会社エナーバンク

twitter.com

電力のリバースオークションサービス「エネオク」を中心に、電力領域で事業を展開しているスタートアップです。開発マネジメントや技術的意思決定、優先順位の決定、組織づくりなどのサポートを目的として、知見提供や壁打ちやハンズオンをしたり、たまに手を動かしてコードを書く...などなどもしています。

事業分野も非常にホットで、絶賛立ち上げフェーズで勢いもあります。興味のある方は連絡いただくか、CEOの@enetech5 の発信をチェックしたりすると良いと思います(直接絡んでもいいかも?)

フリーランス開発者

フリーランスエンジニアとして開発案件やアドバイザ業/コンサルティングなどを請け負っています。現在はNode.js(TypeScript)製のIot関連プロダクトの立ち上げ開発をメインに進めており、アーキテクチャ設計~機能実装を担当しています。

おわりに

業務は完全に途切れていないとはいえ、2015年5月の入社以来ずっと全力でやってきたNextremer/dataremerのお仕事がメインではなくなるというのは、やはり一区切りした感があります。 本当に多くの方に助けて頂いたおかげで、得難い経験をさせていただき、かつ一定の貢献をすることができたと考えています。関わってくださった皆様、本当にありがとうございました。これまでと少し形は変わりますが、恩が返せるよう頑張って参りますので、引き続きよろしくお願いします。

社内制度や規則を整備しなきゃ!というフェーズで考えていたこと - アニメ SYCHO-PASSと制度設計

組織の人数が20~30人あたりになったタイミングで、制度とかルールを整備しようと社内が動きだしていたときに「こういう考えで進められたらいいよね!」と社内に向けて書いたエントリをpublicにしました。エンジニアのリーダーという立場から、制度設計等をメインで進めるチームと、ステークホルダーであるメンバーに向けて書いたものです(改めて見直すと全然社内限定の話ではない)

最近、本業以外で色々なチームのお話を聞いたり壁打ち相手になったりしていることや、最近こういう記事がよく目につくので、自分も考えをアウトプットして置こうと思ったのが主な動機です。 2年前(2017年2月) に書いた記事のため、今よりも幼稚な思考ではあるものの、芯として大事にしたい部分は変わっていません。

これを書いた時期は研究開発受託が事業の主軸であったことと、その時の立場、精神年齢などに起因して、少々偏って要ることを念頭においていただけると助かります。 特に エンジニア => 社員orメンバー と読み替えていただいた方が良いと思います

【本編】社内制度や規則について思ったこと

2017.02.21

社内制度や規則を整備するにあたって、なんとなくこれ大事なんじゃないかな〜と思うことをつらつらと描いていきます。歴史についても少し。

人々はシステムの末端を通して システムを認識し、理解する。システムの信頼性とは、 いかに末端が厳格に機能しているかで判断される (アニメ PSYCO-PASSより)

いきなりアニメからの引用で痛々しい限りですが、核心をついていると思うのでここから始めます。

例えば僕たち一般人は、某携帯会社さんを「携帯端末」「代理店」「契約内容」などの末端のインターフェイスを通して認識し、その質をもって全体を評価します。その評価対象に、創業者の人柄や想いは通常含まれません。某飲食チェーン店なら、「店」「料理」、強いて言えば「店員」のみが認識/評価対象となるでしょう。

社員に対する会社の想いや価値観もこれと同様です。 働いている社員をユーザとするならば、会社の「想い」や「価値観」は何を通してユーザに認識、評価されるでしょうか。それは、トップの人柄でもメッセージでもなく、運用されている「しくみ」「制度」「規則」、もう少しぼかして言えば、「具体的な行動」です。

これまでのお話

Nextremerにジョインする半年前、つまり、高知AIラボが立ち上がる半年ほど前、向井(CEO)さんから「エンジニアが働きやすいためにはなにすればいいの?」と仕切りに聞かれました。ジョインしたあと、そのときに答えたこと+@ がなんらかの形で実行されていて、とても驚いたのを覚えています。

技術書買える。マシンは希望SPECのものを買える。技術的な実験に必要なものは購入できる。経営者がエンジニアを信じ、エンジニアが正しいと思うことをできるように動く。ノリのサイドプロジェクトやエンジニアの意思による開発を推奨する。 ぱっと見クールを重視する。技術的にイケてるを大事にする。利用ツールを先端(エンジニア)に合わせる。などなど、アドホックではあっても「エンジニアが働きやすい場所を作る」という想いにそった「具体的な行動」がそこにあり、「この会社は本当にエンジニアのことを考えている」と感じたのを覚えています。

これからのお話

2015年7月から、ご存知の通り急激に社員が増えて行くことになります。 人数が増えれば当然、創業者、経営陣と社員が触れ合う時間も減っていきます。社員の視点からは、これまで行われていたアドホックなアクションが見えにくくなり、代わりに制度や規則が視界に入るようになっていきます。

この段階に入ると、制度や規則は会社のメッセージの代弁者となり、そのフィルターをとおして社員は会社の想いや価値観を認識し、評価するようになります。だからこそ、制度や規則は、会社や創業者の想いや価値観、文化が正しく反映されている必要があります。

現在、これまでアドホックに行われていたアクションを具体的な制度や規則に落とし込んでいる段階ですが、 「イケてる会社で働いている」(ワードチョイス自体がオッさんかもしれませんが)という感覚を持ち続けられるかどうかは、この作業の質に強く依存します。技術でお客様に価値を提供し続けることができる組織であるために、検討できることは全て検討し、進められたらと思います。

大きくなると

Nextremerは次のステージに向かおうとしています(内部情報過ぎたので表現ぼかしてます)。必然的に外部による監査や助言、指摘、口出しなどを受けるシーンも増えるわけですが、やはり、スタートアップとしていかに効率よく働けるかを意識し、一般的な価値観とぶつかってでも譲れないところは譲らない姿勢を貫きたいと思います。少なくとも、現段階では「攻めすぎ」くらいにはいきたいですね。

「そもそもなんでリスクなのそれが」は常に問い続けたいものです。

制度にはストーリーを

新しい制度、新しい福利厚生を始める時、必ずストーリーや想いをお伝えしたいと思っています。どうして、何を狙ってこれをやるのか。その大義名分を説明することは、発表内容のポジティブ/ネガティブに関わらず常に重要です。このことは完全ガイドに描かれていても良いかもしれません。

  • ネガティブな場合は「協力/理解を得るため」
  • ポジティブな場合は「当たり前ではなく、努力の結果勝ち得た権利だということを共有し、忘れないため」

反対に、以下の二つは望ましくないアプローチといえます。

  • 本当の理由を隠し、破綻した論理であたかも「正しいこと」かのように取り繕う
  • 演出の意図が透けて見える演出をする

Nextremerの社員はとても優秀です。エンジニアとして自信を失うくらい優秀な人がたくさんいます。だからこそ、小手先の言葉では騙されません。正直に情報を開示し、協力を求めるべきところは求める姿勢が大切だと考えています。

自分の環境は自分で作る。空気は読まずに一緒に作る。

制度や規則についての提案や制定は、限られた人の権利ではありません。働く人全員がユーザであり、ステークホルダーです。 思うことはどんどん声をあげ、会社を働きやすい環境にHackしていくのが健全だと思います。

幸いなことに現時点ではそれが許される、むしろ推奨される環境です(続いていくことを望みます)。無関心に流れに身を任せて他にうつるよりも、流れを変えることが比較的容易な社内を変えてみるのも良いのではないでしょうか。

それでもコンサバに倒すこともある

「いつも攻めまくって限界を探してるウチがコンサバな制度をつくったのだから、きっとよっぽどの理由があるに違いない。」

こんな風に思える状態ができると良いと思います。 様々な理由で、攻めの制度を作れない場合はいくらでもあります。そんなとき、普段から信頼を勝ち得ている組織であれば、正確な説明さえすれば納得してもらえる可能性が高いです。  逆に普段から攻める姿勢を持てていなければ「本当にこの可能性は検討したの?」「そもそも大丈夫なの?」という状態になり、進行が難しくなってしまいます。この点、とても大事です。

制度設計の想いを外部に発信したり、LT大会などで発表してみるのも良いでしょう。

こういう話ではない

言葉に意味がないということを言っているわけではありません。 理念やビジョンはとても大事で、言語化できていないのは課題です。ただし、言葉だけでは不十分です。 経営を立て直そうと外部コンサルに頼んで理念とビジョンを、会社全体、各部署にも設置して、、、というテコ入れの現場をなんども見てきましたが、実際の行動の伴わない動きには誰もついてきません。

おわりに

理想論ばかりで現実を見ていないと批判をうけそうですが、最初から理想を諦めるのと、追求した先に落とし所を見つけるのは違います。ただ落としやすいところに落とすのはもったいないと思うので、エンジニア個人としての見解をつらつら書いて見ました。

本編終わり

改めて今読むと..

  • こういうものは「合議」で決めるのが正しいとは限らない、ということに言及すべきだった気がする
  • 「エンジニアが働きやすい」というよりも「メンバーが働きやすい」だ
  • 「働きやすい」というより「パフォーマンス高く...」の文脈の方が労働者発信だとよかったかも
  • 言葉も大事だよ(言葉ばっかりで話が終わりそうな空気があったので言葉だけじゃダメだよって強めに描き過ぎてたのかな)

割と今も同じ様な考えに近いですが、追記したいことも山ほどあるので後日2019年verとしてリライトすることにします! あと、PSYCHO-PASSというアニメはめちゃくちゃに金言が詰め込まれているので10週以上見てもまだ新鮮に見られる素晴らしいアニメですので、dアニメとかで見てみると良いと思います。

【タスク完了した人から抜けてよいSlackチャネル】がとてもよかったので【お礼を言ってくれるBot】を添えて運用してみました

なんとこの記事はNextremerアドベントカレンダー 201816日目 の記事です!本当に申し訳ございません。 qiita.com

要旨

  • Twitterで見かけた「タスク完了したら抜けて良いSlackチャネル」を作る的なHackが凄くよかったので真似してみた
  • とてもよかった。でもそれだけだとアドベントカレンダーを埋めるためのエントリにならない気がした
  • 「チャネルを抜けちゃうからお礼が言いにくい!」という謎課題をでっち上げた
  • それを解決する「チャネルを抜けるとお礼を言ってくれるBot」を作った
  • 一度記事を書いたが限りなく無価値なことに気づいた。焦った。
  • よく考えたら、チャネルを抜けたときの 完了時のインタラクションが改善された気がする と気づいた。

ゆえに、とりあえず課題をでっち上げて何か作って動かしてみると学びがあること、その学びも実はちゃんと考えるモードに脳がなっていないと気づかないんだな、アンテナ大事なんだな、ということに改めて気づきつつ、そんなことなかったかのように「完了時のインタラクションの強化」を目的として導入した程で書いた文章がコチラです。

タスク完了した人から抜けて良いSlackチャネル運用とは

以下の様な素敵なHackです。感化されて運用をしてみました。

june29.jp

試してみて

とても素晴らしい。

  • リマインドするのが楽(@channelぶっぱなし)
  • 誰が残っているのかを確認するのが楽(/who
  • 目的別にチャネルを作るので関係ない会話が始まらない

特に2つ目が素敵です。この手の話は「誰がやってくれていて、誰がやっていないのか」を管理するのがとても面倒くさいのですが、そこが見事に解決されています。以下のスクリーンショットでも、誰がまだタスクを終えていないのかが、自動で管理されていく様子がわかります。飲み会やらイベントやらの調整さんによる日程調整にも使えそうですね。

f:id:rocky_manobi:20181226140906p:plain:w300

完了時のインタラクションを強化するため「お礼を言ってくれるBOT」を投入

すごく便利だ!と思い運用していた一方で、細かいですが改善の余地を見つけました。

この仕組み、実際にタスクを行う側として使うと、チャネルを抜けた後に「本当にこれでよかったのか?」感が残ります。Slackをお使いの方は実際に/leaveコマンドを打ってみると体験できます。チャネルを抜けると何のインタラクションも無しに直前までみていたチャネルが表示されます。

(余談ですが、この感覚は結構不思議です。たとえば「Google SpreadSheetなどに入力してね!」、という運用においても、入力した後に画面を閉じるシーンは当然あり、画面を閉じた瞬間には何のインタラクションもありません。それでもなぜか違和感を感じない。でもこのオペレーションだとなぜか不安になります。この違いはまた今度掘ってみようと思っています)

BOT投入

ということで、チャネルを抜けた人に あなたの直前の行動は運営のお願い通りですという というメッセージを感謝の心と共に伝えるためのBotを作成しました。

使い方は「タスクを完了したら抜けて良いSlackチャネル」にBotを招待するだけ。あとは参加者がタスクを完了させて /leave したらBotから「ありがとうございました!」というメッセージが飛びます。

コードはこちら。Slack AppのCreate BotのPermissionを持ったTokenを環境変数に渡してやればすぐに動くはずです。 github.com

使ってみて

チャネルを抜けた後にDMでお礼がくるので、狙い通り「自分は正しい行動をした」という安心感を強化できたと思います。また、運用初期で慣れておらず、終わってないのに抜けちゃった人へのガイドにもなる という予期せぬ効果も発揮してくれました。

Botのこれから

この手のチャネルを運用するときにBotが備えていて欲しい様な機能があれば追加していこうかなと思います。単なるリマインダは/remindで済んでしまうし、正直あるのかないのかわからんところですが、とりあえずは以下のようなところでしょうか。

使い方やこの手のチャネルの運用TIPSを指南

誰でも運用ができるように、チャネルを作ってBotを招待したら、やり方がわかるような発言をするようにした方が良さそう。

「このチャネルは、チャネル作成者が指定したタスクを終わらせた人から抜けていけるチャネルだよ! /leave で抜けられるよ! まだ残って要る人は /who で一目瞭然だよ! タスク担当でないけど確認のために入ってもらっている人はミュートしておくと良いよ!」

ミュートした人を見つける

脅迫的な機能。できるのかな?

リマインダ改

このボットに「みんなに呼びかけてよ」って言うと、面白おかしくPUSHしてくれる。運営サイドがネタを考えなくていい。

全員が抜ける/アーカイブされたら randomとかにお礼

チャネルメンバーがいなくなったり、アーカイブされたら【#aaaaaaaでのタスクを全員が完了しました。ご協力ありがとうございました!】的なメッセージを`#random'あたりに打つとか(人がやった方がいい気もしてきた)

まとめ

このBOTはともかく「タスク完了した人から抜けて良いSlackチャネル」はとても良いので是非試してみては!

MA2018に参戦したおかげで少し語れる様になった - VUI「けいこさん」の設計思想

MashupAwardsヒーローズ・リーグ Advent Calendar 2018 の16日目の記事です。すみません。

qiita.com

MA2018に参加された皆様、お疲れ様でした!2015年にはじめて2nd Stageを経験して以来虜になり、2016,2017,2018と今回で4回目の参戦となりましたが、今回ついにVUI賞およびHackEverything賞(freeeさん) という大変名誉な賞を頂きました。この記事はその参戦記であると共に、MA参戦で学んだこと、そして、MA良いよ!という思いのアウトプットとなります。

作ったもの

こんな感じの だらしないマネージャを救うVUIアプリ - けいこさん(仮) というものを作りました。漫画を読みながら勤怠承認、Twitterをみながら購買りん議の承認、筋トレしながら休暇申請承認!的なことができます。「一覧」「承認」「却下」の5つのアクションのAPIさえ用意すれば、どんなサービスとも連携が可能だったりします。

www.youtube.com

戦果

以下二つの賞を受賞し、2nd Stageでのプレゼン, FESTA2018でのプレゼンの機会を頂きました。数ある素晴らしい作品の中から選出いただき、感謝の気持ちでいっぱいです。副賞を原資に、サービスローンチに向けて引きつづき開発を進めております。

  • VUIヒーロー賞 : VUIのプロの方々に審査で選出される部門賞的なもの(副賞10万円)
  • Hack Everything賞 : freee さんによる 売上を伸ばす/業務コストを減らすの両面で経営者/業務担当者の生産性をハックする作品に送られる賞(副賞5万円)

作品紹介スライドはこちら(発表時より少しアップデート)

www.slideshare.net

MAに参加している強い人たちからのフィードバックは尊い

さて本題です。

「何かアイディアを思いついたり、何かを作ったら、色々な人に見てフィードバックをもらうと良いよ」とはよく言いますが、MAに参加することはフィードバックをもらうのに非常に適した場所だと思っています。理由は主に以下の通りです。

  • 2nd Stage以降のレベル感を見ればわかる様に、みなさん化け物揃い
  • 多様な評価軸が用意されているため、独自の視点をおもちの変態な方々が多い
  • 名刺は作品、という価値観で行われる懇親会や個人賞など、作品に対して出場者同士で話をすることを推奨する空気と仕掛けがある(そしてアルコールが入った状態で会話する様にデザインされている)
  • 作り手同士の会話になるので、フィードバックが濃くて深い(言語化上手な人が本当に多い)

僕としても、今回は2nd StageやFESTA2018で発表できたことにより、よりたくさんの方々と作品について良い点疑問点悪い点、色々なフィードバックをいただくことができました。特に、GameControllerizerでみんなで選ぶヒーロー賞を2位受賞された 消極性研究会 SIGSHY の栗原先生よりいただいたフィードバックからは、僕自身も気づいていなかった今回の作品の性質や、ひいては僕自身の物を創りたいと思う理由などを言語化するヒントを頂きました。

教えていただいた著書-消極性デザイン宣言 はこちら。必読です。

消極性デザイン宣言-消極的な人よ、声を上げよ。……いや、上げなくてよい。

消極性デザイン宣言-消極的な人よ、声を上げよ。……いや、上げなくてよい。

VUI - けいこさんの設計思想

ということで、制作当初にはなかった考え方を盛り込みつつ、改めてVUI「けいこさん」の設計について、少しだけ触れてみたいとおもいます。本当は別記事でもっと詳しく、丁寧にまとめようと思っていたのですが、そんなことをすると一生アウトプットされないので、勢いでそのままいくこととします。

課題を「やる気」で解決しない

人間は基本的に消極的な生き物であり、やる気というのは人間の心、つまり最もマネジメントし難いものの一つです。「やる気を無理に出させるのではなく、やる気がない状態でも使えるようなシステムとインターフェイスを提供する」というのが消極性デザインの基本的な考え方です。

勤怠承認や購買りん議の承認作業は、それ自体の重要性は分からないでもありませんし、毎日やれれば数分で終わるものです。それでも巷には、僕の様に勤怠承認を月末まで溜め込んでしまう人がたくさんいます。毎日少しづつ捌けば楽になることもわかっているし、業務としてやらないといけないにも関わらずです。これを「やる気の問題」と片付けていては解決しないことは、歴史が証明しています。

「けいこさん」はそんなやる気のない利用者でも、毎日承認作業ができるような仕組みを作ることを目的として設計した結果、VUIをインターフェイスとして選択しました。

ちなみに、ターゲットユーザとしては究極的に消極的な「僕」を想定しています。「たとえ2分のタスクでも、なんやかんやでやり始めるのに2時間かかる」という特徴を持っています。

使おうとしやすさ over 使いやすさ のためのVUI

前述の通り、承認を滞納してしまう最大の原因は毎日コツコツやれないことです。この課題を解決するために必要なのは、アプリの「使いやすさ」よりも「使おうとしやすさ」です。書籍では「アプローチャビリティ」と解説されている概念です。

実際、何かの課題を達成するためのツールとしてみた時、VUIは従来のUIよりも使いやすさの面では劣っています。入力が音声に限定されるため、音声の誤認識や言い回しによる言葉の解釈ミスなど、意図通りに動作させるには使う側にも慣れを必要とするインターフェイスです。

一方で「使おうとしやすさ」について言えば、常に待機状態でいて一声かけるだけで目的を達成できるという点で、VUIが有利となる局面はたくさんあります。実際、スマホのみの時代には天気をチェックしなかった僕も、スマートスピーカを導入してからは出かける前に天気情報を収集するようになりました。「使おうとしやすさ」には人の行動を変える力があります。

他の行動よりも選択されやすくするためのVUI

いかに使い始めやすいインターフェイスを備えていたとしても、ユーザに他の行動よりも優先して選択してもらわなければ、利用されることはありません。

単に承認作業をサクサク完結させるのであれば、例えば Tinder のようなアプリでも良いのです(実は今作っていますが)。アプリを開くと承認タスクが一つずつ表示され、OKなら右に、NGなら左に、保留したいなら下にスワイプしていき、承認等のAPIコールを裏で非同期に行うようにしてしまえばかなりサクサク作業ができそうです。使っている間の体験は間違いなくこちらの方が良いでしょう。しかしそれでも、承認作業のインターフェイスはVUIの方が優秀であると考えます。

上記のアプリを利用するには、前提条件として「スマホを手にしていて、画面を目で確認できる状態であること」が成立している必要があります。この条件自体を成立させることは難しいことではありませんが、一つ致命的な問題があります。それは「 色々なことができすぎる状態であること」です。

スマホを手にしていて、画面を目で確認できる状態であること」というのは、承認アプリを起動することも可能であると同時に、Twitter などのSNSKindleでの読書、ゲームをすることも可能です。ちょっとした隙間時間ができたとして、それらの楽しい行動を抑えて承認アプリを起動することを選択するには、やはり「やる気」に頼らざるを得ません。

ユーザの行動選択には優先順位があり、ユーザはその時々において一番目と判定されたものを行動として選択します。日常的に使われるツールにおいては、この「一番目」になりやすいような設計が重要です。VUIの利用可能条件はスマートフォンの利用可能条件とは重ならず、かつVUIの利用可能条件のみが成立している状態もそれなりに多いため、一番目を取りに行くにはVUIの方が適していると言えます。他のスマホアプリと競い、常時三番、四番にいることよりも、一瞬だけでも一番に確実になれることが重要です。

書籍 : 消極性デザイン宣言 にて「二番目のデザイン」として解説されていることを「けいこさん」に当てはめています

ながら利用で他の行動と同時に一番になれるVUI

先述の一番になりやすいという特徴に関連して、VUI / けいこさん にはもう一つ特徴があります。それは他の行動と同時に一番になれることです。洗濯物を畳みながら、運転をしながら、筋トレをしながら、走りながら、漫画を読みながら、Twitterをしながら、料理をしながらでも利用することができます(本質的に言っていることは前項と同じですが)。

また、この特徴は同時に「ついでの原理(こちらも書籍より)」という、他の行動で駆動したモチベーションに便乗する手法にのっとり、利用を開始することを可能にします。例えば家で筋トレをするなら、その近くにスマートスピーカを置いておくことで、「筋トレをしよう!」というモチベーションで筋トレを開始したのち、その勢いを利用して承認作業を始めることができます。「せっかく筋トレ開始したんだかから勤怠承認もしておくか」という具合です。

このように、何かのついでに利用することができるという点でも、けいこさんはVUIである必要がありました。

共通のインターフェイスで捌ける範囲に機能を限定

アプリでできることを「承認」「却下」「保留」「詳細確認」の4つのアクションに限定することで、勤怠承認、休暇申請承認、購買りん議承認など「何かを確認して承認する」という括りができるものは何でも対応できるように設計しました。これにより「とりあえずコイツに頼めばOK」という体験を提供することができると同時に、先述のVUIの「使いにくさ」をある程度補うことが可能です。

とりあえずコイツに頼めばOKという体験を提供

それが何であれ「あなたが確認して承認しなけれればならないタスク」はこのアプリに聞けば良い、とすることで、ユーザは何も考えずにアプリを使い始めることができるようにしています。これがもし、勤怠承認と購買りん議を異なるアプリで操作する必要がある設計をしてしまうと、ユーザにはどちらのアプリを起動するのか選択を強いることになり、使い始めるコストが増加します。最悪の場合、勤怠承認は0件、購買りん議が2件ある状態で勤怠承認アプリを起動するような事態も発生し得ます。

動作をシンプルにして VUIの使いにくさを軽減

このアプリを起動した後にアクションは、いくつかの隠しコマンドを除けば「承認」「却下」「保留」「詳細確認」および「もう一度聞く」「アプリを終了する」の6つです。シンプルなアクションのみをサポートとすることにより、音声の誤認識や、言い回しによる言語理解のミスの影響を最小限に抑え、意図した通りにアプリを利用できるようにしています。

また、VUIのもう一つの使いにくさの要因である「ソフトウェアの状態をユーザが記憶する必要がある」という点を軽減するため、アプリ内部でどの種類の承認を処理するのかを尋ねる機能も削っています。とにかく何も考えず、読み上げられたことがAcceptableなのかどうかだけを判断し、承認、却下、保留の操作を粛々と繰り返せるようにしました。

理想は紙ベースの承認作業+秘書さん

実は「けいこさん」の目指すところは、紙ベースの承認作業と秘書さんのハイブリッドです。 保育園に持っていくオムツ一つ一つにおなまえスタンプを押すという家庭内業務をしていて気づいたのですが、紙ベースの承認フローというのは、承認印を押す人にとってはなかなかに優秀なインターフェイスであると言え........このあたりはまた書きます。

その他の学び - 作品でそもそも論を引き摺り出したい(かも)

このアプリを見て「そもそもそんな承認作業要る?」と突っ込みたくなったアナタ。ありがとうございます。

懇親会などで話していて、自分はもしかして「馬鹿馬鹿しいルールを守るためにあえて真面目にシステム化して、そもそもそれ必要?という話が出てくるのを狙って開発しているのか?」ということを考えるようになりました。人間のやっている作業を、ITを使ってこれまでとは異なる形、あるいは完全自動に変換することで、それまで見えていた「人間が作業することによる仕事してる感」が削ぎ落とされ、そもそもやろうとしていることが正しいのかどうかに焦点が当たりやすくなるのでは、という仮説です。

作品自体は真面目に課題を解決することを目的として制作しつつも、実は既存のルールに対する風刺になっている。思えばこれまで作ったり、アイディアとして浮かんだものはそんな発想を元に生まれてきたものが多い気がします(公私ともに)。もう少し掘り下げる必要はありますが、今回のMA参戦で自分の創作活動のジャンルのようなもののヒントを得た気がしています。

おまけ : マントの功罪

余談ですが、今回、FESTA2018のヒーロー任命式(授賞式てきなもの)にて、真っ赤でテカテカな生地に「I AM A HERO」とプリントされたマントが配られ、帰るまでそれを着用し続けるという罰ゲーム的な仕掛けがあったのですが、こちらについて。

https://protopedia.net/prototype/84c6494d30851c63a55cdb8cb047fadd

https://ma2018.we-are-ma.jp/wp-content/uploads/2018/12/hero_06VUI.jpg

正直いって非常に恥ずかしく、運営の方々に見つかり怒られるまでは一度外していたのですが、なんだかんだでこれ、あって非常に良かったです。

色々考えてしまいネットワーキングが苦手な僕 でも、懇親会の時に「どんな作品で受賞したんですか?」と声をかけていただき、たくさんの方とお話できたのはおそらくこのマントのおかげでしょう。あのマントは「こいつ、自分から誰かに話しかける勇気はないけれど、作品出して、それなりに面白いものを作ったやつだから、話しかけてやりなよ」という運営からのメッセージだった、というおそらく設計されていないであろう、ある意味のSHYHACK効果を実感したことをここに記しておきます。

MA2019に向けて

(開催されることを信じつつも)来年は身近な課題を、みんなが使える形で、できればソフトウェア領域のみで解決する、的なものを作って出したいと思っています。 完全に今年の優勝作品である「Facelot」の影響です。

FESTAの懇親会でお話させていただいたのですが、ものすごくよく考えられていて、最近の若者は優秀すぎる説を強烈に感じた次第です。特に、課題認識における視点がとても鋭く、常に何かないかと考えていらっしゃる様でした。僕もこのような「すごい!けどくやしい!なんで気がつかなかったんだ!」的なものを作れたら良いなと思っています。

まとめ

今回、精神的/金銭的/労働時間的にもかなりリソースをつぎ込んで作ったので、報われたといいますか、とにかく楽しかったです!ありがとうございました!

f:id:rocky_manobi:20181202183054j:plain