Page 28 of 29

田口さんの「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もこれからはローカルにこだわらないほうがいいと言ってた。

*家計簿と読み上げのアプリ作ってます。自己紹介と過去ログはこちら。

有料のiOSアプリをリリースする時、無料バージョンもリリースする予定なら、とても悩む事がある。

それは、「無料+アプリ内課金」モデルにするか、「有料版、無料版2つ出す」モデルにするかということです。これは凄く悩ましい問題で、どちらも一長一短があります。

Continue reading

*家計簿と読み上げのアプリ作ってます。自己紹介と過去ログはこちら。

反復に敏感になる

ゼロベースの無料相談室にお邪魔した時、石橋さんに言われて最も印象に残っていたのが、「反復に敏感になる」でした。この言葉はとても衝撃的で、僕のUI設計の考え方に大きな影響を受けました。

Continue reading

*家計簿と読み上げのアプリ作ってます。自己紹介と過去ログはこちら。

最近アップストアのSEOについて勉強したので書いてみる。この分野に関して詳しい日本語情報もまだなさそうだし。

僕は「アプリは内容が全てだから、SEOなんていらないんだよ！」というピュアな考えを持つ人間なのだけど、面倒じゃないならとりあえず試してみるかといった気持ちでやってみた。

調べてみたところ、WebのSEOみたいに洗練されてない分、出来る事は限られているのでシンプル。時間かけずに出来そうなのがいい。

最初に白状しておくと、LisgoがアップストアのSEO対策したら爆上げでウハウハだぜーっていう状況などにはなってないのです。まだ、アップデートして日がたってないので効果がよくわからない。

残念ながら、実体験を元にというよりは、各種アップストアのSEOサービスを使ったり、英語のブログを読みあさって得た知識を主に書きたい。

なぜアップストア内のマーケティングが重要か

adMobのデータによると、90％の人はiPhoneアプリを発見する時に単純にiPhoneアプリ内から見つけるらしい。まじか！！本当かどうか知らないけど、これは予想以上の数字だ。

確かに、最近はパソコン使わずになんでもスマートフォン使う人が増えていて、このトレンドはどんどん加速している。

僕はWebサービスからアプリ開発に移ってきたので、Webのランディングページに余った時間を使っていた。とりあえずダウンロード数を増やしたかったら、その時間を使ってストア内のアイコンとか、スクショとか、説明文やタイトルの見せ方に時間をかけたほうがよさそう。

ちなみに、アップストアのSEOを勉強しようかと思ったきっかけは、Lisgoのストア内の説明文を日本語でも書いてみたら、日本のストアの売り上げが一気に変わったからである。この時、ストア内で見つけてもらうのが一番重要なんだなと実感した。

アップストアのSEOは手軽で、個人開発者に優しい

ほとんどの人がアプリをストア内で見つけると書いたけど、圧倒的多数の人達はランキング経由か、検索で見つけるらしい。(appSEOのHP情報）

ランキングに入るのは大変だけど、検索でヒットしてもらう工夫ぐらいなら簡単にできる。なにも考えずに適当にリリースすると、検索にもなかなかヒットされずに詰んでしまう。

自分もそうだったけど、アプリを知ってもらうには、有名なブログで取り上げてもらうとか、SNSでバズるとか、最初はそういう事を考えるんですよ。でも、どちらも大変だし、完成度高いアプリを満を持して発表して、各種媒体に取り上げてもらおうのは時間かかる。個人なら特に。

僕は素早くリリースして、反応をみながらアップデートを繰り返しているので、まだまだ荒削りな段階でバズるマーケティングするのもよろしくない。大多数の人に提供できるほど使いかってが洗練されてないから。

しかし、アップストアのSEOはちょっとタイトルとかキーワードを工夫するだけなので、少しノウハウさえあれば簡単にできる。わざわざ検索してくれるのは最初のアーリーアダプター層な可能性が高く、初期段階のアプリでもOKだし。

もっと具体的なダウンロード数を突き詰めると、レビューを増やす施策が特に重要になってくる。Lisgoは初めて使うユーザでも使いやすいようになってないから、まだ早いかなあ。

ちなみに、appCodの人がQuoraで説明してた実践的なプロモーション方法は素晴らしい。個人開発者でも真似できそうなノウハウ満載だったので、内容だけでも今度紹介したい。

重要ポイント１ – タイトルに関連ワードを

まず、検索結果で表示される長さ（20byteぐらい)の最初の部分は、分かりやすいタイトルをつける。なおかつ、アプリに関連する重要キーワードも加えて入れる。タイトルに重要ワードを入れるのが特に検索には有利みたい。

Lisgoの場合は、以前”Lisgo”だけだった。これはよろしくない。

“Lisgo Blog Speaker – Voice reader for web news, it reads your Read It Later list aloud with Acapela text to speech.”　のほうがよさげ。

*UPDATE
実験的に試したのだけど、上のタイトルは長過ぎてスパムっぽいからもっと短いほうがよいなあ。。あまり長過ぎるといかがわしく感じるし。ちょっと次のアップデートは考え直そう。

長過ぎるタイトルだと検索ランクは薄まるの？ってappCodの人に聞いたら、「それは僕たちも、まだ分からない。」という返事だった。

でも、”Instagram”だけのタイトルだったりする場合、ユーザがInstagramと完全一致するワードで検索したら、絶対にトップに表示されるらしい。だから、Instagramみたいに有名になったアプリは、下手に長くするより、アプリ名だけにして、完全一致で確実にトップに表示されるようにしたほうがいいのかも。

ちなみに、appCodのデモアカウントで、どの長さにすると検索画面に収まるかをお手軽にシミュレートできるのでお勧め。キーワードの検索順位を確かめるのも素早くできる。

間違ってたら申し訳ないけど、だいたい20byteまでが検索結果画面に収まる。Universalアプリだと＋ボタンが値段の左側に表示されるから、さらに短くしないと右側が切れちゃう。

また、あまり関係ないワードで長過ぎるタイトルだったり、単純にキーワードを並べるとリジェクトされるので注意。長過ぎるタイトルはクールに見えないのもあるし、できれば簡潔で短いほうがよいはず。キーワード変えるためだけにアップデートするのも、ユーザにとってはウザいことこの上ないので止めましょう。

*UPDATE
appSEOの柴田さんによると、重要な単語であればタイトルと指定キーワードに同じ単語を入れるのは意味あるらしいです。いろいろ実験して確認したらしい。

重要ポイント２ – 競争率の高いキーワードは登録しない

ストアSEOを勉強するまで、単純に関連しつつ人気そうなワードを適当に登録キーワードに入れていた。appSEOを試してみると、「ダメですよ！こんな人気キーワードいれても、あなたの検索順位は50以下で意味なしだよ。変えましょう！」って教えてくれる。

確かに、順位が下になって意味がないなら、大人気ワードは入れずに、ちゃんと見られる検索順位で表示される他の関連ワード登録したほうがいい。アホだった。。

しかし、AND検索で探す場合もあるから、他のキーワードとAND検索で多用されそうなら競争率高いワードでも入れるべきなのではないだろうか。appSEOでは変えろって警告されるけど。どうなんでしょ。

※UPDATE
appSEOの柴田さんにTwitterで質問したら、全ての設定ワードをちゃんとランクインするほうを優先するほうがよいとのことでした。そのワードでAND検索にヒットする可能性もあるし。どうしても競争率の高いワードでAND検索を優先する場合は別だけど。。。と教えてもらった。なるほど！

とりあえず、人気の競合アプリを登録キーワードに入れるというのは常套手段で、なおかつワードの競争率も大抵そんなに高くないからオススメ。

※UPDATE
競合アプリの名前をキーワードに入れるのは厳密にはルール違反らしい。アプリマーケティングの本で書いてて、リジェクトされた事もないので普通だと思ってたけど、これも避けた方がよいようだ。

ちなみに、アップストアのSEOサービスというのは、登録した競合アプリからお勧めのキーワードを解析したり、自分の登録しているキーワードで自分のアプリがどのぐらいの順位で表示されるかを教えてくれる。

競争率がそれほど高くないけど、自分のアプリに関連する人気ワードを探すのはとても難しいし、自分のアプリの人気度によって最適な登録ワードも変わる。これを選びぬく手助けをしてくれるのですね。

自分の知っている範囲で、アップストアのSEOサービスは、appSEO、appCod、AppStoreOptimizationの３つ。appSEOとappCodは日本のストアも対応してる。特にappSEOは日本語対応で、素晴らしいスタートアップのノウハウをたびたび共有してくれる日本人の柴田さんが運営してる。

関連サービスやブログ

appSEOの一週間の無料期間は、こちらのリンクから登録すると2週間に伸びるらしい。僕の期間も一週間延びると書いてる。
http://appseo.co/ja/?rf=aec2933495dd20e17cdc9c151a913846

appCodのデモアカウントは、競合アプリの登録ワードを予測してくれるのでお勧め。英語だけど、ブログも必見。どのアプリマーケティングの本より実践的で素晴らしい。
http://www.appcod.es/

ユーザ目線で、アプリを落とすかの意思決定までの思考過程を解説してくれてる記事。必見！「AppStoreで残念なアプリをつかまないための11のチェックポイント」http://d.hatena.ne.jp/renewal49/20120403/1333456535

*家計簿と読み上げのアプリ作ってます。自己紹介と過去ログはこちら。

アップルの経営手法を元幹部からの聞き込みを元に分析したインサイド・アップルを読んだ。

社員を特定の仕事に集中させる方式とか、いかに社内政治の発生を抑えるかなど、アップル独特のやり方を細かく分析していて最高に面白い。

でも、自分としてはリーンスタートアップと、アップルの製品開発のプロセスについていろいろ考えたりしてきたので、その部分に絞って書きたい。

主に、”顧客インタビューしない部分”と、”製品を秘密にする”という２つについて。

なぜ顧客インタビューしなくてもいいのか

ちなみにリーンスタートアップは、時間とコストをかけて顧客が望まないムダな製品を作らないようにする手法です。製品を開発する前からターゲット顧客にインタビューする。そして、自分が作ろうとするものに価値を見出す人がいるかの見込みを確認しながら小さく製品を作っていく。

この開発手法を去年の夏頃に勉強し始めた時は、これはいいやり方だなと感銘を受けたのたものであります。実際にいろいろと試して取り入れている部分が多いにあるし。

しかし、アップルは「顧客調査をやるとつまらないものが出来うんだよ！」といって調査を一切やらない。

「人々に欲しいものを聞いていたら速く走る馬を作ってたね」と、フォードが言ったか言ってないか分からない言葉がこの理屈を語る時によく引用される。アップルの開発プロセスは、リーンスタートアップの話を聞いた人が最初に思い浮かべる反証な訳です。

もちろん、UXとかリーンスタートアップを専門とするジャニスさんやらエリックさんやらは、「アップルだって社内で小さく試作品を試しているはずだ。」とか、「顧客に欲しいものを聞くのは間違いで、観察して顧客が欲しがるものを起業家はイメージするのが大切だ」と言っている。

正直、リーンスタートアップを世界中に広めている最中のエリック・リースは、「ウゼエな、アップルの話はすんなよ。」とでも思っていないだろうか。

しかし、リーンスタートアップの定番である「製品を作る前にターゲット顧客となりそうな人、10人以上はインタビューする」という事をアップルはしない。もちろんプロトタイプを作って改善していくというのは、社内で特別な扱いを受けているデザインチームがやっているけれど。

なんで試作品を作る前に顧客ニーズを確認しないでiphoneやらiPadが出来たかというと、ジョブズが欲しいものを作るという判断基準があったからだと思ってた。本を読むとまさにその通りの事が書いてる。

しかも、社内政治に気を散らされないで自分の業務に集中できるように、他の部署が何をやっているかはお互いにまったくわからないらしい。となると、Googleみたいにまず社内の人間が試作品を使って、社内規模で可能な限りフィードバックもらう事もしにくい。これはちょっと驚きだった。

ジョブズ指揮下のプロダクトは、ジョブズが気にいるかどうかが重要事項で、細部まで文句をつけられる。ちなみに、37signalsやEvernoteの社長も、自分が欲しいものを作るのが一番簡単なプロダクトの作り方だと言っている。

この”本人が本当に欲しいもの”というのがとても重要で、「俺もあったら欲しいと思うし、みんなも欲しがるだろう」っていう中途半端な欲求だと、なんかズレたものができるのだと思う。具体的には、代替手段もちゃんと試していて、既存製品のどこが問題かをはっきりと認識して、不満を持っているぐらいじゃないときつい。

まあ、普通自分が欲しい物基準で作るとBtoCになって、ビジネスモデルが難しく、あまり儲からないってのがつらいとこですが。そういう意味で、BtoB向け製品で、その分野の深い知識と問題点を理解してる人は有利だと思う。

ぶっちゃけ、自分が本当に深刻に思っている問題を解決する製品を作ろうとしているのなら、最初のインタビューはすっ飛ばしてもよいはずだ。RunningLeanでもそう書いてる。

下手にいろんな意見を聞いて、自分があまり欲しくはないなと思う機能を付け足してごちゃごちゃするよりも、最初は自分が本当に必要な最低限の機能のみ作るのがいい。Lisgoも最初は大多数の人が使えそうなUIを作って失敗してた。

アップルではジョブズがいろんな機能のアイデアにNOを言いまくって、製品がシンプルになっていくらしい。

ただ、自分が欲しいものを作っていて、ユーザの問題も、問題が解決したかも判断できるからといって、ユーザの意見を聞かないでもOKよってわけではないとは思う。

このへんアップルがどうだかわからないけど、僕の場合はユーザの要望やら意見を聞いてるだけで、「こういう視点があったか」とか、「この機能に気づかないのか」とか、「やっぱり自分と同じ考えの人がいたのね」と、素晴らしくタメになる。

ただ、最終的にどういう形に落とし込むかといった最終判断は、ワガママに自分が使うかどうかで決めている。自分が直接必要じゃなくても、明らかに大多数の人が必要だろうと思う機能のみつけたり。LisgoだったらBluetooth対応とか。

そういえば、Instapaperの作者もPodcastで言ってたけど、そういう作り方をしてるらしい。よいと思った新機能も、しばらく自分が使ってみて、使わないなと思ったら切り捨てるらしい。

製品が完成するまで秘密にする理由

アップルが市場調査をしないのは知っていたけど、製品が完成するまで秘密にする理由が面白かった。

まあ、考えても見て欲しいのです。リーンスタートアップの教えに従うと、出来る限り最初からユーザと対話して、どういう製品を作るかを顧客と接しながら改善を繰り返す。

となると、製品の詳細についてはオープンにならざるをえない。だって、顧客インタビューしたり、顧客にこちら側が考えた問題の解決手段がいいと思うか反応を聞いたりするわけだから。下手したら、製品出来上がる前にお金をもらう約束までする。

誰もお金を払いたがらない無駄な製品を作るリスクを減らすんだ！というのがリーンのテーマであり、「なるほど、こりゃいいね！」と僕も思っていたのですが、アップルはすごい秘密主義で正反対なんですよ。

なんでも、製品が秘密のベールに包まれていたほうが人々の期待が高まってよいと。まあ、これは分かる。でも、僕みたいな元々だれも注目してない状態なら関係ない事だ。

それより重要だったのは、「製品が出来る前に作るものを発表すると、ユーザの期待が勝手に高まり、それを上回るのが難しくなる。それよりも、素晴らしい物が出来てから一気に発表したほうがユーザに驚きと喜びを持って迎えられる。」という部分。

むむ。。これを今までの自分の製品開発プロセスに当てはめてみると、「こんな機能もつける。これにも対応する予定だ。ああ、その機能も付ける予定だよ。待っててね。」みたいな感じで話してた気がするぞ。やってしまったーーー。

そもそも、予定通りにスケジュールが進むわけないから、ユーザの期待値を無駄にあげてしまう愚かな行為だったかもしれない。ユーザの意見を聞く努力はサボらないようにするけど、要望があっても簡単に約束しない事にしよう。

このへんは、37Signalsのブログでも言ってた。「ユーザに約束するな」と。

ユーザから明らかに構想予定の機能を要求された時も、「ああ、その機能ね、もちろん付けるよ。すぐだよ！」みたいな返事は頭の中だけに閉まっておく。

「なるほど、検討しときますね。」といった感じに常に冷静に返事しつつ、機能が出来てから「ついにできました！」といきなり発表というツンデレ方式でいこうと思います。

というわけで、Lisgoの日本語対応は未定という事でお願いいたします。

参考図書 *アップルインサイド

*家計簿と読み上げのアプリ作ってます。自己紹介と過去ログはこちら。

「グーグル　ネット覇者の真実」が面白い。中国で挫折した部分とか詳しくて最高なんだけど、スタートアップというのをブログ名にしてるのもあり、初期の頃にどのようにやってたかに注目して感想を書いてみます。

なんか初期の頃は、創業者の二人とも最初は自分の論文のためにGoogle作って、いい感じに研究結果書けたらいいなっていう雰囲気なんですよ。周りの友達が、「これはスゲエ、お前起業しとけよ！」とか薦めるんだけど、最初は乗り気じゃない二人。

まあ、スタンフォードの研究員という身分も結構満足できるものだし、アカデミアの道を志していたのもあるのであろう。

だからもあって、二人ともGoogleをヤフーとか周りのいろんな会社に売ろうとするんだけど、「みんなはした金だなあ、もっと高い値段で買ってくれよ」みたいな感じでいい買収が成功せずにトボトボと家路につく毎日。

とても面白いのが、最初らへんはGoogle創業者の二人は全然ThinkgBigじゃないのに段々とビッグマウスになっていくところ。途中からアクセス数が増えてくると、「おいおい、これは可能性あるんじゃないの、ちょっと起業しちゃいますか。世界変えちゃうぞ」みたいな感じで発言も調子に乗ってくる。

その後、どんどんGoogleが人気になってくると、ブリンとかは採用面接でいかにGoogleが世界を変えるかという壮大な構想を語りだす。うーむ、最初は適当な会社に売却して博士論文の執筆に戻ろうしていたのに。。

ほどなく、有名なベンチャーキャピタルに出資をしてもらうプレゼンで、ペイジが「将来は100億ドルの会社にするぜ。100億とは売り上げじゃなくて、利益のことだぞ。フハハ。」と盛り上がり始める。売り上げないけどアクセス数はうなぎ上りで自信ついてきたんだと思う。

そして、その頃に出資した側のVCの人が当時を振り返って、「笑っちゃうほど壮大な野望なんだけど、奴は大真面目の未来を計算尽くして、本当にそれを信じてたんだよ。。」みたいな感じで、初期の伝説が出来上がっていく。

そういや、ザッカーバーグもFacebookの初期の頃のインタビューがちょっと前に話題になってたけど、「いやあ、みんあ世界を変えるとか吹いてますけどね、僕はまず小さな大学という単位で価値あるものを作りたいのよね。別に世界変えるとかみんな気にし過ぎっすよね。。」という非常に謙虚な動画がアップされてた。

しかし、有名なエンジェル投資家であるロン・コンウェイが、スタートアップスクールでザッカーバーグと出会った頃の話を語っていたのはこんな感じだった。「彼は最初の頃から、凄く鮮明にソーシャルの行く末をイメージし、これから実現していく未来のビジョンが確固たるものとして自分の言葉で語ってたんだよ。。（スゲエよ奴は。。）」

ビルゲイツも自分用にゲームかなんかのプログラミング作ろうとしてただけだし、ジョブズも最初は企業にPC売って小銭稼げれば満足って感じだった。ジョブズでさえ、「もっとビッグに考えないといかんよチミ！」と初期の年上のメンターみたいな人に言われてるし。

最新のポールグレアムのエッセイでも、”壮大すぎるアイデア”みたいなタイトルで恐れを知らないビッグアイデアの数々を書いてるんだけど、引っ張っておいてオチが凄かった。

「でも、こんな感じで煽って書いてるけど、どう始めるかのベスト戦略は自分のために小さなアプリを作ることだよ。自分の小さな問題を解決すれ事から始めて、最初から壮大なビジョンを語って周りに過度な期待を持たせたり、敵を作ることはないぞよ。」といった感じで閉めてた。

「大きく考えても、小さく考えても費やす労力は変わらないから、どうせならでっかい事したほうがいいよ」というカッコいい事をVCの誰かが言ってたけど、歴史をひも解くと最初はみんなThinkSmallだったようだ。サービスに勢いが出てきて自信がついてきた後、VCや従業員の前でThinkBigになっていくというのが定番なのかも。

*家計簿と読み上げのアプリ作ってます。自己紹介と過去ログはこちら。

最近、趣味でiPhoneアプリやプログラミングを始めたいという人からお勧めの勉強法を聞かれる事が多くなってきた。そこで、挫折しがちなプログラミングの覚え方を考えた。どう最初の壁を乗り越えるかについて書いてみます。

ちなみに、僕は超文系で、数学も死ぬほど苦手である。プログラミングを始めたのは28歳すぎで、歴はちょうど２年。PHPから初めて、2011年の3月にiPhoneでObjectie-Cを勉強し始めた。主にネットと本の独学。

小さい頃からプログラミングに慣れ親しんでいるわけでも、理系だったりもないので、当初の「絶対、俺には無理だ、この呪文の羅列は向いてない！」という気持ちも覚えています。文系出身だったり、プログラミングは専門外すぎて無理だと思っている人向けにこの記事は参考になるかもしれない。

ちなみに、プログラミング始める前までの経緯とか、少なくともhtmlとかできたんですかとかもよく聞かれるけど、そういうのは気にしなくてよいのである。それより、楽しくなるかどうかが重要で、楽しくさえなれば、勉強という意識がなくなり持続する。持続さえすれば勝手に上達する。

楽しくなければ続かないし、楽しくない事を続けても人生楽しくない。だから、自分が欲しいものをいきなり最初に作るのがよい。他人を笑わせれそうとか、情熱が続けばなんでもいい。ちなみに最初に作ったものはどうせ途中で辞めるので、あまり長い期間の間に情熱が続くものとか、スタートアップ的には考える必要ないと思う。

よく、まずhtmlから勉強してみたらいいのかなという事も聞かれる。そういう一般的な手順はどうでもよいのである。自分が作りたいものを先に決めて、それに必要なものだけ逆算すればいいと思います。

なので、最初にどんな言語から始めればいいかとかは考えずに、作りたいもの、欲しいもの、情熱が続きそうなものを決めて、それに必要な言語を調べればいい。その頃には選択肢がある程度絞れているから、選ぶのも楽だし。

まず基礎から始めるかと考えて、データベースとか、なになにの基礎とか、猿でも分かるなんたらなんたらの本から始めるかとか、これとこれを読んだら分かるだろうと勉強チックな感じで進めると挫折確率が高まる。別に技術者試験のテストを受けるわけでもないし、CSの学位を取るわけでもないので、楽しく、挫折せず、継続させるの3点だけに集中するのがよい。

例えば、自分が欲しいものがモバイルアプリだったら、iPhoneとかAndroidアプリを作ればいい。Webサービスでもいいし、ゲームが作りたければゲームでもよいし。

自分の場合、本当に初めての時、実はプログラミングの入門書を買って、こつこつ毎日進めていた。死ぬほど退屈で苦行で、レッスン4ぐらいに進んだ頃にはレッスン2の内容は忘れていた。実践で書いてないから高速で内容が頭から消えて行く。いつ使うかも想像できないメソッドとかを順番に覚えるのもやる気がでなかった。

これで、2回ぐらい挫折しました。でも、めんどくさいから作りたいものを決めて、それに必要なものだけその都度調べるというやり方に変えると、一気に面白くなり今に至ります。確か、ポールグレアムのエッセイに、最初からいきなり作り始めろと書いてたのがきっかけだったような。

さて、情熱が続きそうなものは技術が難しすぎてできないよと反論がきそうだ。うーむ、確かに。これは難しい問題である。自分も小さな頃からどこでもドアが欲しいけど、技術的に難しそうで、いきなりどこでもドアを目指したら挫折確率は限りなく高まる。

ここでは、とにかく簡単そうで、なおかつ自分に役立つものか、あるいは笑えるものを作るのはどうでしょうか。サービスと考えるよりも、特定の用途に絞るといいかもしれない。とにかく、小さな分野にまで切り詰めると、そこまで難しくないものに収まると思う。ジョークアプリとかいいかも。簡単で、モチベーションが湧きそうだったらなんでもいい。

さて、だいたい絞れてきたら、それに必要な言語も現実的には複数まで絞られると思う。例えば、Webサービス系だったらPHP、Ruby,Pythonとか。どれを選ぶかに迷ったら、身近に教えてくれそうな人が得意な言語にすればいい。

ところがどっこい、そんな人は普通まわりにいないのが現実。もし周りに教えてくれる人がいたら、とても幸せだと思う。僕の場合、プログラマの知り合いは皆無だったので、入門書籍が豊富な言語という基準で選びました。

ちなみに、たまたまプログラマの知り合いがいたとして、その人にお勧めの言語を聞くとします。十中八九、その人は自分の好きな言語に誘導します。別に自分が作りたいものに必要な言語であれば丁度いいのですが、下手すれば、モバイルアプリ作りたいのにWebサービスしか作れない言語から始めるといいよというアドバイスをもらうかもしれない。注意。

例えば、僕がPHPやってた時に相談を受けた時は、「PHPでWebサービスするのが最初はいいよ、htmlもcssも基本だし。」と誘導尋問してました。最近はiOSアプリ作っているので、「今ならiPhoneアプリだよ。Xcodeが凄く使いやすいし、アンドロイドみたいにいろんな機種に対応しなくてよいから楽だよ。」とか誘導します。

僕の場合、なんで誘導するかというと、単純に知り合いが興味を持ってるならプログラム仲間を増やすチャンスだと目をぎらつかせからです。まあ、熱心に教えてくれる人がいて、Web系でも作りたいもののアイデアがあるとか、どっちでもよい場合は臨機応変に判断すればOK。

とりあえず、言語（技術）から選んで、そこを出発点にすると挫折確率が高まるので注意。

ようやく、自分のやる気が出て、なおかつ簡単な作るモノのアイデアと、言語も決まったとします。ここで、次にぶち当たる壁は、こういう動作をさせたいけど、そもそもなにを勉強すればいいか検討もつかないというジレンマです。

ここは難しい。ここは詳しい人が近くにいると凄く助かる。検索ワードを教えてくれるだけでも仏様のように感謝したくなる。でも、そんなラッキーな境遇にはいないのが現実。こんな時に、技術書を複数買っていると役に立つ。

慣れてくるとネットで検索したほうが早いけど、初期段階では網羅的に方法論を書いている入門者はもの凄い力を発揮します。技術書は高いけど、似たような内容のものを何冊も買うと挫折確率が低くなる。もしお金がなくて、都内に住んでたら大型書店で立ち読みでもいい。

ここのポイントは、自分がこういう動作をさせたいという目的があるので、それについて書いている箇所を数冊の本から探し当てるのです。数冊買っても全部読む必要はなくて、必要な時に串刺し検索みたいにピンポイントで解説してるかを探し当てる。辞書的に使う。

さらに、同じ技術の解説でも、最初はいろいろな角度から解説してくれると一冊目で理解できなくても、三冊目ぐらいで分かる可能性が高いので数冊あると挫折確率がまた低くなる。せっかく実装させたい動作がはっきりして、学習意欲が高まったのにやり方がわからないのはもったいない。

どうしても分からなければ、出来る限り内容を詳しく書いて、誰かが答えてくれるかもという願いを込めて掲示板で質問するしかない。ところがどっこい、頑張って詳しく内容を書いても誰も答えてくれない確率が高いので、自分で検索したり、本を横断したほうが近道だったりします。

最後に、挫折確率を下げるやり方として、なんでも適当におおざっぱに進めていくのがよい。細かい部分は後から修正するという信念で、とにかく最小限の機能に絞って動くものを、デザインはひどくてもよいから早く作ると。

コードも汚くてよいから、動けばよいという哲学で進めると、ここでもまた挫折確率が低くなる。綺麗なコードに書き直すとか、そういうのは後々勉強すればよいので、はやくリリースさせるのを優先する。次は次はというテンポを作って、途中で止まっちゃわないように。

大抵の人の最初の壁となるのは、if構文とかループとか基礎的なプログラミング構文でさえもない。環境構築であったり、サーバへのアップ方法であったり。iPhoneアプリだったらXcodeの使い方であったり、Developer登録であったり、実機への転送方法であったりする。

こういう事は、実際にその都度、検索しながら覚えていくしかない。基礎をすっ飛ばして、こんなやり方で後から困らないの？と心配になるかもしれない。でも、技術的な事を心配する前に、その他の要素で挫折する可能性は限りなく高い。

そもそも、最初の段階で、これをまず覚えて、これも重要でと、あれこれ考えるとめんどくさくなって挫折すると思います。

基礎固めや発展的な知識は慣れてくるとそのうち興味が湧いてきて、自分からいろいろと知りたくなってくると思う。なので、最初はあまり心配せずに、ある程度興味を持ってきてから言語について学んだり、他人の書き方を参考にしたり、リファクタリングとかデザインパターンを学んだらいいと思う。

*家計簿と読み上げのアプリ作ってます。自己紹介と過去ログはこちら。

サービスのアイデアを考える時、たくさんある中からどれにするかはみんな悩むと思う。悩んだ時は情熱を基準に選べばよいと考えるしだいであります。ビジネスモデルやマーケットもとても重要だけど、当人の情熱とは比較できない。

感情的な部分と、論理的な理由でなぜそう思うようになったか書いてみる。最初に感情的な理由から。

よいサービスを作るのには労力も時間もかかる。情熱がないと、強力な競合が出てきた時や、周りが理解してくれない時、なかなか収益源が見つからない時に、やる気をなくして違う事に移ると思うのである。

お金が儲からないと食っていけないけど、逆にお金がなくなって日銭稼ぎに他の仕事をしたとしても辞めたくないものとか、今の仕事を続けながら作った貴重な時間でやりたいぐらいの情熱を持つものがよいと思う。どうせ軌道に乗るまで時間かかるし。

また、お金よりも自分の情熱をモチベーションにしたほうがやる気も生産性も全然違う。もし途中で辞める事が物理的にできない状況でも、モチベーションがなくなると生産性は極端に下がるから、どうせいいものはできない。

自分はグルーポン系サービスのアラートサービスを2010年の12月から2011年の3月まで作ってました。もちろん、当時はやる気モリモリで毎日開発していたのだけど、思い描いていたような機能を搭載している類似サービスが出現した時にぴたりとやる気がなくなってしまった。

今思えば、自分が死ぬほど欲しいサービスというよりも、これが流行りそうだから誰かが作る前に早く作ろうという気持ちが強かった。

最初は、なんかWebサービス作りたいけどなにかよいアイデアないかな考えていました。マッシュアップアワードのAPIリストを眺めて、流行りそうなサービスを思いついたから作ったという経緯。それもYipitという海外のサービスのパクリが始まり。まあ、アイデアをパクる事は問題ないのだけど。

思い返すと日本でも絶対こういうサービスが出るから、早く作ろうという焦りみたいな気持ちが強かった。似たようなアイデアで、もっと上手に作ってくる競合が出た時点で簡単に諦めちゃうというオチでした。

この時、次に作るサービスは絶対に自分が死ぬほど欲しいサービスを作ろうと思った。毎日そればっかり考えて時間とエネルギーを注ぎ込むから、競合が出てきても逆に自分の選択肢が増えて嬉しいぐらいの分野がいい。

というわけで、2011年の3月に次になにを作ろうか考えていた時の話をしてみる。

その時は、いわゆるスケールしそうなアイデアとか、自分が面白いと思ってスタートアップ的なウケもよさそうなものもいろいろ選択肢としてはそれなりにあったのだ。でも、最終的にiPhoneアプリという一見こじんまりしちゃうけど、情熱度が高いLisgoを作ることに決めたのです。

他のアイデアは面白そうだなぐらいのレベルだったけど、Lisgoのアイデアは、何が問題で、どこが不満で、代替手段をあれこれ試しているけど、こんなのとても面倒だという具体的な部分まで分かっていた。

冷静に何度も考えて、どのサービスが実現したら自分の生活が大きく変わって、毎日使うかとなると、これ作るしかないわとなって、iPhoneアプリ開発のためにMacを買ったのです。

というのも、僕は読書もオーディオブックも好きで、AudibleもKindleも結構初期から前から試していた。でも、オーディオブックは便利だけど、読んでいる途中に気になる箇所を目で確認できない。

本は目が疲れたり、物理的に目や手を使いたくない時にオーディオブックみたいに耳で聞く事に移行できないのが多いに不満だ。Kindleの読み上げ機能は一番ビジョンに近かったけど、オーディオブック業界に圧力かけられて、ほとんど使えない有様だった。

しょうがないから、Web記事をPCの読み上げソフトでMp3化したり、本を裁断して100冊以上自作オーディオブックを作ってiPodで聞いてたりした。でも、死ぬほど面倒だし、本を目で読みたい時に、今はどのページだっけと目で確認しないといけない。

何を言いたいかというと、他のサービスのアイデアは「ああ、いいの思いついた、あったら便利かもしれない。実際にこんなのあるか調べてみるか。」みたいなものだったのにたいして、Lisgoのアイデアはすでに自力で代替手段を試しまくっていて、本当に困っていた。

ちょっと話が飛ぶけど、自分が欲しいサービスの場合は凄く有利だ。自分の問題を解決するサービスになるので、自分が最初の熱心なユーザになれる。ここでは、自分がユーザだと問題が圧倒的に理解しやすいという当たり前の話はおいておいて、サービスの焦点の話をしたい。

他の人にも喜ばれるかや、自分以外の視点で考えるために顧客インタビューをしないといけないけど、この時に自分が欲しいものという軸がないと、どの意見を優先するか悩みまくると思う。

実のところ、ある程度ターゲットを絞ってもユーザが10人いたら10通りのニーズがあるから、それぞれ微妙に違うことを言う。Aさんにとって一番重要なことは、Bさんにとってはどうでもよかったりする。ニーズを絞ったつもりでも、さらに細分化されていく。この時、自分が望むものの軸がないと、どのユーザを優先するかの基準が見つけにくい。

一番お金が儲かりそうなユーザに絞るというのはよさそうな指標だけど、どれが最終的にスケールしそうか予測するのは不可能だし、前述した通り情熱がなくなると途中で諦める。

リーンスタートアップが普及して、ユーザの行動やニーズを観察しながらピボットするという考えが主流になってきている。ユーザの反応を見ながらサービスを作っていくと、毎日が細かいピボットの連続であると思います。どういう時にピボットするべきで、どういう時に諦めずに方針を貫くべきかはみんな悩むし、よくある質問だ。

これは、誰にもわからない。最終的に正否は結果で判断される。どうせ、自分で考えないといけない。

だから、情熱が継続して、ビジョンがあるものを作ったほうがいい。競合相手がいても、自分が凄く欲しいものだったら、なんらかの部分に不満がでて、そこが突破口にもなるし。

結局、世の中は不確実な事が多くて、どれだけ頑張っても様々な理由で上手くいかないことが多いと思う。その時の流行りとか、周りの意見はそこそこにして、自分が困っている事を解決できるようなものを作ればよいと思います。

※参考リンク
Before product-market fit, find passion-market fit

*家計簿と読み上げのアプリ作ってます。自己紹介と過去ログはこちら。