これまで「伝える」ということについて自分が学んだことをまとめた
すべてできているわけではないし、これが 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
