サービスを本当によいものにするには、ユーザからの正直なフィードバックをコンスタントにもらうのがかかせない。とにかく、全方位でユーザの意見をくみ取りやすい仕組みを作るのが重要だと思う。


もちろん、ユーザの意見をそのまま全部反映させようとすると、ブレブレの最悪なモノが出来上がるので、意見を聞いた上で、どうするかは自分で決めないといけない。


まあ、上記の話は前提として、いかにフィードバックをもらいやすくするかをよく悩んでるので、それについて試してる事も含めて書こうと思う。


なんで、これについて書こうと思ったかというと、“自分がボスの時にどうやったら意見してもらうか”という、ハーバードビジネスレビューの記事がもの凄くよいなあと思ったからである。


原文は英語だけど、サービスを作る人なら面白いと思うので、オススメ。サービス開発者はボスというより、ユーザより下の立場な感じではあるけど。

ネガティブな意見は言いにくい

原文では、部下はボスに正直な気持ちを言いにくいことをまず認識しろと書いている。


サービスのユーザの場合、ボスと部下じゃないので、もう少し言いやすいけれど、それでも人間誰しもネガティブな意見は言いにくいもんだ。


ジョブズみたいに相手の気持ちおかまいなしに、ズバズバ言ってくれる人なんてまずいないと思う。


原文では、”意見する側の恐怖を認識しろ”と書いている。


恐怖とか言うと、大げさかと思うかもしれないけど、この認識は本当に大切だと思う。例をあげると、僕はサービスにたいしてなんか言いたい事があっても、以下のような心理状況になる。

“ここが使いにくいけど、Twitter上で開発チームに使いにくいとか言ったら相手が気分悪くするんじゃないか心配だ。Twitterは匿名じゃないし。。やめとこ。。”

“ここが使いにくいというか、よくわからないけど、単純に自分が使い方を理解してないだけかもしれない。偉そうに意見して自分のバカをさらけ出すのが嫌だ。。黙っとこ。。”

“このサービスを作ってる人は知り合いだから、あんまネガティブな事言いにくいなあ。。波風立てないでおこう。。”

まあ、こんな感じでネガティブな事ってのは人間誰しも言いにくい。でも、ネガティブな意見こそが価値があるんですよ！

フィードバックなんてめんどくさい

例えば、このサービスはこういう理由で使うの辞めたとか、ここが分からず使うの諦めた、とかいう意見は貴重度マックスだ。


でも、こういう人達はそもそもめんどいから意見を届けようとは思ってくれない。


こんな状況がよくある。

“このサービス、ここが使いにくいな。横に開発者がぼけーっと突っ立ってたら意見言うけど、わざわざメールするほどでもないや。どこに言えばいいかも調べるのめんどいし。。”

“このサービスのここを改善して欲しい。ぜひ意見を届けたいけど、Twitterアカウントも、ご意見ボックスも簡単に見つからないな。めんどくさいから諦めよう。”

“そもそも文章書くのがめんどくさいわ。”

あと、サービスを好きになってくれてる人は、改善要望とかくれやすいけど、一瞬使ってダメだと判断した人はわざわざ時間使って意見くれないし。


こういう悩みがあった上で、いろいろと施策を書いてみる。

頻繁に、意見を求める

自分からは意見する気はないけど、きっかけがあればフィードバックしてもいいかなという場合は多いはずだ。


なので、コンスタントにチャンスがあれば、ウザくない程度に意見をこちらから聞くのが重要だと思う。


Parse.comという素晴らしいサービスがあるんだけど、最近、突然サポートチームからこういう感じのメールが来た。

“カスタマー様へ、もし何か不満や要望があれば、私 ~がぜひご意見聞きたいので、メールでも、電話でもいつでもしてくださいね。よろしく。”

最後には、電話番号も入ってて、本当に電話かけていろいろ話そうかなって気持ちになった。


さっき思いついたのは、なんかスクリプトでも組んで、定期的にTwitterの公式アカウントで、”サービスについてのご意見あれば、遠慮なく教えてください”みたいなのをつぶやくといいかも。


ただ、この時重要なのが、ウザくならない程度というさじ加減で、ここが難しい。


例えば、Twitterでエゴサーチして、自分のサービスの意見を話してるユーザに突然Replyで “僕達のサービス使ってくれてありがとう！なにかあればいつでもフィードバックしてね！”　みたいに割り込んでも、ウザいと思われるだろう。


メールも、興味ない人にとってはスパムだったりと、タイミングがとても難しい。


さらに、解約時にフィードバックくださいフォームとかよく見るけど、あの瞬間は一瞬でも速くこの作業を終わらせたいと思っているから、いつも僕はでたらめにフォームをチェックしてサブミットする。

あそこの数字で統計とっても意味ない危険性がある。

意見しやすい状況を作る

ここは本当に重要だと思う。例えば、サポートメールはこちらと書かれている無味乾燥なサポートページだと、ちょっと意見を送りにくい。


でも、

“ご意見は全部読んでます。すごくタメになるので、ネガティブな意見でも遠慮なくお願いします。”

とか文章がついてると、フィードバックを送りやすいと思ってる。


また、例えば、こういうふうに書いてくださいと例を表示するといいのではないかと個人的に思ってる。

“(例) ~で戸惑った。。 ~が使いにくい。~が不満。など、ご気軽にご意見お願いします。”　

みたいな感じで。


ところが、僕はiPhoneアプリを作っているけど、実際にこういう文章をSettings画面にずらずら書きすぎると、アプリのインターフェイスが汚くなって、全体のデザインが悪くなるという欠点がある。


本当に難しい。。


後は、クックパッドのご意見ボックスみたいに、匿名で気軽に送れるとよいと思う。Webサービスだと、oLarkという素晴らしいチャット設置ツールがある。


oLarkを設置してると、たまにチャットが突然くるので、これでLisgoのHPを見たユーザがどういう疑問を持つかをかなり学べた。
しかし、トップページに設置すると、デザインが悪くなるという欠点もある。

あとは、意見をもらった時に、行間を読むとか、どういうふうに聞くべきかとか、いろいろ考えて試行錯誤してるので、まだまだ書く事があるのだけど、長くなるので、このへんで終わる。

この記事を読んで、いや、俺は逆にこう思うんだよね、とか。こうしてるよ、とかあれば、ぜひTwitter @umekun123 に意見ください。

本日、ゼロベースの不勉強会という、本をつまみに酔っぱらいながら語るという面白い集まりがある。


普段は、デザインやら、哲学やら、エロスやら、情報社会やら、いろいろやってるみたいなのだけど、今回のお題の本が「新しい市場の作り方」という本。


これは、かなり面白い集まりで、今夜は僕も不勉強会に参加するので、行く前に感想を書こうと思う。


くくりとしては、経営学の本。経営学の本っていい本もあるけど、ケーススタディーばっかりだったり、後付け感が多かったりと、よくバカにされがちだ。


しかし、この本はよかった！スタートアップとか、新規事業、まだ世の中であまりなかったサービスを作ろうとしている人は必見だと思う！


特によいと思う箇所は、2章と３章。さらに、この本は読みやすくて分かりやすい。

問題は発明の対象である

この本で印象的だった部分がここだ！問題とは発見するものではなく、発明するものである。


うーむ、こういう風には今まで考えてなかった。。


ようは、UXリサーチとか顧客インタビューとかが今は流行りだけど、ユーザを観察して、ユーザが困っている部分を発見してその問題を解決するサービスを作るというイメージが漠然とあったんですよ。


ただ、著者によれば、今までになかったサービスや製品が解決する問題は、現時点でユーザが問題だと思っていなかったり、それを普通に説明しても「特に問題だと思ってないし、困ってないわ。」と言われるものだと書いている。


なるほど、確かに、そうかもしれない。


人間だれしも、新しい生活スタイルや、新しいものを使い初めて始めて新しい不満が出てくるもんだと思う。


本に出てくる例だと、水泳の時かぶる水泳キャップというものを使うのは日本のみで、そもそも水泳キャップがないことを誰も不便だとは思ってなかったらしい。


水泳キャップを考えた経営者が、学校のプールの時間に、水泳キャップがあるといかに便利か、生徒の識別にも役立つとか、いろいろ啓蒙して、今では水泳キャップを使うのは当たり前の文化になったと。

正しさを探しに行くな

問題を発見の対象だという錯覚にとらわれると、ひたすら外界に答えを探してしまう。


そうではなくて、新しいサービス、新しい市場というものは、えてして、事業者がこういう世界になったらいいなという妄想から始まり、その妄想世界が素晴らしいんだと啓蒙して、現実にしてしまうというプロセスが必要らしい。


確かに、iPadが出た時なんて、批評家達からはさんざん言われてたなあ。ノートパソコンとしても中途半端だし、モバイルとしても使えないから、これは誰も必要としてないですわと。


そういや、ジョブズは新しい生活スタイルを発表会で、ソファーに座りながらiPadを使うことでイメージしやすいようにしてた。


僕も、iPadが出る前はそこまでタブレットというものに興味がなかったし、別にレッツノートで満足だわと思ってた気がする。だって、タブレットではこれができない、あれもできないとし、みたいな感じで。


しかし、iPadが出るとそのよさがわかり、寝ながら読みたいけどちょっと重いなあっていう新しい問題が出来上がり、iPadMiniでついに僕の欲しいものが実現した！


余談だけど、まあ、時代の変化によって出て来た、一定数の人が問題だと認識しているけど、誰もまだ解決できてないというモノもある。


既知の問題が、新しい技術で解決できるようになったとか、時代の変化で新しい問題が出て来たとか。


こういうユーザが認識できてる問題はやっぱ、やりやすいのはありますよね。ただ、その分、競争も凄く激しくなるだろうけど。


まあ話を戻すと、まずユーザが問題を認識して、それを解決するという順番が全てではないというのが大切と。

新しい文化を作る

この本で象徴的なのが、たいていの新サービスなんて誰も理解してくれない事業者の妄想から始まるんだから、新しい文化を作る働きかけが重要だということ。


そのためには、技術だけが優れてても意味はないと書いてて、そのサービスや製品の価値を理解してもらえるようにしないといけないと書いている。


これは、すごく難しいよなあ。例えば、Lisgoだと、新しい読書スタイルを提案するんだ！ということが重要なんだけど、これは結構大変だ。


でも、この本を読んで僕は啓蒙活動のやる気が出たので、こうやって使うんですよっていう動画を素人くさくても作って、いろいろなユースケースを提案しようかと思う。


そういう意味で、新しいサービスって最初にそのサービスのよさを分かってくれて、周りに啓蒙してくるユーザってめっちゃ大切ですよね。文化を広めてくれるエバンジェリストというか。


例えば、エバーノートがこういう使い方すれば便利だ！みたいにブログを書いてくれるユーザとか、これいいよって友達に薦めてくれる人とか。


こういうユーザが勝手に広めてくれるような仕掛けを製品に組み込むのが重要で（最近流行のグロースハッキング的な）、それは、本当にサービスを愛してもらった上での行動ではないといけないとダメだし。


もっと製品開発側の視点になると、どのタイミングで仕掛けるか、どのタイミングでどの層に広めていくかも重要で、製品が大多数の人にとって使えない段階でバイラルになる仕掛けをすると失敗するし。


まあ、このどういう順番で進めていくかとかはまた別の話なので、違う記事で書こうと思う。

今日起きて、とりあえず昨日のAmazonの発表でもチェックするかーと思ったら、自分にとって死ぬほど重要な機能をAmazonが発表していた。


それは、WhisperSync for voiceである。これは、電子書籍とオーディオブックの読んでいる位置をシンクロさせる機能。


ついにAmazonさんがやってくれた！！いつかやると思ってて、いつやるのかなあと待ってたけど、ついにきたよ！！！これで、確実に読書の体験が変わるのは間違いない。

つまり、通勤途中にオーディオブックで聞いていても、途中からテキストを目で読みたいとなった時に電子書籍の読む場所もちゃんとシンクロしてくれるってことです。


本読んでる時に目が疲れたり、布団でごろごろしたい時に、ささっとオーディオブックに切り替えできる。


本読んでいる時に、出かけないといけないけど、続きが気になる時に、歩きながらオーディオブックで聞くことに切り替えできる。


もちろん、この逆もできる。

日本語は自炊書籍を活用するしかない

僕は、10年ぐらい前にオーディオブックの良さに魅了されてから、自分で本を裁断してOCRでテキスト化して、それをTTSで変換して自作オーディオブックを100冊以上ぐらい作ったりしてた。


で、この耳と目で読むのを交互にする体験こそが読書のあり方の未来だと思ったので、今はそれをWeb記事で実現するLisgoなんてアプリまで作り始めたぐらい、この体験が欲しくて欲しくてたまらなかったわけなんです。


今はWebの記事ならLisgoで出来るんだけど、やっぱり一番やりたいのは、自分が本当に読みたい本なんですよ。


ネックとしては、今のところ品揃え的に英語オンリー。さらに、電子書籍に10ドル、オーディオブックに約25ドル払わないといけないという価格の問題。


なんか、kindleバージョンを買った人には、追加で4ドル払えばオーディオもダウンロードできるらしい！！これはヤバい！！


ただ、まだまだWhispersync for voiceに対応している書籍が少ない模様である。でも、これは時間の問題だと思う。


日本語で読みたい本がたくさんある自分としては、日本語でこの体験ができるのはまだまだ先だなあという印象。だって、洋書なら大抵の人気書籍はオーディオブックも同時に出たりするけど、日本語の書籍はそもそも電子化さえほとんどがされてない。


日本語でいち早くこの体験をするには、自炊業者にOCR化のオプションをつけてもらって、それを使ってTTSで読み上げるアプリを作るしかないな。これなら、価格の問題と、電子化とオーディオ化の品揃えが解決する。


今のLisgoはWeb記事専用だけど、UIとかどうシンクロさせるかの機能面はかなりノウハウがたまってきたので、そのうちORC化された自炊書籍を簡単に扱えるように出来ると最高だ。

読書に慣れ親しむ導入に最適だと思う

まあ、こういうふうに僕は熱っぽくこのよさを語るわけなんだけど、読書に興味ある人でも、オーディオブックを体験したことない人はあまりぴんとこないみたいなんですね。


さらに、読書そのものが好きじゃない人は、まったく興味がわかない。まあ、当たり前なんだけど。


でも、女子高生が携帯小説から活字に慣れ親しんだ例があるように、デバイスの簡易性、その行為自体の簡単さってのは、なかなかとっかかりが難しいものに慣れ親しむために凄く重要だと思うんですよ。


だから、活字を読むのはめんどいけど、耳で聞くなら簡単だから試してみたら、そのうち好きになってきて、結果的に読書が好きになるっていう人が増えるといいと思う。


そのために、今回のKindleのWhisperSync for Voiceは大きな一歩だと思った。


これのためにKindleFire買うか迷うなあ。たぶん、iOS用のKindleアプリでも普通にアップデートで対応しそうなんですよね。うーん。

“ブラックスワン”で有名なタレブが今月、短い論文を発表したみたい。で、それを読んだ金融業界の人が「The secret to success in the arts」というブログを書いていて、これがなかなか面白かった。


ちなみに、タレブは逆ばりにかける金融屋であり、不確実性の専門家であり、哲学者であったりします。”まぐれ”という、投資家がいかに運を実力と勘違いするかを書いた本の後に、“ブラックスワン”という本を出してこれも世界的なヒットとなったんですな。


僕は数学はてんでダメだが、経済学とか社会学とかで数式がそんなにでない本は好きで、面白いなあと思っていろいろ読むのだけど、タレブの”ブラックスワン”は生涯のベスト３に入るぐらい傑作であります。


どういう本かと簡単に紹介すると、「芸術家とか、投資家とか、大金持ちの経営者とかはの大成功事例は、多くの要素が運だ。ついでに統計学者や経済学者は基本的に全員バカでリスクの事をなんもわかってない。」っていう主張をこれでもかと説明しまくる本です。


ちなみに、ネットスケープを共同創業したマークアンドリーセンも、「ブラックスワンは全てのアントレプレナーが読むべき必読書だぜ！」みたいな事を興奮して言ってたりしたので、スタートアップに興味がある人も読むと面白いかもしれない。


タレブの次回作は”tinkering”っていうイノベーションがいかに起こるかという題材の本でずっと楽しみにしてるんだけど、いつ出るんだよ、まじで！


あと、タレブは著作の中では死ぬほど攻撃的なんだけど、どっかの大学で講義しているのを動画で見た時は、結構やさしそうな感じの喋り方で丁寧に話してた。

このへんでタレブの紹介を終わる。

さて、この元ネタの金融業界のブログ主は、「金融業界はプレイヤーが増えすぎて、運の要素がどんどん増えているので、仕事にするのはお勧めできない」という、一見いつもの調子で書いてるタレブの論文を、芸術家にあてはめて書いている。



“ヘッジファンドとかの業界の投資家の成功の多くは運だけど、もし失敗してもいい給料もらえるから、そんなに悪くないですよね。”


“だから、タレブの論文を読んだ後に、一番お勧めできないと思った仕事は、金融業界ではなくクリエイティブな業界、芸術家だ。”


“小さなオッズにかけて、これほど多くの人数が成功を目指している業界は他に考えつかない。”


“だから、もしあなたが芸術家への道を目指しているなら、何かを作り出している行為そのものが報酬でなければならない。なぜなら、世間に認められる可能性は非常に低く、もし成功したとしても、それは実力ではなく運だから”

こんな感じで、ブログは終わっていて、コメント欄も読むと、「いやいや、金融業界でやってくのも簡単じゃないよ」とか、「クリエイティブな仕事が運だけじゃなくて、努力や継続力だよ」とか、まあいろいろみんな書いてる。

さて、このへんでようやく、僕が適当に思った事を書いていく。



こういうのは、ブログの内容と関係ある事を書くかどうかが重要じゃなくて、まったく的外れな内容でも、何かを読んで、それがきっかけで何かを思ったっていうのが重要なんですよね。

作り上げる過程が報酬

ジョブズも従業員を奴隷のように働かせるために使ってたけど、”何かを作り出す行為そのものが報酬と思えるような事”っていうのは、本当に重要なんではないだろうか。


というのも、Webサービスとか、アプリとかで一発ドカンと当ててやるぜって思ったとしても、基本はこつこつとコード書いたり、地味な行為が延々と続くわりには、TwitterのAPI規約変更で数ヶ月の努力が泡になったりと、あんまりセクシーな事は起こらないわけですよ。


なので、作り上げている行為自体が楽しすぎるので、ぶっちゃけスケールするかどうか、キャズムを超えるかどうかの部分は運が大きいから、もちろん狙うけど成功確率は高くないと考えておこう。ぐらいが正しいのかもしれませんな。


会社勤めとかフリーランスとかして安定収入を確保しながら、余った時間を作って作るとか。



でも、ところがどっこい。人間誰でも、自分だけは違うと考えるもので、それが逆に継続的な努力を後押しするパワーにもなって、それはそれでいいとは思っております。そういう人間の性質があるからこそ、経済が発展するわけだし。

果ての国と月並みの国と、スタートアップのスケール

タレブはブラックスワンで果ての国と月並みの国の説明をしている。適当に検索したらこんな解説があった。


果ての国と月並みの国


役者の世界で言うと、劇団員での仕事は月並みの国で収入は予想しやすいけど限界がある。映画スターが果ての国で、確率は非常に小さいけど、当たるとでかい。


この話をよくスタートアップ界隈で聞く、”このサービスはスケールするか”っていう話に当てはめられるのではないかと思った。


つまり、スケールするかどうかっていうのは、果ての国の出来事だから、出来る限り月並みに国で運用できる範囲までターゲットや市場を絞り、果ての国で起こること（スケール）のマージンも確保しておくという感じ。


ポールグレアムは最初は自分専用のTODOリストとか、本当に小さな問題を解くサービスを作るのがよい方法だと言ってる。


ただ、人間誰もがスケールしないサービスはやる気がなくなるもんで、世界を変えるようなサービスを考えるあまり、誰でも喜びそうな幅の広いサービスを初めて、誰にも刺さらないサービスになってしまう。


つまり、ターゲットを絞れば絞るほど、ニッチな感じになっていき、具体的にイメージはしやすいけれども、こじんまりとした感じが漂い、スケール感がなくなり、最初にターゲットを絞るのを顕著してしまうというのがありがちだと思う。


僕も、Lisgoの最初のバージョンは、いろんな人が使えるようにブラウザをまず付けたんだけど、大失敗であった。


何を書こうとしていたのか忘れてしまったけれど、まあ、月並みの国から初めて、果ての国に行けるかどうか、キャズムを超えるか、さあこれからスケールするかどうかっていう所は、大部分を運が左右するという前提で進めればいいのかなと。



ついでに言うと、タレブが著作で薦める戦略はバーベル戦略だ。


バーベル戦略を簡単に説明すると、ポートフォリオ上のメインは大きな変動がない月並みに国に入るものを組み込み、一部を果ての国に入るもの、つまり確率は凄く低いけど当たればでかいレベレッジの効くもので一攫千金を狙うというもの。


まあ、これを参考にすると超安定志向になって凄いつまらないかもしれないんだけど。


ちなみに、投資を受けるのは、ドワンゴ会長が言うように製品開発とはまた違うゲームだと思うので、いかに果ての国に行きますと言えるかどうかだと思う。口では果ての国の行くと言いつつ、ターゲットを絞るのは難しくなりそうだけど。


でも、最近はスタートアップのタレントバイが流行ってる。金融業界みたいにリスクとったほうが起業家にとってはお得だというリスクとリターンのバランスが若干歪んでる状況もあるらしく、バブルのうちは投資受けてガツガツ行くというのもある意味合理的だったりもしてるようです。


というような、反対の事を思いついたけど、最近はカウンターストライクの新作が出て、それが面白いから、このへんで書くのをやめてゲームをしようと思いました。


いやあ、好きな事だけすればいいとかいう考えもあるけど、ゲームはめちゃくちゃ面白いからずっとやってたら廃人なってしまうから、まずいと思う！

「ＬＩＮＥ」、ＳＮＳ参入の理由　フェイスブック追撃へ


この記事を読んでると、収益化に関してはLINEはTwitterより遥かに先を行っているなあと思った。


特に、フォロー数が増えれば増えるほど企業アカウントはお金をたくさん払わないといけない仕組みとか、Twitterも参考にしてそう。


“数年前まではサービスの初期段階はマネタイズのことは考えずにユーザー数増やす事だけに集中するのがCool!”みたいななシリコンバレーのスタートアップ的な考え方が流行ってた気がする。


でも、最近は海外のほうでもリーンスタートアップの普及とかフリーミアムの限界もみんな学習してきて、最初からマネタイズをしっかり考えて、持続可能なビジネスじゃないとダメだぜ！みたいな流れになっている。


まあ、LINEもスタンプでお金取れるようになったのはまったくの偶然って言ってたから、当初はぼんやりとしか考えてなかったのだろうけど。


それでもTwitterみたいにもの凄い企業価値になって、その企業価値に見合う収益を達成するために後から苦労している立場からしたら先を行ってて凄いなあ。


まあ、Twitterがどっかに買収されたら遥かに凄い金額が動くだろうから、ビジネスモデルはバイアウトだ！ってなると、また話が変わるんですが。

一般層がターゲット？

この前友達と話していたんだけど、LINEみたいに普通の人でも使えるサービスで、スケールできるものを作りたいって最初から考えるのは誤解だと思うんですね。


LINEは最初から一般層っていうよくわからないエリアから進めたわけじゃなくて、ネット系を無視して、女子高生とかそういう層にあくまで絞って最初は始めたと思うんですよ。


だから、LINEは最初から誰にでも使えるものを目指して成功したから、自分たちもターゲットは狭めずに、スケールできる誰にでも使えるものを作るぞって考えるのは、「みんなを喜ばせようとして、誰にも喜ばれないサービス」が出来上がる可能性が高まると思うんです。


一般層っていうのは曖昧すぎるから、スマホ持ってて、女子高生で、ネットに疎い層とかなら、まだ分かりやすい。

この記事のタイトルはTwitterとLineのビジネスモデルを分析するみたいな感じだけど、そんなことはよくわからないからできないのです。


単純に、ターゲットが一般層で誰にでも使えるUIっていうのは分かりづらいからよくないという事を思っただけであった。想定の層がしっかりイメージできないと、UIの便利さと難易度のバランスの基準も決めれないし。

僕も愛用しているTwitterクライアント、Tweetbotがブログで「パニクるな」というメッセージを発信しています。かんたんに紹介したい。



ちなみに、僕自身Twitterの規約改正にモロ影響受けそうなアプリを作っているだけあって、規約改正を読んで、いろいろ海外のブログの説明とか読んでたところ、これはやべえどうしようと泣きながらブログ書いただけあって、最初は確かにパニックであった！


というか、勢いで書いたブログが想像以上にバズって、それのほうがビビった。なので、できるだけアップデートしようと思って、その後いろいろ新しくわかった事を元に４回ぐらい追記したりしたけど、分かりにくいと思うので、現時点の情報を整理してみる。


とりあえず、TweetBotのメッセージを黒字でかんたんに紹介。

APIコールの制限について

API認証は元からやってるからTweetbotには問題ない。


新しいAPIコールの制限はアクションごとのリミットだから、今までより逆にいい。例えば、タイムラインをたくさんリフレッシュしても、ダイレクトメッセージを送る制限には影響がない。



まあ、このAPIコールが全体の350制限から、アクションごとの制限になったのはそんなに悪くないんですよね。ここは最初からそれほど問題でない。TweetBotもそういう認識みたい。

ユーザ制限

現在のTweetBotのユーザー数はかなり大きい。現在のユーザ数の二倍まで許容されるから、現在の増加率を元にすると、数年は心配ない。


もし、ユーザー数制限に達したとしても、既存のユーザには影響はない。



この、現在の増加率から、数年は大丈夫だろうというところが重要な部分だと思う。相当数のユーザがいればいるほど、2倍になるのは時間がかかる。TweetBotは有料アプリのみだけど、無料アプリも提供しているクライアントならユーザ数もまた多いだろうし。


短期的にはTweetBotのように、すでに人気のあるクライアントアプリには有利かもしれない。なぜなら、これからクライアントアプリを作ろうとしている人にとっては、10万ユーザが制限となりそれ以上は許可が必要。


TweetBotのようなすでに10万以上ユーザがいるアプリは、現在のユーザ数の2倍になるまで許可なしでOK。


そうは言っても、TweetBotも2倍のユーザ数に達したらそれ以上はTwitterの許可を伺わないといけないし、許可の基準は現時点で不明なので、本音では嬉しくはない変更だと思う。Twitter自身が一般的なTwitterクライアントを作るのはよくないと明言してるから、新しく作る人はいなくなると思う。

Tweet表示ガイドラインの義務化

これからの6ヶ月間、Twitterの指示に従ってガイドラインに準拠するようにしたいと思う。おそらく、そんなに大きな変化はないと思うけど、詳細が分かり次第お知らせします。



短期的に既存のTwitterクライアントへの影響が出るとしたら、この表示ガイドラインなのは間違いない。ここのガイドラインの適用具合によって、どれだけ現在のTweetBotの使い勝手が変わるかが決まる。


特に、ここの部分がどう解釈されるかが気になってたところ。


(Display GuideLineから)
No other social or 3rd party actions may be attached to a Tweet.



しかし、よくよく考えるとInstapaperへリンクを保存するとかを禁止する理由はTwitterにあるんだろうか。公式アプリでもできるし。と考えると、後で読むサービスへの連携の禁止はないような気もする。


と思ってたら、PocketとかInstapaperにリンク飛ばすのはOKみたいだ！
On Twitter’s New API Guidelines and Pocket Integration

それでもつらいのう

まあ、既存の人気アプリであるTweetBotとかEchofonとかはなかなか既存ユーザ数の2倍にはならないので当分大丈夫だと思う。


それでも、今までプラットフォームを支えてきたアプリ開発者が、明確に成長のリミットを提示され、それ以上のユーザ数をカバーしたい時はTwitterの許可を受けないとダメだと言われているのはつらいと思う。


うう、毎日頑張って素晴らしいものをTwitterコミュニティーのために作って来てたのに、ここ最近は気の休まる時がなかったであろう。。プラットフォーム依存アプリの宿命とはいえ、、Twitterに名指しでBadと言われるのは悲しい。。わかる、わかるぞ！


ちなみに、昨日の記事にも追記したけど、Storifyとか、FavStarはTwitterの中の人から、OKな部類だとTwitter上で言われていた。

10万ユーザ制限の適用基準について

まあ、大多数の人は公式アプリ使ってるし、TweetBotのような既存の優れたクライアントアプリがそのまま使えれば特に気にしないと思われる。表示ガイドラインがらみは心配だけど。

一番心配しているのは、今まさに、Twitterのhome_timelineを取得するアプリを作っている人達だと思う。


だって、無料でアプリだして人気でたら10万ユーザなんてすぐに行くし、それ以上のユーザ数増加をTwitterから許可もらえるかの基準も分からない、そもそも自分のアプリは制限に入るのかどうか。



僕は、今度のLisgoでTwitterのタイムラインから記事リンクだけを集めるというものを作っていたので、普通の人にはどうでもいいんけど、僕にはもの凄く重要なことだ。なので、いろいろ頑張って調べ中。違うんじゃないかとかあったら、ぜひ教えてくださいませ。

ここで、もっともクリティカルな10万ユーザ制限について、現時点で自分がわかっている部分を整理してみる。


Twitterの文章の該当部分抜粋がこちら。こちらは全文リンク。


Additionally, if you are building a Twitter client application that is accessing the home timeline, account settings or direct messages API endpoints (typically used by traditional client applications) or are using our User Streams product, you will need our permission if your application will require more than 100,000 individual user tokens.


ポイントは、home_timelineにアクセスするTwitterクライアントアプリを作るなら、10万ユーザ以上のユーザになった時点で、Twitterの許可を受けないといけないとうところ。

まず、10万ユーザ制限を受けるのは、home_timeline、accountSettings,DirectMessagesなので、それ以外のエンドポイントを使う場合は気にしなくてよさそう。

例えば、こういうアプリはOKみたいです。

次に、今作っているのはTwitterクライアントアプリなのかどうか。そうでない場合は、home_timelineにアクセスしても、10万ユーザの制限はないようだ。ここが最も重要な部分だけど、Twitterの中の人の発言を見る限りそんな感じだ。

ここで疑問なのが、なにをTwitterクライアントとして、なにがTwitterクライアントじゃないか。例えば、News.Meみたいなアプリは適用外なのか、それともアウトなのか。凄く気になる。実際Twitterで聞いてみたけど、特に返信なし。

そのうち、もうちょっとハッキリとした事が分かるようになると思うけど、一連のTwitterの方針を参考に、Twitterがダメっていうかどうかの基準の参考になれば幸いであります。

[追記] 以前は”クライアントアプリとキュレーションがオワタ”というタイトルだったけど、混乱するコミュニティーに対し、Twitter側から新情報が出たので変えました。(最後の追記を参照)


[追記]新しく分かった事柄などを整理した記事を書きました。
TweetBotのメッセージと新しいTwitterAPIルールの整理

TwitterAPIの新しい規約詳細が出た！
https://dev.twitter.com/blog/changes-coming-to-twitter-api

６月の終わりに、Twitterがブログで、「Twitterアプリのパクリだったり、エコシステムにそぐわないアプリは禁止するよう規約変更があります。。。」と意味深げな事を語って、開発者のコミュニティーがずっと大騒ぎでした。


Twitterのブログ記事の衝撃はたいへんなもので、内容がはっきりとしてなく、一見開発コミュニティーへの脅しとも取れるし、開発コミュニティーが「今までTwitterのエコシステムを支えて来たのに、裏切られた！！Twitterこの野郎！！」みたいになってました。


「Twitterは本当にオープンなプラットフォームになれたのに。。残念だ。。こんなふうにもなれたし、こんなふうにもなれたのになあ。。」というようなブログ記事がすごくバズって、それがきっかけで、広告に依存しない真のオープンプラットフォームを作るというようなプロジェクトも出来上がってる。


このAppNetっていうやつなんだけど、これは、Twitterのデスブログの後の動きで、クラウドファウンディングで4000万以上集めて、みんなが無理だろうと思っていた目標額を達成してしまった。


あとは、iPhone用の最初のTwitterアプリ、Twitterrificの作者が怒りのブログを書いたり、「Twitter、頼むからTwitterクライアントをサードパーティが作るのを禁止しないで、オープンなままでいてくれ！」みたいなオンラインの署名活動まであった。


僕も、次のLisgoはTwitterのタイムラインからリンク記事だけを取ってくるというものを作ったので、TwitterAPIの動向は目が離せない、どうしよう、ドキドキ、せっかく作ったのになんてタイミングだ。。といった感じで夜も眠れない日々が続いてました。

そんなみんなが心配していたTwitterAPIの新しい詳細が今さきほどアップされた！ドキドキ。


さっそく、変更点を紹介してみる。

API使用に認証が必要に

スクレイピングや、BotによるAPIの乱用を防ぐため、すべてのAPIリクエストに認証を必要とする。 APIリクエストにOAuthを使ってないアプリは、2013年の3月までにアップデートしないといけない。

エンドポイントにつき一時間60回リクエストまで

今までは、一時間に350回までのAPIコール制限だったけど、同じエンドポイントをなんども使うアプリのせいで、特定のエンドポイントのAPI使用が圧迫されてきた。なので、エンドポイントごとに一時間60回までの制限とするようにする。

Tweet display, profile display, user lookup and user searchなどの、ボリュームが必要なエンドポイントに関しては、一時間に720回まで。

※Twitterを使った統計分析とかのサービスにとっては、嬉しい変更だと思う

開発ルールの変更

TwitterAPIを使用したアプリの表示ガイドラインは、守らなければならない必要事項に変わる。
@usernameが適切なプロフィールに繋がるか、Retweetやreplyやfavoriteが適切な形で表示されてるかなど。

Tweetはこういう形で表示しろというガイドラインの写真がこちら。やたら細かいルールが書いてる詳細はこちら。

Twitterクライアントをプリインストールしたデバイスを作っているなら、Twitterの承認が必要となる。100万以上のユーザートークンが必要なアプリはTwitter社に直接問い合わせしてください。

ホームタイムラインとかアカウントセッティングとか、いわゆるTwitterクライアントアプリ系で、10万以上のユーザートークンが必要なら、Twitter社の許可が必要。すでに10万を超えてるなら、現在の200%までユーザートークンを追加できるけど、それ以上の追加はツイッター社の許可が必要。

まだ、これ以上の変更があるかもしれない。

変更までの猶予は６ヶ月

すでにOAuth使ってAPIにアクセスしてるアプリなら、移行はそれほど難しくないけど、それ以外のアプリはOAuthを使うように変更しないといけない。

Twitterのエコシステムについて

今回の変更は、ソーシャル分析や、エンタープライズ系クライアント、メディアインテグレーションなどの分野を促進するもの。

逆に、StorifyとかFavstarなどのキュレーションサービス、伝統的なTwitterクライアントであるTweetbotやEchofonなどのサービスが規制の対象となっているサービス群。

下記の図の、右上の部分が規制の対象。逆に、他のカテゴリーはTwitter応援しちゃうぞって感じらしい。

Twitterクライアント、キュレーションサービスが。。

途中まで読んでて、まあ、エンドポイントごとの制限は問題ないか、タイムラインの制限はむしろ上がってるし。。と思ってたけど、アプリごとのユーザ制限が10万ユーザまでって書いてるのを発見して、オワタ。。。となった。



既存の人気アプリは現在のユーザベースから200％までは最大で認められるらしいけど、もうTweetBotもEchofonも、その他のTwitter系のキュレーション系で頑張って作ってきたサービスのそれ以上の成長は閉ざされたといっても過言ではないのではなかろうか！　(※許可が必要と書いてあって、キュレーションは優遇されるかもしれない)


さらに、なんか、”Tweetに他のサードパーティへのソーシャルアクションを禁止する”とかいうよくわからない制限もあって、これは、”send to Instapaper”とかが禁止されるのではないかと言われている。


(Display Guidelinesから)
3:Tweet Actions
b. No other social or 3rd party actions may be attached to a Tweet.

プラットフォームに依存すると危険とは言うけど

よく、プラットフォームに依存するビジネスしてるなら、プラットフォーム主の変更に左右されるから、しょうがないって言いますよね。


これは、誰もが頭の中で考えつつリスクを見積もっているんだけど、ある意味これは規模を広げればなんにでも適用されるんですよね。


iOSアプリを作ってるなら、アップルが突然一部の規約を変更するリスクあるし、アマゾンとかもそうだし、もっと言えば、住んでいる国の情勢が生活基盤のプラットフォームだという考えもできる。Facebook連携アプリでも、突然Facebookのやり方が変わるかもしれないし。



僕も、Lisgoの新しいバージョンはTwitterのタイムラインからリンクされた記事を集めてくるものを作っていたので、非常に痛い！これはマジで泣ける！ちょっとどうしようか！



僕の場合はまだリリースもしてないし、そんなに時間もかけてないからいいものの、今まですごい時間と労力を費やしてTwitterクライアントを作ったり、キュレーションサービスを作って来た開発者の事を思うと、マジでもらい泣きですわ。

Twitter公式クライアントへの移動

Twitterがやろうとしてることは、TwitterのタイムラインをTwitterの公式クライアントで見てもらうってことだ。そして、そこにある広告を見てもらうってことだと思う。


TweetBotとかは余裕で10万人以上のユーザがいるだろうから、既存のユーザ数が多い場合は、既存のユーザ数ベースという計算にしている。


でも、これからTwitterクライアントを作ろうとする開発者はいないだろうし、今まで素晴らしいものを作って来た開発者もゆっくりとサポートを止めていく。もう、この部分で成長は期待できないから。（それでも、すでにユーザー数がかなり多いアプリの場合は、しばらく続きそう。追記参考）


というわけで、Twitterクライアントがゆっくりと死んでいき、みんながTwitter公式アプリを使うようになるという流れ。



なんで、外部のTwitterクライアントにAPIを介した広告表示を必須にする方針にしなかったんだろう。公式クライアントだけだと不満を持つ人もいるだろうし、面白いTwitterの使われ方がどんどん死んでゆく。


ツギャッターとかは、サードパーティーのソーシャルサービスへのアクションに引っかかるのかな、このへんはちょっと不明。



とりあえず、ここ一ヶ月様子見て、あまりの反発の大きさにツイッターが制限を変更するっていうのにならないか期待したいところだけど、無理かなあ。。。　

アップルも、アマゾンも最初は法外な規約吹っかけて、後からちょろっと緩くすることが多いけど、今回は分からない。

※追記
一応、もうすでに10万人以上のユーザがいるアプリの場合は、現在のユーザー数の200％まではユーザー数の上限を許可するというルールなので、相当人気なアプリであればあるほど、現在のユーザー数の二倍に達する事は難しいので、まだまだサポートを続けるインセンティブはあるかもしれない。


ただ、新しいものは出てこないので確実にTwitterクライアントの競争は減るし、リミットがTwitterに決められるというのもモチベーション下がるだろう。


そもそも、Twitter側が、クライアントアプリを煙たがっているわけで。

さらに、新しいTwitterのタイムラインの表示方法のガイドラインに違反するとAPI取り消されるし、すべてのガイドラインを満たす事によって、いままでの使いやすさが失われる可能性もあり。どんより。。

※さらに追記
海外の様々なブログで指摘されてるように、問題はTwitterのルールの書き方が凄く曖昧で、Twitter側の解釈しだいでどうにでもできるという部分。


そして、僕も愛用しているTweetBotみたいな人気クライアントアプリはどう影響するかという部分では、Timelineの表示方法や、シェアの仕方への規制がどう適用されるかが当面の問題だと思う。少なくとも、大人気アプリは既存のユーザ数の2倍には簡単にはならないから、ユーザ数の制限は当分大丈夫だし。


（ただ、もし2倍以上になった時は、Twitterにお伺いして、許可をもらった場合のみ、それ以上のユーザ数を許されるというルール。どういう場合だったら許可されるかは不明。)



特にわかりやすい参考リンク (英語)
http://www.marco.org/2012/08/16/twitter-api-changes

※また追記（キュレーション系はどうなる？)

悲しさに溢れて勢いで書いた記事が予想以上に拡散されて、いらぬ混乱を巻き起こしてしまったらどないしょうと思いつつ、また追記。まあ、海外の開発者コミュニティーでも混乱中だし、あの規約だと混乱しますよね！と言い訳しつつ。


個人的に心配な、Twitterを使ったキュレーションサービスはどうなんだと検索してたら「StorifyやFavstarはエコシステム表の右上にあるけど、好ましい例のサービスだよ」というTwitter側からの返答があったらしい。

「あのエリアにはGoodとBadがあるんだよ」という返事。これまた微妙な返事だけど、TwitterクライアントはBadでキュレーションサービスはGoodっていうことかね。だって、右上のエリアには二つしかないしw

キュレーション系には光が見えたのか！と思ったけど、なんで大丈夫なのかはまだわからないんですよね。優良キュレーションサービスにはユーザ制限しないという特別処置が簡単にもらえるのだったら、文字通り大丈夫なのかもしれないけど。

ユーザのタイムラインからお勧め記事を集めてくるようなサービスの場合、ユーザー数制限に引っかかるので、ここがクリアされないとどうしようもない。

※またまた追記（home_timelineの10万制限に引っかからないサービス？)

Twitterの中の人のTweetを追っていると、もうちょっと分かって来た。


FavStarはOKなサービスだとか。ユーザ10万制限なのはhome_timelineを取ってくるサービスなんだけど、なぜか、HooteSuiteとかのhome_timelineはOKだ！という返信があった。


HooteSuiteは確かに分析系の機能が豊富だけど、普通にタイムラインを読むツイッタークライアントとして使ってる人もいるだろうし。






Paper.liとかNews.Meみたいな、ホームタイムラインを元にキュレーションするサービスで、10万ユーザ制限は適用されるんだろうか！


なんか、当初よりも期待が出て来たけど、home_timeline使ってても制限かからない状況もあると取れるので、悩む。

僕は遅ればせながら最近スギちゃんにハマっているんですよ。きっかけは、Youtubeの動画でスギちゃんのネタを見て、腹を抱えてわらったからであった。

ひょっとしたら、スギちゃんのiPhoneアプリあったら面白いんじゃないかなあと思って、検索してみたら、あった！


そして、このアプリのマーケティングが今までのiPhoneアプリの常識を覆すものであって、凄く衝撃を受けた。


このブログを書きながら知ったけど、「スギちゃんのおせばしゃべーる」というアプリは有料総合ランクで一位を取ったらしい。

スクリーンショットは一枚

普通、アプリのスクショって最重要ポイントであり、ここにどんなアプリかをわかるようにしないといけない。


しかし、このアプリは全然どんなアプリか内容がわからないスクショが一枚あるだけ！

逆に、これがどんなアプリだろうとワクワク感を抱かせる事に繋がっていると思われる。ただ、これはスギちゃんという人気キャラをみんなが知っているからこそ使える方法なのであるが。

それでも、この手抜き感満載のスクショ一枚が逆に効果的となっているのは、次のくだりを読んでもらえると分かると思う。

レビューが面白いから買う

このアプリで一番面白いのは、レビュー欄である。とりあえず、iPhoneアプリを吟味する時、みんなスクショ見た後に、レビューを見ると思う。

このレビューがすげえ面白い。

こんな感じ。

みんな、レビューで「想像通りクソアプリだったぜ〜」とか言って、嬉しそうに★５をつけてるんですよ。なんだこの従来の常識を覆すマーケティングは！


レビューを読んでいると、みんなスギちゃん用語で自分もレビューを書きたくなり、アプリを買っているのが分かる。


普通、シロートが面白いことを書こうとしても、あまり上手くいかなかったりするんだけど、スギちゃん用語で書かれたレビューの数々が結構面白い。


スギちゃんのネタには、一種の文法があり、「だぜ〜」を語尾としてつけて、最後に「ワイルドだろ〜」と閉めれば、大抵の話が面白くなってしまうという魔法のような効果があるのかもしれない。

ワクワク感の演出

このアプリの場合、スクショを5枚出して、どんなアプリの内容か分かるように売っていたら、ここまでみんなダウンロードしなかったと思う。


レビューを見た後の、「どんなクソアプリなんだろうか？」というワクワク感が半端なく、自分が買った後は、「あれ、思ったよりちゃんと使えるじゃないか」とがっかり感まであったぐらいである。

ちなみに、面白かったレビューが、「アップデートで使いやすくなったぜ〜。逆にアップデートで使いづらくなったほうがネタになったのに残念だぜ〜」というものであった。

「プロダクトがないほうが資金調達しやすい？」というエントリでも書いたけど、夢を売ると人間は食いつきやすい。

実際の具体的なものが分かってくれくるほど、最初は食いついていた人達が、どんどん冷めやすいのは人間の心理だと思う。


これはマーケティグの話で、逆に言えば、プロダクト開発では最小限の機能しかない段階で、熱心に使ってくれるユーザを作るのが本当に重要な一歩

プロダクトが出来てない段階だと、こんな感じのティザーサイトだけのほうが、誰が作ってるか、誰がプッシュしているかの副次的効果の影響しだいで効果的なはずだ。


というわけで、僕もマーケティングの時は、あまり見せすぎないという事と、ワクワク感の演出というものを考えようと、スギちゃんアプリを見て勉強になりました。

※追記
VCへのピッチ時は別として、製品への過剰な期待をユーザにさせてしまうと逆効果のデメリットのほうが高いから、将来的な機能追加のワクワク感をユーザに約束するのはよろしくないでの注意！ 参考記事 アップルとリーンスタートアップ

あと、従来の常識に捕われてはいけないっていうのも重要ですよね。

まあ、スギちゃんアプリのレビュー効果は偶然の産物だと思うけどw　これは狙って作ったもんだったら凄い。ポニーキャニオンすげえってなる。

田口さんの「Githubではなぜ人が辞めないのか？」という記事がたまたまFacebookで流れてきた。

なんと、一人も従業員が辞めてないのは凄い。本当かと思って資料見たら、創業5年で108人も従業員いるのに本当に一人もまだ辞めてないらしい。

これは本当に凄い、Githubが大いに参考にしたであろう37Signalsでさえ数人のミスマッチがあって辞めた人はいるのに。まあ、37Signalsがこういう働き方を広めて、いろいろトライアンドエラーがあったのだろうけど。

さらっと、”How Github Works”というスライドを見たのけど、こういうスタートアップが日本でもっと増えてほしい！もっとやれ！と思ったので、紹介してみる。（ちなみに、海外はこういう会社どんどん増えてきてるみたい。こうしないと、みんなすぐ辞めちゃうのもあるのだろう。）

会社によってベストな方法は違うので、全部猿真似しても上手くいかず、結局は自分で考えて最適だと思う事をすればいいのだけど。

と、最初に逃げ道を用意しておく。

働く時間を決めるのはアホ

9時-5時の就業形態は上手くいかない。クリエイティブなコードを書くのは、クリエイティブな挑戦だ。クリエイティビティを9時-5時の間に意図的に起こすことはできない。

生産的な時間はそれぞれが自分のゾーンに入った時起こり、早起きした時、夜遅く、普通の時間帯など、人によってバラバラ。

これプログラミング経験者ならみんなそうだろうけど、一人で静かで、邪魔の一切入らない長い時間っていうのがないとはかどらないんですよね。


プログラミングに限らず、会社でも、他の従業員がいなくなった深夜に一人で作業する時が一番集中できるとか、朝早く誰もいない時が一番はかどるとかよく聞く。


それなら、会社は非生産的な環境を作り出す悪の元凶じゃないかみたいなことを、37Signalsとかがよく言ってる。

長時間労働は破滅への道

徹夜作業は、精神を衰弱させ、コードの質を低下させ、質の低いコードが将来のコードに影響して、バグを発生させる可能性を指数関数的に増加させる。

僕も、ルーチンワーク的な作業をやってる時は、結構長時間でも続けてられるんだけど、本当に頭使うプログラミングを考えてる時は、頭がスッキリしてるとすぐ解決するのに、疲れてると、だらだらといつまでもできなかったり。

従業員を信頼する

従業員が一番の成果を発揮できるようにしたい。そのためには、従業員が幸せで、健康で、クリエイティブでないといけない。そのためには、雇った従業員を信用して、助けて、その後に、仕事を評価する。

結局は、ここが一番難しいところだと思う。放任主義には信頼が必要で、見張ってないとサボるんじゃないかってみんな心配する。


ちょっと話はずれるけど、自分がもし将来フリーランス雇う時は、時給制で、時間の計測は信頼するから勝手に計ってくれっていう形式がいいんじゃないかなと最近思った。


ソフトウェアの工数に見積もりなんて土台無理ですよね。よっぽど簡単なモノじゃない限り。時給じゃないと継続的なコミットも自分からの提案もしないだろうし。


この機能にいくらっていうと、発注側のリスクは一見低くなりそうだけど、やる側としては、いかに最短でOKの出る程度の完成品を作るかに集中すると思う。


まあ、ここはやったことのない自分の妄想なので、実際のところどうなんでしょうっていうのを経験ある人に聞きたい。

確か、孫正義さんが学生時代に教授陣を巻き込んで、製品を作った時は、こんな感じだった気がする。あれは、時給も自分で決めてくれていいから、成功して売れたら払えるよという凄いオファーだったけどw


以前、学生ベンチャーのスタートアップのオフィスをちらりと見た事があったけど、創業者の人の机が後ろにあって、その前にインターンの二人がモニタみながら作業してるんですよ。みんなの向きは一緒。


これは、前のインターンの二人がサボってたら、後ろからすぐに分かるぞみたいな意図でこの配置にしたんだろうけど、この配置で絶対働きたくないなと思った。


仕事中にツイッターとかしたら後ろから怒られそうな雰囲気がぷんぷんなんですよ。

仕事中の息抜きにツイッターやろうが、ムラムラしたらオナニーしてスッキリしようが、その人の生産性をマックスにする方法はその人が知ってるから、それでいいですよね。特に、後者は一人の時じゃないと無理ですね。

世界中からリモートで働く

場所も自由で、ミーティングもないから、時差と場所に縛られず、世界中から優秀な人材を雇える。引っ越しとか、家庭の事情で従業員が辞めにくい。


これは、日本から世界に通用するスタートアップを作るぜ！と思ってる人は凄い重要なんじゃないだろうか。だって、シリコンバレーなんてビザないと無理だし、給料も高いし。


リモートで世界中から集まったチームをマネジメントするスキルというのがこれから、凄く重要になると思う。ローカルにこだわらずに、ベストな人材を雇えるという意味で。


こういうと、マネジメントしないっていうのがValveとか最先端の主流だよと言われそうだけど。


でも、一緒にいるっていう事の価値も計り知れないものがあるから、ここらへんは悩みどころだと思う。


だって、なにげなく、休憩してる時のおしゃべりの最中にアイデアが生まれるもんですよね。となると、みんなでオンラインゲームすればいいのか！　うむ、このへんは難しいところであります。

仕事の邪魔をしない

定例会議はなし、会議はとにかく減らす。何か用がある時は、その人がゾーンに入っていてプログラミング中だと邪魔したらダメだから、基本はチャットを送信しておく。で、好きな時に返信してもらう。

マネージャーは邪魔なだけだからいない。

これ、似たような事をJoelOnSofwWareっていうStackOverFlow作った人のブログで、興味深い事を書いてたのを思い出した。


「ある分野でわからない事があった時に、同僚のプログラマなら5分で答えられるとする。その時、その同僚に聞くべきか、もしくは、自分で聞かずに20分ぐらいで解決するか。」


みたいな話。

簡単に結論を紹介すると、プログラマがゾーンに入ってる時に、邪魔されると、もう一度ゾーンに入るためには、30分から一時間かかることも珍しくない。


そのため、同僚の質問を5分で答えられたとしても、その人がまたゾーンに戻るために30分以上かかるから、結果的に全体の生産性が落ちる。


なので、同僚がすぐに答えられそうな簡単な問題でも、自分でちょっと頑張れば解決できそうな場合は、ゾーンに入って集中している同僚の仕事を遮るべきではない。

というような話で、なるほど、これはなかなか説得力あるなと思った。

さて、ここまで書いてみたけど、言うは易しで、実行するのはそう簡単に行かない事がいっぱいあると思う。


例えば、チャットだと好きな時に返信すればいいから、邪魔されないっていっても、すぐに返信したら、その後すぐに返信が続くのが期待されちゃうなあとか、いろいろありますよね。細かすぎるかもしれないけど。

日本では、こういう仕事のやり方を取り入れてるので自分が知ってるのは、ソニックガーデンとかゼロベースかな。後は、YCombinator出身で日本にオフィスがあるGinzaMetricsもこれからはローカルにこだわらないほうがいいと言ってた。

先日、プログラミングの師匠であるエランさんと久々にスカイプで話した。

ちなみに、エランは日本語とプログラミングのスキルエクスチェンジを一年間スカイプでやった関係である。

2年半前にPHPを独学で勉強し始めた時に、壁にぶちあたり、その時に日本語教えるからPHP誰か教えてと海外のPHPの掲示板で募集してみたら、親日家で年齢も一緒のエランがたまたま見つかったという経緯。

いやあ、今iPhoneの師匠をしてくれてるマシューもそうだけど、この時もやたらハイスペックな師匠が見つかって凄いラッキーだったと思う。

今、エランはBinpressというプログラミングのライブラリのマーケットプレイスを作るスタートアップをシリコンバレーでしている。彼はイスラエル人でイスラエルからアメリカに一年前に来たんだけど、アメリカで生まれたからグリーンカード持ってるらしい。いいなあ。

あ、ちなみに、エランの会社は今をときめく日本のスタートアップ、Wantedlyの仲さんがMagajinというサービスを作った時に開発を担当していたという経緯もあったり。関係ないけど、Wantedlyって本当にいいサービスですよね。

とりあえず、エランさんの紹介はここで終わる。

やっぱシリコンバレーはよいらしい

さて、シリコンバレーにイスラエルから移ったけど、そっちはどう？とか、そこにいる価値ってやっぱ凄いの？みたいな事を聞いてみたら、いろいろ話が面白くて、思った以上に話が長引いた。

一番面白かったのは資金調達の話なんだけど、シリコンバレーにいるとコネクションが半端ないよという話について書いてみる。

シリコンバレー以外の国でもスタートアップはできるけど、やはりスタートアップするにはベストな場所だと実感したらしい。なぜかというと、コネクションの広がり方が段違いに違うと。

例えば、シリコンバレーでサービスの話をするために誰かと会ったりすると、その人が自分のサービスに関係する人を5人教えてくれて、教えてくれた人に会ったら、また関係性のある人を5人教えてくれたりすると。

自分たちのサービスを進める上で重要なコネクションや、アドバイスを得られるスピードがイスラエルにいる時とは段違いで、イスラエルで2年かかった事が、こちらでは数ヶ月で進むみたいな感じらしい。

資金調達の話

それでは、ようやく資金調達の面白いパラドックスの話に移りたい。

ここまで引っ張っておいて、たいしたことないかもしれないけど、その時はご愛嬌ということで許して頂きたい。

これはエラン自身のスタートアップの経験や、周りの友達から学んだ事らしいけど、資金調達をする時は、プロダクトがない、もしくはβバージョンの初期段階のほうが簡単らしいのだ。

プロトタイプがないと厳しいんじゃないかと直感的に思ってたのだけど、ある程度のレジュメや、チームの実績があれば、プロダクトを作って実際の現実が明らかになる前に夢を見せたほうがいいらしい。

これはエランのお友達の話らしいけど、まず彼はあるサービスのβバージョンを小さく始めるために作って、ある程度のユーザも確保してたらしい。

しかし、この段階で投資家から資金調達しようとすると、そのサービスができ始めるとどうなるかという実際の現実が見え始めるため、よほどのホッケースティック的なユーザ数や利益の伸びが見れないと、現実を見せられた投資家は乗ってこなかったと。

そこで、次のサービスは実際のプロダクトのデータが取れるところまでは作らずに、チームとしての実績と将来はこうなるみたいな夢を売るように方向転換したら、すんなりと資金調達が成功した。やったあ。となったらしい。

Colorみたいに、プロトタイプを作った後に速攻で資金調達するのが一番いいのかも。数ヶ月して、実際のユーザデータとかわかった後だと夢が崩れる可能性が高いから。

プロダクトへの投資は大変

この話はなかなか面白い。YCombinatorの方針にもあるとおり、最初の投資で重要なのはチームであって、人間を重要視する。その時は、プロダクトはどんな形にも変化するだろうから、無限の可能性が広がる。

でも、ひとたび、その人達がサービスを作り始めて、凄い勢いでサービスが伸びない時、堅調ながら、比較的ゆっくりな成長を見せた時でも、現実を見せられた投資家側としては、投資する気持ちのノリが薄れる事が多いそうな。

かといって、エンジェル投資家側からすると、実際のプロダクトができて、サービスも凄い勢いで伸びた状態だと、安い投資額で株式はもらえないだろうから、初期状態に投資するにはこれでいいのだと思う。


とにかく、プロダクトに投資するには相当の説得力のある現実的なデータが必要なため、チームに投資するほうが楽ということらしい。なるほど。

Binpressについて

ちなみに、エランのBinpressはスノーボールのように確実に成長をしつつ、利益をあげていて、まだ自己資金で進めてるようです。

VCマネーなしで進めてるのは凄いなあって言ったら、シリコンバレーでも、Instagramとかセクシーなスタートアップが有名になるけど、実際は地味系のほとんどのスタートアップが自己資金でやってるよって言ってた。

iPhoneのコンポーネントだけ見てみたら、一年前に比べてものすごい数のライブラリが並んでいた。これは未来を感じる。


CocoaControlっていうサイトをiPhoneのライブラリ探す時によく見てるよって言ったら、そのサイトの運営者もお友達で、一緒に協力したりしてるよって言ってた。

これも、シリコンバレーのコネクションの力なのか、恐るべし。