【タスク完了した人から抜けてよい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

Chrome - SpeechRecognition API :「聞きっぱなし」実装のためのイベント周りの挙動まとめ

Nextremer Advent Calendar 2018 - Qiitaの8日目の記事です。 qiita.com

仕事柄 音声認識関係のDemoアプリを作ることが多く、自然とWebSpeechAPIに対する知見が溜まります。というわけで、今回は社内外で「たまに動かなくなるケースがある」という声を多く聞く「聞きっぱなし」を実装するにあたって必要なイベント発火周りの挙動についてお送りいたします。公式Docsにもあんまり書いていないことを、と思ったらこんな角度になってしまいました。よろしくお願いいたします。

注意 : Badノウハウてきな対処を含みます。

要旨

  • 画面を開いている間、ユーザの音声入力を受付し続ける機能、いわゆる「聞きっぱなし」を実装したい
  • WebSpeechAPIは一定時間無音状態が続くと終了してしまうため、適切にイベントをハンドリングして、リスタートしてやる必要がある
  • イベントの挙動が直感に反するのでその挙動とリスタート処理実装のポイントについてまとめる

ChromeのSpeech Recognition のイベント挙動

それぞれのシチュエーションにおけるイベント発火有無は下記のとおりです(僕調べ)。「騒音」のケースで onerror が発火しないのはどう考えても直感に反し、注意が必要であることがわかります。

  • 正常 : 音声が入力され、音声認識が成功した場合
  • 無音 : 一定期間、音声が入力されなかった場合
  • 騒音 : 音声は入力されたが、言語として認識されなかった場合(キーボードのタイプ音等々)

f:id:rocky_manobi:20181210033620p:plain
Chrome WebSpeechRecognitionのイベント周りの挙動

「聞きっぱなし」実装のポイント

先述の挙動を踏まえると「聞きっぱなし」を実装する上でのポイントは以下の2点といえます。

無音ケースへの対処

無音ケースに対処するため、onerrorイベントを利用します。onerrorイベントの引数にはエラー原因が文字列で渡されるので、それを評価して音声認識をリスタートするのが良いでしょう。

const recognizer = new webkitSpeechRecognizer();
recognizer.onerror = (e) => {
  if (e.error === 'no-speech') {
    // 無音状態で一定時間が経過した、ということなので再度音声認識をスタート
    recognizer.start();
  }
};

騒音ケースへの対処

残念ながら僕の調べた限りでは、騒音ケースに対処するためにはBadノウハウ的な対処が必要であり、完全な動作を保証することもできません。しかしそれでも「たまーに動かない」の「たまーに」の発生率を大幅に下げることは可能です。

騒音ケースに対処するためonspeechendイベントを利用します。 onaudioendonsoundendも発火しますが、無音、騒音ケースにおいて onerrorと排他的に発火するonspeechendをハンドリングする方が(比較的)シンプルで良いでしょう。

下準備

下準備として、SpeechRecognizerをWrapしたクラスを用意し、音声認識の成否の状態を保持するフラグを持たせます。(なお、recognizer.start()をWrapしたメソッドは Promise 形式にしています。)

// SpeechRecognizerをWrapしたクラス
// 音声認識が成功している/していない の状態を管理する変数を用意
//  -> onresult(成功)で フラグを立てる / onstart(開始)でフラグをおる
class AutoRetrySpeechRecognizer{
  constructor(){
    this.recognizer = new webkitSpeechRecognizer();
    this.recognized = false;
    this.recognizer.onstart = ()=>{
      this.recognized = false;
    };

  }

  start(){
    return new Promise((resolve, reject)=>{
      this.recognizer.onresult = (e)=>{
        this.recognized = true;
        resolve(/*結果*/);
      };
      this.recognizer.start();
    });
  }
}


// 実行してみる
const recognizer = new AutoRetrySpeechRecognizer();
recognizer.start().then((result)=>{
  console.log(result);
});

onstartonresultのイベントハンドリング処理を記述するところがバラバラなのが気になりますが、一旦おいておきましょう(というか、codeはイメージです)

onspeechendのハンドリング

onspeechendイベントをトリガーとした音声認識のリスタート処理を実装します。先ほど用意した音声認識成否のフラグを参照し、成功していない場合はリスタートします。また、setTimeoutを用いて一定時間(下記例では500msec) 待つことで、onresultよりも前にrestartがなされてしまうことを防ぎます。

  constructor(){
    this.recognizer.onspeechend = ()=>{
      setTimeout(()=>{
        if( this.recognized ){ return; }
        this.recognizer.start();
      },500);
    };
  }

おまけ : Already Started を無視する

すでに音声認識が走っている状態でrecognizer.start()を実行するとエラーが発生します。ほとんどの場合、start()を実行するからには音声認識が起動している状態を期待するはずなので、エラー内容が already started である場合は無視して問題ないと考えます。

try{
  this.recognizer.start();
}catch(e){
  /* already started の場合は無視 */
}

補足

recognizedなんてフラグを利用するならば、騒音でも無音でも発火するonaudioendに対してonsoundendでやったような処理を実装して、onerrorを見ずにすれば一箇所にかけるのに... という考え方もあると思いますが、今回実装したのはあくまでsetTimeoutを用いた実行時間に依存する綱渡りな処理であるため、やはり、公式に提供されて要るエラーケースでハンドリングできる「無音」のケースにおいては、公式のエラーをハンドリングする方が得策であると考えました。

おわりに

聞きっぱなし 実装する人(などという人が居るのだろうか。MA向けに何か作るとか、そういうネタアプリ作るときなんかにこの手の処理実装の需要はあるかもしれないなとは思っているのだけど、改めて考えるとやっぱり「聞きっぱなし」って現実的に周りの人の会話とかも拾ってワークしにくいからボタン式とかそういうのにしておいた方がよいのだよね...でも、例えば擬似的にVoiceTrigger的なものを実装したいとか、そういうときには必要になるんじゃないかな!)の参考になればと。

コミュ障でもコミュニティで新しく友達を作れる ~ コニュニケーションが苦手な人ほど登壇しよう

登壇すれば、自己紹介が完了した状態を作れる。ただし、そこには「貢献」の心が伴うこと

Comunity Leaders Summit in 高知 Returns というイベントでLTした内容です。スライドが超絶言葉補足前提のものだったので記事で補うものです。「コミュニティ活動を通して得たビジネスやキャリアに関係する良い影響」がお題だったのですが、僕としてはその「良い影響」を得る過程で得たある気づきがとても大きかったと思い、そんなお話をしました。コミュニケーション能力強者が多いコミュニティリーダーの方々、僕のような奴を見かけた時にアドバイスしてやっていただければ幸いです。

eventregist.com

www.slideshare.net

コミュニティイベントで登壇すればコミュ障でも新しく友達を作れる

コミュニティ活動に参加することの大きなメリットに「人との繋がり」があります。コミュニティで知り合った人から仕事の依頼をもらえた、知り合った人の会社に転職した、社内では相談しづらい悩みを相談できた、などなど、人と繋がると良いことがたくさんあります(コミュニティ活動で得られる良い事についてはイベントで色々な方々が語られておりますしたので割愛)。

しかしながら、その「人と繋がること」自体が僕らコミュ障にとっては難しい。 同じような興味関心を持つ人たちのあつまるコミュニティの中とはいえ、新たな関係を自分から構築すると言うのはとてもハードルの高い事なのです。

ということでこの記事では、僕のようにコミュニケーション能力に自身がない人でも実践できる「コミュニティにおける勉強会やイベントで新しく友達を作る方法」についてお伝えしたいと思います。

  • 勉強会でのネットワーキングが苦手な人こそ登壇しよう。登壇すると、会場全体に自己紹介が完了した状態が作れるから、話しかけてもらえる確率があがるよ
  • 登壇の敷居が高い!と言う人はコミュ力以外で役に立てることを見つけてやってみよう(些細なことでも良いから続けてみよう)。きっと誰かがみていてくれるよ
  • 「貢献する」って思いがなければ何をやってもダメ!絶対にダメ

勉強会でのネットワーキングが苦手な人こそ登壇しよう

僕はいわゆるネットワーキングタイムというのが苦手です。初対面におけるコミュニケーションで色々考えてしまい、なかなか滑り出しで良い会話をする事ができません。 昔の自分も、師匠の教えに忠実に外と繋がるべく、勉強会、懇親会に積極参加したものの、一向に成果は得られませんでした(技術的知識の蓄積にはなったのだけど、ここでいう成果とは、色々相談できるような人とか一緒に頑張ろうぜできる人との出会い)

ネットワーキングが苦手な理由

僕と同じような感じの人いるんじゃないかと期待して書いておきます。 そして、こんな人にこそ 登壇 という手段がおすすめです。

自分から話しかけるのが苦手

話しかける人のことがわからないので、自分との会話や繋がりで価値を感じてもらえるかどうかが不安、そこからくる話しかけたけど微妙な反応をされることへの恐怖故に話しかけられない。話しかけるタイミングを伺うのも苦手、既に誰かと話をしているところに割り込んでいくのは上記の理由より問題外です。

心の中(この方どう言う方なのかな。仮に自分が話しかけたとして、この人に何か有意義な時間を提供できるのだろうか。対話システムとかITとか興味あるのかな。またはめっちゃ知ってて僕なんかと話しても新しい情報一つも増えないような感じにならないかな。というかなんか疲れてしゃべりたくない気分だったりするんじゃないかな...あ、誰かと話し始めた。他に空いてる人いないかな〜。あ、とりあえずピザ美味しそうだからピザ食べておこう)

こんなことを考えて、お腹だけ膨らませて帰るのが日常でした。

自己紹介が苦手

シンプルに「僕は〜〜で〜〜をやっています」というのに大きな心理障壁があります。

具体的には例えば「興梠です。NextremerっていうAI Techベンチャーで働いています」って言うと同時に心の中(AIって言っちゃったけどこの方はどういう属性なんだろう。AIの定義とか気にする人なのかな。だとするとあとでウチが対話UIメインでやってるって知ったら「対話UI=AI」みたいに考えていると思われちゃうかもしれない。ちょっといやかも。事業としては対話UIが中心であるものの、深層学習/強化学習周りもやっているよと伝えるべきだろうか、対話にしてもDNN使った対話とかも取り組みの研究をしていることを共有すべきだろうか。あ〜いや、だけどそこまで反応ない人だと困るよな。そうだ、僕が前にSIerで働いていたり、IoTとか色々手を出しまくってた話もした方が良いのかな。というか、エンジニアですって言うとどう思うのかな。ちょっとエンジニアリングだけではなくて営業的な部分とか会社経営サイドちっくなお仕事もやっているって言った方が興味持っていただけるのかな、、あ、名刺に高知って書いてある。東京と高知両方あるって言った方が良いのかな。なんで高知でこういうことを〜とか語った方が良いのかな、、、あ〜〜とりあえずどうしようどうしようどうしよう) みたいなことを考えてしまってスムーズにわかりやすく自分を伝えられない事が多いです。

せっかく会話が始まったのに、いまいち盛り上がらずにピザを食べて帰るのが日常でした。

登壇すると「自己紹介が完了した状態」になるので、話しかけてもらいやすい

話しかけるのが苦手なら、話しかけてもらう

勉強会で登壇すると、発表中での自己紹介の内容、趣味嗜好、今取り組んでいること、考え方、レベル感、などなど、多くの情報を参加者に届けることができます。相手が自分のことをある程度知ってくれている状態、もっというと 何が共通の話題になるのかを知ってくれた状態を作れます。

共通の話題が見いだせる相手には話しかけやすいものです。思い返してください。他の参加者の方には話しかけずらかったかもしれませんが、登壇者にはなぜか話しかけやすかったはずです(空いてれば)。

発表での自己紹介は、一対一の自己紹介よりも難易度が下がる

登壇は自己紹介の難易度自体を下げる効果もあります。1on1状態の自己紹介とは違い、長く喋っても大丈夫です。そして何より、スライドを使うことができます。

登壇するなら場に貢献できる事を話そう【重要】

発表するならば、まずは長時間の発表ではなく、尺の短いLT(ライトニングトーク)等が良いでしょう。勉強会によってはLT枠を募集しているものもあるので、そこにエントリーすることでチャンスを得ることができます。

ただし、LTといえども舞台を私物化して好き勝手な話をしても状態は好転しないので要注意です。 ギブから始まるのが世の常です。何を喋ったらみんなの役に立てるかを考えましょう。

僕の人生初のLT登壇は、人生の中で最も思い出したくない瞬間の一つです。発表中は頭が真っ白になり、発表後はすぐにでも出て行きたい気分を必死でこらえ、懇親会的なものにも出ずに帰ったことを覚えています。

敗因はもうわかっていて「全然凄くもないのに背伸びをしてすごい人っぽいことをしようとして無価値な発表をしていた」というものです。

大抵のコミュニティは寛大です。すごい人たちも強い力を持つがゆえに寛大です。。。寛大な傾向があると思います。しかし、それはコミュニティに貢献しようとする姿勢があることが大前提です。場を私物化して好きなことをいって、それが有益でもないような奴に誰も興味は持ちません。

具体的には?

では具体的にどんな内容を喋るのが良いでしょうか。ここでは技術系イベントのLTを想定します。

客観的に誇れる成果や知識がある場合は素直にそれをシェアすれば良いでしょう。しかし、なかなか見つかるものでもありません。そんなときは「自分の体験」を語るのがポイントです。もちろん、無理に深夜アニメのスライドを挟んでボケる必要はありません(できることをやりましょう)。

  • コミュニティでフォローしている技術を現場に適用した!
    • 多様な現場に当該技術がFitする/しない という知見や、新たな適用方法、組み合わせのアイディア、その課題などを提供
    • より良くするためのHowを考えるきっかけを提供
    • 普及活動に前向きに取り組む仲間がいるという勇気を提供
  • コミュニティでフォローしている技術の習得に挑戦した!
    • 多様なレベル感の人のハマるポイントなど、学習における感じ方を提供(会社での教育に使えるかもしれない)
  • 他の人の以前の発表を実践した!
    • 発表者への勇気づけ
    • シェアした知識が色々な人によって磨かれていくというそれはもう美しい...

ネガティブな内容でも全然ありですが、大事なのは身の丈にあった発表をすること。決してマスターではないのにマスターな振りはしない。挑戦のハードルは背伸びしても届かない程度の物が良いかもしれませんが、発表の姿勢は謙虚であることに越した事はありません。

ドヤりたいなら発表の前に相応の血反吐を履きましょう。

登壇するのはハードルが高い!というひとは、とにかくその場で役に立つと思ったことをやってみよう

登壇が効果的であるとはいえ、それは崖から飛び降りるような行為でもあって、中には踏み切れない人もいるでしょう。僕自身は「やってやるぜ!」と息巻いて飛び出すことはできたものの、その後の人生初のLTで大失敗した心の傷はなかなか癒えず、なかなか2ndチャレンジをする事ができませんでした。初対面におけるコミュニケーション能力をあげる以外はいつかは超えなければならない壁ではあるものの、やはり、いきなり超えるのは厳しいものです。

というわけで、そこに到るまでのステップ、ないし代替案としてのオススメの行動が 場に貢献する事 です。どんな些細な事でもいいから、以下のような役に立つ行動をしてみましょう。地味ですが、どれも喜んでもらえると思います。

  • 前の方の席に座るようにする
  • 会場の現状復帰を手伝ってみる(椅子並べ直し / ゴミ捨て)
  • 登壇者の言葉に積極的に反応して(うなづく等)登壇者を孤独にしないよう助ける
  • イベントハッシュタグ付きで実況する / 登壇してくれた人を褒める

これの何が良いかと言うと「話しかけられるきっかけになること」です。 「ありがとうございます〜」「いえいえ〜」というやりとりから「普段何やられている方なんですか?」って話しかけられるパターンが期待できます。なんせコミュニティ活動です。コミュ力の高い人は必ずいます。頼りましょう。まず役に立って自らが敵でないことを証明しましょう。すぐに友達とはいかないかもしれませんが、この積み重ねが信頼を産むのです。コミュ力がない分は行動でカバーです。椅子を運ぶのにコミュ力は要りません。

続けていけば「You次しゃべっちゃいなよ」みたいに機会を与えてくれたり、発表内容についてのアドバイスをくれるかもしれません。コミュニティのコントリビュータのサポートがあるのです。これなら恐怖の壁も超えられます。

まとめ

  • コミュ障だけどコミュニティで新しく友達を作りたいと思ったら「コミュニティに貢献」しよう
    • それは登壇でも些細なお手伝いでも良いはず
      • 登壇の場合は自分勝手な発表内容でないか注意しよう
        • 学習者は潔く学習者としての立場で!
    • そこにいるだけで価値のあるスーパーマンとかは、確かに話しかけられるけど、そんな事は他者が決める事であって背伸びしてすごい人っぽいオーラとか出すとシラけるよ!(自身があるなら良いけど)

終わりに

発表の内容まとめるつもりだったのにリライトみたいになってしまいました。 今回はLTで話した情報量を全部補う(+α)スタンスで書いてみましたが、かなりの文字数いくんですね。

それでは

追記 : コミュ障という言葉についてうんぬん考えたが一旦これで発表してしまっているのでこのまま公開する。議論が生まれればする。

Active Book Dialogue をやるときは「場の心理的安全性の確保」が重要だと思った話 - ABD x エンジニアリング組織論への招待 をやってみて

f:id:rocky_manobi:20180729001257p:plain

Nextremerが主催する勉強会「Nextremer Tech Meetup@高知」の第二弾として、「Active Book Dialogueで"エンジニアリング組織論への招待"を読む」というやつをやりました。その際に「あ〜このイベントは場の心理的安全性の確保が大事っぽい」と思ったのでその話を書きます。

nextremer.connpass.com

イベントの様子はこちら!(本当にありがとうございます)

ABD - Active Book Dialogue とは

ABDはざっくり以下のような流れで進行するアクティビティです。

  • みんなで集まる
  • 一冊の本を切り刻む
  • みんなで分担して読み、要約する
  • 成果物を張り出し、順番に発表する
  • みんなが興味を持った所について対話する(ダイアローグ!!)

ねらい/効果等は以下、公式サイトより開発者様の言葉を引用します。

アクティブ・ブック・ダイアローグ®は、読書が苦手な人も、本が大好きな人も、短時間で読みたい本を読むことができる全く新しい読書手法です。 1冊の本を分担して読んでまとめる、発表・共有化する、気づきを深める対話をするというプロセスを通して、著者の伝えようとすることを深く理解でき、能動的な気づきや学びが得られます。 またグループでの読書と対話によって、一人一人の能動的な読書体験を掛け合わせることで学びはさらに深まり、新たな関係性が育まれてくる可能性も広がります。アクティブ・ブック・ダイアローグ®という、一人一人が内発的動機に基づいた読書を通して、より良いステップを踏んでいくことを切に願っております。

同サイトにてマニュアルも配布されていますので、やってみたいと思われる方はぜひ。

また、タイトルにもありますが、今回はエンジニアリング組織論への招待 という本でABDしました。

場の心理的安全性の確保が大事

奇しくも対象とした本にも書かれているワードですが、このアクティビティを運営するにあたっては、場の心理的安全性を担保することが何より大事だと感じました。

本の一部分のみから得た情報を要約するわけです。「完璧なものを出さなきゃ」「変なまとめしたらバカにされる」などという心理が働いていては手が動きません(きっと)。対話においても「いいこと言わなきゃ」「コレを言ったらバカにされるのか」なんて思っていたら発言なんてできません(きっと)。

前提条件や目的を丁寧に共有する(した方がよさそう)

参加者同士は学びを得るための仲間であり、競争相手ではないこと。対象の本を読んだことがある人も入れば読んだことの無い人もいること。対象の本を専門としている人もいればそうで無い人もいること。同一の事象/事実でも、重要だと感じる部分は人によって違うこと。要約や発表に慣れている人もいれば慣れていない人もいること。何より 目的は対話を通じて得られる能動的な気づきや学びであり、完璧な要約を分担して作ることでは無い ということを丁寧にインプットすることが、より質の高い場づくりに寄与するのだと感じました。

もっと言うと、これは僕の所感ですが、多様なバックグラウンド、多様な受け取り方の人がいた方が、むしろその場の学びの総量は大きくなるのでは無いかと思いました(コレはあとで)

現場ではどうしたのか...

なにぶん作業している途中で気づいたので、超アドホックな対策であることを先に言い訳しておきます。

一応僕なりの工夫としては「これ難しいです」「要約ってこんなに難しいんですね」「これ、完璧なのは無理ですよね..全体読んでいる訳では無いし(僕は読んでるけど)」「完璧じゃなくてもいい!ていう場の心理的安全性が大事ですよねコレ...」「時間足りないかもしれないです」のような発言を時折することで「そもそも難しいことをやっていること」「失敗が許容される場であること」を発信してみたりしました。効いたかどうかは分かりませんが、最後まで参加者全員で要約/発表./対話と、勧められたので良かったと思っています。

その他感想/気づき/学び

チームビルディングに使えそう

松浦春選さん によるレポートでも触れられている通り、これはチームビルディングに効果がありそうです。 お互いについて知り、価値観を共有するのに有用なツールだと感じました。週一でチームで時間をとって、取り入れようとしている考え方、導入を検討しているプラクティスなどの書籍を対象に実施して見ると良いかもしれません。

ある事柄について、担当個人がまとめたものをベースにディスカッションするのも良いですが、ABDのように一冊の本を分担し、そのなかで皆の関心の高い事柄について対話をすることで、皆で作り上げた解釈/価値観を共有することができるような気がしています。

多様なバックグラウンドのある人でやると面白そう

今回は参加者全員が「IT系」という属性を共有しつつ、「学生」「社会人」という属性に大きく別れていました。対話における発言の色にも「学生 vs 社会人」の差が出ていて、やはり同じものを見ても背景によって捉え方は違うのだと改めて認識しました。加えて、自分が発言するときにも「この例え方だと SE経験者にしか伝わらないからどう伝えようか」というトレーニングにもなったかと思います。受け手に合わせた情報発信の心ですね。

というわけで、デザイナーさんの仕事の仕方について書かれた本をビジネス屋さんとエンジニアとデザイナーさんで読んでみるとか、アジャイル開発系のプラクティスをユーザ企業さんとエンジニアで読んでみるとか、特定の業務知識の本を同じくユーザ企業さんとエンジニアチームで読んでみるとか。やってみると面白そうですね。

あ〜、それぞれの立場について主張したい本を一冊出して、それについてABDをやる、、ってすると本当に相互理解できそう。なるほどチームビルディングに使えそう(前項につながる)。

f:id:rocky_manobi:20180727141107p:plain
皆さん認知の歪みに興味があった模様

(というか学生さんでエンジニアリング組織論への招待を読んで何らかの感想がもてるなんてすごいな〜最近の学生さん本当に頭いいな〜)

個人のトレーニングとしてもやはり良い

本を読んで、要点を抽出して、視覚的に表現して、発表して、対話する、、とまぁ普段なかなかやらないというか、数が稼ぎにくい作業だと思いますので、単純にその手のことに取り組めるのは良いです。特に「発表」のトレーニングとして、とても有効なのではと感じました。

発表が上手くなるには「発表することと、その時のフィードバックを得ること」の積み重ねが大事だと思っています。上達のためになるべく数をこなしたい一方で、毎回「発表すべきネタの採掘」という作業が発生し、これが中々時間をくいます。そう言う意味で、ABDに参加すると嫌が応にも発表するネタが降ってくるので、それは良いなと。また、必然的に似たようなトピックに対して皆が発表するので、「上手な人の発表を参考にする」という作業がやり易いというのも良いです。

あとは、普通に読むよりも「深く読める」という効能も確実にあります。僕は以前に「エンジニアリング組織論への招待」を読んだことがありましたが、作業中には「こんなこと書いてあったっけ?」と思うことがなんども。やはり「要約して伝える」を前提にして読むときとは、読む深さが違うのだなと改めて感じました。

ABD x エンジニアリング組織論への招待 をやったきっかけ

A. エンジニアリング組織論への招待めっちゃいい本だよ!みんな読んだ方が良いよ! と言っていたら「じゃあ Active Book Dialogueやろうよ」と言われたから

ぼくは「エンジニアリング組織論への招待」とう本が大好きです。

これはもう良書中の良書というか、凄い本です。どれくらいすごいかというと、読みながら「そうそうそうそう!!!」と叫ばずにはいられないくらいです。チームや組織で仕事をしている人皆が感じ、直面しているであろう課題感(もちろん解決策も)を見事に言語化していて、普段感じていたモヤモヤが一気に晴れるというか、そんな気分にさせられます。

絶対みんな読んだ方がよい。チームを作る人も、チームに所属する人も、人類みんな読んだ方が良い。そうすればみんな少しだけでも優しくなれるというか、ちょっと幸せになるというか、不幸が減る。

まぁ、めちゃくちゃ雑ですがとにかくそんな本です。

と、そんなことをNextremer主催の勉強会@高知 の場で話していたら、その場にも参加頂いていた松浦さんに「Active Book Dialogueやりましょうよ」とお声かけ頂き、開催することになった次第です。

追記: あまりにも雑すぎるので書評へのリンクを... (おんなじ感想感覚だと思っています)

blog.shibayu36.org

note.mu

shufo.github.io

最後に

企画/準備/ファシリテーションと、イベントのほぼ全てを取りまとめて頂いた松浦さん、ABD経験者としてアドバイス頂いた杉尾さん、参加頂いた参加者のみなさま、僕の「やりたいっす!」に協力頂いたNextremerスタッフのみなさんにこの場を借りてお礼を申し上げます。ありがとうございました!

最後の最後に

Nextremerではエンジニアを募集しています:) ぜひ!!

www.wantedly.com