Tweet

かつて証券会社でアナリストをやっていたときの話。

アナリスト（野村証券、みずほ証券などのような株を売る側、通称、セルサイド）は、基本エクイティセールス（以下、営業）とタッグを組んで、顧客（機関投資家、ＸＸ信託銀行、ＸＸアセットマネジメントなど）に株を推奨する。

それで、アナリスト当時、苦労していたのは、インプットとアウトプットのバランス。

アナリストのインプットは、自分の担当業界（ＩＴ業界など）の会社に足しげく通って、取材して、カバー（将来の収益予想モデルをつくって、メンテする）する。電話で確認する場合もあったけど、実際に訪問すると、微妙なニュアンスを感じ取れたりするので、基本、足で稼ぐことが大切。

アウトプットは、足で稼いだ情報を、レポートとして提出し、その内容をミーティングなどで機関投資家に伝える。その情報に従って、投資すると、リターンを取れる場合もあるし、そうでもない場合もある。

それで、難しいのは、インプットとアウトプットのバランス。インプットばっかりで、なんもアウトプットしてないと、”ちゃんと仕事してんの？”となってしまう。一方で、インプットなしでアウトプットだけだと、上っ面をさらっただけでアウトプットの深みがなくなる。

ちなみに、この図式、ＩＴ業界でもかなりよくある。営業と技術の関係は営業とアナリストのそれと全く同じだ。

営業は、その名の通り、自社の製品（サーバ、パソコン、ルータ）などを売るのが仕事。

でも、営業がすべてお客さんのところに行って、お客さんでの契約を受注できるとは限らない。

たとえば、お客さんのところの技術担当者が”技術を呼んでよ”となり、技術を呼んで、その技術が、お客さんに対して、説得できる説明であれば、お客さんは発注する。

ただし、技術もずっとお客さんのところにいってアウトプットしては、製品についてのインプットがなくなり、気がついたら、自社の最新製品を知らなかった、というのは結構多い。

アナリストと営業、技術と営業、結局のところ、重要なのはバランスなんだと思う。インプットとアウトプットのバランスをとる、これは楽なようで難しい、でも、それをやらなくてはいけないってことだと思う。

Tweet

プログラミングを高校・大学の必須科目にすべきという話があるけど、自分はこれにもろ手を挙げて賛成です。

もちろん、高校・大学でちょっとプログラミングを勉強したところで、すぐに企業に入って役に立つというわけでもないけど、次の３つの理由からとても大事と思います。

必須にすべき理由その１：目に見えないシステムを理解する

　システムを作る作業は基本的には建築現場の土木工事に似ている。まず、どんな建物ができるかきちんと設計し、予算を割り当てて、リソース（自社ですべてできる場合は少ないので、場合によっては外注）を確保して、スケジュール通りに仕上げる。ただし、土木工事と違う点は、土木工事は目の前の建物が建っているのはわかるのに対して、システムの場合は、目に見えないこと。そして、目に見えないから、”こんなシステムすぐできるだろう”のように無茶をいう経営者もそれなりにいる。もちろん、あえてシステムを知らないことで自由な発想を生み出すことができるのも事実だけど、目に見えないシステムをプログラミングを通じて理解するのはとても重要だと思う。

必須にすべき理由その２：プログラミングの裾野を広げる

　高校・大学でプログラミングをやったからといって、全員がシステム会社に就職するわけでない。たとえば、自分は大学時代、慶応湘南藤沢キャンパスで6年間過ごして、最初の1年は情報処理のクラスでプログラミング（C言語）が全員必須だった。そして、SFC生全員がシステム会社に入ったかというと、もちろん、そんなことなく、銀行にいったり、公務員になったり、商社にいったり、プログラミングと全く縁遠い業界に入った卒業生も無数にいる。でも、かつて、裾野の広さと500 startupsというエントリで書いたように、ニュージーランドのラグビーのようにプログラミングの裾野を広げることは、次の新しいベンチャー、産業を生みだす点で大切。

必須にすべき理由その３：問題切り分け力をつける

　当たり前だけど、コンピュータは人間が指示したことしか実行しない。そして、プログラミングは、やや抽象的な言い方だけど、”コンピュータに指示する手続き”ともいえる。そして、コンピュータにプログラミングによって”指示”しても、自分の思い通りに行かないことが多々ある、いわゆる、”バグ”だ。それで、どうやって、バグを見つけて、正しい動作にするか、それが”問題切り分け力”だと思う。不具合の原因をあらゆる可能性から検討して、問題解決のあたりをつけて、そして、修正する。自分も最近コンサル案件でプログラミングの手伝いをすることがあるけど、結局、プログラミングとは、問題切り分け作業の連続だと思う。そして、言うまでもなく、この問題切り分け力は、プログラミングだけではなくて、営業、製造、管理、経営などあらゆる場面に応用が効く力で、こうした力はプログラミングによって涵養される要素が大きいと思う。

最後に

　これまでシステムエンジニアの採用を経験したことがあって、そこからわかったこと。それはシステムエンジニアには2つのタイプがある。一つは、あるプログラミング言語に特化して、それを極めるタイプ、今だと、Javaのフレームワークなどそれなりに需要があるので、特化タイプもマーケットはある。一方で、プログラミング言は、言語体系は違えど、考え方（制御構造、データの持ち方、アルゴリズムなど）は同じなので、あるプログラミング言語をマスターして、それを別のプログラミング言語に応用できるタイプ。企業とくに小さい企業では、後者の方が柔軟性があるので、こっちの方がニーズがある。そして、プログラミング科目必須になって、後者のような柔軟に応用ができるタイプがたくさん育てば、これほど日本全体にとってプラスなことはないと思う。

Tweet

先日、写真の便利屋のチラシが入っていて、いろいろとビジネスを考えるきっかけになりました。

かのピーター・ドラッガーは、企業活動の目的について、”顧客の創造”と定義しました。それは当たり前の話で、お客さんがいなくては、ビジネスにならない。

そして、この便利屋のビジネスも、”ゲームの相手がいない”、”犬の散歩の時間がない”、”洗車の時間がない”といった”時間をお金で買う”顧客にハマるモデルだと思う。

ただ、これでビジネスとしてマネタイズできているのか。これは、どこまでお客さんのわがままを聞くか、だと思う。

”お客様は神様です”よろしく、お客さんのわがままをすべて聞く、もちろん、これは顧客満足度を高める最大の方法だけど、ビジネスとして成り立つとは限らない。

たとえば、自分のなじみのあるIT業界では、システムをつくる際、顧客のシステム設計をする際に、”お客様は神様です”とばかりに、、”ＥＣと連動したい”、”ボタン一発で経営状態が見えるようにしたい”など、お客さんの言い分をすべて聞いて、システムを作ろうとすると、ほとんどの場合、予算、制限時間オーバー、もしくは、ひどいとシステム会社の持ち出しになってしまう。やはり、お客さんのわがままをすべて聞くいわゆる”御用聞き”は必要とされていない。むしろ、腕利きのプロマネは、お客さんのやりたいことを制約条件（予算、時間）のなかでうまく調整する、あるいは、断る能力に長けていると思う。ちなみに、当社では、このシステムと経営とのギャップをセカンドオピニオンサービスという形でギャップ分析を提供しておりますので、お気軽にお問い合わせください。

　便利屋もこのシステム開発の話と同じで、お客さんのやりたいことをすべて聞いていると、たぶん、ビジネスとして成り立たないと思う。だからといって、”これはできません”と断り続けては、便利屋の沽券に関わる問題で、その折り合いの付け方が、便利屋ビジネスモデルの肝・ノウハウなんだと思う。ちなみに、システムの話に戻ると、システムでは、この肝・ノウハウは、パッケージに相当します。極端な話だけど、Windowsには、製造業向け専用Windowsもなければ、医療向け専用Windowsもない、どの業種でも同じ。パッケージを買って、インストールするだけで終わり、ものすごくレバレッジの効くビジネスだと思う。Windowsまでいかないにせよ、多くのパッケージは、”お客さんのやりたいこと”がだいたい凝縮されていて、それをインストール＆カスタマイズである程度のことができる。そして、”だいたい”という最大公約数をどこに設定するのかが、企業の腕の見せ所、ニーズの捉えどころなんだと思う。

　こう考えると、最初の”顧客の創造”とは、単に、お客さんのわがままを叶えておカネをもらうのではなく、お客さんがおカネを払ってでも、その成果に満足する仕組み（イノベーションとも言えるかもしれない）を作ることなんだろうと思いました。改めてドラッガーの教えての深さが身に沁みます。