個人でアプリを出しているあなたへ、成果ゼロを隠さず晒す集計監査の記録
個人開発の収益記事は、なぜどれも成功譚なのか
個人でアプリを出している人の記事を読んでいると、あることに気づく。表に出てくる話が、ほぼ全部「売れました」「MRRこれだけになりました」「ここまでの学び」で構成されていることだ。
売れていない側の話は、なぜか出てこない。
売上ゼロの実測、ゼロが続いた期間、ゼロをどう記録したか、集計そのものは正しかったのか。この四つを一度も書いていない個人開発の収益記事を、私はまだ読んだことがない。
これは書き手の問題ではないと思う。売れていない話は書きにくい。何を書けば読み手の役に立つのかも分かりにくい。だから書かれない。書かれないから、これから個人開発を始める人が最初に触れる情報が、全部「うまくいった側の断片」になる。
だからこの記事では、逆をやる。iOSアプリを複数本出していて、直近の計測窓ではすべて確定売上が0円だった記録と、そこに至る集計の設計と、その集計自体にバグがあってAIに指摘された話を、隠さずに書く。
何をやったか、を先に短く書いておく
やったことは大きく二つだ。
一つは、App Store Connect の Analytics API から自分のアプリのダウンロード数と収益を毎日引いてきて、出所つきの台帳に落とす仕組みを書いた。これを Python のスクリプトにまとめて、日次で回すようにした。
もう一つは、その台帳を「AI役員会」と呼んでいる自分専用のレビューフローに流して、集計そのものを審査させた。要は、自分で書いた集計スクリプトを自分で信じずに、AIに二度チェックさせている。
なぜそこまでやるかというと、個人開発の売上は、金額そのものより「本当にその数字なのか」の方が信頼を左右するからだ。特にゼロが続いているときに、集計バグでゼロが千円に化けてしまったら、その千円は自分の判断を全部歪める。ゼロはゼロで、正しくゼロと記録されていることが分かる状態でないと、次に何を直せばいいかも決められない。
実測 — 直近の計測窓は、確定売上が0円だった
具体的な数字を出す。
対象は iOS アプリ5本。計測窓は 8/16 から 8/18。この期間の確定売上は、5本合計で0円だった。
ダウンロードの実測はこうだ。Ukaru というアプリは、この期間に一日あたり約1本のダウンロード。Minori というアプリも、一日あたり約1本のダウンロード。しかもそのうち一本は、フランスからのiPad利用者だった。
私は日本語圏を想定してアプリを作っていて、海外のiPadユーザーを狙って何かをやった記憶はない。それでも Analytics API のデバイス別・国別の内訳を見ると、iPad からの一本がフランスに立っている。この一本が偶然なのか、それとも私の知らない導線で誰かが見つけてくれたのか、その答えは今のところ持っていない。検証していない。
売上ゼロが続いていて、ダウンロードは一日一本前後で、うち一部は想定外の国から。個人開発でアプリを出している人の多くは、この規模の数字を、実は誰にも見せずに一人で抱えているんじゃないかと思う。この記事は、その状態を隠さずに書いておくためのものでもある。
AI役員会が、集計スクリプトから見つけたバグ
さて、この集計を回し始めてすぐ、AI役員会からの戻しが来た。
指摘の内容はシンプルだった。「あなたの集計は加算型pullになっている。同じ日を二回引きに行くと、二回分が加算されて記録される。今はゼロだから見えないが、売上が立った瞬間、それは真の金額の二倍として記録される」
これを聞いた瞬間、背筋が寒くなった。売上がまだゼロだから、この不具合は今の台帳上は見えない。加算しても、ゼロ足すゼロはゼロだ。バグは静かに寝ている。
もしこの状態のまま、明日いきなり最初の一本が売れたとする。私はスクリプトを二回走らせるかもしれない(手動で確認したくなる場面はよくある)。すると、その最初の一本の売上は台帳では二本分として記録される。私はそれを見て「あ、売れ始めた」と勘違いする。実態の二倍を売上曲線として認識してしまう。
こういうバグは、規模が小さい今のうちに見つけた方がいい。売上が動いてから発覚した場合、過去の台帳を全部遡って再計算する羽目になる。しかも、その頃には自分は「売れ始めた」という気持ちで判断を色々変えているかもしれない。判断の土台が二倍に歪んだ状態で下した意思決定は、あとから取り消すのが難しい。
指摘を受けて、集計は「置き換え型」に書き直した。同じ日を何度引いても、その日の値はAPIから返ってきた最新の値に上書きされるだけで、加算されない。冪等性を担保した、と言えばそれっぽいが、要は「二回引いても壊れない」に直しただけだ。
売上が立つ前にこのバグを潰せたのは、正直、運が良かった。もう少し集計の設計を後回しにしていたら、間違いなく最初の売上を二倍で誤認していた。
「ゼロを正しくゼロと記録する」ということ
この経験でひとつ、はっきりしたことがある。
売上ゼロというのは、集計上何もしなくていい状態ではない。ゼロには「本当にゼロだった」と「集計が回ってなくてゼロに見えているだけ」と「引き方が壊れていて片方だけゼロで、もう片方は二重計上」の三種類がある。この三つを区別できる台帳を持っていない限り、あなたはゼロを見ているのではなくゼロっぽい何かを見ている。
台帳の各行には、その数字の出所を書いておく必要がある。Analytics API のどの日次レポートから引いたのか、いつ引いたのか、その日ノーレポートだった場合は「no-report」と明示的に記録する。ゼロと no-report は区別する。売上ゼロと、その日集計が走らなかった、は全然別の話だ。
これをやっておくと、あとから「この期間、本当に売れていなかったのか、それとも計測が抜けていたのか」を自分で検証できる。売れ始めたあとの意思決定は、この検証可能性の上に立つ。逆に、この基礎がないまま「なんとなくゼロだった気がする」で議論を始めると、その議論全体が砂上に建つ。
AIに集計を任せて分かった三つのこと
一つ目。売れていない段階でこそ、集計の設計は真剣にやる価値がある。数字が動き出してからバグを見つけると、過去を遡って直すコストと、それまでの判断を疑い直すコストの両方が乗ってくる。動いていないうちに壊しても、失うものが少ない。むしろ、動いていないからこそ集中して直せる。
二つ目。自分で書いた集計を自分で信じない、という運用は思ったより効く。AI役員会と呼んでいるレビューフローは、要は「同じコードを別の目で二回読ませる」だけだ。それだけでも、加算型pullのような静かなバグは、売上が動く前にちゃんと落ちる。人間の目だけで自分の書いたコードを見ると、書いた本人には見えないものが多い。
三つ目。ゼロを隠すインセンティブは強い。売上ゼロの記事を書くのは書き手にとってつらいし、読み手が求めているものでもない気がしてしまう。でも、ゼロの実測と、ゼロを正しくゼロと記録する設計の話は、これから始める人にとって、成功事例の断片よりも役に立つ場面がある気がする。少なくとも私はこの記事を、始めた頃の自分が読みたかった。
使った道具について、正直に書いておく
集計に使ったのは Python の小さなスクリプトで、App Store Connect Analytics API から日次レポートを引いて、JSON の台帳に落とすだけのものだ。特別なフレームワークは使っていない。台帳の各行にはその値の出所(どのレポートから引いたか)を書いていて、no-report の日も一行占有する。ゼロと no-report は区別する、と書いたのは、この設計を指している。
AI役員会と呼んでいるレビューフローは、私が個人で使っている作業の型で、汎用の商品として売っているものではない。ただ、やっていることは複雑ではない。書いたスクリプトを、目的と前提条件と期待する振る舞いをまとめたプロンプトと一緒にAIに渡して、「この設計で壊れる場面を全部挙げてくれ」と頼むだけだ。今回の加算型pullの指摘も、この問いかけの中で出てきた。
同じことは、道具を選ばずに自分でやれる。特別な仕組みは要らない。プロンプトを整えて、書いたコードと一緒に渡して、壊れる場面を全部挙げてもらう。それだけでいい。
この記事を読んでいる、あなたへ
もしあなたも個人でアプリを出していて、直近の売上が思うほど伸びていないなら、まず集計から見直してみることをおすすめしたい。売上が伸びていない話をする前に、いま見ている数字が信頼できる数字かどうかを自分で検証する。それだけで、次に何を直すかの解像度が一段上がる。
ゼロが続いていること自体は、必ずしも悪いニュースじゃない。ゼロを正しくゼロと記録できていること、それを他人に見せられる状態で持っていることは、次の判断のための土台になる。逆に、ゼロっぽい何かを抱えたまま次の一手を打っても、その一手が効いたかどうかも判断できない。
私は今も、iOSアプリ5本の直近の売上が0円で、ダウンロードは一日一本前後という状態から動いていない。この状態から何をやっていくかは、この記事の続きに書いていく予定だ。もし興味を持ってもらえたら、フォローしてもらえると嬉しい。
連絡先は mirai@miraiunicorn.com。同じように売れていない側から個人開発をやっている人がいたら、集計の話でも設計の話でも、気軽に書いてほしい。
<!-- ここから有料 / note エディタで「ここから先は有料」を挿入 -->
