筆者は中途採用の技術者をコンサルタントとして養成するトレーニングを長年行っている。その仕上げが提案書作成の演習である。コンサルタントは自分を売り込むことができて一人前という考えから、提案書作成は必須のスキルと位置づけている。今回はこの演習を通じて気づいた技術者の提案書の弱点を示し、どうすれば評価を上げられるのかを紹介したい。

 トレーニングの受講者はコンサルタントに必要な一連のスキルを学んだ後、数日間で提案書を作成する。その中身はさまざまだが、提案に不慣れな技術者の提案書には共通の弱点がある。「なぜ自社なのか」を示すことだ。その考え方は簡単で、提案した内容を成功させるのに不可欠な要素が自社の得意領域であると示せばよい。例えば不可欠な要素がビッグデータに関するものだとしたら、それに強いことを主張する。ほとんどの受講者は「当社はビッグデータ活用の実績があり、経験者も多数在籍しています」と書いてくる。しかし、これは提案としてポイントにならない。

 技術者の働いている世界は、正しいことを正しく伝えなければいけない世界である。そのためか、本当のことを言えば信用してもらえると思っているフシがある。しかし、提案書が評価される環境はそうではない。提案はたいてい複数社によるコンペである。他社の提案書に何が書かれているかを想像してみよう。どの企業も前述したようなことを書くに決まっている。顧客はそうした提案書をどう見ているか。書いている内容が本当かどうかは分からないし、どの企業の実績が豊富なのかも分からない、と見ているのだ。提案の現場は、本当のことを書くだけでは信用してもらえない世界である。自社が強いと主張するには、その証拠を見せる必要がある。

 筆者は複数の提案書を見比べる機会があるが、採用される提案は「なぜ自社なのか」の説明がしっかりしている。中でも戦略コンサル会社の提案には感心する点があり、筆者はこれを「リフレクティブな証明」と名付けてノウハウ化したいと思っている。リフレクティブとはオブジェクトがそれ自身の構成情報を取得できるということで、ここでは提案書自体がその内容を証明する構造になっていることを指す。

 戦略コンサルはRFPの記述が不十分で、曖昧にしか書いていなくても、それを補完する情報を独自に調査して加える。そうした上で分析し、結論の仮説まで立ててくる。つまり、提案書作成時にコンサルティングを行うのだ。そうすることで、今回の課題に対して十分な知識を持っており、結果を出せることを提案書自体で実証するのである。このため提案書作成には手間と時間がかかるが、出来上がった提案書には有無を言わせない迫力がある。

 IT提案の場合でもリフレクティブな工夫を施しているものがある。例えばビッグデータ活用のノウハウが豊富という主張であれば、顧客の実際のデータをどう扱えば何ができるかを示すといった具合だ。

 こうした提案は、案件を獲得した後の遂行能力と技術的な応用力を示している。少ない材料を想像力で膨らませているので、求められているものと違ってしまうリスクがある。また、示した分析内容や設計内容が不十分であればスキル不足を証明してしまいかねない。しかし、このアプローチにぜひトライしてほしい。そうすれば、コンペ結果の納得感が違ってくる。

 コンペでは不本意な相手に負けたり、内容や価格に納得できない案件を引き受けざるを得なくなったりすることがある。それは多くの場合、IT案件を獲得できるかどうかが案件遂行能力ではなく営業の提案力にかかっているからだ。技術者から見て不本意なコンペ結果にならないようにするには、提案活動に技術者が深く関与し、実力を証明するリフレクティブな提案書を作る。それしかないと思う。

林 浩一(はやし こういち)
ピースミール・テクノロジー株式会社 代表取締役社長。ウルシステムズ ディレクターを兼務。富士ゼロックス、外資系データベースベンダーを経て現職。オブジェクト指向、XMLデータベース、SOA(Service Oriented Architecture)などに知見を持つITアーキテクトとして、企業への革新的IT導入に取り組む。現在、企業や公共機関のシステム発注側支援コンサルティングに注力