仙石浩明の日記

2008年7月22日

技術力が高い人こそ、ビジネスモデルの良し悪しにもっと敏感になるべき hatena_b

先週参加した社外の飲み会 (私は飲めないので専らウーロン茶でしたが) で、 Linux ディストリビューションの開発や、 カーネル技術を売りにしたコンサルティングで有名な某社の カーネル技術者とお会いしました。 彼はいま伸び盛りの若手カーネル・ハッカーなのですが、 オープン・ソース・ソフトウェア (以下 OSS と略記) ビジネスについて熱く語ったり、 ディストリビューションをサポートし続ける使命感に燃えていたのが、 わたし的にはちょっと気になりまして、 ひとこと言いたくなってしまいました(お節介ですね ^^;)。

ディストリビューションのサポート体制 (カーネルのバグにも的確に即応できる体制) を維持し続けることによって、 多くの企業で Linux を安心して使ってもらうことができて、 それが OSS の発展につながるし、 それこそが自分の使命だと彼は考えているようでした。 それはそれで意義あることだとは思うのですが、 彼のような優秀な技術者には、 「サポート」という目的だけに捕らわれず、 もっと自由に興味の赴くまま学び、 自らのスキルを伸ばしていって欲しいと思ったのです。

OSS 関連のビジネスというと、 すぐ、 サポートでお金を稼ぐとか、 OSS 活用のコンサルティング事業とかの発想をする人が多いのですが、 誰もが思いつく事業だけに、 ビジネスモデルとしては稚拙な部類と言わざるを得ません。 高い技術力がそのまま売りにつながった前世紀ならいざ知らず、 競争が激化してビジネスモデルの巧拙が事業の成否を大きく左右する昨今、 いまだに何の「ひねり」もない「OSS サポート」に固執するのは、 いかがなものかと思うのです。

技術コンサルティング事業というと聞えはいいのですが、 要は「人月ビジネス」です。 どんなに優秀な技術者 (「ピンからキリまで」 の「ピン」ですね) であっても、 一人月 1000万円払ってくれるお客がいるはずはなく、 素人技術者 (以下「キリ」と略記) の 5~6倍の人月単価を稼げば御の字というのが実状ではないでしょうか。 だからコンサルティング事業といいつつ、 高額のソフトウェアを売り付けてライセンス料を稼ぐことのほうが、 メインの目的だったりする会社もあるわけです。

ただあいにく OSS の場合は高額のライセス料を請求するのは無理があります。 せいぜい保守料と称してわずかばかりの費用を請求するのが関の山でしょう。 だから OSS のコンサルティングというのはあまりよいビジネスモデルとは言えません。 ものすごい労力とコストをかけてピンをそろえて (お客に高いね~と言われつつ) 5倍の人月単価を設定するくらいなら、 コストをかけずにキリを大量に集めて格安な人月単価で売りさばく (いわゆる派遣ビジネス) 方が、 経済合理性にかなうというものです。

キリに成長の機会も与えずに 「若いだけが取り柄の労働力」 として派遣して使い捨てにする事業は当然非難されるべきですが、 労働時間では測りしれない価値を持つはずのピンを人月換算してしまう事業もまた、 非難されるべきではないでしょうか? 人月ビジネスでは売上を増やすには人員を増やさざるを得ず、 売上が拡大しても決して余裕は生まれません。 いやそれどころか、 どんどん仕事を片付けてくれる優秀な技術者にどんどん仕事が集中して、 優秀な技術者ほど疲弊する、 という理不尽なことも起り得ます。

頼りにされるあまり、多くの仕事がその人に任されることになる。 できる人に、仕事が集中するのは、よくある話で、 その人は、回りの期待にこたえようとして、遅くまで残業して、 休日も出社したりする。 この状態が、一過性のものだったら良いんだけど、 慢性的なものになると、肉体も精神もぼろぼろになっていく。

ピンとキリでは生産性で何十倍~何百倍 (私は 3桁の差があると日頃から主張していますが) もの差があるのに、 わずか 5~6倍の売上の差しか出せないのは、 「儲ける仕掛け」が無いからです。 ピンの労働時間を人月換算するのではなく、 ピンの技術なしには実現できないような (つまり競合他社には構築不可能な) 儲ける仕掛けを編み出して売上を増幅し、 それによって生じた余裕でピンの仕事量を思いきって抑えることによってこそ、 その優秀さに報いることができるのだと思います。

そうすれば仕事の負荷が軽くなったピンは、 ピンならではの新しい価値を産み出すことに注力できます。 新しい事業のシーズを産み出す研究開発でもいいですし、 あるいは OSS から恩恵を受けている企業であれば、 ピンの人が (勤務時間中も) OSS コミュニティで活躍することを奨励することによって、 OSS の世界に「恩返し」することもできます。

前世紀は技術力が高ければ儲ける仕掛けを誰でも作ることができた時代でした。 つまり優れたソフトウェアなら結構な値段で売ることができたのです。 マーケティングがしっかりしていれば、 開発費を大幅に上回る売上も達成できました。 典型例はマイクロソフトですね。 ピンが作ったソフトウェアを何億本も売ったわけで、 ピンの労働力が人月単価の何万倍もの価値を生んだことになります。 その後 OSS の発展と普及により、 ソフトウェアを売るだけというビジネスモデルは行き詰まりました。 今ほど新しいビジネスモデルが重要となった時代はないと言えるでしょう。

さらにいうと、 技術者が優秀であればあるほど、 その「シーズ」は一般人の「ニーズ」からかけ離れていく、 という難しさもあります。 例えば、 優れたカーネル・ハッカーの技術を、 真に必要とする人が世の中にどれだけいるのか?という問題です。 技術の素人である大多数の消費者にとっては、 小難しい技術のことなんか全く分からないし興味もありません。 高い技術力が売れるどころか、 逆にその高度さが「需要」を減らしてしまう原因となりかねません。

高度な「シーズ」と一般の「ニーズ」を結び付けるには、 高度なビジネスモデルが求められるわけで、 技術者がハッキングの合間に思いつくようなビジネスモデルではお話になりません。 優れたカーネル・ハッカーが、 四六時中寝る間も惜しんでカーネル・ソースのことばかり考えているのと同様、 優れたビジネスモデルを考え出すビジネスの戦略家 (以下、戦略家と略記) は、 四六時中寝る間も惜しんで儲ける仕掛けのことばかり考えています。 素人考えのビジネスモデルが通用すると思うのは、 C言語を覚えたばかりの素人技術者が、 カーネル・デバッグに挑もうとするくらい無謀なことでしょう。

当たり前のことですが餅は餅屋であり、 技術のことは技術者に任せるべきですし、 儲ける仕掛けのことは戦略家に任せるべきです。 優秀な技術者は、優秀であればあるほど、 優秀な戦略家と組むべきなのです。 ところが世の中の大半の会社はそうなっていません。

超優秀なハッカーは互いに認め合う技術者同士ばかりで集まり、 ビジネスモデルの重要性を軽視してしまいます。 ビジネスモデルなんて自分たちだけでも考え出せると思ってしまい、 社員のほとんどが技術者、なんて会社になってしまいます。 実地に売り歩く営業の必要性にはさすがに気付いて営業担当者を数人雇ったり、 あるいは社長が自ら売り歩いたりするようになるものの、 儲ける仕掛けの構築には無頓着で、 旧態依然としたビジネスモデルのままだったりします。 そのため事業を拡大しても余裕が生まれず、 ちょっとした外部環境の変化でたちまち立ち行かなくなる恐れがあります。

逆に、優れた儲ける仕掛けを生み出すことができる有能な戦略家は、 一日24時間、儲ける仕掛けを考え出すことばかりに夢中で、 その仕掛けを下支えする高度な技術のことは軽視してしまいます。 技術なんて下請けをいじめればなんとでもなると考えてしまい、 決して技術者をパートナーとは考えません。 技術者を、売るものを作ってくれる便利な人と考えてくれればまだマシなほうで、 下手するとコストばかりかかる必要悪くらいの勢いで、 原価削減の手法をあれこれ考え始めたりします。 しかし技術を軽視したツケは、いろいろな形で払うことになるでしょう。 事業を下支えする技術が脆弱であれば事業の継続性が危ぶまれますし、 技術面で他社との差別化が行なえずに他社の参入を許してしまうかも知れません。

これでは技術者と戦略家の利害はどんどん対立してしまいます。 この悪循環をくい止める唯一の方法は、 技術者が ──特に、優秀であればあるほど── ビジネスモデルの良し悪しを嗅ぎ分ける嗅覚を持つことです。 誰が優れた「儲ける仕掛け」を生み出すことができるのか、 技術者が判断できるようになれば、 人月ビジネスから抜け出す見込みのない会社を見限ることが できるようになるでしょう。

対称性を考慮すれば、 戦略家が技術の優劣を嗅ぎ分ける嗅覚を持つことによっても、 利害対立の悪循環をくい止めることが (理論上は) 可能ですが、 高度に専門化・細分化してしまった技術を、 技術者ではない戦略家に (優劣を判断できるほどに) 理解してもらうことは現実的とは思えません。 戦略家と技術者が協力しあうには、 まず技術者の側が相手を理解する必要があるのです。

そうすれば、 より優れた戦略家のもとに優秀な技術者が集まるようになり、 戦略家と技術者の利害が一致する方向へ淘汰圧が働きます。 すなわち、 戦略家が優秀な技術者と組むことにより、 技術者には (従来想像していた以上に) 優劣の差があって、 どのレベルの技術者と組むかが事業の成否を大きく左右する、 ということが明らかになってくるはずです。

優秀な技術者が事業にどれだけ貢献し得るか実感できれば、 優秀な技術者に対して、その能力に見合った待遇 ──報酬はもちろんですが、 仕事量を減らして OSS コミュニティへの貢献を推奨するなど── を提供すれば優秀な技術者が集めやすくなる、 ということも実感できるようになることでしょう。

技術者の側からすると信じられないことだとは思いますが、 ピンもキリもそんなに大した差ではない (せいぜい 5~6倍) と、 技術者でない人の大半は感じています。 縁遠い技術になればなるほどこの傾向は強まるようで、 例えばカーネル技術者の中でもメンテナとデバイス・ドライバの開発者とでは、 (技術者の目から見れば) だいぶレベルの差がありますが、 (技術者以外の人で) その能力差を実感できる人は皆無でしょう。

技術者の待遇向上の鍵は、 技術者がビジネスモデルの良し悪しにもっと敏感になること、 すなわち会社における技術職以外の職種の役割についてもっと理解し、 技術職以外の人達についても、 その能力の優劣を見分けられるようになることにこそ、 あるのだと思います。

Filed under: 元CTO の日記,技術と経営 — hiroaki_sengoku @ 07:46

6 Comments

  1. 当人が満足しているのであれば、それが一番良いんじゃないかな、、と思います。
    「彼は出来るから」という理由で、本人が望まない仕事をさせるのは良くないパターンでは無いでしょうか。やりたい事が出来ているからこそ、他人と比較して何倍ものパフォーマンスが発揮出来ている、という事があります。特に技術者は。
    また、スキルについても、特にOSSならば「伸ばしたい技術」に向かって「個人的」に専念するのが一番伸びる方法だと思います。
    昔の汎用機時代であれば、スキルを伸ばしたいなら嫌でも仕事で伸ばすしか無かったと思いますが・・・
    最後の段落は全く同感です。ただ、ビジネスモデルが悪いからといって、自分に向いた職をすてて(モデルの優れた会社の)別の職に行く事は、かなりの賭けではないかと思います。
    特に技術者的な人にとっては(笑)。

    Comment by とおりすがり — 2008年7月22日 @ 20:11

  2. [Style] 技術センスが高い本物のビジネス戦略家になれるか?

    KLab株式会社のCTO、仙石浩明氏の下記エントリに思ったこと。 超優秀なハッカーは互いに認め合う技術者同士ばかりで集まり、ビジネスモデルの重要性を軽視してしまいます。ビジネスモデルなんて自分たちだけでも考え出せると思ってしまい、社員のほとんどが技術者、なんて会

    Comment by 起業ポルノ — 2008年7月23日 @ 03:02

  3. 10倍できて志あるエンジニアがとるべき戦略

    仙石さんが志が高く優秀だけど,あんまり金銭的に恵まれない技術者のことを憂慮されている. 「技術力が高い人こそ、ビジネスモデルの良し悪しにもっと敏感になるべき」 http://sengoku.blog.klab.org/archives/64945422.html 志のある仕事(OSSの普及やボランティア活動など)

    Comment by 最速配信研究会 — 2008年7月23日 @ 07:22

  4. 内外に向けての発信ですね
    大変意義のあるエントリかと思います
    ご成功を祈念申し上げております

    Comment by なるほど — 2008年7月25日 @ 00:12

  5. 先日のパネルディスカッションでご一緒させていただきました。OSSビジネスにおいては個人的にはサポートを極めて効率的に行うことが効率的な収益をあげる方法かと思いました。ただ絶対的な売上・利益の大きさという意味でのビジネス要求レベルをクリアするにはもうひとひねりなにかが必要だろうなぁと常々感じています。

    Comment by mabots — 2008年12月2日 @ 19:04

  6. つまり、この事に気がついている仙石さんと私とこれを読んだ人には効率的に収益を上げる(簡単に言うと大儲けする)チャンスがあるということですよね。実際にはすでに気がついている人が沢山居てずいぶん前から儲けています。そうしたくない人はそうしなければよろしい。そういう会社/人もありますし、そういうところに足を引っ張られることでもないので、それぞれ自由な意思に基づいて商売すればよいのではないでしょうか。

    Comment by Nikoriks — 2010年12月10日 @ 13:31

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.