From 4b5376744c86586d5ea5d1d06d08e4601bdc2152 Mon Sep 17 00:00:00 2001 From: snc Date: Wed, 1 Jul 2026 14:54:45 +0900 Subject: [PATCH] initial commit --- README.md | 58 +++++++++++++++ SKILL.md | 105 +++++++++++++++++++++++++++ references/examples.md | 133 +++++++++++++++++++++++++++++++++++ references/output-quality.md | 27 +++++++ 4 files changed, 323 insertions(+) create mode 100644 README.md create mode 100644 SKILL.md create mode 100644 references/examples.md create mode 100644 references/output-quality.md diff --git a/README.md b/README.md new file mode 100644 index 0000000..b4fad0f --- /dev/null +++ b/README.md @@ -0,0 +1,58 @@ +# Writing Proposals + +「◯◯を変えたい」というざっくりした思いつきから、AIが対話で材料を引き出し、相手に刺さる提案文書を作ってくれるスキルです。 + +意思決定者に「それで！」と言わせる、結論ファーストの提案文に仕上がります。 + +## 何ができるか + +- AIが提案に必要な材料（誰に・相手の問い・何を言い切るか・根拠）を1問ずつ質問してくれる +- 「どうしますか？」ではなく「◯◯がおすすめ、理由はこう」と推奨案つきで聞いてくる +- 材料が揃うと、結論ファーストで構造化された提案文書を出力してくれる +- 過去に書いた文章を渡すと、あなたの文体に寄せてくれる（任意） + +テンプレートを機械的に埋めるのではなく、**書く前に「上流」（誰に・何を・なぜ）を整える**ことに専念します。 + +## 使い方 + +Cursor のチャット欄に、提案したいことを書いて以下のように依頼するだけです。 + +``` +定例会議を減らす提案を作って +``` + +または + +``` +◯◯を提案したい +``` + +``` +提案書を書いて +``` + +AIが1問ずつ質問してくるので、答えていけば提案文書ができあがります。最初にわかっている情報はまとめて渡してもOKです。 + +## こんなときに使う + +- 上司やチームに何かを提案したいが、どう書けば通るか分からないとき +- AIに丸投げすると「当たり障りのない薄い文章」しか出てこないとき +- 自分の作ったツールや改善案を、決裁権を持つ人に通したいとき +- 提案の根拠をどう組み立てればいいか迷うとき + +## フォルダの中身 + +``` +writing-proposals/ +├── README.md ← この説明書 +├── SKILL.md ← スキル本体（AIへの指示書） +└── references/ + ├── examples.md ← 提案文書の模範例 + └── output-quality.md ← 出力品質チェックリスト +``` + +`SKILL.md` がスキル本体（AIへの指示書）で、`references/` の模範例・品質チェックリストを参照します。 + +## 困ったとき + +何が起きても、まずはチャット欄でAIに状況を伝えてください。AIがエラーの内容を読み取り、次にやるべきことを教えてくれます。 diff --git a/SKILL.md b/SKILL.md new file mode 100644 index 0000000..efe9eab --- /dev/null +++ b/SKILL.md @@ -0,0 +1,105 @@ +--- +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) diff --git a/references/examples.md b/references/examples.md new file mode 100644 index 0000000..fa3486b --- /dev/null +++ b/references/examples.md @@ -0,0 +1,133 @@ +# 提案文書の模範例 + +意思決定者の問いに、結論ファーストで答える提案文書の例。 + +## 目次 + +- 対話の流れ（例） +- 例0：Before / After（上流を埋める効果） +- メンツを守る言い換え（NG / OK） +- 例1：在宅勤務を週2日に増やす +- 例2：採用管理ツールの導入（他ツール比較あり） +- 例3：ノー残業デーの導入 + +--- + +## 対話の流れ（例） + +ユーザーが雑に投げ、AIが1問ずつ推奨案つきで材料を引き出す。 + +> ユーザー：定例会議を減らしたい +> AI：①は「定例会議を減らす」ですね。②決めるのは誰ですか？ チームの定例なら直属の部長が承認者になりがちです。これでいいですか？ +> ユーザー：部長です +> AI：③部長の頭の中の問いは「どの会議か／何がよくなるか／自分は何をすればいいか」が刺さります。この3つに答える形でOKですか？ +> ユーザー：OK +> AI：④根拠になる数字はありますか？（なければ体験談でも可） +> ユーザー：週7本・12時間、直近は7人中2人しか発言していない +> AI：十分です。提案文書を作ります。 + +材料が揃うと、下の「例0：After」のような文書が出力される。 + +## 例0：Before / After（上流を埋める効果） + +同じ「定例会議を減らしたい」でも、上流（誰に・相手の問い・何を言い切るか）を埋めるかどうかで結果が変わる。 + +**Before（AIに丸投げ・上流が空っぽ）** + +``` +お疲れ様です。会議運営の効率化についてご提案がございます。 +最近、会議時間の増加が生産性低下の要因として指摘されています。 +つきましては、定例会議の頻度の見直しをご検討いただけますと幸いです。 +``` + +丁寧だが、どの会議か・何がよくなるか・何をしてほしいかに答えていない。意思決定者は「それで？」となる。 + +**After（上流を埋めてから書く）** + +``` +【提案】報告だけの定例会議3本を隔週にして、浮いた月6時間を提案準備に充てます。ご承認をお願いします。 + +◎ 現状の課題 +定例会議は週7本・延べ12時間。うち報告だけの3本が週3時間を占める。 +直近の会議では発言者が7人中2人だった。 + +◎ 提案する理由 +報告だけの会議は資料の前日共有で代替できる。議論のある会議は残す。 + +◎ リスクと対策 +共有漏れを防ぐため、資料は前日17:00までに投稿するルールにする。 +``` + +## メンツを守る言い換え（NG / OK） + +同じ提案でも、過去を否定する書き方は通りにくい。状況の変化として語り、相手の功績を立てる。 + +**NG（過去を否定）** + +``` +今の定例会議は無駄が多く非効率です。やめるべきです。 +``` + +**OK（状況変化＋功績を立てる）** + +``` +定例会議は立ち上げ期に足並みを揃えるのに役立ってきました。 +人数も増えて自律的に動ける今、形を変えるタイミングだと思います。 +まず1ヶ月、報告は資料共有に切り替えて試させてください。 +``` + +## 例1：在宅勤務を週2日に増やす + +``` +【提案】在宅勤務を週2日に増やすことを承認してください。来月から3か月の試験運用にしたいです。 + +◎ 現状の課題 +通勤に往復2時間かかり、集中して作業する時間を確保しにくい。 +資料作成は1人で進める作業が多く、出社の必要性が低い。 + +◎ 提案する理由 +移動時間を作業に充てられ、締め切り前の残業を減らせる。 +週2日に絞れば、対面が必要な会議や相談は出社日にまとめられる。 + +◎ リスクと対策 +連携が滞らないよう、出社日を火・木に固定してチームで揃える。 +3か月後に稼働と成果を振り返り、継続するか判断する。 +``` + +## 例2：採用管理ツールの導入（他ツール比較あり） + +``` +【提案】採用管理ツールをHRtable（月額3万円）で導入したいです。 +Googleスプレッドシートで管理している採用フローを移行する承認をお願いします。 + +◎ 現状の課題 +選考状況の共有にメール往復が発生し、1件あたり平均30分かかっている。 +スプレッドシートの更新漏れで、面接の重複が月2〜3件発生している。 + +◎ 他ツールとの比較検討 +・HRtable（月額3万円）— 採用サイトとAPI連携できる +・Recruit Board（月額2万円）— API連携できないため見送り +→推奨：HRtable（連携で更新漏れと面接重複を防げる） + +◎ コスト対効果 +月額3万円に対し、現在の対応工数（月約20時間）を半減できる見込み。 +``` + +## 例3：ノー残業デーの導入 + +``` +【提案】毎週水曜日をノー残業デーにしたいです。 +定時の18時退勤を原則とすることを承認していただきたいです。 + +◎ 現状の課題 +・定時以降は集中力が落ち、同じ作業でも時間がかかる +・平均残業時間は月40時間で、その時間帯の生産性は低い + +◎ 提案する理由 +・終わり時間を逆算することで生産性が上がる +・残業の常態化を防ぐことで離職リスクを下げられる +・週1回から始めることでまず効果を検証できる + +◎ 補足 +急ぎの仕事が入った場合は例外を認め、翌日に繰り越すルールとする。 +``` diff --git a/references/output-quality.md b/references/output-quality.md new file mode 100644 index 0000000..c52a26e --- /dev/null +++ b/references/output-quality.md @@ -0,0 +1,27 @@ +# 出力品質チェックリスト + +提案文書を出力する前に、以下を満たすか確認する。満たさない項目があれば直してから出力する。 + +## 結論と構造 + +- [ ] 1行目が結論（＝相手へのお願い）になっている。要約で終わらず「だから何をしてほしいか」まで言い切っている +- [ ] 全体像 → 詳細の順になっている +- [ ] 事実・解釈・提案が混ざらず分かれている +- [ ] 情報が階層構造（◎ → ・）で整理され、同じ階層に同じ粒度の情報だけが入っている +- [ ] 選択肢を示す場合、主要な案を網羅したうえで推奨案を明示している + +## 簡潔さと明確さ + +- [ ] 「〜について」「〜の件」で逃げず、具体的なお願いになっている +- [ ] 一文が長すぎない（一文一義）。ただし削りすぎて意味が抜けていない +- [ ] 「品質」「早急に」など解釈の分かれる言葉に具体的な定義がある +- [ ] 同じ意味の言葉の表記揺れがない（用語が一貫している） +- [ ] 過剰な敬語で冗長になっていない +- [ ] 重要な数値や根拠が本文に書かれている（リンク頼みにしない） + +## 仕上げ + +- [ ] 箇条書きはMECE（漏れなく重複なく）で、語尾が統一されている +- [ ] 期限があるなら日時まで具体的（例：2026/07/01 17:00）。「予定」ではなく確定表現になっている +- [ ] 要点が1つだけの短い内容を、無理に階層化していない +- [ ] 意味の区切りで改行され、視覚的に読みやすい