フレームワーク活用ガイドひとことで言うと#
完璧を目指さず、あえて「叩き台」を粗い状態で出すことで、チームの議論を加速させる手法。白紙から議論するより、「ここがダメ」「こう直すべき」と反応するほうが人は意見を出しやすいという心理を活用する。
押さえておきたい用語#
- ストローマン（Straw Man）
- 直訳は藁人形。壊される前提で作られた「叩き台」を意味する。議論の論点を可視化し、反応を引き出すための出発点。
- スチールマン（Steel Man）
- ストローマンの対義語で、相手の主張を最強の形に強化して議論する手法を指す。ストローマンで方向性を決めた後、スチールマンで磨き上げるのが理想的な流れ。
- 叩き台
- 日本語でストローマンに最も近い表現。修正される前提で出す初期案を指す。
- イテレーション
- 叩き台を修正し、再度フィードバックを受ける反復サイクルである。2〜3回のイテレーションで叩き台が最終案に近づく。
ストローマン提案の全体像#
こんな悩みに効く#
- 会議で「何かアイデアありますか？」と聞いても沈黙が続く
- 完璧な企画書を作ろうとして、いつまでも出せない
- プロジェクトの方向性が決まらず、議論がループしている
基本の使い方#
完成度は30%で十分。むしろ粗い方がよい。
- A4で1〜2枚、またはスライド3〜5枚程度
- 構成の骨子、方向性、大まかな数字が入っていれば十分
- 「穴がある」「突っ込みどころがある」のが正常
叩き台に30分以上かけない。 かけすぎると「自分の案」への愛着が生まれ、壊されるのが辛くなる。
共有するときに必ず「これは叩き台です。壊してください」と明言する。
- この宣言がないと、メンバーは「上司の案を批判していいのか？」と遠慮する
- 「ここが弱いと思っている」と自ら弱点を指摘すると、さらに意見が出やすくなる
- 共有は会議の場でもSlackでもよい。非同期で書き込む方がじっくり考えた意見が出ることもある
出てきた意見を整理し、叩き台を修正する。
- すべての意見を取り入れる必要はない。「この指摘は反映する/しない」の判断を明示する
- 2〜3回のイテレーションで十分な品質になるケースが多い
- 最終案は「チーム全員で作った案」になるため、実行段階での抵抗が少ない
具体例#
状況: 全15店舗の飲食チェーン。夏の新メニュー企画会議で「何かアイデアありませんか？」と聞くも、8人の参加者全員が沈黙。過去3回の会議も同じパターン。
叩き台（完成度30%）:
- コンセプト: 「猛暑に負けない冷製パスタフェア」
- メニュー案: 冷製トマトパスタ（980円）、冷製ジェノベーゼ（1,080円）
- 期間: 7月1日〜8月31日
- 売上目標: 月120万円/店（全店で月1,800万円）
議論で出た意見:
- 「冷製パスタは昨年もやった。差別化にならない」→ 和風の冷やし麺もラインナップに追加
- 「売上目標が根拠なし」→ 昨年夏の実績データを基に再計算 → 月95万円/店が現実的
- 「ジェノベーゼは食材コストが高い」→ バジルを契約農家から直接仕入れる案が出た
- 「写真映えが必要」→ 器をガラスボウルに変更してSNS映えを強化
最終案は叩き台から大きく変わったが、会議は45分で結論が出た。白紙から議論していた過去3回はいずれも結論が出ず持ち越しだった。
状況: 従業員80名のSaaS企業。来期のロードマップを決めたいが、営業・開発・CSの要望がバラバラで、3回の経営会議でも合意に至らない。
叩き台（PM1名が2時間で作成）:
| 四半期 | 開発テーマ | 狙い |
|---|---|---|
| Q1 | ダッシュボードのリニューアル | 解約理由1位「UIがわかりにくい」への対応 |
| Q2 | API公開 | 大企業向けの連携ニーズに対応 |
| Q3 | モバイルアプリ | 営業からの要望Top3に常に入っている |
| Q4 | AI自動レポート | 競合差別化の目玉機能 |
議論で出た修正:
- 営業部長: 「API公開はQ2では遅い。大手A社の案件がQ1に入札。Q1に前倒しすべき」
- 開発リーダー: 「API公開をQ1にするならダッシュボードはQ2に。同時進行は人員的に無理」
- CS: 「モバイルアプリより先にCSV一括インポート機能が欲しい。問い合わせの25%がこれ」
- CEO: 「AI自動レポートは技術的に不確実。Q4に入れるのはリスクが高い」
最終案ではQ1にAPI公開、Q2にダッシュボード、Q3にCSV機能、Q4をAIのPoCに変更。全員が参加して決めたロードマップのため、各部門の協力体制がスムーズに立ち上がった。
状況: 人口1.2万人の町で、商店街の活性化イベントを企画したい。住民説明会を開いても「何がいいと思いますか？」の問いに反応がない。
叩き台（NPOスタッフが作成）:
- イベント名: 「〇〇町 夜の商店街マルシェ」
- 日時: 8月の土曜日18:00〜21:00
- 内容: 商店街の10店舗が軒先で特別メニューを出す＋地元高校生バンドの演奏
- 予算: 50万円（自治体補助30万円＋協賛20万円）
- 目標来場者: 500人
住民から出た意見:
- 「夏は暑すぎる。10月の方がいい」→ 開催を10月に変更
- 「夜だけじゃなく、午後からやった方が家族連れが来る」→ 15:00〜20:00に拡大
- 「高校生だけじゃなく、地元のおばあちゃんたちの踊りも入れたら」→ 地元民謡サークルに出演依頼
- 「50万円じゃ足りない。クラウドファンディングで集めよう」→ 目標30万円のCFを追加
叩き台があったことで、住民は「自分ごと」としてアイデアを出し始めた。最終的に実行委員会に住民12名が参加し、当日の来場者は目標500人に対して830人を記録した。
やりがちな失敗パターン#
- 叩き台を作り込みすぎる — 完成度が高いと「もう決まっているのでは」と思われ、意見が出にくくなる。あえて粗さを残す勇気が大事
- 「壊す前提」の宣言を忘れる — この一言がないと、メンバーは叩き台を「上司の決定」と受け取る。特に上下関係がある組織では致命的
- フィードバックを全部取り入れようとする — 矛盾する意見も出るので、すべてを反映するのは不可能。PMが取捨選択し、判断理由を説明する
- 叩き台を壊されて傷つく — 自分の案が否定されるのは気持ちのいいものではない。しかしストローマンの本質は「議論の触媒」であって「自分の作品」ではない。最初からそのつもりで出す
まとめ#
ストローマン提案は「完璧な案を出す」のではなく「壊される前提の叩き台を出す」ことで議論を加速させる手法。白紙から創造するより、既存の案に赤ペンを入れる方が人は得意。叩き台は30%の完成度でいい。大事なのはスピードと「壊してください」の一言。チームの知恵を引き出す最も効率的な方法の一つ。