Page 19 of 29

UberとかGrabTaxiのよさがやっとわかった

旅行でマレーシアとか、インドネシアのバリに行きまして、今、世界中でホットなタクシー配車アプリを使ってみたんですよ。

Uberとか、Grabtaxiとか。

日本にいた時なんて、タクシーは高くてまず乗らないし、そもそもタクシー必要な時は、そのへん普通に走ってるわけじゃないですか。

Uberのプロモで4000円分使えるんだけど、根がケチな僕は、いざという時のために取っておこうと思い、結局使わないままだった。東京は地下鉄という便利なものがあるし。

それが、東南アジアだと、日本だと無用だったタクシー配車アプリが死ぬほど便利。これがないと本当に困るというか、命に関わるというか。

というのも、東南アジアってタクシーは危険なものらしいんですよ。

「え、タクシーが危険ってどういうことよ」って日本の感覚からすると思うんだけど、なんか、知らないところに連れて行かれて、身ぐるみ剥がされたり、襲われたりするのがよくあるらしい。

さらに、日常的にあるのがボッタクリで、乗る前にいちいち交渉しないといけない。メーター使ってくれるタクシー探したり。

初乗り100円とかで、東京の地下鉄ぐらいの値段で移動できるんだけど、安全性とか、ボッタクリに神経使ったりと、なんか疲弊するんですよ。

そこでGrabTaxi

それが、Grabtaxiとかいう、タクシー配車アプリ使うと一気に解決する!

GrabTaxiはマレーシアの起業家が作ったタクシー配車アプリなんだけど、ここだと神アプリ。

まず、ちゃんと身元調査された運ちゃんで安全性が高いし、アプリに値段がハッキリ表示されて明瞭会計。

ホテルで普通にタクシー呼んだ時は、なんか4倍の値段だったので、常にアプリで呼ぶことにした。

これ、出発地点と到着地点をセットしたら、勝手に値段をはじき出して、それが固定価格となる。お国柄でそのままの値段を要求してくる場合もあれば、さらにそこからチップ要求してくる地域もあるけど、基本的には明瞭会計。安い。

まず、安全性が確保されるのと、ぼったくられない、この二つがでかい。

さらに、こっちが現地の言葉話せなくて、相手も英語があまり話せなくて、どうやって意思疎通とったらいいのですか僕たち、みたいな時も、アプリで到着地点を登録してるから、特に問題なく運んでいってもらえる。これが3つ目にでかい。

流れとしては、アプリで現在地点と到着地点登録したら、近くのマッチするドライバーを検索しはじめて、「わーい、ドライバー発見したよ!」みたいな画面になる。

そして、アプリの地図上で、タクシーが近づいてくるのがわかって、あと何分ぐらいで着くかも表示される。

だいたいは、マッチ直後にドライバーから電話がかかってきて、その時に、相手がどの程度英語話せるかわかるんだけど、話すことは「今ロビーにいるから待ってますね。」ぐらいの確認程度。

現地の電話番号は空港で買った、プリペイドSIMカードについてくる。電話番号なんていらないかなと思ったけど、タクシーアプリ使う時に使いまくるので、必須だった。

ぼったくりなしの現地価格で安いし、なんて便利なんだ!もう海外旅行する時は日本にいる時以上にスマホが重要になってきた。

GrabTaxi使えない地域に行ってみたら

その後、インドネシアのマカッサルというところに行ってきたんだけど、ここが観光地じゃないので、タクシー配車アプリが一切使えなかった。

バリとかは英語がいろんなところで通じるんだけど、マカッサルは観光地じゃないから全然通じない。そして、Grabtaxiも使えないし、もちろんUberとかも使えない。

便利な観光地しか行ったことない自分としては、はじめてのローカル地区という感じで、いつも以上に治安に神経尖らせる必要があり、なかなか脳みそが疲れました。

治安が悪いって脳みそのリソースを奪われるから、たぶん、他のことに脳みそを使う余裕もなくなる。欠乏の科学って本に、貧乏なるとお金の計算をする分、学校の成績が落ちる話が載ってたけど、治安の悪化も同じ効果あるなと思った。

ちなみに、使えるのは、Go-Jekとかいう、バイク相乗りアプリのみ。

バイク相乗りて。。渋滞だらけで、ノールールの交通状況を見てたら、容易に事故率の高さは推し量れたので、バイク二人乗りはやめときました。

しかし、このタクシー配車アプリ使えないというのは想像以上に困りまして、とにかくそのへんのタクシーを捕まえると、「このタクシーは大丈夫なタクシーなのか。。」という、面倒なことを考えないといけないんですよ。

インドネシアではBlueBirdというタクシーだけは安心だ!と言われていて、できるだけこのグループのタクシーを探すんだけど、そんなに簡単に見つからない。

さらには、偽Bluebirdタクシーというのもあり、フロントガラスにBluebirdのステッカーがついてないやつは偽物らしい。(笑)

ちなみに、タクシー乗っても、英語はまったく通じないに等しいので、現地の言葉を話せないとなかなか厳しいものがある。

Uberを使ってみたら

で、その後バリ島に戻りましたところ、ホテルのレストランでデンマーク人と仲良くなりました。なんかシンガポールに留学してて、休みだからサーフィンしにきたらしい。

ちなみに、デンマークは大学に行くだけで、国から毎月10万ぐらいお金がもらえると聞いてびびった。お金かかるんじゃなくて、教育受けたら国がボーナスくれるのかよ。

そして、「夜道歩くのは危険だから、俺はできるだけUber使ってるぜ!」と言われ、「僕はGrabtaxi使ってるよ」と言ったら、「とにかく、お金払う手間がないから楽だヨ」と教えてもらった。

そうか、ここはUberも使えるのかと思い、インストールしてたUberも使ってみることにしました。WWDCでサンフランシスコいった時は、レンタカー借りてあまり使わなかったUber。

アプリを起動すると、思った以上に近くにタクシーがいっぱいいて、なんかこのUIはゴキブリみたいだなと思いながら、呼んでみたら、速攻でマッチングした。

GrabTaxiと違って、事前にいくらかかるかわからないのはマイナス要素なんだけど、アプリの操作手順はこっちのほうがシンプルで呼ぶまでのステップが少ない。この手軽さ重視はいいかも。

Uberのタクシー運ちゃんに聞いたら、「ここではGrabTaxiよりUberのほうが人気だよー」と言ってた。そうだったのか。まあ、すぐに捕まるのは重要だから、タクシー配車サービスはネットワーク外部性も関係してくるなと思いながら、目的地へ到着。

到着したら、その後は降りるだけ。値段はアプリの履歴に出るんだけど、別にそこまで高くない。あったとしても誤差の範囲。

で、この、到着した後の、お金を払わなくてよいというのが想像以上に楽チン。

「この値段でOKだよね」「よし、確認してれ」とかの、お金の受け渡しもないし、あっちがお釣りあるかとか、でかい紙幣しかないとか、細かいお金ないとか、あまりはチップにするとか、そういう煩わしい事を全部すっ飛ばせる。

クレジットカード自動引き落としだから、現金も減らない。現金あまり多く持ち歩きたくないし、両替も面倒なんですよね。

到着したら、「ありがとう」と言って降りるだけ。

これがこんなに心理的に違うのかとびっくりした。お金払わなくていいから楽だよとは聞いてたんだけど、頭では理解して想像できてたんだけど、実際に体で体験しないとこの素晴らしさはピンとこなかった。

一度、この楽チンさを体験すると、今まで当たり前のようにしていた、タクシーの最後にお金を払うという行為が突然煩わしいものになってきてしまう。

この感覚は、便利で使いやすいものを使うと、今まで当たり前のように使っていたものに対し、突然不満が出てくるのに似ている。

プロダクトやサービスは、説明された時点で理解できる領域って本当に少ないんだなと思いました。

*このリンクでUber新規登録すると2000円までのクーポンが入るので(登録した人と、僕に)、気が向いたらどうぞ宜しく。https://www.uber.com/invite/bem3e


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

Parse Local Datastoreの限界と、クラウド同期アプリ作る時の注意点

iOSでParseと Parse Local Datastore最近2ヶ月ぐらい触ってるので、わかったことを書いてみます。間違いがわかれば嬉しいので、突っ込み歓迎。

さて、Local Datatoreは発表された時から僕はワクワクドキドキしていて、そのドキドキ感をブログで書いてきました。

Parse Local Datastore for iOSがやっと出た

しかし、実際には使ったレポートは書いてなかったんですね。なぜなら使ったことがなかったから。

しかし、最近はというと、2ヶ月近く前から毎日ParseとCoreDataの連携するコードを書きまくっていて、いろいろわかってきたことがあったので書いてみる。

基本的には、ParseのForum、Google Group、StackOverFlowで書かれている先人の知恵を借りながら、そこで書かれている現時点のベストプラクティスを参考にコード書いてる。

@目的
Taxnoteっていう経費記帳アプリに自動同期機能つける。

@背景
元々はCoreDataオンリーのアプリ。CoreData + Parse (+ Local Datastore)で自動同期機能をつけようとしてる途中。

@目指す動き
オフライン時はローカルにデータを保存し、オンラインな時にサーバと同期する。ようは、オフライン時でもキビキビ動いて、ユーザは意識しないまま、勝手に裏で同期が動く。

いろいろググったけど、Parse Local Datastoreをまとめたブログ記事は英語でもあんまりないので、参考になれば幸いです。

というわけで、まずは、Parse Local Datastoreの話を中心に書いていきまして、その後に、Parseの普通のメソッドの話を書いていく。

CoreDataとParse繋げるライブラリないの?

そもそも、僕はあんまり自分でコード書くより、もっとプログラミングが上手い人のライブラリを使いたいんですが、残念ながら良さげなのがありませんでした。

FTASyncは数年前に書かれてメンテはされてないし、すごくベーシックなことしかできないみたい。また、NSIncrementalStoreを使ったライブラリも試してみたんだけど、これも今はメンテされてなくて、上手く動かなかった。

Local Datastoreがでたから、みんなこっち使おうね。みたいな流れらしい。ただ、Local Datastoreはパフォーマンスの面で致命的な問題があり、使えず、しゃあないから自分で書かないといけなくなったと。

あとは、同期ってデリケートだから、自分で書いたほうがバグとかも対応できていいかなと思ったら、予想以上に大変で時間かかってる。

Local Datastoreのパフォーマンス

100個ぐらいのデータなら問題ないけど、1000個ぐらいセーブした時点で遅くなる。1500個ぐらいのデータを一気に取得しようとする時、iPhone6Plusで2秒近くかかっちゃう。CoreDataと同じことしようとしたら、雲底の速度差。

なので、Taxnoteのメインのデータのクラスには使えず(仕訳帳のクラス)、大幅に書き直す羽目に。

Taxnoteだと、メインの入力していくデータには使わず、勘定科目リストなどのデータのみに使うことに。

なぜかというと、科目リストのクラスと、メインの帳簿クラスはRelationで繋がっているので、ParseにSaveするたびに、Relationの呼び出しする時にLocal Datastor使うと便利だから。

Pinを分けたらパフォーマンス改善しないの?

Local DatastoreにはPinといって、それぞれ保存する領域を分けられる機能がある。

これを使って、カテゴリクラスのpin、エントリクラスのpinみたいに、Pinを分けたらパフォーマンス改善するかなと思って試してみた。

結果的には改善せず、Local Datastoreのパフォーマンスはこの時点で諦めた。なので、Local DatastoreをCoreDataとか、オフラインデータベースの代替品として使おうとするのは無理ゲーだと思う。

最初は自分もそういうふうに使えんじゃねえかと夢想したけど。

Local Datastoreをsyncするメソッドないの?

これ、Local Datastore使い始めたら思うんだけど、ParseをLocalに保存したものを、サーバ側と同期するメソッドがないんですよ。

Local Datastore Syncみたいな。

オフラインの時はLocal Datastoreに保存して、まだサーバに保存されてない部分だけ明示的に同期するとか。そういうメソッドがあれば便利なんだけど、残念ながらない。

どうすりゃいいかというと、結局、Parseのモデルクラスで、needSyncみたいな項目を作って、自分で needSync = NOのやつを後から呼び出して、syncされてないやつだけちゃんと保存しておくとか。

こういう面倒なことをしないといけない。こういうメソッドは必要だろみたいなことは、Parseのフォーラムでも書かれてます。まじで必要。

ここまで、Local Datastoreの話で、以下は普通のParseのメソッドについての話。

SaveEventuallyの弱点

Parseには、SaveEventuallyっていう、データを保存した時、もしオフラインだったら、あとでオンラインなった時に勝手にサーバに保存しときますよっていう素敵なメソッドがある。

これは、ドキュメント読む限りでは神メソッドだ。

ただ、オフライン時に何回か連発で呼んだり、呼んだ後にアプリをタスクから強制終了させたりしたら、Parseサーバに反映されないデータが出たりする。

いろいろテストして、信頼性が低いので結局使わないことにしました。CoreData側でneedSaveとか、needSyncとかのattribute作って、自分でオフライン対応することに。

SaveInBackGroundもSaveEventuallyのようにオンラインなったら自動saveされる動きするので注意。

まあ、すごく厳密にデータSaveされなかった漏れがないようにしたかったから、Taxnoteでは使わないことにしたけど、そこまで厳密にする意味ないような時はガンガン使ってよいと思う。

たいていの状況では普通にあとからsaveされるし。

複数データを一回でsaveAllした時のリミット制限は?

Parseには、1秒間に何リクエストまでという制限がある。無料プランだと少なくて、有料で段階的に上げていける。

例えば、100個ぐらいのデータを PFObject saveみたいな感じで100回繰り返せば、100リクエストになっちゃうのはわかるとして、100個のデータをまとめて、PFObject saveAllで保存したらリミット制限にはどう影響するか?

これは、saveAllでまとめて保存しても、保存するデータを個別にカウントする。だから、無料プランで、1800個ぐらいのデータを一発のsaveAllで保存しようとすると、リミットにひっかかりましたのエラーが出る。

まあ、そんなことは起きないアプリなら問題ないんだけど、Taxnoteは二年分の仕訳帳データが既にあったら、全部で1800件ぐらいなっちゃうんですよ。それを自動同期使う時に一気にアップロードしようとすると、エラーメッセージでてわかった。

解決策は、有料プランでリミットを上げるか、複数回にリトライするか。今、ここやってる途中。

データ削除の設計

これが厄介なんだけど、デバイスAとデバイスBでのデータを同期する時、片方で一つのデータを削除したら、もう片方でもデータを削除しないといけない。

例えば、デバイスAである一つのデータを削除した時、サーバ側でそのデータを本当に削除しちゃうと、デバイスBで同期する時に、そのモデルクラスにある全てのデータをシンクロしないといけなくなるんです。

これはパフォーマンス的によろしくない。

というわけで、実際にサーバ上ではデータを削除せず、isDeletedみたいなカラムを作って、ソフトデリートというデータベース設計の手法を使うらしい。

これなら、デバイスBはisDeleted = YESとなっているのだけQueryで検索かけて同期し、デバイスAで削除されたデータをデバイスBでも同期した時に削除するという動きができる。

まあ、これがベストなやり方だとは思うんだけど、定期的にサーバ側でisDeleted = YESになっているデータをクリーンアップする必要があるんですよね。Cronとか使って。このタイミングが悩み中。

これはParseは直接関係ないけど、同期アプリ作る時はぶち当たる壁かも。

まとめ

Parse Local Datastoreは1000件ぐらい保存したら遅くなるので、この遅さが問題になるアプリなら使いにくい。結局、CoreDataとParseの連携部分のロジックを書かないといけない。

でも、局所的に使うには便利です。

Taxnoteだと、仕訳帳一覧のモデルクラスと、科目のモデルクラスでRelationsつなげないといけないので、科目の部分だけLocal Datasore使うのは意味あった。

ちなみに、TaxnoteはもともとCoreDataで作ってたけど、新しいアプリなら、Realm + Parseで作ってたかも。Realm評判いいし。


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

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

最近、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がここまで普及した現在ではプロモーションの場を持たなくても別にいいんじゃないかと。こういう考えもできます。

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

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

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

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

そして、その後に作った、Taxnote、ZenyListTimer、JetDoはほぼ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と並ぶぐらい好きかもしれない。

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

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

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

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

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

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

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

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


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

Copyright © 2025 うめのんブログ

Theme by Anders NorenUp ↑