106 lines
6.8 KiB
Markdown
106 lines
6.8 KiB
Markdown
---
|
||
name: writing-proposals
|
||
description: 誰かに何かを提案したいとき、対話で材料を引き出し、結論ファーストで意思決定者に刺さる提案文書を作るスキル。「提案文を作って」「提案書を書いて」「◯◯を提案したい」「提案を通したい」「writing-proposals」と依頼された際に使用する。
|
||
---
|
||
|
||
# Writing Proposals
|
||
|
||
ざっくりした思いつき（例：「定例会議を減らしたい」）から、対話を通じて材料を引き出し、意思決定者に刺さる提案文書を作る。テンプレートを埋めるのではなく、**書く前に上流を整える**ことに専念する。
|
||
|
||
## 大原則：上流を整えてから書く
|
||
|
||
文章は5つの工程でできている。
|
||
|
||
```
|
||
上流（人間が決める） 誰に出すか ／ 相手の問い ／ 何を言い切るか
|
||
下流（AIが整える） 下書き ／ 洗練
|
||
```
|
||
|
||
上流が空っぽのまま下流だけAIに任せると、誰にでも当てはまる薄い文章になる。このスキルは上流を対話で固めてから下流を書く。
|
||
|
||
## 基本ルール
|
||
|
||
- **1問ずつ聞く。** まとめて質問攻めにしない
|
||
- **質問には必ず推奨案を添える。** 「どうしますか？」ではなく「◯◯がおすすめ、理由はこう。どうですか？」（特に③相手の問い）
|
||
- **質問は必ず「選べる質問ツール」で行う。** 推奨案を選択肢にして提示し、テキストで列挙しない
|
||
- **ユーザーは最初にまとめて渡してよい。** すでに分かる材料は聞かず、足りない分だけ確認する
|
||
- **ユーザーを否定せず、肯定的な言葉で伴走する。** ダメ出しの口調にしない
|
||
- **提案の穴は誠実に伝える。** 根拠の薄さや相手の問いへの未回答は確認し、矛盾・論理の飛躍・事実誤認など明らかに通らない問題ははっきり指摘する（責めず、直す代替案をセットで示す）
|
||
- **やりとりの回数は固定しない。** 数問で終わることも、長く続くこともある
|
||
- **手で書き換えず、材料が揃ってから一度に出力する**
|
||
|
||
## 集める5つの材料
|
||
|
||
| # | 聞くこと | 役割 |
|
||
|---|---|---|
|
||
| ① | 何を変えたいのか | 提案の核 |
|
||
| ② | 決めるのは誰か | 承認者・意思決定者 |
|
||
| ③ | その人の頭の中の問いは | 相手の関心・不安 |
|
||
| ④ | 根拠になる数字や事実は | 説得材料 |
|
||
| ⑤ | 似た種類の過去の文章（任意） | 文体の学習用 |
|
||
|
||
**相手が誰か迷ったら「忙しい・せっかち・短気・ズボラな意思決定者」を想定する。** 最初の数行で読むのをやめ、YesかNoで答えたいだけの人。その人が「それで！」の一言で終われる文章が、優れた提案文書。
|
||
|
||
## 対話の進め方
|
||
|
||
1. **受け取る**：持ち込まれた提案を読み、分かる材料を①〜⑤に仮置きする
|
||
2. **上流を埋める**：不足する①〜③を1問ずつ、推奨案つきで確認する
|
||
3. **根拠を詰める**：④を引き出す（「根拠の強さ」参照）。数字がなければ体験談へ誘導する。⑤があれば文体の特徴をつかむ
|
||
4. **出力する**：結論ファーストの提案文書を生成する（「出力フォーマット」参照）
|
||
|
||
ユーザーが「もう十分」と言えば、その時点で出力に進む。
|
||
|
||
### 質問の例（良い / 悪い）
|
||
|
||
特に③相手の問いは答えにくい。質問するだけでなく推奨案を示す。
|
||
|
||
悪い例：「これは誰に出しますか？」
|
||
良い例：「承認するのは部長ですよね。部長の一番の関心は『これで残業代がいくら減るか』だと想定し、冒頭で月◯時間の削減を数字で出すのがおすすめです。気になる点はありますか？」
|
||
|
||
## 根拠の強さ
|
||
|
||
```
|
||
強 ┃ 数字・データ ＞ 専門家の意見 ＞ 体験談 ＞ たとえ話 ＞ 思い込み ┃ 弱
|
||
```
|
||
|
||
ただし現実の意思決定は感情で動く。**ベストは「数字＋心を動かす話（体験談など）」**。強い数字が出せないときは、体験談や具体的なエピソードで代替してよい。
|
||
|
||
## 相手のメンツを守る（変える＝過去の否定にしない）
|
||
|
||
「変える・やめる」提案は、それを作った／続けてきた相手に「自分のやり方は間違っていたのか」と聞こえやすい。理屈が正しくても、ここでつまずくと通らない。事実は変えず、伝え方を整える（おだて・ごまかしは不可）。
|
||
|
||
- **過去を正当化する**：「当時は妥当だった」と置き、変更は"状況変化への対応"として語る
|
||
- **問題を人でなく状況・数字に帰属**：「やり方が悪い」でなく「事業が伸びて会議が増えた」
|
||
- **功績を立て、共同の前進にする**："あなた vs 私"でなく「これまでの仕組みを次の段階へ一緒に更新」
|
||
- **小さく・可逆にする**：試験運用や期間限定で、判断を全否定して覆す感を消す
|
||
- **否定語を避ける**：「無駄・非効率・間違い」を使わない
|
||
- **決定権は相手に残す**：最終判断は相手のもの、という姿勢で書く
|
||
|
||
対話では「この提案は相手が作ったもの／続けてきたものを変えるか？」を見極め、Yesなら上の配慮を強める。
|
||
|
||
## 出力フォーマット
|
||
|
||
結論を最初に置き、事実・解釈・提案を分ける。
|
||
|
||
```
|
||
【提案】<結論＝お願いを1行で。要約だけでなく「だから何をしてほしいか」まで言い切る>
|
||
<背景や規模を1〜2文で補足（必要なときだけ）>
|
||
|
||
◎ 現状の課題 … 事実（数字・体験談）
|
||
◎ 提案する理由 … なぜそうすべきか
|
||
◎ 選択肢と推奨 … 比較がある場合。「→推奨：◯◯（理由）」で締める
|
||
◎ リスクと対策 … 意思決定者の不安に先回り（必要なとき）
|
||
```
|
||
|
||
- **完成した提案文書はコードブロックで出力する。** チャットのコピーボタンで1クリックでコピーでき、そのまま貼り付けられる
|
||
- **出力する提案文書では太字（`**`）などのmarkdown装飾を使わない。** 貼り付け先で崩れるため、プレーンな文章にする
|
||
- 見出し名は提案内容に合わせて調整してよい（◎の枠組み「事実→理由→選択肢→リスク」は保つ）
|
||
- `◎` 配下が1項目だけなら、見出しを使わず本文に含める
|
||
- 模範解答例 → [references/examples.md](references/examples.md)
|
||
|
||
## 品質チェック
|
||
|
||
出力する前に、提案文書がチェックリストを満たすか確認する。満たさない項目は直してから出力する。
|
||
|
||
→ [references/output-quality.md](references/output-quality.md)
|