システムエンジニアの晴耕雨読

内山力「ソリューションビジネスのセオリー」

　
　既存の人月ベースの「システム開発」を提供するビジネスモデルから
　ハードウェア・ソフトウェア等を統合して顧客の課題を解決する「ソリューションビジネス」
への転換。
　企業レベルとその中核となる「提案型ＳＥ」についての要素・モデルを
５０の観点から整理されています。

　その中でも、提案にあたってのユーザーへのインタビュー時の観点や
その後のユーザーニーズの整理の仕方、
提案書のまとめ方とプレゼンテーションでの考慮事項等
改めて整理されてみると、非常に納得しました。

　日頃、提案書の作成を求められ、これは営業の仕事ではないか？と
疑問（不満？）を持たれているＳＥの方であれば、一読要だと思います。
・・・内山さん、明快に、これはＳＥ・・提案型ＳＥにしかできない仕事だ、
と繰り返し述べられています。

　最後のハードベンダー、ソフトハウス、異業種から「ソリューションビジネス」への
参入に当たっての課題（各々の弱点）の指摘は図星であり、思わずニヤリとしてしまいます。



・ソリューションベンダーは、ソリューションビジネスを実現するために、
　ＳＥに「ユーザから言われたとおりに仕事を正確に早くやる」というスタンスから、
　「ユーザーの課題の解決策を提案する」というスタンスへの変更を求めました。

　→　このＳＥを「提案型ＳＥ」と呼ぶ。


・システム開発　　　　　　：　「プログラムとデータ」に着目
　ソリューションビジネス　：　「データとその使い方」＝オブジェクトに着目

・「原価見積」＝「いくらかかるか」から
　「投資金額提案」＝「いくら投資するのが妥当か」へ
　　・・・　ＩＴ分配率（＝売上げ対比の投資額）で判断

・「ソリューションはスポーツのようなものです。
　　ルール、原理・原則を知り（知識）、やり方を覚え（ノウハウ）、
　　そしてやってみる（経験）ことです。」

・ユーザーへのインタビューの観点

　「ソリューションベンダーにおけるニーズとは、
　「ユーザーが抱えている課題のなかで、データを提供することで解決できる課題」
　と定義することができ、
　これを聞くのがインタビューテーマとなる」

・「インタビューで正確に伝わるのが１／３、
　　忘れ去るのが１／３、
　　誤解されるのが１／３」

　→　だから、受け取ったニーズを、ユーザーに文書としてフィードバックして確認してもらうこと。


・提案書の位置づけ

「ソリューションビジネスにおける提案書の目的は、
　「ユーザーにそのシステムを買ってもらう」ということであり、
　　いってみればユーザー毎に個別に作る製品パンフレットのようなものです。」

「提案書はその提案したシステムを受注後に設計、開発、運用していく責任者が作るべきです。
　つまり受注後にできるプロジェクトのリーダーであるＳＥが作るべきです。

　冷静に「できること」「できないこと」を切り分けられるＳＥが作ることが、
　ベンダー・ユーザーの双方に幸せをもたらすことは少し考えればわかることです。」

・プレゼンテーションの位置づけ

　「提案書を説明する」ためではなく、
　
　「提案書を見てユーザーがわからないところ、提案書が間違っているところ」を
　　ユーザーに教えてもらうために行う。

　「意思決定者が、はかりにかけて判断をするための正確な情報（費用見積、効果見積）を
　　提供することにあるのです。
　　この情報を意志決定者が持っていないので、意思決定をためらっているのであり、
　　情報提供がソリューションベンダーに求められていることを肝に銘ずるべきです。」

・プレゼンテーション能力とは・・

「どう考えても「正確にもれなく」考えていることを相手に伝える能力のことでしょう。
　・・・内容どおりに伝達されることを考えるべきです。
　逆にいえば内容以外のこと（誤解）が伝わらないことも大切です。」

　×ハッタリがきくタイプ
　○まじめでやや暗いタイプ