Life is beautiful

　最近、私のまわりにもAmazonのレンタル・バーチャル・サーバーであるec2を使用している人、もしくは使用を真剣に検討している人が増えて来た。「自分でサーバーを用意するのとどっちが得か？」という話は、ビジネスにもよるのでさまざまだが、ごくシンプルな「事務所サーバー」（もしくは「マンションサーバー」）を比較対象のモデルとして簡単に損得勘定を計算してみた。

　もっとも安価な Small Instance (1.7 GB of memory, 1 EC2 Compute Unit, 160 GB of instance storage, $0.10/hour）だと、一日２４時間使い続ければ月に７２０時間、つまり月に７２ドル必要となる。

　同じようなマシンを事務所（もしくはマンション）に置く場合、Dellのエントリーレベルのサーバー（Dual core Pentium, 1GB memory, 160GB HD）を買ったとすれば、現在の価格は$999（定価は$1695だが今はキャンペーン中）。

　問題は、同じようなウェブ・サービスを運営する場合どちらが得か、である。

　多くの人が直感的に「999/72 は約14。たった14ヶ月でもとが取れるんだから、買った方が得じゃん」と思うだろう（こういう考え方を「ペイバック期間に基づいた損得計算」と呼ぶ）。

　「サーバーは２年半で買い替えると想定して３０ヶ月でいくらかかるか計算して比べる」という方法もあるのでそれをやってみるとこうなる。

Amazon ec2: $2160 ($72 x 30ヶ月）
自前サーバー: $999

　ec2の方が倍以上かかる。しかし、この計算方法にはいくつか穴がある。

　まず一番大きな問題は、「現在のお金」と「将来のお金」の価値を同じとみなしていまっていること。特にまだ売上げのないベンチャー企業の場合、とにかく今出て行くお金を少なくすることがビジネスを成功させる秘訣。その意味では、「現在のお金」の方を「将来のお金」よりもずっと価値のあるものと見なして計算する必要がある。

　その場合に使うのは、「DCF、discount cash flow」と呼ばれる方法で、将来のお金をある特定の金利で割り引いて計算するのだ。その金利の決め方には色々とあるが、市場の金利にビジネスのリスク分を上乗せしたものを使う。米国の場合、安定して収益のある大企業だと９〜１５％、リスクの高いベンチャー企業の場合２５％〜６０％と幅広い（なぜリスクが高い企業の方が金利が高くなるのかに関しては別途書く予定だが、理屈は「ジャンクボンドが金利が高い」のと全く同じ）。

　日本の場合、公定歩合は米国よりも数パーセント低いので、DCFに使う金利もそれに応じて少し下げて考えても良いが、ここえはベンチャー企業の場合の最低線である２５％からさらに５％を引いた２０％を使ってみよう（ExcelにはNVPという便利な関数があるので、それを使うと簡単に計算できる）。 

Amazon ec2: $1688 （=NPV(0.20/12, 72...72)）
自前サーバー: $999

　まだ自前サーバーの方が安い。しかしこれでもまだ不十分だ。サーバーをオフィスやマンションに置く場合、電気代や通信費は通常のオフィス費用に含まれてしまうので、直接的なコストとしては見えて来ないが、実際にはサーバーの消費する電気代、余計にかかるクーラーの費用、ネットワークのアップグレードにともなうコストなどが必要となる。これはとても計算が難しいのだが、一般的なマンションの電気＋通信費を月２万円と見積もってその１５％（３千円＝$30）程度がサーバーのために必要になると想定して計算しなおすとこうなる。 

Amazon ec2: $1688 （=NPV(0.20/12, 72...72)）
自前サーバー: $1703（$999 + NPV(0.20/12, 30, 30...30)）

　自前サーバーのコストがec2を超えてしまった。もちろん、金利をどのくらいに設定するか、ハードウェアをどのくらいの頻度でアップデートするか、オフィスサーバーに必要とされる電気・通信費用をどう計算するか、などによって結果は大きくちがってくるが、最初の「１４ヶ月でもとがとれるんだから買った方が得」という直感は必ずしも正しくないことは分かってもらえると思う。

　自前サーバーの場合、それに加えて、故障した部品の交換コスト、それにともなう人件費（＝ソフトウェアを開発する手を止めてハードの故障に対応する時間）が「隠れたコスト」として内在する上に、停電やハードディスクの故障でサービスが止まってしまう可能性を考えれば色々な予防措置（無停電電源、ミラーサーバーなど）をほどこさねばならず、そのコストもバカにならない。それに加えて、自前サーバーの場合「万が一サービスが大成功した場合」への迅速な対応がとても難しいので（資金の調達、ハードウェアの購入、データセンターへの引っ越し、...）、せっかく成功しかかったのに「あそこのサービスはレスポンスが悪くて使えない」ということになりかねない。

　こうやって見てみると、小規模なサービスをまず立ち上げようという場合には、自前サーバーよりもec2の方がコスト的にもビジネスリスク的にも正しい選択ではないか、というのが私なりの結論である。もちろん、ビジネスは常にケース・バイ・ケースなので、必ずしもどっちが正しい、ということは言えないが、少なくともこのレベルまで踏み込んだ計算をしてからではないと、経営判断はできない、ということは覚えておくと良いと思う。

【追記】

　ちなみに、ここでは計算すらしなかったが、初期費用が必要な専用レンタルサーバーというのもあるので、それらも同じ方法で計算できる。もちろん、その手のサービスを使う場合に一番注目しなければならないのは初期費用。自前サーバーと比べた時のレンタルの利点は、出費を出来るだけ先送りしてスケーラブルなビジネスを手っ取り早く立ち上げることにある。初期費用の高いレンタルサーバーを借りるほど馬鹿げた話はない。Sakura internetとかが専用レンタルサーバーの価格見直しにかかっているのは、やはりAmazon ec2の影響が大きいのか、と。

　私の書物「おもてなしの経営学」についてのさまざまなフィードバックはポジティブなものもネガティブなものもとても良い勉強になるので全部読ませていただいているつもりだが、以下の二つに関しては、少し誤解があるようなので一言書いておこうと思う。

• 何故SONYの経営はiPodを創れなかったか - 雑種路線でいこう

• 「おもてなしの経営学」：ソニーのエンジニアの名誉のために一言 ([の] のまのしわざ)

　私の本のごく一部、それも梅田氏とのの対談における「ギークとスーツ」の話題の前フリとして「ギークとスーツのすれちがい」「技術と経営の両方が分かる人が少ない」ことの例として語った言葉だけを取り上げて、あたかも私が「ソニーにiPod+iTunes+iTunes storeが作れなかったのはエンジニアが悪い」と決めつけているかのように誤解をされてしまっているのが私としてはとても残念。

　せっかく私の本を読んでいただいたのにそんな誤解をされるようではまだまだ本としてのおもてなしがなってない、ということか。

　とは言っても、紙に印刷された本はブログのように簡単に修正することもできないので、ソニーのエンジニアの人たちにはぜひとももう一度読んでいただきたい一節を本書（４０ページ）から抜き出して、下に貼付けておく。　

コンシューマー・エレクトロニクス業界の将来像

　私は少し前に、アップルをもっとも脅威に感じているのはマイクロソフトではなくソニーだとブログに書いた。

なぜアップルにできたことがソニーにはできなかったのか（２００７年12月29日）

　アップルがｉＰｏｄ＋ｉＴｕｎｅｓ＋ｉＴｕｎｅｓＳｔｏｒｅというハードウェア、ソフトウェア、サービスを巧みに組み合わせてインターネット時代にふさわしいコンシューマー・エレクトロニクス・ビジネスモデルを見せてくれたことに関しては、ここでもさんざん書いて来たが、反面教師として注目すべきなのは、「ソニーになぜそれができなかったのか？」ということ。

　メディア産業を有し、ウォークマンというブランドを持ち、インターネットビジネスに抜群のセンスを持つ出井伸之氏を社長に据えたソニーはアップルよりはるかにいい立場にいたはずだが、なぜこんなことになってしまったのだろうか。

　メディア産業を持つことが逆に足かせになった／ソフトウェア開発力の差／たまたまラッキーだった／天才スティーブ・ジョブズがいなかった／イノベーションのジレンマ……などなど、それぞれの側面から考察を加えることは可能だが、あの時代のソニーに特有の問題としていちばん注目すべきなのは、出井陣営と久夛良木陣営の対立に象徴される「スーツ族とギーク族の軋轢(あつれき)」ではないかと私は考えている。

　結局のところは、出井氏を中心とするスーツ族（ソニー内部では「文官」と呼ばれていたそうである）が久夛良木氏を代表とするギーク族（もしくは「技官」）の心をつかむことができず、せっかく出井氏が持っていたビジョンを実行することができなかった、というのが私なりの解釈である。

　そういう見方をすると、アップルにとってスティーブ・ジョブズの存在がとても重要だったことが逆によく理解できる。『スティーブ・ジョブズ――偶像復活』（東洋経済新報社）にも書かれているとおり、スティーブ・ジョブズはエンジニアではなくマーケティングの天才。その意味ではギーク側の人ではなくスーツ側の人だが、普通のスーツ側の人と大きく異なるのはギークの心をつかむのが天才的にうまいこと。そんなカリスマ性を持つリーダーがはっきりと方向性を示したからこそ、あれだけのことをこれほどの短期間に成し遂げることができたのである。

　テクノロジーの会社が伸びるときというのは、ギーク族の心をつかむのが上手なスーツがリーダーシップをとったとき（ここ数年のアップル）、抜群のビジネスセンスを持ったギークがリーダーシップをとったとき（１９９０年代のマイクロソフト）、ギークとスーツが絶妙のコンビを組めたとき（昔のソニー）の、いずれかが成り立ったときだけなのかもしれないと思う今日この頃である。

　ではなぜ、当時のソニーのエンジニアたちは出井氏の掲げたビジョンをサポートすることができなかったのだろうか。私はここにこそ、日本のコンシューマー・エレクトロニクス業界の将来を占う鍵が隠されていると思う。ソニーにしろパナソニックにしろ、もともとはハードウェア・エンジニアの集まりである。デバイスがデジタル化し、ソフトウェアの重要性が増したとは言え、彼らのＤＮＡにはアナログ時代からの「設計技術・実装技術・製造技術で勝負」というエンジニア魂が脈々と流れている。そんな彼らにとっては、インターネットを利用したサービス・ビジネス・モデルなどは「スーツ族のたわごと」にしか見えなかったのだろう。

　一方、アップルは「CPU、メモリなどのハードウェア部品は外部から調達。実装・製造はそれが得意な台湾、または中国の会社にアウトソース」というはっきりとした割り切りとともに、ソフトウェア＋サービスで徹底的な「おもてなし」を提供することにより差別化をはかってここまでの成功を収めた。iPod nanoの発売に際して、韓国のサムスン電子から大量のフラッシュメモリを破格で調達することで、ソニーよりもはるかに安い値段設定をしたことは記憶に新しいし、iPodやMacBookの製造がQuanta ComputerやAsustek Computerといった台湾のＯＤＭにより製造されていることもよく知られている。この勝ち方は、ソニー内部のエンジニアたちにとっては、今までの勝ち方そのものを否定する自己否定にもつながる戦略転換であり、自ら進んでその方向に進むことは決してできなかったのである。　

　この方向性がさらに進むと、ソフトウェアやインターネットに弱い企業がブランド力を保つことはどんどん難しくなるし、時代の変化に俊敏に対応しにくい、部品から最終製品まで何でも作るという垂直統合型総合家電ビジネスを維持することも厳しくなる。　最終的には業界は、アップルのようにソフトウェア＋サービス＋デザイン＋おもてなし＋ブランド力で徹底的な差別化をはかりつつ部品と製造は外部に頼る企業と、液晶の製造技術で勝負しているシャープのように特定の部品の実装・製造技術および製造設備への積極的な投資により他社に追従できないまでの品質とコストで勝負をする企業に、二極化していくのではないかと思う。

　私がここで伝えようとしていることは、エンジニアが悪い・経営者が悪い、などという小さな話ではなく、企業のDNAというか存在意義のようなものが問われている、という点である。経営陣は会社として「どこで勝負するのか」をはっきりとしたビジョンで示さなければならないし、エンジニアはそのビジョンに真剣に耳を傾けるべきである。

　「こういう問題は経営者が考えるべき問題で、エンジニアである俺たちには関係ない」という発想は大きな間違い。経営者が語るビジョンに同意出来ないときはちゃんと自分の意見を表明すべきだし、それを聞いてもらえなかったら別の会社に移るべきだ。エンジニアが経営者のメッセージを「机上の空論」と感じるようになったら終わりだ。

　その意味では「テレビを制するものは家電を制す」というパナソニックのビジョン、「HD DVDからは撤退するが半導体で本気で勝負する」と宣言した東芝のビジョンなどは高く評価できる。もちろん、任天堂の「ゲームを誰でも楽しめるものにしたい」というビジョン、アップルの徹底的なまでの「おもてなしへのこだわり」も尊敬すべきビジョンである。

　ポスト出井であったはずの久夛良木さんの「Cellチップを全部の家電に」というビジョンが頓挫してしまった今、求められているのは「ソニーはどこで勝負する企業なのか」をはっきりとさせるビジョンであり、そのビジョンを伝える言葉である。私が見逃しているだけかも知れないが、少なくとも私には届いて来ない。

　去年の秋から始めたMBAも４月第三期目に突入。ここのところiPhoneのSDKに夢中なのでなかなか勉強する気になれないが、何も予習をせずに行くと痛いめに会うのでしぶしぶ勉強開始。

　科目の一つは既にある程度知識がある統計学なので思いっきり手を抜いて臨む予定だが、宿題だけはやって行かないと話にならないので、順番に消化開始。その宿題の一つが、

自分の仕事と関連のある統計データを三つ集めて来てヒストグラムを書いた上で分析せよ。

というもの。手短かに手に入る統計データとして思いついたのは、Google Analyticsなどで集まるこのブログに関するデータ。漠然とベージビューの平均値ぐらいは認識していたが、日々のベージビューがどのくらいのばらつきを持っているかなどは調べたことがなかったのでちょうど良い機会だ。

　最初に集めたのは、Google Analyticsから分かる日々のベージビューの変化。去年の４月の頭から今年の３月末までのページビューをExcelに取り込んだ上で、StadPadという統計処理用のプラグインを使ってヒストグラムを作るとこんな感じになる。

　興味深いのは、ページビューの平均値が９０００であるにも関わらず、ピークは７５００付近にあること。このブログを訪れる人が常連さんとサーチエンジンから来る一見さんだけで成り立っている７５００付近を中心にしたきれいなベルカーブになるはずだが、何週間かに一回出す「ヒット作品」による特殊なトラフィックが重なってこんな形になったもの、と想像できる。

　次にヒストグラム化したのが、Google Adsenseにおける日々のクリック数の統計データ。

　平均クリック数は５にも関わらずピークは２と３の間にあり、ページビューの偏りだけでは説明できない偏りだ。これを見る限りで言えることは、Google Adsenseは毎日でないにせよ、たまに「クリックする価値のある広告」を選び出して貼付けるため、日によっては３０クリックを超える日もあるということぐらいか。

　次にヒストグラム化したのは、アマゾン・アフィリエートで売上げのあった書物のそれぞれについて、何冊の売上げがあったかのデータ。

　とヒストグラム化してみたものの、１冊しか売れなかった本が大量にあるため、その偏りのためあまり訳にたたないグラフになってしまった。「これぞロングテールの力」と言っても良いのだが、テールが左上にあるのでこれでは恐竜には見えない。そこで仕方がないので、ヒストグラムではなく、純粋に売れた数順に書籍を並べて棒グラフ化したのがこれ。

　こうすれば、ちゃんと左上が頭、右下がしっぽのロングテールになってくれる。

　iPhone用の「はてな人気エントリーリーダー」、そろそろ形になってきたのだが、作ってみていろいろと発見した部分もあったので、全面的にクラス構成を見直し、大幅に書き直した。

　HTTPで通信をしているコードが二カ所に分かれていたので、それをDataOverHTTP/XMLOverHTTPという二つのクラスにまとめ（XMLOverHTTPはDataOverHTTPのサブクラス）、はてな独自のRSSフィードを読んでいるコードから一般的なRSSフィードを扱うコードをくくりだしてRSSFeed/RSSFeedLoaderという二つのクラスにまとめて、あとで別のアプリケーションで再利用することを可能にした。それに加えて、各種ローダーに非同期通信をさせる主体をController（HotEntryViewController）からModel側（HateneHotEntry）に移すことにより、難解になりがちなControllerのコードを大幅に簡略化して読みやすくした。

　この手の「大幅書き直し」をリファクタリングと呼ぶ人もいるが、私にとってはこの手の書き直しはプロジェクトの初期においては日常茶飯事。「これで完璧」と思ったものを次の日にさらに大幅に書き直し、なんてことも良くある。どんなに賢いエンジニアであっても、最初に思いついたアーキテクチャが最適であるなんてことはまずあり得ないので、この「作っては壊す」段階はより良いアーキテクチャに到達するためには必須の工程。焼き上がった壷が気に入らずにたたき割る陶芸師と同じだ。

　この段階で目指すことは、とにかくメンテナンスのしやすいコードを生成すること。プロジェクトも後半になるとどうしても大規模な書き直しはしにくくなるため、その場しのぎのコードでプログラムはどんどんと「きたなく」なって行く。その時に大きく影響してくるのが、プロジェクトの前半で書いたコードの品質。基盤さえしっかりしていれば、「その場しのぎコード」が多少混ざったところでなんとかなる。基盤がぐらぐらしていると、デスマーチあるのみだ。

　NTTの研究所にいた時にかいま見たウォーターフォール型の開発は、上流にいるエンジニアがフローチャートのレベルまでに落とし込んだ詳細設計書を下請けに渡して「コード化」するというものだったが、ここで完全に欠如しているのは、この「作っては壊しながら設計を改良して行く」という工程。

　私の経験から自信を持って言えるのだが、どんなに優秀なエンジニアでも、この「作っては壊す」という過程を経ずには良いソフトウェアは作れない。料理でも陶磁器でも同じだが、ソフトウェアには「作ってみて初めて分かる」ことがたくさんあるので、そこからのフィードバックを主任設計者が自らコードを書いて実感することがとても大切なのだ。

　ソフトウェアを作る上でもっとも難しいのは、顧客や内部からのあいまいな要求を詳細設計書に落とし込む部分であることは誰でも知っている。しかし、意外にちゃんと認識されていないのは、良い詳細設計をするためには、実際に設計者自身が（ここが大切、他人に任せてはいけない）プロジェクト初期段階で、自分が考えた設計をコードに落とし込んで「作っては壊す」という作業を繰り返しながら（コードではなく）設計そのものを「練り上げて行く」過程が必須だということ。

　それはシェフが新しく思いついたレシピに基づいて実際に料理をしながらレシピを改良して行く過程、もしくは陶芸師が焼き上がった壷のできを見ながら製造工程を改良して行く過程と全く同じだ。実際に料理を作らずにおいしい料理のレシピが書けるシェフがいないのと同様に、実際にプログラムを書かずに品質の高い詳細設計書など書けるエンジニアがいるはずがない。

　Cocoaのネットワークライブラリ上で、非同期HTTPでXMLを取得するクラスを作ったのでそれのテストを兼ねて、iPhone用「はてな人気エントリー・リーダー」を少し進化させてみた。

　アプリを立ち上げると、最初に取得するのは人気エントリーのRSSフィード。残念ながらこのフィードには各エントリーのブックマーク数に関する情報が含まれていないので、さらにXMLRPCでそれを取得しなければならないのだが、それが取得できるまでユーザーを待たせるのは好ましくない。

　そこで、RSSフィードを取得しだいすぐにタイトルのみ表示し（青字のテキスト）、ブックマーク数の取得は非同期にバックグラウンドで行い、情報が取得できしだい後から表示するようにした（赤字の部分）。

　実際に走らせると青字のタイトルが表示されてから、少し遅れて赤字のブックマーク数が表示される。もちろん、ブックマーク数が表示される前からリストをスクロールすることもエントリーを選択することもできるので、ブックマーク数に興味が無い場合はどんどん先に進める。

　モバイル端末で動くアプリケーションを作る時に注意を払わなければならない点は幾つかあるが、この手のきめ細かな工夫によりネットワーク遅延によるストレスをユーザーにできる限り感じさせない様に作ることは、重要項目の一つ。

　３G→４Gとネットワークが進化するとビットレートは高くなるのだが、ネットワーク遅延は必ずしも小さくならないので注意が必要だ。ブロードバンドだと100ms程度ですむ遅延が、ワイアレス・ネットワークだと数秒になることもあるということは覚えておいて損は無いだろう。

　ついでに見つけた壁登りロボットでもまたまた感動。しかし、日本のロボットと米国のロボットの方向性がかなり違うのが何とも。

• 日本のロボット研究者が二足歩行にこだわるのはやはりアトムの影響か
• 米国のロボットが実用性を重視しているのはやはり軍事予算のためか
• 日本の美少女ロボットはやはり秋葉原の影響か

しかし、ソニーがロボットの研究から手を引いたのは痛いな、と。

　こういう新しいテクノロジーを見た時に感じるものは人それぞれだと思う。私の場合は「どうやって動いているのだろう」よりも「何に応用できるだろう」が常に先に来る。障害者用の歩行椅子とか、ボストンバッグとか。４本足のボストンバックが紐をひっぱるだけで犬のようにピョコピョコと付いて来たら楽しいかも。階段とか楽だし...

「BSやCSができたときや、キャプテンシステムや音声多重放送など、新メディアが出てくるたび、『クリエイターの仕事が増えて引く手あまたになると言われたが、過去1回も、そんな経験はない」（堀さん）...堀さんは「コンテンツのデフレスパイラルが起きている」と指摘する。「例えばテレビの場合、設備投資が増した分、制作費が落ち、番組は横並びになる。しかしスポンサーは数字（視聴率）を求めるから、“分かりにくい番組”が淘汰される。分かりやすく作るからつまらなくなる」【「日本のコンテンツ、ネットのせいで沈む」とホリプロ社長 (1/2) - ITmedia Newsより引用】

　堀さんの言っていることはとても良く理解出来る。ネットに限らず、コンテンツの流通チャネル（メディアと呼んでも良い）が増えると、チャネルごとの絶対量が減るために、従来型の数で稼ぐ広告ビジネスがなりたたなくなるのだ。

　「巨人・大鵬・卵焼き」と言われるぐらいにほとんどの日本人が同じ方向を向いていた時代に誕生したテレビとそれに付随する放送・広告・コンテンツビジネスが、ネットの時代に直面して悩むのは当然と言えば当然。

　結局のところは、（ホリプロなどの）コンテンツプロバイダーに対して「儲かる仕組み」を提供しなければ話にならないということ。ニコニコ動画が消費者がテレビ局から盗んで来たコンテンツで盛り上がっている限りは「すきま産業」でしかありえない。コンテンツプロバイダーやテレビ番組の制作会社が「テレビ局とビジネスをするよりこっちの方が儲かるじゃん」と思えるビジネスを作らなければダメだということ。

　そういうところまで踏まえた上でiTunes storeをもう一度見直してみるとAppleの戦略が見えて来る。iTunes storeは今やWal-martに次ぐ世界第二位の音楽流通業者だが、ジョブズの目標はWal-martを抜いて業界一位になるなんて低いところにはない。狙いは当然、iTunes store単体でCD全部の売上げを抜くこと。そしてその次のターゲットはDVD。ジョブズはiTunes+iTunes storeを「CD」や「テレビ」に匹敵するメディアに育てようとしているのだ。

　ようやくiPhone SDK下で非同期通信をする方法が分かったので、「はてな人気エントリー」リーダーを作ってみた。SDKのドキュメントにはXMLパーサーの有無が明記されていないので、とりあえずはCocoaのXMLParserを使って実現。メモリをやたらと使うXMLDocumentはいざしらず、XMLParserぐらいは入れて来るだろう。

　ちなみに、UIKitにもずいぶんと慣れて来たので、このくらいのUIならサクッと作れる様になった。簡単なUIだとviewだけで作れてしまうが、ある程度複雑なUIを実現しようとするとview/controllerの分割を強制的にさせられるところがなかなか良くできている。

　本来ならこの手のサンプルのソースをオープンにしながら他の開発者と意見交換ができると良いのだが...はやいとこNDAの呪縛を取り払って欲しいぞ、と。

大手電機メーカーのSEとして就職して一年。うちの職場は、なんというか、生ぬるい。
...
きっと自分の成長の為には職を変えたほうがいいんじゃないかと思う。でも、自分の向学心の強さにはっきりとした自信が持てない。
...
24年間優等生をやってきて、さらに新卒という切符を使って手に入った貴重な（？）大企業への就職を、簡単に手放してしまっていいのだろうか。
...
【新卒で入社して一年より引用】

　なんだか昔の自分を見るようで心を動かされてしまったので一言。

　私自身、「せっかく理系の大学院をそれなりの成績で出ることができたのに（そうでない人が簡単には入れない）大企業へ行かないのはもったいない」というさもしい気持ちがあったからこそ、ベンチャー企業には行かずにNTTの研究所に入ったのは事実。「新卒という切符を使って手に入った貴重な（？）大企業への就職を、簡単に手放してしまっていいのだろうか」という気持ちはものすごく良く分かる。

　私もちょうど同じような悩みを抱えていたところに、アスキー時代に一緒に働いていた古川さん・成毛さんたちがマイクロソフトの日本法人を作るというニュースが飛び込んで来たために「これは行くしかない」と一瞬で決断できたわけで。あのきっかけが無くても遅かれ早かれNTTは辞めていたとは思うが、「この人たちと一緒に働きたい！」という前向きな姿勢で転職出来たのはとてもラッキーだったと思う。

　「こんなところにいて時間の無駄じゃないか」というプッシュの気持ち（＝出たいという気持ち）だけで飛び出すのは確かにリスクが高い。今の職場がなまぬるいなら、決意が固まるまでの間は、それを利用して自分なりの勉強をするなり、会社の外の人に会うなり、何か手を動かして作ってみるなりすると良いと思う。そんなことをしているうちに、「どうしてもこの人と働いてみたい」「どうしてもこんなものを作ってみたい」というプルの気持ちがはっきりと表れて来たら、迷う必要もなくなる。

　受け入れるベンチャー企業側としても、「今の会社にいても時間の無駄だから」というネガティブな理由で来る人よりも、「ぜひともここで働きたいから」というポジティブな理由で来る人を採用したいもの。