uedayo's diary

2011年11月29日（火）にラフォーレミュージアム六本木で行われたTechCrunch Tokyo2011に参加してきました。

今回は、非常に優秀なリアルタイムまとめがあるので、カンファレンス、スタートアップバトルの内容についてはこちらを参照していただくのが良いと思います。

TechCrunch Tokyo2011実況まとめ #tctokyo [NAVER まとめ]

会場内個別ブースにおいて個人的に気になったサービスを以下に列挙します。

remembAR

http://remembar.me/

デモブースでしっかり確認できなかったが、後から聞いた話によると面白いサービスらしい。今後、サービス開始後に再確認

facematch

http://facematch.jp/

Hot or Not のFB版という印象。

Twizard

http://twizard.net/

twitterAPIで本家の画面+アルファを再現

RingReef

http://ringreef.com/

簡単にReef(サークル)を作成する事ができるのがウリのGMS

NodeNinja

https://node-ninja.com/

Node.jsのPaaSを3ヶ月無料で利用できる

個人的感想を幾つか書きたいと思います。

Webサービスのライバルが増えてきているなと感じました。

具体的には以下のとおりです。

1)VCの援助による低資本でのスタートアップ

2)非Web、IT企業のサービスの多角化

3)高校生によるサービスの出現

1) については、セッションの中で何度も触れられているとおり、スタートアップ資金よりも

・どのような問題を解決するのか？

・どのようなチームで臨むのか？

・現時点で考えうる最善のソリューション(できれば。上２つのほうが重要)

がしっかりしていることが求められる風潮になってきています。そのため、今までは資金面で諦めていた人々もどんどんチャレンジするようになってきているわけです。

2) については、私の友人についての話をさせて頂きます。偶然会場でWeb、ITとは直接関係ない企業の友人に会いました。彼の話を聞くと、サービスの多角化のため社内でアイデア出しを行なっているとのこと。本日のスタートアップバトルに出てきたアイデアは案として挙がった。ただ、マネタイズのビジョンが描けないということで、見送られたとのことです。彼曰く、「考えた方向性が間違っていなかった。スタートアップの心構えについて知ることができた。」ということで、非常に有意義だったようです。

3) はもちろん、高校生であるにもかかわらず、見事KDDI 賞を受賞した engraph / 高橋さんについて。学業と両立して一人で開発をされたという継続の力は本当に見習いたいです。私が怖くなったのは、「実はWebサービスの開発って、ひとりでも、学生でも、本業ではなくてもできちゃうんだよー！」ということが、世の中に広く知れ渡ることです。開発のための環境が誰でも非常に安価で構築できる、開発に必要な情報が誰でも手に入るようになった今、今まで以上にたくさんの中高大学生がWebサービスの土俵に上がってくることは必至でしょう。現状は、個人で開発をしたり、たまたま隣にいた友人とチームで開発を行なっている彼らも、いずれスキルの高い物同士が出会い企画・開発を行うことが当たり前になるでしょう。高校生でなくても、チームメンバーののマッチングは進むでしょう。nanaを開発された文原さんは、一人でアイデアを思いついたが自分一人ではコーティングを行えない。そこで、twitterでそれまで一度も会ったことない開発者を集めてサービスを作っているとのこと。会社などの組織のつながりを元にチームでの企画・開発を行なっている我々のアドバンテージを保っていられるのもあと僅かなのかもしれません。もちろん学生でもアイデアがあればファンドから出資を受けることが出来る世の中に移行していくわけです。発想力が豊かで、まとまった時間がとれる彼らと真っ向勝負になったときに、我々は何を武器にしていけばいいのでしょうか。

以上、本カンファレンスの本質と外れた内容について書かせて頂きました。とにかく、大事な事はサービスのアイデアを相手に応じて適切に伝えられること。開発者であっても一人ひとりがピッチを使いこなせるように、訓練していきたいと思います。

先日日本でもCSPO研修を行ったJeffの資料で気になった部分をメモ

http://www.slideshare.net/nashjain/user-story-mapping

p.5

ユーザストーリは多目的

ユーザのニーズ
プロダクトの詳細
プランニングの材料
会話のきっかけ
会話を引き伸ばす仕組み

p.6

まず始めにタイトル
～として、～したい、それは～のためだ ※あくまでもテンプレート。全てのストオーリーをこのように書く必要はない
メモ、仕様、スケッチを追記
受け入れ条件/基準

p.9

boundary objects が何を目的としているのかが分からない。各サービスにおいて個々にfixされていくということだろうか？

p.14

ユーザストーリマッピングは体系化し、優先順位をつけるアプローチ

uedayo's diary

Webエンジニアによるブログです。Scrum, XPなどのフレームワークを実践中。

SQLが重い場合の対処

【メモ】ソーシャルアドレス帳のUIなど

TechCrunch Tokyo2011 に参加してきました。

Jeff Patton の User Story Mapping 資料