こんな私なので、提案書作成について、これといった方法論を持っているわけではない。しかしそれでもいつも気をつけていることはいくつかある。なかなか見落としがちなポイントなのではないかとかねてから思っていたので、少し書いてみる。
ひとつは、提案に先立ってお客様からヒアリングした内容を、自分のことばに置き換えて書くということだ。システム構築に関するおおかたの提案書では、適用する技術とかツールについて詳しく書かれているが、お客様の話したねらいとか現状業務の問題については、せいぜい１ページか２ページでかるく確認する程度で済まされている。しかし、お客様にとって本当のところ一番の不安は、ベンダー側（すなわち、われわれ）がお客様と同じ目線で状況や問題を理解してくれているかどうか、のはずだ。その点に不安があると、いくらソリューションを提示されても、お客様としてはいまひとつ「これだ」と思えなくなる。だから私は、自分たちがお客様の問題認識を理解しているということをなんとかお客様に伝えたい。いちばん嬉しいのは、お客様に「これ、これ、まさにこれが言いたかったんですよ！」と言って頂くことだ。そうなれば、未来はかなり明るくなってくる。ここでのポイントは「自分のことば」という点だ。ヒアリング議事録からお客様のことばを抜き出して書いてもだめだ（もちろん、別の意図でそうすることはある）。相手のことばを繰り返しても、それは耳が聞こえていることの証拠にこそなれ、こちらが相手の意図を理解しているということが伝わらないからだ。また、お客様の言ったことを分析して図や表にしたり、お客様とはちょっと異なる視点からながめた意見を提案書に含めると、お客様の信頼感はいっそう増すかもしれない（「はずす」かもしれないが）。
このとき、こちら側の理解に誤りがあってもたいした恥ではない。ふつう、提案書を出す前に２回か少なくとも１回は事前打ち合わせをするから、そこでお客様からフィードバックを頂いて直せばよい。プロジェクトの開始前こそ、もっとも盛大に誤解をしても許されるタイミングなのだ。プロジェクトが進むにつれ、間違いの許容幅はふつう小さくなっていく。最初にぎょっとするような間違いをしても次にそれをきっちり正して提案書を持って行けば、だいたいのお客様は許してくれる（許してくれない場合、本当にそのお客様とこれから付き合っていって大丈夫か考えた方がよいと私は思う。われわれは、しょせん間違いをおかすものなのだ）。理解が一致しているかどうか、いつまでもはっきりしないもやもやした状態が続くことが、お客様にとっては（そしてわれわれにとっても）一番のストレス源になる。
もう一点は、プロジェクトに関して現時点で自分たちが感じている不安を書き尽くすことだ。たとえば、経営陣からのサポートが心配ならそれを書く。スコープが曖昧ならそれも書く。技術面での不安も書く。全部書く。
書いた上で、それらの不安に対処するための方向も仮説ベースでよいから書く。経営陣に、たとえばプロジェクトのどの段階までにどういう判断をして頂ければ安心できるのか、スコープが不安なら、ある一部を除外するとか、段階的に導入することにすればどうか。ポイントは、「不安（格好よく書くと『懸念事項』）」と「対処の方向」を対応づけて表形式で書くことである。対処だけ書くのは良くない。お客様はまず「不安」に共感するのであって、そこではじめて「対処」の方にも目が向くのである。また、提案段階ですべての不安要素を見切ることはできないし、対処についても仮説ベースに過ぎない。だから「不安」を列挙したからといって、かならずしも解決したことにはならない。それでも列挙するのは、われわれがお客様と同じ目線で（さらに望ましくはシステム構築の経験者としての視点も加えて）プロジェクトに取り組むことを理解して頂きたいからである。また、不安と対処を書くことで、プロジェクトが潜在的にどのくらい拡大する可能性（あるいはリスク）があるのかも共有できる。これによってお客様もわれわれも「心の準備」をしておける。不安を書きすぎると、こちらの能力についてお客様が心配しないかとお思いになるかもしれない。しかし、われわれが感じるような不安は、だいたいお客様の側でもなんとなく気付いているものなのである。それを明確に書くことはかえって相互理解と信頼につながる。それに、書くことによって不安を客観化すれば、対処の方法も冷静に検討できる道が開ける。不安がもっともリスクになるのは、もやもやしている時だ。
以上、二点を挙げたが、共通する意図は、プロジェクトの道行きを一緒に歩く「旅の連れ」としてお客様に受け入れて頂く、ということである。もちろんビジネスである以上、お客様とわれわれの利害が100％一致することはありえない。しかしプロジェクトが成功するかどうかは、お客様とわれわれ双方の幸せにとってもっとも重大な問題だ。お客様が「失敗した」と感じているのにわれわれの側のメンバはみんないきいきしているプロジェクトなどありえない。だから、共通の問題に対して、いかに同じ目線で、しかし異なるスキルをもって取り組んでいけるのか、ということが、お客様にとってもわれわれにとっても一番だいじなことであるはずだ。お客様はRFPで「ベンダー」や「コンサルタント」を求めていると書くかもしれないが、ほんとうは「旅の連れ」を求めているのだと思う。そしてわれわれもまたそうなのではないか。
