1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

はじめに

在宅ワークの方が増えている昨今、チームメンバーや顧客とのコミュニケーションでチャットツールを利用するプロジェクトが多いかと思います。
ただ、会話のコミュニケーションと違い、相手の顔色や感情が文章から読み取りにくく、些細な認識齟齬やコミュニケーション不足に陥るケースを多く見られます。
メールと違い、チャットツールではある程度フランクな会話を行える場面が多く、工夫次第で相手に一歩踏み込んだコミュニケーションができるのでは?と筆者は考えています。
次項から、筆者なりの***「チャットツール活用術」***と題して、slackを例にチャットツールの活用例を提案します。

チャンネル活用術

勇気を出して、自分の発言をオープンにしましょう。

普段オフィスで顧客やチームメンバーと会話する際、みなさんはどういった場で会話していますか?
なるべく周囲の人に迷惑にならないよう、袖机や会議室でクローズなやり取りをする方もいらっしゃるかと思います。
または会話の内容次第によっても、周囲の人に聞かれないよう場所を移動するかと思います。
チャットツールのチャンネルも同じく、話題ごとに適切なチャンネルを作成することが望ましいです。

ただ、こういうことを思う方いらっしゃいませんか?
「チーム内チャンネルやダイレクトメッセージ(DM)だけでやり取りすれば、他の人に聞かれる心配がない」

事実ではありますが、筆者としては***「それでは、チャットツールでのコミュニケーションの利点を活かせていない」***と考えます。
例えば、

  • 開発内の雑多な話題は開発内部チャンネルやDMでやる。
  • トイメンのお客さんに報告する時だけ顧客とのやり取りチャンネルを使う。

というケースが多いと思いますが、
あえて顧客向けチャンネルで開発内部のやり取りを見せることで効果的な場面もあります。
  
例)お客さんから障害調査を依頼された際、開発内部チャンネル内のみでやり取りすると、
  顧客から見れば「障害調査どこまで進んでるんだ、、、今どういう状況なのか。。。」
  という不安にかられ、逐一開発側に調査状況だったり進捗状況をヒアリングしなければならない。
  なので、あえて顧客とのやり取り用チャンネルで開発側のやり取りを見せることで、顧客的に障害調査のプロセスや状況把握に寄与できる。

チャンネル使い分けについて

「話題ごとに適切なチャンネルを作成することが望ましい」と言いましたが、チャンネルを使い分けることで以下のようなメリットがあります。

  • 話題ごとにチャンネルを分けることによって、会話がカオスにならない。
  • 検索がしやすい、整理しやすい。

また、「何の話題に対するチャンネルなのか」わかるようチャンネル作成時にチャンネル概要を必ず記載しましょう。
チャンネル内のやり取りについても、自分が直接会話に参加していない話題でも、チャンネルの主旨と別の話題に発展している場合、臆せず注意しましょう。
ちなみに、チャンネル作成時に1点気を付ける必要があるのは、「プライベートチャンネル or パブリックチャンネル」かを明確に決めることです。
例えば、見積もりの話など、関係者以外に知られたくない話題をする予定がありそうなら、チャンネル作成時にプライベートチャンネルとして作成する必要があります。(後から変更可能だが、slackの場合、管理者等一定の権限を有するユーザでしか変更できない為、後から変更が困難なケースがあるので注意。)

チャットの書き方

チャットに限らず、文章を書く場合、意識するポイントが何点かあります。
特にチャットのような短文でのやり取りを主にしたコミュニケーションの場合、筆者としては以下を心掛けているポイントになります。

読み手の立場で書いています?

特に、相手が超多忙な人であればあるほど、長文読むのがツライです。
その為、後述の「テキストスニペット」「以下スレッド」「報告する時、結論から書く」等の手法を用いて、読み手の負担減らすことも考えてほしいです。
***「あの人に質問しても全然回答返ってこないなあ」***という経験ある方、実はこの辺が原因ということもあるのでは?
(本稿も読み手の立場で書けているのか、心配なところではありますがw)

報告や質問の主旨が明確か?

報告や質問をする際、「結局何が言いたいのか」や「どういう背景で質問してるのか」といったところを意識できていますか?
特に長文になるとこの辺伝わり難くなりがちなので、送信ボタンを押す前に読み手の立場に立って自分の文章を読み返すことをおススメします。
(筆者は、どんなに短い文章でも、送信ボタン押す前に必ず読み返すクセを付けています。おかげで、相手との認識齟齬の回避に役立っていいると感じています。)

スタンプで個性を演出

スタンプはチャットツールならではのコミュニケーション方法ですよね。
会話のコミュニケーションと違い、文章だけだと活字が主体なので硬くなりがちかと思います。
また、たまに普段使わないスタンプを使ってみると、より相手に自分の感情表現が伝わりやすいかも?
(筆者は単純な性格の為、例えば自分の回答に「神」スタンプを付けてもらえると、「やったー!また神スタンプもらえるようにがんばるぞー!」とモチベーションアップしちゃいます。)

筆者流用例集

ここからはより実践的なチャットツール活用例になります。
slackのみの機能に言及しているものもありますが、他のチャットツールにも活かせるテクニックもあるかと思いますので、是非参考にしていただければと思います。

プチ進捗報告/プチアラート

 みなさん、リアルタイムな状況報告はできていますか?
 報告を受ける側としては、「何も連絡ない=問題ない」と受け止めます。
 報告する相手にもよりますが、筆者は短文でも雑文でもよいのでプチ状況報告/プチアラートしてほしいと感じています。
 特に、障害対応時やリアルタイムに情報欲しい場面など。
  例)今、〇〇作業中なんですけど、テストチームから△△の問い合わせ来てて、〇〇作業を今日一杯とさせてください。
  例)今、進捗報告書いてるんですけど、〇〇調査依頼が来てて定時までに間に合わないかもしれないっす。
  例)テスト環境構築の状況ですが、現在デプロイ中ですので14:00から受入確認できるかと思います。続報あれば後程ご連絡します。

つぶやき

 hereで広報するまでもないが、メモ的に情報共有したい時など。
 つぶやきをする際は、「もしかしたら、誰かの何かの役に立つ情報かも?」と思えるかどうかが大事。
 また、筆者の経験上、つぶやきはプロジェクト全体状況をキャッチアップしたり、情報連携手段として特に重要視している。
 自ら情報を発信できるようにすることは、プロジェクトの中核を担う上で、必要なファクターとも言える。
  例)うちのチームの案件に関係あるかわからないが、○○案件で△△という障害が出てるみたい。
  

独り言

 つぶやきに近いが、会話の本流に絡まないようにコメントしたい時。
 ※↓Cさんのチャットが独り言
  例) 
  Aさん「〇〇のリグレッションテストって必要ですかね?」
  Bさん「必要かどうかは今回の改修の影響範囲見てAさんで考えてほしいです。」
  Cさん「(まあ、関連性薄そうな機能だから個人的には不要な気はしますが。やるとしても動作確認くらいじゃないっすかね)」
  Aさん「To:Bさん→承知しました。確認いたします。
     (To:Cさん→ありがとうございます。参考にさせていただきます。)」
  

テキストスニペット

 文章が長くなる際に使用。議事録等。
 概要を本文にして、詳細をテキストスニペットにすると、概要をぱっと見るだけで確認の優先度判断することができ、読み手の負担軽減に繋がる。

数行の概要だけ一旦書いて、詳細はスレッドにする。

 テキストスニペットと使い方は似ているkが、
 どちらかというと、詳細を注視してほしい場合に用いる。
 

報告する際、結論から書く。

 これも読み手の負担を減らす手法の一つ。
 特に、報告書は文章が長くなりがちなので、「問題/課題があるのかないのか、オンスケなのかどうか」といったことを冒頭で書くだけで、読み手が「注意深く読むべきか or サラッと読めばいいのか」判断できる。
 
 ちなみに、案出しの際にも使える手法で、例えば開発側から通したい案ある時には↓のような書き方をする。
 例)
  ○○の件ですが、以下の2案考えております。
  ちなみに、開発としては案1で考えております。
   案1:○○
   案2:△△
   

逆に結論を最後にする

 「報告する際、結論から書く。」よりは使用頻度少ないが、例えば以下のような例で使用する。
 例)開発側で考えてる案はあるが、どちらかというと顧客に決めて欲しい時。
   
   〇〇の件ですが、以下の2案考えております。
    案1:〇〇
    案2:△△
   ちなみに案1は■■のメリデメがあり、案2は××のメリデメがあります。
   開発としては案1でもアリかなと考えておりますが、ご判断いただきたく。
   

質問や報告する際、どんな返しがくるか想像し、なるべく相手の返信負担を減らす。

  究極を言えば、はい/いいえやスタンプで済ませさせるのがベスト。
悪い例)
   Aさん「〇〇APIですが、どうすれば動きますか?」
   Bさん「ご質問ありがとうございます。ちなみに〇〇APIはどういった理由で動かしたいのでしょうか?また、試したパラメータを教えていただければと思います。」 
 
良い例)
   Aさん「現在、△△案件のリグレッションテストの為、〇〇APIを動かしたいと考えてます。
       設計書に記載あるサンプルを元に実行しましたが、××エラーと出ます。
       また、wikiには廃止とありますが、こちら既に廃止機能になりますか?」
   Bさん「ご質問ありがとうございます。
       確認したところ、ご指摘の通り資料が古く、現在廃止機能となります。」

おわりに

冒頭でもお話した通り、チャットツールは相手の顔色や感情が読み取りにくく、聞き手の捉え方次第で、円滑にコミュニケーションできない場面も多々あるかと思います。
ちなみに、(性格上)普段オフィスで比較的消極的なコミュニケーションをしがちな筆者は「顔色や感情が読み取りにくい」ことを逆手にとって、
普段のキャラクターとは対照的に、チャット上では臆することなくコミュニケーションを図り、
スタンプを活用して、チームメンバーのモチベーションアップを図り、
顧客とのコミュニケーションの補助ツールとして活用しています。

みなさんも是非、チャット上で様々な人と円滑にコミュニケーションできる「チャットイケメン/イケジョ」を目指してみてください。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?