"伝わる" テキストコミュニケーション
この記事は プロダクトマネージャー Advent Calendar 2023 の4日目の記事です。昨日は『許認可取得と向き合うプロダクト開発』(@nozo_omuさん) でした。
こんにちは！プロダクトマネージャーのひまらつ(@himara2)です。
私の所属するmicroCMSという会社では「フルリモートワーク」かつ「非同期ワーク」で働いています。 非同期ワークというのは同期的な集まりを持たずに仕事を進めることで、例えば朝会のような定例は極力開かれません。microCMSはエンジニアの比率が高いため、エンジニアが集中して作業できる時間を増やす目的で非同期ワークが導入されました。
非同期ワークを始める前は不安もありましたが、実際にやってみるとSlackやNotionで事足りることも多いです。ミーティングが減り作業時間が増えるのもうれしいですが、それに加えて会話の質もあがっていると感じます。大人数の場での発言が苦手、内容を調べてから正確に回答したいなど、ミーティング中では拾えなかったメンバーの意見が出やすくなったためだと思います。
一方で、非同期ワークの難しさも実感しています。
正しく仕様が伝わらず勘違いのまま進んだり、芯を食わない会話のラリーが続いたり、テキストが冷たい印象になったり。人間同士が仕事をしているので完璧に情報を伝えるのはとても難しいことです。そして情報のやりとりに失敗すると、仕事はうまく進みません。
約1年半の非同期ワークのなかで、「正しく伝える」ための自分なりのポイントが見えてきました。このnoteではそれを整理してみます。
前提: 認識が揃わない = 開発が停滞する
認識の齟齬が起きると、それを補うために会話のラリーが発生します。相手からの返信を待つ時間も含めると、メッセージの往復はかなり時間がかかります。そして結論が出るまでに時間がかかれば、それはそのままユーザーに価値が届くのが遅れることを意味します。
もっと悪いケースもあります。仕様を勘違いしたままタスクが進み、プロジェクトの中盤や終盤で発見される場合です。設計・開発の工数が無駄になることはもちろん、チームとしても徒労感を覚えます。
「正しく伝わる」コミュニケーションができれば、プロダクト開発の摩擦を減らし、ユーザーへの価値提供を早くできると言えそうです。
どういうテキストが伝わりやすいか？
では本題です。伝わるメッセージにするために、何に気をつければよいでしょうか？
1. 結論やお願いごとを冒頭に書く
ブログやメールでもそうですが、結論から書きましょう。
例えば技術仕様について確認する場合、次のように書きます。
おつかれさまです！
◯◯のタスクについて、技術仕様の認識があっているか確認したいです。
いま◯◯の改修を進めてもらってると思うんですが、以下の3点が認識合ってるか確認したいです：
1. 〜〜〜〜
2. 〜〜〜〜
3. 〜〜〜〜
こちらお手隙でご確認・コメントいただければと思います。よろしくおねがいします。
メッセージの冒頭で「どのタスクの話か」と「何を依頼する内容なのか」を明確にしています。
この構成にしておくと、読み手は「このタスクについての、技術仕様の確認なんだな」と頭の中に先に箱を用意できます。文章を読みながら意図を理解する必要がないので、主題である確認内容の理解に脳のリソースを多く割けるはずです。
コミュニケーションにもパターンがあり、「シェア」「質問」「確認」など種類があります。「【シェア】今週金曜日、勉強会やります！」と先頭にラベルをつけるだけでも読み手の理解を助けられるでしょう。
2. スレッドに途中から人を呼ぶ時はサマリーを添える
例えばエンジニアから仕様の質問が来て、Slackで議論をしていく中でスレッドが伸びることがあります。その議論を経て最終的に仕様変更が決まり、そのデザインをデザインチームに依頼するケースを思い浮かべてください。
このとき、「↑これお願いします！」のように急にデザイナーさんを召喚するのは厳禁です。
もちろんスレッドを読めば内容は理解できますが、発散と収束が入り混じった議論を追っていくのはかなりストレスです。議論の内容を取り違えるかもしれません。その議論を進めていた人（自分）が内容を一番わかってるはずですから、サマリーを添えて次のように書きましょう。
@design-team
おつかれさまです！デザイン相談です。
以前から進めていた◯◯の改修ですが、エンジニアチームから◯◯の機能がユーザーに伝わりにくいのではないか、と相談してもらっています。
話し合って、以下の3パターンがありそうです。
1. ボタンのラベルの表記を◯◯に変更する
2. ボタンの位置を◯◯に変更し、他のボタンと色を揃える
3. 今回のリリースではこのままリリースして様子を見る
自分としては〜〜という理由から2が良いかと思ってるんですが、デザインチームから見てどうでしょうか？
もし2で問題なければ、Figmaの更新をお願いしたいです！
（議論の詳細はSlackのスレッドにあります）
このように書いておけば、このメッセージを見るだけで全体像を把握できます。議論の変遷を知りたい人はスレッドを遡ることになりますが、その場合も頭の中に箱ができているので読み進めるのが楽でしょう。また、デザイナーさんが他の人と会話するときも、このメッセージのURLをシェアすれば伝わるのでお手軽です。
議論が白熱してスレッドが伸びることはよくあることです。サマリーを添えるのは細かい改善ですが、チーム全体の認知負荷を減らせていると思っています。
（この例では決まった後にデザイナーチームに声かけしてますが、もちろん内容によっては最初から議論に入ってもらったほうが良い場合もあります。）
3. 箇条書きには番号をつける
箇条書きは文章を構造化できる良い方法ですが、もう一段上があります。それが「番号付き」にすることです。
これまでの例でも登場しましたが、例えば以下です。
1. ボタンのラベルの表記を◯◯に変更する
2. ボタンの位置を◯◯に変更し、他のボタンと色を揃える
3. 今回のリリースではこのままリリースして様子を見る
箇条書きの先頭が「・（なかぐろ）」ではなく、番号になっています。これの何が良いのでしょうか？
まずは、「1についてですが、これは〜〜」のようにテキストで引用してもらいやすくなります。会話するときに対象のトピックを勘違いすると不幸な結果になります。番号をつけることで議論の対象が明確になり、ズレが起きづらくなります。
また、同期的に話すときも便利です。Slack上で議論がまとまらなければオンラインで集まって話していますが、そこで「1は〜〜だよね。2は・・」のように番号を使ってコンパクトに会話を進められるのもメリットです。
4. 画像で強調する
長文がドーンと投下されると、読んで内容を理解するのにも一苦労です。画面上の要素を説明するときは、画像を添えると直感的に伝えることができるでしょう。
例えばnoteのシェアボタンについて話したいとき、以下のような画像をメッセージに添えます。
「PC版の記事詳細を閲覧した時に、タイトルの右下に出るボタン群」と書くよりも遥かに伝わるはずです。
同様に、バグの再現手順などが複雑な場合は動画を撮ります。再現手順や前提条件が伝わっていないと確認ラリーが増えますが、動画なら不具合の内容を確実に表現することができます。
5. 画像だけに頼らず、テキストでも書く
画像は視覚的に理解できて便利ですが、画像に依存したメッセージは避けるべきです。
画像を使うときは必ずテキストも添えるようにしています。アクセシビリティと検索性を担保するためです。画像だけでやり取りしてると後からメッセージを探しづらくて苦労することになります。
例えば上記の画像なら「PC版の記事詳細を閲覧した時に、タイトルの右下に出るボタン群（画像のハイライトの場所です）」のようなテキストをあわせて投稿します。
バグの再現手順の動画であれば、「1. アカウントを作成する」「2. 記事を書く」のように、バグの再現ステップをテキストで添えます。
画像・動画に毎回テキストを添えるのは手間ではありますが、正確に伝え、後から振り返りやすくなるのでメリットの方が大きいです。
6. 第三者の目を意識して文脈を「ひらく」
特定のメンバー宛にメッセージを書くときがあります。二人の間には高いコンテキストが共有されていても、あえて前提から書きましょう。
ダメな例:
さっきのミーティングで話した件ですが、Aパターンでいきましょう！
良い例:
先ほどの◯◯についてのミーティングで、画面表示をどうすべきかが宿題になってたと思います。
↓この3択がありました
A. 〜〜〜
B. 〜〜〜
C. 〜〜〜
時間をつくって考えたところ、〜〜〜という理由からAパターンでいきたいと思います。不明点あれば聞いてください。よろしくお願いします！
良い例では前提、選択肢、意思決定の理由が書かれています。
このように書くと何が良いでしょうか？
ひとつは認識の齟齬を減らせます。宿題の内容を勘違いしている、別のミーティングの話と勘違いするなど、認識齟齬はどこで生まれるかわかりません。前提を含めて共有することで、コミュニケーションのすれ違いを防げます。
もうひとつは、周りからコメントをもらいやすくなります。ダメな例の方では「Aパターンで！」と言ってるだけで、このメッセージを見ても何が決まったのか把握できません。前提や決定までのプロセスを「ひらく」ことで、第三者からフィードバックもらえる可能性を高めています。
実際、他のチームのメンバーから「その話なんですが、実は…」とコメントをもらうことも多々あります。別の良いアイデアが提案されたり、もらった質問に答えることで意図が明確になったり、フィードバックは良いことづくめです。
非同期コミュニケーションはミーティングよりもオープンで、誰でも参加できます。そのメリットを最大限活かすため、できるだけ文脈はひらきましょう。
7. シェアはしすぎるくらいで良い
何か決まったことをシェアするとき、Slackのいろんなチャンネルに書くのはGoodだとしています。
インターネット上では「マルチポスト」と言われて敬遠されることもありますが、仕事においては逆。知ってもらうためには、何度も同じ情報をシェアしてOKです。各チャンネルで入っているメンバーが被っていても、気にせず投稿します。決定事項に関連があると思うチャンネルには積極的にマルチポストしましょう。
おわりに
テキストコミュニケーションを円滑にするために普段意識していることを整理してみました。会話自体は重要だと思っていて、私が避けたいのは無駄なすれ違いです。摩擦はできるだけ減らして、本質的な時間を増やせればと思っています。
「他人に正しく伝える」というのは非常に難しく、永遠のテーマです。もしみなさんのテクニックがあればぜひ教えてください。
最後までお読みいただきありがとうございました！