経営者たるもの、先ず第一に経営戦略の要諦をまとめなければなりません。
　戦略的視点がない経営は場当たり的になり、それでは到底、事業の長期的な発展を望むことはできません。

　それでも新米の経営者は、戦略をたてることが苦手です。
　多くの場合、戦略と計画の区別もついていません。

　今日は軽視されがちな経営戦略の立案法についてプログラマーの視点から見ていきましょう。
　まずはビジネスモデルの構築法から見ていきましょう。

　まず、経営をしようというときに最も重要なのは、ビジネスモデルです。ビジネスモデルは、変化の早いITの世界では3〜5年で一周すると言われています。IT企業の経営者ならば、常にビジネスモデルを変化させつつ、次の3年、次の5年に備えなくてはなりません。

　ビジネスモデルとは、平たく言えば「どのように人様のお役に立ち、どのように価値を認めていただくか」ということ。短く言えば価値創造です。

　なんらかの価値ある商品なりサービスなりを考案し、対価をいただくところまでの一連の構造が、ビジネスモデルというわけです。

　このビジネスモデルの構築は、プログラマーの仕事でいえば、「設計」行程にあたります。ビジネスモデルはアーキテクチャと言い換えてもかまいません。

　優れたアーキテクチャを考えだすのは、プログラマーとしての最終段階にあり、だから、プログラマーの最終形態はしばしば「アーキテクト」と呼ばれるのです。

　ビル・ゲイツも会長兼チーフ・ソフトウェア・アーキテクトとしてMicrosoftに関わりました。

　大なり小なりのアーキテクチャを考えだす訓練を、プログラマーはプロジェクトごとに経験しています。

　最初は誰でも不格好なアーキテクチャを考えてしまいがちです。
　しかし慣れてくるとだんだん優れた、効率的なアーキテクチャを考えだすことができるようになります。最初から完璧なアーキテクチャを作れる人間など居ません。最初は見よう見まねで始めることもありますが、多くの場合、初心者プログラマーはアーキテクチャをほとんど意識しないか、または極端に意識しすぎて独創的(に思える)奇をてらったアーキテクチャを夢想しがちです。しかし得てして、プロジェクトを成功させるのは、独創的な部分を意図的に抑えた、堅実なアーキテクチャだったりするのです。

　まったく同じことは、ビジネスモデルの構築にも当てはまります。
　
　起業の未経験者は、ビジネスモデルについて極端に独創的にするか、全く意識しないかのどちらかで事業をスタートしようとします。

　典型的なのは、新しいWebサービスをスタートしようとする起業家です。
　そういう人たちに「ビジネスモデルは?」と聞くと、「とりあえず広告収入で・・・」と答えます。しかし実際に広告収入で「どれだけの収益」が見込めるか、最初の段階で理解している起業家はほとんど居ません。

　実際には、「とりあえず広告収入で」会社が最低限成立するには、最低でも月に1000万PV程度は必要です。

　しかし月に1000万PVというのは、生半可なやり方では獲得できない膨大な数字です。にもかかわらず、誰もが安易に「はてながうまくいってるように見えるからとりあえず広告で・・・」と考えてしまうのです。

　こういう考え方でビジネスをスタートするとまずたいていの場合は失敗します。まあビジネスはたいていの場合失敗するのですが、この場合は立ち上がる前に失敗します。

　優れたアーキテクチャを設計できる人間になる、つまり優れたアーキテクトになるための唯一にして確実な方法は、過去のアーキテクチャを研究することです。これはとても当たり前のことなのに、ほとんどの人が疎かにしているポイントです。ビジネスモデルにも同じことが言えます。

　例えば、はてな、ドワンゴ(ニコニコ動画)、mixi、DeNA、GREE、Livedoor(旧オン・ザ・エッヂ)、楽天といった、今現在までに成功しているIT企業の過去のビジネスモデル(アーキテクチャ)を研究してみると、いわゆるネット広告(Google AdSenseなど)の収入に頼って成功した会社は実は一社もありません。

　はてなは創業当初、受託開発で乗り切っていましたし、ドワンゴもミドルウェア(DWANGO/IWANGOシステム)を売り込む下請け会社のひとつでした。mixiはFindJobという求人広告サイトで、これは求人広告というリクルートが持っていた先行するビジネスモデルを踏襲したものです。DeNAはビッダーズというオークションサイトで、GREEは当初Google AdSenseやAmazonモデルを採用していましたが、それでは売り上げが十分あがらず、KDDIの資本参加を経て、DeNAがスタートしたモバゲータウン(アフィリエイト広告)方式を踏襲したゲームサイトのビジネスモデルを踏襲して成長し、釣りゲームでソーシャルゲーム(これもFacebookでZyngaが成功していたビジネスモデル)の端緒をつけ、それにさらにインスパイアされたDeNAとmixiの三つ巴で成長してきました。LivedoorはWebページ制作会社でした。

　これら成功企業のビジネスモデルの根幹にある共通項に、お気づきになった方はいるでしょうか。

　実はどのビジネスモデルも、最初はすべて対面営業に頼っていたのです。
　唯一の例外と言えるのはGREEですが、これも社長の田中良和氏がグロービスキャピタルやKDDIにプレゼン(いわば対面営業)して出資を取り付けたところが成長のきっかけになっています。DeNAも、当時の携帯電話コンテンツ大手のインデックスと提携してスタートしたモバオクが初期の成長エンジンになっています。

　また、B2BとB2Cのビジネス構造の違いも見えてきます。B2Bとは、対面営業が基本の仕事です。要は先方の担当者か責任者、誰か一人を説得すれば仕事がもらえるというビジネスモデルです。

　B2C(一般消費者向けビジネス)は利益があがるまでかなり時間がかかり、しかも資本が必要です。当初からB2C(今で言えばO2O)を指向していたDeNAのビッダーズも黒字化するまで3年かかったと言います。

　ドワンゴがB2C事業に乗り出したのは1999年の年末で、それまではセガやSo-net、Microsoftの下請け業者でした。しかも、B2C事業はB2B事業の合間に、余った予算で行われました。私たちはドワンゴでB2C事業の立ち上げをやっている間にも、しばしばB2B事業の仕事を手伝っていました。

　mixiが黒字化するまで持ちこたえることができたのも、FindJobという手堅いB2B事業があればこそです。

　ところが起業を志望する学生の多くは、B2Bビジネスをとても嫌がります。
　社会に出た経験がないので、B2Bが得体の知れない、泥臭い仕事だと思っているフシがあります。

　でも結局、学生起業でもうまく行ったのはB2Bでスタートしていることが多いのです。

　起業3年の法則と私が呼んでいる性質があり、たいていの会社は3年は持ちます。

　起業1年目は、知り合いから仕事をもらうことができます。多くの場合、前の会社から自分のやっていた仕事を外部業者として引き継いだり、「起業した」という噂を聞きつけた知人がご祝儀も兼ねて仕事を投げてきたりしてきます。これでだいたい一年目は乗り切れます。20代で起業すると、それだけでちやほやしてもらえますし、みんなが期待をこめていろいろな話をもってきてくれます。

　起業2年目になると、第一の試練です。これは1年目にご祝儀として貰った仕事をきちんとこなせていれば、向こうがお得意様になってくれて継続的に仕事が貰えます。しかし同時に金回りが良くなってきて仕事も増えると、どうしても社員を雇わなければならず資金の変換効率が下がります。雇ったばかりの社員は基本的には会社のお荷物です。給料分働くことさえほとんど期待できませんが、雇わなければ仕事がまわらないので雇うしかありません。それでもこの段階でつぶれる会社はあまりないです。信用保証協会から保証付きで1000〜3000万円程度の運転資金を借りることができます。これでなんとか凌げます。

　起業3年目、これが試練の本番です。知り合いで仕事をくれそうなルートは漁り尽くし、悪いときは相手の会社がつぶれていたり、懇意にしてた部長が引退していたり、とにかく悪いことは全部起きます。仕事を頼んでいた外注先に逃げられたり、社員が横領まがいのことに手を染め始めるのもこの時期です。この時期の社長は舐められ易く、社員からは一ミリも尊敬されていません。給料が安いなどの悪口を公然と言われるようになります。社員の仕事は雑になり、取引先からは「社長のお前を信用したのに」となじられます。信用保証協会の保証付きで借りられるお金の範疇を飛び出していて、もうお金を調達する手段はどこにもありません。知人の社長に泣きついて仕事を無理矢理まわしてもらっても、うまくこなせず、相手を大激怒させて最後に残った人間としての信用さえ喪ってしまいます。最後は会社をつぶすか、大リストラをして自分一人になるか、タダ同然の値段でバイアウトするかです。この三年間の間で、得るものは一つもなく、残ったのは借金と恨みだけです。そのうえ、当初のビジネスモデルは時代遅れになり、新興企業との競争が始まります。新しい会社はとにかく価格を下げて勝負してきますから、既に社員を何人も抱えているこっちはジリ貧になっていきます。社員はうだつのあがらない社長と会社に愛想をつかし、次々と出て行って、人材が一回転します。人材が回転する会社には社員も忠誠を尽くさないので、どんどん人材が逃げていきます。まるで穴のあいたバケツで水を汲むかのごとくです。

　この3年の壁と、次に5年の壁、10年の壁があります。

　会社が5年以上成長を続けると、今度は間接費が多くかかるようになり、増収減益という事態が起きやすくなります。10年が経過すると当初のビジネスモデルは完全に通用しない世界になっていますから、この時点で全く新しいビジネスをスタートできてないと詰みです。膨れ上がった間接費と人件費で会社は死を目前にします。社員をリストラし、事業規模の縮小を余儀なくされるのです。

　こういう事例は、過去の企業の変遷を調べればいくらでも出てきます。

　プログラムを組むときに、既存のデザインパターンやフレームワークの仕組みを熟知していたほうがより良いアーキテクチャを組むことができるのと同様、ビジネスモデルを考える時、経営をするときに既存の企業がどのようにして成功したかだけでなく、どのようにして失敗したかということにも同じくらいかそれ以上に注意を払わなくてはなりません。

　畑村洋太郎さんの「失敗学」の本などはかなり参考になりますが、あれも実は通り一遍の内容しか書いていないので、実際の失敗の経験は、できれば実際に失敗した人に会いにいって失敗談を聞くのがベストです。

　「なぜ成功したのですか?」
　

　と、成功した人にいくら聞いてもまともな返答は得られません。
　プログラマーに限りませんが、エンジニアがより良いものを作ろうとするとき、それは必ず失敗作の分析から入ります。

　「風立ちぬ」では、黒川技師や堀越技師が、幾度となくバラバラになったボディを見て立ち尽くします。あれは単に絶望しているのではなく、失敗から欠陥をあぶり出し、より良い改良を加えるための思案をしているのです。失敗を学ぶことこそが本質的な成功を導く唯一の手がかりであり、成功例だけを見ていたら決して自分が成功することはできないというのが、エンジニアの基本的な姿勢です。

　私はときたま、映画「ソーシャルネットワーク」を見てザッカーバーグに憧れた学生の起業志望者などに、「どうやったら成功できるんですか?」と聞かれることがあるのですが、「まず、失敗すること」と言うと、とても落胆したような顔をされます。

　スティーブ・ジョブズに憧れる学生も同じです。
　彼らは基本的に「成功者の成功」にしか注意を払っておらず、Apple創業と同時期にパーソナルコンピュータを作って小さな成功のあとに失敗したアダム・オズボーンのことなど知りもしないでしょうし、ジョブズに追い出されたMacintoshの最初の開発者、ジェフ・ラスキンのことについても同様です。

　成功者や成功したプロジェクトの表面に憧れ、夢想すると気分はいいでしょうが、それでは確実に成功できるビジネスモデルを作ることはできません。

　それではプログラマー経営では、ビジネスモデル構築をどのように行うのか、詳しい説明はここでは難しいので、概要だけ説明しましょう。

　以下のステップで行います。

1. 既存のデザインパターンの分析
2. 外部環境の分析
3. 既存モデルの分析と改善
4. ジャンプ

　まず、「既存のデザインパターンの分析」は、過去の企業のプロジェクトや、企業の成長曲線を分析します。失敗したプロジェクトと成功したプロジェクト、できれば同数やるのがいいのですが、実際には失敗したプロジェクトは資料が殆ど残っていないので分析するのは難しいです。

　そこで私は、過去30年分のコンピュータ雑誌を蒐集しています。
　そこでは結果として失敗したプロジェクトの途中経過も紹介されているからです。

　たとえばパーソナルコンピュータ史でいえば、MSX、NeXT、Newton、BeOS、MorphyOne、WindowsVista,Windows8、MicrosoftBob、MagicCap、Linux Zaurus、X68000、SMC-777、Nifty-Serve、BTRON、BASIC、GUIDE、JustWindowなどです。

　途中まで成功していても、最終的には失敗した、というプロジェクトもいくつかあります。それを分析します。なぜそうなってしまったのか、どうすればよかったのか、それともどうしようもならなかったのか、ということです。

　ゲームで言えば、将棋ソフトで無制限の「待った」をかけてとにかく勝つ方法を探します。もちろんこれは妄想の上なので、ここで勝ったとしても本当に勝てたかどうかはわかりませんが、過去の事例をもとに自分のなかでゲーム化し、仮想的にプロジェクトを成功させるイメージトレーニングを行うのです。

　例えば、解りやすい例でいえば「ソニーはなぜiPodを作れなかったのか」でもいいです。コンピュータ産業に限る必要はありません。どんな産業でもいいので研究するべきです。

　MSXの時代を知る人なら、「MSXはなぜ衰退したのか」でもいいです。どうすればMSXは21世紀の覇者になれたのか、夢想してみるのも楽しいものです。

　例えば私はMSXが衰退した理由の一つは、BASICだから、という仮説を持ちました。90年代に入り構造化プログラミングが発達したにも関わらず、BASICの利用を前提とした機械には無理がありました。MSX-DOSもありましたが、時代遅れでした。16ビット化にも乗り遅れ、MSX全体が時代に取り残されつつあり、しかも取り残されることがむしろ肯定された面もあったと思います。

　続く「外部環境の分析」では、現在の状況がどのような状況で、会社をとりまく状況から隙間を探していきます。たとえば過去にあったものが現代では喪われていたりします。喪われてはいても年長者の記憶の片隅には残っていたりするのです。それも含めて環境と言えます。

　過去の時点からどのような変化があって何が喪われたのか、何が何に置き換わったのか、ということを樹形図にして分析します。新技術は突然出てくるということはまずありません。過去のある時点で存在した思わぬものが、突然先祖帰りのように復活するタイミングがあり、それが若い人には全く新しいもののように見えるチャンスがあるのです。J-POPのヒットチャートのイントロも、実は昔の洋楽にどことなく似ていたりします。AKB48もおニャン子クラブの現代風リバイバルだと言えばその通りですし、その意味では実はモーニング娘。も同じです。

　人々の根底には普遍的な欲求があり、この欲求を上手くとらえて現代風にアレンジすると、ヒットする可能性があります。これは同じ分野、同じジャンルに限りません。

　たとえばmixiは90年代のNifty-Serveをインターネット風にアレンジして蘇らせたもの、という解釈ができます。

　例えばかつてはPCを買うという行為は、そのままBASICでプログラムをするのだ、ということを指していました。ところがBASICでプログラムするのは取っ付きは簡単でも、自分の思い通りにプログラムを書くのがまだまだ難しく、簡単なゲームさえ作るのが大変です。いつしか人はプログラムを書くことを特別な行為なのだと考えるようになりました。

　しかし、重要なのは一度は「プログラムを書こう」と思ってPCを買った人たちが相当数存在するという事実です。「プログラムを書いてみよう」と思わせる普遍的な魅力が、プログラミングにはあるのではないかと分析することができます。プログラムに限らず、手芸やお絵描き、ギターなど、人は根底に「なにかを作りたい。なにかを表現したい」という普遍的な欲求を内面に持っているとも分析できます。

　次に「既存モデルの分析と改善」です。
　たとえばインターネット時代にもNifty-Serveは継続していたのですが、インターネットとの親和性も必ずしも高くありませんでした。

　Nifty-Serveは日本で最も成功していたサービスだったからこそ、より大きな流れであるインターネット化に際して、保守的になってしまったのだと思います。Nifty-Serveのビジネスモデルがインターネットによって大きな揺さぶりを掛けられ、ピンチになったとき、脅威の存在を無視するというのは一番やってはならない愚策ですが、過去の企業の失敗例を見るとたいていは脅威を無視することよって大失敗をしています。

　私がもし、当時のNifty-Serveの経営者だったとするなら、ここは先んじてインターネットサービスプロバイダ(ISP)事業を日本で最初に立ち上げるべきだったと思います。ニフティがISP事業である@Niftyをスタートしたのは1999年。日本初の個人向けISPであるTWICSがスタートした1993年ですからこれではいくらなんでも遅すぎます。しかも経営に行き詰まって99年に富士通の完全子会社になった後に、富士通のinfowebがそのまま@Niftyになったことになります。infowebのスタートは1994年ですからぜんぜん遅れてないことになりますが、Niftyが会社としていち早くインターネットに取り組んでいれば、今でもFacebookより存在感を維持できていた可能性はあります。ネットコミュニティの力を誰よりも意識していたはずのNifty-Serveは現代においては蚊帳の外です。

　目の前の脅威は無視するよりはむしろ脅威を味方につけることで次世代へ生き残っていくことができる場合があります。

　私は「プログラミングをしたいという欲求に答えようとして答えられなかったMSX」の歴史をふまえ、その問題点がマシンの性能と、BASICの古くささと記述性の低さにあると考えました。

　そこでBASICを現代風に蘇らせることで「プログラミングをしたい」という欲求に答える方法を探してみることにしました。かつてMSXでプログラミングをしていた人たちにも、この発想そのものは受け入れられるはずだと思いました。

　最後に「ジャンプ」です。
　「ジャンプ」とは、どのような優れたアーキテクチャにもある、「大胆な決断」です。

　例えば、初代PlayStationでは、民生用のゲーム機に3D描画チップを搭載するという大ジャンプを行っています。当時、3D描画チップは、一台何千万円もするグラフィックスワークステーションにしか搭載されていませんでしたから、そのコストたるや相当なものです。CPUでさえも、一台300万円するワークステーションでしか使われていないものでした。それを3万円台で売るというのです。内部構造もまさに「割り切り」を地でいくもので、その美しさにほれぼれしたものです。

　たいていのアーキテクチャの「ジャンプ」では、きわめて大胆な割り切りがされます。いわば、割り切りの方法そのものがジャンプの本質なのです。その割り切りは、見方を変えれば自殺行為的ですらあります。しかしジャンプできるかできないかが、優れたアーキテクチャと凡庸なアーキテクチャを分ける決定的な差になっていると言えます。

　たとえば既存モデルの分析と細かな改善、だけでも堅実なビジネスモデルを作り出すことはできます。いくつか似たような現状認識から製品が生まれたのも目の当たりにしたことがあります。しかし、私は現代風に大胆な「ジャンプ」を行うことにしました。

　それは「目先のお金を求めない」という選択です。

　オープンソースソフトウェアが全盛のときに、目先の金銭を求めず、広く普及させ、その引き換えに長期的な利益を得ることを選択しました。

　そうして生まれたのが「enchant.js」です。
　enchant.js本体は無料のソフトウェアですが、それに関連したビジネスによる売り上げは、年数億円に達します。しかもまだ増え続けています。

　enchant.jsというビジネスモデル自体は一応の成功を収めたと考えていいと思っています。まだ発展途上のビジネスですが、さらに大きく飛躍する可能性を秘めていると確信しています。

　オープンソースにしたことにより、バグの発見や性能の改善を広く受け付けられるようになりました。

　ユーザーさんが制作したプラグインも出現したり、企業で製品開発にenchant.jsを使っていただけるようになっています。企業向けにenchant.jsの有償サポートを行い、そこで利益を出せるようになっています。

　海外の大学の授業などでは積極的に取り入れられ始めました。このために教科書が売れると、我々のところに継続的に収入が入ってくることになっています。

　これは一つの例ですが、私がどのようなプログラマー的な発想を活かしてビジネスモデルを考えているか、そのプロセスをお解りいただけたのではないかと思います。