新しい便利なモノは新しい問題も作る


最近、Dモーニングっていうのを購読したんですよ。モーニングっていう雑誌がiPhoneやiPadで読み放題、一ヶ月に500円っていう値付けのやつ。

これ、モーニング系の漫画好きな人ならモトが取れるし、きっかけは友達に熱烈に勧められて、「た、たしかにそれはいいかも。。」と思って一週間まえから始めてみた。

使ってみた感想はなかなかいい!雑誌買ったらゴミになるけど、スマホならいつでもどこでも、気軽に読めるし、バックナンバーも自由にダウンロードできる。

僕は毎週木曜日にチャンピオンの刃牙を立ち読みするのが一週間の楽しみだったんだけど、毎週の楽しみがまたひとつ増えました。

と、こういう普通の日記を書こうと思ったんじゃなくて、このDモーニングの重要な設計について書きたい。

漫画の掲載順が重要になる

この、Dモーニング、雑誌版に比べて、漫画の掲載順が死ぬほど重要になるんです。それぞれの漫画のページビューにとって。

というのも、Dモーニングの設計はまず低画質版を一気に全部ダウンロードされると、すべての漫画が”とりあえず”アプリで読めるようになり始める。

しかし、低画質版だとちょっと読む気にならないレベル。だから、バックグラウンドで高画質版をアプリがダウンロードし始めるので、高画質版が完了した漫画から読むようになりました。

これ、高画質版のダウンロードは漫画の掲載順なんですよ。

普通、雑誌の掲載順も読まれやすい漫画に影響はあるだろうけど、この高画質版のダウンロード完了の順番が関係してくると、もう圧倒的に影響がでかい。

だって、雑誌ならペラペラっと数秒で終わるところが、高画質版のダウンロードになると、数分、電波悪いともっとかかるわけですよ。

これなら、Dモーニングの掲載順が一番後ろの漫画は読まれる可能性がすごい低くなるだろうと簡単に予想できる。

読まれる可能性が低くなると、読書投票にも影響するし、電子書籍版はページビューとかの数値も計測してるなら、そこにも大きく影響するはず。

今後、電子書籍版で読むユーザがほとんどになった時、この設計のままだと大御所の作者が掲載順の前で有利になるから、新しい漫画の読まれる確率や、後ろに回された漫画の逆転は雑誌時代に比べてはるかに難しくなるかもしれない。

App Storeでランキング上位になれば、ずっと上位が続きやすく、新しいアプリがなかなか下克上しにくいみたいな。

じゃあ、どうすりゃいいか。お気に入り機能とかで、高画質版ダウンロード順をカスタマイズできるとか、いろいろな方法があるとは思うんだけど、僕は、別にDモーニングの設計はこうするべきだってことをここで書きたいわけでもないんですよ。

何を思ったかというと、使うモノの設計しだいで、人間の行動が大きく影響するから、その業界のビジネスの新陳代謝や発展にどれだけ影響するかを意識しながらアップデートしていくと、いい未来がやってくるんじゃないかと思ったわけです。

ニコラスカーの話

これをすごく意識させられたのは、ニコラスカーの、「ネットバカ」という本です。

毎回、ニコラスカーの本はクソみたいなタイトルを翻訳版はつけられて、カー先生に出版社は恨みでもあるのかと勘ぐっていますが、この本は素晴らしい本です。

人類が、道具の発達によって、行動様式、脳みその機能、身体機能がどう変わっていったかという話を、活版印刷の登場からGoogleまでかなり深く洞察してる。

例えば、パソコンを使うようになって漢字は書けなくなるし、GoogleMapで地図を読めない人が増えるとか、そんなのは誰でも思いつく。

で、そのマイナス面はみんな直感的にわかっていて、僕だって「別に漢字書けなくても、パソコン時代だから特にデメリット少ないし。」と思ってるわけです。

ただ、世の中にはデメリットがないと思いこんでたり、まったく気づいていないデメリットが往々にしてあったりするということもあります。

最近読んだ、「失われてゆく、我々の内なる細菌」という本では、画期的な発明と賞賛され、昔なら死んでいた病気から人類を救っている抗生物質や、家畜に使われる成長促進剤が、昔ならほとんどなかったアレルギーなどの新しい問題の原因になっているという話を書いていた。

なにか便利なものを作ると、想像の範囲を超えたデメリットや結果が発生する可能性がよくあると。そういうことをモノづくりする時は意識して、改良し続けるのが重要だなと思う。

電子書籍 月額読み放題サービス

音楽ではSpotifyやAppleMusicなど、当たり前になってきた月額定額での聞き放題サービス。

これに似た、電子書籍の読み放題サービスをアマゾンがこの前発表してた。

音楽では聞かれた曲数によってクリエイターに収益配分が分配されるが、書籍だとさらに複雑になる。

ニコラスカーのこのブログ記事では、Amazonの新サービスのルールを適用すると、書籍業界にどういう影響が出るかを詳細に書いてて面白い。

How to write a book when you’re paid by the page

例えば、読んだページ数によって、作者に分配がされ、カウントは最初の読んだ時だけというルール。

これなら、サクサクと読みやすく、続きが気になる本が圧倒的に有利になり、儲けるためにはそういうジャンルばかりになりやすい。

何度もページを読み返して、深く味わう種類の本にはまったく儲からないプラットフォームになるので、そういう本は消えていく。

紙の本から電子書籍になり、その次は放題サービスと、プラットフォームが変わるたびに、そのルールが生態系を変えちゃう可能性があります。

ふだんの生活でどうすりゃいいか

普通は大きな影響力を持つプラットフォームを作るわけでもないので、なにかを利用する時のほうが意識すると面白いかもしれない。

なにか、便利なものを買ったり、使い始めたりした時、一見想像できるデメリットや副作用はなさそうで、後々顔を出してくるネガティブな側面に気づくとか。

逆に、すごく不便な土地や、快適とは思えない生活をしばらくしたら、今まで頭の中だけではわからなかった事が実感できたり。最近そういうことが自分にあって面白かった。


*シンプルなアプリ作ってます

ブログ更新をお知らせ。ブログで書けない話、最近読んだ面白い記事や本も紹介します。

Parse Meetup Tokyoが7月24日に六本木で開催


先日、ParseのエバンジェリストであるEricさんに会いに行ってきたという記事を書いたけど、7月24日にParse Meetupを六本木で開催するらしい。

https://parsemeetuptokyo.splashthat.com/

Parse使ってるけど、Parse周りで情報交換したいとかいう人はオススメだと思う。

しかし、このイベントページ見た人はこう思うはずだ。

「あれ、これ全部英語なの?ここ、日本だし、僕日本人なんだけど?」

そうなんです。今のところ、英語オンリーの予定みたいだ。(同時通訳してくれる人が現れる可能性もあるけど)

場所は六本木のFacebookオフィスだから、この前お邪魔したあの高そうなビルですね。アークヒルズ仙谷山の森ビルだから、あのみんながイメージする、映画館とか隣接するでっかいほうの森ビルとは違うので注意。

Ericさんいわく、このビルの賃料はサンフランシスコより高いぜ!だとか。

このイベント、第一回なのもあり、かなり濃いメンツが集まりそうな予感がするので面白いと思う。ちなみに、このイベントページを作るサービスいいですね。Splashというのか。
https://www.splashthat.com/


*シンプルなアプリ作ってます

ブログ更新をお知らせ。ブログで書けない話、最近読んだ面白い記事や本も紹介します。

Mixpanelでアプリ内に告知ポップを出す


前回、AppStoreに依存しないメディアの価値という記事を書きました。

ただ、アプリ宣伝にはやっぱ自分のアプリ内で宣伝するのが効果あるなという話になってしまった。

ブログ、Twitter、メルマガなどは、AppStoreに依存しない長期的な資産になるけど、とりあえず今回はアプリ内で他のアプリを宣伝する方法を考えてみる。

これは、アプリが全てリジェクトされたら終了なので、AppStoreに思いっきり依存するのだが。。

アプリ内でスマートに宣伝したい

さて、スマートに宣伝するというのは、スパムにならないように宣伝するとも言い換えられる。このバランスが非常に難しいので、常に気を使わないといけないけど、いろいろ考えました。

まず、自分のアプリの例でいうと、それぞれのアプリの設定画面に、「開発者のアプリ」というボタンを設定してる。このボタンをタップすると、自分のアプリ一覧が表示される画面が出る。

こうやって、ささやかながら、よければこんなのも作ってるから、ダウンロードしちゃってくださいねという動線をこしらえているわけです。

ちなみに、設定画面の奥底に設置しているだけでも、意外にコアなユーザは他のアプリも試してくれたりする。なぜかというと、Zenyのレビュー欄で、こんな書き込みがよくあるから。

「この作者さんのアプリは使いやすい!もうひとつのListTimerも使ってます!」

こういう書き込みを見ていると、うーむ、やっぱり親和性の高いアプリだと、どっちも使ってくれる人が多いんだなという印象を持った。

でも、設定画面の奥底の「開発者のアプリ」みたいなボタンをタップして、他のアプリまで覗いてくれる人は少ないと思う。

なので、ここはもっと、こちらから知らせたい!というのがこっちの理屈なんだけど、どうすればよいか。

プッシュ通知?

まず、思いつくのがこれ。プッシュ通知で他のアプリをオススメする。

ただ、これ、そもそもアップルの規約でプロモーションに使うのは禁止ってあるんですよね。あんま守られてない気もするけど。

さらに、プッシュ通知て、プッシュ通知の許可を取ってないといけないし、アプリがバックグラウンドにある時にお知らせされても鬱陶しい。

というわけで、プッシュ通知はボツにしました。

アプリを開いた時に宣伝する

例えば、Zenyをある程度の期間使ってくれている人に、アプリを開いた時にListTimerを紹介する、というようなダイアログを出したい。

もちろん、紹介するアプリであるListTimerをすでにインストールしている人は覗いて。

例えば、ListTimerがアップデートしてさらに便利になったタイミングとかだと、紹介する理由がちょっとできてやりやすい。

先日Lineを開いてたら、Line Musicの宣伝が出てきたんだけど、イメージとしてはこんな感じ。

ただ、こういう機能って、サーバ側からの操作が必要なので、サーバーサイド用意しないといけないんですね。自分でサーバーサイド準備するの面倒じゃないですか。

みんなが欲しがるような機能はすでに誰かが作っているはずだ。

ちなみに、昔Githubでこのものズバリのライブラリを見た気がするけど、探し出せなかった。。なんだっけなあと調べていると、一番使いやすそうな機能をMixpanelが提供してました。

MixpanelのIn-App-Notifications

MixpanelのIn-App-Notifications。これがそのものズバリです。

他のアプリの宣伝にも使えるし、その他の重要な通知にも使える。最新版にはバグがあるので、こちらを参照してねとか。

画像とボタン付きのポップアップをアプリ内で表示できる。こりゃ便利。というわけで、ここからはMixpanelのこの機能を紹介していこうと思う。

表示の仕方は2つあって、「Fullscreen」と「Mini」。

正直の写真では画像、タイトル、詳細、ボタンとカスタマイズしているFullscreenのほう。Web上ですごくカスタマイズしやすい。ボタンをタップすると、特定のページに飛ばしたり、deeplinkでアプリの特定の場所に飛ばしたりできる。

今回は、AppStoreのダウンロードリンクに飛ぶようにしてみた。これをアプリ内でポップさせるとこのような感じになる。

ちなみに、「Mini」のほうは、アプリの下にメッセージだけ表示できるもので、任意の秒数がたった後に勝手に消える形式。閉じるボタンをタップしないと消えない設定にもできる。

ただ、モーダルとか、アプリ内で画面転移しても自動で消えるので、なにかの操作中に、ぴょこっと下にでて、気づかないうちに画面転移しちゃって同時に消えてしまうという可能性があるので、そこがネックですね。

セグメントする

Mixpanelの便利なところは、闇雲に全員に出すのではなく、ちゃんとセグメント区切ってポップを表示させることができる。

例えば、最近、数日の間にアプリを開いているユーザだとか、英語のメッセージを表示させたいから、言語が英語設定の人だけとか。

僕の場合、ListTimerから家計簿プリのZenyを宣伝する場合、すでにZenyをインストールしている人には宣伝を表示したくない。

この場合、Mixpanelにはpeople設定というのがあり、ZenyのURLスキーム使って、アプリをすでにインストールしているかどうかをAppDelegateで下記のようにチェックしてみた。

// Set indetify and people profile to use in-app notifications
[mixpanel identify:mixpanel.distinctId];

// Check if Zeny installed
if ([[UIApplication sharedApplication] canOpenURL:[NSURL URLWithString:@”zeny:”]]) {
[mixpanel.people set:@{@”Zeny”: @”Installed”}];
} else {
[mixpanel.people set:@{@”Zeny”: @”NotInstalled”}];
}

このコードを書いておけば、Mixpanelのページで後からセグメントが切れる。

国が日本で、なおかつListTimerをインストールしてない人にMixpanel内でセグメント区切るとこんな感じになる。

ちなみに、一度送ったメッセージは同じ端末には送らないようになっているので、重複して送信しちゃうこともないらしい。こりゃ便利。

ついにで、宣伝ポップを表示して、ボタンをタップした割合が何パーセントだとか、そういう分析もAnalyticsで出来る。iTunesのAnalyticsリンクと組み合わせたら、実際にアプリをインストールまで行ったコンバージョンも測れそうだ。

無料では26,000デバイスまで

こんなに便利なMixpanelだけど、基本は有料サービスなので、無料だと制限がある。

このIn-App-NotificationsはMixpanelのPeopleっていう端末毎にセグメントする機能を使わないと送れないんだけど、このPeopleの数が制限あるんですよ。

価格表はこちら。https://mixpanel.com/pricing/#people

このMixpanelパートナーってのは、自分のHPにmixpanelのリンクを設定したら簡単になれるから、tumblerでも登録して、適当にリンクを貼ればOKなゆるいもの。

なので、実質26,000デバイスまでが無料での制限となる。

これ、月に26,000の制限だから、毎月ユーザー追加していけるって意味なのか?とも思って、メールしてみたけど、やっぱり、最大の端末数が26,000であって、それ以上は無料では追加できないようだ。人生そう甘くなかった。

うーん、50,000まで使えるのが一番安い有料プランなんだけど、月に$150はこれだけのために出せないかなあ。

実際に自分でやってみて、どの程度の訴状効果が生まれたかとかをまた書いてみたいので、このシリーズは続くはず。

ちなみに、Mixpanelなどのデータ分析に興味ある人は、LeanAnalyticsについてこちらの記事もどうぞ。
虚構の数字と改善に繋がる数字


*シンプルなアプリ作ってます

ブログ更新をお知らせ。ブログで書けない話、最近読んだ面白い記事や本も紹介します。

AppStoreに依存しないメディアの価値


最近読んだ本で、ピカイチに面白い本がありました。それは、ドワンゴの会長が書いた鈴木さんにも分かるネットの未来という本。

これはネットの未来や仮想通貨、ネットの国境の話など、とにかく全ページ面白いのだけど、個人でアプリを出している者として、「やっぱりそうだよな」という部分があった。

それは、App Storeなどのプラットフォームに影響されないプロモーションの場をクリエイターは持つべきというところ。

確かにApp Storeでのプロモーション方法って限られてて、結局ランキングに載るか、アップルに特集してもらうぐらいなんですね。だから、自分のTwitterとかブログで宣伝できる人は強い。

AppStoreでランキング上位のアプリだったとしても、アルゴリズムが変更されて一気に落ちる場合もあるし、Androidを出す時はApp Storeでの人気のレバレッジが効かない。

なにより、AppStoreが衰退した時に、一からやりなおしになっちゃう。

というわけで、前からそうだよなと思いながら面倒くさがってたこの問題についてちょっと考えてみました。

ブログでメーリス作る?

まず考えつくのが基本のこれです。RSSが下火になり、メールマーケティングの価値が復活している昨今です。TwitterやFacebookだと新規サービス作った時でも、流れて見逃される可能性高いし。

この流れに自分も乗ってみようかなと。

でも、僕、メルマガに書くほどの価値のあることなんてないんですね。困った。でも、ブログの読書にこちらから発信できる方法をもっておくと、新しい事を始める時にお知らせできる。

でも、別に書くことなんてないし、書くのも面倒だ。

というわけで、単純にこのブログ記事の新着を通知するのと同時に、ブログで書けなかった事を補足として付け足すぐらいのメルマガでも実験的にやろうかと思った。

あとは、最近読んで面白かったネットの記事があれば載せる程度の軽い感じのものを。

僕はどっかのメルマガ購読してみても、すぐに解除しちゃうんだけど、今でも続いているのは、iOS Dev Weekly, Benedict’s Newsletterの二つぐらい。

特に、Benedictのほうは、毎回モバイル業界の鋭い分析を交えた自身のブログと、その週の面白いネット記事を紹介するので、こういうのに近いのがやりたいけど、俺には無理だなあと思いながら読んでます。

これでアプリがダウンロードされんの?

で、しばらく上記のようなことを考えてたんだけど、ふと気付きました。

これ、万が一、1000人ぐらい登録してくれたとしても、新作のアプリ出すなんて年に一回か二回。その時の最初の通知に使えるだけってどうなのかと。

アプリとかサービスって、初動の人気より、結局重要なのはオーガニックなダウンロードであり、ニュースサイトに取り上げられなくなったあとの口コミによる人気の継続なんですよね。

となると、結局、みんなが友達に勧めてくれるようなよいもの作れば、SNSがここまで普及した現在ではプロモーションの場を持たなくても別にいいんじゃないかと。こういう考えもできます。

と、思ったんだけど、これに反する結果が自分のアプリではあるんです。

まず知られないと話にならない

自分のアプリは一応、英語と日本語に対応してるんだけど、英語でもそこそこ頑張ってブログ書いたり、ランディングページ作ったLisgoVoicepaperはユーザ比率が今では若干海外のほうが多いんです。

当初は日本のようが8割ぐらいだったけど、ある程度海外のユーザも使ってもらえてたので、いつの間にかユーザの割合が半分ぐらい海外になってた。ちなみに、英語圏のアメリカ、イギリス、カナダ、オーストラリアなどがほとんど。

そして、その後に作った、TaxnoteZenyListTimerJetDoはほぼ95%以上が日本のユーザです。英語対応してるけど。

JetDoとかListTimerなんて、日本じゃなくても世界共通で使えるアプリのはずで、特に最高傑作であるListTimerなんてもっと日本以外でも使ってほしいんですよ。

これ、なんでだろなと思ったら、やっぱ、LisgoやVoicepaperに比べて海外向けの宣伝行為を一切やってないから、誰にも知られなくて、口コミが発生する前の段階までも到達しないんじゃないかと。そうだ、そうに違いない。たぶん。

と考えると、周り回って、ブログとかTwitterとか、クリエイター側が発信できる場を持つってやっぱ重要ですね。

それか、ニュースサイトに取り上げられるなり、広告にお金を使うなり、まずは知ってもらうという努力って大事なんだなという当たり前の事実に行きつきます。

いいものを作れば勝手にSNSで広まる時代ではあるけれど、最初のアーリーアダプターへ伝える道筋はあるにこしたことはないと。

長期的な話になる

ちなみに、この話はプラットフォームに依存しない宣伝の場を作るという話だったので、どうしても長期的な話になります。

実は、アプリ時代には、自分のアプリ内で、自分が作った他のアプリを紹介する方法が一番即効性がある。

ダウンロードにインセンティブを与えると規約違反なので注意が必要だけど、任天堂のマリオシリーズが好きな人に、同じ任天堂のマリオカートを紹介するのは親和性も高くてよい。

というわけで、自分のアプリ内で、プッシュ通知以外の方法で、重要なニュースを伝えたり、他のアプリのリリースを伝える簡単な方法を研究したので、次の機会に書きます。


*シンプルなアプリ作ってます

ブログ更新をお知らせ。ブログで書けない話、最近読んだ面白い記事や本も紹介します。

ParseのEricさんと日本のコミュニティについて話してきた


先日、Facebookが買収したモバイル開発者向けツール、ParseのエバンジェリストであるEric Nakagawaさんと会ってきた。

先日シリコンバレーに初めて行った時、一緒に行った写真右の加藤さんの友達のジョージさんと飯食って、そっからジョージさんが繋げてくれたという経緯でした。

東京にあるFacebookのオフィスに遊びに行ったんだけど、アーク森ビルとかいう賃料高そうなオフィスだった。Facebook金あるな。

Facebook Japanのオフィス

情熱に心動かされる

なによりも印象に残っているのは、EricさんのParseに対する情熱だ。もう、エバンジェリストはこうあるべきというお手本のようなお人で、Parseをどうやって広めていくかを凄い考えている。

どうすれば、日本でParse開発者が助け合うようなコミュニティーができるかを熱っぽく語っていて、話出したら止まらないエネルギーに溢れていた。なんか、こういう情熱があると、人間誰しも応援したくなると思う。

ちなみにEricさんは、シリコンバレーで起業して会社を売却した成功者なのでお金持ちなんだけど、自分もParseをずっと使ってきていて、今でも個人で小さなプロダクトを作る時にParseを使っているらしい。

「Parseが好きだし、Parseに入る前から使っていてよく知っていた。Parseのようなサービスがあれば、近い将来、デザイナとエンジニアの二人だけでも世界的に大きなサービスを作ることが出来るようになると思う。」という話を熱っぽく語っていた。

これは、僕も以前から思っていたことで、Parseのようなバックエンドやスケールを担当してくれるサービスを使い、下手したら一人で相当スケールする部分までやっていけるようになるんじゃないだろうか。

とにかく感じたのは、EricさんのParseラブな情熱で、どうすれば日本でもParseがもっと広がるか、よいParseコミュニティーが出来上がるかということを考えてた。

僕も、Parseは登場した時から、「こいつはすげえサービスだ!」と思い、このブログで何回か取り上げたりLisgoで月額課金試す時に使ったり、今せっせと作ってる新しいアプリでも使っている。

なので、Ericさんの話をうんうん聞きながら、自分の頭で、うーん、どうすればParseを日本で広めるいい方法はなんだろうなとJetDoでメモとりながら考えてた。

加藤さんと一緒に、こういうやり方はええんじゃないだろかとか、いろいろ話してたわけです。

Ericさんの存在と情熱を伝えるには

日本人からしたら、Parseって海外のサービスだし、どうしても遠く感じるんですよね。特に、データベースを扱うし、モバイルアプリだとWebサービスと違って簡単に後からスイッチができない。バージョンアップもインストールしてもらう必要があるし。

となると、どうしても海外のよくわからないサービスだと顔が見えづらいし、なんかあった時のサポートも不安という心理になってしまう。

だから、Ericさんのようなエバンジェリストの存在が重要で、最近の開発者向けサービスのスタートアップはコミュニティーマネージャ的な職業をすごく重視している。

実際僕も、Parseは便利なサービスだけど、なんか問題が起きた時にあまりノウハウもまだまだ少ないし、不安だなあと思っていた。

でも、「なんでも聞いてくれ!」みたいな情熱のある人がエバンジェリストとしていると凄く大きい。こういう情熱を持って開発者をサポートしたいという人がParseの中にいるんだと認知するだけでもでかいなあと話聞きながら思いました。

じゃあ具体的にどうすりゃいいのかなと。

イベントなどで露出する

まず真っ先に考え付くのがこれだと思う。

日本には開発者の勉強会が多く、そこで登壇して実際に日本の開発者と顔を会わせる機会があるだけで、だいぶ違う。Ericさんの母国語は英語で言葉の壁はあるのだけど、それでも大きい。

こういう事を言うと、「来日した時にイベントなどに出てもいいんだけど、よくあるのはさっと発表して、さっと帰るだけのマーケティング色が強いパターンが多いので、それは個人的に好きじゃないんだよね。ちゃんと、開発者の人たちと向き合って、コミュニティに貢献したい。」

というような返事が返ってきた。うーむ、自分が開発者としてやってきたのもあり、いろいろ考えているんですな。

いっそ、日本人のエバンジェリストを雇う

これは、適任者が見つかるかとか、ハードルが高いんだけど、最も効果的だとは思う。

例えば、Realmというモバイル向けデータベースのスタートアップに、iOS界ではGod的な存在である岸川さんが少し前にジョインした。

これは凄く大きな効果があって、iOS開発者の中では一気にRealm使ってみようかなという人が増えたと思う。

日本でのRealm関連の勉強会も増えたし、Realm関連の日本語での記事もよく見る気がするし、今までアメリカのスタートアップのサービスという遠い存在だったものが、みんな知っている岸川さんが窓口になったという心理的安心感はでかい。

でも、岸川さんみたいに技術力が高くて、なおかつコミュニティに顔が広い適任者なんてそうそういないよねっていうのは現実なので、他の案もいろいろ考えました。

技術系サイトのインタビューに出る

これならそこまで大変じゃない。

Ericさんがエンジニア向けサイトのインタビューに出て、「これから日本のParseコミュニティをサポートしていきたい」といった、僕たちにランチしながら熱く語ったような話をするだけでもでかい。

ああ、日本人のコミュニティも考えてくれてるんだなとも思うだろうし、Ericさんが日本に来日してる時に、Parseユーザ向けのオフィスアワーをそこで宣伝してもよいし。

来る人をある程度スクリーニングするという意味では、ParseのTipsをブログで書いてくれた人を優先的に抽選でオフィスアワーとか。

日本語ブログ、ヘルプの翻訳家

これはコストかかるからすぐにはできないけど、確実に効果ある。

ちなみに、Parseを使って、将来スケールした時に、AWSとかに移行するノウハウを詳しく書いて欲しいと個人的に提案しました。

ほとんどのサービスは失敗するので、Parseから移行する必要なく終わるだろうけど、人間心理としてParseを導入する時に、誰もがスケールした時のことを考えるんです。

その時、他のサーバに移行する時のノウハウがネット上にはあまりないので、それなら最初からAWS使おっかていう人は少なくないと思う。

もちろん、大きくなってもParseを使っていくという選択肢を取るかもしれないけど、移行の方法を詳しく解説することにより、逆にParseを使い始めやすくなるといった考えを話した。

Parseのコミュニティ

ちなみに、Parse使っている人の不安点として、以前あったParseの公式フォーラムが止まっていて、StackOverFlowで質問してくれみたいになってるんですよね。

これが、Parse公式のサポートがほぼ停止しちゃってんじゃないかっていう不安感あるという事を話したら、現在はParse Googleグループが一番活発なサポートコミュニティらしい。知らなかった。

最近ではサポートにSlackも使われ始めてるらしい。確かに開発者向けサービスなら相性よさそうだ。

ちなみに、最近できたFacebookグループ、Parse.com Developers Japanもあります。ここはほぼ日本語。Ericさんも入っている。

Parseを会社サービスの規模で運用しているnohanaのエンジニアの人の話とか、すげえ内容が濃くてやばい。この前、第一回の飲み会を恵比寿でやったのだけど、相談できるコミュニティがあるとやっぱいいですね。

Ericさんが登場するAsk Parse Anything。


*シンプルなアプリ作ってます

ブログ更新をお知らせ。ブログで書けない話、最近読んだ面白い記事や本も紹介します。

かくかくしかじか最終巻で泣いた


かくかくしかじか 最終巻がKindleで出たのでやっと読めた。泣いた。

物語で泣いた記憶がほぼなくて、人生でも片手で数えられる数なんだけど、この漫画は泣いてしもた。

僕の一番の趣味は漫画なんだけど、歴代一位はレベルEだった。この、かくかくしかじかが近年でベスト1なのは間違いないとして、もしかしたら歴代一位のレベルEと並ぶぐらい好きかもしれない。

ちなみに、作者のインタビューを読んでいると、この漫画は思い出すのが辛いから、あまり時間をかけずに速攻でネーム書いて、がががっと書いていく方式だったらしい。天才か。いや、そういうあまり考えずに、気持ちの赴くままに書いたものから傑作が生まれることも多いのだが、うーむ。

そういや、奥田民生のマシュマロも、ふふふーんと適当に作ったらヒットしたとか言ってた。マシュマロは奥田民生の歌で一番好きだ。

ブログも頑張って推敲して書いたのに全然読まれなくて、適当にえいやっと書いたらバズるってのはあるあるです。なんか、あまり気張らずに、ブログも適当に書きなぐっているぐらいが精神衛生上よいし、楽しいかもしれない。

そういや、絶対に書いた文章を書き直さない主義の古代哲学者がいたな。

いくら推敲しても、中身が面白くなければダメで、中身のエネルギーがありさえすれば、がががっと書いても面白いものができるのかもしれない。

そういう意味で、かくかくしかじかは作者の思い入れというか、人生の中での重さというのは凄く伝わる。あまりネームに時間をかけてなかったとしても、中身のエネルギー量は半端なかったのかも。

話は戻るけど、かくかくしかじかの中で、つらい時も、漫画を書いていたから救われたというのにすごい共感してしまった。なにか毎日やることがあるって本当によくて、常にハッピーそうだなとかよく言われる僕も、いろいろ落ち込むこととかはあるわけです。

そんな時も、毎日、開発だったり、日々のやることをかかさずやらないといけないというルーチンワークがあって、こういうのがあると、本当に救われるってのはあるんですね。打ち込む仕事があるってのは救いにもなるというのが凄くよくわかる。


*シンプルなアプリ作ってます

ブログ更新をお知らせ。ブログで書けない話、最近読んだ面白い記事や本も紹介します。

需要調査と作り始めるタイミング


リーンスタートアップという仮説検証を繰り返す新規事業の手法があります。

これは新規事業開発の考え方として必読の内容なんだけど、小さく作ってさっさとリリースする手法であると同時に、製品を作る前に顧客を探せという手法でもあるのです。

理想としては、需要調査で潜在顧客が見つかり、小さな製品を素早くリリースするという流れなんだけど、いつまでも仮説検証を続けて、なかなか製品を作り始めないという落とし穴がある。

というか、リーンスタートアップを勉強した後に僕自身がハマった落とし穴で、あるあるじゃないだろうか。

リーンスタートアップの父的な存在で顧客開発モデルを広めたスティーブブランクも、仮説検証のインタビューが十分終わり製品開発を始めてよい時期なのに、この落とし穴にハマる生徒がいるよとブログで書いてた。

この落とし穴にハマる原因は恐怖が関係してる。

需要があるかわからない恐怖

リーンスタートアップ始めて知った時は、「おお、この手法通りにやれば簡単やないか。素晴らしい!」と気分が乗ってくる。

というのも、アプリやサービスを作る時、一番の心配事は苦労して作っても誰も使ってくれないんじゃないかという恐怖です。

人間誰しも無駄なことはしたくないもんです。作る過程事態が楽しいからそれ事態が報酬だという気持ちもあるが、結果はまったくいらないと言う奇特な人はまずいない。

やっぱ成功する希望を心にせっせとモノ作りをするはずなんですよ。この誰しもが持つ恐怖感により、いつまでも顧客を探し続け、まだ確証が持てないからもうちょいユーザーインタビュー続けよっか、となってしまうやつです。

僕はLisgo作る前に、自分が欲しいアプリでユースケースもばっちしイメージ出来てたのに、だらだらインタビュー繰り返してた苦い記憶があります。なかなか「それ凄い欲しいよ!」という人が見つからないなあと。

でも、作ってとりあえずリリースしたら、「これは凄くいい!」と言ってくれる人が勝手に集まってきたので、この場合、逆に時間を無駄にしてた気がする。

作り始めるタイミング

じゃあ、どのタイミングで作り始めればいいのよ?というのが自然な疑問だけど、残念ながら明確な方程式なんてないので難しい。

あえて言うなら、ユーザーの問題とそれを解決する製品アイデアがある程度理解できている時。さっさとリリースしたほうが、ターゲットユーザがあちらから集まってきてくれる事も多い。

例えば、自分がユーザーである製品の場合、ユーザを探すことに時間を使うより、まずはリリースして、その製品のよさや使い方を広める工夫に時間を使ったほうがよい。

実際に何人の人が使ってくれるか、お金払うかはリリースしないとわからないし、インタビューの時に反応がよくても、製品を前にするところっと意見が変わるもんです。

ただ、もちろん、解決する問題をハッキリ理解してない時は、市場調査を先にしたほうが効率いい。

Taxnote作る前は、自分が確定申告の帳簿入力をアプリでやりたいという明確なニーズを持ってたけど、申告制度や、人気ソフトの使われ方は知らなかったので、アプリの作り始める前にかなり研究しました。

実際に自分が確定申告を済ませるまでの流れで、どこが面倒な部分か、アプリを作ったとしても、致命的な欠陥を見通してないかなどを調査しました。

時間の投資効果で決めればいい

結局は、市場調査にかかる時間と製品作る時間のトレードオフで考えればいいんです。

ターゲットユーザーを探して、アポ取って、インタビューする時間がたいしてかからない環境ならリスクも低い。普通は苦労するけど。

そして、製品作り始める段階では、どの機能が一番早く作れるかではなくて、どの機能が一番重要かをまず先に考える。

そのプロダクトに需要があるかどうかを検証するにはどの機能が必要かを考え、その最低限必要な機能からリリースして、仮説検証するまでの時間を可能な限り短くする。

結果的に、その他のナイスな機能は後回しになると思います。その時々で検証部分を決めて、小さく進んで行く。

向き不向き

リーンスタートアップが向く製品と向かない製品があるので、向かない製品に無理して応用することはできない。

例えば、ガンの特効薬とか痩せる薬に市場調査なんていらない。需要があるのは明白だから。重要なのは、有効な製品を開発できるかどうかであり、そこに時間使えばいいわけです。

逆に、2014のベストニュースタートアップを受賞したProductHuntみたいに、メーリングリストから小さく始めたサービスは、まさに、リーンスタートアップがハマった事例。

どういった方法論でいくかは、その時の製品、趣向(目指すもの)によって変わるので、結局は最適だと思う方法を自分で考えてやるのがいい。一番ダメなのは、こう書いてあったからこの通りにやろうという姿勢なわけで。

ちなみに、ピーターティールのリーンスタートアップ批判について面白い洞察をしている記事があった。=>リーン・スタートアップ教をめぐる宗教論争


*シンプルなアプリ作ってます

ブログ更新をお知らせ。ブログで書けない話、最近読んだ面白い記事や本も紹介します。

英語添削をoDeskにアウトソース


前々から海外へのアウトソースには興味があったんだけど、なんだかんだでずっとやってませんでした。

自分がアプリやサービス作る時は、企画、UIデザイン、プログラミング、サポート、マーケティング、アップデートと全部自分でやっているのもあり、なんでも自分でやりたがり症候群というのがある。

これはあまりよいことではないなとは思いつつ、どれも外注できない重要なことだよなあと今までやってきました。

しかし、以前聞いたスタートアップ系のPodcastでこんなことを言ってた。

「昔の自分にアドバイスするとしたら、一刻も早くアウトソースする能力を身につけろと言うだろう。昔の自分はすべて自分でやろうとしていたけど、アウトソースする事を覚えて世界が変わった。」

そうか、じゃあ、やってみたいな、と思うも、アプリ開発は改善の繰り返しだからアウトソースに向かないし、なにがいいかなと思っていたところ、ちょうどよい案件がありました。英語ブログ記事の添削です。

これならアウトソースにぴったりだし、そこまで高くなさそうだから練習にも最適。

英語ブログを書きたかった理由

そもそもなんで英語でブログ書こうと思ったかというと、ブログを書くとよいことがたくさんあるんですよ。まずは自分のアプリの宣伝ができるし、このブログ記事を読んでくれた人とひょんなことで繋がりができたりとか。

例えば、最近書いたこの記事はパッと見そんなバズってないけど、ロングテールで読んでもらえて、ここからTaxnote使い始めたっていう人がめちゃ多い。苦労して書いてよかった。

フリーランスの確定申告をぶっちゃける 1 – 青色申告と白色申告、手間も考慮した本当の費用対効果

自分はツール系の一回買い切りのアプリだから、ゲーム系の当たればでかいやつみたいに広告費をかけても回収できないんですね。なので、結局自分でこつこつブログを書くのがもっとも投資対効果が高いし、自分も文章を書くのが好きなのでぴったりです。

日本語に比べて、英語が読める人はだいたい10倍の人口がいると仮定すると、同じ時間でひとつの記事を書いたとしても、10倍の人に読んでもらえる可能性がある。そのぶん、10倍の競争率があるのも重要な点ではあるが。

外国人の開発者の友達が、たまたまMacProについて書いた記事がHackerNewsでバズってすげえPVになったという話を見てたのも理由です。そのPVは僕の日本語ブログ記事がはてぶでそこそこバズった記事と比較すると、桁がひとつ違いました。

そして、彼はせっかくバズったんだから、アプリのリンクも入れて宣伝しようと後から記事を編集したんだけど、その広告効果も文字通り桁が違いました。英語人口はすごい。

日本のAppStoreの売り上げだけで言えば日本とアメリカは大して変わらないけど、英語で人気が出ると、アメリカ、イギリス、オーストラリア、カナダ、その他海外の英語が読める人達に訴求できるので、やはり、日本語に比べて10倍ぐらい違うのかなといった印象でした。

英語ブログを書いてみた

そこで、一年ちょい前ぐらいに英語ブログを書いてみた。

ネタはとりあえずこのブログで書いたものを英語化しようと思い、個人的に一番よい記事だと勝手に思っている下記を英語化してみた。確か、この時はネイティブの友達に自分が書いた英語を添削してもらった気がする。

ユーザーの意見にNOと言うのは大切だけど、実際にどう言うかが難しい
How do you say No to users without annoying them?

しかし、現実は甘くなく、日本語の記事はそこそこ読んでもらえたのに、英語ではほとんど読んでもらえなかった。HackerNewsでポストしてみたのではあるが。

とはいえ、海外のユーザフィードバック専門のコンサルの方から、「この文章はすごくよかったよ!」という個人的なメールをもらい、書いてよかったなとは思った。

TwitterやFacebookも日本語でやっているから、日本語だとある程度シェアした時の影響が違うのかなと思ったけど、やはり10倍の競争率も痛感。確かに、英語記事って質の高い文章がゴロゴロあるから、オリジナリティーがないと厳しい。

次は、ちょっと肩の力を抜いて、Lisgoという自分が初めて作ったアプリを競合の開発者がタダで紹介動画作ってくれた奇跡の出来事について書いてみた。

競合アプリの開発者が無料でプロモ動画を作ってくれた
My competitor made my app promo video for free

こっちはもう面倒だから、英語の添削もせず、変な文章でもいいだろと思って自分が書いたそのままでHackerNewsにポスト。

すると、珍しい出来事だったのか、英語でちょこっとバズった。36回ぐらいツイートされた。この数字だけ見ると、全然大したことないんだけど、日本語の記事を書いて36回ぐらいツイートされた記事に比べて、なにかが違った。数時間でのPV数の伸びの桁が文字通り違ったのです。

とはいうものの、やっぱちゃんと長い記事書くなら、添削してもらいたいなと思っていたので、oDesk使うかとなったわけです。

oDeskの使い方はここでは説明しないので、この記事が参考になるかも。
海外の力も借りよう!英語が苦手でもわかるクラウドソーシング「oDesk」の利用方法

Jobを投稿するとすぐ応募がきた

添削をお願いする前に、スペルと簡単な文法は最新のテクノロジーの力を借りることにしました。Gingerというツールを使って書いたので、単純なスペルや文法のチェックはそこまで必要ない状態にしておいた。

そして、だいたいoDeskの他のJobポストを参考に、タイトルと説明文に重要な項目は入れつつ、簡潔に書いて募集してみた。金額はとりあえず10ドル固定で。

内容はこんなもの。

タイトル: 僕のエッセイの変な英語表現を直してください。(5500words、スペルと文法はツール使って修正済み)

説明文: 下記のブログ記事を書いたので、修正お願いしたいです。英語表現はあなたのスタイルで自由に変えてもらってもよいです。

ここで失敗したのは、5500wordsという部分で、本当は1000wordsぐらいだった。英語の文字数の数え方を間違ってた。

それにもかかわらず、4人ぐらいからすぐに応募があった。この中には、10ドルでやってもいいよという人もいれば、20ドルならやるよという人もいたり。

その中で、文章構成の仕事の経験があるアメリカ人の女性が10ドルでやってくれるようなのでこの方に頼む事に。プロフィールを読むと、海外を放浪中で、その間にサクッとアルバイトするのにoDeskを使っているらしい。

初回はクレジットカードの認証に一週間もかかり、相手を待たせてしまったけど、認証が終わるとすぐ添削してくれてWordで送ってくれた。送られてきた文章を見ると、やっぱり自分の英文はいろいろ変な部分があったなあとよくわかり、勉強にもなりました。

ちなみに、添削してもらったブログ記事はこちら。

アプリ操作を単純解説した動画はコスパがとても高い
Making a simple video tutorial is one of the most cost-effective ways for your apps

日本語記事のほうはそこそこ読んでもらえたけど、英語のほうは全然読まれませんでした。HackerNewsでポストしただけなんだけど、なかなか厳しい現実。

しかし、10ドルでサクッと1000ワードの英文を添削してもらえるのは安いし、なにより添削してもらえるまでの時間が相当早かった。12時間以内だった気がする。このスピードにもすごく価値がある。

アウトソースの衝撃

今回の場合、僕の小学生レベルの英文がそれなりになればいいので、そこまでクオリティーを求めないのもあり、アウトソースがぴったりかもしれない。

次は実験的に5ドルで募集してみた。同じ1000ワードぐらいの文章、Gingerで基本スペルは修正ずみの形式で。

これは誰も応募ないかなと思っていたけど、驚くべき事に、1時間ぐらいで4人の応募が。今回はネイティブの人が一人で、フィリピンの人が二人、他の国の人が一人だった。

その中で、大学で言語学と文学の修士をとって、今はコンテンツライターでバイトしているというフィリピンの女性の応募の文章がすごくしっかりしていたので、この方にお願いすることに。契約が決まったらすぐ添削した文章を送れますよとも書いてた。

まあ、ネイティブに拘らなくてもよいかと思い、この方に依頼すると、ちゃんとした英文で速攻で添削してくれた。フィリピンとの時差はないのもあり、ガチで数時間以内に送ってくれた。慣れている人がやれば1000ワードぐらいならサクっと終わらせることができるのかもしれない。

こんな安くていいのかなとも思うけど、海外との物価の差、仕事の内容しだいではアウトソースとはここまで力を発揮するのかと、自分で体験してみないと実感できないことがたくさんありました。

アウトソースに負けないスキルをつけないといけないとも思うし、自分の能力のここに価値があるんですよと考えていても、それを求める人がいなければお金も発生しないしなあとか改めて感じた。

やる価値のある新しい事は、めんどくさがらずにやってみようと試したoDeskですが、価値のある体験でした。

アプリの説明文の翻訳、AppStoreのキーワード選定、SEO、海外のある業界のリサーチ、事務作業とかなど、いろいろ使えそう。個人的には99designsで、アプリのデザインとか頼んでみたい。


*シンプルなアプリ作ってます

ブログ更新をお知らせ。ブログで書けない話、最近読んだ面白い記事や本も紹介します。