公式スキル · マネジメント
意思決定メモ
推奨案を先頭に、背景、トレードオフつきの選択肢、リスク、決める人と期限を添えた依頼を、短いナラティブ形式の意思決定メモにまとめる。
Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。
使う場面
- 創業者、役員、チームに判断を求めたいとき
- 会議が毎回、結論が出ないまま終わるとき
AI に渡すもの
- 問いの形にした決定事項
- 決める人と期限
- 選択肢と、それぞれの事実
- 書き手の推奨案
できあがるもの
推奨案を冒頭に置き、選択肢の比較表、対策つきのリスク、依頼ひとつをまとめた1〜2ページのメモ。
手順
- 問いと依頼を先に書く 1段落で、必要な決定、推奨案、決める人、期限、期限までに決めないと何を失うかを書く。ここで読むのをやめても、相手が動けるようにする。
- 背景は必要な分だけ書く 1〜2段落で、何が変わったか、なぜいまか、わかっていること（数字とその出どころ）。決める人がすでに知っている経緯は削る。
- 実際にありうる選択肢を2〜4つ並べる 現実的なら「何もしない」も入れる。それぞれ、内容、費用、時間、得られるもの、手放すもの。数字は比較表に、理由は文章で書く。
- トレードオフをはっきり書く 推奨案がなぜ勝つのかを1段落で書き、それを選ぶと何を手放すかも書く。やり直せる決定なら、そう書く。ベゾスの2016年の手紙は、こうした決定を軽い手続きで進めてよい「両開きのドア」と呼んでいる。
- リスクを挙げる 推奨案の主なリスクを2〜3つ。それぞれに対策と、早めに気づくための兆候を添える。
- 依頼で締める 必要なものを具体的に書く: 案 B の承認、予算、人。決める人、期限、承認されたら最初にすること。
- 文章で書き、削る 選択肢の表のほかは、スライドの箇条書きではなく文章にする。2ページ未満を目安にする。データの代わりに使っている形容詞（「大幅な」「圧倒的な」）を消す。
SKILL.md の全文
AI が読むファイルそのものです。 ダウンロード
---
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ページ書き、推奨案を最後に置く。推奨案から書く。
- ひとつしか現実的な案がない、当て馬だらけの選択肢。決める人は気づき、信頼が下がる。
- 推奨案の弱点を隠す。何を手放すかを書く。決める人が聞いてくるのはそこだ。
チームで使う
AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む
変更履歴
- v1.0.1 · · Example: the deadline is Friday 13 Nov and the start Monday 16 Nov (2026 weekdays), and the input now gives today's date (Tuesday 10 Nov 2026), the author and the January renewal peak; what each tool's plan includes is marked to check.
- v1.0.0 · · First release.
出典
出典は英語のページです。
- 2017 Letter to Shareholders - Amazon (2026-11-04に確認)
- Jeff Bezos' 2016 Letter to Amazon Shareholders (2026-11-04に確認)