トップ > チャット > 口頭ではなくチャットでコミュニケーションするためのヒント集

口頭ではなくチャットでコミュニケーションするためのヒント集

チャット ポエム

「口頭を使うべきかチャットを使うべきか」はケースバイケースあるいは宗教論争。

私の職場では口頭ベースが多い。が、もうちょっとチャットに頼ってもいいんじゃないかと思っている。ひとまず整理も兼ねて、根拠やらアイデアやらテクニックやら（あとポエムも少し）を雑多に記してみたい。

口頭のデメリット

デメリット1. 集中阻害

話しかけられた時点で集中が阻害される。

口頭で話しかけられたら、基本的に必ずその場ですぐに応答を返さなければならない。たとえ作業中であっても。無視するという選択肢は無い（人として最低の行為）。

（一般論はさておき少なくともエンジニアの）仕事は集中して取り組むべきもの。いつ口頭で割り込まれるかわからない中で仕事をするのは辛すぎる。口頭による集中阻害を乱暴にたとえるなら、将棋の棋士さんが対局で思考してる時に「ねぇねぇ、ちょっと」と声を掛けられるようなもの。

  • Q: チャットを使うとどうなる？

話しかけられた時でも即座に応答せずに済む。集中している場合はいったん放置するか、とりあえずタスクリストに突っ込んでおけばいい。言い方を変えるなら、メールのように自分のタイミングで処理できるとも言える。

デメリット2. 記録されない

記憶違いや怠慢が起きやすい。

口頭でコミュニケーションした経過や結論は記録されないので、たとえば

  • 例1: 言った/言ってない論争
  • 例2: そんなの聞いてないよ
  • 例3: そんなこと言った覚えはないぞ

以上のようなことが起こる。

  • Q: チャットを使うとどうなる？

会話の経過が記録されるので記憶違いが起きない。書いていることが正義。また、記録という形で証拠が残っているので誤魔化しも効かない。

デメリット3. 共有できない

情報の属人化 が進む。

口頭で話された経過や結論は、会話したメンバーにのみ伝わる。逆を言うと、その場にいなかったメンバーには伝わらない。

  • Q: チャットを使うとどうなる？

（皆が見ているチャンネルで発言すれば）経過や結論を皆にもインプットできる。

1vs1 と 1vsN

チャットによるコミュニケーションは「相手の数」という観点で二種類に分類できる。

  • 1vs1: いわゆるDM(ダイレクトメッセージ)
  • 1vsN: いわゆるチャンネルでの発言

適宜使い分けると良い。

宗教論争だろうが、いくつか例を挙げる。

  • 上司にプライベートな事情について共有する → 1vs1
    • 理由: なるべく人に知られたくないことだから
  • 上司に承認依頼を出す → 1vs1
    • 理由1: 承認依頼は上司のみが絡むタスクなので上司にだけ知らせればいいから
    • 理由2: 逆に 1vsN だと無関係なメンバーに無関係なメッセージを読ませちゃうことになるから
    • ただし「私はあなたに承認依頼出したよ」という状況を皆に伝えたい場合は、あえて 1vsN + Mention を使うこともある
  • 技術的にわからないことを質問する → 1vsN
    • 理由1: メンバーの誰かに答えてもらえればいいから
    • 理由2: 他のメンバーにとっても参考になるかもしれないから

コミュニケーションの種類

四種類あると思う。

  • 報告: 相手に伝えたらおしまい
  • 依頼: 相手にお願いしたらおしまい
  • 質問: 相手から答えが返ってきたらおしまい
  • 相談: 相手と複数回やり取りするもの

細かい使い分けは後述するが、一点だけここで取り上げておく。相談についてはチャットで行わない方が良い。やり取りが発生すると 相手の意見がタイプされるまで待つ時間が生じる。これがバカにならない。口頭なら 1 分で済むことが、数倍は平気でかかる。じゃあどうすればいいかというと、 相談の依頼 だけ行い、相談は口頭など別手段でやる。

チャットの推進に必要なもの

これらを備えていないとチャットは浸透しづらいよ、というもの。

使いやすいチャットシステム

一言で言うなら Slack。

Slack はバージョン管理でいう GitHub みたいなもので、よほどの事情が無ければ他の選択肢は無いと思う。古いチャットツールや IM 等では役不足であり、使いづらさでストレスが溜まってチャットどころではない。

  • Q: オンプレじゃないと会社が許してくれないんだけど？

Ans: Rocket.Chat など非公式の Slack クローンもある。ただオンプレだと自前メンテが必要なため、どうしても管理者のスキル不足や大人の事情が生じる。「環境が貧弱で重たい」とか。なので多少苦労してでも Slack を使う方向に倒した方が幸せだと思う。

  • Q: グループウェアのコミュニケーション機能で十分だと思っているけど？

これは単に無知なだけ。Slack レベルのチャットの使いやすさには到底及ばない。この質問は「チャット使わなくてもメールがあるじゃん」と言っているようなもの。

(特に上司やリーダーは) タスク管理

上司やリーダーは読むべきメッセージ量が多く、報告や依頼される量も多い。そのため彼らには 「自分が対処すべきメッセージ」をタスク管理に落とし込み、対処を漏らさないようにするスキル が要求される。そうしないとメッセージ発信者が改めてフォロー（口頭であることも多い）する羽目になり、チャットの意義が薄れる。

ここで一つの疑問（主張）が生じる。

  • Q: 上司/リーダーは忙しいのだから部下がちゃんとフォローするべきでは？

確かに一理あるが、常にそうであるとも限らない。上司側の怠慢であるケースもある。

以下ポエム。

私が思うに、上司/リーダーレベルの人間であればタスク管理程度は習得して当然だ。タスク管理を使えば、受けたメッセージをタスクリストに追加するとか、一日数回ほど「メッセージを読んでタスク消化に落とし込む」タスクを設けておくだけで、これに対処できる。もちろん、それら管理作業に時間がかかっていては話にならないので、呼吸するかのように素早く使いこなす技術も必要だ。

通知をコントロールする技術

チャットにも通知という仕組みがあり、口頭ほどではないものの割り込みを感じることがある。これを対処するスキルも必要だ。

アプローチは二つある。

  • アプローチ1: 通知を切る＆自分のタイミングで読む

通知を意図的に無視する、でも OK。しかしクイックレスポンスを要するメッセージへのレスポンスが遅れがちになる。この点は「緊急な用事は口頭にして」とか「メンションは緊急な時のみ使って」など目安を決めて回避できる。

あと、よくあるのが「チャットを読むのを忘れる」だが、それはタスク管理なりリマインダーなりで忘れないよう制御するしかない。たとえば一日三回ほどチェックしたいなら、アラームソフトなんかを使って毎日三つほど「チャットを読む！」というアラームを設定しておくとか。

  • アプローチ2: 集中タイムを設けて、その間は一切反応しない

これは「この時間帯は一切反応しませんよ（集中したいんです）」という時間帯をつくる、というもの。集中タイムの時間帯をチーム内でしっかり共有できていれば案外機能する。

この方法の問題は「集中タイム時に送ったメッセージはどうなるの？」ということだが、そこは「集中タイムが終わった後に読んでくれるだろう」と信じるしかない。読んでくれないとしたら、それは受信側の問題だ（上述のタスク管理できてないケースが大半だと思う）。

運用時のコツ

チャットベースコミュニケーションの運用が捗る TIPS をまとめる。

既読リアクションをする

メッセージを送っただけでは「ちゃんと読んだのかな」と不安になる。読んでくれていたなら問題はないが、読んでない場合は「ちゃんと伝えたじゃないですか」「聞いてねえよ」となりかねない。

これを防ぐために 既読リアクション を導入する。

  • 絵文字でリアクションする ということ
  • 用意しておくと捗るリアクション
    • (1)許可: 「いいよ」とか「OKです」といった意
    • (2)認識: 「（まだ対応してないけど）認識はした」の意

特に重要なのが 2 の認識リアクション。今すぐ結論を下せない（あとで処理したい）メッセージも多いので、「とりあえず認識だけはしたよ（対応は後でやるよ）」というクッションがどうしても必要になる。

期限を添える

チャットで依頼を行う場合、相手に「いつまでにやればいいのか」という期限も与えておくのがよい。そうしないと「あのー、Aの件、まだです？明日までに必要なんですが」「え？そうなの？」となりかねない。

ただし「今日中」みたいな期限のキツイ依頼については、受信側の都合もあるので、口頭などで相談をした方がいい。

用途に応じて部屋を分ける

プログラミングには「一関数や一クラスは一つのことだけをさせる」というプラクティスがある。日常生活でも情報をフォルダやカテゴリやタグで分類する。会議でも目的とアジェンダを定めて、話が脱線しないようにする。同じように、チャットにおいても部屋を適切に分類するべき。

部屋を適切に分類できてないと、たとえば「このチャンネルにはどうでもいい雑談が多いけど、たまに必要なメッセージが混ざるので読まざるをえない（読むのに時間かかるのがだるい）」という状況になる。そんな部屋が 3, 5, 10……と多数存在すれば、メッセージを読む負担は計り知れない。

悪い例:

  • (Slack限定の仕組みだが) #general チャンネルで雑談する
    • 理由: #general は必ず全員が所属しており、どうでもいい雑談で注意力を逸らすべきではないから
  • #team_hoge チャンネルでほげチームに属する複数 PJ の話題を全部やり取りする
    • 理由1: 関係無い PJ の話題が多くて見づらいから
    • 理由2: 複数 PJ の話題が錯綜して読みづらい・追いづらいから

良い例:

  • 全体連絡は #general、雑談は #random チャンネルを使う
  • #team_hoge_pj1、#team_hoge_pj2、というふうに PJ 毎にチャンネルを細分化する

ここで一つの疑問が生じる。

  • Q: 部屋数が増え過ぎたら逆に読みづらくならないか？

部屋数が少ないよりは確かに読みづらいが、一つの部屋内で関係無い話題が錯綜するよりは断然マシである。

一つたとえを出そう。ちゃんと整理された数十のフォルダと、未整理の1000個のファイルが放り込まれた一つのフォルダ、どちらがマシだろうか。ピンと来ないなら数百のフォルダと10000個のファイルで考えてみてもいい。

役職の高すぎる人は入れない

「役職の高すぎる人」がいると、一気に発言のハードルが高くなり、気を遣うためストレスも溜まる。また（彼らはリテラシーが低いため）下っ端は振り回されやすい。さらに言えば、彼らは高齢で、新しいことを学ぶ体力も気力も持っていないため、運用ルールにも従ってくれない。老害という言葉があるが、まさに邪魔者である。

邪魔者は 入れない に限る。

  • Q: 役職が高すぎる人って、どれくらい？

平社員、係長/リーダー、課長/マネージャー、部長……でいうと部長以上。「プロジェクトメンバーでない人」と言い換えてもいいかも。

  • Q: でもチャットシステムを使わせない、というのはさすがに無理があるのでは？

であれば、チームのチャンネルに彼らを入れないようにする。彼らは雑談チャンネルで喋らせておけばいい。自分も雑談したいなら、別に雑談チャンネルを作って、必要メンバーを入れればいい。

人数は少ない方がいい

参加人数が多すぎると、緊張や配慮が働いて発言しづらくなる（特に1vsN）。人数は小さい方が発言しやすい。目安は笑いを示す「ｗ」が使えるレベルだろうか。

会社雑務や技術的な質問は人数が多い方がいい

会社の雑務について、あるいは技術的な不明点を質問したいケースは多々ある。特に前者はググっても出てこないのでよく発生する。このような場合は、参加人数が多い部屋の方が回答が集まりやすい。

極端な例を言えば、全従業員が見ている雑談チャンネルに投下すれば、誰か一人は反応してくれるだろう。逆に、自分のチーム内のみの部屋であれば（質問内容にもよるが）回答はあまり期待できない。

Mention の使い所

正解は無いだろうが、たとえば以下の目安がある。

  • 相談と依頼には使う
  • 報告と（特に1vsNの）質問には使わなくてもいい

Mention は相手の注意を引く行為なので、極力抑えなければならない。「そのうち読んでもらえればいい」とか「最悪読んでもらわなくてもいい」ことは Mention しなくてもいい。

しかし（特にチャンネルが活発な場合は）相手が過去ログを辿らないかもしれない。そのあたりは運用時の観測が必要だろう。読んでもらえそうにないなら、Mention で喚起するしかない。

資料やノウハウをまとめておく

いわゆる「尋ねる前にここを見ろ」的なものを作っておく。そうしないと同じ質問を（違う人から）何度も繰り返されることになり、（特に「わかる人」は）回答に時間を取られることになる。

ちなみに「過去メッセージにあるからそれを見ろ」は参考にならない。チャットは過去ログを読むのに弱いため、面倒くさくて読むのを諦めてしまう。Wiki のようなストック性に優れたシステムでまとめるのが良い。

「ググる」という習慣を叩き込む

ググって調べればすぐわかることも質問してくる人がいる。そういう人は「ググる」という考え方を知らないことも多いので、しっかりと啓蒙しておく。

以下ポエム。

私が思うに、エラーメッセージをググって解決策を調べる程度のリテラシーは社会人なら備えるべきだろう。もちろん、だからといって（他に知っている人がいるのに）1時間調べるのは遠回りであるから、ちょっと調べてわからなかったら質問する、というのはアリ。その際、皆は知らなかったら「知らん」と反応してあげるとグッド（質問主は回答を待つことなく「自分が頑張って調べるしかないか」と腹をくくれる）。

参考

「口頭 チャット」でググると、色んな見解が出てくる。適宜参考にすると気付きが得られるだろう。

以下は私が読んだリンク先と簡単な感想のメモ。