アプリを作っているとプロダクトデザイン上の選択が次から次へと押し寄せてくる。

例えば、どのタイミングで課金メッセージを表示するのが適切か、アプリ名はA案とB案どちらがいいか、ある機能のデフォルト値をどちらにするかなどなど。

どちらにしたらいいかを悩んで、ああでもない、こうでもないと２つ３つの選択肢からどれがいいか考える。

そんな時、よく出てくるのが、「これはABテストしてみないと分からない」とか、「データがないと分からない」という反論しにくい最強のメッセージです。

しかし、これは数限りなく降り掛かってくる開発中の選択において、まったく現実的でない場合が多かったりする。

LeanAnalyticsの記事に書いたように、定量データは重要な意思決定に役立つ反面、ほとんどのケースはデータなしで決めないといけない。

ほとんどの選択は不確実情報の中でする

まず、参考になるアプリのUIや定量データをかき集めても、アプリ開発でぶち当たるデザイン上の選択には不十分なことがほとんど。

基本的に不確実情報の中で決定しなければならず、本当に役立つ情報は実装してリリースした後に分かるか、リリースした後もよくわからない事が多い。

なので、「データがないと決定できない」だと開発が止まってしまうので、不確実情報の中で、こういう理由でこれがベターだろうという判断をして前に進むしかないのが日常茶飯事。

ABテストするコストが見合うか

「この機能はつけようか、つけまいか、判断が難しい。。。」こんな時はよくあると思う。

でも、「よし、わからないからABテストしよう！」というのは現実的じゃない場合がほとんど。

というのも、ABテストするにはそれに伴う実装コストが必要で、決断を先送りすることによって失う機会費用もある。迷った時に毎回ABテストしていたら開発はまったく進まないので、ほとんどの場合はできない。

なにかをすることを決定したら、それをしなかった時にできる作業や開発の機会費用が失われるので、本当にその価値があるかどうかを考えないといけない。

経験と参考事例

そんじゃ、どうすりゃいいかとなると、地味に参考になるデータや実装事例を集めたり、行動心理の実証データを参考にしたり、自分で何度も考えるしかないと思う。

周りの意見を聞くのは悩んだ時に判断する重要な材料になったり、決めきれない時の後押しでさくっと決断するきっかけにもなったり。

UIやUXの専門家にコンサルしてもらうのも、実際にユーザーテストやデータ分析するより時間対効果が高かったという話もよく聞く。

いろいろ考えた先にいくつか選択肢が残り、メールマーケティングみたいにABテストがしやすい状況が生まれて、手間をかける価値がありそうだったらやればいいのではないかと。

それ用のサービスではOptimizelyとかいうのが最近iOSにも手を広げ始めたらしい。

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

先日Facebookのf8とかいうイベントがあった。僕は去年のf8はそこまで注目してなかったのだけど、Parseがf8に買収されたので今回は楽しみにしてました。

そしたら期待のParseからこりゃいいねという発表が２つあった。

ひとつはParseの料金体系が変わり、安くなったこと。もうひとつはオフライン時のデータベースを扱うParse Local Datastore。

特にLocal Datastoreはオフラインで使えるデータベースを実装しつつ、他のデバイスとの同期も実現したいモバイル開発者にとって死ぬほど期待の機能。ワクテカが止まらない。

なぜかAndroidのみ使えて、iOSは近日公開らしい。待ちきれん！

Parseの新しい料金体系

今までは月に一定の回数のアクセス以上は有料になりますよっていうシステムだったけど、今度は一秒間に30requestsまでだったらいくら使っても無料になった。

一秒間に40requestは月100$といった感じで、スケールしていったら高くなる。これはいいかも。ただ、気になるのはオートスケールしてくれるかってところだ。

ドキュメントを読むと、無料プランで制限を超えるリクエストが一秒間にあったらエラーが出ると。

じゃあ、普段は無料で余裕で使えてて、突然なんかの拍子でバズって、いきなりアクセス殺到してエラー連発だったら困る。こういう時に自動的にスケールして頂きたい。

でも、リミットはつけておきたいので、100$のプランにしておけば制限をその月に一回でも超えなければ自動的に無料になって、超える時があればその月は100$払うっていうシステムなんだろうか？

ここが気になる！Parseの新しいシステムでPriceの設定を見たりドキュメントを読んだかぎり、ハッキリとわからない。

100$のプランにするボタンがあるのだけど、このボタン押したら一気にその月に100$の請求来るのか怖くて試せない。

ということで、質問しておいた。
The 30 requests/second price plan can be scaled automatically?

※アップデート
残念ながらオートスケールしないみたい。100$のプランにすると、30req/sを超えてなくても請求くる。つねにエラーをチェックしてくれという悲しい返信がきた。

iPhoneアプリ同期機能の面倒さ

iPhoneアプリにデータベース機能をつける時はCoredata使うのが一般的なんだけど、アプリを他のデバイスでも同期できるようにする時に、Coredataをサーバ側のデータベースとシンクロさせるのが凄い手間。

データベースはサーバ側のみとすると楽だけど、それだと毎回読み込みが発生するので遅いし、オフライン時に使いかってが悪い。

アップル製品だけで同期すればいいという方針だとiCloudがあって、長らくぶっ壊れてて使えないと評判だったiCloud + CoredataもiOS7でいくらかましになったらしい。

でも、それでも構造上の問題でまだまだ鬼門だと海外の有名な開発者のブログとかで書いてました。僕は面倒なので、有名な人がまだまだ面倒だと言ってたら自分でチャレンジする気も起きずに悶々と過ごしてた。

理想はiOS側ではオフラインでもさくさくデータベースに保存できて、バックグラウンドでネットに繋がってたら自動で同期して、iPhoneとiPadがシンクロするといった形。

この問題で期待をしてるのが、ParseのLocal Datastore。

ParseのLocal Datastore

ParseのSDKって凄くよくできてて、データベースの実装とか本当に分かりやすく直感的なコードで書けるんですよ。

iOSのCoredataとかで書いたらすごく面倒なコードを長々と書かないといけないけど、ParseのSDKだと分かりやすくて短いコードでちゃちゃっと。

でも、Parseはもともとクロスプラットフォームで同期するためにサーバにデータをその都度送信する前提で作られてる。

一応、ParseのSDKにはキャッシュで保存する、saveEventuallyみたいなメソッドもあるんだけど、このキャッシュ機能は貧弱なもんなので、Coredata使った時みたいにはオフラインで保存して検索とか使うのは無理だった。

だから、iOSでオフラインでもサクサク保存したり、検索したり、フェッチしたりするには結局CoreData使わないといけないねっていう結論になって、iPhone/iPadで自動同期機能つけたい僕もCoredata使ってた。

で、Parseの掲示板見ても、サクサクオフラインで動くようにCoredataを使いつつ、同期機能のためにParseとCoredataを繋げる実装をみんな四苦八苦しながら頑張るという苦しみを訴えている人がたくさんいた。

Parseチームは、「今、この問題に取り組んでます。」とか一年前に書いてた。そして、一年ほどたって、Local Datastoreがやっと発表されたので期待せずにはいられない。

Coredataいらないぐらい強力だったら最高

まだiOSには対応してないから試せないのが悲しい。出たら速攻で試したい。

Local DatastoreのAndroidのサンプルコード見た限りだと、普通にParseの保存、検索などの機能がオフラインでも動きますよといったように見える。

それだと、将来同期機能を予定しているアプリに、最初からParseSDKでデータベース作ってCoredataを代替できるようになるかもしれない。

CoredataとiCloudとか、CoredataとDropboxAPIとか、CoredataとParseを上手くつなげてシンクロ機能を上手く動かすというめんどいことが一気に解決しそうなので、これは期待するなというのが無理というものです。

LocalDataStoreのコメント欄には興奮した開発者たちが、「おお、これが出たらもうCoredataとParse繋げるために今苦労してる実装いらなくなるから、いつ出るか教えてくれ！」とかみんなも期待度マックスのようです。

その気持ちは本当にわかる。僕もTaxnoteやZenyでiPhoneとiPadの自動同期機能をつけたいんだけど、実装に入るのはこれが出るまでちょっと待とうかと悩み中。

この動画の14分55秒あたりからParse創業者の発表がある。Parseの料金体系、Local Datastoreの実際のコード、AppLinkとかのデモなどがざっと全部見れるので、オススメ。特にAppLinkのデモは一見の価値あり。

※Facebook Updates Parse With Lower Prices, Improved Analytics, Offline Capabilities

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

今年に入ってから毎日の開発時間を去年の半分にしてみた。

すると、毎日凄く集中できて、空いた時間に頭にスペースが出来てアイデアもわきやすく、効率もよくなったのでこれはいいかも。

タレブとDHHの話がきっかけ

最初のきっかけは、Rails作ったDHHが「開発なんて長時間やっても逆効果だから毎日の仕事時間を減らせ。8時間じゃなくて5時間、4時間だけにしろ。それだけ短かったらSNSなんて見てる暇はない。」とスタートアップスクールで話してたこと。

あと、去年タレブのAntifragileという本を読んで、短い仕事時間を毎日やるのが長期に渡っていいパフォーマンスを出す秘訣だというような事を言ってた。

アップストアでアプリを出すのは、結果が出なければ開発時間をいくらかけても価値が０となる世知辛い世界。でもこれは完全成果主義でなかなか面白い。

毎日の開発時間の成果をいかに上げるかっていうのを考えていると、時間を絞るってのが一番よいかなと。デザインも余白が重要で、その余白こそが大きな価値を持つので。

週のノルマとかいろいろ試してた

個人でアプリ作っているから時間配分は自由にできるけど、ずっと一週間単位、一ヶ月、一年単位で一番パフォーマンス出せる時間の割り振り方はなんだろうと試してきた。

特に強制する人がいないからいつでも休めるので、ノルマというものを作ってた。例えば、週に40時間とか。そこで、毎日開発する時間をストップウォッチで計って、今日は6時間進めたとか、昨日は遊びに行ったから出来なかったから今日多めにやろうとか。

でも、同じ時間をやっても、今日は全然集中できてなくてあんまり成果でなかったなあとかよくあった。

同じ時間でも、疲れているコンディションとか、眠いとか、集中してない環境とか、その時々の状況によって成果がバラバラ。

最初の数時間は集中してても、時間がたつとだんだんと密度が薄まっているのがなんとなくわかる。

短い時間で毎日やる

で、思い切って、集中してやるのは一日3時間までの制限にして、それを休日はなしで毎日やるというルールにしてみた。

実験的に極端なことやってみたけど、ここまで短いと、いかにその時間に最大限のパフォーマンスを持っていかねばならんと必死になる。

まず、一日の一番集中できる時間は朝起きてすぐなので、ぐっすり寝て、起きてすぐ開発することになる。メールやニュースも見たら気になるので、終わるまで一切見ない。朝ご飯は水かバナナ。

ダラっとすると貴重な時間がなくなるので、SNSも絶対見ない。毎日朝に重要な公式戦があって、その時間に最大限集中できるよう準備するスポーツ選手みたいな真剣度になる。

一日にまとめてやった９時間と、極限まで集中してフレッシュな状態でやった３時間×３日の９時間だと、合計時間が同じでも時間当たりの開発の密度や成果が段違いに違った。

なにをやるかにシビアになる

これは新しい発見だったけど、時間が短く指定されると、なにに時間を使うかを今まで以上に真剣に考えるようになる。

開発のTODOリストを作る時も、ここは今やるべき価値があるかとか、今日時間使う意味あるかとか。

数ある重要なタスクの中で、今日やる部分は本当に現時点で最優先するべきなのかを凄く真剣に考えるようになった。以前も考えてたけど、時間が限られてるからその緊迫さが月とスッポン。

なぜかハマりにくくなった

プログラミングしてる時はなにかでハマることが多いのだけど、時間がすぎて次の日になったら新しい角度で検証する方法がころっと出てきたりして、何もできずに時間が過ぎる事がなぜかなくなった。

でも、ハマるとムキになってしまって、悔しくて寝れなくなるので、ついついルールを破って延長してしまう時もたまにある。このムキハマり現象が一番の敵だ。おのれとの戦い。

で、そんな時に時間たってもあまり成果がでなくて、一晩寝ると別の方法が思いついて解決したりする。

後はあっさり諦めて次に進んで後から思い返すと、そこまで時間をかける価値がなかったなと冷静になったり。

また、一日を過ごす上で頭の中に余裕ができる時間ができたので、今やっている作業を違う角度で見たり、新しいアイデアを考えやすくなった気がする。

作業中は夢中でやってても、時間を置いてみたら、「あれは優先度そこまで高くないから、あそこまで時間かける意味はなかったな・・」と冷静に振り返る時間が増えたり。

問題点

このやり方の問題点は、いい感じにフロー状態に入った時にタイマーがなって、「もうちょっとやりたい。。」ってしょちゅうなること。

一日の開発時間が短すぎると平日はなんか暇なので、ついついもっとやってしまう時がある。

ただ、延長してしまうと、それに慣れてしまって、フロー状態に入るスピードも下がって、延長すればするほど時間単位の集中度クオリティが下がるのもわかる。

悩ましい。

ただ、一週間ぐらいだと、倍働いた方が量の違いで成果は出るかもしれないけど、二週間以上や一ヶ月以上で見ると、全体の成果は短い時間のほうがよい気がする。感覚的に。

一生仕事してもよいかも

以前は、ずっと仕事するのは嫌だから、早く引退して遊んでくらしたいなあと思ってた。

でも、短い時間で毎日やるなら一年ずっとやっても特にストレスたまらないし、一生続けてもよいかもと思った。これも予想してなかった新しい感覚。

今はハードに仕事して将来楽するぞっていうのより、マラソンみたいにずっと一定のペースでやりたい性格なので向いているのかもしれない。

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

個人的にずっと切望していたiTunesConnectの機能がついに実現していた。今日気づいたのでぜひ紹介してみる。

小さな変化だけど、このお手軽最終チェックのおかげで不幸な出来事を未然に防ぐ開発者が増えるのではないだろうか。

ちなみに、Model部分のロジックをやるユニットテストではなく、UIを自分でいじってする、”サブミット前にいろいろテストしたけど念のために最終チェックしよう”の話です。

アップデート審査通ればリリースする前にプロモコードでテストできる

以前のiTunesConnectだと、1.0.1バージョンとかの、アップデートされるアプリをストアにリリースする前にプロモコードが使えなかった。

ちなみに、一番最初のリリース(1.0)なら単純にリリース時期をずらす事によってリリース前にプロモコードでテストは昔から出来たのだが、その後のアップデートのバイナリではできなかった。

上記の写真だと、右上のプロモコードのボタンがなかった。これが表示されるのはReady for Saleになったアプリだけだった。

どういうことかを僕のTaxnoteで説明すると、

1.Taxnote1.0を始めてリリース。
2.Taxnote1.1という次のバージョンを審査に出す。
3.Taxnote1.1が審査に通る。
4.Taxnote1.1をストアに出す前に、開発者だけストアからダウンロードして最終テスト。
5.最終確認で問題なさそうなので、Taxnote1.1のリリースボタンを押して、全世界でTaxnote1.1にアップデートされる。

以前は4の部分ができなかった。

つまり、Taxnote1.1のアップデートが審査に通った後、自分だけプロモコードを使ってAppStoreからダウンロードしてテストするという最終確認作業が出来なかった。

やった。これがずっとやりたかった。GJアップル！

TestFlightでよくないかについて

もちろんTestFlightを使って、アップルにサブミットする時のバイナリをAdhocでアップロードすれば、ほぼ同じバイナリで実機テストすることはできる。

今までこうやってた。

でも、100％アップストアにリリースされるバイナリと同じという安心感、もっというとお手軽感はでかい。

ようは、テスト環境と本番環境という超えられない壁があり、プロモコード使うとリリース前に本番環境でテストできると。

最終的にストアにリリースされる次のバージョンのバイナリをTestFlightにアップロードして、それでテストしてたつもりが、なんかの間違いで少し微妙にバージョンが違ってて、それがバグに気づかない原因となり。。といったシナリオはなくなる。

そういった恐ろしい事は今までなかったけど、やっぱアップデートする直前って凄い怖いんですよね。

いろいろチェックしたけど、なんかの間違いでおかしなところないだろうか。。とか、なんとかリリースボタンを押す前に、このiTunesconnectにアップロードされている同一のバイナリを実機で最終テストしてみたいといつも思ってた。

I will Releaseでサブミット

この方法を使うには、アップストアに次のバージョンをサブミットする時、アプリが承認されたら自動的にストアにリリースされる設定ではなく、自分でリリースするタイミングを決める設定にしておく。

上記だと、下のI will releaseのほう。これだけでOK。

ちなみに、実はDeveloper Forumで去年の６月頃に、アップデートリリース前のバイナリでもプロモコード使わせてと書き込んだんですよ。
でも、TestFlight使えばいいじゃんと他の人にいわれて、もひとつ理解されなかった。

でも、今回のiTunesConnectで実現したので満足です。

TestFlightの配布ってやっぱ面倒な部分があって、受け取る側への負担もでかいけど、これで承認された次期バージョンをアップデート前に限られたグループの人だけに配布などできますね。

追記 ※3月6日

アップルのサーバ側の反映時間の関係で、たまにプロモコードを使っても現在のバージョンがダウンロードされてしまう時があるようです。

アンインストールして再ダウンロードしたらストアのバージョンがダウンロードされるなどの報告ももらいました。僕が試した限りでは、どちらの場合も次のバージョンがダウンロードできたので、たまに挙動が変わるのかもしれません。

挙動の情報提供にはSylfeed作者の@gachalatteさんにも教えてもらいました。@koogawaさんからは、iOS6、iOS7どちらでも成功したとも教えていただきました。

追記 ※3月23日

アップルにアップデート版が承認されて、すぐプロモコードを使おうとしても、「エラー：このコードで利用できるバージョンはダウンロードに対応していません」というエラーが出ました。承認後8時間たってもこのエラー出ました。次の日の朝まで待ったら問題なくいけました。

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

先日、弥生会計やFreeeをサポート、爆速で会計入力できる青色申告アプリTaxnoteをリリースしましたという記事を書いたら、想像以上に反響があった。

これは確定申告の時期的なものもあると思うけど、作っている最中は常に”そこまで需要はないかも..”という恐怖との戦いだったので、ニーズがありそうでよかったです。

いつもなにかアプリを作る時は、実際にコード書き始める前に需要があるか少しでも把握できないか考える。

それはもちろん時間かけて作っても誰も欲しがらなかったというリスクを避けたいからに他ならないのであるが、結果的に、今回もほとんど何も分からず作ってリリースすることになった。

時間と効果のバランスでいろいろ選択肢を試したけど、結局リリースまでにほぼ何もわからなかったという過程を書いてみる。

コンセプトページで需要リサーチを検討

まず、去年自分が青色申告するようになって、日々の仕訳入力を素早くできるアプリが欲しくなったのです。

青色申告の本を読みあさったり、流行のクラウド会計や既存の会計ソフトの動向とかを研究して、ニーズもありそうだなと作る気持ちになったのが12月の頃。

ただ、自分が本当に今すぐ欲しいというのは最低限のスタートとしても、自分以外の人でどれだけの数の人が欲しがるかはわからない。

よく新製品を出す前にランディングページだけ作ってそれの反響で作るかどうか決めるとか、ターゲットユーザにお金を払う価値があるか聞いてある程度いけそうだったら作り始めるという、需要がないものを作るリスクを下げるリーンスタートアップ的な手法がある。

これは、一見、夢のような手法だ。

ただ、あれはやろうと思ったら結構難しくて、明確なイメージを聞く相手に持ってもらえるかが重要で、そういうサイト作成や調査のコストをかけても曖昧な情報しか得られない場合が多い。

あと、アプリやサービスのタイプによっても違ってきて、ターゲットユーザとすぐ会えるとか、BtoBですでに代替サービスを使っているところに流れ込むなどの場合にやりやすいと思う。

作る前に顧客が獲得できたらしいOptimizelyのような場合もあると思うけど、もし作る前にニーズを調査したい場合、動画付きのランディングページを作るとか、LaunchRockとかで作ってそれをターゲットの人達に見えるところに拡散しないといけない。

その時になんとも反応がない場合、そのサイトがダメなのか、ターゲットユーザに見られてないのか、アプリのニーズがないのかの判断がまた難しい。さらに、どの数字がリアルなのかの判断も難しい。

これは、なんかアイデアを思いついたらすぐ作るのがいいと言っているわけではなくて、もちろん今回もコードを書く前に、ユーザとなりそうな人に直接意見を聞いたり、自分が本当に欲しいかいろいろなソフトやアプリを研究して、どこに絞るべきかまではコード書く前に時間をかけた。

ただ、どれぐらいの人数の人が欲しがるかは以前としてわからないなと。

ということで、今回は、最も重要な部分に絞ったものを作って、ストアにリリースして、リアルな反応を見た方が時間帯効果が高いと思って作る事にした。

開発ブログを立ち上げる

今年に入ってから開発を始めたんだけど、作ってもニーズがないかもと思いながら作るのは怖い。

TweetMashの時とか、作ってみたものの毎日のダウンロード数が１とかで特に反響もなく自信を喪失した過去がフラッシュバックしてガクブル状態。

技術的な勉強とか他の目的があればそれほど気にしなかったのだけど、お金を払ってもらえる価値のあるアプリを作るというのが目的だったので、自分でコントロールできない予測不可能な部分はどうしてもリスク。

これに対する一番よい対処策は、やっぱり重要な部分に絞って早くリリースすることにつきると思う。

それに加え、なにか新しい事をしたかったので、作る過程を公開する開発日誌ブログを毎日書くことにした。

今回は開発初日からほぼ毎日やった作業を記録してました

そこでTaxnoteのコンセプトを書いておいて、読んだ人で興味がある人はリリース時にお知らせするからメアド登録してねみたいなボックスを作っておいたのだが、それを登録してくれた人は5人ぐらいで、あまり反応はなかった。。

今でもコツコツと書いているけど、あれはマーケティングというより自分の自己満足で続けている感じだ。最近は一応１日に50PVとか行く時もあるけど、まあそんなもんです。

でも、このブログもなんも記事書いてない時の平均は150〜200PVぐらいなので、そこまで悪くはないのかもしれない。

というわけで、ブログ記事を書いても、Twitterでこういうアプリを作っているとか毎日書いてても特にそんなに反響もなく、リリースしたら分かるのかなあと考えながら作ってた。

ちなみに、開発を始める前に、こんな会計アプリはどうだろうという、アイデアだけを書くというブログも書いてたけど、そっちも対して反響はなく、まったくニーズがあるかは不明であった。

あれは白色申告・青色申告どっちを選ぶべき？みたいな、一般的な記事も混ぜて工夫してたのだが。。

リリースされて分かったこと

AppStoreでTaxnoteがリリースされた日に、よし、ランディングページを作るほど時間はかけれないけど、少なくともブログ記事を書こうと思って、出来るだけアプリの良さが伝わるように書いてみた。

これについては、この日の開発日誌ブログの、Taxnoteが一日で承認されたので、短時間で出来る効果の高い宣伝方法で悩んでVine使ったに詳しく書いてる。

そしたら、思った以上に記事がTweetされて非常に嬉しかった。

なんというか、毎日、平常運転なモチベーションで開発してたけど、アプリの事を呟いてくれたり、アプリ内の意見ボックスから要望とかがくると、一気にアドレナリンが駆け巡り、アプリ開発のモチベーションが沸騰する感じです。

そういう意味で、普段の開発モチベーションが圧倒的に上がるので、早くリリースしてよかった。

この記事で、Vineの動画がわかりやすいという意見をたくさんもらったので、実際に動いている動画が乗っていたのがでかいと思う。

そこで思う疑問が、このブログ記事と同じような内容を、アプリが完成する前に書くことができたか？ということ。

まあ、物理的にはできる。ようは、見た目だけ動いているUIを作って、動画とブログ記事でコンセプトを伝えればよいわけです。

しかし、開発期間の間に、あのUIはああでもない、こうでもないと、実際にコーディングしながら変化していったのもあり、その間に動くものを周りの人に見せてアドバイスをもとにコネコネと作っていた。

だから、コーディングを始める前に同じようなブログ記事を書く事は実質できなかったのです。

せいぜい、青色申告の記帳業務が大変で、クラウド会計使っても現金部分は手動だからiPhoneでサクサクやりたい。といった部分を文字で説明するぐらい。

アプリの見た目より、実際に長く使い続けたくなる操作性に力をいれて作るので、やはり動いているものがないと厳しいと思う。なおかつ、すでに使えるものが出来たという状況もプラスだし。

その他、アプリを使ってくれている人がいるか、アップグレードまでしてくれる人の割合などの数字、要望や使いかってのフィードバックなど、一番大事なこともわかった。これはリリースしないと絶対分からない部分。

ついでに、会計ソフトの会社からいくつか連絡がもらえて、これもリリースして反響がなければ無理だった。

こうすればめちゃくちゃ使いやすい会計アプリが出来るというビジョンはあるので、フィードバックを参考にしながらTaxnoteを素晴らしいアプリにしたい。

結論

今回の記事はただの一例で、作る前に需要をリサーチできる部分と、リリースしないと分からない部分は状況によって変わってくる。

リリースまでの開発コストがどのぐらいかによっても、バランスも変わる。

それを前提としたうえで、今後新しいものを作る時は、リリースする前に分かる限界を意識して、ここまできたらもう作り始めてリリースを早めたほうがよいという見極めを大事にしたいです。

Taxnoteの場合は、「作ろうかな、どうしようかな、でも誰も欲しがらなかったら開発時間が無駄になるしな。。」と悩んでる期間が無駄に長かった気がする。その間に青色申告の知識は増えてたけど。TweetMashが悲惨だっただけにビビリが。。

関連記事

TweetMashが見事にこけた

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

青色申告・白色申告の帳簿入力を劇的に楽にするiPhone/iPadアプリ、TaxnoteがAppStoreでリリースされました。めでたい。

このアプリは、エクセル、弥生会計、Freeeなどで確定申告する人が、日々の記帳業務をiPhoneから爆速で入力できるアプリです。

日々の経費を楽に記録したいというフリーランス・個人事業主の人向けに作りました。

Taxnoteをダウンロード

なぜ作ったか?

去年、僕自身がアプリ開発をする個人事業主として青色申告を始めたのがきっかけ。

申告に関する本読みあさり、近くの青色申告会に入会して帳簿作りのイロハを教えてもらった。

弥生会計などの会計ソフトを使えば、最終的に必要な帳簿の作成は凄く簡単になるけど、一番大変なのは日々の記帳業務。

確定申告に必要な決算書は会計ソフトが自動的に作ってくれるけど、それを作成するもとになる、日々の経費をコツコツ記入していく作業が相当めんどくさい。

そこで、時代の最先端を体験しようと思った僕は、話題のクラウド会計Freeeを使うことにしました。

Freeeでも現金入力は手動

Freeeやマネーフォワードなどのクラウド会計は、クレジットカードを登録すれば明細を自動的にダウンロードし、それを元に、日付と金額、予測した勘定科目などをセットしてくれる。

これでかなり楽になる。

ところがどっこい、当然のごとく、現金で支払った分はレシートを持って帰って、その都度ペチペチと入力しないといけないのです。

Freee公式アプリが最近出たのでさっそく使ってみたのだけど、Taxnoteの快適さに慣れるとさすがに戻れない。

支払い後、素早く経費を入力できるアプリ

損益計算書、貸借対照表などの決算書作成は弥生会計やFreeeなどのソフトが自動で作成してくれる。

しかし、日々の支出入力を、お金を払ったその場で、iPhoneから素早く入力できるアプリが必要だとなった。

iPhoneでやるのは仕分け入力だけでいいのです。

仕分け入力したデータを弥生会計やFreeeなどのソフトにエクスポートすれば、決算書までの細かいところを任せられる。

AppStoreにある会計系のアプリをほぼ全て試したけど、操作性の面でどれも満足できなかった。勘定科目の選択はすぐ覚えるので、レシート自動認識など逆に時間のかかる動作は早い段階で却下となりました。

日々発生する仕分け入力をお金を支払ったその場で、iPhoneを使って爆速で入力できるアプリ。この体験だけに照準を絞った最高のUIを作ってやると思い立ち、何度も何度もUIを作っては捨てを繰り返しました。

どれだけ爆速か？

このアプリは仕分け入力を、片手で、最小タップ数で、爆速で出来るということを追求しました。

上記の動画で入力された項目は、

日付: 本日の日付 (自動)
支払い方法: 現金 (初期設定。普通用金などへの切り替えも素早く可能)
勘定科目: “接待交際費”を選択
摘要: “飲食代”を選択 (次の画面で摘要欄をタップすれば手動入力も可能)
金額: 支払い金額を入力

これらの項目のうち、毎回選択が必ず必要となるのは勘定科目と摘要と金額３つ。

この動作をアプリ起動からスムーズにすること、見た目でフローが分かりやすくすること、何度もタップするボタンは押しやすい位置に配置すること、文字表現の分かりやすさ、フォントやボタンの大きさなどなど、操作性を何度も詰めに詰めて作り込みました。

支出を入力すると仕訳帳が出来ます

Taxnoteでは、ユーザが仕分け入力すると複式簿記で記帳された仕分け帳が自動的に出来上がります。

Excelや会計ソフトにエクスポート

アプリで入力した仕分けデータは、エクセルや弥生会計、やよいの青色申告、Freee、MFクラウドなどでインポートできる形式で、メール経由でエクスポートできます。

期間指定も自由にできる。

会計の知識は必要か？

入力時に必要な勘定科目の選択は慣れれば難しくない。よくある支出の勘定科目を何にするか覚えれば後はルーチンワークです。

ただ、青色申告の帳簿付けが完全に初心者の人の場合、弥生会計使おうが、Freeeやマネーフォワードを使おうが最初のスタートダッシュは厳しいと思う。

その意味では、Taxnoteは記帳業務をすごく楽にするアプリではあるけど、青色申告や確定申告で必要な仕分けの知識がなくても使えるアプリではないのです。

ただ、一度、青色申告のやり方を本で勉強するなり、相談するなりして、日々の経費を記帳するやり方さえ覚えれば、Taxnoteは強力な便利アプリになるはずです。

気に入ったら購入してもらう形式

無料版ではそれぞれの月に15件までの仕分け入力と、CSV形式(Excel)でのエクスポートのみとなってる。アップグレードすると月の制限がなくなり、弥生会計やFreee形式でエクスポートできるようになる。

気に入ってもらった人に、一度限りでのアップグレードをしてもらうフリーミアム形式。iPhone・iPad版どちらかで購入すると片方のデバイスは無料でアップグレードできます。

レシートを持ち帰ってポチポチと会計ソフトやエクセルに仕分け入力するのは苦痛だし手間なので、その時間を買うという意味で、気に入ったら購入してもらえると嬉しい。

*更新 Taxnoteは進化してます

この記事を書いたのは2014年2月なので動画も古いバージョンですが、現在のTaxnoteはさらに使いやすくなっています。

飲食店経営の方、美容師さん、税理士さん、フリーライター、エンジニアなど、個人、法人問わず、幅広い方に使ってもらい、ストアのレビューも700以上で平均4.5の評価をもらっています。(2015年6月時点)

一年以上コツコツとアップデートしているので、今ではカレンダーから日付選択、パスコードロック、損益表の出力、電卓など、シンプルさを守りつつ、さらに便利になりました。よければ使ってみてください。

Taxnoteをダウンロード

確定申告する方は、こちらの記事も参考になるかも。
フリーランスの確定申告対策をぶっちゃける – 青色申告と白色申告、手間も考慮した本当の費用対効果

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

先日Twitterを眺めてたら、iOSアプリの価格モデルについての記事を発見。

Paid, Paymium or Freemium?

“有料アプリは死んでないよ”みたいなツイートと共にリンクが貼られてたと記憶してる。Clearを作った会社が書いたいい記事。

価格設定というのはその製品の戦略やポジションそのものを決定するとても重要な要素。僕もいつも悩む。

最近のアプリは有料アプリがどんどん売れなくなってきていて、売り上げランキングでもアプリ内課金がほとんどを占めてる。

アプリ戦国時代のご時世、いったいどうすればいいのだろうか？

価格モデルで悩んでいる人に参考になりそうなので、かんたんに要約して、それをネタにいろいろ書いてみたい。

ゲーム系でもある程度は参考にはなるかもしれませんが、主にプロダクト系のアプリを前提にしています。

有料アプリ

いろいろ言われてるが有料アプリモデルはまだ死んでない。特にツール系アプリでブランド力がある場合、有料モデルはまだまだよい選択肢だ。

有料アプリはセール時のプロモ効果があるだけでなく、ブランド力があるならとても上手く機能する。

有料モデルはここ18ヶ月減少傾向であり、アップストアの36％が有料アプリで。Distimoによると、アップストアの売り上げの4％しか占めてない。

しかし、無料アプリばかりになった今、有料アプリのプレミアム感が相対的に向上して有料モデルが復活するかもしれない。

僕は有料モデルが以前みたいに売れるようになる可能性は低いと思う。

アプリの数が増えれば増えるほど全体の質は落ちるので、ダウンロードして数秒で削除するようなハズレを引く可能性が高い状況でユーザが気軽にお金をさくっと払ってくれるとは思えない。

返金システムが変わるか、動画紹介やプロモーション方法が大きく進化するか、Appleが有料モデルをプッシュするような仕掛けに本腰をいれない限り厳しい。

でも、Appleのビジネスモデルはデバイスからの売り上げが大きく占めており、アプリの平均価格が低いほうがiPhoneは売れやすいので、構造的な問題であまり大きく期待できないのが現状。

製品の質とブランド力に自信がある場合は有料買い切りモデルがマッチするけど、問題は、製品の質とブランド力があるデベロッパーはほんの一握りだという点。

例えば、TweetBot3などは有料アプリが下火だからといってフリーミアムにしてたら逆効果だっただろうというのが分かりやすい。

さらに、有料買い切りモデルを成功させるにはプロモーションでも高いレベルが要求され、間違いなく数年前より敷居は高い。

僕の中では、有料買い切りモデルでの敷居が高い部分は、最初のリリース時から完成度と、それに備えたプロモーションを用意しないといけなくて、売れるかわからないアプリだと失敗した時のリスクが高いところだと思っています。

まとめると、ブランド力があり、すでにマーケットがあると確信があり、バージョン1.0に力を入れられるなら、有料買い切りはよい選択肢。

ランキングでも有利で、セールというブーストも使える。

あと、長く使い続けるかはわからないけど、一度触ってみたいという魅力があるアプリにも向いていると思う。

フリーミアム

※ここでのフリーミアムの定義は、無料でダウンロードできて、アプリ内課金を売るモデル。

たくさんの開発者が単純にフリーミアムに移行して、なにも得ずに失敗しているのを見てきた。

無料でユーザに与えすぎたか、与えすぎなかったかが原因であり、経験と知識がないとフリーミアムで成功するのはとても難しい。

アップストアでの売り上げの92％はフリーミアムのアプリからだが、実は、アップストア全体でフリーミアムのアプリが占める割合は11％だ。

一日に5,000万円以上稼ぐフリーミアムモデルのアプリもあるが、成功しているのはほんの僅かであり、それらの会社は新規ユーザを獲得するための戦略や、分析などにたくさんの投資をしている。

フリーミアムで収益をあげるにはたくさんのダウンロード数が必要。小さなデペロッパがフリーミアムタイトルで、長期的な収益をあげるのはとても難しい。フリーミアムモデルを選択する時は十分慎重にならないといけない。

ここで指摘しているように、フリーミアムモデルの場合、どこまで無料で、どこからアップグレードにするかの選択がとてもとても難しい。

ちなみに、アップストアのルールでフリートライアルは禁止されているので、Webサービスでよくある、30日間無料で、その後続けるには有料というモデルが使えない。

なので、Dropboxみたいな無料でも使えるアプリにしないといけないので、そこの境目を考えるのが難しい。

ちなみに、”みんなが使いたがる機能は無料にし、一部のハードコアユーザだけ必要な機能に課金する”というフリーミアムモデルの考え方が参考になるかも。これも、時と場合によるから難しいけど。

このモデルのメリットは、たくさんの人にとりあえずアプリを試してもらえるところ。

有料買い切り+無料バージョンの二つ出す場合と同じじゃないかと思うかもしれないけど、二つに分けるより、アプリ内ですぐアップグレードできるほうがシンプルで待ち時間もないので、ユーザフレンドリです。

気に入った人にだけ購入してもらうので、アプリに自信があれば、価格も買い切りモデルより高めに設定しやすいとも思う。

上手くいっている参考事例がPaperですが、このモデルを採用した時点で、ある程度のネガティブフィードバックは避けられない運命にもあります。

他のデメリットは、買い切りモデルと違い、有料版をプロモコードで配ることができない。

これは、なにかトラブルがあった時にお詫びとしてユーザにプロモコードを渡したり、レビューアに無料のプロモコードで試してもらうことができない。

他には、セールでダウンロード数を増やす無料のプロモーション活動が使えない。

ちなみに、元記事にある、”フリーミアムで利益を出すにはダウンロード数が相当数必要で難しい”という指摘は正しくないと思う。

ダウンロード数がそこまでいかなくても、コンバージョン率 x 一人当たりの単価が高い場合もあるからだ。

僕は有料買い切りモデルと無料+アップグレードは有料のフリーミアムモデル、どちらもやったことがあるけど、基本的にフリーミアムが多いです。

一番の理由は、新しいアイデアのアプリを早くリリースして、反応を聞きながらアップデートしていくという開発方法がフリーミアム型に合っているからです。

ペイミアム

元記事の最後では、「有料で最初に購入してもらい、一年ごとのアップグレードや追加機能にアプリ内課金で購入してもらう」という、ペイミアムというモデルも最後に紹介されている。

このモデルは今後可能性があるので、試していきたいと書かれているけど、これは有料買い切りアプリを売るよりハードルが高そうである。

まず、有料アップグレード機能をAppleが採用しないと無理だし、有料で購入したアプリでさらにアプリ内課金があると、アップストアの一般的なユーザ心理としてはかなり難しいと思う。

ただ、新しいモデルにチャレンジする先行者は常に応援するつもりなので、難しいだろうなと思いつつも、ぜひ頑張って頂きたいです。

僕も、あれが上手くいったとか失敗したとか、出来る限り試した事をブログでシェアしていきたい。

長くなってきたけど、価格モデルをネタにもうちょっと書いてみたい。

広告型

カジュアルゲームでは広告型が多いけど、プロダクト系のアプリではあまり広告型はみない。

これは、プロダクト系のアプリでは広告が嫌われるという要素もあるけど、実は広告のマッチング率の話なんじゃないかと思う。

アプリ広告を専門にしている人に詳しく聞いた事があるんだけど、日本でアプリ広告にお金を出す会社は、同じくアプリで儲かっているアプリゲーム会社が多い。

となると、似たようなユーザからの流入が期待できるカジュアルゲームのほうが、ユーザがその広告をタップしてくれる確率が高くて、その後、広告先のアプリをインストールしてくれる確率が高い。

例えば、毎日使う便利系のアプリに広告を出しても、それを使うユーザはゲームアプリに興味がない人が多く、タップしてくれる人はほとんどいなくて、広告単価が下がって、いれても儲からないというサイクルになるらしい。

ただ、モバイルでのEコマースが今後広がり、マッチング率も高まったら、プロダクト系のアプリを使っている人でも興味のある広告が出やすくなる可能性が高まるので、今後は変わる可能性がありそうです。

例えば、Gunosyというレコメンド系のニュースアプリにコマース系の広告出したら、もの凄い結果がよかったと最近聞いて、ほほーそうなんですかとびっくりした。

広告モデルはシンプルにユーザからお金を貰うモデルに比べ、サービス側が誰を優先するかのインセンティブが広告主とユーザと二分されてしまう難しいデメリットはあるけど、WebだとStackOverFlowというプログラムのQ&Aサイトみたいに、プログラマの求人広告がウザくない感じで上手く表示されているケースもありますね。

また、地味に重要なポイントとして、個人開発者がアプリを出す時に有料アプリは心理的ハードルが高いけど、広告モデルだと気軽にアップストアに出してみようかなとなりやすいこと。

ちなみに、サブスクリプション型とか、iOS7から可能になった買い切り => フリーミアムというやり方や、買い切り型とフリーミアム同時に出すとか、まだいろいろあるけど、さすがに長くなりすぎるので止めようと思う。

一番重要なこと

価格モデルを決定するうえで最も重要なのは、ユーザを知ることだと言われます。

自分のアプリを使ってくれる人はどういう人達なのか。さらにいえば、どういう人達に向けて売りたいか。

また、往々にして、実際にリリースする前に、この値段で払いますか？と聞いても無駄なことが多い。

人間は「喜んで払うよ」という人も、使った後に、「これは違うな、これじゃ払わないわ」となったり、「絶対払わないわ」と言っていた人が、「これはいいものだから払ったわ」となったりすることは日常茶飯事だし、自分もたくさんそういうことがある。

価格モデルには正解がないので悩ましいところです。

参考記事

discounted app upgrades suck
なぜか元記事のリンクが消えてたのでしょうがなくキャッシュ先。開発者が長年訴えてきた、有料アップグレード機能がなぜ最悪のユーザ体験に繋がるかの一読の価値ある文章。

How to Develop Your SaaS Pricing Model
SaaSを前提にしてるけど、価格設定の基本的な考え方は共通なので凄くいい。

ユーザーインタビューで製品にお金を払うか聞いても無駄な理由

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