日経ビジネス 2006年10月23日号の特集は、日本一○○を売るセールスマン・セールスウーマンの記事だった。この特集記事には10人以上の日本一が登場する。セールス日本一の秘訣というか、共通の特長はあるか考えてみた。
ひと言で言えばお客さんの立場にたって何が求められているのかを自分なりに考え実践し、目的を達成するための努力を惜しまないということだろう。
ここで考えてみたいのは、セールスマン・セールスウーマンは顧客に直接対応するフロントエンドのパーソンで、ものづくりをしているメーカーから見た場合でも自分たちの商品をユーザーに売ってくれるという意味で彼らはフロントエンドだということだ。
セールスマン・セールスウーマンはメーカーと同系列の社員であるとは限らない。独立した販売店なら複数のメーカーの商品のうち、お客さんが求めていることを聞き出して「ピタッと」きている商品を勧める。
だから、メーカーは日本一のセールスマン・セールスウーマンに成り代わってユーザーが求めていることを調査・分析し、その要求にピタッときた商品を開発しなければいけない。
そうすれば、メーカーの系列ではない独立した販売店の店員も、自分たちの商品を紹介してくれる可能性が高まる。
この話は部品の供給者や、ソフトウェアの受託開発業者にとっては関係ないと切り捨てない方がいい。なぜなら、メーカーは部品やソフトウェアのサプライヤーに「顧客要求を満たすために必要な、安価で品質のよい部品、ソフトウェア」を求めており、それが何なのかを考えるにはエンドユーザーが何を欲しがっているかについて知っておいた方が絶対に有利だからだ。
そう考えると、トップセールスが顧客要求を正確に吸い上げているノウハウをメーカー、サプライヤーサイドのエンジニアが知ることは非常に大事だということが分かる。
＜トップセールスが顧客要求を吸い上げるノウハウ＞
- “お客さんの立場にたって”何が求められているのかを考える
- それを“自分なり”に考える
- 分析した顧客要求を“実践（実現）”する
- 目的を達成するための努力を惜しまない
一見、この4つはマーケティングの技術のようにも見えるが、必ずしも既成のマーケティングテクニックだけで実現できることではないように思える。
たとえば、1の「“お客さんの立場にたって”何が求められているのかを考える」は、顧客へのアンケート調査なので実現できそうな気がするが、トップセールスが実践している顧客要求の分析方法はそのような画一的なやり方ではない。
たとえば薄型テレビのトップセールスウーマンは若干20歳にして、メーカーの新製品展示会があると、休暇を潰してでも見学に行き、開発担当者を質問攻めにする。そして、新機能をリモコンで完全に操作できるようになるまで、展示機の前を離れない。そして、電化製品に詳しくない母親に説明して分かってもらえるかどうか確認する。そして、店頭でこの情報をお客さんに披露し、その反応を見ながら提供した情報がフィットしたかどうかをリサーチしフィードバックする。
2の「それを“自分なり”に考える」という部分は、他社よりもよりフィットしたユーザー要求を吸い上げて商品に反映させるという意味で重要である。ようするに人と同じような調査では他を出し抜くことはできない。ちなみに、このような外部環境を含めた経営戦略分析手法の一つに SWOT分析というのがある。
SWOTとは Strength（強み。内部環境・自社経営資源の強み）、Weakness（弱み。内部環境・自社経営資源の弱み）、Opportunity（機会。外部環境・競合・顧客などからのチャンス）、Threat（脅威。外部環境・競合・顧客からの脅威）の4つの要因の頭文字を会わせたもので、この4つの要因をマトリックスにして、分析する方法である。『通勤大学MBA1 マネジメント
』（￥893）を参照されたし。別の見方をすると日本のトップセールスは、MBAを取らなくても、顧客が何を求めているのかを分析する能力を自らの経験により身につけているということである。
ただし誰もがトップセールスのなれるくらいの分析能力を身につけられる訳ではない。そういう場合は、先人の知恵が体系化されているマーケティングの技術を知って自分の現場のテーラリングすることができれば、人が何十年もかかって蓄積した知恵を効率よく拝借することができるはずだ。
さて、次は3の「分析した顧客要求を“実践（実現）”する」だが、これは関わっている人間の数が少なければ少ないほどやりやすい。トップセールスは自分の中で閉じている環境を持っているので、顧客要求に応えるための戦略を実践しやすいと言えるだろう。
技術者の方はどうだろうか。メカ、エレ、ソフトの技術者がひとりずつといった小さいプロジェクトならば、分析した顧客要求の実践は自分の役割分担の中で実現させることができる。逐一誰かにコンセンサスを得ながら進める必要もない。しかし、プロジェクトの規模が大きくなってくると、プロジェクトマネージメントのテクニックを使わないと顧客要求の実践を効率よく適用させることは難しいだろう。
エンジニアもトップセールスマン・セールスウーマンの気分を味わいたい。トップセールスは顧客の要求にピタッとあった商品を選んだり、顧客が望んでいる使い方をサジェスチョンしたりするのだが、エンジニアは顧客の望んでいるものを作り上げることもできる。
ただ、トップセールスの場合は「分析した顧客要求を“実践（実現）”する」は成功すれば組織全体に利益をもたらし、失敗してもセールルマン・セールスウーマンの販売実績が伸びないという被害にしかならない。
ところが、エンジニアの場合はそうではない。「分析した顧客要求を“実践（実現）”する」が組織的にコンセンサスを得られていない状況で失敗した場合、その影響は個人の責任範囲では済まされない。
機能が足らない、期待した性能が出ていないといった顕在的価値が低いだけならまだしも、エンジニアがよかれと思ってやったことが安全性や信頼性を損ねるような結果になっていると、ユーザーに不利益をもたらし、リコールにより組織に経済的な損失をもたらす。
したがって、「分析した顧客要求を“実践（実現）”する」は技術者の場合は、組織的コンセンサスを得ながら進めていく必要がある。要求分析やユーザビリティの分析結果は、組織としてオーソライズされなければならない。
ただ、そのときにトップセールスが実践しているように、自分自身のオリジナルの分析を盛り込むことは可能だ。ユーザビリティの分析方法としてペルソナ法というのがある。ペルソナ法は、仮想の特定ユーザーを想定して、そのユーザーならこんな使い方をするだろうとか、こんな趣向があるのでこのような機能の提供のしかたが好まれるはずだといった分析をする。
トップセールスが「自分が考えるユーザー像」から、販売戦略を考えるように、ペルソナを想定するときに「自分が考えるユーザー像」を設定するのである。この2つの違いは、トップセールスの場合は自分だけの秘密にしておける可能性があるが、エンジニアの場合は自分だけの秘密にしてしまうと、失敗したときにユーザーに不利益をもたらすような組織的失敗に結びついてしまう危険があるという点である。
最後に、4の「目的を達成するための努力を惜しまない」については、トップセールスもエンジニアも同じだと思う。みんなと同じことをやっていて、競争力の高い商品やサービスを提供できる訳がない。
ただ、トップセールスの場合は個人の中で閉じた話になることが多いが、エンジニアの場合は目的を達成するための努力を惜しまずに、より顧客要求を満たした競争力の高い商品やサービスを提供するための設計を行う者と、誰かが設計した仕様を忠実にコードの落とす者に分かれる。
どっちのサイドに行くのかはエンジニアの心づもりひとつだが、普通なら「目的を達成するための努力を惜しまずに、より顧客要求を満たした競争力の高い商品やサービスを提供するための設計を行う者」と「誰かが設計した仕様を忠実にコードの落とす者」の間には評価に差が生じるはずだろう。
アメリカではエントリーしたばかりのプログラマとアーキテクトやアナリストとのサラリーの差は10倍以上もあると聞いたことがある。
日本の場合、ソフトウェアエンジニアの職種が明確でないこともあって「目的を達成するための努力を惜しまずに、より顧客要求を満たした競争力の高い商品やサービスを提供するための設計を行う者」と「誰かが設計した仕様を忠実にコードの落とす者」の間に明確な評価の差がないことが多い。
そうなると、「誰かが設計した仕様を忠実にコードの落とす者」のサイドにいた方が楽だと考える技術者が増えても不思議ではない。
「目的を達成するための努力を惜しまずに、より顧客要求を満たした競争力の高い商品やサービスを提供するための設計を行う者」が組織からルールに基づいた評価を得られる確証がないのなら、自分の努力が顧客満足につながるという方向に持って行くしかないだろう。
しかし、エンジニアの自己努力（多くの場合、オリジナリティを主張した努力）の成否の影響は、自分の中だけに閉じないため、大枠で組織のコンセンサスを得ながら進めていく必要があるのだ。
ここがトップセールスがある程度自分の裁量でいろいろなことができるのと違う部分だ。
したがって、組織はエンジニアの貢献度を客観的に評価するためのシステムを確立できていないのであれば、エンジニアが考えた顧客満足を達成するためのアイディアについて大枠でとらえてオーソライズしながら、ディテールについては権限を持たせて自由にやらせるということも必要ではないだろうか。
ただ、忘れてはいけないのは、顧客要求の中には設計品質の代表さえれるような潜在的価値の部分が含まれており、エンジニアが好き勝手にプログラミングしていたのでは決してソフトウェア品質を高めることはできず、潜在的価値を高めるという顧客要求を満たすことはできないということだ。
「エンジニアにある程度権限を持たせて自由にやらせる」を詳細に分解すると、次のようになる。
- 顕在的価値（カタログに載るような機能・性能）については自由度を広げる
- 顕在的価値（安全性や信頼性）については、顧客要求を満たすために1とは逆に自由度を制限する
トップセールスもトップエンジニアも顧客満足を高めたいという目標設定は同じでよい。しかし、エンジニア特にソフトウェアエンジニアの方は、以下の4点を進めるにあたり、エンジニア個人のオリジナリティを持って進めていい部分と、組織やプロジェクトのルールを満たしながら進める部分の両面がある分難易度が高い。
- “お客さんの立場にたって”何が求められているのかを考える
- それを“自分なり”に考える
- 分析した顧客要求を“実践（実現）”する
- 目的を達成するための努力を惜しまない
0 件のコメント:
コメントを投稿