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

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!だそうな

「外を知る」という目的で国内のクラウドイベント技評さんのG-CLOUDに行ってみた。

いろいろな観点で気づいたことがあったので、大項目に分けつつ書いてみたいと思う。

G-CLOUDというイベントについて

おそらく技評が行う初めてのクラウド系イベントだったのだと思うけど、プログラムの組み方と参加者の層を見るとエンタープライズ色が強めかなと思った。ここで言う「エンタープライズ」とは、

• 一言で言えばSIな方々
• コンシューマ向けのサービス提供をしていない
• 請負でシステムを開発もしくは提供する
• システム利用者は中大規模の国内企業
• システムは国内利用のみ、ワールドワイドでの利用は想定していない

という意味で使っている。

プログラムは「ソーシャルクラウドトラック」「エンタープライズクラウドトラック」と分かれていたが、ソーシャルクラウドトラックでもエンタープライズ向けのサービス紹介があった。

会場やイベント運用について

以下は気づいたこと。反面教師として自分が開催側になった時の教訓にしようと思う。

• 会場はさほど広くなく、でも埋まっていなかった。なぜだろう？
• ネット環境がなかったのはNG。この手のイベントはもう無線LANの環境は当然と思ったほうがいい。
  • 地下の会場だったのでe-mobileは入らず
• 下記の理由で、twitterのハッシュタグの利用が効果的でなくライブ感に欠けた
  • ネット環境が用意されていない。携帯からとりあえずポストするだけ。タグをリアルタイムに追いにくい
  • Webには記載してあるが、会場で配布される資料など目立つ場所にハッシュタグ情報が表示されていない
  • 実際、ポストされたハッシュタグの数が少ない
• 必ず質問時間を設けるべき。話し終わって終了のセクションがあった。
• スピーカーにスポットライトを当て、聞く側が暗くて、会場の反応や一体感がなかった
  • 会場のホテルのやり方なのだろうけど、会場がフラットな関係になっていないと聞く側も聞かなくなる。

5年以上前のやり方を踏襲しているだけなのがすごく気になったので、是非改善して欲しいと思った。

国内のクラウドサービスの進捗具合

フリービットとGMOホスティング＆セキュリティの実際聞けた。IIJと富士通研究所は資料のみ

• やっていることは「仮想サーバの時間貸し」サービス
• コストが安いことをみんなアピールしていた
  • コストはみんな安い方向に走るので、それ以外の特徴が知りたかった
  • フリービットはVMwareを採用していると言っていたが、ライセンス費用で安さは追求しにくいはず
• フリービット
  • クラウド＋オプショナルなマネージメントサービスというのは、クラウドの理念から考えると矛盾していると思った</p>
    • 本来はマネージしないことを求めるから雲の中に委ねるはず
  • リブートが必要だけど、ユーザがスケールアップできるのはGood
• GMO
  • 初期費と月額固定的な料金体系はナンセンス
  • まだ開発中と言っていたオートスケーリングの内容が気になる。特にどのレイヤまでフォローするのか知りたい
  • CDNの連携がそんなにメリットがあるとは思えなかった
    • CDNに置けるのは静的なファイルだけで、動的に生成するページは補えないから。でも、そこも扱えるのなら素晴らしいことだと思うけど、できるのか？
• 話は聞けなかったが、IIJの資料にRightScaleのテンプレートのようなWebサーバ、MySQLサーバが選べるメニューがあったが、MySQLサーバの接続先情報とか自動的に付与してくれるのかとか、詳細が気になった。

国内でクラウドサービスの提供者はサービスが始まったばかりで、未熟な機能・考え方にとどまっていると感じた。機能も専用レンタルサーバをすぐ貸出しますよ。というイメージ程度でこれをクラウドサービスと言ってしまってはクラウドの理念が腐るかと思う。今後どういう差別化と機能拡張をしていくか、聞いてみたいところだった。これが描けないと価格の叩き合いにのまれてつぶれるだけだと思う。

GREE, Amazon+利用者の話が魅力的だった

GREEのCTO藤本さんの話は、Webサービス提供者として、クラウドに何を期待しているか、自ら取り組む場合どう考えているかが聞けた。

気になっていたのは、日本で規模の大きいインフラをすでに持って運用しているポジションにいる人が、クラウドに対してどう思っているかだった。なぜかというと、Zyngaみたいに大きいけれどEC2使っているケースはまだ日本ではなく、自前でサーバ買ってデータセンタで動かしている方がほとんどで、そもそもクラウドを利用したいのか、どの部分がクリアできれば実際移行の可能性が出てくるのかが知りたかったから。

「Webサービス開発者がサービスだけに集中できるサービスプラットフォーム」が理想で、これが実現できたら素晴らしいと話されていた。PaaSのレイヤに属し、自動セットアップやスケーラブルであることのようだ。

これはニヤリだった。まさにfluxflexはそういうサービスを実現しようとしているから。GREEにどんなシステムがあるかは不明だし、アプリケーションがたくさん複雑につながると困ってしまうのだけど、コンセプトはGREEの規模であってもマッチすることが確認できた。

あと、GREEがAmazonやGAEのようなクラウドサービスを提供する可能性としては、現状を聞く限り5年以上先 or やらない感じがした。

やはり、充実した内容のプレゼンだったのはAmazonだった。クラウドサービスと名乗る他社との差は圧倒的だった。

• 機能の豊富さ: EC2/S3だけではないというアピールをちゃんとしていた
• 取り組み方: 日本語ブログやStartup Challenge
• 実績: 多くのサービスを海外と日本でもたくさんあるよ
• 2つの事例: AWSの機能を利用しつつ、それなりの規模で運用し続けている。運用できる証拠を示した
  • モバツイはAutoScalingは使ってなさそうだった。gumiは自前で仕組みを持っていたはず。

(もし日本でEC2が利用出来るようになるとしてw)今後日本のユーザが増えるのは必然のように思えた。すでに利用されているモバツイ、gumiの話は確かな実績だし、まだそこに到達出来ていない人には何か次元の違う話のように感じただろう。話をした2名とエンタープライズな方々とはユーザドメインやビジネスのスタンスも異なるので、その差がそのままクラウドの利用実績につながっているようで、この比較に気づいたことはすごく面白かった。

まとめ

国内でもクラウドサービスが提供されたという状況だが、AWSの優位はまったく変わらない。国内クラウドがAWSのレベルになるにはあと、3年以上はかかる or そこまで目指さないのではないかと思う。

ユーザを昔からの付き合いという、旧石器時代的な要素だけでとどめることはもうなくなっているので、エンタープライズな方向けだとはいえ、国内クラウドサービスをやっています、と言っている方々は本気で考えアクションしないと、足元すくわれちゃうなぁと感じたイベントでしたと。

gumiの国光さんにfluxflexを紹介しに行ったのだけど、後半に話したことが以前考えたことと重なって再考してみたので、書いてみる。

ソーシャルアプリはいろいろな種類のアプリケーションが提供されているが、やはりゲームが最も利用されていそうだし実質、「ソーシャルアプリ＝カジュアルゲーム」になりつつあるんだろう。

特徴としては、

• すぐ始められる
• 題材が誰もが知っている一般的なもの
  • ペット、車、街、農場など
• ミッションが単純

というところだろうか。なぜそういう傾向になるのかと思うと、基本的に無料のフリーミアムのモデルだからだろう。

1. 基本フリーにする
2. できるだけ多くのユーザを集める
3. そのうち数%のユーザが課金対象となって払う
4. サービスとしては売上があがり成り立つ

という流れでビジネスとして成り立つ。たくさんのユーザを集める必要が前提としてあるからカジュアルになりたがる。

この発想でビジネスとして成り立ってるタイトルもあるが、オリジナリティは低く誰もが作れるレベルになり差別化しにくくなる。実際、サンシャイン牧場とZyngaのFarmVilleの違いはほとんど無いだろう。

そこで考えたいのが「ゲーム性」という視点。ゲーム性が高いというのは、

• 前提とする背景やストーリーが複雑</p>
  • 途中で変わったりもする
• ミッションが複雑で複数あったりする
• 難しさがある
• レアなケースがあって、その度合が深い
  • レアなものを得るにはすごい困難さがある
• すべてをクリアするには相当な時間と努力が必要

あたりとすると、ソーシャルアプリの流行っているものはゲーム性は低いと言える。

ゲーム性は「お金を払う価値があるかどうか」「ユーザがゲームの世界観にはまってくれるかどうか」が目的で、これはコンソールゲームやオンラインゲームでユーザがお金を払うことを前提としたビジネスで求められている。

ここにはネットが普及する前から長いゲームの歴史があって、ゲーム会社はゲーム性の高いものを求めて企画を練りタイトルを世に出してきた。ゲーム会社がソーシャルアプリに入ってこないのは開発プラットフォームの違いもあるだろうけど、そんなカジュアルなものなんて作っていられない。と思っている面が強いからではと思う。

それでは、本当にソーシャルアプリはカジュアルでないといけないのか。と考えるとそれはNOだと思う。たくさんのアプリケーションの中でカジュアルゲームにユーザを集めるのはゲーム性に差がないとすると、その会社の資金力がものをいってくる。資金力の大きな相手に対向するには、ゲームそのもので純粋に勝負するしかなくなってくる。今のソーシャルアプリはプレイヤーがそろっていない状態なので、先行逃げきり型でカジュアルゲームをヒットさせて売り抜けたウノウの例もあるけれども、今後はゲームそのものの面白さでユーザに判断されるフェーズに入るのだろうと思う。

これは健全な状態だし、すでにiPhoneアプリは良質なアプリが上位に入る健全な状態になっていると思う。

そんな発想でゲーム作りのノウハウがあるゲーム会社が、ゲーム性の高いものをソーシャルアプリとして本気で入ってくると今のプレイヤーの相関図も結構変わってきて面白い状態になるのかなぁ、そうなったほうがユーザにとっても楽しいのかなぁと思っている。フリーミアムにする必要はなく、一部の熱狂的なユーザを作り出せれば収益としては十分なので、ゲーム性とオリジナリティの高いものを求めて良い。

コンソールゲーム市場が減少傾向に入った今、ゲーム会社はゲーム性の高いものをソーシャルアプリに出してほしいなと個人的には思う。ゲーム会社のノウハウはそれだけ深く、Webサービスとは異なる体制が取れているので、もっと色々なプラットフォームの中で存在感を発揮できるのではと思っている。

こんなことを考えた根っこには、単純にもっと面白いゲームはソーシャルアプリにないのかなと思ったことと、それを変えていけるのはすでにノウハウと実績を積んできたゲーム会社だけなんじゃないかと思ったことがきっかけで、あまり他に書いている人がいないので言ってみた。