「ソフトウェア企業の競争戦略」読書感想文6（最終回）

ソフトウェア「ビジネス」で起業する人向けの話。そのアンチパターンを紹介しているのが「第6章スタートアップ10社のケーススタディ」なのだが、さすが米国だけあって、まさに死屍累々。気持ちいいぐらいの栄枯盛衰。

その10社は、それぞれオリジナルの優れた製品やサービスを有していた。ITバブル華やかなりし米国市場に参入し、人とカネを集め、「モノを作り」、売れずに落ちぶれていった（ただ1社を除く）。筆者は経営顧問や取締役会などの立場からアドバイザリーを行った。どこぞの「動かないコンピュータ」のように、記者の立場から安穏とインタビューした報告ではなく、まさに当事者の一員としてかかわっていた分、生々しい。

報告の一つ一つは、これから起業しようとする人にとっては「めぐすり草」となろう[注1]。最も重要なのが「死のくちづけ」。ベンチャーキャピタルからの資金調達に成功したことを指すのだが、これはなぜ「死」なのか? 答は明らかなのだが、状況により様々な姿をとる。

いったん資金を調達すると、約束したとおりにカネを使わなければならなくなる。ビジネスを構築していく過程で、資金の使い方に注意を払っていれば、もっとよいポジションにいることができたかもしれない

「カネを調達したら、約束どおり使わなければならない」←目論見書には小難しいことがいっぱいかいてあるが、本音はこれやろ。技術や市場の充分な下調べがないまま、経営プロのサポートがないまま起業へと踏み込むと、この「くちづけ」を受けることになる。

「くちづけ」は、製品とサービスのどちらに重心がかかっているかによって、異なる化け方をする。製品を売ることを主眼とする場合、調達した資金は、新規開発費に費やされる。何のためにVCがカネをよこすのかというと、リターンを望んでいるからだ。起業というリスクを一度負いながら新たに開発を始めてしまうということは、種銭を再ベットしてしまうことと一緒。まずいま起業したネタを売ることを考えるべきだろう。売るべきソフトウェアがあるのなら、その市場の顧客全てに売り続ける。一度作って、何度も売ることが極意。Javaの極意が"Write Once Run Anywhere" なのと同様だ。一方サービスで儲けることを目的とした起業だと、調達したカネは、豪奢なオフィスやマネージャ層の新規雇用や新たな販売拠点へと化ける。外部からの資金調達を得る理由は、内部でまかなうよりも、よりスピーディーに有望顧客や市場へ近づくためなのだ。いわばこれらは作られた富、身の丈にあっていないカネなのだろう。

実は、起業できるかと企んでいたネタがある（というか、あった）。ターゲットは「ソフトウェア開発企業」そのもので、売りものは「ソフトウェア開発ライフサイクル全般のプロセス管理スキル」を有した人。売り方はサービスプロセスの均質化と人材開発の注力による「固定価格／固定時間」、即ち時間・コストの遅れはなし（出た場合は追加コストを一切請求しない）。まとめると「ソフトウェア開発プロジェクトマネジメントを人員込みで売る」企業なり。本書でそっくり同じコンセプトの会社の顛末を読んで、あきらめたorz すでに前例があったのね…

* * * * * * * * * *

結論みたいなもの。

本書で何度も強調されてきた「製品を売って、サービスでもうける」という、ソフトウェア企業の基本戦略は、企業に限らず、社畜である私自身にもあてはまることに気づいた。企業と個人の関係で置き換えると、「製品」は「技術」であり「サービス」は「貢献」になるだろう。つまり、私は技術を会社に売って、会社への貢献でもうけることでキャリアを積んでいるのだと考える。

私が新人だったころは「COBOLさえ極めれば、一生喰っていける」あるいは「Cがちゃんとできれば、一生喰うには困らない」と言われた。しかし、かつてバリバリのコボラーや、Cのプログラマは今ではプログラミングをしていない。いや、COBOLやCのプログラミング需要が無くなったとは言っていない、メンテナンスやレガシー更改のため、まだ需要は沢山ある。しかし、COBOLやCを読み書きできるもっと安い給料の若手も沢山いることも事実。さらに、JavaやC++といった、もっと単価の安い言語（失礼！）が取って代わっていることも事実。

そんなわけで、かつてバリバリのコボラーやC使いは、製品の製造過程で身に付けたマネジメントスキルやノウハウ、あるいは特定業界の業務知識やパイプにより、管理職や営業職や指導者へクラスチェンジしている。COBOLなりCといった「技術」にしがみついているわけにはいかない。なぜなら、若手プログラマやJava技術と取替えができるから。会社としては同程度のことを安くあげることができるのなら、むろんそっちに飛びつくだろう[注2]。その代わり、取替えがききにくい「貢献」により employability を向上させることができる。

会社が欲しいのは「そのソリューションを適用して製品化できる人」であって、募集要項「要Javaスキル」はその一例に過ぎない。Javaプログラマとして入社した新人クンは、「Javaが使える人」というパッケージ「製品」としてその「技術」を買われたのであり、恒常的なサービスを提供しつづけなければ、いずれもっと安い「若手Javaプログラマ」という製品に取って代わられることになるだろう[注3]。極端に言うと、究極のプログラマは、一行もコードを書くことなく、製品を生み出すことができる人だろう。MDAが取りざたされているが、ありゃモデルのパターンや部品の数だけコードを書かなきゃいけないので、むしろ業務にロックインされたプログラミングを強いられるオチになろうかと。

COBOL→C→Java と転戦してきたが、次の技術を追いかけるのはちょっと休憩にしてみよう。そして、これまでの経験を基にし、会社の利益に対して貢献できる私なりの方法を形にしてみようと思う。会社であれこの業界であれ、私なりの方法にロックインされるようなサービスを提供できるか、（そのアイディアをカネに換える方法も含めて）考えてみよう。P.F.ドラッカー「プロフェッショナルの条件」で言っていた一節を思い出す。えらい回り道だったが、この「貢献を重視せよ」がようやく分かった気がする。

貢献を重視せよ。貢献に焦点を合わせることによって、専門分野や限定された技能に対してではなく、組織全体の成果に注意を向けるようになる。成果が存在する唯一の場所である外の世界に注意を向けるようになる。自らの専門や部下と組織全体や組織の目的や関係について、徹底的に考えざるを得なくなる。

（;ﾟ０ﾟ）ﾊｯ！ 本の題名が違う…が、まぁ気にしないで下さいませ。だらだらと書きなぐったこの連載をここまで読んでいただき、ありがとうございます。

（おしまい）

--
[注1] 「めぐすり草」を知らないよい子に説明しよう！ めぐすり草とは、「風来のシレン」や「トルネコの不思議のダンジョン」シリーズにでてくる、「隠れていたワナが見えるようになる薬草」のことだ。転ばぬ先のめぐすり草だねっ。

[注2] もちろん一定の年齢以上になっても「プログラマ」として雇われ続けることができる人がいる。しかし彼はその世界では既にネ申のごとき存在となっている。神はそうそういない。

[注3] 話を分かりやすくするために形式知と暗黙知という要素を除いて書いているが、「開発のお作法、暗黙知があるじゃねーか！」というツッコミが入れられる人は、もう「サービス」で会社に貢献しているといえる。