「生成AIを使っているのに、思ったほど成果につながらない」「分析アウトプットは早くなったが、評価が変わった気がしない」
──そんな相談を周りからよく受けるようになりました。
私自身は、本業でデータサイエンティストとマーケティングを兼務し、副業先では経営改善コンサルティングや人事改革など、幅広く案件に関わっています。どのような現場でも必要になってくるのが「叩き台」です。
叩き台作成で共通して感じるのは、生成AIの進化によって「迅速に作れるかどうか」が、これまで以上に市場価値を左右するようになってきたということです。
本記事では、私自身の実体験を踏まえながら、なぜ「迅速に叩き台を作る力」が今の時代に強いレバーになるのか、そして具体的にどう実践していけば良いのかを整理していきます。
本記事のターゲット
- 生成AIを使っているが、思うように成果につながっていない方
- プロジェクトマネージャーやプロジェクトリーダーの方
- プロジェクトの主導権を握り、自分の市場価値を高めたい方
叩き台のない会議で起きていること
私がこれまで多くの現場で見てきたのは、叩き台のない会議ほど議論が発散し、プロジェクト全体が歪んでいくという光景です。
叩き台がないということは、参加者全員がまっさらな状態で議論を始めるということです。
すると、目的や制約条件を十分に理解していないメンバーであっても、その場の思いつきで好き勝手に意見を出せてしまいます。
「それ、12月までに終わらないんじゃない？」
「最近私が抱えている課題にXXXXがあるのだが、一緒に解決できないだろうか？」
といった発言は、目的と制約が共有されないまま議論が始まったときによく起きる典型例です。
こうした発散した議論を放置すると、本来の目的からずれた要件が積み上がり、納期遅延や関係者間の不信、再調整工数の増加といった実害につながります。私自身、何度もこの光景を見てきました。
逆に言えば、たとえ60点の叩き台でも早い段階で目の前にあれば、議論は「ここをどう良くするか」「どこを削るべきか」から始まります。論点が明確になり、目的と制約に立ち返った会話ができるようになります。叩き台は、「議論の起点」であると同時に、議論を脱線させない「ガードレール」にもなります。
生成AIによって叩き台作成は別次元の速さに
私の実例：業務効率化・システム移管プロジェクト
私が関わったプロジェクトのひとつに、社内業務を効率化しながら、新社内システムへの移管を同時に進める、という締切が迫った案件がありました。
このようなプロジェクトでは、まず目的を定め、スケジュールを引き、タスクを分解し、誰にいつまでにアサインするかを決め、各タスクの稼働量や認可までの工数を見積もる必要があります。このような「WBS(Work Breakdown Structure)」の叩き台を作成し、上長やステークホルダーに相談・承認してもらわなければ、実際の動き出しには移れない業務の進め方でした。
以前であれば、この一連の「叩き台」を一人で作るのに半日、慣れていない領域だと丸一日かかるのが普通でした。
叩き台を作り、レビュー依頼を出し、調整して会議を入れるとなると、結局その週は動き出せず、本格稼働は翌週から、というケースが大半だったように思います。
ところが、Claude Codeを使うようになってから、この時間配分が劇的に変わりました。
Claude Codeに、締切日や協力部署といった「目的と制約条件」を伝え、「ExcelでWBSとガントチャートをシート分けで作ってほしい」「ガントチャートはWBSと連動して変更される仕様にしてほしい」といった指示を投げると、20〜30分程度で実用に耐えるスケジュール叩き台が完成します。
半日のうちに叩き台を作り終え、午後にはステークホルダーへレビュー依頼を出し、その日のうちに議論・修正を済ませてしまう。結果として「翌週から動き始める」のではなく、「翌週にはすでにタスクが走り始めている」状態を作れるようになりました。
叩き台を作れる人は、プロジェクトの主導権を握る人
「計画性」と「クリエイティビティ」のどちらが優位という話ではない
叩き台をすんなり作れる人と苦手な人を観察していると、性格的な傾向があるように感じます。
作れる人は、ゴールから逆算して計画的に考える逆算思考の方が多い印象です。一方で「議論する中で何かが生まれてくる」と考えるタイプ、いわゆるクリエイティビティ寄りの方は、叩き台を事前に作ることに抵抗を感じやすい傾向があります。
ただ、プロジェクトに関しては話が違います。プロジェクトには必ず締切があります。クリエイティブな発散の議論を経て、最終的にはその結果を合意・実行可能な計画に落とし込む必要があります。つまり、「クリエイティビティを発揮する場」と「計画として収束させる場」の両方を設計する責任が、プロジェクトをリードする側にはあるということです。
そう考えると、プロジェクトリードやプロジェクトマネジメントを担う立場であれば、叩き台を作らないという選択肢は基本的にあり得ません。生まれ持った性格の話ではなく、責任の所在として「作るべきもの」だと捉えるのが現実的です。
最初に叩き台を出した人が、プロジェクトの主導権を握る
そして重要なのは、最初に叩き台を出した人が、結果としてプロジェクト全体の主導権を握りやすいということです。
最初にコミットした人は、プロジェクトの全体像を一番早く理解し、目的と制約を踏まえた意思決定の中心に立ちます。プロジェクトを通して全体を見渡せる位置に立てるかどうかは、最終的にそのプロジェクトの成果が誰の評価につながるかにも直結します。
もちろん、途中から参加して大活躍する方も多くいらっしゃいます。ただ、「最初から全体をコントロールする役回り」を狙えるのは、最初に叩き台を出した人の特権だというのが、私の実感です。
生成AIによって、その「叩き台を出す」というハードルが、かつてないほど下がりました。手を挙げれば、それなりの精度のものを短時間で作れる時代になった。あとは手を挙げる勇気があるかどうか、という状態に近づいていると感じています。
Claude Codeで叩き台を作るときに私が意識している3点
私が普段、叩き台作成に使っている生成AIツールはClaude Codeです。
Claudeのモデルとしては、Sonnet以上（SonnetまたはOpus）を選んでいます。叩き台作成という用途に関しては、Claude Codeさえあればほぼ事足りる、という感覚です。
少し前までは「プロンプトエンジニアリング」が話題になり、いかに細かく指示を書くかが重要視されていました。しかし、最近のモデルは背景を汲み取る能力が大きく上がっており、過度なプロンプト設計は不要になってきていると感じます。
その代わり、私が意識的に伝えるようにしているのは、次の3点です。
1. 目的
「何のためにこの叩き台を作るのか」を必ず冒頭に書きます。スケジュール表ひとつとっても、「移管を完了させること」が目的か「業務効率化まで進めること」が目的かで、設計は変わります。
2. 制約条件
締切日、関与する部署、使えるリソース、外せないマイルストーンなど、動かせない条件を明示します。
また事前にプロジェクトに係る会話がメモとして残っている場合にはそのテキストファイルを参照するように指示を出すこともお勧めです。
制約があるからこそ、叩き台は「議論可能な現実的な選択肢」になります。
3. アウトプットのフォーマット
「Excelで作ってほしい」「WBSシートとガントチャートシートに分けてほしい」「ガントチャートはWBSと連動するように」など、具体的な形式まで指定します。特に私の場合はプロジェクトの進捗管理をスプレッドシート形式で管理することが多いため「Excel」、プロジェクトメンバーに伝えるため「PPTX」の2つを両方をアウトプットするケースが非常に多いです。
ここまで書くと当たり前のように見えますが、これは結局のところ「人に仕事を頼むときと同じ」です。
絶対にずらしたくない「目的・制約・フォーマット」は明確にして、それ以外は考えさせる頼み方をする
──このスキルがあれば、AIにも人にも、同じように良い叩き台を引き出せます。
まとめ：最高の叩き台で、最後の最後までリードする
叩き台を作るのは、決して気持ちの良い作業ではありません。自分が出した粗いアウトプットに対して意見を言われたり、時には否定されたりもします。これは叩き台という言葉どおり、「叩かれる」ことを前提とした成果物だからです。
それでも、最初の上流工程で叩き台を持ち込んだ人は、プロジェクトの目的に最初にコミットした人であり、全体像をコントロールするきっかけを誰よりも早く得られる人です。
生成AIの進化によって、その叩き台を「精度高く、短時間で」作れる環境が整いました。あとは手を挙げるかどうかという、行動の問題に近づいています。
最後にひとつだけ強調しておきたいのは、「叩き台をたくさん作ること」自体を目的としてはならないということです。
本当に市場価値の高い人材は、叩き台を起点にステークホルダーと親密にコミュニケーションを取り、円滑な議論を導き、結論まで合意しきる人です。叩き台はあくまで、そのスタート地点に立つための入場券にすぎません。
生成AI時代の本質的な変化は、「叩き台の生産」がコモディティ化したことよりも、「みんながプロジェクトをリードしやすい状況が生まれた」ことにあると私は捉えています。
明日の打ち合わせから、まずは粗くてもいいので、プロジェクトを任された場合でも分析を依頼されたシーンでも自分なりの叩き台を持ち込んでみてください。
