2013年12月16日月曜日

変化への6段階の抵抗6layer buy-in processes

ジョナコースを受けたときは、相当大変でした。ジョナコースとは自分の抱えるテーマについて、ザ・ゴール2TOC思考プロセスで書かれている5種類の図を順次教えてもらい、図を作っていく戦略立案実践コース。私が受けた2004年は、講師はイレーンフロスト、受講生はお歴々ばかり。私は入社したてでジョナコースの事務局を兼ねての受講。

コース中自分のテーマに関する図をつくり、1日が終わると毎日食事の場をセットして飲み会。これを連続で8日間実施しました。

私の抱えているテーマに関して図を作っていくと、イレーンフロストに指摘されて書き直しになります。「論理がおかしい」と。それが5種類の図で8日間繰り返し指摘されます。頭が痛くなります。CLR(論理の正当性検証)を使って指摘されるわけです。私の選んだテーマは「とある業界にTOCを普及させる」という漠然とした複雑なテーマ。業界の知見はありましたが、テーマの範囲がかなり広い。

途中何度も書き直しさせられ、こんな図をいくら作っても正解がわかるわけないのではないかと悶々としてきました。論理が正しいのと正解であるのとは違うのではないのか。いちおう複雑系の本とか一杯読んできたので、論理で正解を導けるほど世の中単純ではない。こんな面倒なことやらずに、ともかくやってみたらいいんじゃないかと。いらいらしてきます。

コースの途中6layer(変化への6段階の抵抗)の話しがでてきます。行動するためには、この6段階を合意形成しなければならないと教えられる。このあたりから考える方向が変わってきました。


もしあれこれ考えずともかくやってみたら良いんだったら、論理なんてどうでもよくて、すぐ「自分」が実行すれば良い。しかし自分はなぜ行動していないのだろうか?なにか内省モードに入っていきます。

最終日全部の図が出来上がり、クイズが10問ほどでました。最初の問題が 「What two things should you memorize from this course ?(このコースで覚えておくべき二つの事は何)」

答えは、CLRと6layer。(CLR:論理の正当性検証 6layer:変化への6段階への抵抗)

TOC思考プロセスは、複雑な問題を解決するプロセスではなく、合意形成を導くプロセスが狙いという事です。

自分は5つの図を一生懸命作りましたが、結局のところテーマを解決するための正解ができたとは思えません。ただ、その後、TOC思考プロセス研修100回以上、CCPM研修100回以上、現場への導入支援多数、テーマであった活動を多数実施できました。

なぜそんな事ができたのか、それは偶然が重なったからです。たまたま起こった偶然を生かせたのは、ジョナコースで、自分自身の変化への6段階の抵抗をクリアーしていたからでしょう。
ザ・ゴール2の原題はIt's not luckですが、ようやく意味がわかってきました。

複雑な状況では、やってみて仮説検証しないと分からない事が沢山あります。しかしやるためにはクリアーしなければならない事があります。それは会社や他人や社会とかではなく、まず自分自身の抵抗。自分が納得していないのに実行できない、そんな状況で他人にやって頂くなど不可能、人を巻き込むなどできるはずもない。まずは自分自身の変化への6段階の抵抗をクリアーすることが必要。TOC思考プロセスの最初の役割はここにあります。

ジョナコース最終日、台風が来て新幹線が止まっていました。もう一泊しようと嫁に電話したらめちゃくちゃ怒っている。8日間忙しすぎて1回も電話していなかったのです。さすがに、もう一泊するとはいえず、ともかく新幹線に乗ってみました。台風でたびたび止まりながら大阪に帰宅できたのは朝の4時。これだけ時間がかかると特急料金を払い戻ししてくれるとは始めて知りました。
2004年の印象深い話しを記録しておきます。


2013年11月5日火曜日

アキレス最後の戦い「アジャイル/スクラムvsTOC/CCPM」

最近twitterやFacebookをみていると、CCPMとアジャイルについて議論しているのを見かけますが、自分の書いている物を引用しているものもあるのでTOC/CCPMについて自分のやってきたことと、アジャイルについて自分が思うことだらだら書いてみます。乱文失礼

今の会社に入った2002年からCCPMのインプリメントを10年やってきました。海外の方から色々教えてもらって、現場で指導してきたのですが、結構大変でした。CCPMの計画の立て方は入念に教わったのですが、私の行く大規模開発環境だと、計画を立てているのは1ヶ月、開発期間は1年以上、コンサル契約も1年以上、計画しているとき以外の長い期間どうするのかは手探りでやらざるを得ませんでした。
そうしているとバッファが赤になったり、黒になったりして、どうすればいいのだ!!となるので大変でした。海外の書籍も色々見ましたが、海外の事例は期間の短い物が多く、実行段階で参考になる物が少ない。コンサル先のワーキンググループのメンバーと一緒に考えながらやってきました。

全く別で、たまたま、XP本を読み、これは面白いと思いました。自分の直観に会う感じです。それがあってXP祭りなどアジャイル関係のイベントにちょこちょこ参加していました。

当時のアジャイルは計画よりも、実行段階のことがほとんどでした。そこでCCPMをやっていてのの困りごと解決にアジャイルのプラクティスを紹介し、ワーキンググループで検討して展開するという事が始まりました。朝会、タスクボード、ペアプロなどなどです。紹介したらすぐ展開できました。やはり開発者の直観にあうのでしょう。

以来色々調べていました。2004年には当時マイクソフトのDアンダーセンが「FDD towards a TLS for software engineering」でTOC/DBRとアジャイルの組み合わせをTOC-ICOで発表。AgileManagement software engineering applying TOCを出版しています。
しかし私が読む限り、この本は実務的に使えるレベルとは思えませんでした。本としては悲惨です・・・

しばらく試行錯誤が続きましたが、営業同行していたプロジェクトリーダーからあるプロジェクトが非常に短納期になり困っているとの話を聞きました。08年です。
たまたまマイクコーン「Agileな計画と見積もりづくり」の本が鞄に入っていたので、これが使えるかも、と本をあげました。この本には計画領域のアジャイルの考え方・やり方が明確にまとめられています。

先方はCCPM経験は十分あります。プロジェクトリーダーは、本を読みマイクコーンのやり方とCCPMを組み合わすことを考え、様々な人を巻き込み実践し、成功しました。
私はたいしたこと出来ませんでしたが、チームのすごさで新しいやり方を創り上げました。この方法は 2009年10月PMIでプロダクトリーダーと私で共同発表しました。

その後たまたまアジャイルのコンサルタントをご紹介頂き、一緒に共催セミナーなど事業展開をする事になりました。当時も今もアジャイルを指導することはしませんが、これで紹介先ができました。

打ち合わせでは、それぞれの位置づけを明確にする必要があります。そこで出来たのが3層モデルというものです。この考え方は今の私のCCPMインプリメントの骨格になっています。

マネジメント層:パイプラインマネジメント(複数プロジェクトの開始タイミングを計画しマネジメントする)

プロジェクト層:バッファマネジメント(単独プロジェクトのバッファをマネジメントする)

チーム層:チームマネジメント(プロジェクトファシリテーション及びアジャイル開発)

弊社のCCPMインプリメントではこの3層のPDCAサイクルをつくり連携させる仕組み作りを行います。私が書籍「CCPM標準ハンドブック」を出したのは2010年6月。ここにアジャイルのプラクティスとCCPMを組み合わせた2つの事例を載せています。

2012年にはアジャイルとCCPMの組み合わせがTOC-ICOで発表され世界にでていきました。

アジャイル開発はスクラムの登場などどんどん進化しているようです。その中でも2011年4月Dアンダーソン著「Kanban」は色々な意味で驚きました。やればできる!!

この頃から、自分の中でバイブル的本であった「リーンソフトウェア開発」に疑問を感じます。この本はTPSをソフトウェア開発に応用する考え方が書かれており何度も読み、使ってみました。しかし実務的に使ってみるとおかしいように感じます。いくつかこの周辺の本がありますがなんか更におかしい。

仕事がらTPSの本は沢山読みますし、製造の現場にいきます。「リーンソフトウェア開発」の本自体おかしいのではとこの頃から明確に思うようになりました。平準化計画していないのにカンバンが回るわけがない等々。

その後私の興味は開発上流に移ります。
私の認識は、アジャイル開発が解こうとしている問題は、「ソフトウェアの機能のうち半分以上は一度も使われていない」というつくりすぎのムダ。これをシステマチックに解決していく方法論と理解しています。使われない機能をCCPMで早くつくってもムダです。そこにメスをいれているのが共感するところ。

プロジェクト環境でTOCを活用する方法をまとめたS&Tプロジェクトテンプレートでは、この問題に対して、フルキットしてからプロジェクトを開始しろとしています。フルキットとは要求と仕様を万全に準備した状態でプロジェクトをスタートさせろという意味合いです。たしかに要求仕様がぐたぐたの状態でCCPMをやるとバッファ傾向グラフが2回転後方宙返りのような感じになりどうにもなりません。

しかし「要求と仕様を万全に準備した状態」それは簡単なことではありませ。これにたいする解決戦略がS&Tツリーには実施策が書かれていますが、まともに開発標準がある企業では既に用意されていることがほとんど。それでも出来ないので多くの人が悩んでいます。アジャイル開発はここにメスをいれているのでとても重要だと思っています。

ただしアジャイル開発にも限界があるように感じます。契約問題とかが議論されますが、そうではなく。
・足の長い金型があるなどハードウェア開発の場合適用ができない。
・要求自体が固まっていない場合

その後
リーン製品開発を知り、ここに解決策がある事を知りました。トヨタの製品開発手法であるリーン製品開発/セットベース設計。
更にリーンスタートアップにあるMVP検証による要求の検証。

以上だらだら書きました。それぞれの手法には限界や前提条件があります。しかしこうやって書いてみると、この10年それぞれあきらかに進化しています。更に10年立つと全く新しい形になるかと思うとワクワクします。

(上記一部日付が違うかもしれません。あれば指摘ください。また私がやってきたTOC/CCPMの一つの側面ですので、別の方の意見もあるのは当然です)

2013年9月19日木曜日

BufferManagement: SPIN問題点

BufferManagement: SPIN問題点: ニールラッカム「SPIN式販売戦略」 本ブログに従来から言われている5つの重要場面にたいてい ニールラッカムがどのように考えているかを紹介しました。 非常に説得力のある話しばかりであり、実際の導入事例についても詳細に書かれています。 このようにS...

SPIN問題点


本ブログに従来から言われている5つの重要場面にたいてい
ニールラッカムがどのように考えているかを紹介しました。

非常に説得力のある話しばかりであり、実際の導入事例についても詳細に書かれています。

このようにSPIN式販売戦略は非常に参考になりますが、現実に実行しようとすると問題点があります。今回は問題の方を整理しておきます。



1.SPIN式商談の開発工数増大


多品種少量の時代では、営業マンは沢山の商品を扱っている。それぞれの商品ごとに営業マンそれぞれがSPIN式の質問を考えたり、身につけたりするのはかなりの困難がある。商品ごとの質問事項を誰がどのように創り営業マンに伝えるのかが最大の問題。

2.営業マンのトレーニング工数増大
SPIN式の営業は、営業マンのパラダイムを大転換しないと行けない。このためのトレーニングは大きな工数がかかるであろう。一度のトレーニングでできるようになるとは思えない。できない営業マンをどのようにCheck&Actするのか方法論が書かれていない。

3.反論処理が弱い
反論処理の考え方は理にかなっているが、反論自体はあるので反論処理の具体的な方法を用意しておかないといけないがその点について弱いと感じる。

4.コンプレックスセールス方法が弱い
SPINは商談の初期段階につかうものであり、その後の関係者との合意形成、決裁者への合意形成といった沢山の人への合意形成(コンプレックスセールス)についての具体的ステップや営業プロセス構築方法についての記載が少ない。別途考える必要がある。

5,営業マネジメント方法の記載がない
本のテーマを超えているからであろうが、沢山いる営業マンを統率する営業マネジメント方法についての記載がない。

6.マーケティング方法との関係について記載がない
こちらもテーマを超えているからであろうが、訪問すべき見込客をどうのように確保するか、競合品や代替品との関係など、営業と密接にからむマーケティングについて記載がない。

>>学問的な検証を繰り返すことで、販売にどう役立つか計画し、実践的とはどういう事かをしっかり理解することができたのである。セールストレーニング業界の方々に、もっとこうしたアプローチに関心をもっていただきたい。本書が効果的な販売についての研究のきっかけになることを心から願っている<<

書籍の最後に書かれている言葉。このようなスタンスで考えられていることがニールラッカムの最もすごいところで今後も発展していくだろう。

自分は、ニールラッカム、ミラーハイマン、Kイーズ、Sブランク、Jムーア-、Eゴールドラットといった巨人の肩の上に立ち、彼らが扱わなかった広大な問題をといていきたい。SalesBufferManagerリリースまで あと12日

2013年8月2日金曜日

競争戦略:まず、戦略思考をかえろ。アントレプレナーの教科書


商品をどのように売っていくかを考えるとき競争の視点が重要な要素として存在します。競争戦略と言えばMポーター「競争の戦略」マイケルポーター著
この本は試験に出るのでとにかく暗記した覚えしかありません。よって論評はしません。実務的に競争戦略を始めて考えることができるようになった「アントレプレナーの教科書」Sブランク著をご紹介します。

アントレプレナーの教科書のSブランクは、今はやりの「リーンスタートアップ」エリックリース著をアドバイスしたコンサルタント。この書籍は経営学でも残っていく名著でしょう。
しかし非常に読みづらいです。私は辞書のように使っています。
この本ずっと積読でしたが、ページを開くたびに気になることがかかれています。私は本を最初から読まないのですが、どこのページを開いても気になることが書かれている不思議な本でした。あるとき最後の参考文献をみると驚きます。
自分が読んだ、興味ある本ばかりなのです。だからどのページをみてもそれらが浮かんできて気になっていたわけです。

この本はそれらの本をただまとめたわけではありません。「事業は4つのステージにわけられ、そのステージごとにやるべき事が違う」とうったえ、そのポリシーに基づき、4つのステージにそれぞれ有名なやり方をマッピングしている書籍です。

この4つのステージは製品ライフサイクルから来ているのですが、相当に説得力があります。4つのステージそれぞれの失敗例は私が現場でTOC/CCPMの初期段階から今までに出会った事ばかりだからです。

この本を紹介すると相当なページがいるのですが競争戦略についても、独特のことが書かれています。
競争戦略を3つのタイプにわけています。既存市場・新規市場・中間市場の3つ。

既存市場とは、もろにライバルがいる状態、こちらはライバルをいかに倒すかが鍵になりますが、相手が大きすぎると相当なコストが必要で現実的でなくなる事を書いています。
>ライバルが26%以上のシェアをもっているならマーケティングコストが1.7倍以上必要になる、2社で75%以上シェアがある寡占市場の場合3倍のコストが必要になり参入は難しい<

新規市場とは、ライバルがいない状態。世の中にとって新しい商品であればライバルがいない事が多々あります。この場合競争戦略はお客様の代替品(代替行動)との戦いになります。例えば「手作業でやっているVSソフトウェアでやる」といったものです。この状態の場合、比較ではなく考え方を啓蒙していく必要があります。エバンジェリスト(伝道師)を打ち立てて考え方自体を広めていかなければ買ってくれません。この状況はライバルがいないので価格も高めに設定できますが、そもそもお客様が何なのか理解していませんので相当な提案営業能力が必要になります。
多くの商品の場合理解されず消えていきます。
Sブランクは啓蒙するにはうまくいっても3から7年の時間がかかると言っています。

中間市場とは、再セグメント化した市場です。つまり競争のある既存市場の中でも、ある特定の人たちのみを相手にして、新たな商品のようにたち振る舞う状態。
この立ち位置(ポジション)をとった場合、大きなライバルのいる既存市場、啓蒙に時間のかかる新規市場の中間をとれる事になり成功する確率が高まるとしています。


ちなみに私の今開発しているソフトウェアは非常に独特の物ですが、CRM市場(6,534億円規模)うちSFA(23億円規模)に分類されます。
そのうち43%のシェアを1社が持っています。既存市場真っ向勝負するにはシェア1位の会社の1.7倍のマーケティングコストをかけないといけない。そんな資金はないのでムリ。
TOC専用営業ソフトという新規市場のポジションをとるなら、自分がエバンジュリストとして講演や書籍を出して世に広めるという事になりますが、軌道にのるまで3年~7年かかるのは資金的にきつい。
よって中間市場を選択する方が良さそうです。

このような考え方はマイケルポーターのリーダー・フォロワー・ニッチャーよりも実践的と感じました。Mポーターの場合市場は創られている物という前提で分析的であるように読めます。
しかし、現実には市場は誰かが創り出すのであり、それは自分自身である事が多いでしょう。よってどういった市場を創り出すかは企業側が決めるわけで、世の中ではありません。よって競争戦略(ポジショニング戦略)は自ら決めることができるはずです。


Sブランクは自らどのタイプを選ぶのか決めろとしています。未来の市場は、誰からに与えられるのではなく、自ら創り出すと考えている思想を感じさせます。

2013年7月22日月曜日

「そのそも」っていわせるな



市川淳信氏の書籍は全て読みました。同じ事が何度も書かれている科学哲学の本。氏の書籍を読むことで、気になっていた
なぜTOC思考プロセスは現状構造ツリーから始める5ステップ法から3cloud法へ移行したのか?
なぜTOC思考プロセスはビジョンを構築するストラテジックIOマップという図が発展しなかったのか?


といったTOCコンサルタントとして分かっておくべき重大な事もわかるようになってきたすばらしい本です。哲学とかに興味ある方にはおすすめです。



哲学の話になるので難しいのですが、この話は会議やプロジェクト運営の実務に関わる話しで重要
とくに先週TOC思考プロセスの研修をしていたので特に考えるところがあり少し書いてみます。


市川氏の書籍に科学が進化する5つの条件の4番目に過程論という話しがあります。
過程論の反対は目的論ですが、科学は目的論によるアプローチを捨てて、過程論の話しに集中するようになり爆発的に発展したそうです。

例えば、「クジャクの雄はきれいな羽を持っている」これを説明するときなぜ綺麗な羽を持っているのかを考えていく目的論のアプローチと、綺麗な羽がどのように出来上がるのかを考えていく過程論のアプローチ二つがあるとのこと。

目的論で考えていくと、
「綺麗な羽を持っている目的は、メスに注目されるため」
更に目的を考えると
「メスに注目されたいのは、繁殖をしたいため」
と目的は上位に展開されていきます。しかしこれをどんどん展開すると
「繁殖したいのは、子孫を残すため」
「子孫を残したいのは、????」
「????は神の意志?」
といった具合に必ず神の域のような超越的なところに話しが言ってしまいます。
神の域のような話しはそれが間違っているのかどうか反証できません。
よって不毛な議論になり何も生み出さなくなります。

19世紀以降科学の世界ではこのような目的論によるアプローチをやめて、どのように綺麗な羽ができあがるのかの過程を中心に議論されるようになったそうです。過程については仮説を観察や実験で検証することが可能です。よってどんどん真実がわかるようになってきたとの事です。

我々の会議やプロジェクト運営でも、目的論でアプローチする議論が出てくることがあります。
「そもそも何のためにこれをやるの?」
この議論になるとだいたいが収集つかず不毛な会議になります。

この10年、自分はTOC・アジャイル開発・システム思考 3つほど興味を持ってみてきましたが、TOC・アジャイル開発はどんどん具体的な進め方が進化してきたと感じます。これはTOCは「企業のゴールは儲け続けること」アジャイル開発は「アジャイル宣言」といった目的を決めてしまっており関係者はそれに合意している。その中で、目的を達成するための過程についての議論が中心になっているから爆発的な進化がおこったのかもしれません。

一方、システム思考は色々な方法論が出ているには出ているのですが実務的な進化がすくないような?
システム思考はリーダーシップについて過程よりも目的を問う部分が多く、答えにならない超越的な世界にはいりこんでいっているからでしょうか。 


もちろん目的を考えることが重要ではないとはいえません。会議をする目的・プロジェクトをおこなう目的が合意されていなければ過程を探求してもしかたありません。しかし議論が目的論に入り出したら注意しなければならない。そんなことをちらちら考えています。

2013年7月19日金曜日

顧客と販売員をともに成功へ導く販売プロセスとは -ニューソリューションセリング



先日飲みの席で営業マンのモチベーションは何?との話をしていたときに「競争の商談で逆転したときのうれしさは忘れられない」との話がありました。


この本先日紹介したソリューションセリングの新しい本、内容は整理されていますが相変わらず読みにくい。しかし参考になる話しが沢山あります。



まず
売り手である営業マンの構成は、出来る営業マンは20%、普通の営業マンが80%というのが一般的

買い手の構成は、キャズムによると新しいものに飛びつくマニア・ビジョナリーは20% 相見積もりなど面倒なことを求める売りにくい顧客(マジョリティ)が80%いる。

そうすると80%×80% 商談の64%は普通の人が売りにくい人に営業しなければならない、これはとても悩ましいことだとの話しから始まります。

その上で、具体的な販売方法を作らないと売上はのびないとして、どのようにニーズを把握するのか9ブロック法などを紹介しています。

細かいところでは、
価格交渉があった場合、「商談がおくれて、導入計画がおくれてよいのでしょうか?」「弊社の商品による価値は大きいと合意できているのでありませんか?」「御社が抱えている問題を放置した場合の損失は大きいと合意したのではないのですか?」と念押しをして、それからバーターで交渉する。

商談プロセスを進めるため小さなクローズを取っていくために、「御社のニーズにお応えできると思えるのですが、一度かえって弊社の技術と確認させてください。そして再訪問させてください」と答え、少しずつ営業プロセスを進めていく。「商談を先に進めるためには誰に相談しますか?」ときき、商談人数をひろげていくといったコンプレックスセールスの方法

細かい話しですが参考になります。

特に「自分が一番乗りでない場合お売り込み方」と章があり、ここに逆転商談について書かれています。

まず、IBMソフトウェア・グループの自社内調査によると、
>>IBMが課題を定義せず、要求事項を決めなかった場合、競合他社が契約を勝ち取ったケースは93%<<

一番乗りでない商談とは、具体的にはRFP(Request For Proposal)が出されている案件の事で、これはとても不利。ほとんど受注できないと書かれています。

よってまずこのような商談は基本的には断るべきとしてします。

そんな馬鹿なと、、、、思う人もいるかもしれませんが、
RFPが来ているときの状態とは

・一番乗りでない場合、既に長い時間競合他社が商談を進めている。
・お客様は競合他社によって具体的な問題・解決状態・解決機能がわかっている状態になっており競合の物を買う事がほぼ決まっている。
・しかし、お客様には3社見積もりをとらないといけないといった社内ルールがある
・競合は、お客様が必要なRFPを書いてあげている。
・お客様は、このRFPを出して複数社に問い合わせを行う。
・こうやって自社が問い合わせが来る。

この状態だと勝てる見込が10%ないのも当然でしょう。ただの当て馬です。
このような案件ばかり追っていれば成約率はかなり低くなり、貴重な営業マンのリソースをムダに使ってしまいます。


確かに私もこのようなRFPにまじめに対応して無駄に終わった経験がありますので書かれている事は正しいのだろうと思えます。売上が減少しているのに積算の人がボトルネックになっているところよくみます。。

とはいえ問い合わせに対して断るのは現実難しいので、この事を考慮して4つの戦略を提示しています。

1正面攻撃戦略:競合に対して特徴機能で真っ向勝負を挑む
2側面攻撃戦略:競合の提案とは異なったビジョンを創り上げる商談をおこなう
3ゲリラ的戦略:全てを失わないよう、一部分自分が勝てるとわかっている部分だけ売る。
4時間稼ぎ戦略:お客様の意思決定を遅らせる

この本では、相当に機能が勝っていない限り正面攻撃戦略で勝てる事はないので、側面攻撃戦略の具体的方法が詳しく書かれています。


1,ニーズが不明確な状況ではRFPにお答えできないとの断りの連絡をする。このときRFPと同じぐらいのボリュームの複数商品がのったカタログなど資料を送る。
2,それでもと言われた場合、RFPに対応するためには、それなりの人(各ライン部門経営責任者等)に対して、1時間を3回インタビューさせてくれと連絡する。
3,インタビューで、今回の案件の背景にある、主要課題を2つ挙げてもらう
4,RFPに書かれている具体的な問題・解決状態・解決機能について我々も実施可能である事を示す
5,RFPに書かれていない我々の解決できる問題(他社が解決できない問題)の存在を質問する
6,その問題が重大な問題である事を確認する質問を行う
7,質問を通じてできた新たな具体的な問題・解決状態・解決機能を文章化してインタビューした人に確認する
8,我々の持っている機能を活用しないとどれだけの損失があるのか数値で提示した提案書をだす。このとき最も合意してもらった人にも提案書を提出しておく。
9,逆転受注!!

大まかにまとめるとこのような流れになります。なかなか大変なプロセスです。

このような面倒な営業をしたくないならば、こちらからニーズを顕在化させる営業を行ってRFPを作る側にならないといけません。
ひっくり返すのであれば、このようなプロセスを素早く行える売り方を開発しておく必要があります。

さて、今依頼されているRFPをどうしようか。。。


2013年7月9日火曜日

これが全米トップセールスマンのトップ攻略法だ-VITO


法人営業の場合、一人の人だけでなく様々な人の合意を得ないと購入されません。ですので様々な人にどのように合意を取っていくべきか営業プロセスを考えておく必要があります。このようなことをコンプレックスセールスと呼んだりします。


「トップに売り込む最強交渉術」アンソニー・パリネロ

この本に書かれている事全てに賛同できませんが、コンプレックスセールスを理解する上で読むべきところかなりあります。

VITO(Very Important Top Officer)とは、代表取締役とは限りませんが、そのぐらいの地位で「あの人がやるといったらやる、やらない言ったらやらない」という怖い役員クラスの人を指しています。VITOとはゴットファーザーのビートー・コルレオーネから来ているのでしょう。

この本の紹介はまずVITOではなく、シーモア氏(Mr.SeeMore)から。
シーモア氏とは、ユーザーでも決裁者でもない評価をおこなう関係者のこと。このような人に営業することは「なんの意味もない!!」と激烈な事が書かれています。

Mr.SeeMoreの特徴と対応

シーモア氏は、「もっとみせてくれ」と何度も言って商談を長引かせる
シーモア氏は、あなたの提案のあら探しをするのが仕事
シーモア氏は、会社にとってではなく自分にとって気に入る商品かという視点でみる
シーモア氏は、無償教育をもとめている
シーモア氏は、自分のいないときに何かが変わるのを恐れる。
シーモア氏は、あなたに嘘を教えても何とも感じない
シーモア氏から、もらえる情報は重大でないものばかりで、あなたを誤った方向に向けてしまう
シーモア氏に、与えた情報は競合に筒抜けになる
シーモア氏に、商談において重要人物は誰か聞いてはいけない。なぜならば自分だと答えるからだ。

わからんでもないですが、そこまで言うか・・・・といった感じ。

この本では、営業すべきはVITOのみとしてVITO(Very Important Top Officer)の特徴と対応をまとめています。

VITOは、忙しいのでアイスブレークみたいな話しを嫌う
VITOに、商談において重要人物は誰か聞いてはいけない。なぜならば自分だと答えるからだ。
VITOは、今使っている製品について質問しないこと、知らない可能性が高い。
VITOに、出来そうにない対立を強調して自社商品で解決可能である事をアピールすべき。ムリな対立解消をおこなって上り詰めていることが多いからだ。
VITOは、自分の会社に関する話しよりも同業種の話しを好む
VITOは、自分だけでなくあなたを含め誰の時間も無駄にしない。自分の商品が必要は早めに直接的にきけ
VITOに、自社商品が利益向上に役立つと説明するのではなく、売上増加に役立つと説明すべき。VITOは、利益の計算方法を知らない可能性があるからだ。
社員は、VITOのやりたいことを聞きたくない。新しい事を聞いてしまえばやらざるを得なくなり、今期たてた計画はパーになってしまうからだ。
VITOが、あなたの話を遮って話し出したら勝ち。VITOは聞き役としては最悪な場合が多く、聞き役を探している。

利益計算の話しは笑ってしまいますが、当たっていると思います。

この本の言うように確かにVITOに営業する方が効率が良いのは理解できます。
しかしどうやって会うのか?がそれが問題でこの本に書かれているやり方は、残念ながらちょっと古いように思え使えそうにはない。

法人営業では、一人の人を説得しても購入に至りません。複数の人に合意形成を取っていく営業プロセスが必要です。これをコンプレックスセールスと呼びます。

複数の人をタイプで分けると、ユーザー・決裁者・関係者の3種類。
ユーザーは商品を実際に使う人たち、決裁者は購入を承認する立場の人、関係者は決裁者に技術的観点から購入の問題点を指摘する役割の人。

上記の書籍にあるVITO以外無視作戦はキャズム前の商品であるなら有効だと思われます。
しかしキャズム越えを狙っており一般的な企業(マジョリティ)に売る事を考えるには3つのタイプそれぞれにいかにして合意形成をとるかの営業プロセスが必要です。

例えば、TOCのセールス方法では、ユーザーの人には問題の存在に合意するところから始めるマイナス・マイナスバイインとよぶ方法をおこないますが、VITOの場合プラスバイインと呼ばれる別の合意形成プロセスをつかえタイプ別に提案方法を変えます。

このようなことを考慮して複数の人への合意形成方法を検討していくことで、身のある営業プロセスを構築できるようになります。


2013年7月5日金曜日

開発が進化する5つの条件


久しくブログ更新を怠っていましたが、思うことあって市川淳信氏の書籍を読み返しあまりに重要と感じたので自分なりにまとめてみます。




・人がわかるようになるまでの流れ
わかるとは経験していないことを予測できるようになる事。
人が経験を通じてわかるまでの典型的なプロセスは以下の通り


<イメージする>
例えば佐藤さんのことを色々知っている。というだけでは佐藤さんの行動を予測することはできず分かっているとはいえない。色々な経験を抽象化して「佐藤さんは几帳面な人」といったイメージを作ることで記憶することができ、予測に活用できるようになる

<イメージを使って予測する>
例えば佐藤さんから本を貸してくれと頼まれたとする。「佐藤さんは几帳面な人」というイメージから「佐藤さんは貸した本を返してくれる」との予測が立てられる

<予測と観察結果を比較する>
実際に本を貸してみて佐藤さんが本を返してくれたら、イメージは間違っていなかったといえる

<反例をもとにイメージを作り直す>
もし佐藤さんが返してくれなかった場合、その経験をふまえて新しいイメージを作り直す。

このループを通じてわかるようになる。

・科学における仮説検証の方法
わかるまでのプロセスを様々な人が分業できるようにしているのが科学の仮説検証プロセス。このプロセスが19世紀に確立され、以降科学的発見は爆発的に増加した。


<仮説設定>
現象を観察するなどからモデルを作成する

<演繹的推論>
「aであるとaではないが共存しない」「aであるならbである。bであるならCである。ならばaであるならcである」この二つのルールに基づき仮説の結果起こることを因果関係で検討し推論結果を作り上げる。このステップは一本道で枝分かれしない。

<推論結果と観察・実験結果の比較>
推論結果と観察・実験結果を比較する。誤差の範囲内であれば仮説は間違っていないと実証される。

<帰納的推論をもとに仮説の作り直し>
比較結果が一致しなければ反例を検証し新しい仮説を設定する。反例を検証する方法は、帰納的に推論するが、これは一本道の論理的方法はなく、試行錯誤による。

科学の世界は世界中の様々な研究者がこのループするプロセスに従うことにより進化していった。

ここで興味深いのは。
・分業するから爆発的に進化したと言う事
・分業が出来るようになったのは推論方法などが統一されているからという事。
・具体的には演繹的推論方法が統一されており、これは一本道で枝分かれしない事。
・仮説を立てるときの帰納的推論は特に定まった方法はなく、一本道の論理的方法はなく枝分かれしていく、いまだに夢でみたとか様々な方法から生まれているという事。
・19世紀以降科学が爆発的に進化したポイントは、アイデアを思いつく所(仮説設定方法)がスピードアップしたからではなく、アイデアの間違いを発見する所(仮説を検証する方法)がスピードアップしたからという事


・マフィアオファーによる商品戦略の仮説検証方法
以上を元に、私が開発しているTOCセールス&マーケティングでの仮説検証を整理してみる。

<仮説設定>
商品に関係する商品企画・開発・営業各部門から選抜された3名で仮説設定を行う。
新しく開発する商品や既に開発されている商品に関してアピールポイントとなる特徴的機能を3つ考える。
3つを考える方法は特に決まったプロセスはない。

<演繹的推論>
商品企画・開発・営業各部門から選抜された3名で推論を行う。
3つの特徴的機能が生み出す、顧客価値をそれぞれ因果関係でだし、その反対の状態を顧客の困りごととして3つ設定する。
更にこの3つの困りごとがお客様の重大な問題になっているか因果関係で推論する。
重大な問題とは顧客の株主満足・顧客満足・従業員満足への影響と考え推論していく。
この推論はTOC思考プロセスに規定されるルール(CLR)をもちい現状構造ツリーを作成することで実施していく。

<推論結果と観察・実験結果の比較>
営業マンが顧客に訪問し検証を行う。
設定した顧客の困りごとを問題質問、顧客への重大な問題を重大質問という質問の形にして5段階評価で点数をつける。
「4点:能動的に困っていると答えた」
「5点:困っており既に問題解決策を打っているが不満足」
といった高得点が得られれば商品を開発して良い、売り方が開発できる、と判断できる。

<帰納的推論をもとに仮説の作り直し>
質問に対する点数が低い場合その原因を商品企画が検討する。
顧客のタイプで評点の高低に特徴があある場合、セグメンテーションを行い、そのセグメントに集中して営業を行えば十分な売上規模を得られるのかを検討する。
売上規模が足りない、また低得点ばかりの場合、結果をうけて新たな特徴的機能を検討する。
検討する方法が観察法などいくつかの方法があるが定まった方法はない。


今のところ以上という事になる。
企画のステップをきちんとおこなうと、開発するスピードよりも、作るべき物がなにかを企画するスピードの方が遅い。つまりほとんどの企業で要求仕様を作るプロセスがボトルネックになる。

これをもっと爆発的に進化させる仕組みを考えていきたい。





2013年4月3日水曜日

トヨタが発想し、HPで導入、ハーレーダビッドソンを伸ばした画期的メソッドをやってみて


今回開発しているTOCの新たなセールス&マーケティングコンサルティングプログラムとソフトウェアは、1年程度構想を行いコンサルティングプログラムのテキストを作って、それからソフトウェア開発を始めています。

今回のコンサルティングプログラムの開発は、議論の進め方が今まで通りだと完成しないと認識としていました。
コンサルティングプログラムの目的は「お客様の売上高を増加させる」と明確なのですが、それを実現する方法を考えるとなると、複雑でどのような因果関係があるのか把握するだけでも困難な問題です。
今までのコンサルティングプログラムや、沢山ある参考書籍、相当なコンサル経験と知識のある人、これらを集めて開発するにしても、議論の進め方を工夫しないと完成できそうにありません。
そこでリーン製品開発にあるLAMDAサイクルというものを使うことにしました。



LAMDAプロセスとは、車の開発が欧米と日本でかなり異なっている。日本は構想設計段階が長い。長い構想設計段階で何をしているのかの研究からアレンウォードがまとめた構想設計のやり方です。
基本的にはサイモンの意思決定モデルと同じで
「問題認識→代替案の探索→代替案のモデル製作とシミュレーション→結果の評価と選択→選択された案の実施」
このサイクルを繰り返し実施して設計案を固めていきます。



これを使った検討の流れは以下の通りで実施しました。

・わからない事とわかるための対策案を議論して表「LAMDAシート」を作成
・複数の対策案に関する検証を実施
・2週間に1回ミーティングを開き
・対策案で目的が達成できるのか報告とレビュー、
・案の絞り込みをおこない表を更新
このサイクルを繰り返していきます。

これにつかう表がLAMDAシートです。表の要素は


Look:達成すべき目的
Ask:目的達成を阻むわからない事(知識ギャップ)
Model:知識ギャップを解決するための複数対策案
Disucuss&Act:検討結果共有日と検証実施担当者

たいした表ではないのですが、この流れで実際にやってみると今までとは大きく異なる結果がでました。

LAMDAそれぞれ実施するときに注意したポイントと効果をまとめると

Look:達成すべき目的

ここでの目的は、要求仕様レベルの物ではなく、議論を整理するための大枠の要素レベルにする。
ここでの分類でもめないよう、参加者がある程度認める分類の仕方を事前に用意しておき議論時間の短縮をはかった。(今回はゴールドラット博士の決めている分類にした)

要求は実現手段の検討によって変化すると考え早期に固定しない方針とする。
早期に要求(目標スペック)を固定しようとすると、今できるレベルにしてしまうので凡庸な製品になる。これを避けるため大枠レベルから段階的に要求を具体化する方針にしておく。

Ask:目的達成を阻むわからない事(知識ギャップ)
複雑なテーマでは何がわからないのか分からない段階から議論を始めるのに、従来の方法では分からない事を発言できる時間帯がほとんどないし、分からないと言いにくい雰囲気がある。よってやや分かっているリーダーばかり発言して、その他の人はそもそも論以外何も発言できないという展開になる。そうするとリーダー一人で考えて、皆は指示を待つような形ができてしまい問題解決ができない。

LAMDAシートを使って話すと、まずは分からないことを列挙することから始めるので、全員堂々と質問でき発言数が多くなる。

誰かが分からない事でも、誰か答えられればその場で解決。この時点で知恵が共有される。誰にも答えられないことがあれば知識ギャップとして記録される。
(ある会社では3分以内に答えがでなければ知識ギャップとして記録するルールにしている。)


わからない事を記録することは典型的な失敗プロジェクトを防ぐ意味で有益。従来のやり方では納期のプレッシャーから、分からない事は置いておいて、分かっていることをまず実施して進捗しているように見せる。最後の方になって重大なわからない事が浮上してプロジェクトが立ち往生。プロジェクトは中止。という最悪のパターンががある。

アジャイル開発で進めてもこのリスクをさけられないが、LAMDAシートで構想設計していればこんな失敗をさけられる。

Model:知識ギャップを解決するための対策案を複数立案する

LAMDAシートでの対策案は、複数あげなければならない。
このことは、最適な案を言わないといけないプレッシャーがなくなるので、様々な人が思っている案を制限なく列挙できるメリットがある。

議論するのは対策案の検証方法が中心になる。○○という本に書いてあったとか、過去のプロジェクトで似たようなことをやったので調べてまとめればよさそうとか。

案の善し悪しについてこの場で議論しない。
わからないのに決めなければならないというムリなこと、不毛な議論を避けられる。

早期に決めなければならない方針を持つと、リスクの少ないありきたりな物で意思決定をせざるをえなくなる。
安全案とチャレンジ案を複数持って意思決定を遅らせることでリスクにチャレンジして画期的な案を発見できる可能性を高めることができる。


ここで、対策案が全くでてこないこともあるだろう。そういうときはまず誰かが実現可能な最低な案を発言してみる。「前のバージョンのままでいいんじゃない?」といった感じ。
そうすると、それは駄目だと、その案よりはましな案を皆が発言しだし、議論が活性化する。このようなやり方をマクドナルド理論とよんだりする。安全な雰囲気作りをして案が沢山出るよう場を作る事が重要だ。

Disucuss&Act:検討結果共有日と検証実施担当者

検証結果を共有する会議の日時は、一定間隔の日に固定しておく。(2週間ごとの金曜日等)
これにより見積もり不可能な代替案の検証期間について機械的に目標値をおく事ができるため会議時間を短縮できる。

会議での意思決定は複数案のうちどれを捨てるのか決め、一つにするのを出来るだけ遅らせる。対策案検証結果をみて自然に収束する事を狙う。

納期から逆算したデットラインに到達しているが収束しないものについてのみリーダーが一つに意思決定する。
このとき多くの場合、安全策を選択し、要求を低い方へ下げる事になる。
要求を引き下げても売れるのかどうかが判断基準になり、この意思決定が重大。

・上記の流れを繰り返して一つの設計案に収束させる。収束できたらプロジェクト計画を立案し開発をスタートさせる。

私が今やっているものの場合、上記のプロセスを実施し、案を収束させコンサルティングテキストが完成。テキストをインスペクションでレビューして、売れるのかどうかの検証を実施。ここまでで1年程度かけました。
それからソフトウェア開発をするかどうかビジネスモデルの検証、要求を絞り込みソフトウェアで実現する部分を特定、予算取りをして、それからソフトウェア開発が始まっています。そこからの開発はおおよそスクラムのやり方に沿っています。

以上のやり方が完璧だったとは全然思わないですし、もっと工夫できないのか考え中ですが、いきなりスクラムを使ってとりあえずソフトウェア開発を始めていたら不必要な物を開発してしまい、早期に開発中止になっていたでしょう。ITコンサルタントに要件定義してもらってウォータフォールで開発していたら多額の投資をして出来上がった時に使えないことが判明、会社が倒産するぐらいの問題になっていたでしょう。。

多くの企業で、要求・構想設計の探求段階は半年以上ありますが、プロセスが定義されておらず、マネジメントされていません。LAMDAのそれぞれを具体的にどのようにするかはまだまだ多くの議論が必要ですが、ヒット商品を作り出すため企画と開発が検討するやり方として可能性が大いにあると考えています。

2013年4月2日火曜日

アジャイル開発は全体スケジュールにコミットすべき



アジャイルソフトウェア開発について極端な議論をされています。極端に話すと議論がわかりやすい。議論を見ていると7つの理由のうち「全体スケジュールにコミットできない」「アーキテクチャ上の無駄が生じる」の2点が興味深い。「全体スケジュールにコミットできない」は自分の仕事にも絡むので書いてみます。

ちなみに、私はアジャイルのコンサルタントでもないので利害関係ありませんし、開発者ではなく企画の立場。できれば全てのソフトウェア開発がアジャイルソフトウェア開発でやった方が良いのではと思っています。

・全体スケジュール
スクラムでは直近の期間(スプリント)についてのみ計画する事になっており全体計画がありません。これについては確かに企画側は困ります。全体計画がなければ予算取りができませんし、変化に対して対処できません。

開発側からみて意味のある計画が作れないとか、後のことを考えてもしかたないというのは一理ありますが、企画側はあきらかに必要。
アジャイル開発のやり方として、「全体スケジュールは計画しなければならない」と明言してどのように計画すべきか議論した方がよいのではないでしょうか。
企画側が欲しい全体スケジュールは詳細なタスクではなく、最終成果物のスコープがどう変化するか。よって、どのイテレーションにどの機能が実装予定になっており、追加要求によって最終成果物がどのように変化するか大枠がみえれば十分です。

・コミットメントできない
全体スケジュールは作れば良いだけなのでいいのですが、全体スケジュールにコミットできるかどうかは厄介。
アジャイルソフトウェア開発では最終成果物についてコミットをおこないません。これは契約問題を含め大きなポイント。

「昔プログラマーはマジシャンと思われていた。動くソフトを作るだけで認められていた。しかしいまや普通の人。普通の人が約束を守らなければならないように、開発者も約束を守らなければならない」ケントベックが講演していた話しです。この発言からアジャイル開発は約束をしないというものではないでしょう。

問題はどうすれば約束を守られるのか。我々は誰も未来を正確に予測できません。よって計画に約束するためには必ずバッファが必要です。バッファはコスト・スコープ・時間といった形がありますが、いずれにしろバッファをもっていないと約束することは不可能です。
このことはアジャイル開発だろうがウォータフォールだろうが開発以外の業務であろうが同じです。

私のアジャイルソフトウェア開発の理解は「QCDにはコミットしなければならないが、スコープは柔軟に調整可能である。これを具体的に実現するための開発プロセス」であり、スコープにバッファをもたせる方法だと思っています。
このやり方は企画側からもメリットがあります。事前に全ての要求を洗い出すことは不可能ですから。

であれば
100機能開発する全体計画だが、70機能は必須で開発。30機能は変更可能なバッファスコープとする。
こういう全体計画すれば開発側も企画側もコミットはできるでしょう。バッファなんてお金の出元の方が認めてくれないと思うかもしれませんが、普通は大丈夫です。

以上の通りで「全体スケジュールにコミットできない」のでアジャイルが駄目なら、「バッファをもった全体計画を作る」という事で問題解決ではないでしょうか。

どのぐらいのバッファを、どのように誰が持つとバッファは最小化できるのか。こちらの議論が必要かと。

2013年3月25日月曜日

驚異のプレゼン―人々を惹きつける18の法則


プレゼン方法について書かれた物をたまたま連続してみたので私もまとめてみようと。

まずこのブログはブックレビューなのでその手の書籍についてですが、タイトルがいいのは「スティーブ・ジョブズ 驚異のプレゼン―人々を惹きつける18の法則」残念ながら練習する位しか得られません。。

仕事柄色々な本を見てきたのですがこれといって紹介できるほど参考したものはありません。
プレゼンの本ではないのですが「超文章法」野口 悠紀雄著は色々な意味で参考になります。

私のプレゼンは2種類で営業的なセミナー(2時間程度)か研修(1日中)で年間200回ぐらいプレゼンをしています。このペースが7年ぐらい。ほとんど旅芸人状態。そこでプレゼンするときに経験主義的に気をつけていること、気をつけていたこと、自身の振り返りのためにも書いてみます。

<事前準備>

・話の構成

プレゼンの構成はかなり気をつけています。色々な構成方法がありますが、ザ・ゴールに書かれている「何を、何に、どのように変えるのか」にそってプレゼンする事がほとんどです。「問題の提示→解決方向性の提示→具体的な解決策」という進め方。TOCのコンサルタントだからという理由もありますが、結局これが一番わかりやすいように思えるからです。
特に現場の方に話すときは、共感を得るような問題の共有から始める事を重視しています。社内プレゼンではなく、アウェイで話すことが多いので特にここには力を入れています。

「何を、何に、どのように変えるのか」の反対のパターンは、最初に結論をいう、最初に成功事例を話す、最初に商品説明するといったパターンです。これは決裁者プレゼンでは良いのですが多くの場合反感をかい失敗します。
また、どうやっても「何を、何に、どのように変えるのか」の構成で話せない場合、人に話すような内容にまで昇華できていないという事なのでネタを変えます。

・スライドのデザイン
スライドについて色々な議論があります。フォントは16以下は使ってはいけないとか、プレゼンテーションZENのような極端な物から色々。文字だけのスライドばかりは論外ですね。

私は、文字だけのスライドを使うことはほとんどないですが、文字のないスライドも使わないようにしています。
研修会社からの依頼の場合、文字がないスライドだとクレームをうけますし、後で読んでもらう、また他の人に回覧してもらう事を考えるとある程度文字が必要だと思っています。
公演中はスライドをみてもらうよりも話している自分の方をみてもらう事を前提に考えています。
スティーブジョブズの伝説の講演はパワーポイントを使っていませんし、TEDでもスライドが映っているのではなくスピーカーが写っています。その事を考えるとスライドはその場でみてもらうと考えるより後で読んでもらう、共有してもらう目的で作る方がよいかと思っています。

また、プレゼンテーションZENについては、他の人がZEN的にやっている人と同じようなスライドになるので、個性が出せないのでやらないようにしています。

・最後の方にアニメーションを使わない
 プレゼンしていて一番気になるのは時間です。早く終わってしまっても困るし、時間がなくなっても困ります。
これを避けるためにはスライドを少なめにしておき、時間が余りそうならゆっくり話すというのがテクニックになります。しかし、これは相当慣れていないと難しいので人には勧めません。

たいがいは短めに終わってしまうのが怖いのでどうしても多めにスライドを作ってしまうのはしょうがないと思います。ただ気をつけるのは、最後の方のスライドにはアニメーションをつかわないようにしておくという事です。
時間がなくなったとき、最後の方のスライドは早く進める事になりますが、この時スライドにアニメーションがあるとなかなか次に進まずかなりみっともない状態になります。これを避けるため最後の方のスライドにはアニメーションを使わない方が無難です。
プレゼンテーションZENのようなやり方をしたときも同じリスクがありますので十分練習しないと難しいでしょう。

・「この続きは○○で」はやめる
 色々な人と一緒にプレゼンする機会があるのですが「この続きは○○で」としめる人がいます。これはやめた方が・・・・。宣伝するのは目的なので全然問題ないと思いますが、話が面白くないうえ、結論は別のところで、だったら聞いている側は最悪。いままでこのパターンでしめた人を何人も見たことがあるのですが、共通して内容が面白くなく最悪です。。。
聞きに来ている人は貴重な時間を使ってわざわざ聞いてくれているのできちんと結論を話さないと失礼です。

・学生症候群はやめる
プレゼンをぎりぎりまで作って話す人がいますが、これはやめた方が良いです。そうやっている人のプレゼンはだいたい支離滅裂。よっぽどの偉いサンでない限り、早めに完成させて提出してスタッフや他の講演者から意見をもらえるようにした方がよいでしょう。

・練習する
結局の所練習するにつきると思います。うちの社員にはそうアドバイスしています。
一人で口に出して練習するのはもちろん、誰かに聞いてもらえるのがベストです。声に出して話せばロジックが通っているかどうかがわかります。これを繰り返せばきちんとしたロジックのプレゼンができます。どんな競技でも練習しないプロはいないので当たり前。
私の場合だいたい電車の中で黙読して練習します。
<講演当日>

・演壇の目の前に座っている人とは話す前に名刺交換しておく
話しているとき怪訝な顔をする人を見てしまうと一気に落ち着けなくなります。目の前の人と名刺交換して話しておくと、あまり怪訝な顔をして聞かないので、その人をみれば落ち着く、また公演中に質問を投げかける事ができる。こんな理由から名刺交換しておくのはお勧めです。
誰かから聞いたやり方だと思いますが誰だったかは想い出せません。

・話し始める前に口を大きく開ける練習をして滑舌をよくする
これは講演を沢山やっている人が実際にやっているのを真似てやるようにしています。

・最初にスクリーン・プロジェクターの前にたつ
講演を聴いたけど、どんな人が話していたか覚えていない。色々な講演を聴きますがそんな事がほとんどです。聞き手はスクリーンをずっと見ているので当たり前。ほとんどの聞き手はしゃべっているのが誰かみていません。
そこで私の場合、話し出す最初はスクリーンの所に立つ。中央にあるプロジェクターの前にたってスクリーンを消す。といった事をやるようにしています。一番最初は自己紹介なので、そのときは顔を見せて覚えてもらうようにしています。

・なるべく指し棒をつかう。
 これは、ある書籍に「レーザーポインターをちらちら動かすと見ている人の目が疲れるのできとんと固定して使わないといけない。しかした緊張しているとどうしても震えてポインターが動いてしまうので指し棒を使う方が無難。」と書かれているものを読みそうしていました。いまは震えるほど緊張する場面が滅多にないのですが、くせになっていて大きな会場以外では指し棒をつかうようにしています。

・うなづいている人を見る
 これも最近は意識しなくなってしまいましたが、昔は意識していたものです。話しているとき頷いてくれる人がいます。この人を見ながら話すと相当に落ち着け冷静に話せます。
逆に私が面白い話をする人の話を聞くときはなるべく頷きながら聞くようにしています。そうすれば得られることが更に多くなるわけですので。

・大きな声で話す
「どうせ1時間とかで内容まで理解してもらえないので、一生懸命やっていることをわかってもらう事に重点を置くべき」若いときにプレゼン方法についてアドバイス頂いた中で一番覚えている言葉。これは確かです。嫌われても良いので一生懸命大きな声で話すのはとても重要かと。

<フィードバック>
・アンケートをとる
アンケートを採るとき満足しましたか?を5点法でつけてもらうのが普通ですが、あまりフィードバックをえられません。
どんなアンケートがベストかはまだ試行錯誤中ですが、最近意識しているのがノイズを拾わないようにする事。聞いてもらいたくない人が1点、2点つけていても気にしない。聞いてもらいたい人の点数がいくつかが重要です。どうしても全員にうけるよう話したくなりますがこれでは八方美人で何だったのか記憶に残らないプレゼンになるので気をつけなければなりません。
アンケートには問題を最初に話すので、問題に対していかがでしたか(5点法)解決に使えそうですか(5点法)こんな感じがよいかと思っています。

・同じ話を何回もする
色々な人と一緒に講演してきましたが、非常に話のうまい人に共通しているのは、同じ話を何百回もしているという点です。以前私が話した後の基調講演の社長様は500回ぐらい同じ講演をしているとのことで、笑いあり涙ありの上ためになる漫談という感じ。
何回も同じ話をするからうまくなるのか、うまいから何回も同じ話ができる場があるのか、因果関係の検証が必要ですが、何度も話していればうまくて当然、練習するにも通ずるのですが何度も話す事は重要です。

何度も講演するチャンスがあるのに、いつも構成を変えてしまうのはやめた方が良い。改善するときは少しだけパラメーターを変えて結果がどうなるか観察することが重要です。沢山のパラメーターを変えてしまえば違った結果がでても何が良くなったのかわかりません。

・講演すること自体を目的化しない
私の場合話を聞いていただいた方に「やってみよう!!」と思ってもらう事が目的なのですが、どうしても講演に満足して頂き、沢山の拍手をもらう事を目的にしてしまいます。これはまだまだ解決策がみつけられていません。

自省をこめて、だらだら書いてしまいました。

2013年3月15日金曜日

日本企業が捨ててしまった大事な物


TOCのコンサルタントなのにブログにTOCの事がほとんど書かれていない。というのもあれなので本日はTOC関連
ゴールドラットのインタビューなどを編纂した書籍が出版されています。

・経営学の常識を覆す自然科学に基づいたTOC
・効率を正しく追求すればむしろリストラの必要はなくなる
・巨人の肩の上に立って

この3つは何度も読み返してきた文章で格好いい。是非みなさんも読んで頂きたいと思います。論点を少々。

【TOCとは、Inherent sinmplicity かつ People are goodである】

ゴールドラットの定義するTOC。これは難しい定義です。
ゴールドラットの左腕と言えるエリーシュラーゲンハイムが書籍に解説しているものがありこちらの方が"やや"わかりやすい。
Supply Chain Management at Warp Speed
Eli Schragenheim (著), H William Dettmer (著), J. Wayne Patterson (著)
People are goodについて
>>また、制約理論では、会社にとって正しいことなら従業員は喜んでやってくれると仮定する。しかし、時にはこの仮定が保証できないこともあるだろう。だがこの願望を叶えるのは、いかなる場合も指導者の役割であり、本書の範囲を超えている<<

脚注にこのような事が書かれています。ゴールドラットの話では理解できなかったのですが、私はこれを読んで次のように解釈しています。
→TOCは、「全ての人が良いことをしようとしている」との前提条件の上に成り立っている。そうでない事もありえるがそれはTOCの扱う領域ではない。

Inherent sinmplicityについて

P7・経営学の常識を覆す自然科学に基づいたTOC
>>社会科学では4行ですむなら単純、4000ページを要するならなら複雑。自然科学の定義ではデータ要素が多い少ないは関係ありません。「自由度が高ければ高いほど、システムは複雑」という事になります。<<

ゴールドラット。かなり難しい・・・。

iPhoneはシンプルで、日本の携帯は複雑だ。そんな話を聞きますが、この定義で考えるとどうだろう。
iPhoneは、開発としては自由度が高いので複雑。ユーザー側も色々出来る。
デザインがシンプルとかいう人もいますが、安藤忠雄、バウハウスはシンプル?
クラシックは複雑で、パンクロックはシンプル?

Supply Chain Management at Warp Speedでは、Inherent sinmplicityの解説としてカオス理論を引き合いに出した説明があります。一見複雑に見えるものも単純な式でできている。といった話です。うーーむ。

【効率を正しく追求すればむしろリストラの必要はなくなる】
これは始めて読んだとき人生観が変わるぐらい影響を受けました。
私は前職でカルロスゴーンもびっくりの固定費60%以上削減した実績があります。
その後自慢じゃないですが固定費100%削減達成です。(倒産したということです)

ゴールドラットはザ・ゴールで、企業の目的はお金を儲け続けることだと書いています。
このインタビューではそのためには終身雇用を守りリストラはするなと書いています。
格好いい。

【巨人の肩の上に立って】
これについては是非原文をお読みください。ゴールドラットが追求してきた物がまとめられています。
格好いい。

【未開拓の分野】
>>すばらしい科学者になる秘訣は、脳力(知力)にあるわけではない。脳なら誰でも持っている。我々はただ現実を直視して、その現実を理論的に、かつ正確に思考しなければならないだけである。肝心なのは、我々が見ている物と、導き出す結論と、実際に何が行われているかの間の矛盾を直視する勇気を持つことである。基礎となる仮定を疑うことが、ブレークスルーに必要なのである。<<

現実のセールス&マーケティングの話は矛盾したことばかりと感じます。
ですので私は、巨人の肩の上にたってセールス&マーケティングの分野を追求してみようと思っているところです。

ともかく、思うのはゴールドラットは格好いいという事です。

2013年3月13日水曜日

SPIN4,反論処理



4,反論処理 

「顧客の反論を上手にさばくことこそ商談成立の決め手」と教えられるが高額商品では不調に終わることがほとんどである。

私の営業経験でも反論をされることがあり、それにどう対処するかは考えさせられます。
しかしニールラッカムは、

>反論処理する方法を身につけるのではなく、反論を予防する方が重要である<
としています。

まず反論処理をトレーニングする講師に聞いた話を紹介しています。

>反論処理が重要との話しでしたが、あなたは商談で反論されるのでしょうか。若い頃と今を比較して見てください。若い頃より今の方が反論が少なくなり営業成績がよくなっているのではないでしょうか。もしそうであれば反論処理がうまくなったから営業成績が上がったのではなく、反論されなくなったから営業成績があがったと言えるのではないでしょうか<

これは自分自身の経験を考えれば説得力のある話しです。私自身営業時点で反論される事は非常に多かったですが、てっきり反論に対処できるようになったから成約率があがったのだと思っていました。しかし考えてみると営業段階での反論自体が少なくなっているのは事実です。
よって反論処理がうまくなったから成約率が上がったとはいえず
反論自体が少なくなったので成約率が上がったと言えるでしょう。

ニールラッカムは、
特徴を示すことは価格
利点を示すことは反論
につながると分析しています。

商談のはじめの方に特徴を説明すると、お客様はその特徴に対する対価をはらわないといけないのだろうな、つまり高いだろうなと思ってきます。この特徴が多ければ多いほどそう思うます。
価格の安い少額商品の場合、まず特徴の話をしててんこ盛りですが今なら1000円です。といわれれば飛びついて買うでしょう。
しかし価格が高い高額商品の場合、やっぱり高いなぁと反応され購入してもらえません。

次に利点を示すと反論につながるとしています。

ニールラッカムは利点とは
>製品・サービスの特徴がいかに役立つかを示すこと<

と定義していますが、利点を言うと「本当に御社のサービスで実現できるのですか?」と反論されますし、利点は一般論ですので、「我々は特殊ですので」という反論を受けてしまい、特殊である自分たちに必要な特徴はあるのかとの反論が続きます。

このような事を考えると、反論を生む原因は商品にあるのではなく、「利点を示す」という営業マンの行動にあるといえます。

これらの解決策としてニールラッカムは、
利点を示すのではなく、お客様のニーズについて質問し、それに対する解決策として自社商品を提示する。こうすれば反論は大幅に減少すると。

お客様自身が解決したいと思っていることに対する解決策であれば100点満点でなくても50点でもよいと考える可能性がでてきます。

ただし、ニーズが顕在化していなければこのやり方は通用しません。つまり「言われてみればそういう問題あるなぁ」といったレベルのニーズに対して解決策である商品を提案しても、価格が高いなぁとの反応になるだけです。高額商品の場合ニーズをしっかり顕在化している状態になってから自社商品を提示しなければならないのです。

ニールラッカムはこれらを具体的に実現するために
状況質問
問題質問
示唆質問
解決質問
と4つの質問を順次展開していくSPIN式販売というものを提唱しています。

非常に理にかなっています。

ただ問題はこれを実際の営業の現場でやるのは難しすぎてムリがあるいという点でしょう。