2009年7月14日

あっぱれ!マイク

 先日、米国から帰省していた娘夫婦(夫は、米国人)が、帰国した。

 彼女は、3姉妹の長女。彼女の夫と、妹二人、そして、運転手の私が、成田まで送った。そこでちょっとした事件があった。

 予約していた成田-ソルトレイク・シティ(ユタ州)への直行便が、キャンセルになったという。これは、一日一便しかない。聞くと、バードストライク(鳥がエンジンに飛び込む事故)で、修理が必要なためだという。

 そこで、航空会社の窓口の方は、必死にフライトを探し、なんとか別会社のサンフランシスコ経由便を確保してくれた。ところがである。このフライトには、マイレッジがつかないという。

 貧乏学生夫婦である二人は、マイレッジを貯めて、日本への帰国に使おうと考え、多少高いことを承知で、このフライトを選んだという。納得できないマイク(彼女の夫)は、「これは、そちらの都合であって、こちらには一切の非は無い。にもかかわらず、マイレッジがつかないとは、許せない。何とかするべきである。(英語なのでよくわかりませんでしたが、たぶんそういうことのようです)」とカウンター越しに交渉している。しかし、担当者は、申し訳ないの一点張り。

 ついに、マイクは、「マネージャーと話をさせてほしい。」と切り出した。そして、交渉の末、マイレッジを獲得してしまったのだ。交渉は、30~40分かかっただろうか。待ってるこちらの身にもなれよ・・・といいたいところだが、彼らには切実な問題。あっばれ!である。

 さて、今度は、乗り換えることになった航空会社で、発券、チェックインの手続きをしなくてはならない。そこで、今度はちょっとだけ、悪知恵を授けた。

 「大変なことになった。とんだ迷惑である。御社に変更してもらったのはいいが、予定より、4時間も余計にかかってしまう。本当に参ったよ。こういうときは、アップグレードなんて、してもらえないんですか・・・?とだめもとで聞いてみなさい。」と・・・

 なんと、エコノミーから、プレミアム・エコノミーにしてもらえたらしい。災い転じて、福となすである。

 別に、こんな身内の話はどうでもいいのだが、私は、改めて米国人の交渉力に感心した。若いころから、交渉は当たり前、理を尽くし、時には感情を交えて、きちんと自分の主張をする。

 ハンサムで温厚な好青年のマイクであるが、いざ、ビジネス(彼ににとっては・・・)となると、タフな交渉にもひるまない。幼いころから、学んできた、というか、それが当然の生活習慣のなかで、育ってきたのだろう。

 ビジネスは、ますますグローバルになっている。われわれ日本人は、こんな連中と、渡り合わなければならない。「きっと相手も意を汲んで、対応してくれるはず」は、通用しないのだろうなぁ。

 翌朝、娘からメールが届いていた。無事帰国したとの知らせ。しかし、そのタイトルは、「日本に着きました!」。

 親ですから、日本人ですから、あなたの気持ちは良くわかります。しかし、あなたは、海外で生活しているんでしょ。そんなことで、いいのですか?

親として情けない限りである。

2009年7月12日

日本型クラウドの可能性(4)

日本型クラウドを考えるとき、もっとも心配なことは、ビジネス・プロセス・マネージメント(BPM)の問題だ。

 日本人の素性として、業務をプロセスに分解し、整理、系列化することには、どうも向いていないように思う。

 BPMが、なぜクラウドと結びつくかといえば、それは、SOAとの関係においてである・・・とくると、話がみえなくなったという人もいるかもしれないので、このあたりを整理しておこう。

 いままでも述べてきたとおり、クラウドは、万能ではない。提供するサービスに違いがあり、得手不得手もある。

 当然、利用する側は、それを使い分けるべきだ。そのとき、どのシステム機能を外部のクラウドに預け、どこを自社システムに乗せるかを判断しなければならない。

 システムは、ビジネスを実現する手段だから、個々のビジネス機能に対応するシステム機能を実装する必要がある。

 だから、まずは、ビジネス全体の流れを整理、系列化して、重複なきようにプロセスに分解する。そして、ビジネス全体をこれらプロセスの組合わせとして表現する。

 このような、一連の作業が、BPMだ。

 つまり、BPMとは、あるビジネスの範囲で、それをプロセスに分解、整理し、整列させることである。システムは、この分解された個々のプロセスに対応するように実装される。

 各業務プロセスは、相互に独立性が高いほうが望ましい。

 たとえば、[受注]-[出荷]-[受領]-[売上計上]という業務のプロセスが存在するとしよう。しかし、商品によっては、[受注]-[出荷]-[売上計上]-[受領]のほうが、都合がいい場合がある。もし、最初に決めた業務プロセスが、[受注]-[出荷・受領]-[売上計上]であれば、このような商品によるプロセスの組み換えが不可能となる。ということは、その都度、別々のシステムを作らなければならない。これでは効率が悪いので、プロセスは、その機能において重複無く、独立させなければならない。

 この業務プロセスに対応して、システム部品を用意しておけば、必要に応じてその部品を組合わせ、あるいは、順序を変えれば、必要とするシステムを実現できる。システムが、汎用化された部品の組み合わせとして作られていれば、他のシステムでも利用できるので、開発の生産性は高まる。

 このように、システムを特定の機能やサービスを提供する部品に分解し、他でも使えるようにインターフェイスを統一して、システムを開発する。これが、SOAのアプローチだ。

 つまり、BPMで整理されたビジネス・プロセスに対応したシステム開発の方法が、SOAとなる。

 これがなぜクラウドと結びつくかというと、このようにシステムが、機能やサービス単位で部品化されていれば、どこをどのクラウド・サービスに、どこをオンプレミスにという判断が容易になる。インターフェイスを標準化すれば、異なったクラウド・サービス、オンプレミス・システムを必要に応じて、最適に組合わせ、利用できるようになる。

 また、各業務プロセスに対応したシステム部品が、クラウド上で汎用的なサービスとして提供されれば、その部分の開発は不要となり、すぐに利用できる。走すれば、必要なシステムを短期間に利用できる。また、業務が変われば、その部分を他に入れ替えることもでき、変更にも柔軟に対応できる。

 クラウドが目指す理想像とは、こんなシステム形態といえるだろう。だから、クラウド-BPM-SOAは、切り離せない関係にあるのだ。

 冒頭申し上げたとおり、このような業務プロセスの整理整頓については、欧米人の方が、どうも素性がいいのではないかと思っている。日本人にできないとは思わないが、残念ながら、個人技、職人芸を尊ぶ文化である。これは、システム開発の現場にも根強い。それは、それで、すばらしいこととは思うのだが、世界に向けてビジネスを発信してゆこうとすると、このBPM-SOAのアプローチが不可欠である。

 そこをどう乗り越えればいいのか。それについては、また、次回。

-------------------------------------------------------
 こんな仕事をしています。
 よろしければ、弊社ホームページをごらんください。
-------------------------------------------------------

↓みなさん、有り難うございます↓
↓ここまで順位をのばすことができました↓
にほんブログ村 経営ブログ 営業へ

2009年7月8日

日本型クラウドの可能性(3)

 「日本型クラウド」といいながら、「メインフレーム」の話をしたら、それはIBMだから外国製ではないか?なぜ、それで日本型なのかというご質問をいただいた。

 ちょっと、言い訳をしておこう。

 もう10年以上前の話である。半導体メーカーのお客様をIBMの半導体工場であるニューヨーク州イーストフィッシュキルへお連れしたときの話。

 この工場は、最先端の8インチ・ウェハーを世界に先駆けて稼動させたところでもある。その後、このノウハウは、日本の野洲工場に移転され、日本でも8インチのラインが動き始めていた。
 
 私たちが訪問すると日本からの出向社員が、工場を案内してくれた。当時、この工場には、彼を含め野洲工場から派遣された多くの日本人のエンジニアが働いていた。彼らの目的は、歩留まり率の向上だった。

 いち早く8インチ・ラインを立ち上げたのは、米国であったが、歩留まりが上がらないことに手を焼いていた。そんな米国に続いて立ち上げた日本の野洲工場は、米国で開発された最新の半導体製造技術をベースにしつつも、日本独自の工程管理のノウハウを組み込んで、本家をしのぐ歩留まりや生産性を実現していたのである。

 そこを見込まれて、本家の支援にやってきていたのだ。

 また、こんなこともあった。

 IBMを卒業の後、ある外資系の半導体製造装置メーカーのマーケティングと営業を手伝ったときのこと。このメーカーの製品は、欧米のエンジニアが設計し、中国と香港で製造していた。

 中国・深センにある工場に行って驚いたのは、ずらりと並ぶ最新鋭の生産設備。アマダのマシニング・センター、イスラエル製のプラスチック成型機械・・・どれもコンピューター化され、工作精度はきわめて高い。

 あるとき、この工場に部品を納めている日本企業のエンジニアに話を聞く機会があった。彼によると、この工場は、通常より一桁高い公差で部品を納めるように求めているらしい。そのため、コスト的に相当きついとのこと。

 当然出来上がってくる製品の精度は高いものと期待されるが、意外にも普通なのである。仕様の上では、世界最高であっても、実用性能は、それほどでもなかった。

 こんな装置を輸入して、日本のお客様にお納めするのだが、これを日本のエンジニアが、出荷前に徹底的に整備、調整すると、実におどろろくべき性能を発揮する。

 欧米の優れた設計思想とユニークなアイデアの数々。部品や加工精度の高さ。実に素性がいい。これを正しくくみ上げ、調整すれば、そのポテンシャルを最高に引き出すことができるのは、当然といえるかもしれない。

 「どうすれば、そんな性能が出るのか?」と開発や製造の人間が、聞きにくるほどであった。

 ユニークなアイデア、それにチャレンジし、リスクを犯してでも試してみようという行動力は、欧米諸国の伝統といえるかもしれない。一方、いいと思ったなら一意専心に改良を重ね、完成度を高め、百花斉放のこどく、その本領を発揮させることに、日本人は長けているように思う。

 さて、話を「メインフレーム」に戻すが、「メインフレーム」は、確かに欧米の優れた着想と思想に支えられた製品であり、外国で作られた製品である。しかし、その能力は、機械本来の性能だけではなく、高度な運用管理能力無くして、最高のパフォーマンスを引き出すことがてきないのは言うまでも無い。

 あるコールセンターのコンサルタントから聞いた話だが、「日本の顧客ほど、応対の品質にうるさい客はいない」そうだ。当然、コールセンターもお客様の満足度を高めるために、徹底した工夫と教育を怠らない。そんな積み上げが、世界でも最高の応対品質を実現しているという。

 このような顧客の高い要求に応えなければならないという、強迫観念にも似たプレッシャーは、チャレンジを避け、ユニークなことを排除するというネガティブな一面はある。しかし、その一方で、徹底して品質や完成度を高めなければならないという、モチベーションを生み出していることは確かだろう。

 「メインフレーム」は、IBM、「NGN」も使われている機器の多くは、CISCOなどの外国製品も多いと聞く。その意味では、純粋な国産ととはいえない。しかし、そんなことはあまり意味が無い。

 私が、日本型クラウドと申し上げているのは、単に機械のことではない。高い品質を求め、徹底して運用の品質や完成度を高めたサービスを提供することに、日本人は、執拗なまでにこだわるところがあるからだ。これは、家電製品同様、世界でも十分に受け入れられるのではないかと思っている。



-------------------------------------------------------
 こんな仕事をしています。
 よろしければ、弊社ホームページをごらんください。
-------------------------------------------------------

↓みなさん、有り難うございます↓
↓ここまで順位をのばすことができました↓
にほんブログ村 経営ブログ 営業へ

2009年7月6日

日本型クラウドの可能性(2)

 クラウド・コンピューティングの課題として、よく言われるのが可用性と信頼性だ。それには、3つの要素が相互に関係している。

 まず、ひとつは、PCサーバーの信頼性。昔に比べて、PCサーバーの信頼性は、高まったとはいえ、銀行の勘定系に使えるレベルには無い。だから、可用性を高めるためには、冗長度を高めなければならない。しかし、冗長度を高めれば高めるほど、今度は、運用管理が複雑となり、システム全体を見たときの信頼性は、再び低下する。

 PCサーバーの魅力は、取得金額(TCA:Total Cost of Acquisition)が安いことにあるが、それは同時に信頼性もその金額に見合うものという現実をうけいれることでもある。それでは困るということで、冗長度を高めれば、今度は、TCO負担が増大する。結局は、どこかでこの両者に折り合いをつけなければならない。

 二つ目は、ミドルウェアの組み合わせ。たとえば、クラウド環境を構築する上で欠かせないのが、仮想化だ。これには、サーバーの仮想化やストレージの仮想化がある。また、分散ファイル管理機能も必要だ。さらには、負荷配分のための機能も必要になる。このように、クラウド環境を実現するためには、さまざまなミドルウェアが介在する。

 これらミドルウェアを単体で取り出せば、夫々に責任の所在も明確であるだろうし、各社完成度を高めるための努力は行われている。しかし、いったいそれらシステムの組合わせについては、誰が責任をもってくれるのであろうか。

 結局は、運用事業者の責任となるのだが、彼らにも、全体の信頼性を保証できる根拠が無い。従って、ユーザーにクレームされれば、「ネットワークの障害です」、「相性の問題です」、「仕様なので仕方がありません」という言い訳で、乗り切るしかない。

 最後は、ネットワークの信頼性だ。いうまでも無く、インターネットにQOSを求めることには無理がある。セキュリティ上の課題も存在する。従って、たとえデータセンター・システムの可用性を高めたとしても、ネットワークが、ボトルネックとなることは、さけられない。

 PCサーバー、ミドルウェア、ネットワークが、夫々に持つ信頼性と可用性についての限界。それらが、組み合わさることで、さらにシステム全体として、信頼性と可用性は、低下せざるを得ない。というか、そもそも、だれが保証してくれるのかという、責任の所在、つまり、トータル・クオリティ・マネージメントが、できない状況の下で、提供されているのが、現在のクラウド・コンピューティング(厳密に申し上げれば、パブリック・クラウド)の現実だ。

 このような現実であっても、99.9%や99.95%を保証するというわけであるから、これは相当の努力であり、技術力だと思うべきかも知れない。しかし、ユーザーにとっては、彼らがどのような努力をしていようとも、結果として、求める可用性が提供されなければ、基幹系、勘定系ではつかえない。

 そこでであるが、品質や信頼性に、過剰なまでに神経質な我が国民気質が、このクラウドに新しい可能性を提供してくれるのではないかと密かに期待している。「高信頼性クラウド・コンピューティング・サービス」という切り口だ。ノーダウン、QOS、低コストのクラウド・サービスである。

 どうやって、これを実現するかといえば、「メインフレーム」と「NGN」の組合わせだ。

 何をいまさら、メインフレームと言われるかもしれないが、メインフレームは、ここ数年劇的に進化している。自分が、元IBMの営業だからというわけではない。最近、改めてメインフレームを勉強しなおし、それを実感した。

 残念ながら、メインフレームにまともに開発投資し続けているメーカーは、IBMだけである。その予算は、年間1000億円を超えるという。その集大成が、System/z。

 たとえば、一台のPCサーバーに仮想化ミドルを導入し、いったい何台の仮想マシンを動かすことができるだろうか。まず、10台を動かすことは無理だろう。現実的な運用を考えれば、数台がいいところだ。しかし、メインフレームならば、比較的小規模なモデルであっても、簡単に数十台、規模が大きくなれば、数百台、数千台は問題なく稼動する。

 これは、単にプロセッサー能力の問題ではない。基本機能として持っている高度な負荷管理機能、入出力の負担を専門で請け負うプロセッサーであるチャネルの存在。ハードウェア・レベルで仮想化を実現するLPARなどなど。昔から、高価なメインフレームというシステム資源を、できるだけ多くのユーザーに同時に使ってもらうための研究開発の蓄積が、今大いに生かされている。

 限られたシステム資源をできるだけ多くのユーザーにサービス・レベルを保証しながら、しかもノンストップで利用させる技術。これに、半導体やストレージの価格性能比の向上が組み合わさって、「高価なメインフレーム」の汚名を返上しつつあるようだ。

 「ソリューション営業塾」で、メインフレームについて話したときの資料を以下に掲載する。



 また、System/zは、ネイティブで、Linuxが稼動する。もちろん、複数の仮想マシンの上で多重に稼動するのである。IBMの資料によれば、40万人で3900台のLinuxサーバーを使っているのだが、これを30台のメインフレームに集約しようというプロジェクトが進んでいるそうだ。これによって、TCOは、90%削減される。

 メインフレームは、ハードウェアからOS、ミドルウェアまで、すべてIBM一社が、その組合わせに責任を持っている。全体の責任の所在が明らかであり、全体で相互の稼動を保証し、最適化されている。

 そもそも、メインフレームは、その設計思想上、ノンストップである。故障しても稼働中に修理し、復旧できるように作られている。PCサーバーでよく行われる「リブート」などという、ごまかし操作はありえない。そのプラットフォーム上で動くLinuxシステムの可用性もまた、同じレベルが保証される。

 ひとつのシステムあたりの多重度が高まれば、システムの運用管理負担も低減し、信頼性も高まる。その結果、ユーザーあたりのTCOも低下する。

System/z同様に、IBM/i(旧AS/400)も同様の思想の上に作られている。ネイティブOSに加え、Linuxも動くし、Windowsも、同時多重で稼動する。これであれば、比較的規模の小さな事業者でもサービス環境を構築可能であろう。

 さらに、わが国が誇る高信頼性のIPネットワークであるNGNサービスを組合せば、AmazonやGoogleとは、異なる「高信頼性クラウド・コンピューティング・サービス」を実現できるのではないだろうか。

 別に、IBM製品を売り込みたいわけでもなければ、NTTさんの回し者ではない。あくまで、客観的な視点で考えてみた結果だ。

 この両者の組合わせは、クラウドの弱点を克服し、しかも日本人の感性にも符合するのではないか。

 日本発世界に向けたクラウド・サービスのひとつの可能性として、考えてみてもいいのではないかと思う。

---------------------
おかげさまで、ここまでランクアップいたしました。
ありがとうございます。↓↓
にほんブログ村 経営ブログ 営業へ

2009年7月3日

日本型クラウドの可能性(1)

 クラウドが、ビジネスになるのかという議論は、もはや意味がないと思う。Google、Amazonを見れば分かるとおり、すでに立派にビジネスとして成り立っている。

 SaaS(Software as a Service)型クラウドの代表であるGoogle Appsは、GmailやDocsなど、パーソナル・プライベート・ツール(PPT)のクラウド化をターゲットとしている。これは、Microsoftのビジネスと完全にかぶっている。では、どちらが、お得なのか。

 私が主催している「ソリューション営業塾」で、クラウド・コンピューティングの講義を行ったとき、Googleの有償サービスである、Google Apps Premier EditionとMicrosoft Office Enterprise 2007を比較した資料である。



 これを見ると、Google Appsの年間コストは、Microsoft Officeの1/2であることがわかる。ただし、MS Officeの場合は、これ以外にも導入やアップデート、トラブル(MS OfficeかPCかどちらが原因かわからない場合も含めて)対応しなければならないので、さらにコストがかかることになる。

 同一機能ではないので、単純に比較することもにも無理はある。しかし、日本ほど、見た目やブランドにこだわらない米国では、ユーザーがどんどん増えているらしい。

 Amazonのクラウドは、システムのインフラを提供し、アプリケーションは、どうぞご自由にお作りくださいというビジネス・モデルだ。IaaS(Infrastructure as a Service)型クラウドといわれるものである。表現を変えれば、データセンターのデスクトップ化、つまり、個人でも、中小企業でも、設備の導入や運用管理を伴わず、データセンター・リソースを必要なだけ従量課金でお使いくださいというものだ。

 例えば、いままでなら、ウエブ・ビジネスをはじめようとすれば、自分のところに置くか、データセンターに預けるかは別にして、相応のシステムを所有しなければならなかった。当然、システム構築にもコストがかかる。それがなくなる。そのため、中小企業でも、少ない投資リスクでウエブ・ビジネスをはじめられるようになった。

 やはり、「ソリューション営業塾」で使った資料であるが、オンプレミス型(自身でシステムを所有し、運用管理するシステム利用形態)とクラウド型でのシステム開発形態の違いを整理したものである。



 Amazonのクラウドサービスは、このような中小企業の需要に支えられて、これまた急激にユーザー数を伸ばしているらしい。

 ただ、これらクラウド・サービスも、稼働率という点では、まだまだたよりない。Googleは、Google Appsの稼働率を99.9%としている。これは、年間でおよそ8時間停止することを意味している。ただし、メンテナンスなど、事前に計画され、通知されるシステム・ダウンについては、含まれていない。

 また、Amazonは、その中核となるサービスEC2の稼動率を99.95%としている。これとて、年間4時間の停止である。

 これに加えて、パブリックなネットワークを利用するとなると、その稼働率や信頼性も考慮しなければならないので、実質的な稼働率は、もっと低下すると考えるべきだろう。

 一般的に、大手銀行などの場合は、稼働率は限りなく100%である。具体的には、99.9999%の保証が求められる。これは、年間30秒程度の計算になる。

 ここまでの稼働率は、ともかくとしても、小数点以下一桁や二桁程度では、基幹業務で使うには、心もとない。しかし、PPTやエンターティメント系のウエブ・アプリケーションであれば、問題ないレベルといえるかもしれない。

 稼働率については、両者とも重要な課題として取り組んでいるようなので、このあたりは、いずれ改善されるだろう。しかし、そんな先のことを考えなくても、使える業務領域は、いくらでもあるように思う。

 また、そもそも、中小企業であれば、基幹系とて、99.9%の稼働率さえ維持できていないところも少なくない。そんな現実を考えれば、「基幹系でも使えるところがある」と考えていいのではないだろうか。

 しかし、これは、GoogleやAmazonだからできることであって、わが国で同じ様なサービスを提供できるのだろうかと考えると、簡単なことではない。

 では、どうすればいいのだろうか?次回、その点について、もう少し掘り下げてみようと思う。

■ ソリューション営業プロフェッショナル養成講座 ■

どうすれば、新しいビジネスを立ち上げられるのだろうかを、考えてみませんか?

 7月10日(木)、11日(金) 東京・茅場町 
 7月16日(木)、17日(金) 沖縄・ITOP

-------------------------------------------------------
 こんな仕事をしています。
 よろしければ、弊社ホームページをごらんください。
-------------------------------------------------------
↓みなさん、有り難うございます↓
↓ここまで順位をのばすことができました↓
にほんブログ村 経営ブログ 営業へ



2009年7月2日

コミットメントとサイエンス

  「平和と科学が進歩した今日、この記録がどれほどの価値があるのか、わかりませんが、あの時代の若者たちが、祖国を守るために示した精神力が、現代の日本人、特に今日の若い人たちの気迫の上に訴えるものがあれば幸いです。」

 第二次世界大戦中、零戦を駆って戦った撃墜王、坂井三郎の著「大空のサムライ」の冒頭の言葉だ。

 友人に進められ、読み始めたのだが、あまりの面白さに分厚い上下二冊の文庫本も、三日ほどで読みきってしまった。

 戦争を「面白い」とは、不謹慎かもしれない。しかし、フィクションではない、戦争を生き抜いた生々しい体験者の言葉、そして、冒頭にもある「気迫」が、その悲惨さを越えて、伝わってくる。そんな彼の生き様、そして、私の知らない戦争のおどろおどろしい現実。驕りもしなければ、美化もしない、平明達意な文章に引き込まれてしまった。

 コミットメントという言葉がある。必達目標と訳されるが、未達ならば、その責任を取るという含意もある。戦闘機乗りである坂井氏にとっての未達とは、即ち死を意味していた。

 「どんなに不利な状況にあっても、死力を尽くす覚悟」、「必勝の信念」を持つこと。そして、そのために、冷静に自分の行動を見つめなおし、まだできることがあるのではないかと徹底的に考え、工夫し、行動することの大切さを、彼は語っている。

 「生きるためではなく、戦いに勝つために全力を尽くした。死は、ひとつの結果に過ぎず、何よりも大切なことは、勝つことである」という彼の信念こそ、まさにコミットメントそのものであるように思う。

 そんな彼の信念があればこそ、戦死率が最も高い飛行機乗りにあっても、彼を生かし、敗戦を迎えさせたとも語っている。

 不況である、予算達成も容易ならざる状況だ。果たして、自分は、自分に対して、あるいは、部下に対して、言い訳はしていないだろうか。

 幸いにも、私たちは、未達でも死ぬことはない。上司にお叱りを受けるだけである。にもかかわらず、失敗を恐れ、これでもかという工夫を放棄してはいないだろうか。

 この著のもうひとつの魅力は、零戦のメカニズムと戦法について、きわめて冷静に、論理的に考証していることにもある。彼は、単に精神論だけで、戦い抜いたわけではない。

 彼は、続著「零戦の真実」の冒頭で、「われわれの愛機であった零戦についても、万能というには、程遠い欠陥を多く抱えた機であった」ことを認めている。それでも、「零戦に遭遇したならば、戦闘を回避し、逃げるべし」と戦闘マニュアルに記載されるほどに、敵国の戦闘機乗りを震撼させのである。

 「長所を活かし、短所を補う」、「長所と短所、その相反する因果関係にある愛機に折り合いをつけ、あるときはあきらめ、あるときはほれ込んで戦っていたのである」と彼は書いている。

 私たちの現実もまったく同様ではないかと思う。万能な武器などどこにもない。だからこそ、その短所、長所を見極め、戦法を工夫し、競合他社と戦っている。

 冷静な分析力、論理的方法論なくして、必勝の精神だけでは、戦に勝つことなどできないことを彼は、自らの戦いを通じて証明して見せたのである。

 私は、今、営業研修に取り組んでいる。まさに、その精神は共通している。がんばれば、不況を乗り切れるなど、ありえはしない。お客様に足しげく通えば、案件が見つかるなどは、「がんばればなんとかなる」の類であり、なんら根拠のないばくちである。

 営業という仕事の仕方、いうなれば戦法は、論理的で科学的でなければならない。それを伝えることにこそ、私の役割だと考えている。

 2000年9月、彼は鬼籍に入られた。しかし、数多く残された彼の至言は、時代を超えて、受け継がれてゆくのだろう。久々に「これぞ」という一冊にめぐり会わせてくれた友人に感謝したい。


営業という仕事を科学すること。不況を気合で乗り切ることはできません。


-------------------------------------------------------
 こんな仕事をしています。
 よろしければ、弊社ホームページをごらんください。
-------------------------------------------------------

↓みなさん、有り難うございます↓
↓ここまで順位をのばすことができました↓
にほんブログ村 経営ブログ 営業へ

2009年7月1日

マネージャーとリーダー

 「マネージャーはいるが、リーダーがいない。」あるソリューション・ベンダーのベテラン営業さんから、そんな話を伺った。なるほど、面白い視点だと持ったので、ここで考えてみることにした。

 マネージャーとは、組織としてのパフォーマンスを最大化する責任を担っている。とすれば、部下の能力や性格を見極め、リソースの最適な配置を決め、目標達成のための行動を起こさせるなくてはならない。

 状況を冷静に整理し、行動に裏づけを与え、必要とするリソースを準備する。高度な理性と判断力が求められる。

 さて、リーダーとは何か。言葉通りに受け取れば、「先導者」である。道を示し、率先して、その道を進む。人を魅了し、従おうという気持ちにさせる。

 リーダーには、先を見通す力が必要だ。世の中の動き、人々の心の機微、時代のトレンドなどなどが、これからがどう動くかを予測し、その先を見通す感性が必要だ。直観力というべきかも知れない。たぶん理屈だけでは超えられない、見えない先を見取り、感じ取る能力というべきだろう。

 そして、欠くべからざるは、信念である。これをやるんだという強い決意である。従うものに安心を与え、ともに何とかしようという決意を起こさせる。

 よき指導者とは、理性的な側面であるマネージメント能力と感性的な側面であるリーダーシップ能力を兼ね備えた人たちなのだろう。
 
 霞を喰らうことができないように、夢だけを追いかけてみても、生きてゆくことはできない。しかし、行くべき道、あるべき姿を示されなければ、いくら合理的な行動であっても、疲れてしまう。

 営業もまた、お客様にとってのリーダーであるべし

 確かな信念と、自信を示し、お客様に正しい道を示す。それができれば、お客様はあなたに従い、売り込まずして、モノは売れる。

 さて、自分はどうか?とてもその「うつわ」では、なさそうだ(笑)。


営業としてお客様にリーダーシップを発揮する方法とは、・・・


-------------------------------------------------------
 こんな仕事をしています。
 よろしければ、弊社ホームページをごらんください。
-------------------------------------------------------

↓みなさん、有り難うございます↓
↓ここまで順位をのばすことができました↓
にほんブログ村 経営ブログ 営業へ