提案書はプレゼン資料ではない。契約書の内容を補完する役割も果たすので、正確に書かれていることが重要だ。そのため発表者には、細かく正確に書かれた資料を、決められた時間内に要領よく説明することが求められる。

 提案書作成は、あまり口が達者ではないITエンジニアにとって力を発揮しやすい作業である。とはいえ、やはり説明は重要だ。今回は失敗事例から、提案書の発表時に覚えておいてほしいことを伝えたい。

 あるシステム開発の発注側のプロジェクトマネジメントを支援するコンサルティング案件の話だ。そのときの提案書は、部門長である筆者とコンサルティング部のマネジャーが準備した。自社にとって得意分野でもあり、そこそこ説得力のあるものに仕上がっていた。提案の場には、筆者、マネジャー、担当予定のPM、営業の4人で臨んだ。提案書の説明はPMが行った。

 提案書はそのプロジェクトにアサイン予定のPMが準備するのがベストだ。しかし提案時点でそのPMは、既存案件のマネジメントを担っていた。しかも、プロジェクトの終盤なので、多忙を極めている。そんな中で、次の案件の提案準備まではしてもらえない。その提案では、PMに筆者らが作成した提案書を予習してもらい、説明に臨んだ。そのPMは、提案書をしっかり読み込んでくれており、内容の説明は申し分なかった。

 説明が一通り終わってから、ひと波乱起きた。顧客の責任者から、提案書には書かれていないプロジェクトの詳細な進め方を質問されたのだ。ここで、PMは、答えに詰まってしまった。質問されたポイントは、提案書からでは方針が読み取れず曖昧だったため、回答に迷いが生じたのだ。それを察知したマネジャーは、すかさずフォローを入れた。その後続いた質問にも丁寧に答えて、提案の説明は終了した。

 提案の帰り道、マネジャーは筆者に「ちょっと私がしゃべりすぎましたかね」と言ってきた。そこは筆者も気になっていた。PMの第一印象が悪くなったかもしれない、という気がしたのだ。数日後、営業から失注したとの報告が入った。マネジャーと筆者の予感は的中した。「提案内容は良かったが、そのPMに頼れるかどうか確信が持てなかった」ということだった。

提案は一発勝負ではない

 では、どうすればよかったのか。本来、アサイン候補のPMが提案の方針を策定すべきだ。あるいは、どんなことにも答えられるだけ読み込むべきである。しかし、それができるなら苦労はしない。いつもベストな状態で提案に臨めるほどの余裕はないのだ。

 この局面だけ捉えると、内容の正確さを取るか、第一印象としての信頼感を取るか、究極の選択である。不正確な内容を適当に答えれば、顧客にとっても自分たちにとっても大きなリスクになる。かといって、答えなければPMとしての信頼を失ってしまう。