HubSpotやCSS設計に明るい半田のウェブサイトです。
ウェブサイトの本質は情報を伝えることですので、それを言い訳にデザインは全体的に工事中です。

業務コミュニケーションをデザインする 1. コミュニケーションの背景とタイプの分別

シェア:

業務コミュニケーションをデザインする 1. コミュニケーションの背景とタイプの分別 サムネイル画像

最近会社の業務コミュニケーションについてガッツリ考え、フローをリファクタリングし、実運用できるレベルにまで落とし込んだのでその内容を少しずつシェアしたいと思います。 前提として私はweb屋で、ディレクターとエンジニアの架け橋となるテクニカルディレクターをしています(自分でコードを書くこともまだまだ多いですが)。

なぜコミュニケーションスキルが必要なのか?

チャネルの多様化

一つに、コミュニケーションの方法が多様化していることが挙げられます。 数十年前の業務におけるコミュニケーション方法は、主に対面、電話の2パターンしかありませんでした。 十数年前から、そこにメールが加わります。 今はそこにチャットツール、チケット型タスク管理ツール、ビデオチャットが加わります。

対面、電話だけの時代でさえ人によるコミュニケーションの癖というのはあったと思います。チャネルが少なかった時代は、癖が強くても、カオスな人でもなんとかなったかもしれません(口頭ベースのコミュニケーションというのは人間にとって1番自然な方法なので尚更です)。

いまはその癖が、乱立する各コミュニケーションツールの上に乗ります。カオス×カオスの、カオスの乗算です。 元々癖の強い人が書くメールなんて、もう何言ってるかわかりません。

業務の複雑化

もう一つのポイントが、さまざまな仕事が高度化、複雑化しているということです。 ただでさえ複雑な仕事内容なのに、そこにカオスのごった煮の指示が届いたらどうでしょう。もう色々ひっちゃかめっちゃかです。とっちらかっちゃってます。

そして何よりの罠が、 「私たちは自分の癖に気づきにくい」 ということです。 自分としては普通に伝えているつもりでも、実はそれが他人にとってとても癖が強かったり、わかりづらかったりすることはザラにあります。きっとこの文章もそうですね。

プライベートのコミュニケーション方法にとやかく言うつもりはありませんが、仕事上でそれをやってしまうと工数が増大するだけでなく、カオスなコミュニケーションに段々と疲弊してきます。きっと誰もがそんな経験をしたことがあるのではないかと思います。

一つは単純に、無駄な工数をかけないで利益を確保するために。 もう一つはせめて社内の自分達の間では平穏な心で、平和に、業務を行えるように。 そのために、体系的でロジカルなコミュニケーションツールスキルが必要です。

同期型と非同期型のコミュニケーションの違い

まず同期型、非同期型のコミュニケーションの違い、それぞれのメリットについて説明します。

同期型

同期型は主に直接の対話や電話、ミーティング、ビデオチャットが該当します。場所に限らず、時間を合わせて行うものが同期型になります。

メリット

  • 密なコミュニケーションを取りやすい
  • 感情や微妙なニュアンスが伝わりやすい
  • コミュニケーション速度が1番早い

デメリット

  • 参加者の時間を拘束する
  • そのため、セッティングが難しい
  • 他者の業務を強制的に中断させる
  • 意識的に行動しないとログが残らない

非同期型

対して非同期型は古くは手紙・留守電から最近ではメールやチャットツールが該当します。斉一的な時間の一致が必要なく、「メッセージを残す」的な挙動をしていれば何でも非同期型になり得ます。

メリット

  • 時間に拘束されない
  • ログが自然に残る

デメリット

  • コミュニケーションの速度が同期型に比べて遅い
  • 感情や微妙なニュアンスが伝わりづらい
  • 誤解を招きやすい

どちらが良いと一概に言うのは難しく、状況によって使い分けるのがもちろんベストプラクティスです。 しかしあえて言えば、非同期型のデメリットは全て工夫によって解消することが可能です。

フロー型とストック型の違い

次にフロー型とストック型の違いについて整理します。これは主に非同期型のコミュニケーションツール(プラットフォーム)の中の更なる分類と思ってください。

フロー型の特徴

フロー型はとにかく情報が早い速度で流れます。口頭と同等、あるいはそれに準ずるものの位置付けと捉えておくとよいでしょう。 ただし口頭と違い非同期型として使用することも可能で、もちろんログも残ります。

代表例

  • Slack
  • Skype(チャット)
  • LINE などのチャット的なツール
  • メール

メリット(推奨する使い方)

  • 早いスピードでやり取りができる
  • ストック型に比べて密なコミュニケーションができる
  • 簡単な確認や、何往復かやり取りが必要な確認がしやすい

デメリット(非推奨の使い方)

  • ログは残るが、流れてしまいがち
  • 将来的に参照することを目的とした参照先としては向かない
  • ゆえにチャットのやり取りで何かを決定し、ストック型のプラットフォームに転記しないのはバッドプラクティスです(これは口頭でも同様です)

ストック型の特徴

ストック型は一言でいえば「情報を整理する」ことが目的です。 特にチケット型タスク管理ツールは、「進行中のタスクを管理する」ことの他に 「将来何かあった際に参照して、当時の情報を取得する」という役割も担っていることを忘れてはなりません。 いわゆるエビデンスってやつを見つけやすくしておく必要があります。エビデンスの保管庫です。

代表例

  • Backlog
  • Redmine などのチケット型タスク管理ツール
  • Wiki

メリット(推奨する使い方)

  • 情報を自由に整理できる
  • ハイパーリンクの設定
  • 情報の構造化

デメリット(非推奨の使い方)

  • きちんとルールを決めて運用しないと、参照性がどこまでも悪くなる
  • ゆえに簡単な確認や、何往復かやり取りが必要な確認をストック型でやるのはバッドプラクティスです

じゃあつまりどう使い分ければいいの?

同期型

  • 急を要するとき
  • 微妙なニュアンスや感情を伝えたいとき
  • ログに残したくないとき

非同期型/フロー型

  • スピード重視のときに
  • 同期的にミーティングする必要はないけど、何か話し合いたいときに
  • ログが残るので、出来れば業務にクリティカルに関わることは口頭の代わりに使いたい
  • 簡単な連絡・確認や、何往復かやり取りが必要な確認をする際に
  • 決定事項やきちんとログを残したいものは、必ずストック型のプラットフォームに転記する!

非同期型/ストック型

  • 情報をきちんと構造化する
  • それでも人によって必ず癖は出るので、チケット・Wikiそれぞれにサンプルやテンプレートを用意する
  • 残すべき情報・将来的に参照する情報に追加があった場合は、コメントに書かず概要部分などにまとめる
    • 「ここを見れば概ね把握できる」という形にしておくのがポイント
  • チケットにまとめるべきかWikiにまとめるべきか、の粒度を見極める
  • チケットが増え続けることに対して、アクセシブルな状況を保つ努力をする
  • そもそもプロジェクトを分ける
  • チケットにカテゴリやタグを付与する
  • 親子関係を設定するなど

まとめ

以上、簡単ですが

  • 同期型
  • 非同期型
  • フロー型
  • ストック型

の整理をしました。 「これからコミュニケーションしたいものはどれを使うべきか」 を一度立ち止まりちょっと考え直すだけで、相手に嫌な顔をされたり、大切な情報が見つからないといった事態を防ぐことができるかもしれません。

次回は、現場で実際に運用するにあたり策定したルールをご紹介する予定です。

シェア:

コメント

関連記事