Page 25 of 29

アプリ作った人の影響力は、売り上げにどの程度関係するか？

こいつは気になりますね。興味深い結果がInstapaperを作ったMarcoさんのブログで書かれていた。

http://www.marco.org/2013/07/31/the-app-store-problem-is-not-price

結論から言うと、最初の数日だけ影響があり、その後は大して関係がないと言っておられます。

最近、MarcoさんがBugshotというよく出来ている、シンプルなアプリを99セントでリリースした。

売り上げグラフが上記ブログで公表されているけど、二日目に1,250個ぐらい売れたのをピークに、最初の大きな勢いはすぐに下がり、最近の平均は一日に47ドルぐらいらしい。

2週間で作ったアプリらしいから悪くない数字だと思うけど、それでも、ネット上の影響力は瞬間的なものだというのが分かる。

ちなみに、MarcoさんはブログもよくHackerNewsで話題になるし、人気のPodcastもやってるし、おそらく個人開発者としは世界一自分のアプリを宣伝しやすいポジションにいると思う。

そうであっても、最終的にはアプリ自体の出来と、口コミで広がってロングヒットになるかどうかが鍵となるみたい。

ちなみに、Bugshotは自分も買った。コンセプトもよくて、シンプルで凄くいい。アプリの出来が悪かったらもっと人気は急降下していたんだろうと思う。

この事実自体は、アプリを作る人にとっては朗報ですね。ようは、アプリの質で勝負して、ロングヒットを狙うのがよいということになる。

ロングヒットを狙うには

じゃあ、ロングヒットはどう狙うかとなると、いいものを作るしかないので近道はないと思う。

とは言っても、小さく早くリリースして、反応を見たり聞いたりしながらコツコツ改善するのが王道じゃないかと。

例えば、別に影響力のない僕みたいなものがアプリをリリースしても最初からダウンロード数は伸びない。

でも、すごくシンプルなものでもリリースする事によって、需要があるか、ダウンロード数に応じて買ってくれた人の割合など、重要な部分が分かる。

例えば、ダウンロード数が最初は少なくても、その中からフィードバックをしてくれる人が数人でもいたら、需要がありそうだとか。

あと、実際にお金を出してくれる人がいるかをリアルに知るのも参考になる。もし、最初に50〜100ダウンロードしか一日にいかなかったとしても、その中から一定数がアップグレード版を購入してくれるか割合を見るとか。

ダウンロード数や売り上げ数単体の数字じゃなくて、いいと言ってくれる人が出てくる割合、コンバージョンなどの割合に注目する。

僕も、昔は、アプリが取り上げられたり、何かの拍子で一気に注目される時にダウンロード数があがるので、その回数をいかに増やせばいいのかなと考えたことがあった。

でも、そんなものは狙ってできないし、そこに時間をかけるのは非効率だと思い直した。

外部要因に影響がない状態、例えばリリースしてしばらく立った落ち着いた状態とか、そういう時の数字こそ重要だなと最近は思う。

あと、特定のグループでのベータテストと、本当のパブリックリリースで分かる事は全然違う。ベータはやっぱり、限られたグループ内での出来事だから。

ビッグローンチは重要か

アプリのリリース時は重要で、ストアで新規リリースとして注目されている間に一気に広めるのが大切だとよく言われる。

でも、疾風のようにリリースして、数ヶ月で回収するんだ！という場合以外は、気にしなくてよいと思う。

つまり、長くやる予定、もしくはリーンスタートアップみたいにテストを繰り返したい場合などは、ビッグローンチはノイズが多すぎて弊害が多いし。

影響力のあるサイトやストアで取り上げられるのは嬉しいし、いい事だけど、一時的に一気に流れてくるユーザが多いほど、オーガニックな成長具合や、重要な指標が分かりにくい。

まあ、投資家の目があるスタートアップの場合や大企業は大人の事情があるかもしれない。そういう事情がない場合は、逆に強みになる。

App Storeだと、ひとたび低評価がつくと後々にも残るからお陀仏だ、最初から一定の質を用意して出さないといけないという考えもあるけど、これもそんなに気にしなくてよいと思う。

低評価は後々、いつ何時、誰にでも、一気につく可能性はあるし、ストアで有名な質の高いアプリも様々な事情で一気に星の数が減ったりすることもよくある。

それを気にしすぎてリリースを遅らせて、たくさんの知見に気づくのが遅れるリスクのほうが遥かに高い。

あと、小さく作ればそれだけバグの可能性も少ないし。

話がちょっとそれたけど、今回のMarcoさんの記事は、例え有名な人が作ったアプリでも思った以上に影響は限定的なんだなとわかり、いい意味で励まされる記事でした。

Tweet

Helpshiftというモバイルアプリ用のサービスが凄い。ユーザのフィードバックを出来る限り欲しいアプリ開発者やスタートアップはぜひオススメ。iOSとAndroidにネイティブSDKで組み込む。

こういうサービスをずっと探してたんだけど、なぜか今までよいのがなかった。やっと出てきて嬉しい。

なぜ欲しかったか

製品開発ではユーザの意見を詳しく聞いたり、ユーザがいかに低コストでフィードバックしやすい状況を作るかが凄く重要。

Webサービスだとユーザがすぐにサービス提供者側とチャットできるoLarkとか、素晴らしいサービスがいっぱいあるんですよ。

ただ、ネイティブアプリには似たようなサービスがなかった。

iPhoneアプリでよくあるのは、アプリ内にフィードバックボタンがあって、それを押すとメールで送信するモーダルが立ち上がるもの。

ただ、メール設定してなかったら動かないし、メール送るのって思った以上に心理的コストが高い。メールだったら面倒だから止めようと思う時が自分でもほとんど。

だから、クックパッドのご意見ボックスみたいなのが欲しかった。

Helpshiftの利点

HelpshiftのiPhoneSDKをインストールすると、簡単にiPhoneアプリ内にFAQの画面とか、不都合を報告する画面とか作れる。

これなら、ユーザが匿名で気軽にバグ報告とか、不満とかをサクっと送りやすい。結果的に、App Storeのレビューで星ひとつをつけられる前にフィードバックもらいやすくなる。

自分はHelpshiftをVoicepaperに導入して一ヶ月近くになるけど、今までメールならほとんどメッセージがこなかったけど、毎日一人ぐらいHelpshift経由でフィードバックがくるようになった。

これによって、ユーザがどんな部分に不満もっているかとか、どういう使い方をしているかとか、なかなか分からない事がたくさんわかった。いやあ、素晴らしい！

FAQも作れる

Helpshiftのよいところは、ご意見ボックスを作れるだけじゃなくて、サーバ側でいつでも変更できるFAQを作成できる。

これで、僕はヘルプ画面を作って、使い方とか、よくある質問をサーバ側からいつでも変更できるので凄い助かってる。

さらに、ローカライゼーション機能もよくできているから、英語と日本語どっちも用意して自動きりかえも出来る。いいね！

アプリ内通知で返信できる

ユーザが、「こんな問題があって困る」とか送信してきたら、Web側のダッシュボードから返信が出来る。そして、その返信をプッシュ通知でアプリ側から表示できる。

僕はプッシュ通知お金かかるから、通常のローカルノーティフィケーション通知のみだけど、これでもユーザがアプリ開いた時に上に返信通知がくるからかなり便利。

それでも、気づかない時もあるだろうから、僕は返信通知がある時は、アラートビューでも知らせるようにしてる。まあ、ここはプログラミングの話になるけど、細かい動きもネイティブSDKだから出来るということです。

あと、問題が解決した時に、ストアレビューお願いボタンとかも用意されてる。

気になるお値段

最初はトライアルで使わせてもらっているけど、一ヶ月のアクティブユーザが1万人までなら年20ドルのプランで使えるから、僕のアプリならこれでいける。

ちなみに、アクティブユーザとは一ヶ月にアプリを開いたユーザの数みたいだ。だから、単純に月のダウンロード数が1万以下なら安いプランでもいけるとなる。

それ以上のアプリになると結構お値段はるので、どれだけ必要としてるかですな。。

※追記
現在は価格体系も変更されているみたいなので、pricingページを参考にしてください。

http://www.helpshift.com/pricing/

返信するの大変そう

うむ、値段の次に心配なのはこれだと思う。もし、すでに保守モードに入っててアップデートする予定もないアプリならいれる意味もないと思う。

しかし、もしユーザのフィードバックを参考にしたかったり、スタートアップとかだったら、返信する面倒さより、はるかに有意義な知見が得られると僕は思います。

いっぱい同じ質問が来たらFAQやヘルプをリアルタイムに更新すればいいし、なにがヘルプページで一番重要な項目かも分かる。

そもそも、ユーザの意見を自分から聞きにいくのって凄いコストだし、あちらからコンタクトしてきてくれるチャンスなんてなかなかないんですよ。

メールでわざわざ送ってくる人なんて大変だし、Twitterだとかなり気軽にフィードバックしてもらえるけど、それでもアプリ内に手軽な送信箱があると圧倒的。

ユーザからみた手軽さが徒歩一分内のコンビニと、車で行くでかいショッピングモールぐらいの距離感の違い。

最悪、返信する時間がなければ、聞く専用のボックスにしてもいい。アプリ開発者でも、アップデートを頻繁にしている初期段階だけ入れるとかもありかも。

100の機能要求に99回NOと言うのが難しい

ユーザのフィードバックが手軽に聞けるようになった時、とても重要なのは、どんどん機能追加の要求が来た時に、いかにNOといえるかだと思う。

わざわざ時間をかけてフィードバックしてくれる人のお願いは出来るだけ全部聞きたいのが心情なんですよ。

でも、みんなが要求するすべての機能を追加していくと、シンプルだったアプリもいつのまにか機能盛り込みすぎの複雑なアプリになってしまう。

みんなを喜ばせようとした結果、誰も喜ばないアプリになってしまう。

僕は機能追加要求はぜんぶ聞くけど、じっくり何度も検討して、複雑さを増やしても本当に必要かどうか考えるのに時間をかけるようにしてる。

でも、これ、口で言うのは簡単だけど、実際に「〜をできるようにしてください」と言われた時に、どういうふうに答えるかっていつも難しい。

あとは、機能要求がきた時に、なんでそれが欲しいのかの理由を聞くのも大事だと思う。表面上の機能追加だけ聞くと、なぜそれが必要なのかの理由を分からずなんだか違うなあという実装をしてしまう危険性がある。

でも、理由を聞けと言うのも、実際に実行するのは簡単ではない。あまり「なんで？なんで？」と聞かれると嫌がる人もいるだろうし。ユーザーの声を聞け！って格言のように言われるけど、なかなかもって簡単な事ではないし、日々の訓練が必要だなと思う日々です。

こう書くと、やっぱHelpshiftなんて面倒なものをいれるのは止めようと思うかもしれない。（笑)

しかし、プログラミングとフィードバックを聞くのをセットで進めると、無駄なものを作る危険も少なくできるし、自分の間違いに気づきやすいし、新たな発見もあるのでいい事たくさんあります。あと、バグ報告もたまにしてもらえるし。

関連する記事

ユーザーの意見を聞く難しさ
スタートアップがユーザからのフィードバックを逃さないために

Tweet

「ほぼ日」のビジネスに関する考え方とか、商品開発に関するインタビューを読んでとても感銘を受けた。知っている人には今更感が強いかもしれないけど。

「ほぼ日」は売れ筋を”考えない”
「ほぼ日」はブータンを目指す

かいつまんで話すと、ほぼ日は毎日更新するポータルサイトで、日に140万PVぐらいあるらしい。でも、広告がない。そのかわり、自分たちがよいと思うものや、自分達が欲しいと思って開発した商品をサイト上で売っていて、それで利益を上げている。

ネット広告で利益を上げようと思うと、どうしてもクリックされやすいえぐいタイトルに走ったり、大抵はユーザに嫌がられる広告の貼り方に走らざるをえない。

僕も頑張って書いた記事を誰にも読まれなかったら悲しいから、ちょっとでも気を引くようなタイトルを考えたり、いやいや、これはあざと過ぎるなと心の中で葛藤があるのはしょっちゅうです。

しかし、ほぼ日の方向性はバナー広告が収益源でないのと、一時的なPVを狙う方向性は狙っていないのがインタビュー読んでいると分かる。

ブログでストーリーを語り、自分が本当に欲しいと思う商品を開発し、それを売って利益を得る。なんとも素晴らしいなと思った。

どかんと成長してどかんと売り抜けるモデルが注目されやすいけど、ほぼ日や37signalsのように、急成長はしないけど、薄利多売ではない着実な利益を稼ぐロールモデルもたくさん出てきてほしい。

ほぼ日の商品開発は、自分達が欲しいという強い動機があるものを作る。商品開発では、お客さんの意見は聞くけど、意識しすぎる事はしないようにしているらしい。

糸井：もちろん、お客さんのご意見は聞きますが、モニターとして意識しすぎると、「あぶはち取らず」になってしまう。だから、意識しすぎないようにしています。アンケートも当てにしすぎるといけません。どうしても「考えるために考えた」アイデアが入りますから。

さらに、安さで勝負をしないで、高いと言われたら、そのお客さんに買ってもらうのは諦めるという方針らしい。

これ、僕の作ったアプリも自分が欲しいという強い動機があったし、アップグレード価格もApp Storeの平均価格からすると決して安くない価格なんだけど、フリーミアムでしばらく使ってもらって、納得した人だけ買ってもらう売り方にしてるから結構似ているんですよね。なので、共感してしまう。

ほぼ日と少し似たモデルとして、海外の風刺的な漫画を書くオートミールというサイトを思い出した。ここも大人気サイトで、サイト内でTシャツとかカレンダーとかマグカップとか売っている。

オートミールを知らない人は「猫対インターネット」で検索して欲しい。

Webを使ったこういうモデルはこれから増えていくと思うけど、ほぼ日で特に重要だなと思うのは、文章で自分で開発した商品や薦める商品に対する思い入れを伝えるところだと思う。このストーリーをしっかり語る部分が重要だと感じるので、これからの商品開発はブログとセットに考えるぐらいでいいのかもしれない。

サービス側が人を集める時によくやる戦略は、ターゲットユーザが好きそうな情報をまとめたり、関連記事のキュレーターになるというのがある。でも、本当にオリジナルな文章、コンテンツというものを発信できると大きく違う。(ほぼ日とかポールグレアムのエッセイのような）

さて、アプリ開発に関すると、物販と比べて、App Storeのアプリってアップデートが大変で保守コストが難しいところですね。iOS7とか対応したり。マグカップ売るのに比べて継続的なサポートがネックになって、流通コストはないけど、それなりの障壁もある。

そうは言っても、自分がいいと思ったものをブログで紹介して、自分の開発した商品を売るというのはアプリやサービス開発も同じだと思う。

例えば、この「カレー皿」を紹介するページ。

ろくろを回している動画もあるけれど、簡単な写真と文字で商品のよさを伝えている。たくさん文字がある。現代人は忙しいから動画さえも見ないとは言われるけれど、興味を持った人は文章を読んでくれるのはアプリ作ってて僕も何度も経験してる。

Lisgoの時なんて、適当な英語で開発日誌ブログを書いてたら、全部読んだよとメールしてくれる人が結構いたのが驚いた。

改めて文章を書く事、ストーリーを伝えるという事の重要性を思い知らされた記事でした。

Tweet

ここ2,3ヶ月、精魂込めて開発していた“通勤中に聞ける太宰治”がアップストアでリジェクトされた。泣ける。

原因は「ブックアプリだからiBookStoreで出してね!」だった。。

もちろん、「いやいや、これは読み上げ機能とかあって、聞く事と読む事を繋げるアプリで、iBookStoreじゃできない」とか、いろいろごねて何回かアピールしたけど、無理だった。最後には、「そんなに言うならアピールボードがあるよ」と言われたけど、なかなか厳しそう。

アプリのコード自体は、次のDropboxのテキストファイル連携する本命アプリに流用するので無駄にはならないけど、それでも、結構な時間を太宰アプリのリリースに費やしたのでつらい。

アイコンだけは手を抜けないと思って、太宰のイラストとかもイラストレーターの方から購入して作成したし。アプリに入れる太宰作品の紹介文とかも書いたし。

調べてみると、最近は書籍アプリは基本的にリジェクトされる運命にあるらしい。ついつい、アップストアに並んでいる類似アプリを眺めながら、大丈夫だろうと思い込んでしまっていた。まあ、確かに書籍関連はそうなるのもしょうがないか。

そもそも、アップストアのガイドラインなんて刻々と変わるもんだし、アップストアで並んでいる類似アプリがあったからといってOKとは限らない。数日前に承認された類似アプリと同じような内容でもリジェクトされるリスクもある。

僕は反省しました。

もっと早くサブミットして、アプリがリジェクト対象になるかどうか確認しておけばよかった。

Webサービスを作る上での最大のリスクは、ユーザが欲しがらないものを作る事なので、最低限の機能でリリースするのは重要なんだけど、iOSアプリに関して言えば、なによりも、ストアリジェクトが最大のリスクなのに。。

可能な限り最低限の機能だけに絞って、できるだけ早くリリースすることを教訓としていたのに。今思えば、もっと省略できた。

フォントサイズ変更、ナイトモード、ランドスケープロック、カスタムUI、文字検索も、あれもこれも省略できた。「この機能やこの機能は必須だな！」と思い、サブミットするのを遅らせてしまっていた。

全部すっとばして、とりあえずサブミットしていたら、一ヶ月以上は早くリジェクトリスクを確認できた。

ちなみに、アプリ開発者なら大抵知っているけど、ストアにサブミットして承認される=ストアでリリースされるではないのです。

例えば、5月10日にストアにサブミットして、５月17日に承認されたとしても、iTunesConnectのアプリのAvailable時期を一年後とかに最初から設定しておけば、ストアにリリースされる事はない。

もちろん、承認されれば、いつでもリリースできるようになる。だいたい数時間以内に反映される。さらに、アップストアに承認された時点で、TestFlightのような面倒なサービス使わずとも、プロモコード配布でβテスターにカンタンにアプリも試してもらう事ができる。

これは、アップストアのリリース時期は一年後にしてても、承認さえされればプロモコード経由でストアからダウンロードできるから。

ああ、なんてバカだったのだろうか。

これからは、もっともっと、「この機能は後回しにできるんじゃないか」と自問自答して、いかにやらないかを考え、まずはリジェクトリスクを確認する。ついでにリリースを早める事を徹底したい。

リリースする事で、いろんな事が分るし、使ってもらえる人の反応もわかるし。最初から大々的に宣伝して初動で回収するアプリを作ってるわけでもないし、最初は評価低くなっても、こつこつよくする予定だったらそこまで関係ないし。

とにかく、これからはもっと早くサブミットするよう気をつけよう。だって、アップストアって、すごい些細なメタデータ入力不足とかでリジェクトされて、速攻で修正してサブミットしても、平気で数日返事待たされたりするからなあ。

ちなみに、太宰アプリのティザーサイトに登録してくれた方は、次のアプリ「読み上げさん(仮)」が出た時お知らせしようと思います。これも、もうサブミットしたけど、今審査中。

Tweet

最近、以前は理解できなかった利便性に、どういう風に自分は気づき始めるかというのを凄く考えている。

もう、本当にこれは、切実に考えている。

なんでかというと、LisgoやVoicepaperで広めようとしている、”目で読んでいる読書の続きを、立ち上がった後に耳で聞く”という新しい読書体験が、とても理解されにくいからです。

一度理解してもらうと凄く刺さるし、この体験は読書好きじゃない人でも読書に親しむようになるぐらい大きな事だと思っているけど、そこまで理解してもらうのはとても難しい。

でも、これは、至極当たり前のことで、自分もいろいろなことにおいて、あるサービスや、製品の機能について、最初はさっぱり理解できなかったことが、それはもう、本当にたくさん、しょっちゅうあることに気づいた。

自分に最近起こった変化、さらには、自分がサービスを広める側なら、どうやってその変化まで持って行けばいいかを書いてみたい。

最初、理解できなかったもの

最近の例でいうと、iOSのフリック入力。

僕はキーボードでの入力に慣れ切っていたので、iPhoneを始めて買った数年前、携帯で文字を打つのを頑なに拒否してた。

いやいや、キーボードで打つほうが遥かに早いし、打ちやすい。こんな小さい画面でチマチマ打つなんて非効率すぎるわ。その時間は違うことしたほうが有益だな。とか思ってた。

でも、フリック入力に慣れてくると、キーボードほど速くも正確でもないけと、モバイルで文字を打てるメリットがありありと理解できてきた。

それは、もう、薄々理解してたつもりだったけれども、実際に習慣になるまで、本当の意味でしっくりきてなかったアハ体験。

外でもいろんな状況で打てるし、寝転びながらでもブログが書ける。なんで、長文書く時は、絶対キーボードじゃないと嫌だと、あそこまで、頑なに拒んでいたのでありましょうか。

もうひとつは、マニアックな開発ネタで申し訳ないのだど、CocoapodsというiOS開発のリーサルウエポン的なシステム。

これは、いろんなオープンソースライブラリを超絶簡単に入れたり出したりできる神ツールなんだけど、使い始めるまで設定とかめんどくさいし、今までのやり方で別に不満ないからなーと思ってた。

この、今までのやり方で満足してるからなーというのが結構重要なポイントだと思う。

やはり、別に満足してるもののを、面倒なコストかけて新しいことを覚えるのは疲れる。だから、はっきりとしたメリットを自分がイメージできないと、人間なかなか以前の習慣から移ることができない。

しかし、恐ろしい事に、一度使い始めて、最初は、「まあ、便利だけど、別に以前のやり方でもいいかな」とも思ってた。

そんな自分が、cocoaPodsをしばらく使っていると、「あれ、これないと俺もう死んじゃうぐらい便利だわ、これなしではオープンソースの管理めんどすぎ。もう戻れない。」とまでなってきた。

新しいサービスを提供する側になった時は、どうやって、この状態まで持っていくか、出来る事はなにかを考えてみたい。

利便性に気付くプロセス

自分が新しいものの利便性に気付くまでは、いくつかのプロセスを辿っていると思う。

まず、誰かがそれについて薦めてくる。気付く。気になる。使い始める。まだよくわからない。でも、とりあえず続ける。慣れて来て、利便性にはっきり気付き始める。習慣になる。

例えば、フリック入力なら、だいぶ前にどこかのブログでフリック入力が絶賛されていて、出来るだけ使うように努力し始めた。とりあえず、使い続けてたら、慣れて来た。だんだんとツイッターとか、長文のブログでも使い始めた。

CocoaPodsなら、iOSTokyoMeetupで絶賛されてたから、これは時代に乗り遅れそうだぞと思い使い始めた。で、あまりよさが理解できないまま使い続けてたら、離れられなくなった。

さて、サービスを提供したい側なら、どうやってこのプロセスを促進できるんだろうといつも悩んでいる。

まず、サービス自体に価値があって素晴らしいものだという前提で話を進めてみる。

どう持っていくか

もっとも重要なのは２つの部分だと思う。

１つ目は導入がいかにカンタンか、2つ目は、まだよくわからないけど、とりあえず使い続けてもらうこと。

１つ目はとても、とても難しい。特に、なかなか利便性が理解されないようなサービスであるほど難しい。

ParseとかCrashlyticsのようなサービスは、導入でいかにつまづかないか、本当に細かいところまで気を配って手順が設計されていると思う。

モバイルアプリなら、開いた後に、いかに離脱せずに、らくらく前に進めてもらえるか。

2つ目の、とりあえず続けてもらうという部分も結構難しい。

一度使ってみて、ああ、これいいなと思っても、しばらく使ってなかったら忘れられるというのがよくある。

これに対処するには、Webサービスだと、メールアドレスを登録してもらえるようなインセンティブを作って、忘れないように定期的にお知らせを送るのがよくある。

スパムにならないように、ユーザが開きたくなるようなものがいい。

モバイルアプリだと、定番なのが、Push通知。家計簿アプリのZaimはしばらく使ってないと、「お金の入力最近してませんよ」というような通知がいくらしい。これはユーザも納得の通知だし、上手いなと思う。

他に思いつくのは、ゲーミフィケーションで、利便性がまだよくわからない段階でも、なんか気持ちいいから続ける仕掛けを作るとか。

気持ちいいからなんとなく続けるという意味では、効果音とか、アニメーション自体が気持ちいいというのもある。

とにかく、考えだしたら本当に細かい部分までいろいろある。

ちなみに、まずは、誰か製品を欲しがる人がいるかどうか、これを確認できた後に優先度を上げる項目なので、どのタイミングでこれらの事柄に力をいれるかも難しい。

Tweet