インプットとアウトプットのバランス

8月 17th, 2013 | Posted by admin in イノベーション | 経営 - (インプットとアウトプットのバランス はコメントを受け付けていません)

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

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

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

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

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

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


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

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

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

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

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

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

プログラミング科目を必須にすべき3つの理由

4月 7th, 2013 | Posted by admin in テクノロジー | プログラミングを考える | 経営 - (プログラミング科目を必須にすべき3つの理由 はコメントを受け付けていません)

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

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

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

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

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

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

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

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

最後に

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

スペックを書くコツ

3月 20th, 2013 | Posted by admin in テクノロジー | 経営 - (スペックを書くコツ はコメントを受け付けていません)

これまで、ビジネスとしてシステムのスペック(仕様)を書く仕事をしてきて、スペックの書き方にはコツがあるなあと思うようになってきた。

ちなみに、ここでいう、スペックは、システムをつくる上流工程での要件定義・基本設計で、それをもとにシステムを作ったり、あるいは、ベンダーにRFP(Request For Proposal)として提示して、見積もりをお願いしたりする。そして、要件定義・基本設計を大きく外さなければ、それに続く設計・実装もそれほど大きく外れることはない。言ってみれば、建物の設計図に相当するもので、作ってみたら、”柱が足りなかった”、”家が傾いていた”、ということがあってはならない。

それで、どうやってスペックを書くか、一言でいえば、”漏れをなくし、重複をなくす”だと思う。

 これはコンサル用語でいうところ”MECE(Mutually Exclusive and Collectively Exhaustive)”であり、漏れなく、重複なく、は当たり前のことなんだけど、これが以外と難しい。結局のところ、何が漏れているのか、全体像が見えていないとわからないし、経験を積まないと、失敗するポイントも見えてこない。

 どうやって漏れと重複をなくすか?その一つのアプローチとして、自分がいつも心がけているのが、証券アナリストをしているときに教わった”分解して考えるべし”という考え方だ。たとえば、ある会社の売上高が100億円だったとして、その100億円が、業種別(金融30億円、製造業70億円など)、セグメント別(コンサル10億円、システム開発60億円、物品販売30億円など、そして、この組み合わせによって粗利が決定される)に分解することができる。そして、その分解の粒度(金融であれば、そのうち、銀行、証券、保険など、さらに銀行であれば都市銀行、地方銀行、最終的には個社(MUFJなど)に帰着する)を上げれば上げるほど、その会社の特性、何が伸びて、何が落ち込むのか、おぼろげながらわかってくる。

 これはスペックを書くときも同じで、結局、経営もしくは発注側は、”ECのシステム作りたい”など漠然としたリクエストが多い。その漠然としたコンセプトを漠然としたままでいくと、結局できるものも漠然としてしまう。だからこそ、分解して、分解して、分解する、その過程で、不必要なところを削り、必要なところをさらに深堀りする。これを繰り返すことで、漏れなく、重複なく(MECE)を実現できるケースが多い。もちろん、分解しすぎて、全く当てが外れることもあり、どこを捨てて、どこを深堀りするかの勘所を押さえるのは経験によるものだと思う。

 いってみれば、このMECEは分解した後の結果であり、それ自体は目的じゃないと思う。そして、分解して、分解して、分解する、これが重要なんだと思う。

便利屋ビジネスと顧客満足度

3月 11th, 2013 | Posted by admin in テクノロジー | 経営 - (便利屋ビジネスと顧客満足度 はコメントを受け付けていません)

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

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

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

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

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

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

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

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