Page 24 of 29

昨日はお台場で開催されたMaker Faire Tokyo 2013に行ってきた。

自分は普段アプリ作ってるだけで、DIYとかの知識もMAKERSって本を読んだぐらい。予備知識はさっぱりだけど、非常に楽しめた。

まず、お台場近くの駅につくと、派手なトラックが集合してた。なんか、トラック野郎のイベントが近くであったようだ。

しばらく歩くと科学未来館が見えてきた。

中に入ると人がたくさんいて、活気に満ちておった。とりあえずどんなもんかと一階の展示をながめてまわる。

すると、早くも未来的なロボコップの手みたいなものを発見。今までは400万ぐらいしてたものが、3Dプリンタのおかげで、数万ぐらいのコストで作れるようになったとか。

こういう話はMAKERSにも書いてたけど、個人にカスタマイズされたものが安価に作れるようになるらしい。

こちらが初めて動くところを生で見れた3Dプリンタ。

こちらはカメラをつけた小型ラジコンみたいものを自作していた親子らしき方達の作品。ラズベリーPIを基盤にして、ジョイスティックで通信されてきている画面を見ながら操作できる凄いもの。

これで人間がなかなか入りにくい場所に画面見ながら探索するとかできそう。お父さんらしき人が説明してくれて、小さなお子さんがパソコンの操作をしてくれてた。いいですな。こちらが、制作していた方のブログ。

七階に行くと、一気に女子力の高い一室の部屋があり、手芸っぽいものや、レーザーカッターで作ったかわいいハンコが置いてあった。

なんとこの階では、先日カヤックの横浜支社でハッカソンをした時に知り合った松田さんの奥さんがブースを出していた！iPhoneやiPadに使う革製のケースやアクセサリーの展示してた！声かけてもらって気づいた。

COLOOというハンドメイドのブランドで、最近話題のBaseを使ってオンラインショップをやっていると教えてもらったので、紹介してみる。すごく本格的。
http://collo.thebase.in/

ちなみに、この女子力高い部屋でなぜか、右手に装着して攻撃力を高めるというガジェットの展示があったらしい。らしいというのは、後から一緒に行ったお友達に写真をもらって、あのブースでこんなの展示してたよと教えてもらったからだ。

なんでも、近接攻撃が今回のMakersフェアで最強だという触れ込みらしい。バネを使っていて、実演してもらおうとしたら今回は故障してて上手く動かなかったとか。僕はなんでこんな面白い展示に気づかなかったのだろうか。

この一室の後に回ったのが、視線を感知するモーションセンサーのブース。

視線を感知する部分のプログラムがオープンソースで出ているとか、これ系の勉強会で、すごい人達に生で教えてもらえて嬉しいとか、リアルな話をいろいろしてくれて、やばいな、DIYいろいろと熱いなと興奮してしまいました。

自分もやりたくなってきた

さて、しばらくいろいろ見ていると、なんか自分もDIYで作りたくなってきた。でも、自分はプログラミングはしたことがあっても半田とか、工作系はさっぱりやったことがない。

そもそも、なにが作れて何ができるかっていうのがさっぱりよくわからない。RaspberryPiなどの小さな基盤が安価に買えて、それにキットを組み合わせていくといろいろな可能性があるというのはだいたい聞いててわかったのではあるが。

こういう時は、なにか作りたいものをまず考えないといけないなと思い、いろいろ思索にふけっていると、小型の肩たたき戦車みたいなガジェットが欲しい事を思い出した。

電気屋さんで売っている50万ぐらいのマッサージチェアは場所も取るし、高い。そこで、うつぶせに寝転がった時に、背中にちょこんと乗って、ゆっくり上下に動きながら肩たたきしてくれる小さなラジコンみたいなものがずっと欲しかった。

これ作れたら毎日寝る前に使いまくって最高だなあと思ったので、「こういうの作りたいんですけど、可能ですかね」とかRaspeberryPiのブースの人とかに聞いてみると、それは電源が足りないから、モーターが必要だとか、ヒントとしてはRaspeberryPiを使って工作機械を作っているブースがあるから参考になるかもとか、ものすごく的確なアドバイスがもらえた。

うーむ、こんなちょっと思いついた事を聞けて、専門家がいっぱい集まっているので、素晴らしいなと感謝。なんといっても、RaspeberryPiで始めるDIY入門みたいな本が紹介してあって、それを書いた人達がブースにいるわけです。

しかし、いろいろ考えていると、ちょっと初めての自分にはレベルが高いかもと思ってきた。なんか、プログラミング初心者なのにそこそこ学習コストが多岐にわたるものを考えちゃう昔のパターンだなと。

ということで、ここは、さらにもっと簡単なものを考えようと思って、ブースを回っていると、なんと、iOSアプリと連携するDIYですみたいなものを発見。Konashiというツールらしい。これなら普段IOSアプリ作っている人がDIYに手を出す導入にぴったりじゃないかと説明をうんうんと聞いてた。

なんと、Konashiを使ったガジェットの展示品を見ていると、AppSociallyの堤さんが作成に参加しているものを発見。先日会った時に、「最近デバイス系のハッカソン行ってきたんですよー」って言ってたから、これか！！！と思った。

ここで、肩たたき戦車より、もっと簡単なものを考えようと思い、家にある壁スイッチの横に、吸盤みたいなものでくっつけて、単純にiPhoneを操作すると、バネみたいなものでボタンを押してくれるというガジェットを考えた。

これは、夜寝る時とか、いちいち立ち上がって部屋の電気を消すのがめんどいからです。あとは、朝起きた時とか、すぐに寝ながら部屋の電気をガッとiPhoneから操作してスイッチをつけたい。

これなら電源もそこまで必要ないから簡単じゃないかと。Konashiのブースで聞いてみると、横にあったFab x Fabといういろんなパーツを売っているブースを紹介してくれた。

すると、このブースの人達がまた凄く親切で、アイデアを話すと、それならBluetooth LDEでアプリ側から送信さえすれば、このパーツでオンオフを受信できるから、後はサーボモーターをつけてバネを動かすといいと思います。みたいな的確な説明をもらえた。素晴らしい。パーツを買う時は、Fab x Fabでみんな買おう。

こういうパーツってどこで売っているんですかと聞いたら、秋葉原にはあるけど、やっぱりオンラインが一番品揃えいいとか。
http://www.fabxfab.com/

まとめ

普段アイデアを考える時はアプリ側で実現できる壁があるけど、ガジェットのレベルまで脳みそを拡張すると、本当にいろいろな事が実現できるなあとワクワクした。

アプリだけで生活をがらっと変えるものを作るっていうのはある程度の限界があるんだけど、DIYキットみたいなものでちょこっとしたものでも作れるようになると、一気に幅が広がって、もの凄く便利なものが作れるかもしれない。

というわけで、大満足なお台場遠征でした。

※参考リンク
MAKERS―21世紀の産業革命が始まる
誰でもできる! Raspberry Piで楽しもう (日経BPパソコンベストムック)

※追記
Konashiを詳しく紹介した連載を発見。
konashiとiOSアプリを連携させる

Twitterで壁スイッチを作っているブログを教えてもらえた！
【Arduino】照明のスイッチをブラウザから操作してみる

Tweet

またまたファスト＆スローについて書いてみる。この本は凄く面白いからしょうがない。

行動経済学とか、プロスペクト理論とかの部分は定番すぎるのであえてスルーして、今、カーネマンが一番力を入れてるらしい、人間の幸福に関する研究の部分について書いてみる。

それは、経験による幸福と記憶による幸福の概念。

カーネマンはここで、幸福になるためにはこうしましょうとか言ってるのではなく、ある意味、より幸福だと感じていることが、脳みそによる錯誤なんじゃないかという面白い見方をしてる。

終わりよければそれでよしについて

簡単にいうと、人間は途中までの経験が辛くても、終わりがよければ幸福だと感じるけど、 その人による記憶と、客観的な部分を重視するかで見方をが変わってくる。

例えば、温水に二分間手を入れた後、一分間だけ氷水に手を入れる場合。氷水に二分間だけ手を入れて、最後の一分間に温水に手を入れた場合。この二つを比べると、最後に温水に手を入れた後者のほうが人間はましだと感じるのが実験でわかっている。

これは、終わりよければすべてよしの精神に通じるけど、最後がよければ、人間はそっちのほうが幸福だと感じるように脳みそができてるかららしい。

でも、客観的に考えると、全体的につらいのは氷水に二分間も手を入れたほうだから、これは人間の記憶による幸福と実際に起こった事で違いがあることになる。

悪代官と苦労人の助平

この経験と記憶の話を読んでいると、よくある話を思い出した。物語であるのが、すごい贅沢な暮らしをしている悪代官にたいして、「お前！ろくな死に方しないぞ！」とののしる場面。

実際、物語では悪代官が最後は悲惨な死に方をしてしまって、ずっと苦労をしていた貧乏人の助平さんが最後は幸せに暮らしましたとさ、みたいな話。

これ、普通に考えると、人間は最後の死に方というものを凄く重視する。

でも、客観的に考えると、悪代官も助平も50年生きたとして、極端な話、悪代官が49年間贅沢三昧の好き放題で楽しくくらして、最後の一年間だけつらい形で死ぬのと、助平が49年つらい思いをして、最後の一年かんだけ幸せに暮らして死にましたというのは、どちらがよいのだろうかという難しい話になる。

経験と記憶どちらを重視するか

経験による幸福と、記憶による幸福、どちらが大事なのかという難しい問題については、哲学者が何年も前からずっと考えてきた命題であるとカーネマンは本の中で語っていた。

そういや、物理学者のファインマンの本とか読むと、哲学者なんていうものは、ひたすら揚げ足とりの理屈ばっかり物理学者に投げかけてきて、なんか世の中の発展に役立ってるのか、とかひたすら愚痴ってたけど、カーネマンは心理学者だから哲学者にたいしての見方が違うんだなと面白かった。

人間の記憶に残るのは最後の部分なので、こういうどうでもいい事を最後に書くのはよくないなと思い、TEDのカーネマンの講演を見つけてきました。

Tweet

最近よく考えていることに、UXのバグというものがあります。名前は勝手につけてみた。

ようは、アプリを使っていて、ユーザが混乱したり、分からない部分が発見されたら、UXのバグが発見されたと考えてる。

このUXのバグとフィードバックループは密接に関わっていて、Aという機能がすでにあるのに、ユーザから「Aという機能をつけてください！」とか問い合わせがあると、UXのバグがあるとなります。

問い合わせ以外に、データ分析で使われていない機能を計る事でも分かる。

このバグの治し方として一番いいのが、UIをパッと見て分かりやすくする、ボタンの名前を変える、メッセージやイラストで分かりやすくする形だと思う。

そして、ヘルプページのFAQに書くという最終手段もあります。

この最終手段は、多くの事をUI上のメッセージで書くと、情報過多でノイズが増えすぎてどうしようもないとか、ごくまれなケースとかに使います。

ヘルプやFAQも長くなりすぎると、FAQが読みにくくなるから、何でも放り込むわけにもいかないし、使いたいという強い思いがあるユーザ以外は読まない。

このUXのバグはある程度は経験から想定できる場合があるけど、リリースして初めて分かる部分も多い。

そして、UXのバグの重要度も、問い合わせメッセージの頻度から計りやすい。

課金部分でのUXバグ

例えば、今までの経験だと、”アプリの復元”というアプリ内課金を無料で復元できるというボタンに対する問い合わせが多かった。

「iPhone4sから、iPhone5sに変更したのですが、以前の機種でアップグレードしても、再度購入する必要があるんですか？」という質問。

僕は、復元という名称は分かりにくいと思って、ボタン幅が長くならない程度に「購入の復元」という名前で設定画面の右上に設置していたんだけど、分かりにくいので問い合わせがきてるんだと思う。復元は開発者向けの用語だし。

音声文庫の設定画面。

考えられるやり方として、アップグレードボタンのすぐ下に、「以前アップグレードした方はこちら」というボタンを置くとか、位置や表記を工夫できないかなと考えてます。

「復元は知っているけど、パスワードを要求される時点でもう一度お金払っちゃわないかと不安になるので念のため質問しました」という問い合わせもあった。

これを聞いた後は、まだバグがあるなと思い、最初のメッセージをもっと工夫して、不安を取り除かないといけないなと思った。

購入部分のUXのバグはすごくセンシティブだし、自分もWebサービスにお金を払う時は、たぶんこういう動きするだろうけど、大丈夫かな？と不安になる事が多いです。

TweetMashの購入画面はこんな感じでテスト中

２種類のフィードバック

ユーザからのフィードバックがあるというのは、そのアプリを気にかけてくれる人がいる証拠なので、基本的によいことだけど、それにも大きく２種類ある。

機能リクエストや、こうしてほしいというリクエスト型の問い合わせと、「これはどうするの？」とか、「ここが動かない」という技術やUXのバグに対する問い合わせ。

後者の問い合わせが何度も来るということは、バグが治っていないという意味で、それを治さないと、何度も同じ内容の返信を繰り返したり、ヘルプページに誘導しないといけない。

一人が問い合わせしてる時点で、その裏では50人以上の人が経験していてるんじゃないかと思ってます。ほとんどの人は問い合わせするのはめんどくさいと思うだろうし。

大多数のユーザは、アプリの説明文も読まないし、スクショも見ないし、ヘルプページも見たくないので、使っていく過程で、自然と、ストレスなく適切なタイミングで疑問点が解消されるよう、UXのバグをプチプチ潰して行くしかないと思う。

UXの作り込みと優先度

そして、技術的なバグとUXのバグの大きな違いに、最小限の機能でリリースする初期バージョンでは、すべてのUXに対応する事が難しいのも悩む。

機能が少ない段階で技術的なバグは出にくいけど、初期起動時の分かりやすいUXの作り込みなどは、それ事態が手の込んだ機能の一つなので、どういう優先度でそれに取りかかるべきかのトレードオフが難しい。

やったほうがいい事は無限にあって、どの順番で、どれからやるかが難しいところです。

一番コストパフォーマンスがいいのは、名前とメッセージをよく考える事だと思う。コーディングの時間もかからないし、バグも発生しないし。

Tweet

以前、カーネマン先生のファスト&スローを読んだのですが、この本は素晴らしいので、アプリのUI設計やマーケティングに関わる人にぜひオススメです。

本で学んだ事は多岐にわたるけど、とりあえずUI設計に役立つ事を書いてみたい。

認知リソースのHP

以前から気にしてたけど、この本を読んでさらに気をつけるようにしているのが、アプリのUIを考える時の、認知リソースです。

僕は認知リソースのHP（ヒットポイント）と勝手に呼んでる。

ようは、認知リソースのHPが100あるとしたら、アプリを操作する時にだんだんと無意識にそのHPゲージが削られていくことを意識してます。

例えば、モバイルアプリ使っている時は、ノートパソコンを使っている時と違い、外出中で周りに騒音があったり、近くに魅力的な姉ちゃんのポスターが貼ってあったりと、認知HPがどんどん削られる機会が多い。

アプリをダウンロードするまでの、スクショでも削られる。ストアのスクショの中で説明する文字が多すぎると、インストールする前にユーザの認知HPが削られていく。

アプリを開いて、チュートリアルが長いと、いらいらして認知HPが削られる。

ボタンやメッセージの長さが長いと読むたびに認知HPが削られる。

ローディングに1秒かかるごとにHPが減っていく。

この認知HPが０になったら、めんどくせえとなって、ユーザはアプリを閉じてしまう。なので、離脱率と認知HPゲージは密接に関わってくる。

操作を学習しても削られるHP

自分のアプリの操作方法をユーザが学習してくれた後も削られる。

以前の僕は、少し学習コストが高い操作だけど、一度覚えてしまえばこっちのほうがはるかに使いやすいとか、一般的なUIと少し違うけど慣れると価値があるとか、そういう時の敷居を低く見積もってました。

いったん学習すればOKだろうと思うことも、ファスト&スロー読んだ後に、もう少し慎重になりました。絶対やらないというわけでなく、かなり慎重になった。

つまり、ユーザが学習してくれたUIでも、その他のアプリを使った後、自分のアプリに戻ってきた時に認知HPが削られる。

「あれ、そうそう、このアプリの操作はこうだったよな」とユーザは無意識に頭のスイッチを切り替えたとしても、二つの異なるUI操作をアプリによって頻繁に頭で切り替えるのは認知リソースを食うので、離脱率が高まる。

ファスト&スローでは、人間が無意識に行動できる直感的な動きと、論理的に考えないといけない動きをする時の仕組みを詳しく書いてる。

直感的な動きから外れると論理的に考えないといけないシステム２が動きだし、これにはとてもエネルギーが必要で、人間は出来る限り節約しようとする。

この認知リソースを出来るだけ節約してくれるアプリじゃないと、すぐに閉じられて、二度と開いてくれないかもしれない。

ということで、本を読んでからは、一般的な動き、メッセージ、名称、それらをいっそう意識するようになってきて、少し変化を加える時は流れの中での認知HPの推定ゲージを考えるようになってきた。

新しいUIや操作方法にチャレンジする時は、この事を十分考えて、それでもやる価値があるのかどうかを何度も考えるとか。

Tweet

二年ほど前まで、一年間ほど、スカイプで日本語とプログラミングのスキル交換をしてたイスラエル人のお友達、Eranさんが東京にやってきた。

EranはBinpressというプログラマーのためのマーケットプレイス・サービスをやっていて、それの関係で日本にきたのでついに会う事ができたのです。

僕は三年ほど前、一念発起してPHPを独学で勉強始めたんですが、三か月ほどでメンターの必要性を感じ、海外の掲示板で、「日本語教えるから、PHP教えてくれる人いませんか？」と募集したら、たまたま見つかったのがEranさんだった。

iPhone開発に移るまで、１年ほど、１週間に１回スカイプで１時間日本語教えて、１時間PHPのアドバイスをしてもらうというのをやってた。

Webサービスを作りながら、基本的には本やネットで調べるんだけど、どうしても設計でつまづく部分やら、MVCの綺麗な分け方とか、リファクタリングとか、自分で調べても分からない部分があった。その部分を短い時間に集中してアドバイスしてもらうっていう形だった。

この時は、スカイプ上でなかなか教えるのも難しいだろうに、こんなにスラスラと的確なアドバイスができるとは、世の中には頭のいい人がいるもんだなと、いつも関心しておりました。

僕のほうといえば、日本語を教えるんだけど、そんなに上手くなかった気がする。年が近いのがよかったのかもしれない。

さて、そんな形で、今でもSNSやらで繋がっていたのですが、ついに昨日リアルで会う事が出来て、「おおー」と感動を覚えた。

これほど長い間、スカイプやらで話していたり、お互いの写真も見ていたのに、リアルで会うまでこれほど時間がかかった人というのは人生で初めてだったからかもしれない。

そうはいっても、リアルで実際に会ってみても、まあ、スカイプでずっと会話とかしてたから、今まで通り自然な感じで、「ああ、今の時代、リモートで働いている会社の人達ってこんな感じなんだろう。」となんだか変な実感をした。

文字チャットだけに比べて、声も聞けるボイスチャットというのは特にでかいと思う。最近はビデオチャットもストレスなくできるようになってきたし。

クーリエジャポンで書いてたけど、近いうちにホログラム技術が発達して、遠くにいながら隣で仕事しているような体験がいっそうリアルになる可能性があるらしい。

いやはや、技術発展というものは凄い。

Binpressについて

ちなみに、EranとAdam(二人は学生時代から、十年以上の付き合いらしい)が一緒に作ったBinpressというサービスを応援したいので、紹介する。

これは、プログラマーが自分で作ったコンポーネントとかライブラリを売買できるマーケットプレイス。デザイナはWordpressのテーマとか売るサイトがあるのに、プログラマのそれはないから作ったらしい。

ちょっと前に500Startupsに入って、今回はBDashベンチャーズというイベントに参加するので日本にきたらしい。

このサービスは、もちろん初期の頃から教えてもらってて、最初はGithubとかで無料のライブラリが主流だからそういうのは流行るのかな？と思ってたけど、順調に成長しているらしい。

なんと、自分で作ったコンポーネントを売って、シリコンバレーの平均的なエンジニアの年収と同じぐらい稼いでいるエンジニアも普通にいるというから驚きです。

こういう形でプログラマが稼げる選択肢が出来るというのは素晴らしい事だと思うんですよね。

例えば、最近はアプリを売って収入を得る事ができるようになり、Webサービスだけの頃に比べてマネタイズはしやすくなっている。

しかしですよ、アプリをストアで売って生活するのって、プログラミングの技術に加えて、マーケティングの比重も大きいから、技術に集中したい人には面倒が多いと思う。

まあ、コンポーネント売るのもマーケティングやサポートは必要なんだけど、より技術的に高度で自分の得意な部分で稼ぎたいという人がお金を稼げる選択肢が増えれば、開発者コミュニティにとっては素晴らしい。

以前はオープンソースでいいじゃないかと思ってたけど、例えば、僕が作っているVoicepaperとかには有料の音声エンジンSDKを使っているんだった。

世の中には、みんなが参加したがるジャンルのライブラリと、凄くニッチだけど一部の人には需要があるライブラリとがあるので、後者はお金が発生しないとなかなか質の高いものが提供されにくいだろうというのはある。

現状だと、有料のSDKはそれなりの質があるけど、そういうのを提供しているのは、ほぼ企業オンリーで値段も高い場合が多い。

ここにイノベーションが起こってくれれば、さらにアプリやサービスが作りやすくなるので、ぜひ応援したい。

左がAdam、右の西武警察みたいなのがEran

Binpressが乗っているTechcrunchの記事。
B Dash Campが大阪で開催、ピッチコンテストで国内外から11社がプレゼン
ソースコードのオープンマーケットBinpressがイスラエルからカリフォルニアに引っ越してGithubを統合

※ちなみに、日本でのコミュニティマネージャを募集中らしいです。英語と日本語出来て、日本の開発者コミュニティにアプローチできる人が適任みたい。
http://www.binpress.com/jobs/positions#community

あと、プログラミング用語が分かって、Binpressのサイトを日本語に訳せる翻訳者の方も切望してるみたいなので、もし興味がある方がいれば上記からコンタクトしてみてください。

Tweet

少し前、スタートアップのための実践的なデータ分析といった趣旨であるLean Analyticsという本を読みまして、これが素晴らしかったのです。

「僕みたいな小規模のアプリだと、たいしたデータ量もないんだし、分析なんて参考にならんでしょ、初期段階はユーザーフィードバックだけでOK！」と以前は思ってたんですが、間違ってました。

直接ユーザの声を聞く定性的なフィードバック、データを使った定量的な分析、アプリをよいものに改善していくのには、どちらもすごく大切で、おろそかにできないなと最近は実感しております。

ポールグレアムも、ちゃんと計測しろみたいな事を言ってましたね。

Webのマーケティング担当者からすると当たり前の事かもしれないけど、とりあえずLeanとつけるバズワードに乗っかろうと思います。

Lean Analyticsってどんな本？

数々のスタートアップを経験してきたAlistairさんとBenさんが、スタートアップのための実践的なデータ分析において、どう見るか、どう改善につなげるかを、様々な例を上げながら説明していく本。

リーンスタートアップで有名になったエリックリースも監修してる。

僕は、ABテストを事あるごとにしてたら意思決定が遅くなるし、そもそも、重要なビジネス上の方向性やUIの方針なんて、データを見て多数決で決めるものじゃないだろうと思っております。

まず人間が考える仮説があって、それを検証したい時にABテストが、そのコストに見合うだけの時間と労力が取れるならやればよくて、とりあえず意見が分かれたら、なんでもデータで判断しようという姿勢はよくないという考えなのです。

でも、この本は、ちゃんと、そういう部分もしっかり書いている。大きな視点や仮説は人間の頭で考えるべきであり、データにとらわれてはいけないという本で、凄くよかった。

とても印象的だった文章が、ここ。

データは中毒性があり、すべてを分析したくなるかもしれない。でも、実際に私たちがする事のほとんどは、無意識であり、経験や実践が土台になる。

実際に、精密な分析より、経験や知恵に頼る事は道を開く鍵にもなる。

結局のところ、毎朝、着ていくパンツは何にするかをABテストしていたら、いつまでたっても家から出られない。

リーンスタートアップへの批判として、あまりにもデータドリブンすぎるという意見があるが、ある意味、的を射ている。

大きな視点を持たずに、データだけで意思決定をするのは危険だ。データに捕われるのではなく、データを参考にするようにしないといけない。

ちなみに、Lean StartupもRunning Leanも邦訳が出ているけど、この本は出てないのが残念なところ。

細かい説明や実際の例も豊富なんだけど、すべて紹介していたらきりがないので、重要だと思った部分を４つ書いてみる。

虚構の数字(Vanity Metrics)に注意

見てて気分はよくなるけど、それを見て、何をどう改善すればいいのかが分からない、実際の行動につながらないのが虚構の数字。

ダウンロード数や、アクティブユーザー数などは増えると喜んじゃう分かりやすい数字だけど、それに惑わされてはいけない。

例えば、ダウンロード数だけ見ても、それは何が原因でダウンロードが増えたかが分からないと、どう改善すればよいかもわからない。

ダウンロード数が多くても、ほどんとの人は起動してすぐに離脱しているかもしれない。

アクティブユーザー数であっても、時間がたてば自然と増えていくものなので、それだけでは参考にはならない。

数字を見た時は、これを知って、自分はなにか改善に繋がる行動をできるかどうか。ここを常に意識する。

注意する虚構の数字の例として、ヒット数、PV、ユニークビジター数、Like数やフォロワー数、ダウンロード数などがあげられてた。

行動につながる数字(Actionable Metrics)を見る

実際の行動に繋がらない数字より、それを知って、なにか改善に繋がる行動が起こせる数字を見る。

その一例として、全体数よりも、割合(パーセンテージ)をあげてます。割合はシンプルで、比較できて、取りやすい。

例えば、ユーザ登録が必要なサービスで、その部分のUIを改善してアップデートしたら、以前のバージョンと新しいバージョンで、総数ではなくて、パーセンテージがどう変わったかを比較する。

これは別に数字とかだけじゃなくて、いろいろな事に繋がるなと思った。

なにかを研究したり調べたりする時に、最終的にふーんとだけにならず、実際の行動が変わるかどうか、変わったか、ここを結構意識するようになった。

改善すべき指標は、重要なもの一つに

サービスが初期段階か成熟期かで、重要な指標が変わる。

例えば、会員登録のステップを改善したい段階なら、そこだけに集中する。アプリへの定着率や購入率など、いろいろな部分に手を出さずに一つに絞って改善する。

今現在どこが一番重要な部分かを考え、一つに絞る。

でも、最初はどこが一番重要なのかも検討がつかないですよね。

なので最初は仮説から入るしかないし、いろいろな指標をチェックしたり、全方位でフィードバックを聞くしかない。

自分は、アプリのステージによって、どこを優先してアップデートするかを意識して開発するようになりました。

例えば、最近出した音声文庫という青空文庫読み上げアプリでは、”まずは、初めてアプリを開いた人が、どんな小説を読めばいいかを助けるオススメ部分を強化する。”という点に絞ってアップデートしました。

想像もしてなかった事への気づき

製品を開発している時に重要な、２つの要素。

１ 自分が知らないと知っている事
２ 自分が知らないと、自分でもまだ知らない事

例えば、１の例だと、自分がそれを知らないけど、重要だと分かっていて知りたいと思っている事。

アプリを使い続けてもらっている割合とか、ユーザ登録や有料版へのコンバージョン率など、どうしたらそれらを改善できるか。

こういうのは自分の頭の中で重要だと思っていて、知りたいと分かっている。

２は、重要なんだけど自分がまだ想像もしてないことで、まだ気づいてない事。頭の中で想像もしてないから、自分からは調べたりはせず偶然発見するしか道がないもの。

これはデータ分析に限らず、ユーザーフィードバックからでもひょんな事から想像もしなかった事を発見する時は多い。

例えば、僕のVoicepaperだと当初は自分が読みたい本を耳で家事洗濯中に聞きたいから作ったんだけど、アプリのフィードバックでいろいろな使い方がされている事がわかったりした。

自分で書いた文章の誤字チェックに使ってますとか、英語学習に耳で聞きながら読んでますとか、青空文庫の小説を聞いてますとか、数々の驚きの発見が。

こういう偶然の発見が発生しやすいような状況に持っていくのがとても大切なので、そういう意味でも、とにかく早くリリースして学びながら改善するのは大事だなと思っています。

英語ではLearning by shipping とか言うらしい。カッコいい。

アプリでの実践

というわけで、勉強した事を参考に、どうアプリの改善に繋げていったかを今度の勉強会で話す予定です。

ボトルネックをどう発見して、UIを改善して、どう検証したかの話。間違っていた数々の直感の話。

ユーザーフィードバックを出来るだけ聞いて、リリースしながら学んでいくために気をつけている事とか。

僕のアプリは特に有名でもないしスタートアップでもないですが、この発表では、本を読めば分かる事ではなく、実際に体験した実例を中心に話したいと思っています。もしよければ。

「Lean Analyticsとアプリの話」(9月6日金の勉強会)

参考記事

アプリに組み込むヘルプサービス、Helpshiftがいい
iPhoneアプリのクラッシュレポートCrashlyticsが最高すぎる
一番リスクの高い部分から始める

Tweet