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回目と繰り返しながらでも成功を目指し続けることが重要だと思うので、なるべくリスクを抑えるための策を練っておいたほうがいいと思っている。

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

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

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、完了です

宣誓書の内容は？

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

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

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

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

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

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

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

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

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

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

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

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月

• Tech Crunch Japanにfluxflexを取材してもらい記事になる
• エンジェルを紹介してもらい、資金調達の具体的交渉に入る

11月

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

12月

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

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

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

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

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

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

実際にアメリカ法人の日本支店設立を自分でやってみたので、今後同じようなことをやってみようと思っている方の参考になれば。できるだけ、これさえ読めば申請出来る！という状態になることを目指します。

大きなフローは日本法人を作る時と同じだけども、ちょっと異なる部分もあるのでポイントを抑えられればと思います。基本的には事務処理なので、外部に委託しなくてもフローと書類が正しく守られれば個人で行うことが十分可能。

手続きの順番は以下のようになる。

1. 申請する準備をする
2. アメリカ大使館へ公証を受けに行く
3. 法務局へ登記する
4. 税務署に申請する
5. 都税事務所に申請する
   • 支店の住所を東京にしたので
6. 銀行口座を開設する

銀行口座開設は税務署の前に行っても可能。その方が登記簿の発行代が節約できる。詳しいことは追々。

あまり馴染みがないのが公証を受ける部分かと思う。ロジックとしては、

• 外国法人が主になるので日本の役所はその会社の情報が正しいか証明できない
• だからその会社のある本国(アメリカ)か日本国内ならアメリカ大使館で、この会社の申請内容は正しいですよ、という公証をしてもらう
• 公証の印を信じて法務局は登記手続き行う

ということのようだ。ロジックは理解できるけど実は公証を受ける時にはちゃんとチェックしていなかったりしていて、結構いい加減なところもあったりする。このあたりも追々伝えられれば。

最初に準備するものをあげておく。

• 印鑑を作る</p>
  • ハンコヤドットコムで会社設立3点セット￥16,800のやつにした
  • 2点セットもあるけど、念のため3点にした
• 日本支店をスタートさせる日を決める
  • 公証を受ける日の前になっていること
  • 日付の流れは以下のようになる
    1. 外国法人で日本支店をつくろうと決める
    2. 日本支店を開始した(公証を受ける前に始めてしまってOK)
       • この日付が法務局、税務署などの申請時にも記述する必要がる
    3. 各所に事後として申請する
• 宣誓供述書とその訳文を作る
  • アメリカ大使館での公証の説明時にサンプルを示します。

とりあえず、導入としては以上。フロー毎に詳細に説明出来ればと思います。

今回のシリコンバレー滞在のもうひとつの目的はJTPAのセミナーに参加することだった。2009年のJTPAカンファレンスには参加したものの、日常的なJTPAのイベント参加者と交流できていた訳でもなく、どんな人達がいるのか知りたかった。あとはシリコンバレーでの日本人コミュニティはSVJENとJTPAくらいでとても少なく、ネットワーキングしやすい日本人コミュニティに早めにリーチしておきたかったという思惑もある。SVJENは6月のネットワーキングパーティーに参加していた。

当日の様子はJTPAでも紹介されていて、Ustreamでも見ることが可能。

fluxflexで一緒にやっている id:keikubo も話して、fluxflexのサービス概要を紹介した。参加者の反応も気になったところ。これはなかなか反響が大きくサービスの方向性は間違っていないことがこの場でも分かった。今後日本でもサービスの紹介は進めていくので、色々な反応が聞ければと思う。

20代の彼らの話や質疑応答を通して感じたことは、「自分で決めて、自分で実現させる」というシンプルなことをやり通してきているし、その成功体験が彼らの自信になっているので生き生きしているように見えた。海外の大学に入るために自分で教授にアポを取ってアメリカを回ったり、スタンフォードに入るために教授の推薦を工面したり。自分で考えて行動してきてスタンフォードに入ってきている。

自分自身でリスクを取ってアプローチして手に入れる。実はこの経験ってやれているようでやれていないことだと思っている。自分が考える or 実行する前に誰かがやってくれる環境に囲まれやすいとも思う。本当に自分一人でどうするか考える、やることを決める、実行する。他の誰でもない自分自身で行うから実現したときの快感に似た喜びはすごく大きい。彼らはすでにその経験をあの若さで経験している。今後、何を創りだしていくかすごく楽しみに思えた。自分ももう少し早い段階でこんな経験をしていれば、、とも思うがそれは仕方が無いし現在大きなリスクを取ってスタートアップしているので、これはこれでよし。ただ、彼らの残された時間の多さが羨ましく感じる。ほんとうに羨ましい。

シリコンバレーにいる日本人で意外と多いのが日本人企業の駐在員。逆に現在スタートアップをしている日本人は数名程度だろう。企業に依存しながらシリコンバレーの地にいる人達には自らの意志で立っている彼らの姿はどう写ったのだろう。自分自身のリスクを取る振る舞いをし始められたら良いなぁと思った。

前向きなエネルギーをたくさんもらった。良い場だった。

以下は当日のメモ。

石綿整

• スタンフォード PhD Electrical Engineering
• 小学4年生 マリオ 物理興味持った
• 0/1の半導体を作った場所がシリコンバレーだった
• スタンフォードの教授がファウンダーになってる アイデアがあればすぐ会社作る
• 半導体の素材としてダイヤモンド注目 固体の中で一番熱が伝わりやすい、一番固い
• 電子源として使える Diamondoid
• 人工ダイヤモンドが作れれば安くすむよ
• スタンフォードは物理をサイエンスとして捉えるのが上手
• 夢は日本の教育と起業のギャップを埋めたい

郡司まりか

• 色々住む場所を点々としてきた
• Stanford University, Materials Science and Engineering Ph.D.課程所属
• 物理学の半導体材料を研究している
  • ナノテクという分野らしい
• ナノサイエンス 基礎研究、ナノテクノロジー 応用研究
• ムーアの法則
  • 60年以上の研究
  • 短期的 微細加工プロセス、オフ時の消費電力の問題
  • 長期的 新しい材料、構造で高集積化、高性能化
• ナノワイヤが面白い構造 縦に構造させる
• 赤血球が電気を取れるか 将来性のある分野

宮崎勇典

• 東大後、Stanford University, Chemical and Systems Biology Ph.D.課程所属
• 小学校までシンガポールとハワイ、最初は帰国子女
• タンパク質の研究している
• 60兆個ある、タミフルの薬のターゲットもタンパク質
• 酵素がないのがお酒が弱い
• 光るタンパク質を発見した いろんな色を出せる ノーベル賞
• タンパク質を制御する 形を変える
• 海外大学留学説明会に日本に行った 1月にも行く

クボケー

• 個人、中小企業、スタートアップがターゲット
• 無料からはじめられる
• fluxflexがあらかじめ設定しておく
• できるだけユーザがサーバのこと考えなくていい
• 4つのサイクル
• 開発はテスト自動的にWebサービス用のDropboxみたいな感じ
• 運営はメイン
• ノウハウのいるサーバ構造が構築されていて、気にしなくて良い
• テストユーザいれているよ

船木信宏

• 2009年9月会社作った SmashBooth, Inc.
• Co-founder 田畑さん
• 「寄付」crowdfundingという単語があるらしい
• 寄付ほしい人と、払いたい人をマッチングさせる
• たくさんの人から小額をもらう
• 今いろいろやっている モバイルでできるように
• 余ったマイレージを使えないか画策中
• Senzoo.com

近藤誠

• Evernote
• 最近の100万人 83日で達成
• 日本人ダントツで第2位 18％
• スタッフ40名

QA

• 1. 今の研究分野、事業領域にしたか？</p>
  • アメリカに来たかった、スタンフォードは共同事業が多いから、人は手にしたものには、誰も提供していないインフラのサービスだから
• 2. 苦労は？
  • こっちに来て奨学金を得る苦労があった。やりがいがある。スタンフォードの中でもダイヤモンドを使っているのは自分だけだった
  • 楽しくやりがいを持って4年きた。意味のないミーティングはない
  • あまり感じない。自分がやりたいことをやってきた。動いていたら誰かが助けてくれた。
  • ビザに苦労した
• 3. チームづくりの苦労？
  • インフラのスキルとソフトウエアの勘所が分かる人 経験がある人が必要だった
  • 質問攻めにして、プロトタイプを見せたりして意気投合した
• 4. 日本に戻ったら何をしたい、何を変えたい
  • すごく後だけど教育に関わりたい
  • ロールモデルになれれば
• 5. 問題、課題が一番難しい、かつ解決できたこと 成功体験
  • スタンフォードに来るために1回のプレゼンで、国際学会で論文出してかなった</p>
    • でも楽しかった、日本にいたらできなかった。自分で決めてやって仕留めた快感
  • 成果を出して楽しんだ
  • 大学の情報を得て、アメリカ1週間で教授に会った、実際かなった
  • 学費が大きかった、工面できて卒業できたこと
  • ビザ
• 6. アメリカ来てみて思ったこと
  • ディスカッションする相手があまりいない日本、アメリカはみんなでディスカッションする
  • 感覚的に思っていたことが実現した
  • 上下関係がある、ちゃんとした英語を使わないと目上の人に対して
  • バイオロジーは東大のほうが設備が良い
  • 思ったよりもアメリカは安全
  • 人物金が揃っていると思っていたけど、ネットワークに入っていく厳しさ
• 7. 日本人に対してどう思いますか
  • 行動力がない、やりたいことを主張して行動する人が少ない
  • 安定志向に走らないでほしい、リスクが高い事はしない
  • 自分の人生に責任をもってほしい、どうなっても自分が生きていくと思う、ハッピーに生きて行くこと
  • 日本人ですごい人多いのに、シリコンバレーのスタートアップファウンダーが少なくて、待ってます

2週間ほど久しぶりにシリコンバレーに行ってきた訳ですが、その目的の一つが本場のCLOUD EXPOを見ることだった。

まだ知らないクラウドサービスがあるかどうか、またfluxflexと同じようなサービスがあるかどうか、最新の情報がそこに行けばあると思っていた。RightScale User Conference に申し込むとCLOUD EXPOの参加費がタダになるということで、こちらもついでに見てみようという感じだった。

で、結果的にどうだったかというと、CLOUD EXPOは非常に残念な場だった。むしろRightScaleの話のほうが実践的で内容は良かった。

CLOUD EXPO はクラウド上で展開しているサービスの見本市というよりかは、完全にエンタープライズを意識したITベンダーの宣伝の場になっていた。各セッションのスピーカーはスポンサー企業の担当者で、展示物もハードウエアもあり、自社のソフトウエアもあり、「クラウドにかこつけた」キーワードで今まで通りの自社製品のアピールをしている。

スポンサー企業のたくさんお金を出している上位を見ると大手ITベンダーであり、クライド？と思ってしまうようなメンツだ。

アメリカらしいちょっと変わったセッションといえば、スタートアップがクライドを活用するための指南、SaaSスタートアップを束ねるようなコミュニティの紹介というところだろうか。ただ、これらのセッションもスタートアップを顧客と狙うコンサルタントが話していて、スタートアップが自ら語る生きた情報ではない。

基本的には日本のよくあるクラウドセミナーでITベンダーがアピールする傾向とまったく同じなことが分かった。その次の週に日本で行われたCLOUD EXPOのほうが、さくらの新サービス発表とかニフティクラウドにAWSの方が飛び入り参加したりして、実際見ていないがこっちのほうが面白そうに思えた。展示に関しても、USは広めの会議室1つだったので幕張の展示面積のほうがずっと広いしたくさん展示されている。

気になるAmazonは一番下のランクのスポンサーで、配布資料もWebに乗せているセキュリティホワイトペーパーを印刷した物、という気合のなさがまる分かりという感じだった。

CLOUD EXPOと言いつつ、エンタープライズに完全に絞ったイベントだということが分かった。次回は行くことはないだろう。

一方、RightScale User Conferenceはユーザ向けに自社サービスの活用法などを実践的に紹介していた。

しかし、DBのスケーリングの良い答えはRightScaleでも持っていないのだなぁ。悩ましい。。。

こちらの方のメモを以下に記しておく。

RightScale Case Studies

RightScale を使っている4社が自ら説明

• American Gril</p>
  • 子供向け人形、着替えなどの販売
  • オンラインもやっている Jun 2010 スタート アバター使う
  • Cloudへ移行した パフォーマンスを測って選定したよ
  • 1日で移行した implemented
  • 2500%キャパシティ increased
  • すでに登録済みのユーザアプリケーションは1ヶ月後に移行した
    • 1000%キャパシティ increased
  • 構成 : php CDN はAkamai
    • フロントは image, web array , re gstry jetty arrayなど
  • 今後 much more work ahead
    • RightScaleでの教育を受けたい DEV, TEST, LOAD
    • implement ability to auto-scale # 現状オートスケールは使ってないみたい
• WATCHMEN (AltEgo)
  • MMO iPhone Appらしい
  • 3DバーチャルなMMOぽい
  • 25日で 沢山のリクエストが来たよ、登録数ではないけど
• なぜRightScale?
  • Fail Forward</p>
    • Nominalizes downtime, Unix Script
    • RIghtScale Server Templatesすごくよいよ
      • テストのためのたくさんのサーバの開発環境を用意
      • 地域に関係なく利用出来る
      • RightScaleは早いレスポンスがよい
• Associated Press
  • 世界中にニュース配信する
  • 3700従業員、300ヶ所のロケーション
  • ニュースにとってのチャレンジは第2のマーケットつくる
  • 色々なpublisherにライセンスニュースを送ること
  • コンテンツのトラッキング、ニュースコンテンツのマネージメントとモニタリング
  • 今後 コンテンツライセンスの実行、Audience and engagement services
  • Associated Pressから hNews を配信してトラッキングして、Real time rollup,Mapに描いて、Data Warehouse に食わせて News Registry として保存する
    • AWSはEC2, S3, CloudFront, CloudWatch
    • AzureはTables, Queues, SQL Azure
    • data ware house は自社、private cloud で開発、QA、Testした
    • RightScaleのManagemnt UI使った。depoy時間が少ない、深い部分のマネージが出来る、コスト削減になった
    • アクセス解析、アメリカ東側中心にアクセスあり
• Pogo.com
  • Socal Gameづくり、Facebook, iPhone, Yahoo!Gamesなど
  • Free 100以上作っている、$5-30/m くらいのゲーム40種
  • 構成 : AWS base でREST/jSON.HTTPSのフロントとSimpleDB, EBS, RDB, SQS, S3の連携 ＋ EA Hosted Oracle RAC
  • テストが終わってからのデプロイの自動化が問題だった
    • installerを書いた
    • Nexus から Automated Buikds(Hudson)つかって、Debian Repository(Jetty, JDK含む)でパッケージ化して、Ubuntu EC2にデプロイする流れ
    • RightScaleのモニタリング使えるよ、いろいろな言語のスクリプトが使える
    • Webnorogukara Syslogで集めて SDBにHadoopかましたろを置く
    • S3におく そこから HIVEと連携する
    • デプロイがダウンタイムなく早くなった、ロールバックが早くなった
• Web Filings
  • SECレポートのためのソリューションを提供
  • GAEの環境ではいくつかのユーザのアプリが動かない
  • RightScaleのpre-built script パッケージからはじめられる
  • スケーリングのパラメータも設定できる
  • ちょっと問題あったけど今はRightScaleのUbuntu imageでcheck outしている
    • tweak scriptを使っている
  • rebuild と redeploy が12時間以内で実現できるようになった
  • In-HouseするよりもCloud使って色々できるようになった

RightScale Non-MySQL

codeFuturesというDBのShardingの製品を持つ会社の説明

• shard の説明より、Each partition forms part of a shard
• The key to Database Sharding… Share Nothing ができる
• C0001のCはCustomerなのか？
• ASとDBの間にproxy をはさむ
• EC2上でスケーラブルに増やしたらリニアに書き込みパフォーマンスがあがった
• Sharding work: No contention between servers
• Sharding を利用した場合、CPUの利用率が上がって、wait が減ったよ
• Database Typeの比較 MySQL, Postgess, Oracle vs NoSQL(in memory0
• NoSQLでShardingを動かすためには S2にkey,objectをputして、S3からgetする
  • # ってことはS2,S3で同じデータを持てているということ？
  • MySQLでも同じ構成
• Cross-Shardの構成
  • Client側でAgregateしている、Go Fishの命令を出す</p>
    • 各サーバにブロードキャストする
• Sharidingは2台あればfailoverに対応できる、メモリは3つのDBががあること
• S1とS2を1つにすることもできる Elastic shards
• 現在はMySQLのみでできる、将来的にはPostgreSQL, NoSQL, Caching対応

RightScale Web Scaling

Webのサーバ構成でのProxy, App, DBそれぞれのスケーリング方法紹介

• バランシングにてELBはTCPレベルのみ(古い情報であることを断っている)
• HAProxy + Apache もある
• Recommendationは Minimum of two load balancers
  • 異なる Availability zone に置くこと
  • m1.largeを使うと良いパフォーマンスをした
• Application Server Tier
  • (RightScaleの)Autoscaling使うことを想定
  • 自動化してcodeを持ってくる仕組みが前提
  • Triggers で Custom で connections と Application specific metricsがある
    • instance size m1.largeが良い選択肢
    • m1.smallはtestにいいよ
• Caching Tier
  • databaseへのアクセスを減らす
  • PHP + memcached の組みわせはいいよ
  • メモリサイズによってインスタンスサイズが決まる
  • 手動でのスケーリングになる
    • TTLを気にする
    • memcached
• DB Tire
  • slaveのスケールの時にMySQL Proxyを使う構成を紹介
  • マルチマスターはライトスケールはお勧めしない
  • NoSQLは一部のユーザで使っている
    • SDBとか
• DBのスケーリングのおすすめはない # あらあら。。。
• It depends!だそうな