check-communication

コミュニケーションレビュー

送信前にメッセージの下書きをレビューします。目指すのは、明確で、思いやりがあり、読み手に合わせた、必要な長さだけのメッセージです。修正版と、具体的なメモを2～3件出力します。

ワークフロー

0. トーンを調整する

書き直す前に、チャネル、相手との関係、重要度、コミュニケーションの目的を推測します。デフォルトは温かく率直です。明確かつ簡潔でありながら、人間味も保ちます。

フィードバック、意見の相違、謝罪、パフォーマンス、対立、失望、力関係、または冷淡・ぞんざいに受け取られる可能性のある内容には、共感的なトーンを使います。

トーンや重要度が曖昧で、推測によって書き直しの内容が大きく変わる場合に限り、構造化された質問ツールを使います。質問は1つにします。

どのようなトーンにしたいですか？

選択肢：

トーンの種類	使用する場面
温かく率直	多くの同僚やチームへのメッセージのデフォルト。明確で丁寧、過度に柔らかくしない
共感的	繊細な内容、対人関係、対立、フィードバック、謝罪、感情の強いメッセージ
経営層向けに簡潔	要点をすばやく把握する必要がある、多忙な読み手向けの意思決定に関する報告
詳細だが読みやすい	読み手に背景情報が必要だが、メッセージが長文にならないようにしたい場合

出力のトーンが、下書きから推測された場合でも、ユーザーが選択した場合でも、そのトーンが決まった時点で完了です。

6つのチェック項目

すべてのコミュニケーションで、6つの項目すべてを確認します。

完了条件：検出したメッセージの種類、選択したトーン、送信できる修正版、影響の大きい変更点を説明するメモ2～3件を出力に含めます。情報共有以外のメッセージでは、依頼内容または読み手に求めるアクションを明確にします。

1. 明確さ — 最初の一文で要点が伝わるか？

読み手がメッセージの目的を理解するまでに第3段落まで読む必要があるなら、書き直します。依頼や背景は冒頭に置きます。

悪い例：背景を3段落説明 →「ところで、これを確認してもらえますか？」 良い例：「金曜日までに認証PRをレビューしてもらえますか？背景は以下のとおりです。」

2. トーン — チャネル、相手との関係、重要度に合っているか？

チャネル	適切な文体
SlackのDM（同僚）	カジュアルで温かく率直。略語も問題ありません
Slackの公開チャンネル	ややフォーマルにし、後から読む人にも背景が伝わるようにします
メール（社内）	プロフェッショナルで、堅苦しくしすぎません
メール（社外・顧客向け）	フォーマルで親切にし、専門用語は避けます
PRコメント	技術的かつ事実に基づき、受け身の攻撃性を含めません
パフォーマンスに関するフィードバック	共感的で、具体的かつ根拠に基づき、今後の改善につながる内容にします

注意すべき点：テキストでは伝わらない皮肉、受け身の攻撃性と受け取られる曖昧な言い回し、技術に詳しくない関係者への専門用語の使用、または対人関係上の配慮が必要な場面で冷淡に受け取られる率直さ。

3. アクション — 読み手に何をしてほしいか？

曖昧：「意見を聞かせてください。」 明確：「水曜日までに承認してもらえますか？それが難しい場合は、火曜日の営業終了時までに懸念点を知らせてください。」

情報共有のみのメッセージでない限り、読み手に求める対応を明確にします。純粋な情報提供の場合も、そのことがはっきり伝わるようにします。

4. 長さ — 30％削れますか？

多くの場合、削れます。以下を取り除きます。

• 読み手がすでに知っている背景
• メッセージを送ること自体への謝罪（「お忙しいところすみませんが……」）
• 意味を加えない限定表現（「少しだけ手短にお伝えしたいのですが……」）
• CCに入れる必要のない人

5. 背景 — 読み手が行動するのに十分な情報があるか？

読み手の立場で確認します。追加の質問をしなくても返答したり、行動したりできますか？できない場合は、不足している情報を加えます。

6. 関係性 — メッセージは仕事上の信頼関係を保てるか？

フィードバック、対立、謝罪、失望、力関係の不均衡がある場合は、依頼を弱めずに、関連する努力や影響を認めます。読み手が不必要に軽んじられたり、責められたり、驚かされたりせずに行動できる状態になれば完了です。

メッセージの種類を自動判定する

評価する前に、内容からメッセージの種類を特定します。

種類	判断材料
ステータス更新	進捗に関する表現、スケジュールへの言及、障害
スタンドアップ	短く、日次の進捗報告、「何をしたか／これから何をするか」
提案／RFC	変更を提案し、承認を求め、選択肢を提示している
PR レビューコメント	コードへの言及、レビューの表現、提案
意見の相違	相手の立場への反論、懸念の表明
Slack メッセージ	カジュアルな口調、非同期コミュニケーション
メール／正式文書	宛先、件名に似た構成、正式な口調

判定した種類を明示してから、以下の種類別チェックを6つの基本チェックに加えて適用します。

種類別チェック

ステータス更新 → STATUS フレームワーク：

• 状態（順調／リスクあり／ブロック中）
• 目標（成果物と期限）
• 達成事項（作業内容ではなく影響。「キャッシュに取り組んだ」ではなく「レイテンシを40％削減」）
• 脅威（問題が起きる可能性）
• ブロック解除（他の人に必要なこと）

提案／RFC → 提案の構成：

• 実際のデータに基づいて問題を説明している（漠然とした不満ではない）
• トレードオフを明示している。メリットとデメリットの両方を挙げている（メリットだけでは信頼を損ないます）
• 検討した代替案と、採用しなかった理由が示されている
• ロールバック計画がある
• 「未解決の質問」セクションで決定事項を明確にしている（何も書かれていないと、読み手は何に反応すべきかわかりません）

PR レビューコメント：

• nit:／suggestion:／question:／issue:／thought: の接頭辞を使っている
• ブロッカーについては、変更内容だけでなく理由も説明している
• 作者を見下した気持ちにさせない。批判ではなく、説明する

意見の相違／反論：

• 相手の立場を好意的に言い換えてから反論しているか（スティールマン）
• 「私対あなた」ではなく、「私たち対問題」という構図になっているか
• 懸念を述べる前に、相手の意見に妥当な点があることを認めているか
• 注意する表現：「前にも説明しましたが……」など、防御的な言い回し

Slack の非同期コミュニケーション：

• スレッドのルール：3回以上のやり取りが必要になりそうなら、通話を提案する
• 媒体に合った長さにする。Slack はメールではありません

よくある問題

• 依頼が埋もれている：背景 → 背景 → 背景 → 15行目でようやく依頼。依頼を1行目に移し、背景はその後に置きます。
• 「前回のメールにも書きましたが……」：ほぼ確実に、嫌味に受け取られます。言い換えるか削除します。
• 次のステップが曖昧：「ご連絡ください」だけでは、具体的な行動がわかりません。何を、いつまでに、誰から必要としているのかを明確にします。
• 技術に詳しくない読み手への専門用語：必ず指摘し、わかりやすく言い換えます。
• 謝罪から始める：「お忙しいところすみません」はメッセージを弱めます。削除します。
• 不意打ちのリスク：グループで共有した際に関係者が驚くような内容であれば、指摘します。

出力形式

最初に判定した種類とトーンを示し、次に修正版、最後に2～3点のメモを記載します。

Detected type: [type]
Tone mode: [Warm direct / Empathetic / Executive concise / Detailed but readable]

[Revised message]

---
What's landing well: [1-2 specific strengths]

What to tighten:
- [What changed and why — specific, with a concrete rewrite if needed]
- [max 2-3 issues]

下書きに大きな問題がなければ、その旨を簡潔に伝え、1～2点の小さな修正だけを挙げます。終始、同僚として成功を願う、対等な口調で対応します。審査員のような口調にはしません。