テキストコミュニケーションで意識していること

ymdkit
·

リモートワークで仕事をしていると、Slack や Teams といった何かしらのチャットツールでコミュニケーションを取ることが多い。そうやって仕事を続けていく中で「こう伝えたらよりスムーズに話が進んだかな...」という後悔は多々あり、日々試行錯誤を続けている。

そうやって試行錯誤を続けていく中である程度テキストコミュニケーションを取る上でのフォーマットが定まってきた気がするので、箇条書きでまとめてみようと思う。(随時更新予定)

prefix (接頭辞)をつける

文章の先頭にその文章の目的がわかるような prefix をつけて、何のためにポストしたかを一目で分かりやすくする。例えば以下のような prefix をつけることがある。

  • 【質問】→ 相手の返信が欲しい時

  • 【共有】→ 返信は不要だが、内容は把握しておいてほしい時

  • 【メモ】→ 返信不要で、後から検索できるよう残しておきたい時

箇条書きする

文章が長くなってきた時に、情報が並列になっている場所があれば箇条書きに直して見やすくなるようにする。

例:Aの時にBの状態になって、Cの時にDの状態になるんですが...

  • Aの時:Bの状態になる

  • Cの時:Dの状態になる

相手の目的を意識する

自身はエンジニアとして仕事をしているため、仕様や実装内容についてやり取りをすることが多い。その中で、やり取りをする相手に応じて伝え方を変えることでコミュニケーションが進めやすいのでは... という場面によく遭遇する。具体的には、相手の目的や立場に応じて「最終的に何が知りたいのか」を考え無駄なラリーを減らせるようにするのが重要だと感じる(先読み力)

例:新しく実装した機能にバグがあった時

  • ビジネス職

    • 相手の目的:顧客に説明したい、影響範囲を知りたい、いつまでに直せるか知りたい...

    • 伝え方:〇〇の機能でバグが発生しています。現状このシナリオのユーザに影響が出そうです。原因はわかったので明日には直せると思います。

  • エンジニア職

    • 相手の目的:原因を調査したい、バグを修正したい、再発防止したい

    • 伝え方:〇〇の機能でバグが発生しています。XXのPRの内容が原因だと思うので、修正しつつ他の場所でデグレが発生しないかの確認をお願いします。

背景を共有する(してもらう)

先ほどの内容にも関連するが、何かしら質問する際、面倒がらずにその背景や目的を含めて共有した方が結果としてやり取りがスムーズに終わることが多い。自分が質問する時もそうだが、される時も背景含めて確認することで、適切な回答がしやすいと感じる。

例:デザインとその実装についてのやりとり

A「〇〇に表示する文字数を計算することはできますか?」

B「実装自体は可能です。ちなみに、どういった箇所でそれが必要になりますか?」(背景の確認)

A「〇〇に表示される文字がはみ出ると困るので、フォームに入力制限をかけようかなと思ってます。」(質問の裏に隠れていた本当の目的を確認)

B「そのシナリオだと、画面の横幅を越えたら自動で省略する機能があるので、あえて入力制限をつける必要はないと思います。」(別の解決策を提示)

A「なるほど、であればそもそもその部分の考慮は必要なさそうですね」(根本解決)

解釈の幅をもたせない

テキストコミュニケーションでは、対面でのコミュニケーションより細かいニュアンスが伝えづらい。そのため、受け手によって伝わり方が変わる表現は可能な限り避けるようにする。相手側にいい感じに察してもらえる場合もあるが、最初からそれを期待するのではなく、そもそもその気遣いの必要がない状態が理想である。

  • この間のミーティングで...

    • いつ行われたのか、何についてのミーティングだったのかが不明瞭(その後の文章で判別できない場合)

    • → 01/01 の〇〇についてのミーティングで...

  • このページ、レイアウトが崩れてますね(画面全体のスクショのみ添付)

    • 画面のどこを見て崩れていると感じたのかが不明瞭

    • → このページ、ヘッダの〇〇の部分のレイアウトが崩れてますね。もう少し文字サイズを小さくしてもらえると助かります。

具体例を書く

具体例は、前述した「解釈の幅をもたせない」を実践する上で有用な一つの手法である。特に、何かを依頼する時自分の求めるものと相手のアウトプットのズレをなくす上で効果的だと思う。 最近は ChatGPT にお願いするときにこれを意識することが多いが、人間相手でも同じだなと思う。

例:技術選定をお願いしたい時

新しく Web サイトを作りたいので、どのフレームワークがマッチしてそうか調査して欲しいです。↓のような感じでまとめてもらえると嬉しいです。

| フレームワーク | SSR に対応しているか | 既存の記事を移行しやすいか

| Next.js | ○ | hogehoge

クローズドクエスチョンを意識する

質問の仕方の分類として、クローズドクエスチョン、オープンクエスチョンというものがある。

  • クローズドクエスチョン:YES/NO の様に選択肢から選ぶ質問

  • オープンクエスチョン:「今日どうしたい?」の様に自由な回答を求めるもの

雑談等で親睦を深めたい場合にはオープンクエスチョンも有効だが、仕事をする上ではクローズドクエスチョンを使う方が効率的だと感じる。また、クローズドクエスチョンをする場合は「自分的にはどちらの選択肢が推しなのか」も書いておく方が議論が進めやすい気がする。

ただ、無理して見当違いな選択肢を用意するよりは素直に「わからない」といった方が話が早い場合もあるので、ケースバイケースな気もする。

例:要件で決まっていた仕様の実現が難しい時

〇〇の理由があり、当初決まっていた仕様の実現は技術的に困難です。

なので、↓のどちらかの方法で回避しようと考えています

  • Aの方法:工数少なく実現できるものの、後の仕様変更に弱い

  • Bの方法:工数はかかるもの、拡張性を担保できる

今の事業フェーズとしては A の方がいいと自分は思うのですがいかがでしょうか?もし他の方法があれば教えていただけると嬉しいです。

ボールを落とさない

状況説明だけで文章が終わった場合、責任の所在が曖昧になることが多い。こういった場合は次のアクションも記載しておくことで、次に誰が行動すれば良いかを明確にでき、塩漬けになるリスクを軽減できる。

例:検証をお願いされていた技術が期待通りでなかった時

〇〇のライブラリを試してみたのですが、XXの部分の問題で期待通りの出力が得られませんでした。

...

なので、このまま別のライブラリの調査を行おうと思うのですが問題ないでしょうか?もし他に優先して着手して欲しいタスク等あればご連絡いただけると助かります。

URL、画像(スクリーンショット)を使い分ける

"テキスト"コミュニケーションからは少し離れるが、発言の根拠となる情報を示す時、URLや画像を使うことが多い。そしてこの二つにはそれぞれメリット/デメリットがあるので、それを意識しつつ使い分ける様にしている。何なら場合によっては両方使っている。

  • URL

    • メリット

      • 情報が最新であることが保証されている

      • 一次情報等について、情報の質がある程度保証されている

      • チャットツールのURLについて、周辺のやりとりも同時に参照できる

    • デメリット

      • 相手側に「URLを開く」という手間が発生する

      • リンク切れのリスクがある

      • リンク先の内容が更新された場合に、発言内容との整合性が取れない場合がある

  • 画像

    • メリット

      • チャットツール上ですぐに内容を確認できる

      • その当時のスナップショットとして残せる

    • デメリット

      • 内容のコピペが困難(以下具体例)

        • エラーログやソースコード

        • 内容について検索したい時

      • 古い情報がそのまま残ってしまう

        • 最新の情報と勘違いしてしまうリスク

      • 後から検索しにくい

メンションの範囲を考える

チームの人数が増えてくると、関係ある人にだけメンションを送って返信を求めることが増える。ただ、この時のメンションの範囲をどうするかは難しいところで、広すぎても狭すぎても何かしら問題が発生する。

  • 広い場合:

    • 誰かが答えるはず... という集団心理で返事が返って来にくい

    • 関係ないメンションばかり飛んでくると必要なメンションが埋もれてしまう

  • 狭い場合:

    • 忙しい人相手だと返事待ちの時間がかかる

    • メンションしなかった人に情報が行き渡らず、同じ質問が繰り返される

上記の問題を解決するため、自分は 「cc」のようなキーワードで「返信して欲しい人」と「知っていたらで良いので返信して欲しい人 / 返信はいらないが内容を把握して欲しい人」を区別するようにしている。

ただ、cc だからといってむやみやたらにメンションをつけるとメンションが埋もれやすくなってしまう(鬱陶しいと思われかねない)ことに変わりはないので、本当にこの人たちにも伝えるべきかというのは常々意識しておきたいところ。

例:モバイルアプリを開発している人が、デザインについての質問をしたい時

@デザイナーA cc @team-designer @team-mobile-app

〇〇の画面について、XXの状態の時のデザインは以下のような形で良いですか?(Figma みた感じAさんが着手した部分だと思ったので、Aさんにメンションしました)

フォーマットを気にしすぎない

上記に書いた内容を意識しすぎて投稿までに時間がかかってしまうと、結果としてコミュニケーションコストが増えてしまう。自分の中で完璧だと思う文章を10分かけて送るくらいなら、80%くらいの文章を1分で送って後から補足していく方が、情報が素早く共有されるという意味ではチーム全体としてプラスになる時もある。

例:不具合が起きていることは分かったものの、原因がはっきりしていない時

〇〇の機能で不具合が発生していることがわかりました。原因までは突き止められていないのですが、取り急ぎ動作確認に支障が出ると思うので共有です。(原因や影響範囲がわかり次第スレッドに追記していきます)

最後に

まとめた上でこれを書くのも本末転倒な気がするが、結局上に書いたような Tips は小手先でしかないとも思っている。コミュニケーションはきっと

  • 伝え方

  • 伝える内容

の両方が上手くいって初めて成立するものだと思うので、今の状態を正解だと思わず日々試行錯誤を続けていきたい。

@ymdkit
「暗記メーカー」ankimaker.com というサービスを開発している個人開発者です。 @keita_developer