---
name: decision-memo
description: Amazon のナラティブ形式で、短い意思決定メモを書く。最初に推奨案、次に背景、トレードオフつきの2〜4の選択肢、リスクと対策、決める人と期限を添えた依頼を、箇条書きのスライドではなく文章でまとめる。創業者、役員、チームに判断を求める必要があり、意思決定メモ、1枚の提案書、稟議の下書き、推奨案の文書、スライドに代わるナラティブ、「X を通すための説明を手伝って」を頼まれたときに使う。
---

# 意思決定メモ

意思決定メモの目的は、議論ではなく決定を得ること。Amazon はスライドでの発表をせず、ナラティブ形式の6ページのメモを書き、会議の最初に全員が黙って読む（ベゾス、2017年の株主への手紙）。このスキルの考えでは、箇条書きが隠すあいまいな考えを、文章は表に出す。このスキルのメモは短く（1〜2ページ）、最初の段落に推奨案を置き、決める人の名前と日付で締める。

## 使う場面

- 誰かの承認が必要な選択があるとき: 採用、取引先の選定、価格の変更、組織変更、自社開発か購入か。
- 会議が毎回、結論が出ないまま終わるとき。
- 経営陣のレビューで、スライド資料の代わりにするとき。
- すでに決まったことの記録には使わない（decision-record を使う）。長い戦略文書にも使わない。

## 用意するもの

- 決めるべきことを、問いの形で。
- 誰が、いつまでに決めるか。わからなければ一度だけ聞き、それでもなければ「[決める人: 要確認]」と書く。
- 検討した選択肢と、それぞれの事実: 費用、時間、効果。数字は作らない。わからないところには「[要確認: ...]」と付ける。
- 書き手の推奨案。推奨案がなければ中立に書き、最初の段落に「推奨案はまだない」と書く。

## 手順

1. **問いと依頼を先に書く。** 1段落で、必要な決定、推奨案、決める人、期限、期限までに決めないと何を失うかを書く。ここで読むのをやめても、相手が動けるようにする。
2. **背景は必要な分だけ書く。** 1〜2段落で、何が変わったか、なぜいまか、わかっていること（数字とその出どころ）。決める人がすでに知っている経緯は削る。
3. **実際にありうる選択肢を2〜4つ並べる。** 現実的なら「何もしない」も入れる。それぞれ、内容、費用、時間、得られるもの、手放すもの。数字は比較表に、理由は文章で書く。
4. **トレードオフをはっきり書く。** 推奨案がなぜ勝つのかを1段落で書き、それを選ぶと何を手放すかも書く。やり直せる決定なら、そう書く。ベゾスの2016年の手紙は、こうした決定を軽い手続きで進めてよい「両開きのドア」と呼んでいる。
5. **リスクを挙げる。** 推奨案の主なリスクを2〜3つ。それぞれに対策と、早めに気づくための兆候を添える。
6. **依頼で締める。** 必要なものを具体的に書く: 案 B の承認、予算、人。決める人、期限、承認されたら最初にすること。
7. **文章で書き、削る。** 選択肢の表のほかは、スライドの箇条書きではなく文章にする。2ページ未満を目安にする。データの代わりに使っている形容詞（「大幅な」「圧倒的な」）を消す。

## 出力の形式

```markdown
# [問いの形にした決定事項]
**決める人:** [名前] · **決定の期限:** [日付] · **書いた人:** [名前] · **日付:** [日付]

## 推奨案
[1段落:「Y なので X を推奨する。[日付]までに決めないと、[結果]」]

## 背景
[1〜2段落: 何が変わったか、なぜいまか、主な事実と出どころ]

## 選択肢
| | A: [名前] | B: [名前] | C: 何もしない |
|---|---|---|---|
| 費用 | | | |
| 時間 | | | |
| 得られるもの | | | |
| 手放すもの | | | |

[選択肢ごとに、理由を1段落]

## [推奨案]を選ぶ理由
[トレードオフを平易な文で。手放すものも含めて。やり直せる決定かどうか]

## リスク
| リスク | 対策 | 早めに気づく兆候 |
|---|---|---|

## 依頼
[日付]までに[X の承認 / 予算 / 人]をお願いしたい。承認されたら、[担当者]が[日付]に[最初の行動]を始める。
```

## 例

**入力:** 「今日は2026年11月10日（火）。金曜までに、山本社長に決めてほしい。サポートをメールから Zendesk に移すかどうか。いまは共有の Gmail で、サポート担当は2人、問い合わせは月に約600件、そのうち約5%を見失っている（お客様から催促されて気づく）。Zendesk Suite の見積もり: 1エージェントあたり[要確認]。別案は Help Scout で、安いが機能は少ない。あるいはいまのまま。自分は Help Scout がいいと思う。うちには Zendesk ほどの複雑さはいらない。移行はどちらも2週間くらい。1月は更新が集中する繁忙期。（小林）」

**出力:**

```markdown
# カスタマーサポートを共有 Gmail からヘルプデスクツールに移すべきか
**決める人:** 山本 花 · **決定の期限:** 11月13日（金） · **書いた人:** 小林 亮 · **日付:** 11月10日（火）

## 推奨案
サポートを Help Scout に移すことを推奨する。問い合わせを見失う問題を、Zendesk より低い費用と少ない設定の手間で解決できる。Zendesk には、いまの規模では使わない機能が多い。金曜までに決まれば、1月の更新が集中する時期の前に移行が終わる。それより遅れると、繁忙期と重なる。

## 背景
サポート担当2人が、共有の Gmail の受信箱で月に約600件の問い合わせに対応している。そのうち約5%（月30件ほど）が見失われ、お客様からの催促で初めて見つかる。誰がどの問い合わせを持っているか、お客様がどれだけ待っているかを確かめる方法がない。どちらのツールも、移行には約2週間かかる。

## 選択肢
| | A: Help Scout | B: Zendesk Suite | C: Gmail のまま |
|---|---|---|---|
| 費用 | [要確認: 見積もり] | 1エージェントあたり[要確認: 見積もり] | 追加費用なし |
| 時間 | 約2週間 | 約2週間 | なし |
| 得られるもの | 担当者の割り当て、対応状況、レポート[要確認: プランの機能] | 同じものに加え、高度な振り分けと豊富な連携アプリ[要確認: プランの機能] | 新しいものはない |
| 手放すもの | まだ必要のない高度な振り分け | 設定と管理にかかる時間が増える | 月約30件の見失いが続く |

Help Scout は、いま足りない3つ、つまり割り当て、対応状況、レポートをそろえる。Zendesk は、大きなチーム向けの振り分けと自動化を上乗せする。いまのままならツールの費用はかからないが、1日に約1件の問い合わせを見失い続ける。

## Help Scout を選ぶ理由
Zendesk の伸びしろと引き換えに、管理者を置かずにサポート担当2人で回せる簡単なツールを選ぶ。この決定はやり直せる。Help Scout では足りなくなっても、問い合わせの履歴はエクスポートできる[要確認: エクスポートの条件]。

## リスク
| リスク | 対策 | 早めに気づく兆候 |
|---|---|---|
| 移行中に問い合わせを見失う | 1週間は両方の受信箱を並行して動かす | お客様が古いスレッドに返信してくる |
| サポート担当が新しいツールを嫌がる | 対応状況の種類はサポート担当が決める | 2週目を過ぎても Gmail から返信している |

## 依頼
11月13日（金）までに、Help Scout とその年額費用[要確認: 見積もり]の承認をお願いしたい。承認されたら、11月16日（月）に小林が試用環境の設定を始める。
```

## 送る前のチェック

- [ ] 推奨案、決める人、期限が最初の段落にある。
- [ ] 選択肢が2〜4つあり、それぞれ手放すものが書いてある。現実的なら「何もしない」も入っている。
- [ ] すべての数字に入力内の出どころがあるか、「[要確認: ...]」が付いている。
- [ ] やり直せる決定かどうかが書いてある。
- [ ] 具体的な依頼ひとつと、承認されたら最初にすることで締めている。
- [ ] 2ページに収まっている。

## よくある失敗

- もったいぶる: 背景を1ページ書き、推奨案を最後に置く。推奨案から書く。
- ひとつしか現実的な案がない、当て馬だらけの選択肢。決める人は気づき、信頼が下がる。
- 推奨案の弱点を隠す。何を手放すかを書く。決める人が聞いてくるのはそこだ。