「51歳の左遷」からすべては始まった 川淵三郎

「51歳の左遷」からすべては始まった (PHP新書)

</div>
</div>

Jリーグ発足時にチェアマンだった川淵三郎さんの本。サッカー協会にいる間というよりかは、サラリーマン時代より共通して重要だと思った事項をまとめた付属的なお話といえる。自分の中で日本サッカーの躍進と基本思想といえば、この人が象徴的な存在になっている。

タイトルに「左遷」とあるが、実際は子会社へ部長職での出向なわけで「左遷」というには大げさかと思う。さらにサブタイトルの「大逆転のリーダシップ論」とあるがリストラされて職を失ったわけでもないから、大逆転というのも釣りっぽい感じがする。

ただ、51歳という人生における「何らかの落ち着いた職に就くだろう年代」から日本サッカーリーグに入り、Jリーグを発足させ、トップのポジションに就いたことを考えると、新しいことをなす時には年齢は関係ない。ことを実践しているわけで、これは40歳以降のキャリアデザインができない自分にとっては大きな励みになった。

というのも、転職する、起業するなど手法がどうあれ、職種を変える、今いるフィールドを変えることはとても大きなリスクであって、確実に自己実現につながるキャリアアップになるか、経済的にも成り立つのかの問に対して、確実なことは何も言えない。

特に年齢が上がるほど、キャリアが上がっていることを想定すると、よりスケールの大きなことを望むはず。「スケールが大きい = 失敗のリスクが高い」だろうから、本当にチャレンジしていいものかどうか、それを現実的なプランにしていいのかどうか。まだよく考えられていない状況がある。

励みになったからといって、今からJリーグのチェアマンになるという目標はたてないと思うけど、なにか今と違ったフィールドを想定するのもいいなぁと思った。

書かれている内容は川淵さんが古河電工のサラリーマン時代に得た経験やノウハウで、チェアマン、キャプテンとして日本サッカー協会の中でも使ってきたものを紹介している。

大企業でたくさんの役割の人の中でのふるまい方というのは確かにあって、スタートアップの経験とはまた異なるノウハウは確かに存在すると思う。これはこれで貴重な経験、ノウハウだと思っている。

Jリーグの地域密着とか芝生の校庭の小学校をとか好きなのだけど、その思想がどこから来たかはこの本からはわからないが、サラリーマン時代のノウハウというのはスポーツ界でもいろんな場で生きるものだと思えた本。

この本が出版された年が2009年でこの時70歳で、キャプテンも辞められているが、実に20年以上も時が流れ、携わり続けたことが何とも素晴らしいキャリアだと思う。

</div>

日本人よ! イビチャ・オシム

いきなりだが日本代表前監督イビチャ・オシムが好きだ。

今はもう日本代表監督は岡田監督をへてザッケローニ監督になり、日本の世界サッカーでのポジションもワールドカップ以降、急激に成長した。この躍進に直接関与しなかったこともあり、日本の中では過去の人になっているのかもしれない。

自分にサッカーの面白さ、奥深さ、世界視点でのサッカーを教えてくれたのはこのオシムだった。いくつかのオシムに関する本を読んできたが、この本も同じように色々なことを教えてくれる。

日本人よ!

</div>
</div>

書かれた時代は日本代表監督就任後、1年ほど経過したとき、脳卒中で倒れる前になる。

この本は日本でジェフ市原(現、ジェフ千葉)の監督時代から日本に住み、日本サッカーの発展を牽引してきた、オシムなりの日本に対するメッセージが詰まっている。話好きなオシムのことだから本当はもっと多くのことを述べたかったのかもしれない、それを思うとボリュームを抑えたページ数は彼の思いが凝縮された一冊だと思う。

サッカーというものへの向かい方、捉え方、世界のサッカーのトレンド、世界の中の日本というポイントで彼なりの思想、伝えたいことを示している。

日本のサッカーに携わる人達、協会、マスコミ、サポーター、ファン、それほどでもないファンがもう一つ奥深くレベルを上げてサッカーというものに取り組むときに必要なエッセンスが散りばめられている。

あくまでオシムは自分の考え方の押し付けはせず、日本人に問いかけ考えさせる。答えはこちらにあり、それを見つけだせるように促してくれる。

Jリーグが発足して以降、日本においてサッカーは市民権を得て、日本代表はワールドカップ出場、アジアカップ優勝の実績をあげてきたわけだが、そこに対して我々は何かフィーバーのような感覚で接していなかったか、相手の実力や実績を知らずに根拠なく、勝ち続けることができるような気がしていなかったか。

より相手を知って、己を知って、サッカーを知って、世界を知って、より客観的に捉えるように戒めを与えてくれる。

オシムの指摘は的確だと思う。それは彼自身、日本の文化、歴史について学んだ上で述べているからであり、文章中でも日本の歴史的背景を踏まえている部分が見つけられる。

この本を読んでからサッカーの試合を見るとなにか印象が変わっていることに気づく。試合を冷静に考えつつ見ることができて、サッカーが起きることが何か荘厳な人生の教訓を教えてくれるようなものに感じられた。

サッカーをもう一つ深い視点で見たい人、サッカーともう少し深い付き合いにしたい人にこの本を薦めたい。

</div>

オンラインゲームを支える技術

元コミュニティーエンジン社長のringoさんから「オンラインゲームを支える技術」を献本していただきました。ありがとうございます。

ringoさんとは2007年に meet-me の立ち上げの時に初めて出会って、独立した後の2009年に ShakeSoul としてバーチャルコミュニティーサービスの立ち上げプロジェクトで声をかけてもらって一緒に仕事させてもらった。帰り道に電車の中で色々言い合ったことがとても楽しい記憶に残っていて、今後も一緒にできたらと思っている人だ。

オンラインゲームを支える技術  --壮大なプレイ空間の舞台裏 (WEB+DB PRESS plus)

</div>
</div>

この本はオンラインゲームをつくり、運営/運用するための要素がまとめられている。

タイトルに「支える技術」とあるが、トータルとして必要な要素に触れているので、技術だけでなくオンラインゲームそのものの奥深さを実感できると思う。エンジニア以外のソーシャルアプリプロバイダーの経営的な立場にいる人にとってはMMORPGのような規模の大きいゲーム作りへの模索が可能になるかと思うし、逆にエンジニアにとっては技術を知るだけにとどまらず、技術がオンラインゲームを構成する上でどういう重要度や立ち位置なのかを知ることができると思う。

曖昧な解説にとどまらず、概念から具体化していくようなアプローチが取られており、筆者の10年以上オンラインゲームづくりに関わってきて血肉化された経験の結晶だと思う。

オンラインゲームのシステム構成やその技術手法はWebとは異なる歴史があり、ゲーム会社がそれぞれ独自に開発してきたことやゲームシステム自体に閉鎖性が必要なためブラックボックス化されてきた。各ゲーム会社の技術ノウハウが共有されることはなかった。やっとオンラインゲームの技術情報がオープンになりつつある。そのきっかけとしてこの本の役割は大きい。

この本を読めばオンラインゲームを作るための必要な要素が分る。本格的なMMORPGを作るための要素はにはWebサイトをつくるととは全く異なるため、Webの延長では簡単には参入できないことが実感できる。Webの参入障壁の低さに比べ、オンラインゲームをちゃんと作ることはとてもシビアな世界だと言える。すでにWebの技術要素が単純で効率化され整った環境が用意されているし、特に最近はRuby on Railsなどのフレームワークによってより効率的な環境を利用することがはやりの方向なので、なおさらかと思う。今後オンラインゲームも同じ方向に進むと思われるし、そんなサービスも作ってみたいが、まだまだ超えるべき技術的な壁が数多くある現状かと思う。

オンラインゲームの求める要件は高く、特に限りあるサーバスペック、ネットワークレイテンシーの中でどう収めるかがエンジニアの課題になることが具体的に書かれている。抽象化された部分からでは解決できない、低レイヤ部分への考慮から始まりそれを実現するためのの実装につながる。幅広い技術知識を有する必要性も感じる。エンジニアが実際設計や開発する際に役立ちそうな、作法を載せていたり具体的な数値を使ってサーバ台数や処理スピードなどを算出している部分は、現場で是非真似してほしいとても重要なノウハウだと思う。

さらに企画やデザインの様々な要件課題を技術的アプローチで解決する。すべては可能にならないので、企画とのすり合わせでベターな技術的手法を探る。技術ドリブンではなく「ひとつの世界観を創り上げるための手法としての技術」の位置づけは、Webとは異なる部分かと思う。

ページ数が多く、技術要素も多岐にわたり、やや冗長な印象もあるが階層的に丁寧に説明を進めるので、必要な時に読み返しつつじっくり付き合うような本かと思う。読み終わればオンラインゲームの基礎概要はしっかり理解できるはず。

実際作ってみようかと思っている人にとっては「これを読めば作れるようになる」とまではいかないが、それなりに規模感のあるオンラインゲームをつくるのに必要な体制(チームづくり、人員配置、エンジニアのスキルセット)や予算規模(システム規模、収益計画)がイメージできるのではと思う。

筆者が冒頭に述べているように、ゲームがiPhone、スマートフォン、facebookなど様々なプラットフォームで提供されるようになっているので、今後ゲームはもっとコンシューマに近いものとして利用され、その数も増えていって欲しいと思う。

個人的に興味があるのは、Webのオープン性とゲームの閉鎖性のバランス。Webとゲームの境目は今後ますます曖昧になっていくのだろう。今まではWebはオープンであろうとしてきた、今後はゲーム的要素が入ってくると面白いコンテンツになるかもしれない。ゲームのようなストーリーを持たせることやレベルなどの差別要素、制限要素などはオープン性と相反するから、どこかで折り合いを付ける必要がある。やはりWebはオープンであろうとし続けるのか、ゲーム性によって新しい方向を示しつつより豊かになっていくのか、今後利用されるアプリケーションのオープン性とゲーム性のバランスはどのくらいなのか。とても興味がある。

しかし、どこかで見たサーバプロセスの構成図、サーバや帯域の算出方法、懐かしい思い出に浸ってしまう。良い経験の思い出。

iPhone, facebookをプラットフォームとしたソーシャルゲームの広がりが進み、Webとゲームの境目が曖昧になってきている今この時に、オンラインゲームの技術的な解説がされているこの本が出ることの意味は大きい。

</div>

スタートアップを始めるときの優先順位

2010年3月から最初のスタートアップをやってきているが、色々やってみないと分からないことが本当に多かった。このチャレンジで自分なりのノウハウをつけたいと思ってきたし、ある程度まとまってきたような気がするのでまとめてみる。

書いている内容は実際やってみて、今のところこの優先順位で進めることが一番失敗のリスクを抑えられる方法と思っている。起業の全ては可能性なので、基本どんな方法でも可能性はあるし、この方法が絶対だ!と言うつもりもない。今も模索している最中なので、是非経験された方々と意見交換がしてみたいと思っている。コメント、twitter、メールでもフィードバックをいただけたら嬉しいです。

ここで述べている前提としているスタートアップの定義は以下。

  • 何がしかのインターネットにからむサービスを自ら開発し、運営しながら高い成長率を目指す
  • 個人~3名くらいの少数の創業者で始める
  • サービスの成長過程では資金調達を行い、企業価値を結果的に5倍~十数倍程度まで上げてエグジットを目指す
  • デバイスなどハードウエア系は対象としてない
  • 低い成長率を目指す中小企業もしくはプライベートカンパニーは対象としていない

自分なりの優先順位は以下。

  1. サービスをつくる
  2. 無料をローンチ
  3. 会社を作る
  4. 課金サービスをローンチ
  5. エンジェルからの資金調達

1. とにかく最初にサービスを作るところまでやる

まずサービスありき。少なくともインターネット系のサービスであればデモできるレベルまでつくることが必要。何よりも先に優先し、ある程度形になるまでは次の動きを始めなくて良い。

動くものがなければ単なるアイデアであって、アイデアだけには価値はない。

実際にデモが出来る前にいくつかの日本のVCに話してみたが、具体的に話がすぐ進むということはなかった。その場としては日本のVCは興味がありそうな姿勢を見せてくれて、結構好感触かと思ってしまった。実は今すぐ投資することはなくて、ローンチしたら当たるかもしれないから、それまでキープしたいがための姿勢だったというのが後から分かった。やはり、アイデアだけを示しても、それにお金がつくことはないと思ったほうがいい。あとは、そもそも日本のVCはローンチ後ある程度会社が成長してきた段階の、シリーズB以降の資金提供を行うところがほとんどということもあった。もしうまく話を進めて、投資検討できたとしても会社のバリューはすごく低く見積もられるだろうから、創業者の割合が低い悪条件が前提になるだろう。

スタートアップをやろうとするときにまず会社をつくろうと発想しがちだが、それよりも本当にアイデアが実現できているかを示せていないと、後々苦しくなってくる。アイデアの実現可能性はスタートアップを行う上では問われるシーンはほとんどない。問われてしまっている時点で投資対象にはならない。ちゃんと動くことが用意できていることが投資検討の前提になっていると思う。投資する側から見ればイメージしやすい当然のことなのだけど、意外と気付けていない点だったと思う。

だから、資金調達をしてエンジニアを増やして最初のローンチを目指す。という流れはまず資金調達が難しい。その資金は少なくともVCからは出てこないと思ったほうがいい。その場合は、エンジニアを創業者としてタダで動いてもらうことが一番リスクを抑えられつつ、前に進める策かなと思う。

2. フィードバックをもとに改善

たくさんの人に使ってもらう or デモしながらフィードバックを集めるのがこのフェーズ。

最初のアイデアが最もユーザに適しているとは思わないほうがいい。客観的評価を得てサービスをよりよい方向に変化させていくことは必要なことで、そのための時間は優先して取るべきだと認識した方がいい。なるべく多くのターゲットとなりうる人たちからフィードバックを得て、変更を加えていく。無料サービスであればサービス内容を変更することへの抵抗は少ないはずなので、変更しやすい。

この時に初めてターゲッティングやマーケットを意識しだして、ビジネスプランを練っても遅くはない。1つのアイデアがユーザのフィードバックによって、ビジネスらしくしてくれる。むしろサービスを作る前からビジネスプランを固定化してしまうほうが、誰も使わないものを出してしまう可能性が高くて危険だ。

この時は無料でサービスを提供するので売上は上がらないから、個人名義でサービスを行っていても問題ない。ただ、サーバのホスティング費用は自腹になるので、やはりある程度の出費は覚悟しておいたほうがいい。

3&4. 会社を作るのはなるべく後

会社作りを急ぐ理由はないと思う。大事なのはサービスが多くのユーザに使われるかであって、会社が必要な状態は有料サービスを始める時で、売上を受け取るための受け皿としての役割でしかない。あとはここで示している順番通りにいかず、売上があがる前に資金調達を行う場合も、会社が株を発行する or 転換ノート(Convertible Notes)するために必要になる。

早く会社を作る必要がない理由として、売上があがる前 or ユーザが獲得できる前の会社であれば、バリュエーションはどこも同じで差別化できないという状況がある。だいたい$1Mくらいにしておくのが無難のようだ*1*2。ローンチ直前に作っても、ローンチしない状態を半年続けてもバリュエーションは変わらないだろう。

もうひとつの理由としては、会社を作ると色々お金がかかってくる。専門家(弁護士、会計士など)への支払い。税金の支払。会計用アプリケーションの購入などなど。売上がないのにこれらの費用が発生し、しかも時間も取られるのは、自らの環境をより一層状況を厳しくさせる。

5. 資金調達は最後、必要な段階になったらがベスト

「スタートアップを始めるので、会社を作ってすぐ資金調達をする」と思ってしまうと、その後の状況が苦しく不幸な状態なる。サービスを続けていく上で、売上だけではまかなえなくて、これ以上は自腹も切れないとなったら最後の最後で資金調達をする、と思っていたほうがいい。あくまで、「必要となったから入れる。」のほうが創業者の利益確保の観点から良い。

もっとも最初からサービスをつくるために大きな開発費用が必要なデバイス系などハードウエア製品であれば、アイデアの段階で資金調達をする必要があるので話は違ってくる。

資金調達をするタイミングをなるべく遅くする理由は、サービスをローンチしている前提ならば、この耐えている時間で会社のバリュエーションが上がる or 上がる可能性があるから。「バリューが上がる => 有利な条件で資金調達が行える => 創業者の株式保有比率は高く保たれる => エグジット時の成功が大きくなる」という具合になる。

もうひとつの理由は、資金を入れる前にサービスの反応が得られているだろうから、このチャレンジを継続させる or 辞めるかの大きな判断ができる。もし辞める場合には今まで自腹を切った費用だけになるので損出を小さく抑えることができる。資金を入れてしまったら、損出がより大きくなってしまうことに加えて、投資してくれた方々への配慮が必要なので、辞めづらい状況になる。

以上まとめてみたが、この流れで行くと有料サービスを始めるまでは資金調達はしないので、自腹を切っている状態になる。実はスタートアップをするには資金調達をする前に出て行く費用は自分で何とかしなければいけない。結局、他人のお金をあてにする前に自分のお金を用意しなくてはチャレンジできないことだと思う。蓄え or 他の仕事をしながら or 親戚友人から借りる、手法はいろいろだが、どの程度のお金が必要かについては別エントリーにまとめる予定。

今のところこの優先順位で始めれば、リスクを抑えつつ大きな成功を目指すチャレンジが繰り返せるのではないかと思う。スタートアップは1回だけで終わりではないし、2回目、3回目と繰り返しながらでも成功を目指し続けることが重要だと思うので、なるべくリスクを抑えるための策を練っておいたほうがいいと思っている。

</div>

facebook を読んでみて、なぜここまではやったのかを考えてみた

映画の原作になったfacebookを読んでみた。

facebook

</div>
</div>

一応、本を読んだ感想を少しだけ述べておくと、

  • スタートアップによくある感じのサクセスストーリーを退屈な状況描写を絡めて、架空の物語を描いているだけのお話。
  • 結局、マーク・ザッカーバーグにインタビューできたわけではないので、誇張や嘘の含まれた「作られた小説」でしかない。
  • 小説なので、これを読んでスタートアップを成功させるためのヒントを得ようと思わないほうがいい。なんの示唆もない。
  • 読み終わった後に「で、なんだったの?」で終わる。

ちょっとだけ面白い部分もあるが、まぁよくある話だよね。で終わってしまうかな。

今年2011年1月時点で、facebookのバリュエーションは$50 Billionと言われている。

http://tctechcrunch.files.wordpress.com/2011/01/fb-valuation-chart.jpg?w=830

上場前としてはとんでもない数字だし、上場後はさらに上がるだろうからまったくどうなってしまうのやら。また、ユーザ数が6.5億(執筆時点)という数字もこれまたすごい。この本を読んだ後にfacebookはなぜ空前の評価額になるまではやったのか、その理由がふと思い浮かんだのでつらつらと書いてみる。

米国のトップ校発というブランドイメージ

  • 「ハーバード大学のコンピュータサイエンス専攻の学生が作ったサービス」というだけで、すでにこの時点でブランドイメージは作られている。
  • ブランドイメージがサービスの拡大を加速させた。
  • 初期のfacebookのユーザの拡大は大学単位で、「あの大学が流行っているからうちも使いたい」になる。
  • マイナーな大学の中ではやっていても、他の大学は真似しようと思わないだろう。
  • 日本で言えば東大で流行って、京大も加わって、東京6大学も加わって、、、のような展開の仕方と思えばイメージしやすいだろうか。

先行実績の大きさと有利な投資条件を得る

  • ユーザに課金せずFREEで提供するモデルが成功するためには、「ユーザをいかに多く獲得できるか」のみにフォーカスされるが、実際facebookは最初の資金調達を行う前の早い段階で、すでに数万のユーザを獲得していた。</p>
    • ユーザ数がすべての要素を凌駕する。ユーザ数の多さが価値になる。
    • このモデルは売上規模も利益も数年は出ないだろう。単月で見れば赤字が続き、毎月キャッシュを消費しつつ、それを補うために資金調達をする。
    • エグジットのための条件は、とんでもなく多いユーザ数、それを支えるに必要な大量の資金(資金調達額)、バリュエーションの最大化(ベストはIPO)になる。
  • 自分たちの資金も尽きそうでギリギリまで耐えて、時間をなるべく経過させバリューを上げるだけ上げる。そして有利な条件で投資を受ける。創業者の株式保有率は高く保たれる。
  • 投資をしたいところは多かったが、安易に資金調達の誘いに乗らなかったのは、理にかなっている。
  • このモデルのエグジットを成功させるには長い年月が必要だが、早期には売らないという創業者の信念が一貫されてきた。

絞り込みやすい狭いコミュニティがターゲット

  • 初期のユーザとなる大学内の学生同士は日常的な結びつきが非常に高いし、結びつこうとする特性が元々ある。
  • 寮に入っているケースが多いので、学生同士会話する機会は職場のビジネスマンより圧倒的に多い。
  • 友人の間でクチコミが広がりやすい。伝搬速度はとても早い。
  • 大学のメールアドレスをログインの条件にしていたことで、ユーザになれる資格が一種のプレミアム感を作り出し、乗り遅れないよう登録しようという雰囲気を生む。

米国シェアNo.1 = 世界シェアNo.1

  • アメリカでダントツにはやったからこそ、他の国でも使われやすい。
  • インターネットサービスにおける、「アメリカ = シリコンバレー = 世界」のイメージの強さが背景にある。
  • 現に日本でもアーリーアダプターはmixiをとっくに離れfacebookメインで使っている現状。今後もこのイメージのもと日本でのシェアは伸びるだろう。

と書いてみたものの、振り返ってみれば色々言えてしまうわけで、マーク・ザッカーバーグも最初からfacebookがここまで大きくなると確信していたわけではないだろう。確かに言えることは、小さな種がここまで巨大な資本の塊に成長できるという事実で、その生まれる土壌はまだまだアメリカにある。ということだろう。

</div>

Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方

まずはじめに言ってしまうと、この本は 初めて起業しようと思っている人は必ず読んでおいたほうがいい。推薦書だ。

Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方

</div>
</div>

邦題は「革新的ソフトウェア企業の作り方」だが原題は「Eric Sink on the Business of Software」となっていて関連がない。原文は筆者のWebサイトで見れるようだ。筆者はエンジニアで、いくつかの起業を行い小さなソフトウエア会社 ISV(Independent Software Vendor) として成功してきている。

本の発行は2008年だが実際書かれたのはMSDNのコラム連載として2003年から2005年にかけてで、今からみるとかなりの年月が経ってしまっているが、書かれている内容が色あせている印象はない。あと筆者の会社ではWindows上で用いられる開発ツールを開発、販売をしており、スタートアップの印象としてよくあるインターネットサービスのモデルとは異なるが、この点も書かれている内容に影響しているとは思わなかった。それほど本質的、普遍的な書き方と内容になっていると思う。

日本では起業の本というと、実践的ノウハウの乏しいタイトルだけで釣るまがい物が多々ある中で、この本は本物で、ノウハウや示唆に富んだ貴重な1冊だと言っていい。内容は起業すること自体への考え方、人、マーケティング、セールスに分かれており、起業し会社を動かしていく際に重要な側面を網羅していると思う。今スタートアップをしてみているが、始める前に読んでいればいろんな面で遠回りが減っていただろうなぁと想像して少し悔やんだほど。

起業の全ては可能性なので、どんなやり方も可能性は0ではないが、失敗するリスクを最小限にするためにどうすればいいか。という観点で、筆者の成功も失敗も含めて経験してきたてきたノウハウが書かれている。筆者もきれいな結論を述べるのではなく、考える上でポイントになるようなこと、それが絶対ではないことは度々説明している。

共感したポイントの抜粋は以下。

  • 単なるアイデアには価格はないのだ。ビジネスの世界では、アイデアに値打ちはない。本当の価値はうまく実施することでもたらされる。
  • 収支計画の作り方
    1. 収支計画を立てたとき、バージョン1.0を作るのにどれくらいかかると仮定したか?その値が何であれ、それを2倍にすること。そして収支計画をそれに応じて修正する。最初のリリースを作るまでには、あなたが考えているよりずっと長くかかるだろう。
    2. 収支の予測値をすべて半分にすること。
    3. 支出の予測値をすべて2倍にすること。
  • 小さなISVに必要なのはプログラマではなく開発者
  • 絶えず学び続けることに真剣な人を雇うということだ。そういう人は自分がどれほど知識があるか見せようとして時間を無駄にしたりはしない。
  • ブレーンストーミングにおいてもっとも重要なルールは、やっている最中にはアイデアの評価をしないということだ。出てきたアイデアはどんなにバカらしく見えても書きだすようにしよう。
  • 製品の問題を隠そうとする企業は、その問題を修正しないということだ。
  • 主たる差別化要因が価格だというなら、考え直したほうがいい。差別化要因というのは極めて重要なものであり、低価格を主要な差別化要因とするなら、よく踏みならされた失敗への道を歩むことになる。
  • オープンに開発することで、そのことを開発の非常に早い時期に知ることができたということだ。あなたには機能セットを修正する時間がある。あるいはプロジェクトを中止して、損出を抑えるという決定をするかもしれない。どちらの場合にしても、アプリケーションの完成まで待たずに、早い時期に悪い知らせを得られたことで、状況は良くなるのだ。

今まで自分になかった新たな気づきのポイントの抜粋は以下。

  • ニッチにあるチャンスこそ、今日のソフトウェア製品が生き延びる道だ。私が言っているのは、大きな会社が追いかけるには単に小さすぎるマーケットセグメントのことだ。
  • 樽の中にはめ込める石を注意深く選ぶ方法を知る必要がある。大きさが重要だ。小さな石に目を向けるなら、クールなチャンスはたくさんある。
  • 多くの会社は競合の優秀さや強さによってではなく、自らの愚かなミスによって潰れていく。手堅くありつづけ、ビジネスを継続することだ。そうやって何年か経たとき、いかに多くの競合が現れては消えて言ったかに驚くだろう。
  • 成功するための方法は、小さな集団を見つけ、その人々が製品を好きになるようにするということだ。大きなマーケットに取り組むのは、小さなマーケットを手に入れた後にすること。走る前に歩けるようになる必要がある。
  • あなたの付ける価格はそのメッセージと整合している必要がある。あなたが199ドルのような値段をつけたなら、誰もそのメッセージを信じないだろう。安い値段をつけるのは混乱したメッセージを送ることになるのだ。

初めてのことだと概要の理解どまりで、そこから先の実践的な事柄が欠落しがちになる。スタートアップのニュースはとても華々しく映るし、自分もその流れに乗っているかのごとく錯覚しがちだが、大事なのは手堅く製品を作り、それを表す明確な文章を考え、すぐに潰れないための収支計画を作るなどの地味なことの積み重ねが失敗するリスクを減らしてくれる。そのことをこの本が教えてくれる。

最初の起業は失敗するリスクはとても多いはずで、ほとんどが消えてなくなってしまっているだろう。facebookのような例は本当にまれだ(まれだからこそ注目されているのだけど)。失敗したことを踏まえて2回目、3回目とチャレンジして成功の規模を大きくしていくような、戦略的な堅実さと謙虚さが大事だということを筆者は身を持って伝えている。

スタートアップという華やかなチャンジに身を染めてみたい、と考えている方はその覚悟の度合を測る意味でも、この本を一度読まれることをお薦めする。

</div>

今までやってみて良かったアジャイルぽいやり方

2008年くらいにアジャイルという単語を知って著名な本を読んでみたりしたが、いつの間にか市民権を得ているアジャイルという単語。

「***手法というのがあってドキュメントがあるから読んでみる?」みたいに言われて読んでみてみたけど、今まで読んだ本に書かれていることと結構ダブっていたり、仕事でやってみたことと同じ部分もあった。やはりアジャイルは概念ではなく具体的な実践のための考え方だなぁと再認識した。

紹介されている手法と重複していた実際やってみて良かったかなと思うやり方をこれを機にまとめてみる。今後忘れないためのメモでもある。

特に今はなきコミュニティーエンジンと一緒に2009年夏~2010年春にかけて3Dバーチャルコミュニティの立ち上げプロジェクトをやったときの経験が多いと思う。本当にいい経験をさせてもらったと今更ながら思い返す。

  • 役割分担</p>
    • 1チームは3~5人。1名のプロジェクトマネージャとその他はすべてエンジニア
    • エンジニアの技術的手法にはプロジェクトマネージャは口を出さない
    • プロジェクトマネージャは顧客とのインターフェイスに徹する。つくるものの内容(仕様/要件)の確認や進捗の報告を行う
  • スケジュールを状況変化に応じて日々更新する
    • 機能ごとの工数見積りはエンジニアが行う
    • 更新するのはプロジェクトマネージャが行う
  • バーンダウンチャートを活用する
    • 全体の工数と進捗率がビジュアル的に分かり、共通認識がつくりやすい
  • 毎日15分の立ったままミーティング
    • 各人の昨日やったTODO、今日やるTODOを言う
    • 相手へのリクエスト(相談や説明がほしいなど)、その場で解消せずに当人同士で後で時間を決める
  • 週1回のミーティング
    • スケジュールとゴールの共有
    • バーンダウンチャートの確認
    • プロジェクトマネージャから全体の情報や変化している状況をエンジニアに伝える
  • エンジニアが日常的にプロジェクトマネージャへ相談する
    • 実装する上での不明確な点の解消
    • プロジェクトマネージャはいつでも相談される体制にしておく
  • TODOのチケット化、ポストイット
    • 担当者の受け渡し可能
    • チケットの処理状況はバーンダウンチャートに反映される
  • スケジュール(A4 x 9枚くらいに大きく印刷)とポストイットを壁に貼って可視化する
    • 各人のタスクと順番が確認できる

意外と良かったのは5cm x 5cmのポストイットを使うこと。1つのマイルストーンごとに壁に貼って、今やっているものを固めて貼る。終わったら別の場所にまとめて貼る。新たに出てきたタスクはポストイットに書いて壁に追加する。受け渡しもポストイットを渡すだけで簡単。最初チケッティングシステムを使っていたが、いまいちチケットの進捗が出にくくポストイットも併用した。メンバ全員が全体量が見えやすく、受け渡しがしやすかった。1マイルストーン分のポストイットが壁から消えたら終了で全員で達成感を味わえる。で、次のマイルストーンも同じようにとりかかる。

あとはバーンダウンチャート。これも全体量を可視化しやすく達成率が分かるが、これはタスクの処理速度が速いか遅れているかが分かりやすい特徴がある。

特にアジャイルという言葉に縛られずに、流動的な事態に対応しつつ確実に進めていくために、どんな手法を使うか。事態に飲み込まれることなく、積極的に工夫して自分たちがやりやすい環境を作りだそうとする姿勢が大事なのだろう。

困難な状況でも日常的に行う手法で楽しんでいければ、チームとしてはより良いパフォーマンスがしやすくなるということだろう。

今後もより良い手法を見つけていけたらと思う。

外国法人の日本支店設立 アメリカ大使館での公証

今回アメリカ法人の日本支店を作ったので、東京にあるアメリカ大使館へ公証を受けに行きました。アメリカで公証を受けることもできるようですが、アメリカ大使館に行けば日本で手続きを全て済ませることができます。

具体的にはアメリカ大使館の職員のもと宣誓して事前に作っておいた宣誓書に印を押してもらいます。宣誓自体は数分で終わる簡単なものです。準備も含め流れとしては以下のようになります。

  1. 宣誓書を作る
  2. アメリカ大使館のWebサイトで予約をする
  3. アメリカ大使館へ行って、交渉を受ける

宣誓書の作り方

宣誓書に記述する内容は本社住所、資本金、発行株数など、Certificate of Incorporation に記載している内容で埋められます。

ここにあるサンプルをベースに作りました。自分の会社の情報に合わせて書き換えて使ってもらえればと思います。公証を受けるのは英文のみですが、公証が終わった後に法務局に和訳を提出するので、ついでに作ってしまいましょう。

Webサイトからの予約

  • ここから予約をします</p>
    • 予約をしなくても手続きはできるようですが、大使館内での処理は予約者が優先されることと、大使館前の警察官の検問の時に予約がある、と言うとスムーズにパスできるので、予約したほうが何かと良いと思います。
  • 「Make Appointment」— 「Request notarial and other services not listed above.」と進んで名前などを入力し登録すると、登録完了のページが表示されるのでこのページをプリントアウトしておきます。大使館で受付するときにこの紙を提出するので必要です。Appointment UIDが分かればあとで日付も変更できます。

いざアメリカ大使館へ

なかなかアメリカ大使館に入る経験もないと思うので、少し細かめにその様子を書きます。

受付に到着するまで

9.11のテロ以降だからだと思うのですが、アメリカ大使館入口周辺の警備はとても厳重でした。大使館前に渡る横断歩道を挟むように警察官がいて、大使館入口の前には装甲車2台でしかもエンジンかけてレディー状態。こわごわ前を通り正門横にある小屋のような受付に進みます。

  1. 小屋の前にいる警察官に用件を聞かれ、カバンの中から金属探知機に反応するようなPCや携帯を出します。携帯は電源を切ります。
  2. 小屋の入口前に立ち、中にいる警察官に開けてもらい中に入ります。空港によくあるゲート状の金属探知機があるので、PCと携帯を出した状態でゲートをくぐります。ゲートをくぐった後、PCと携帯は敷地内に持ち込まないよう預け、引換番号券を受け取ります。
  3. 小屋を出るとアメリカ大使館の敷地に入り一気に景色が広がります。案内板にしたがって手前右の建物にむかいます。
  4. 建物の入口に受付があり、そこでもカバンの中身チェックとゲート状の金属探知機をくぐります。問題なければやっと建物の中に入れます。

中に入ると銀行の窓口前の待合室のように椅子がたくさん並んだフロアに出ます。入った左側の窓口が並ぶエリアが公証を受けれる場所です。順番待ち用の発券機があるのですが、予約がある場合にはその券は取らずにそのまま左手に進みます。平日の昼前に行ったのですが、4組くらいの人たちがいました。壁から吊るした液晶テレビには画質の悪いESPNが流れていてNBAの試合を中継していました。ここはもうアメリカなのだなと思える光景でした。

公証してもらう

予約の登録完了ページを印刷した紙を窓口にあるトレイに出します。予約した時間になると中の職員が紙をとって中で処理を進めます。待合席と職員のいるエリアには透明なガラス or アクリル板で区切られていて、小さな穴がいくつか開いた部分で会話をするようになっています。

  1. 名前が呼ばれ、支店設立の公証を受けに来たと伝えると、まず料金を払って来るようにと言われました。
  2. 入口すぐ左にあった購入場所で払います。$50でした。クレジットカードでの支払いもできます。
  3. 再び窓口に持って行き、呼ばれるのを待ちます。
  4. アメリカ人のおじいちゃんくらいの歳の人に呼ばれて、アクリル板越しに宣誓を始めます。
    • 右手をあげるように言われて、ここに書いてあることは正しいか?みたいなことを聞かれるので、Yesと答える。
    • そうすると宣誓書に刻印を押してくれます。
    • 押した後に軽い会話のように会社の場所はどこだ?みたいな事を聞かれて、デラウエア州です。と答えたら宣誓書を返してくれた。
      • 会社の住所は宣誓書に書いてあるのに聞いたということは、中身はちゃんと読んでいないようだ。
  5. 刻印の押された宣誓書が手に入ればもうOK、完了です
宣誓書の内容は?

これはやってみて分かったことですが、アメリカ大使館では記載内容に間違いはないね。という宣誓をさせる場なので、宣誓書の内容が正しいかどうかはチェックしません。この後、公証の終わった宣誓書を元に法務局で支店登記を行うので、実は会社情報に対するチェック機能はどこにもないことになります。結局、宣誓書を書いた自分の責任で全て完結させることになります。国をまたいだ制度なのでグレーゾーンというか微妙な部分はあるのでしょうね。

次回は法務局への登記について説明します。

</div>

Amazon RDS の Read Replica 触ってみた

前から気になっていた Amazon RDS を触ってみた。gumiは自前でインスタンスにMySQLをセットアップせずにRDS使っているし、read replicaも出てスケーリングに関してどの程度カバーできるのか興味もあった。やっぱりMySQLの構築や運用は任せられたほうが楽なので。

f:id:d_sea:20110207182011p:image:w350

作り方はとても簡単。AWS Management Console上ではいくつかのパラメータをいれてクリックしていければ作れる。最初にインスタンスタイプとストレージ容量などを決める必要があるが、これは後から変更も可能。

ここで特徴的なのは Multi-AZ だと思う。これはおそらくレプリケーションしていて、Masterとは異なるAvailability Zoneにあるインスタンスでホットスタンバイ機が設けられる。万が一、Masterのデータセンターごと落ちちゃった時やメンテナンス時にこのスタンバイ機にフェールオーバーされるらしい。やはりDBはシングルポイントで落ちては困るので、Multi-AZ は付けておきたいが、料金も倍かかるので注意。

f:id:d_sea:20110207182013p:image:w350

変更画面はこんな感じでいろいろ変えることができる。インスタンスタイプとストレージ容量が途中で変えられるのは、予測しづらい中で運用する際には嬉しいと思う。

最初のMasterの起動自体は5分くらいかかっている。裏でEBSマウントして、MySQL立ち上げてユーザ設定してとかやっているのだろう。

f:id:d_sea:20110207182014p:image:w350

Slaveにあたる read replica を作るのもAWS Management Consoleから行える。Masterより設定項目が少ないので、簡単にレプリケーションを張ったSlaveが作れる。read replica は最大5台まで立ち上げられる。

f:id:d_sea:20110207191957p:image

read replica が立ち上げ中の時はManagement Console上のMasterのstatusはmodifyingになるので、レプリケーションをはるためにMySQLは止まってしまうのだろう。上は新規で立ち上げた read replica のstatus。

ここから色々探ってみる。

ホスト名を引くとec2のホスト名にCNAMEされていた。


2010年を振り返る

2009年も振り返りをして、1年間を俯瞰して記録しておくのは大事だと思ったので、2010年も残しておく。

2010年はシリコンバレースタートアップを実際始めたという点では、自分の人生の中で大きな転換点だろうしこれはちゃんと残しておきたいという気持ちもある。

1月

  • ShakeSoulとしてコミュニティーエンジン(CE)との3Dバーチャルコミュニティのプロジェクトを2009年から継続して行う
  • id:keikuboとアイデアを練ってきたサービスをシリコンバレースタートアップとしてスタートさせる具体的動きを始める
  • シリコンバレーでオフィスを構える手段として、JETROのインキュベーションプログラムの審査を受けるように準備をすすめる
    • インキュベーションプログラムは2010年度で終了予定。新たなプログラムが4月から開始されるらしい。
  • JETROとコンタクトをとる

2月

  • ShakeSoul, inc設立後、1年が経過
  • JETRO審査会、結果的に合格しシリコンバレーオフィスを構えることができた
  • 末日でCEとの契約が終了。関わったプロジェクトのサービスオープンまで関われずに途中で抜ける心苦しさが残った

3月

  • 2009年末から進めていたAmazon EC2本の執筆が本格化する
  • id:keikuboとサンフランシスコ空港近くで合宿。オンラインでfluxflex, incをデラウエア州に設立
  • ShakeSoulの仕事を受けることをストップし、fluxflexにフルコミットして時間を使うことにする

4月

  • シーズン終わり間際に家族でスキーしに行く。9年ぶりにスノボーしてわりと滑れた
  • JAWSユーザ会のライトニングトークではじめてfluxflexのコンセプトを発表する
  • 4年間通った矯正歯科が終了
  • 6月からの渡米に向けてSkype英会話スタート。5月末まで週5ペースで行う

5月

  • Tech Crunch Japanのイベント東京Campのデモピットにfluxflexとして参加
  • 2009年から一緒に仕事をさせてもらったCEが解散し、とてもビックリしたと同時に、小さな会社を継続させていくために何が必要か考え気づけたこともあった

6月

  • fluxflexシリコンバレーオフィスを立ち上げるためにサンノゼに渡米する
  • 渡米後1週間でアパートを探し、keikuboと一緒に暮らす
  • オフィスで開発を進めつつ、現地の日本人を中心に人脈を広げアドバイスをもらう
  • シリコンバレーの日本人コミュニティの小ささ、スタートアップのプレイヤーの少なさを実感する
  • シリコンバレー特化ではなく、日本も同時にアプローチすることを決める
  • ワールドカップをストリーミングでリアルタイムに見る。日本よりも時差も少なくPCで見れる環境は快適だった

7月

  • 2ヶ月間の滞在予定を1ヶ月変更して、早めに日本に帰国
  • 集中的に日本のVC10社程度にビジネスプランを紹介する
  • ソーシャルアプリの開発会社10社程度にサービス紹介しつつ現状の開発環境をヒアリングする。サービスの反応からコンセプトは間違っていないことがわかる
  • 外出が多いので仕事しやすいようにアカデミーヒルズの会員になる

8月

  • 引き続きVC、スタートアップを目指す人など紹介してもらう。またひとつ人脈が広がった
  • 資金調達の動きを具体化する
  • インキュベーション数社へのサービス紹介、投資交渉を行う

9月

  • 5年以上ぶりに歯医者に行く。やはり虫歯あり、歯石が溜まっていてしばらく通うことになる
  • JAWS-UGのLTに出てfluxflexの進捗を報告
  • JAWS-UGに出たことでRightScaleの座談会に出席。RightScaleへの直接パスが出来る
  • 前の職場の人主催のBBQに参加

10月

11月

  • シリコンバレーオフィスとのコミュニケーション、現地のCloud Expoを見に行くためシリコンバレーレに10日間ほど滞在
  • 現地でJTPAのギークサロンに参加。現地の日本人ネットワークも少し広がった
  • サービスプロモーションビデオの製作開始
  • Startup Dating でライトニングトークする。ホスティング業界の皆さんから良い反応を得る
  • 最初の資金調達の投資条件の基本合意

12月

  • シリーズAAの契約がすべて完了。最初の資金調達が完了する
  • 家族をねぎらう意味で叙々苑へ

こうして振り返ってみると年の初めにfluxflexをシリコンバレースタートアップとして立ち上げることを決めて、オフィスを構え、最初の資金調達までよく終えられたなぁと思う。飲みに行く機会をなくして、時間が有限であることを意識してfluxflexに使う時間をなるべく確保しようとした。その結果でもある。

なにせシリコンバレーでスタートアップとしてやるためには何をすればいいのか、情報は得ていてもよく分かっていなかった状態だった。経験がなかったので、色々迷ったり修正したりした部分は多々あった。だから決して効率は良く振る舞えたわけではなくて無駄が多かったと思う。まぁ、Y-Combinatorのような有名インキュベーターやシリコンバレーでの経験を持つメインターがいない状態だったので仕方がないと思っている。ただ、この非効率な体験はほんとうに貴重で重要なノウハウになったので、例えば2度目の起業以降迷うことなく生かすことができると確信している。

もうひとつ大きな財産としては人脈だろう。スタートアップを実際始めることでスタートアップに関連する起業家、インキュベーター、投資家、イベンター、ライター、BIGプレイヤーのキーマンのネットワークが新しくできた。今までの人脈よりもっとスタートアップ寄りのネットワークだ。また新しいフィールドがひらけたことがとても嬉しい。

そういえば、2009年のJTPAシリコンバレーカンファレンスから帰ってきて、何をしていこうか考えたときに、日本だけの範囲からシリコンバレーも含めた仕事仕方に変えていきたいとブログに書いていたことを思い出した。その目的に対してはある程度出来たかなと思っている。

2010年の歩みが順調かどうかは今の時点では結果が出ていないので何も評価できないけれども、実際勝負の年となる2011年につなげた年としては悪くはないと思う。2011年は実際結果が出る年になるので、また同じように振り返りをしていきたいと思う。