※2012年12月1日より新ブログに移行しました。よろしければこちらもご覧ください。
free to write WHATEVER I like
January 17, 2012

「80点主義」は、最初から100点を目指すつもりでやって初めて80点の出来になる

拍手してくれたら嬉しいな⇒
 私のクライアントにはSIerが多く、営業担当者のコンサルティング営業力・ソリューション営業力を強化するための研修や、研修に付随するアクションラーニング的な仕事を幸いにも結構たくさんやらせてもらっている。ここ数年で、何百人もの提案書(研修で作成した提案書だけでなく、実際の商談で作成した提案書も相当数に上る)のレビューをさせてもらう機会に恵まれた。

 クライアント企業の関係者と話をしていると、「営業はスピードが命だから、提案書が多少粗くても顧客のところへさっさと持っていくべきだ」、「失注したら提案書はムダになるのだから、完璧に作ろうとしなくていい」、「営業は無償のサービスだから、提案書を細かく作り込む必要はない(営業担当者の人間的魅力で勝負すればよい)」といった声を時々耳にする。その一部は確かに私も納得できる。営業には競合を出し抜くぐらいのスピードがないとダメだし、失注する可能性が高い案件にまでわざわざ全力を注ぐ意味はない。しかし、だからといって提案書に多少の穴があってもよいという考え方には、個人的には賛同しかねる。

 システムというのは全く融通が利かない製品であって、プログラムを1字でも間違えると平気で落っこちる。私がSEとしてキャリアをスタートさせた時、私の先輩が移行対象データを抽出する条件式の不等号の向きを逆にしてしまったがために、本来移行すべきデータをあやうくほぼ全部消し去ってしまうところだったことがある(不等号が逆向きという程度ならコンパイルは通ってしまうので、プログラムを動かすまでバグに気づかなかったのである。一応、バックアップデータがあったので何とか事なきを得たが・・・)。

 そういうシビアな製品を扱っている企業の提案書に、ちょっと読むだけでもおかしいと思うほどの”穴”があったら、顧客はどう思うだろうか?少なくとも私ならば、その会社にシステム構築を任せるのは相当不安に感じる。だから、私が提案書レビューをする際には、提案ストーリーのロジックが通っているかどうかに非常に気を配っている。

 もちろん、商談の段階で顧客から必要な情報を全て完璧に引き出すことなど到底不可能だし、要件定義が始まってから顧客のニーズが変化することもザラであるから、本当の意味で100%非の打ちどころがない提案書を作成することは土台ムリな話である。とはいえ、限られた情報しかなくても、その情報を使う限りにおいて完全と言える提案ストーリーを目指すことは、非常に重要であると思う。

 これは何もSIerに限った話ではないはずだ。どんな製品でも、些細な機能の不備が品質全体に深刻な影響を及ぼすものである。だから、一部の例外を除いて(企業の戦略上重要度が低い案件や、当て馬扱いされていることが見え見えの案件など)、基本的には100%の完成度を目指すつもりで提案書を作成する心構えが必要ではないだろうか?

 トヨタには、1966年に発売された初代カローラの開発主査である長谷川龍雄が打ち出した「80点主義」という考え方があるそうだ。製品の完成度を高める一方で、一部の飛び抜けて優れた機能や性能を追いかけることなく、まず全ての項目において最低でも80点を目指し、及第点に達した後にさらに上の点数を順次達成していくトータルバランスを念頭に置いた企業思想であるとされる(※トヨタ自動車のWikipediaより)。

 この80点主義は企業経営の他の場面にも援用される。例えば、事業戦略は構想が80点ぐらいでき上がったら実行に移し、走りながら修正を加えて100%を目指せばよいと言われる。とりわけ、意思決定に必要な情報が事前に十分に手に入らない場合には、80点主義で行こうとすうスタンスがよく見られる。冒頭で紹介したSIerの関係者の言葉も、80点主義の表れであろう。

 だが、80点主義という言葉に関して誤解してはならないと思うのは、最初から80点を目指しているうちは、決して80点にならないという点である。最初から100%を目指しているのだけれども、それでも情報が不十分であるがために、結果的には80%程度に落ち着くということに他ならない。私が提案書をレビューして感じるのは、最初から80点を目指している人の提案書は、60点ぐらいの出来にしかならない(研修で学習した”提案ストーリー構築のポイント”を踏まえてアセスメントシートを作り、実際に提案書を採点してみると、如実にその傾向が出る)。

 60点の提案書でも、これまでの顧客との関係や、営業担当者に対する個人的な信頼によって受注できることはあるだろう。しかし、そうやって受注してしまった案件は、その後の開発フェーズで、顧客の細かいニーズを聞き漏らしたり、SEに対して仕様を的確に伝えられなかったり、顧客に説明していなかった製品上の制約条件が顧客側の重要な要求を阻害することになったりと、プロジェクト炎上の種を次々と内在させることになりかねないと思うのである。

おススメの書籍

トラックバックURL

このエントリーのトラックバックURL:

コメントする