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

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

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

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

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

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

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

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

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

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

この先は会員の登録が必要です。有料会員(月額プラン)は申し込み初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら