システム開発の提案書

RFPにもよりけりなのだけど、今の提案書って、会社が違っていても、それほど差別化できるものはない。技術が標準化され、調達品も平準化され、特別、厳しい非機能要件とかなければ、だいたいサーバー構成とかに差は出ないよな。インターネットの商取引とかだと、セキュリティやセッション管理など、不特定の利用者アクセスへの対応が重要だけど、それにしたって、技術的にやるべきことはそれほど違わない。また、アプリケーション開発もJ2EEベースやDotNetベースが多いので（あとはCOBOL継承か）
これまた作る作り方にもそれほど差はでない。（実力には違いがあるだろうけど）

だとすると、差をつけるのは、コストか、期間か。

それだと、単純に早く作るか、安く作るかしかなく、ムダ取りをしていく、工程を圧縮するしかないんだけど、そうするとやり方は、単価の安い人で作る、自動化を推進する、って方向にしかいかない。(いや、うちはスーパーアーキテクト集団だから、生産性は、10倍。従って、単価高い分かけても、３分の１でやれますよって本当はいいたいけど）

じゃあ、提案書では、その生産技術に特徴があるっていうしかないか。
工程自動化ツールを使っているので早いですよとか、
オフショア一杯やるので大丈夫ですよとか書けばいいじゃん、
しかも、それでも品質は高い。
なぜ、安くしても、品質が高いのか、それは、こうやっているからです
徹底してこれが言えれば、少なくとも特徴は出るかな。

あとはRFPの裏に潜む、もともと発注側の抱えている課題や問題への理解とそれへの対応を考えて、一般的な機器、ソフト、言語をこういう形で活用していくことが重要ですよ、、、、
なんて、気持ちに届く、提案って手もある。

いずれにしても、提案書はパーツだけそろえればいいってわけじゃなく、
（だって、パーツになるものは、すでに標準化されたもの多いし、差別化できないものが多いから）
まして、それの組み立て順序だけを示したおうな、アウトライン、目次構成から入るものでもない。もちろん、パーツも構成は重要だけど、一番大事なのは、全体のストーリー固めだとおもう。

差別化しにくい時代の提案書を作成するのだから、まず、主張を明確にして、何で戦うかを示すのがいいだろうと。生産技術でいくのか、お客様のパートナーとしての提案なのか、・・・
もちろん、開発できることは当たり前。

しかしなあ・・・
｢んー、やっぱ全体感が大事だよな、主張がないんだよ、なぜそう思うのかが書けてない｣
っていわれてもねえ、それを書くには、しっかりと全体イメージを確認して、どういった提案ストーリーでいくべきか、それから入らないとぶれるんだよ、、、

だから、そこから議論したいといったじゃん。

本気で戦う気があるのかね？

しかも高みの見物的に、そうじゃないんだよ、といわれてもね。

そりゃ、違うよね。