これはなに
プロダクト開発の現場において、コミュニケーションエラーは非常に大きな障害となります。結論が曖昧であったり、正しい意図を汲み取ることに読解力を要したり、ログとして機能しないようなメッセージを投稿してしまう人は、どうしても存在します。また、いざ自分がそういった厳密性のあるテキストを作ろうとすると思ったよりも難しかった…という経験をされた方もいるのではないでしょうか。
本稿ではSlackによるコミュニケーションにおいて、「なんとなくこういうことに気をつけると抜け漏れない連絡ができる」という項目をチェックリスト的に列挙します。皆さん自身のテキストコミュニケーションであったり、一緒に働くメンバーに対するFBとして機能すれば幸いです。
また、本稿は @fujinumagic さんが書かれていた チャットやメールの文章をないがしろにする人はチーム全体の開発効率に悪影響を与える へのアンサーというか、「じゃあ明日からどうするのか？」という部分の補完としての役割を意識しています。
こころがけ
そもそもテキストだと全然伝わらない
メラビアンの法則 によると対面コミュニケーションにおいて他人に影響を与える情報の割合は以下のようになっているそうです。
- 見た目などの視覚情報 -
55% - 口調や話の早さなどの聴覚情報 -
38% - 言語情報 -
7%
Slackで会話するときに表情や声色は伝わりませんので、使えるのは僅か 7% の言語情報のみということです。はじめから我々が普段話すときに伝えている情報のうち 93% が失われた状態でコミュニケーションを行なっているという言い方もできます。
つまり、誰であっても「普通に話したのでは伝わらない」ということです。これを常に意識し、誤読の余地を極力減らしていく必要があります。
適当な文章は相手に失礼
これは当たり前の話ですが、特にクライアントワークだと開発チームのコミュニケーションは我々のお客様の目に触れていたりします。誤字・脱字だらけであったり文意を掴みづらいテキストは会社の信用に関わるので絶対にやめましょう。
そして、たとえ社内であっても相手は頑張って意味を解釈しようと読んでくれています。きちんと伝えようという姿勢が見られなければ相手に不信感を与えてしまうというのは自然なことであると感じます。
頑張って書いても適当に読まれる
どれだけ頑張って書いた文章であっても、相手が忙しかったり帰宅中の電車でチラッと見ただけ…というような場合は十分な時間と注意をもって読んではもらえません。なので、読解するために力を要する文章を送ってはいけません。リンクは誰も開いてくれないしスレッドを積んでも誰も追ってくれません。本当に読んでほしいことは横目で適当に眺めても正確に内容が理解できるよう簡潔かつ平易な文章を心がけます。
ガイドライン
曖昧さの削減
日時は正確に記述する
WHAT
「明日」や「今週末」「先月末」「来週頭」などの相対的な指標を使わない。
ただし、状況によっては理解を助けることもあるので、必要に応じて併記することが望ましい。時刻は24時間表記で記述し、分単位は利用しなくても「00」をつける。
WHY
相手がいつ読むか分からないため。
また、ログとしての機能が損なわれるため。
DON'T
明日のMTGですが、来週木曜の5時にリスケさせてください。
DO
明日 7月19日 (金) 12:00に予定されていたMTGですが、来週 7月25日 (木) 17:00にリスケさせてください。
タスクの期限には時刻を明記する
WHAT
タスクを頼むときには日時だけでなく、期待する完了時刻を伝える。
ただし、本当にいつでもよい時はその限りではない。
WHY
「明日まで」という書き方をすると「明日が始まるまで」なのか「明日が終わるまで」なのかわからなくて心理戦になるため。また、「明日中」も同様に「終業まで」なのか「23:59まで」なのかが不明瞭であるため。
また、そうした細かい指定がないままの依頼は「適当に頼んでいる」というような印象を与え、相手の気分を害する恐れがあるため。
DON'T
来週プレゼンする資料、明日中に仕上げておいてね！
DO
来週プレゼンする資料、
明日 7月19日 (金) 19:00までに仕上げておいてね！
相手に期待する行動を明らかにする
WHAT
人に何かを頼むときは、具体的にどういう行動を期待するのかを明記する。
特に「確認してください」という言葉は解釈に幅があるため安易に使わない こと。
一例として、以下のような言い換えが可能である。
| 意図 | 表現 |
|---|---|
| 見てくれればいい | ご一読ください |
| 承認がほしい | ご一読いただき、問題なさそうであればその旨お伝えください |
| 意見がほしい | ご一読いただき、お気づきの点などありましたらお伝えください |
WHY
相手に何を返せばいいか考える負荷を与えてしまうため。
ちょっといやらしい話をすると、音沙汰なくて意思決定が遅延しても相手に「いや『確認』はしたが？？」という言い訳を許してしまうため。
DON'T
Sketchファイルを送っておいたのでご確認ください。
DO
Sketchファイルを送っておいたので、目を通してユーザーテスト用の画面に抜け漏れがあったら教えてください。
疑問への返答を最初に書く
WHAT
相手に何かを聞かれたときはそれに対する答えを最初に書く。
理由、根拠、補足や折り返しでの質問などは全てその後に記述する。
回答は質問の形式 (YES/NO, WHなど) に合わせて直接的なものにする。
WHY
相手に考える負荷を与えてしまうため。
DON'T
相手: トップ画面のデザインは確定済みという認識でよろしいでしょうか？
自分: ユーザーテストの結果次第では修正する可能性があります。
DO
相手: トップ画面のデザインは確定済みという認識でよろしいでしょうか？
自分: はい。現時点では確定しております。
ただし、ユーザーテストの結果次第では修正する可能性があります。
不要な婉曲表現を使わない
WHAT
「-と言える」「-と思われる」というような表現は無くても通じるようなら消す。意見を述べるときは「思います」「感じます」「考えます」と言い切る。
ただし、あまり断定的な表現を連発するとキツい人みたいになるので、空気が悪くなってきたら婉曲表現によるクッションを利用する。
HOW
変に含みが生まれてしまい、文意が分かりづらくなるため。
DON'T
ユーザーの反応は概ね良好と言えます。
DO
ユーザーの反応は概ね良好です。
不要な受動態を使わない
WHAT
能動態で表現できることはそのようにする。
その際、可能な限り主語を明記する。
WHY
主語・目的語の省略に気づきにくくなったり、対応が分かりにくくなるため。
特に長い文章だと読めないレベルになり得るので注意が必要。
DON'T
ボタンが押されたときに、リクエストが発行されて保存処理が実行される想定です。
DO
ユーザーがボタンを押すとクライアントからリクエストを発行し、それを受け取ったサーバーサイド側で保存処理を実行する想定です。
曖昧な慣用表現を使わない
WHAT
エンジニア同士の会話において口頭で用いられる慣用表現はテキストでの業務連絡では使用しない。
前後の文脈から「誰がどう見ても間違えようがない」場合は省略できるが、そうでない限りは正確に記述する。
あくまで一例として以下のような言い換えを用いる。
| 慣用表現 | 言い換え例 |
|---|---|
| (値を) 投げる/渡す | リクエストする/引数に渡す/... |
| (値を)返す | レスポンスを返却する/戻り値を返却する... |
| (値を)弾く | リダイレクトさせる/バリデーションして保存処理を阻止する/... |
| URLを叩く | アクセスする/リクエストする/... |
| 画面側 | フロントエンド/クライアント/... |
WHY
どういう意図で言ったのかが思い出せないと終わるため。
DON'T
バックエンドにユーザートークンを投げて、認証できたらトップに飛ばします
DO
バックエンドにユーザートークンをペイロードとしてPOSTリクエストし、認証成功レスポンスがクライアントに返却されたらトップにリダイレクトさせます
不要な指示語を使わない
WHAT
こそあど言葉や、「- のやつ」「- の件」といった具体性を欠く指示語を使用しない。
「元の」「前の」「今度の」「次の」などはうっかり使いがちなので気をつける。
但し、同文中に指示対象が明確に含まれる下記のような場合は使える。
私が用意した素材があるので、それを使用してください。
以前のログを指す場合は当該部分のテキストを引用し、「下記ですが-」といった指定を行う。
WHY
わかりにくい
DON'T
プロトタイプの件だけど、前に言ってたやつで行きます。
DO
来週 7月25日 (木)のユーザーテストで使うプロトタイプだけど、下記のもので行きます。
[Slackリンク]
共通認識がない用語を使用しない
WHAT
略語や専門用語などを利用する際、それが相手に通じないものである可能性がある場合はその単語そのもの使用しない。
止むを得ない場合は平易な説明文を書き添えるなどして対応する。
仮に共通して用語を使用していることは確認できても、業界が違うと意味が変わるような用語は非常に多いため、最初に使用する際にはどのような意図で利用したのかを説明する。
特に「モック」「プロトタイプ」や「レビュー」といった用語については期待する成果物/作業の粒度にかなりの幅がある ため、事前に認識をすり合わせること。
DON'T
8月末に一度、関係者でプロトタイプをレビューして頂きたいと考えておりますので、宜しくお願いいたします。
DO
8月末に一度、関係者でプロトタイプをレビューして頂きたいと考えております。
成果物の粒度としては全体的な情報設計のみを行いビジュアルデザインを当てていない状態のものを想定しておりますので、トップページからの会員登録導線が改善されているかどうかを検討したいと考えております。
事実と意見は分離する
WHAT
客観的な事実と自分の考えは分けて記述する。
事実は根拠を併記して断定形で、意見は「考える」「思う」「感じる」などの表現を用いて明確に記述する。
WHY
プロジェクトを進めるうえで制約となるものや意見の余地があることの境界が曖昧になり、議論が停滞するおそれがあるため。
また、事実である場合にその根拠を添えることで前提と思われたものが間違っていた場合の軌道修正を早めることができるようになるため。
DON'T
現状のデザインだとユーザーは混乱してしまうと思うので、次ページへのリンクには変更が必要です。
DO
ユーザーテストの結果から現状のデザインだとユーザーは混乱してしまうことが分かっているので、次ページへのリンクには変更が必要だと思います。
可読性の担保
リンクは本文の最後に配置する
WHAT
SlackでURLを添付する際は本文の下側に添付する。
WHY
Slackではサムネイル画像が本文下側に展開される仕様であり、URLもそこに並べて表示されることが望ましいため。
また、クリック領域を一箇所にまとめることで誤操作を防ぐことができるため。
DON'T
DO
書式の統一
記号の使用ルールを統一する
WHAT
Wikipedia:表記ガイド に則り、記号の使用をルール化する。
- 数字・アルファベットは半角のものを用いる
- 可読性担保のため
- 括弧は半角で使用し、隣接する文字との間に半角スペースを入れる
- 和文・欧文どちらにも対応できるため
- テキストの全文検索における利便性が高いため
-
〜は使用しない (win互換性のため)- MacとWIndowsで文字コードが異なるため
- 文言の省略には半角マイナス (
-) か三点リーダー (…) を用いる (例: 「 - のお客様」という文言ですが)
- 罫線素材を使わない
- テキスト読み上げが正しく機能しないため
WHY
いちいちケースバイケースで考えていると面倒であるため。
また、著しく可読性を損なうような記号の誤用を事前に防ぐことができるため。
長文はスニペットとして貼る
WHAT
議事録など、長い文章をそのままSlackに展開するときはスニペット化する。
WHY
コードブロックは等幅フォントで全ての文字が展開されてしまい、可読性が低いため。
また、長大な文章がそのまま投稿されると会話のログが流れてしまうため。
DON'T
DO
(この長さだと大して変わりませんが、長文になってくると DON'T の方は割と読むのがつらくなってきます)
お気持ち
何かしてもらったら感謝を先に述べる
WHAT
タスクの完了連絡に応答するようなタイミングでは最初に感謝を述べる。
絶対に後回しにしたり適当な返事をしないこと。
WHY
チャットの性質上コンテンツの印象は最初のテキストで決まりやすいため。
また、表情や細かなニュアンスの伝えづらいテキストの性質上、曖昧な伝達をすることでそもそも「伝えた」という事実そのものが認識されない可能性があるため。
DON'T
相手: 先方に連絡しておきました。
自分: じゃあ、ユーザーテストに向けて頑張っていきましょう。
DO
相手: 先方に連絡しておきました。
自分: ありがとう！助かりました。
じゃあユーザーテストに向けて頑張っていきましょう。
固有名詞は絶対に正確に記述する
WHAT
人名、ニックネーム、社名、製品名などの固有名詞は絶対に正確な記述を心がける。
覚えていたり、予測変換で確からしいものが出たとしても自信がなかったら一次情報をあたること。
チームメンバーや顧客など直接関わっている人名・社名は無論のこと、話に登場する製品名やアーティスト名・曲名に関しても同様に注意すること。
特にニックネームが明らかな自動変換の誤用でカタカナになっていたり、大文字・小文字を間違えるケースは非常に多いので注意すること。
WHY
注意を払わずにテキストを打っているという印象が強くなるため。
特に人名・社名・ニックネーム等に関しては非常に失礼な行為となるため。
送る前に見直す
WHAT
テキストを打ったら送信・公開前に絶対見直す。
見直す時間が取れない場合は送信・公開しない。
社内などであれば公開してから読み返し、編集するという流れでもよい。
WHY
誤字・脱字によって与えた「適当な人」という印象を払拭するのは難しいため。
また、初歩的な誤変換やタイプミスなどの多くは一度通読すれば修正可能であるため。
おわりに
これらは未だ試しながら拡張を繰り返しているような状態で、決して完成されたものではありません。
読んでいただいた中で、「こういった観点も必要ではないか」「この規則は不要ではないか」といった気づきがありましたら、共有していただけるとありがたいです。