written-communication について
エンジニアリングマネージャー向けの文書コミュニケーションスキルです。相手に応じた明確な文章の作成や、誤解、高い影響を伴う告知への対応を支援します。
主な機能
- 01相手に応じたメッセージ設計
- 02簡潔な文章作成フレームワーク
- 03重要な告知の作成ガイド
- 04未読メッセージへの対処法
- 05コミュニケーションのずれを診断するモデル
活用シーン
- 01チームや関係者へのメッセージ作成
- 02慎重さを要するポリシー告知の準備
- 03Slack の見落とされたメッセージへの対応
- 04誤解されたメッセージの修正
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/written-communicationを入力して読み込まれたか確認します。
同梱ファイルreferences/sources.md
詳細
文書でのコミュニケーション
始める前に
まず EM のコンテキストを確認してください。.agents/em-context.md が存在する場合は、内容を読んでください。人物について言及されている場合は、.agents/reports/[name].md を確認してください。
.agents/em-context.md が存在しない場合は、詳しいアドバイスをする前に、まず必要最小限のマネージャープロフィールを尋ね、保存してください。プロフィールには、役職、チームの人数、チームのミッションまたは担当領域、現在の課題または優先事項を含めます。
特定の人物が会話の中心であり、.agents/reports/[name].md が存在しない場合は、詳しいアドバイスをする前に、その人物について必要最小限のプロフィールを尋ね、保存してください。プロフィールには、役職／レベル、在籍期間、強み、現在の課題または成長領域を含めます。
会話の中で後から長期的に有用な新しいコンテキストが明らかになった場合は、.agents/em-context.md または .agents/reports/[name].md を自動的に更新してください。推測、一時的な苛立ち、未解決の解釈ではなく、安定した事実やパターンを保存してください。
応答スタイル
最初の回答は簡潔で役に立つものにしてください。ユーザーが詳しい説明を求めていない限り、フレームワーク全体を一度に提示しないでください。
基本方針：
- 可能性の高い診断または推奨事項を最初に述べる
- 不足しているコンテキストによって助言が変わる場合に限り、焦点を絞った質問を最大 2～3 件する
- 次に取るべき具体的な行動を示し、役に立つ場合はマネージャーが使える正確な文面も提示する
- 関連するフレームワークに簡単に触れるが、すべての要素を説明しない
- 直接的な回答の後でのみ、より詳しい説明を提案する
このスキルの使い方
- メッセージの作成や下書きが必要な場合 → 3 ステップフレームワーク
- 重大な影響を伴う発表や慎重な扱いが必要な方針変更の場合 → 重大な局面での対応
- 異なる対象者（エンジニア、ステークホルダー、リーダー層）向けに書く場合 → 3 ステップフレームワーク → ステップ 1：準備
- Slack で未読メッセージを指摘されている場合（「前にも言ったように……」など） → 非同期の再説明の落とし穴
- 意図したとおりにメッセージが理解されなかった場合 → 圧縮／展開モデル
デフォルトの応答形式
文書でのコミュニケーションを支援する場合は、実際のメッセージ案を作成してください。
- 意図： メッセージで達成すること。
- 対象者に合わせた調整： 対象者が知っていること、懸念していること、必要としていること。
- 下書き： 簡潔で率直、そのまま送信できる内容。
- 効果の理由： 構成や表現についての短い説明。
- リスクの確認： 誤解される可能性のある点と、そのリスクを減らす方法。
ユーザーが文面を求めている場合は、説明より先に下書きを提示してください。
3 ステップフレームワーク
機械向けのコードを書く場合は、言語、バージョン、ライブラリが分かっているため、予測がつきます。一方、人向けの文章ではそうはいきません。同じメッセージでも、読む人によって受け取られ方はまったく異なります。このフレームワークは、その差を縮めます。
ステップ 1：準備
一語も書き始める前に、次の 3 つの質問に答えてください。
なぜ書くのですか？ 何がきっかけで、このメッセージを書くのでしょうか。重要であれば、その理由をメッセージに含めてください。また、苛立っているときに書こうとしているなら、いったん止めてください。ほとんどのメッセージの目的は議論に勝つことではなく、結果を得ることです。自分の意図を理解すると、メッセージを書き直すことになる場合もよくあります。
何を達成したいのですか？ 具体的にしてください。「チームに新しいデプロイルールを守ってもらいたい」は目標です。「デプロイについて伝えたい」は目標ではありません。目標を明確に言えないなら、そのメッセージには目標がありません。
対象者は誰ですか？ グループによって、必要な語彙や説明の詳しさは異なります。
- エンジニア — 適切な技術的詳細を含め、対象分野のコンテキストを理解しているものとします
- ビジネスステークホルダー — 相手にとって重要な点を説明し、専門用語を避けます
- サポートチーム — あらゆる状況と例外ケースを知りたいと考えています
- 同僚のマネージャー — ほとんどのコンテキストを共有しているため、簡潔に伝えます
対象者についてよく知るほど、誤解が起きる前に予測しやすくなります。
ステップ 2：簡潔に書く
話すときのように書きましょう。簡単な言葉でも、複雑な言葉と同じ意味を伝えられますし、読み手の認知負荷も軽くなります。複雑な文は知性の表れではありません。推敲が足りないことの表れです。
役立つ具体的なルール：
- 能動態を使う。「本番環境が更新されました」ではなく、「本番環境に反映しました」と書きます。
- **最も重要なことを先に書く。**要点を後回しにしないでください。
- **長い文章のかたまりを避ける。**段落を分け、各段落を 3～4 文にします。
- **流し読みしやすい構成にする。**長い場合は、見出しや箇条書きを使います。
ステップ 3：余計な言葉を削る
送信する前に、情報を増やさない言葉をすべて削りましょう。短いメッセージは読まれます。長いメッセージは流し読みされたり、誤読されたり、無視されたりします。
例：
「プルリクエストをマージする現在のルールを変更します。変更をマージするには、これまでの 2 件ではなく、最低 1 件の承認が必要になります。皆さんを信頼していますし、作業をもう少し速く進めたいからです。」
余計な言葉を削ると：
「プルリクエストをマージするルールを変更します。2 件ではなく、1 件の承認が必要です。皆さんを信頼していますし、もっと速く進めたいからです。」
伝えている内容は同じです。余計な負担が減っています。
影響が大きい場合
方針変更、チームの再編、伝えにくいお知らせなど、重大な影響を伴うメッセージは、送る前に対象読者の一人に読んでもらいましょう。誤解が広がる前に気づけます。
完璧を目指さないでください。明確でタイムリーなメッセージは、遅れて届く完璧なメッセージより優れています。
非同期の再説明で陥りやすい罠
Slack で最も人間関係を損なうのは、文法の誤りや長文ではありません。以前のメッセージを見落とした相手に、「すでに言いましたが」「上に明確に書きました」「先週説明しました」と指摘することです。
相手は恥をかかされたと感じます。何度も繰り返されると、仕事上の関係が損なわれます。根本には、誤った思い込みがあります。自分が何かを明確に書いたのだから、相手も同じように読んで理解したはずだ、という思い込みです。
考え方を改めるには、相手には自分の 10 倍の進行中のスレッドがあると想定します。そう考えると、相手の見落としは不注意ではなく、起こり得ることとして捉えられます。さらに、最初から簡潔で文脈のそろったメッセージを書くようになり、見落としがあっても公の場で訂正するのではなく、辛抱強く対応できるようになります。
メッセージの見落としが常態化して組織的な問題になった場合は、スレッド内ではなく、本人に直接、個別に伝えてください。
圧縮と展開のモデル
あらゆるコミュニケーションには情報の損失があります。話し手は、豊かな内面の経験や技術的な文脈を、伝達できる言葉に圧縮します。聞き手は、自分自身の視点を通してそれを展開します。受け取ったメッセージが、送ったメッセージと完全に同じになることはありません。
ここから、2 つの失敗パターンが生まれます。
- **圧縮しすぎる：**文脈が足りず、相手が空白を誤って補う
- **説明しすぎる：**わかりやすさのピークを越えると、詳細を増やすほどノイズが加わり、かえって理解しにくくなる
圧縮のスキルとは、最も完全な説明ではなく、特定の相手に確実に「なるほど」と思ってもらうための最小限の言葉を見つけることです。フィードバック、技術提案、関係者への進捗報告にも当てはまります。
展開のスキルとは、相手の言葉を自分の期待どおりに解釈するのではなく、実際に何を意味していたのかを積極的に受け取ろうとすることです。理解したという確信が強いほど、実は誤解している可能性も高くなります。
認識をすり合わせる方法として、メッセージを伝えた後、相手にどう受け取ったかを言い返してもらいましょう。こちらの意図と相手の要約のずれが、圧縮による誤差です。技術系のマネージャーは、この点が苦手なことがよくあります。コードでの正確さが、コミュニケーションの正確さにつながるとは限りません。
さらに詳しく
このスキルで扱うフレームワークの由来や、トピックについて詳しい背景を知りたい場合は、references/sources.md を読んでください。
関連スキル
feedback— 書面および口頭でフィードバックを伝えるための具体的な原則managing-yourself— シニアリーダーとのコミュニケーションを円滑に進める方法working-with-pm— ステークホルダーとのコミュニケーションは、PM と EM の関係の中心ですinfluence— 組織内で影響力を築くためのツールとしての書面でのコミュニケーション