このコンテンツは有料note「webライターとメディア運営者の、実践的教科書（安達裕哉著）」より転載しています。
BtoBビジネスでは、「提案活動」が頻繁に行われます。
しかし、この「提案」という行為。
実務をやる前のイメージと、実務をやった後のイメージがかなり違う行為の一つでもあります。
例えば、私がコンサルタントになる前に抱いていたイメージは次のようなものでした。
・お客さんの課題に気づく
・解決策を考える
・提案書をまとめる
・提案書をプレゼンテーションして相手を説得する
・プロジェクトのスタート
だが、実務は大きく違いました。
私がイメージしていた「提案」と、実務における提案は、まったく似たところすらありませんでした。
最初は「愚痴を聞く」
まず、私が勘違いしていたのは、「提案」の起点でした。
実務においては、上にあげた「お客さんの課題に気づく」ことから始まる提案活動というものは、ほとんどありません。
では何が「提案」の起点になるかと言いますと、「お客さんの何気ない愚痴」でした。
ご存じの方も多いでしょうが、「課題」と「愚痴」は似たような印象ですが、まったく異なります。
「課題」は、企業内で解決されるべき、とすでに意思決定がなされている問題です。
ところが「愚痴」というのは「問題」に近いものであり、「頭は痛いが、手を付けるかどうか意思決定はされていない」ものです。
端的に言えば、
「課題」はやらないとまずいもの。
「愚痴」はやるべきかどうか議論されていないもの
となります。
これは大きな違いです。
なぜかというと、企業では「愚痴」が「課題」として認定されれば、お金と人を出してもらえるからです。
これは、単に課題を解決するよりも、圧倒的に面倒な行為です。
したがって、「課題」かどうかという議論を行ってからでなければ、「提案」はできません。
これはおそらく、「提案型営業」という言葉があるため誤解が広がったものと考えられます。
営業は「これ課題ですよね」と売込むことが多いからです。
しかし、本来であれば「課題」を決め打ちすることはできず、
「お客さんの愚痴を聴く」
「悩みを話してもらう」
「社内事情をうかがう」
といったことから、提案の起点を探ることが大切になります。
× お客さんの課題に気づく
〇 お客さんの愚痴を聞く
解決しましょうよ！と言わない。解決策を出さない。
お客さんの愚痴を聞くと、ムクムクと「解決しましょうよ！」と提案をしたくなります。
が、ここで焦ってはいけません。
「解決しましょうよ！」というと、大体失敗します。
なぜでしょう。
簡単です。ほとんどの場合「愚痴」が「課題」のレベルになっていた場合、コンサルタントに言われるまでもなく、社内で何かしらの形で解決策を模索しているからです。
これは、プライベートでもよくある話です。
パートナーが愚痴を聴いてほしいだけのときに、解決策をあれこれ出してしまうと、かえって相手をイラつかせしまうこと、ありますよね。
そもそも「解決しなきゃならない、切羽詰まった」時には愚痴なんて言ってる暇はありません。
だから、無邪気に「提案」などと言っていると、相手は内心
「いや、もうやってるよ」
「外部が余計な口を出すな」
「言ってみただけ」
といった感じになります。要は、体よくあしらわれる。
実際、「悩んでいるけど、手が付けられてないこと」のほとんどは、
面倒なのでやりたくない事であったり、解決の優先度が低いものであったり、愚痴が言いたいだけのことであったりと、「解決不要」とみなされていることが多いのです。
カネが出ることと、愚痴っていることは違う。これは、提案活動において重要な認識です。
したがって、「解決しましょうよ！」とうかつに言わない事です。
では「愚痴」を聞いて、どうすればよいのでしょうか。
うんうん、と頷いているだけで良いのでしょうか。
いいえ、それも間違いです。
「愚痴」の一部は、実際に解決に向けて課題化されることも多いからです。
そこで、こう聞いてみましょう。
「すでに手を打ってらっしゃるのですよね。」と。
これで、相手の解決への本気度がすぐにわかります。
ここで「いま、〇〇という対策をとってるんです」という返事があれば、それはお客さんの中で「課題」と認識されている悩みですから、提案の余地があります。
「いや、時間もお金もないから、特に今なにもやってないよ」という返事があれば、それは単なる愚痴ですから、「そうですよねー」と言って、流しましょう。
また、注意点として「対策を取ってますか」と聞いてはいけません。詰問になってしまいますからね。
ここは自然に「皆さまであれば、もう解決に向けて動いていて不思議じゃないですよね」という雰囲気で、自然に「課題化」されているかどうかを探ります。
× 解決策を考える
〇 お客さんが今やっていることを聞く
「提案書」は極力つくらない
愚痴の中に隠れている「本気の愚痴」、すなわち、すでに何かしらの手を打っている事項に関して聞くことができたら、素直に「ウチもご支援できますよ」と言ってみましょう。
ほとんどの人は「どんなことができますか？」と聞いてくるはずです。
これが、提案の糸口になります。
が、ここで大きな注意点があります。
このラインより上のエリアが無料で表示されます。
「提案書を作りましょうか？」と、この時点では絶対に言わないでください。
理由は二つあります。
１．「提案書」は、主従で言うと、「従」であり、「主」である「提案」とは別物である
２．提案書を作る手間に見合うほどの成果は得られない
端的に言うと、提案に、提案書は必須ではない、ということです。
提案書というのは、「提案」という一連のプロセスの結果をすべて記した「まとめの文書」であって、なくても提案のプロセスは進みます。
むしろ、この時点で提案書を作ることは危険です。
この時点では「課題」を聞き出した程度であって、相手の要望や社内事情などは全く把握していない状況です。
そんな時に提案書を作っても、手間になるだけで、良い提案ができるはずがありません。
したがって「どんなことができますか？」と聞かれたら、もう少し課題を深堀をするため、すかさずこう答えましょう。
「〇〇と▽▽と□□はできますが……、逆にどのようなところでご支援が必要か、もう少しお話を聞かせていただけませんか」と。
すると、お客さんはほとんどの場合、「そもそも……」と、かなり突っ込んだ話を始めてくれます。
ただ、この時点では話がまとまっていないことがほとんどです。
そうでなければ、愚痴は出ません。
いろいろと悩んでいるけれども、何をすればよいのか、どこで困っているのかを言語化できないからこそ、愚痴が出てしまうのです。
ここまできて、ようやく「本当の提案活動」ができます。
実は、提案活動とは、解決策の押し売りではなく、相手の困っていることを交通整理して、言語化してあげる行為のことなのです。
だから、お客さんの話に対して、
「それは、こういうことですか？」
「こういうケースに似てますかね？」
「昔、こんなことがありました」
と、言い換えをしていくだけで、お客さんは「目からウロコ」だと思ってくれます。
× 提案書をまとめる
〇 ディスカッションして、お客さんの本当にやりたいことを言語化する
プレゼンテーションの前に、すでに「提案の採否」は決まっている
上のようなやり取りを複数回行い、議事録をまとめていくと、真の意味での「提案書」が出来上がります。
だから「提案書」の作成は、お客さんとコンサルタントの共同作業である、と捉えると良いでしょう。
張り切って「ウチの知見で解決できます！」なんて言うよりも、「一緒に考えた解決策」のほうが、はるかにお客さんにとっては納得感があります。
したがって、本質的には、提案は、「提案書」をプレゼンテーションする前に、すでに終わっていなければならないのです。
前述したように、提案書はお客さんとディスカッションした結果を、簡潔にまとめたものです。
だから書かれている内容は、「お客さん」がすでに納得していて、知っているもの出なくてはなりません。
もちろん例外的に、担当者や現場の責任者の「上の上の人」などの最終決裁を取り付けるために、提案書のプレゼンテーションを、エライ人たちに対して行うケースはあります。
しかしそれは、「すでに現場の人が納得」しており、「上の人に最終的に判断を仰ぐ」という形式上の問題でしかありません。
よほどの失態がなければ、プレゼンテーションにおいてその提案の採否が決まるようなことは、かなり少ないと言えます。
× 提案書をプレゼンテーションして相手を説得する
〇 提案書をプレゼンテーションするまえに、提案の採否は決まっている
「提案活動」でヒアリング／ディスカッションすべき７つの事柄
さて、「提案活動の流れ」については、上で細かく解説しましたが、その中身について、もう少し深く解説します。
具体的には「提案」には、次の事項が含まれていなければなりませんので、ディスカッションの中で、これらのことを議事とし、記録を取ることが必須です。
１．お客さんの現状
最初にヒアリングすべきは、お客さんの現状です。
現状の正確な記述がなければ、この提案にある取り組みの成果を、正確に定義することができません。
なお、現状の正確な記述のためには、可能な限り「比較可能な」数値や状態で記述する必要がありました。
例えば昔、現状を「社員の元気がない状態だ」と表現した経営者がいました。
しかし、社員の元気がない、という状態は、何をもってそう言えるのでしょうか。
経営者に「何を見て、そう思ったのですか」と聞くと、彼は
「挨拶がない」
「会議で発言しない」
と表現し、最後に「仕事に前のめりではない」
と言いました。
しかし、「挨拶がない」というのも、正確な表現とは程遠いものでした。
観察をすると、挨拶をしていない社員もいますが、きちんと挨拶を交わす社員もいます。
要するに、この経営者は「社員の元気がない」という表現を使ってはいましたが、「雰囲気」の話をしているだけだったのです。
そこで我々は、曖昧な表現を排除するため、さらに質問をしたところ、経営者は本音を語り始めました。
要は真の現状は、
「ここ数年、売上が不振である」
「売上不振の原因は、社員の覇気が足りないせいだ」
「もっとやる気を出してほしい」
ということだったのです。
つまり、経営者の感じている真の「課題」は、売り上げ不振であり、その解決策として、「社員の元気」を取り上げていただけでした。
そこで我々は、「売り上げ不振」の原因を経営者とディスカッションし、
現状の正確な把握に努めたところ、どうやら
「引き合いの数の不足」
「受注率の低下」
が、現状の大きな課題であることが、経営者と共有できたのです。
２．お客さんの要望
現状を正確に定義できれば、「どの程度の期間で」「どの程度の改善を」実現したいのか、という要望を固めることが可能です。
前述した「引き合い不足」「受注率の低下」については、今後半年で
「引き合いの数を30％のばして、3年前の水準に戻したい」
「提案を提出した案件の受注率を50％にしたい」
といった要望が、経営者から出てきました。
当初の要望であった、「社員の元気」についても、何かしらの
施策を、と経営者から出てくることも予想されましたが、結局、根源的な課題である売上の話に言及するにとどまり、要望の中に「社員の元気」が含まれることはありませんでした。
３．要望を実現するための具体的施策と効果
要望が固まれば、それに即して、専門的な見地から「どうすれば改善できるのか」という話が可能です。
その際、注意すべきは「要望」を実現するための施策は、より根源的である必要がある、という点です。
例えば、私が在籍していた会社では
引き合いの数を30％増加させる施策 → 〇〇
受注率を50％にする施策施策 → △△
というように、個別にとる施策は対処療法であり、あまり根源的ではない可能性が高いとみなされていました。
逆に、複数の課題を一気に解決する、根源的な施策を最初に考えるように、とコンサルタントは指導されていました。
例えば、以下のような形です。
引き合いの数を30％伸ばし、受注率を50％にする施策 → ■■
もちろん状況を鑑みて、個別の施策に落ちてしまうケースもあります。
しかし、個別の対処をするよりも、より多くの課題を解決する目線をもって提案することは、コンサルタントに必要な素養として、非常に重視されていました。
４．スケジュール
提案にスケジュールを含めるのは普通ですが、単なる線表を引く、というだけでは不足です。
提案時におけるスケジュールで特に重要なのは「振り返りのポイントを明らかにすること」だからです。
多くの根源的な施策は、完全な成果が出るまでに、半年、関係者が多数に上る施策では1年、2年と時間がかかるものです。
しかし、多くのお客さんは成果が出るまで、それほど多くの時間を待てることはない上に、1年後に「やはり施策が間違ってました」というわけにもいきません。
そこで、多くの提案では、スケジュールの途中に意図的に「振り返り」を含めます。
具体的には、最低でも3か月に一度、欲を言えば1か月に1回、成果に対して、どのような進捗がみられるか、方針を変更しなくてよいかを、ディスカッションする場が必要でした。
この時、ほとんどの場合、
プロジェクトの最初の1か月については
「引き合いの数を30％伸ばし、受注率を50％にする施策」のタスクがもれなく消化されているかをチェックし、
2か月目に現場での実施状況に対するフィードバックをもらい、
3か月目に、成果の出る兆候があるかを判断する、
といった段階的なチェックが成されていました。
一度プロジェクトが始まってしまうと、目の前の仕事をどうしても優先しがちで、地味なチェックの仕事、間違いを認めざるを得ないかもしれないレビューの仕事などは敬遠されがちです。
したがって、プロジェクトの提案時に、「面倒ですけど、チェックは必要です」と、差し込むことで、のちのプロジェクトのトラブルを軽減することは、とても重要でした。
５．体制／作業分担
多くのプロジェクトは、コンサルタントだけが動けばよいというものではなく、お客さんとコンサルタントの共同作業でした。
しかし、ここにもトラブルが潜んでいます。
例えば
議事録は誰が作るのか。
各部署への通達文書は誰が作るのか。
アンケートなどの集計は誰がやるのか。
計画の時には、もろ手を挙げて賛成をしていた人が、「実際に手を動かして作業してください」とお願いすると、突然しり込みを始めてしまうケースは多々あります。
そこで、提案の中には細かいタスクへの分解と、タスクごとの「業務分担表」を含めることが必須となっていました。
特に、お客さんに作業リソースを割いてもらわねばならない場合は、早めに担当者に通知が必要であるため、分担は事前に話を通したうえで、書面に落としました。
６．費用
上にあげたことをディスカッションしていれば、あとは費用の明確化をするのみとなります。
実作業としては、上の「スケジュール」と「分担」をもとに、工数を算出し、単価を乗じて費用を算出するだけですので、非常に楽です。
なお、値引き交渉があった場合、総額から5％程度、値引きをすることについては許容されていました。
しかし、その場合はあくまで「総額からの値引き」であることを強調します。工数の削減や、単価を落とすことで値引きをすることは、禁じられていました。
これは、プロジェクトの品質を保つ目的が一つと、もう一つはプロジェクトが「継続」となった場合に、「単価」が持ち越されてしまうのを防ぐためです。
７．前提条件
最後に、「前提条件」を記述して終了です。
なお、「前提条件」とはプロジェクトマネジメント世界標準の「PMBOK」によれば、「計画を立てるにあたって、証拠や実証なしに真実、現実、あるいは確実とみなした要因」のこと。
主として、災害や人災、事件事故など、想定が難しい事象が発生しないことを前提として提案しています、という「現在の状況を前提」という文言を、提案書に含めることを、リスクヘッジとして行っていました。
以上、提案実務についてのノウハウ集でした。
もちろん上に記述したことは、私が在籍していた、コンサルティング会社で実施されていたケースですので、個別の企業には当てはまらないこともあるかと思います。適宜、状況に合うよう、ご参考としていただければ幸いです。
—
【お知らせ】
Books&Apps及び20社以上のオウンドメディア運用支援で得られた知見をもとに、実際我々ティネクト（Books&Apps運営企業）が実行している全48タスクを公開します。
「成果を出す」オウンドメディア運営
5つのスキルと全48タスク
をプレゼント。
これからオウンドメディアをはじめる企業さま、現在運用中の企業さま全てにお役に立つ資料です。ぜひご活用ください。
資料ダウンロードページはこちら↓
https://tinect.jp/library/5skills48tasks/
メールアドレス宛てに資料が自動送信されます。
【著者プロフィール】
安達裕哉
元Deloitteコンサルタント／現ビジネスメディアBooks&Apps管理人／オウンドメディア支援のティネクト創業者／ 能力、企業、組織、マーケティング、マネジメント、生産性、知識労働、格差について。
◯Twitter：安達裕哉
◯Facebook：安達裕哉
◯有料noteでメディア運営・ライティングノウハウ発信中（webライターとメディア運営者の実践的教科書）