ひびのログ

日々ではないけどログを出力していくブログ

メッセージを伝えるときのポイント

これまで「伝える」ということについて自分が学んだことをまとめた

すべてできているわけではないし、これが 100% あっているというわけではないし、メッセージの種類によってもポイントは違ってくる

不足しているものがあるはずなので追記していきたい

ポイントだけを箇条書きでまとめたので、この記事を読むだけでは不十分であることが多い 実際に「このポイントを達成するには?」と考えてググることが必要

ポイント一覧

メッセージの内容を考えるときのポイント

大項目は具体度によって分類している(メッセージを書くときのルール、メッセージを構成するときのテクニック、などの部分) 上の方の大項目ほど具体的な話で、下の方の大項目ほど重要度が高い(「メッセージが何かを考えるテクニック」がこの中では一番重要(上の方も大切ではある))

メッセージを書くときのルール

実際に文章を書くときはこういう記述にすべき

言葉の選び方

  • 助詞・助動詞を適切に使用し、主語・述語・修飾語などが明確になるように記述する
  • ですます調とだである調を混ぜない
  • 接続詞は必要なときだけ使う
  • 書き言葉を使用する
  • 否定表現はすんなり理解できる範囲に留める(NG 例:二重否定)
  • 表記を統一する
  • 用語集を付属する
  • 時間によって意味が変化しない単語を選ぶ(日付等)
  • 体言止めしない

文章の構成

  • 一文には一つの意味だけ入れる
  • 一文を長くしない(目安は 50 字以内)
  • 文書のタイトルで目的を伝える
  • 句読点を適切に使用する
  • 重要な内容を最初に書く
  • 状況説明ではなく、行動を書く
  • 要素ごとにブロック化する
  • 箇条書きだけ箇条書きにする
    • 普通のテキストは箇条書きにしない

メッセージを構成するときのテクニック

実際に書く文章を構成するときにはこうするといい

  • 理解に必要な情報を入れる
  • 関係ない情報は入れない
  • 具体的に情報を入れる
  • 相手が知らない事柄は説明する・独自の言い回しは避ける
  • 最初に何について話すのかを伝える
  • 初めの方に結論をまとめて書く
  • 言葉では分かりづらいものは、図・表を使う
  • Next Action を入れる
  • 抽象的で伝わりづらいものは、具体例を提示する
  • 比喩を利用する

メッセージをまとめるテクニック

文章を書く前の整理に使うといい

  • 5 W 2 H を盛り込む
  • 論理の流れを整える
    • PREP, SDS, CRF, DESC, TAPS など
  • 定量的な指標を軸にする
  • 組み合わせを考えるときは表を使う
  • メッセージを一文に要約する
  • 自分の内にある言葉を、箇条書きで書き出してみる

メッセージが何かを考えるテクニック

そもそも何を文章にする必要があるのか

  • 伝えること自体の目的を決める
    • 相談内容の共有、決議事項の説明、報告内容の説明
  • 伝える相手を決定する
  • 理想状態(ゴール)を定める
  • 現状を把握する
  • 事実と推測・解釈を区別する
  • 関連する事柄を洗い出す
  • 具体的・細かい情報に分解する

技術的な質問

NG 例

開発環境が動かなくなったんですけど、ご存じの方いますか?

何が NG なのか

  • 「開発環境」ってなに?
    • ローカルのサーバー? エディター? PC 自体?
  • 「動かなくなった」ってどういう状況?
    • ビルドできない? 開発用サーバーが起動しない? PC が起動しない?
  • 何を「ご存じ」か聞いているの?
    • 解決方法? 原因? 同じことが起こった人がいるか確認?
    • この場合は解決方法を聞いてるんだと思う
  • 解決に必要な情報が一切ない
    • 「何をやって」「何が起こって」「どうなっているのか」「何が原因だと思っているのか」

どう考えればいいのか

「何を伝えるのか」の決定

メッセージを伝える目的を決める → 今回は「相談」 ゴールを決める → 開発環境が動く状態にする 「開発環境が動かない」を細かく具体的に捉える → エラーメッセージ・ログ・ブランチ などを見る

相談内容をまとめる

やったこと

5 W 2 H を洗い出す 日本語で「いつ誰がどこでなぜ何をどのようにどれくらいした」というまとめ方のほうがやりやすそう

  • いつ:ついさっき(最新のコード)
  • 誰が:自分が
  • どこで:ローカル開発環境で
  • なぜ:開発したくて
  • 何を:ローカルサーバーを
  • どのように:起動しようとコマンドを実行
  • どれくらい:(今回はなし)
結果どうなったか

事実として

  • コンパイルエラーが発生した
  • ローカルサーバーが起動しない
  • ログとエラーメッセージが出ている
  • エラーメッセージに「◯◯ファイル」と書いてある

推測として

  • ◯◯ファイルにエラーの原因がある
  • 先週変更されているのでこれが原因っぽい

文章を組み立てる

↑ で洗い出した内容を組み合わせて、あとは文章として読めるようによしなに

OK 例

@ エンジニアの皆さん
最新のコードでローカルサーバーの起動コマンドを実行したら、コンパイルエラーが発生してサーバーが起動しません。
◯◯ファイルの変更が原因だと思うのですが、心当たりある方いらっしゃいますか?
開発に影響が出るので revert などの対応をお願いします。

コマンド実行時のログはこちらです。
:
:

実際にはある程度のコンテキストが共有できているので、もうちょっと省略しても問題なさそう

@ エンジニア
最新のコードでローカルサーバーを起動したら、コンパイルエラーが発生します。
◯◯ファイルの変更が原因みたいですがどなたかわかりますか?

コマンド実行時のログ
:
:

作業指示待ち

NG 例

今の作業が終わったんですがどうすればいいですか?

何が NG なのか

  • 「今の作業」って何?
    • 相手は覚えてない可能性が高い
    • 作業の順番が重要なことも多い
  • 自分で考えた形跡がない
    • 相手からはこう見える可能性がある
    • 「どうすればいいですか」というのは、質問される側にすべてを任せている
      • もちろん場合による

どう考えればいいのか

「何を伝えるのか」の決定

目的は「作業が終わったことの報告」「次にやるべきことが知りたい」 これらの達成がゴールとなる

2 つの目的があるので、2 つに分けて考える

メッセージの内容を考える

まずは「作業が終わったことの報告」から

  • When:今
  • Where:(なし)
  • Who:自分(作業者)
  • What:着手していた◯◯という作業
  • Why:(なし)
  • How:終わった

「次にやるべきことが知りたい」について 以下を疑問文にすればいい

  • When:このあと
  • Where:(なし)
  • Who:自分(作業者)
  • What:いずれかの作業
  • Why:手持ちの作業がないから
  • How:着手する

文章を組み立てる

まずは 2 文で書いてブラッシュアップする

今自分が着手していた〇〇という作業が終わった
このあと手持ちの作業がないからいずれかの作業に着手したいが、どれがいいか?

「◯◯という作業」が相手に伝わるか検討する 例えば「ユーザー管理処理のリファクタ」では詳細が伝わらないので、「src/modules/users.ts で行なっているユーザー作成処理のリファクタ」などある程度具体化する

OK 例

◯◯という作業が終わったんですが、バックログの上にある☓☓という作業を進めていいですか?
◯◯という作業が終わったら、依存している☓☓という作業に着手していいですか?

他のポイント

「メッセージを伝える」からはスコープがずれるけど、大切なポイント

コミュニケーションに関する考え方

コミュニケーションをうまくとるには

  • 相手の立場に立って考える
  • 相手は人間である
  • 相手に伝えたことしか相手に伝わらない
  • 知識やバックグラウンドは千差万別
  • 人間には限られた時間しかない
  • 自分のことを一番考えるべきなのは自分

テキストの確認に使えるテクニック

メッセージを書いたあとに、それが相手に伝わるかどうかを確認する

  • 時間をおいて見直す
  • レビューしてもらう
  • 声に出して読んでみる
  • 「本当にそれでいいのか」を常に問いかける

補足

深堀りのためのキーワード

  • ロジカルシンキング
  • テクニカルライティング
  • ロジックツリー
  • MECE
  • なぜなぜ分析
  • As-Is / To-Be

参考文献

事例