提案書作成の実践テクニック【前編】

行動促すストーリーを

2006.09.08

ITエンジニアが持つべき提案力は，3つに分けられる。第一は，ユーザー企業の置かれた状況や自社の強みを理解する能力，第二は，それをもとに，ユーザー企業に意思決定を促す提案書を作成する能力，第三は，提案書の内容をユーザー企業に正しく伝えるプレゼンテーション能力――である。この流れに従って，提案力を向上させるポイントやテクニックについて解説していこう。

袖山欣大（そでやまよしひろ）
野村総合研究所　営業開発部統括担当部長

ユーザー企業の情報を集める

　提案書を書くためにまず必要なのは，ユーザー企業の置かれている状況を正しく理解することだ。

　提案書の作成前に最低限調べておくべき項目を表1に示した。ユーザー企業はどんな業種で，業界何位の事業規模か。また売上高と営業利益はどの程度で，今回提案する部門の売上比率はどうか，平均年齢は何歳か…。こうした様々な情報を事前に調べておく必要がある。

表1●日本IBMにおける要件定義のプロセス
相手を知り尽くさなければ，相手の課題や置かれている状況，具体策を見いだすことはできない。提案書を作成する際は，最低限これらのことを前もって調べておく必要がある
[画像のクリックで拡大表示]

　ある程度大きな企業になれば，「会社四季報」や「日経会社情報」などで容易に調べられる。また，日頃から新聞や雑誌，ニュースサイトをチェックして，ユーザー企業の情報を集めておくことも大切だ。

　会社の基本情報とソリューション提案が無関係だと思ったら大間違いである。相手を知り尽くせば，自ずと課題やその対応策が見えてくる。裏返せば，情報収集を怠ると，的外れな提案書しか作れないことになる。

　例えば，業界全体が抱えている経営課題があるとする。たとえ厳しい不況の業界でも，その課題の解決が成長戦略に欠かせない要素であれば，企業は積極的に投資するだろう。また，平均年齢が高い会社だと分かれば，操作性を考慮したユーザーインタフェースをアピールするという手もある。

　案件が寄せられた経緯も重要な情報である。付き合いの深い既存顧客からのものか，あるいは新規顧客がいきなり代表電話にかけてきたのか，それとも展示会やセミナーがきっかけで連絡が来たのか――。

　最近はどんな案件でもコンペにする企業が多い。だが代表電話にかかってきたり，展示会のアフターフォローから突如「沸いてきた」案件は果たして勝ち目があるのだろうか。他社の影がちらつき，もともと出来レースを感じさせる案件の場合，辞退するのも1つの選択肢だ。

　ただし，どうしても受注したいという場合は，“裏技”を使う手もある。例えば，「貴社が提出したRFPは，○○と××の部分がそもそも間違っている」という逆提案を行い，ライバル企業のこれまでの努力をリセットしてしまうのだ。こうした裏技を使うかどうかを判断するためにも，ユーザー企業との付き合いの経緯はきちんと押さえておくべきである。

提案書とは「ストーリー」だ

　必要な情報を収集したら，いよいよ提案の内容を作り上げていく。

　まず注意して欲しいのは，構築するシステムの概要や自社が取り扱う製品やサービス，期間や金額は提案書の大切な要素だが，単にそれらを記すだけでは受注には結びつかないことだ。提案書はプロジェクトを遂行するための手順書ではなく，ユーザー企業にソリューションを納得してもらうための「ストーリー」だと考えるべきである。ユーザー企業に意思決定と行動を促すためには，ユーザー企業の抱える課題に対し，それをどう捉え，自分たちだったらどのように解決するかを提示しなければならない。

　ではストーリーはどのように構成すればいいのだろうか。ここでは筆者らが実際に行っている，「I，S，O（アイ・エス・オー）」という3つの要素を用いてストーリーを構成する方法を解説する。

　I，S，Oとは，「Issue（ユーザー企業の抱える課題構造）」，「Solution（課題を解決する具体策）」，「Operation（プロジェクトの運営方法）」の頭文字を取った言葉である（図1）。

図1●提案書に盛り込むべき3つの要素
提案書作りの基本は，「Issue」，「Solution」，「Operation」の3つの要素を軸に，ストーリーを展開することだ。この3つの要素によってユーザー企業の意思決定と行動を促す

気付いていない課題がある

　I（Issue）は，ユーザー企業の抱える課題構造を明らかにするものだ。自分たちがユーザー企業の課題をどう理解したのか，なぜユーザー企業が今の時期にこのプロジェクトに取り組む必要があるのかなどを，競合他社にはない独創的な視点で分析してみせる。

　Issueを示すことで，ユーザー企業に「課題を解決するために，このプロジェクトには早急に取り組まなければならない」ということを再認識させる。そのためには，ITベンダーはRFPに示されたニーズだけでなく，ユーザー企業自身が気付いていない“隠されたニーズ”を探し出し，それらを課題として構造化する必要がある。

　「ユーザー企業自身が気付かない課題構造を，どうやってITベンダーが見つけられるのか」と思う方もいるかもしれない。だが覚えておいて欲しいのは，ユーザー企業よりも外部の人間の方が，Issueを構造的に把握しやすいということだ。

　自分の会社の問題に置き換えてみれば分かるはずである。ある業務の担当者は自分の担当以外の業務は案外知らないものだ。提案するソリューションの範囲が大きくなればなるほど，影響を与える業務や部門も多くなる。したがって，それらをよく調査すれば，RFPを提出した担当者の想像をはるかに越えるIssueを提示することは，決して難しいことではない。

　そのうえ，ユーザー企業は往々にして自分の会社や業界のことを「特殊」だと思い込んでいる。このため他社や他業界の状況を熱心に研究することはほとんどない。そこで，こちらが他社や他業界の例をうまく使ってIssueを説明できれば，インパクトのある提案を行える。

　Issueではユーザー企業に対して，「今，抱えている課題は何か」，「その課題によってユーザー企業は具体的にどういう状況に置かれているのか」を認識させることに主眼を置く。図2は，OA機器メーカーであるABC社の，業界内でのポジションを示した例だ。図3は，具体的な数値を使い，ABC社の営業人員が多いこと，1人当たりの売上高が少ないことを示したものである。このように様々な切り口でユーザー企業の抱えている課題を分析し，目に見える形にする。