#はじめに
エンジニアであろうと、「提案書作成」をする（させられる）ことがあります。
この「提案書作成」がうまくできるかどうかは、直に受注に繋がるわけで、一つのプログラミング言語を習得し実装できること以上に大切だったりします。
「提案書作成」はエンジニアにとっても一つのスキルなわけです。
#提案書を書くのは難しいのか？
提案書を書くのは、はっきり言って難しいです。
なぜならば、世の中には「提案書の上手な書き方」と題したフレームはたくさんあるものの、具体性が伴っていないからです。
このフレームってやつは、ほぼ間違いなく下記です。
1.御社の課題は◯◯と××と△△です
2.これらを整理すると「こう」なります
3.これらの解決策は「こう」です
4.それぞれのメリット・デメリットはこうです
5.よって「これ」がいいです
これを書けと上からも言われます。
（口で言うのは超簡単です）
#提案書を書くのはなぜ難しいのか①
先方から◯◯したいと聞けば、ある程度の経験があれば即座にこうすると良いといったことが思いつきます。
この判断は自社の実績や経験に寄るところが大きく、実績や経験があるほどぱっと提示できます。
そのため、提案書は「答えは〇〇です」といった結論ありきになります。
言い方を変えると、提案書（フレーム）はボトムアップ的であるにも関わらず、頭の中はトップダウン的になってしまっているわけです。
なので、必ず顧客とのギャップを生みます。
さらに言い換えると、本来は課題を細かく分析して結論をだすべきなのに、外部的要因（自社のリソース等々）から結論の押し付けになってしまうわけです。
#提案書を書くのはなぜ難しいのか②
人間には感情があります。感情に伴ってありとあらゆるものに対してバイアスをかけてしまいます。
当たり前のように提案内容がまったく同じであっても、キレイな提案書と雑多な提案書があれば、キレイな提案書を書いた方を選択することでしょう。
このありとあらゆるものに対してかかるバイアスをコントロールするのが人間だからこそ難しいわけです。
今までの経験上、これはこうやって解決できるとぱっとわかってしまうが故に、現状の分析ができずに、提案が押し付けになってしまいます。
顧客が本当に求めていることは、ボトムアップ的な現状の課題解決にも関わらず、トップダウン的な課題解決になってしまいます。
#どうすればいいのか
解決策をぱっと出さないことが大切です。（そして、解決策をぱっと出せるオレかっこいいと思わないこと）
フレームは決まっているので、このフレームに沿って分析を行うことが必要です。
具体的にやるべきことは下記になります。
1.現状の課題をインプットする
2.課題を整理する
3.解決案を複数出す
4.解決案のメリット・デメリットを考える
普通は、3の解決案を出す上で、１が甘かったり、2がイケてなっかったりし、一回キレイにまとめたものをやり直すといった面倒なことをやる必要があります。（ここにも「せっかく頑張ったのに」バイアスがかかります）
提案書はありとあらゆる外部要因が重なって、ありとあらゆるバイアスを生じるが故に難しいわけです。
#最後に
このように考えると、エンジニアがあまりもっていないスキルである、「パワポ作成能力」と「ビジネス的な人脈」をたくさん持っているコンサルさんの必要性がわかります。
彼らは、システムを実装する能力がないが故にトップダウン的な解決策の提示にならず、ボトムアップ的な顧客の要望に沿った提案書が書けるわけです。
#最後の最後に
両方できた方がいいに決まっているので、世の中のエンジニアの皆さん、がんばりましょう!!!
#参考
『ギリギリまで「まとめに入らない」能力』 by ちきりん
http://d.hatena.ne.jp/Chikirin/20111124