３月１６日に出す、「コピーされるほど儲かるシステム！開発日記」第１４号について

３月１６日に出す、「コピーされるほど儲かるシステム！開発日記」第１４号は、ウィリアムのいたずらが行った場合の見積もり例です。実際に何を作るのかについて書いてあります。

----------

内容は、
ウィリアムのいたずらが行った場合の「コピーされるほど儲かるシステム」の見積もり
http://blog.goo.ne.jp/xmldtp/e/58cde1a7e9197d37e739fdd073729fff
とほぼ同じです。


----------

　で、１４号のメルマガについての、感想などはここの「コメント」にどうぞ！

　メールと、ウィリアムのいたずら自身のブログについては、このブログの
「コピーされるほど儲かるシステム！開発日記」へのメールについて
http://blog.goo.ne.jp/xmldtp/e/a58b79b40b1148c2f744556e27b76a79
を参照してください

日経ソリューションビジネスの提案書の極意のやり方を、日経システム構築で否定してなーい！？

　提案書の書き方について、日経ＢＰ社の日経システム構築と日経ソリューションビジネスで、それぞれ記事があります。
　でも、これを２つあわせて読むと、商談の極意は、日経システム構築の考え方を否定することだ、もしくは、日経システム構築の考え方では、日経ビジネスソリューションのやり方は、ありえない！！ってなっちゃうのよ(^^;)

---

　「日経システム構築」２００５月３月号「ＲＦＰに基づく提案書の書き方」の１２８ページに「ＲＦＰを十分に意識したものであるべきだ」と書いて、「しかし、実際にＲＦＰに対する回答を明文化している提案書にはほとんどお目にかかったことが無い」として、ＲＦＰを満たすことが大事だ！でも、実際には満たしていない、なんてやつって言う論調で書いてあるのよ。

　でもね、その考えで、「日経ソリューションビジネス」の「商談に勝つ提案書作成の極意」をみてね。２００５年２月２８日号のＰ６５の図２が明確にＲＦＰになってるよね（「ご協力をお願いします」って書いてあるんだもん）。つまり、
（１）課題と解決策の再確認
（２）活動のデザイン「企画提案型ビジネスにおける顧客獲得活動のグランドデザイン」
（３）営業に必要な情報の明確化
（４）情報システムの要件定義
を書けってかいてあるよね。
　ところが、その答えとして、書いてある２００５年３月１５日号Ｐ５３の提案書、
　多分この答えが図３だと思うんだけど、
（１）課題の再確認→課題も多く存在します？？
（４）情報システムの要件定義→（図３一番下の行）上記を踏まえた上での情報システム化の要件定義
なにも、答えて無いじゃん！全然、対応わかんないじゃん！！

　つまり、日経システム構築で、ＲＦＰに提案書がこたえてなーいっていうことを怒ってるけど、その書き方こそ！日経ソリューションビジネスによると、「極意！」なのよ(^^)v

---

　実際の現場でも、こういうことよくあるよね。
　課長が、「こんなやり方やるやついねーよ！そんな風にやるやつの顔が見たい」とか、ぼろくそ言ってるんだけど、まさに、そのやり方が、部長の方法のような、

　

２人の上司が言っているやり方が全然違うとき、部下の私は、どーしたらいいの？？

　っていうこと。

　今回の話も、まあ、答えておくと、日経システム構築の、「しかし、実際にＲＦＰに対する回答を明文化している提案書にはほとんどお目にかかったことが無い」わけは、実際には、ＲＦＰの書きかたって、いろいろあって、受け取る人もさまざまだから、いろんなやり方で、成功しちゃうことがあるのよ。でも、一度、それが成功しちゃうと、そのやり方が成功体験となる。
　したがって、ＲＦＰを満たさない成功体験っていうのも結構あって（営業が勢いで売る）そういう人の部下は、「おっかしいんだけどなあー」と思いながら、上司のやり方を踏襲する。その結果、百花繚乱のＲＦＰの書き方になったっていうのが、オチじゃないかなあ？って思うけど。
　だから、この極意のように、直接ＲＦＰを提案書自体は満たしているかどうか、わかんないように書く書き方も「あり！」だと思う。

　でも、部下にしてみれば、一方の上司が、「日経システム構築」方式、一方の上司が「日経ソリューションビジネス」方式だと、困るのよ！どっちのやり方に従っていったほうが、自分の身は安全か！（もう、客は関係ないっす。保身の問題です！）

---

　で、ウィリアムのいたずらの場合、どうするか？

・一番危険なのが、どっちかの上司やり方にあわせ、一方の上司を無視すること
　例えば，日経システム構築の上司を一切無視して、日経ソリューションビジネスのやり方にあわせると、あとで、「日経ソリューションビジネス」上司がはしごをはずして、「どうして、日経システム構築上司の言うようにやらないんだ！おれは、そんな指示をしていない！おまえが馬鹿だから理解できない！」と、いきなり責任逃れをされる危険がある。

・一方のやり方を踏襲し、「ところで」と話をどんでん返しさせ、後の話に持ってくる
　これは、ウィリアムのいたずらは良くやります。
　はじめに、「日経システム構築」の上司のやり方で、とりあえず書いておきます（ＲＦＰを満たして書いておく）
　で、「でも、こういう問題がある」とかあげて、あとの「日経ソリューションビジネス」のやり方にもってくる。
　もちろん、逆に、日経ソリューションビジネスのやり方で書いて、あとで、「まとめると」、として日経システム構築の話を書くとか、このバリエーションはいろいろあるけど、両方の意見を取り入れて、玉虫色にする。

・フォーマットをどっちかの上司、中身をどっちかの上司のやり方に変える
　反則技っぽいんだけど、内容が多少違っても、形式はＡ上司、中身はＢ上司のやり方という方法で両方を立てる。
　今回の場合、日経ソリューションビジネスの
　　Ｐ５３ページ図３、２つの中見出しがありますが、この中見出しの上のほうを
　「課題と解決策の再検討」
　下の見出しのほうを
　「営業に必要な情報の明確化」
　図４の大見出しを「活動のデザイン」
　図５の大見出し（プロジェクトアプローチ）を、「情報システムの要件定義へのアプローチ」

　とすると、「ばっちり！」日経システム構築上司（＝ＲＦＰの内容）のやり方を満たしているように見えます。
　中身は、「日経ソリューションビジネス」上司のやり方だけど。

---

　でも、サラリーマンの場合、怒られてなんぼで、お金もらっているっていうことは確かなわけで、このように、上司がまったく意見が違う場合、どっちなの上司に怒られることは必至。
　まあ、無理にがんばんないで、どっちかに怒られ、嵐の過ぎ去るのを待つしかないのかな？

　まあ、どっちにしろ、大手の雑誌に載せるくらいなんだから、どっちも偉い人なわけで、その人の意見すらまとまんないんだから、正しいやり方、心に響く提案の仕方なんていうのは、決まりが無いんだろうね。