writing-internal-comms

社内コミュニケーションの作成

概要

社内コミュニケーションがうまくいかない原因は、大きく2つあります。長すぎて読まれないか、曖昧すぎて役に立たないかです。どちらも原因は同じです。読者が判断するために必要なことではなく、書き手が知っていることを書いてしまうのです。

基本原則： 結論から伝えましょう。読者は最初の一文で要点を把握でき、続きを読むのは補足情報を得るためだけであるべきです。

鉄則

NO INTERNAL COMMS WITHOUT GATHERING THE FACTS FIRST

記憶を頼りにまとめた最新情報には、曖昧な表現がつきものです。書き始める前に、コミット、チケット、スレッド、指標、ドキュメントなどから実際の状況を確認してください。曖昧なコミュニケーションの原因は、文章の出来が悪いことではなく、ほとんどの場合、事前調査が不十分なことです。

事実が本当に確認できない場合は、ユーザーに情報を尋ねてください。「大きな進展がありました」のような言葉で不足を取り繕わないでください。

チェックリスト

1. 種類を特定する — 以下のガイドラインファイルを参照します
2. 読者と、その人が下す判断を特定する — 誰が読み、その後どのような行動を取るのかを確認します
3. 事実を集める — 日付や数値を含む、実際の情報源から集めます
4. 形式に沿って下書きする — ガイドラインファイルの構成に厳密に従います
5. 簡潔さを確認する — 以下を参照してください
6. トーンを確認する — 特に問題、インシデント、人に関する内容は注意します

振り分け

依頼	ファイル
チームまたは全社向けの週次／隔週アップデート	examples/3p-updates.md
全社向けニュースレター	examples/company-newsletter.md
よくある質問への回答	examples/faq-answers.md
その他 — お知らせ、インシデント、ポリシー、ローンチ	examples/general-comms.md

振り分け先のファイルを読み、その構成に従ってください。 読者が毎回同じ方法で内容を素早く把握できるように、これらの形式が用意されています。独自の構成を即興で作ると、その価値が損なわれます。

読者と判断

書き始める前に、両方に答えてください。答えられない場合は、確認してください。

誰が読むのか？ 読者の背景知識によって、あらゆる内容が決まります。

読んだことで何が変わるのか？ すべての社内コミュニケーションは、判断、行動、または認識の修正につながるべきです。どれにも当てはまらないなら、送る必要はありません。

読者	知りたいこと	知りたくないこと
経営幹部	成果、リスク、求められている対応	どのように構築したか、完了したチケット
他チーム	影響する変更点、時期、移行方法	内部での検討過程、チームのプロセス
自チーム	詳細、担当者、次のステップ	すでに把握している背景の繰り返し
全社員	自分たちにとっての重要性、必要な対応	チーム内の専門用語、組織の詳細

事実の収集

利用できる連携機能は環境によって異なります。使えると決めつけず、実際に接続されているものを確認してください。

情報源	確認する内容
Git／課題管理ツール	対象期間にリリースされたものと、その日付
Slack／Teams	活発なスレッド、チャンネル内で決まったこと
ドキュメント／Drive	最近編集された仕様書や意思決定記録
ダッシュボード	主張の規模を示す数値
カレンダー	定例以外の会議 — レビュー、インシデント、ローンチ

すべての主張に、数値、名称、または日付を添えてください。 「パフォーマンスが向上しました」では情報になりません。「p95 レイテンシが840msから210msに低下しました」なら情報になります。数値がない場合は、代わりに具体的に何が起きたのかを述べてください。

圧縮の工程

すべての草稿に実施してください。品質の大部分はここで決まります。

1. 前置きを削る。 「ご存じかもしれませんが……」「ご連絡してお伝えしたいことがあり……」「チームは懸命に取り組んできました……」――本当の最初の一文は、たいてい3文目です。
2. 結論を冒頭に移す。 結果が最後の段落にあるなら、置き場所が間違っています。
3. 程度を表す副詞を削る。 「とても」「本当に」「かなり」「大幅に」「相当に」は、文章を長くし、正確さを損ないます。
4. 曖昧な表現を、事実または明示した不明点に置き換える。 「まもなく準備できるはずです」→「木曜日に準備完了」または「日程は未定です。ベンダーの返答待ちで止まっています。」
5. 段落ごとにアイデアは1つ、文は最大3つにします。
6. 文章中の列挙は箇条書きに、文章中の比較は表にします。
7. 最初の一文だけを読んでみる。 要点が伝わりますか？ 伝わらないなら、書き直してください。

長さの目安： 3P アップデートは250語以内。幹部向けアップデートは200語以内。お知らせは300語以内。インシデントレポートは必要な長さで構いませんが、冒頭に100語以内の要約を付けてください。

問題について書く

間違えやすく、コミュニケーションが信頼を築くか損なうかを左右するセクションです。

• 最初の一文で問題を述べる。 問題を後回しにすると隠しているように見え、あとから問題に気づいた読者は、そのほかの内容も信頼しにくくなります。
• 大げさにせず、責任を認める。 「回帰を含む変更をリリースし、チェックアウトが40分間停止しました」――「一部のユーザーに問題が発生しました」ではありません。
• 失敗を受動態で書かない。 「過ちがあった」は、書いてはいけない表現の典型です。
• 人ではなく仕組みに原因を求める。 チェックの欠如、責任者の不明確さ、未テストの経路など、失敗を許した要因を明示します。個人を原因として名指ししてはいけません。
• 依頼事項を含める。 依頼のない問題提起は単なる不満です。「X が原因で作業が止まっています。木曜日までに Y の判断が必要です。」
• 影響と原因を分ける。 読者はまず影響を知る必要があります。原因はそのあとで構いません。

トーン

• 平易な断定文を使い、能動態で書きます。
• 会議の合間にスマートフォンで流し読みする人に向けて書きます。
• 企業的な婉曲表現は避けます。「適正規模化」「相乗効果」「学び」「改めて連絡する」「活用する」（動詞として）。
• 人工的に熱意を演出しません。感嘆符は、本当に喜ばしいときに一度だけ使います。
• 読んでくれたことにお礼を述べません。長さを謝るのではなく、短くします。
• 組織で使われている既存の文体に合わせます。過去のアップデートがあれば、参考にしてください。

セルフレビュー

• 最初の一文で要点が伝わる
• すべての主張に数字、名前、または日付がある
• 不確実な理由を明示せずに曖昧な表現を使っていない
• 問題を率直に、能動態で、依頼事項とともに述べている
• 種類ごとの長さの目安を超えていない
• 前提知識のない読者にも、何が変わり、なぜ重要なのかが伝わる
• 名前、日付、数字、リンクを記憶に頼らず確認している
• 意図した範囲を超えて、機密情報が公開されていない

よくある間違い

活動を成果として報告する。 「計画会議を6回開催した」は進捗ではありません。何をリリースし、何を決め、何が変わったのでしょうか？

要点を最後まで隠す。 読者は途中で読むのをやめます。常に結論を先に述べてください。

項目ごとの詳細度が一律。 大規模なローンチと依存関係の更新に、同じ3行を割いています。重要度に応じて記述量を調整してください。

見栄えが悪いという理由で問題を省く。 見栄えを悪くするのは、問題があとから明るみに出たときに備えて省くことです。

チケットのタイトルをそのままコピーする。 それは担当チーム向けに書かれています。この読者にとっての成果が伝わる表現にしてください。

すべての読者に同じアップデートを使い回す。 幹部向けの要約とチーム向けのアップデートは、同じ文書の長さ違いではなく、別の文書です。

キーワード

3P アップデート、社内ニュースレター、社内コミュニケーション、週次アップデート、状況報告、幹部向けアップデート、リーダーシップ向けアップデート、FAQ、インシデントレポート、ポストモーテム、お知らせ、社内コミュニケーション

関連スキル

• coauthoring-docs — アップデートではなく、仕様書、提案書、RFC などの本格的な文書向け
• verifying-before-completion — 何かをリリースした、またはテストに合格したと文章で述べる前に、実際にそうなったことを確認するためのスキル