提案書の作成はどうしても毎回バタバタする。経験豊富なシステム開発のPMからは、RFP(提案依頼書)で聞かれていることに回答するだけなんだから、計画の立て方が悪いんじゃないの?といった冷ややかな目で見られたりする。ところがこうした開発PMが、提案書作成で失敗することは珍しくない。

 計画を立ててそれに従って進めるというのは、開発プロジェクトと変わらないはずだ。提案の全体構成を定めてタスクにブレークダウンし、提案チーム内で役割分担して定期的に確認していけばよい。そう考えて取り掛かるのだが、それで済むほど甘くない。

 開発プロジェクトがプロフィットセンター、つまりお金を稼ぐ活動であるのに対し、提案書作成はコストセンター、つまりお金を使う活動である。このことは、要員の稼働が保証されないということを意味する。しばしば「重要プロジェクトが火を吹いたから人を回してほしい」と要員が半減する。

 さらに、「提案先の部長が海外出張なので、提案が2週間前倒しになった」とスケジュールが短縮になったり、「顧客のキーパーソンはクラウド利用に慎重という情報があるから、構成を見直すべき」と内容も変わったりする。

 要員もスケジュールも内容もふわふわで確定しないない中、受注という目的を達成できる品質を確保しなければならない。それには、成果物の濃淡を意識したプロジェクトの進め方が求められる。これがなかなかできない。

提案目前の巨大Excelシートに驚く

 筆者配下の開発リーダーを中心に提案書作成を進めたときの例を紹介しよう。RFP提案で、100ページを超える提案書を作成した。十分な時間をかけて準備していたが、提案の2週間前になって、提案書のドラフトではなく巨大なExcelシートが出てきて驚いた。

 提案リーダーは、RFPの全項目について内容を確定してから、提案書のテンプレートに流し込んで完成させる計画だった。あと1週間でExcelを完成させ、残り1週間で仕上げるという。一覧性が高く、編集もしやすいExcel上で検討するほうが効率的だというのは一理ある。しかしそのまま進めるのは危険と判断し、方針転換した。

 単体プログラムを作って単体テストで品質を上げ、最後に結合すれば完成といった感覚だ。この進め方は前述したような計画の急な変更に弱い。加えて、完成後に全体を通して読んだら納得感が弱いという話になるが、その時点で手遅れになることが多い。

 システムは全体を通して均質に作る必要がある。しかし、提案書は違う。顧客が気にしていると思うところは、これでもかというくらい懇切丁寧に記述する。気にしていないところは、簡潔に記述すればよい。こうした濃淡は、実際に書き込んだ提案書で、テキストの量も見て考えないと分からない。