コンサル向けプロンプト20選、 クライアントのデータから始める
AIに任せたコンサルの仕事は、誰も渡していないデータやベンチマークをモデルが勝手に埋めるせいで、クライアントとの会議で崩れます。このプロンプトは、あなたのメモとクライアントの数字だけで作業し、置いた仮定に印をつけ、結論を先頭に置きます。
[かっこ]の部分は、クライアントのメモ、データ、下書きに置き換えてください。
01. あいまいなクライアントの課題をMECEなイシューツリーに分解する
1週目、依頼内容が「利益率を改善したい」だけで、それ以上の情報がないとき。
クライアントが説明した課題：[ブリーフまたはキックオフのメモを貼る] 最終的にクライアントが下す意思決定：[わかっていれば意思決定の内容] すでに除外されていること：[検討対象外の選択肢やテーマ] まず、課題を意思決定で終わる一つの主要な問いに書き直して、私のメモのどの行を根拠にしたかを示して。この問いがどの意思決定につながるのか私のメモに書かれていなければ、先に進む前に私に質問して。 次に、3階層のイシューツリーを作って。第1階層は、重複も漏れもなく主要な問いに答えられる3〜5個の問い（MECE、つまり相互に排他的で全体として網羅的）にして。各末端には、必要な分析と、そのために必要なデータを書いて。 最後に、自分で作ったツリーを点検して。重複している枝を2つ、クライアントが持っていそうなデータでは検証できない枝を、そして答えを暗黙のうちに前提にしている枝を、それぞれ挙げて。
02. 仮説を並べ、それぞれを否定するデータを書き出す
イシューツリーの後、クライアントに何かを依頼する前。
[案件を一行で]のイシューツリーはこちら：[貼り付ける] クライアントと私のチームがすでに信じていること：[初期の見立て、勘、CEOの発言] 末端ごとに、検証可能な仮説を一つ書いて。間違っている可能性のある主張の形にして（「利益率低下の主因は価格ではなく運賃だ」のように）。それぞれについて次を示して： 1. その仮説を検証する分析。 2. その仮説を否定する具体的な結果。 3. 必要なデータと、クライアント側でおそらくそれを持っている人。 4. 検証にかかる期間（日数または週数）。 次に、その仮説が間違っていた場合に最終的な答えがどれだけ変わるかで順位をつけて。実はクライアントの望む答えを仮説の形にしただけのものと、私が入手できるどんなデータでも反証できないものには、印をつけて。
03. クライアントが実際に埋められる初日のデータ依頼を書く
キックオフが終わり、最初のインタビューの前にデータが必要なとき。
検証が必要な仮説はこちら：[リストまたはイシューツリーを貼る] 私が把握しているクライアントのシステムとチーム：[ERP、CRM、経理チーム、現場責任者] 対象とする期間：[例：直近36か月] データ依頼を表で書いて。項目番号、必要なもの、粒度（月別、製品別、顧客別）、対象期間、希望する形式、クライアント側でおそらく持っている人、どの仮説に使うか、の列にして。 [日付]までに必須のものと、あれば望ましいものに分けて。必須リストは15項目以内にして。キックオフに出ていない経理の担当者が、私に電話せずに抽出できるように、各項目を書いて。 最後に、機微な可能性が高い項目（給与、顧客名、個人情報）を挙げ、代わりに依頼できる集計版または匿名化版を提案して。
残りの17個のプロンプトを無料で開く
Whiziのニュースレターに登録すると、このパックの続きを読めます。
- 会う予定の役割ごとにステークホルダーインタビューのガイドを書く
- ステークホルダーインタビューをクライアントが受け入れる発見事項にまとめる
- クライアントのデータ抽出ファイルを、分析の土台にする前に点検する
- 2×2マトリクスが役に立つのか、飾りにすぎないのかを判断する
- リスク、担当者、最初の90日を含む提言を書く
- 結論を先頭に置くエグゼクティブサマリーを書く
- わかったことから最終報告のストーリーラインを組み立てる
- 意思決定で終わる運営委員会向けの進捗報告を書く
- 合意した行動で終わるクライアントワークショップを設計する
- クライアントが発見事項を否定したときに応じる
- 初回ヒアリングのメモから提案書のエグゼクティブサマリーを書く
- 対象外の明示リストを含む作業範囲記述書（SOW）のスコープを書く
- スコープが膨らみ始めたときの変更依頼を書く
- あなたの時間の日数ではなく、クライアントにとっての価値として報酬を説明する
- クライアントチームがそのまま運用できる引き継ぎ文書を書く
- 完了した案件から、クライアントの承認つきの事例を書く
- 別のモデルに、最初のモデルが作ったクライアント向け成果物を批評させる