---
name: internal-announcement
description: 社内の変更を知らせるメールや Slack の投稿を書く。結論を先に（BLUF）、何が変わり何が変わらないか、理由、時期、対象者、グループごとにだれが何をいつまでにするか、質問の窓口。規程、業務の流れ、ツール、組織、スケジュールの変更をチームに知らせたいとき、全社メール、Slack での告知、「みんなにどう伝えればいい？」と頼まれたときに使う。
---

# 社内の変更のお知らせ

このスキルの既定の前提: 多くの読み手は最初の2行しか読まず、そこで自分に関係があるかを決める。だからその2行に、変更とやることを書く。それより後ろは、詳しく知りたい人のためのもの。

## 使う場面

- 規程、業務の流れ、ツール、スケジュール、オフィス、組織が変わり、社員に知らせる必要があるとき。
- 変更についての全社メール、#general への投稿、マネージャーからチームへのメモを頼まれたとき。
- 変更の伝え方がまずく、わかりやすいフォローが必要なとき。
- 顧客や社外へのお知らせには使わない。顧客向けのお知らせかリリースのお知らせを使う。このスキルは社内の人に向けて書く。

## 用意するもの

- 何が変わるか、いつからか。どちらかがなければ一度だけ聞く。日付は推測しない。
- 対象者。はっきりしなければ全員向けの下書きにして、「[要確認: 対象者]」と付ける。
- 何を、いつまでにする必要があるか。何もなければ、冒頭に「対応は不要です」と書く。
- 質問の窓口: 人、チャンネル、説明会。なければ送り手にして、「[要確認: 窓口]」と付ける。
- 任意: 変更の理由、変わらないこと、規程全文へのリンク、伝える手段（メールか Slack）。

## 手順

1. **結論を先に書く。** BLUF（bottom line up front）は、最初の1〜2文に変更とやることを書くこと。NN/g の逆ピラミッドの指針も、ウェブの文章について同じことを言う。「記事は要点から始めるべき」。件名か最初の太字の行には、変更と日付を書く（「3月1日から、経費精算はマネーフォワード クラウド経費で」）。
2. **何が変わり、何が変わらないかを書く。** 変わることを具体的に2〜5個の箇条書きで。不安に思われそうなら、変わらないことを1〜2個足す（「承認の上限額は変わりません」）。
3. **理由を1〜3文で書く。** Prosci の ADKAR モデルは認知から始まる。人は変更を支持する前に、「なぜその変更が必要かを理解する」必要がある。本当の理由を書き、スローガンは書かない。
4. **時期を書く。** 始まる日、その前の締め切り、新旧どちらのやり方でもよい期間。「近日中」「来週」ではなく日付で。
5. **やることをグループごとに分ける。** グループによってやることが違うなら、グループごとに1行（「マネージャー: 2月26日までに未承認の申請を承認する」）。やることはどれも動詞で書き、日付を付ける。何もしなくてよいグループには、そう書く。
6. **質問の窓口を書く。** 人かチャンネルを1つ。その場で質問できる説明会があればそれも。このスキルの既定値: チャンネルだけでなく、人の名前を出す。
7. **伝える手段に合わせる。** このスキルの既定の長さ: メールは件名と、本文はおよそ500字まで、詳細へのリンクを付ける。Slack は太字の1行目、短い3〜8行、詳細へのリンク、スレッドで返信してもらうよう頼む一言。このスキルの既定値: 給与、職務、労働時間に関わる変更は、全体に知らせる前に、マネージャーが対象者に直接伝える。雇用条件に触れることには「[要確認: 日本の法令・就業規則]」と付ける。

## 出力の形式

```markdown
**件名:** [変更] — [始まる日]

[結論: 1〜2文。何が、いつ変わり、読み手が何をするか。なければ「対応は不要です」。]

**変わること**
- [具体的な変更]

**変わらないこと**
- [不安に思われそうなときだけ。なければ削る]

**理由**
[1〜3文]

**時期**
- [日付]: [起きること]

**お願いしたいこと**
- **[グループ]:** [日付]までに[動詞で書いたやること]
- **そのほかの方:** [やること、または「対応不要」]

**質問は** [人]か[チャンネル]へ。[説明会があれば]

[詳細へのリンク]
```

## 例

**入力:** 「全社（40名）に、経費精算を Excel からマネーフォワード クラウド経費に移すと知らせたい。3月1日（月）から。Excel の受付は2月26日（金）で終了し、それ以降は全部クラウド経費で。マネージャーは、チームの未承認の Excel の申請を2月26日までに承認すること。理由: 経理が毎月2日ほど領収書の回収に追われている。承認の上限額は変わらない。質問は経理の小林さんか #経理への質問 へ。2月24日（水）に小林さんが20分のデモをする。メールで」

**出力:**

```markdown
**件名:** 3月1日から、経費精算はマネーフォワード クラウド経費で

3月1日（月）から、経費はすべて Excel ではなくマネーフォワード クラウド経費で申請してください。マネージャーの方は、チームの未承認の Excel の申請を2月26日（金）までに承認してください。

**変わること**
- 経費と領収書は、クラウド経費で申請します。
- Excel での受付は2月26日で終了します。3月1日以降の経費は、クラウド経費でのみ受け付けます。

**変わらないこと**
- 承認の上限額。

**理由**
経理は毎月2日ほど、領収書の回収に追われています。クラウド経費に移すのは、この時間を減らすためです。

**時期**
- 2月24日（水）: 小林さんによる20分のデモ
- 2月26日（金）: Excel での受付を終了
- 3月1日（月）: クラウド経費のみ

**お願いしたいこと**
- **マネージャー:** チームの未承認の Excel の申請を、2月26日までに承認してください。
- **全員:** 3月1日以降の経費は、クラウド経費で申請してください。[要確認: クラウド経費のアカウントの受け取り方]

**質問は** 経理の小林さんか、#経理への質問 へ。2月24日のデモでも受け付けます。

[経費精算ガイドへのリンク]
```

## 送る前のチェック

- [ ] 最初の2文に、何が、いつ変わり、読み手が何をするか（または「対応は不要です」）を書いた。
- [ ] 日付はどれも実際の日付で、「近日中」「来週」がない。
- [ ] 対象のグループにはどれも、動詞で書いた締め切りつきのやることがあるか、何もしなくてよいと書いた。
- [ ] 質問の窓口として、名前のある人かチャンネルを1つ書いた。
- [ ] 理由を3文以内でわかりやすく書いた。
- [ ] 入力にないことを書いていない。未確定の点には「[要確認]」と付けた。

## よくある失敗

- 経緯から始める（「ご存じのとおり、これまで〜を検討してまいりました」）。読み手は変更にたどり着く前に読むのをやめる。
- マネージャーと社員でやることが違うのに、やることの一覧を1つにまとめる。
- 給与、職務、労働時間の変更を、対象者がマネージャーから聞く前に全社に知らせる。