【個人開発】リリースして2ヶ月で 『PMF』 を達成するためにやったこと・やらなかったこと
はじめに
はじめまして、マイクです！
都内のIT企業でiOSエンジニアをしています🍎
はじめてnoteを書きます。ワクワク。
突然ですが個人開発者の皆様！
こんな経験はありませんか？
「アプリをリリースしてもほとんど使われない」
「新しい機能をたくさん追加しても、デザインを改善してもなかなかダウンロードされない」
僕自身、これまでいくつかアプリを開発してきましたが、リリース後にほとんどユーザーが増えず、そのまま開発をやめてしまうことが何度もありました。
ダウンロード数が少ないと、機能が足りない気がして、新しい機能を追加する。
デザインが悪い気がして、画面を作り直す。
それでもなかなか使い続けてもらえない。
そこで今回は、気がして（=感覚）を捨て、データを見ながら開発を進めました。
「どこで離脱し、どんな改善が継続率に直結するのか」
を整理してから進むこと、他にもたくさんのルールを作ってアップデートを繰り返しました。
その結果リリースしてから約2ヶ月でPMFを達成できました！
時系列でいうと、2026年4月にアプリをリリースして6月にPMFを達成してます。
そもそもPMFとは？
PMFという言葉、初めて聞く人が多いと思います。
PMFはProduct Market Fit（プロダクト・マーケット・フィット）の略です。
一言で表すと、
「作ったプロダクトが市場のニーズに合い、ユーザーに継続して使われている状態」
です。
「このアプリが市場から求められている」
「これからも使い続けたい」
と思ってもらえている状態だと僕は捉えています。
PMFについては、田所雅之さんの『起業の科学』に詳しく書かれています。
課題の見つけ方から、仮説検証、MVP、PMFまでが体系的に整理されているため、興味がある方はぜひ手に取ってみてください。
起業の科学スタートアップサイエンスVer.2
この記事では、PMFを達成するためにやったこと、逆にやらなかったことも紹介します。
先に結論を言うと、重要なのは
SNSでバズらせることでも、
たくさんの機能を作ることでも
ありません。
とにかく優先順位を間違えないこと。
そして、やらないことを決めることです。
個人開発は企画、デザイン、実装、分析、集客まですべて一人で行います。
だからこそやれることが多いです。
「今、このプロダクトにとって一番やらなきゃいけないことは何か？」
「次のフェーズへ進むために何を解決する必要があるのか？」
を考え続ける必要があります。
その優先順位の付け方は、記事の後半で詳しく説明します。
PMFの基準
「何をもってPMFを達成したと言えるの？？」
という疑問が湧いてくると思います。
今回、僕はPMFを達成できたかどうかを判断するために、次の3つの数値をPMFの基準として設定しました。
DAU100人以上
5週目継続率20%以上
アプリのコア機能CVRが60%以上
それぞれ、簡単に説明します。
DAUとは、1日にアプリを利用したユーザー数です。
例えば、その日に100人がアプリを使った場合、DAUは100人になります。
今回は、毎日一定数のユーザーに使われている状態を確認するために、「DAU100人以上」を基準にしました。
5週目継続率とは、アプリを使い始めたユーザーが、5週目以降にも利用している割合です。
例えば、100人がアプリを使い始め、そのうち20人が5週目にも利用していれば、5週目継続率は20%です。 一時的に使われるだけではなく、1か月以上使い続けてもらえているかを確認するための指標です。
コア機能CVRとは、アプリをダウンロードしたユーザーのうち、コアとなる機能を使った人の割合です。
コア機能とは、アプリの価値を提供するメイン機能のことを指します。
有名なプロダクトで例えると、amazonであれば「購入」、youtubeであれば「動画視聴」などです。
アプリをダウンロードしただけではなく、ユーザーにアプリの価値を届けられているかを確認するための指標です。
DAU100人以上
5週目継続率20%以上
アプリのコア機能のCVRが60%以上
「じゃあこの数値はどうやって決めたの？？」
結論、僕一人で決めたわけではなく、けいさん（「けい@生成AI×アプリ開発」）と壁打ちしながら決めました。
僕は2026年4月に、けいさんのnoteのメンバーシップに入会して、それ以降定期的にけいさんと1on1をして、アプリの分析や、マーケティングについて相談しています。
（けいさん、本当にいつもありがとうございます🙇♂️）
話は戻りますが、前提としてPMFは全てのプロダクトに共通する明確な基準があるわけではありません。
アプリのジャンルや利用頻度によっても見るべき数値は変わります。
毎日使うアプリと、月に数回使うアプリではDAUや継続率の考え方も異なります。
そのため、今回設定した数値がすべてのアプリに当てはまるとは考えていません。
アプリの利用シーンや特性を踏まえて、
一定のユーザーが毎日利用している
アプリのコアとなる機能が実際に使われている
一時的ではなく、1ヶ月以上使い続けられている
これらを意識するために、先ほどの3つの数値的基準を設けることにしました。
さて、数値的基準を決めると、なにが嬉しいのでしょうか？
その答えが「優先順位が決めやすい」という冒頭にお伝えした大事な要素なのです！
例えば、
DAUが足りなければ、新しいユーザーが来ていないのか、既存のユーザーが離れているかを確認する
コア機能のCVRが低ければ、初回体験を改善する
継続率が低ければ、使い続けてもらえない理由を考える
具体的な数値目標を設定したことで、やるべきことを判断しやすくなりました。
やったこと
PMFへの意識以外にも、効果があったTryはたくさんありました。
実際にやったことを共有します！
1. 自分が本当に使いたいと思うアプリを作った
まずアプリ開発の出発点は、大きく分けると2つあると思っています。
一つは、自分自身が使いたいと思うアプリ
もう一つは、家族や友人、特定のユーザーなど、他者が使いたいと思うアプリです。
どちらが正しいというわけではありません。
他者のニーズを深く理解できていれば、自分が当事者でなくても、価値のあるプロダクトは作れると思っています。
ただし、その場合は、ユーザーインタビューや行動観察などを通じて、課題を深く理解することがマストだと思っています。
今回作ったアプリは、僕自身が実際に困っていた課題を解決するものでした。 そして、リリース後も、僕自身が日常的に使い続けています。アプリのファンです。ただ自分が使っているからといって、必ず市場が存在するとは限りません。
しかし少なくとも想像だけで作った課題ではありませんでした。
この「想像だけじゃない」がめちゃめちゃ重要だと思っています。
「アプリを使わなくなると、自分の生活が少し不便になる」
「だから自然と毎日使う」
この状態は、「課題が本当に存在している一つの証拠」だと思っています。
個人開発では、大企業のように何十人、何百人へユーザーインタビューやアンケートを行うのが難しいです。
だからこそ、自分自身が深く困っている課題を選ぶことには、大きなメリットがあります。
ユーザーがどんな状況で困るのか。
どんな体験なら使い続けられるのか。
どんな不満を感じるのか。
自分自身がユーザーだからこそ、仮説の解像度を高く保ったまま、適切な改善を続けることができます。 これだけで的外れな機能追加はなくなります。
2. とにかく一つの体験・機能にこだわった
アプリをリリースすると、さまざまな要望が届きます。
また、自分が普段から使うアプリだからこそ、
「こんな機能もあったら便利そう」
「この機能も追加したい」
と、新しいアイデアが次々に思い浮かびます。
競合アプリにある機能。
SNSで反応が良さそうな機能。
実装してみたい技術。
しかしこれらのすべての機能追加をしませんでした。
重要視したのは
「ユーザーが迷わずコア機能を使えて、アプリの価値を実感できるかどうか」
です。
そのために以下を意識しました。
コア機能までの動線はわかりやすいか
不要な説明や画面はないか
アプリを使うメリットがちゃんと伝わっているか
操作することへの不安がないか
新しい機能を追加するよりも、コア機能を使うまでの障害を減らすことを優先しました。コア機能のCVR60%を超えるまでは、他の改善は二の次です。
機能が増えると、プロダクトが成長したように感じます。
開発者としても、新しい機能を作っている時間は楽しいです。
達成感もあります。ドーパミンが出ます。
しかし、ユーザーがコア機能まで到達できていなければ、新しい機能を増やしても結局使われないと思っています。
（ただしピボット的な意味でコア機能自体を変えることはありだと思います）
よく「アプリはシンプルなほうが良い」と言われますが、
コア機能までの動線がわかりやすく、アプリの価値を実感しやすいことも、その理由の一つだと思っています。
初期のプロダクトで大切なのは、機能の数ではありません。
大切なのは、一つの体験を、迷わず体験してもらえる状態を作ること
だと思います。
3. 定常的に数値を観測し分析をしました
リリース後は、主に次の数値を毎日見ていました。
DAU
オンボーディングの完了率
コア機能のCVR
継続率
これらの数値は、毎日定時にSlackへ通知して観測していました。
また数値の中でも特に最初はオンボーディングとコア機能のCVRを重点的に確認しました。
アプリをダウンロードしてくれても、コア機能を使ってもらえなければ、価値を届けたことにはなりません。
4. 定量で「どこ」を見つけ、定性で「なぜ」を考えた
実際に数値を見ることで、「どこで離脱しているか」は分かります。
しかし、数値だけでは、「なぜ離脱したのか」までは分かりません。
例えば、ある画面で離脱率が高かったとしても、その理由には複数の可能性があります。
説明がわかりにくい
メリットが伝わっていない
操作が面倒
ユーザーが不安を感じている
次に何をすればよいかわからない
なので「なぜ離脱したのか？」の原因を考える時は仮説ベースで考える必要があります。ただ「自分がユーザーのアプリ」だとこの仮説の精度がめちゃめちゃ高いんですよね。
定量データで「どこ」を見つけ、定性情報で「なぜ」を考える
この組み合わせが、コア機能のCVRを改善するうえで特に重要だったと思います。
5. プロダクト側のメリットをすべて捨てた
アプリを運営していると、ユーザーにさまざまなことを求めたくなります。
レビューを書いてほしい。
課金してほしい。
広告を見てほしい。
もちろん、プロダクトを運営していくうえでは、どれも重要です。
しかし、PMFを達成するまでは、これらをすべて捨てました。
PMF達成前は、広告もサブスクリプションも入れてません。
ユーザーに価値を届ける前に、プロダクト側の都合を押し付けると、数値検証のノイズになると思ったからです。
例えば、オンボーディングの途中で課金画面を表示した場合、ユーザーが離脱した理由が分かりにくくなります。
アプリ自体に魅力がなかったのか。
価格が高かったのか。
課金画面を出すタイミングが早かったのか。
無料で使えると思っていたのか。
複数の原因が混ざってしまいます。
広告も同じです。
コア機能を使う途中で広告が表示されると、機能自体に問題があるのか、広告が邪魔だったのかを判断しにくくなります。
プロダクト側が何を得られるかではなく、 この画面はユーザーにどんなメリットがあるのかを常に考えるようにしていました。 まず価値を届ける。
その後に、レビューや課金をお願いする。
収益化は重要ですが、使われていないアプリを収益化しても、大きな売上にはなりません。 まずは、 ユーザーが繰り返し使いたくなる体験を作ること を優先しました。
※もちろんモチベーション維持のために広告や課金機能を入れるのはいいと思います。僕はPMFに向けて数値が上がっていること自体がモチベーション維持につながってました。
6. 自分一人で答えを出そうとしなかった
今回のアプリは、会社の同期であるM君と一緒に運営しています。
毎週日曜日に定例MTGを行い、数値の振り返りや施策の検討、今後の方向性について話し合っています。
役割としては実装やデザインは僕が担当し、M君には僕が作ったものをフラットな立場から見てもらっています。
個人開発は、企画から実装まで一人で進められますが
一人ですべて作れることと、一人で正しい判断ができることは別です。
自分で作っていると、どうしても作り手の目線に偏ってしまいます。
「この機能は便利なはず」
「この説明なら伝わるはず」
「この画面は使いやすいはず」
そう思っていても、実際には価値が伝わらなかったり、思わぬ場所でユーザーを迷わせたりすることがあります。
そこで、施策を実装したり、画面を変更したりするたびに、M君に確認してもらいました。
M君は実装やデザインに直接関わっていないからこそ、作り手の都合に引っ張られず、僕が作ったものをフラットに見てくれます。
そして、少しでも気になることがあれば、そのまま流さず、とことん深掘りします。
「ユーザーは、そもそも何に困っているのか」
「なぜ、この機能を使いたいと思うのか」
「この改善で、本当にその悩みを解決できるのか」
「初めて使う人にも、アプリの価値が伝わるのか」
表面的な使いやすさだけではなく、ユーザーの課題や行動の理由まで掘り下げたうえで、本質的なフィードバックをくれます。
「作り手の都合ではなく、ユーザーにとって何が一番良いのかを考える。」
言葉にすると簡単そうですが、実際に作っていると、実装のしやすさや自分の思い入れに引っ張られてしまうので、簡単なことではありません。
M君は、そうした作り手側の事情に流されず、いつもユーザーの立場から意見をくれます。
常にユーザーの課題を深掘りできるM君は本当にすごいと思っています。心から尊敬しています。
実際に操作してもらうと、自分では当たり前だと思っていた操作で迷ったり、分かりやすいと思っていた説明が伝わらなかったりしました。
M君の反応を通して、自分では気づけなかった思い込みに気づき、何度も軌道修正できました。
自分一人で答えを出そうとせず、信頼できる仲間にフラットなユーザー視点で見てもらう。
これも、今回PMFの基準を達成できた大きな理由の一つだと思っています。
7. SNSで最低限の検証に必要なユーザーを集めた
良いプロダクトを作っても、誰にも使われなければ検証できません。
そこで、SNSを使って最低限のユーザーを集めました。
ここでの目的は、フォロワーを増やすことでも、投稿をバズらせることでもありません。
改善結果を数値で判断できるだけのユーザーを集めることです。
1日あたり5~10人くらい新規ユーザーが入ってくれればいいと思っています。 さらっと書いていますが、SNSで5~10人の流入を獲得することはかなり難しいです。読者の皆さんの中で共感してくださる方もいらっしゃると思います。
SNSマーケの話をすると、長くなりそうなのでやらなかったことだけ共有します。
それは
「アプリの機能を紹介すること」
です。
なぜか？
理由はシンプルで機能紹介は広告感が出るからです。
広告から購入まで至った経験ってありますか？を想像していただけると納得できると思います。
ただ広告感がない機能紹介ができれば最強コンテンツだと思いますmm
（このやり方があれば僕が知りたいですm）
少し脱線しましたmm
初期段階で必要なのは、何万人ものダウンロードではありません。
施策の前後で数値の変化を判断できるだけのユーザーがいれば、検証を進められます。
8. とにかく優先順位を間違えないこと
振り返ると、最も重要だったのは優先順位です。
何度も言いますが、個人開発をしていると、やりたいことが無限に出てきます。
新しい機能を作りたい。
デザインを改善したい。
SNSを伸ばしたい。
課金を入れたい。
広告を出したい。
別のアプリも作りたい。
やりたいことは、いくらでも出てきます。
しかし、すべてを同時に進めることはできません。
そこで今回は、次の3つの順番で改善を進めました。
オンボーディングで離脱していないか
コア機能を使ってもらえているか
継続して使ってもらえているか
まずは、アプリをダウンロードしたユーザーが、途中で離脱せずにコア機能までたどり着ける状態を作る。
次に、実際にコア機能を使い、アプリの価値を感じてもらえる状態を作る。
そのうえで、継続して使ってもらえる状態を目指しました。
この順番を意識したのは、『バケツの穴の法則』があるからです。
PMFしてないアプリにユーザーを集めることは、「穴の空いたバケツ」に水を注ぐことに似ています。
初回体験やコア機能に問題がある状態は、バケツに穴が空いている状態です。どれだけSNSや広告でユーザーを集めても、次々と離脱してしまいます。
穴をふさがないまま水を入れても、注いだ水が流れ出てしまうだけです。
同じように、コア機能の価値を感じてもらえていない段階で継続率を改善する施策を行なったり、継続して使われていない段階で収益化を最適化したりしても、大きな成果にはつながりません。
まずは初回体験を整え、コア機能の価値を届け、継続して使ってもらえる状態を作る。
広告による集客、課金による収益化は、そのあとでいいと思っています。
やりたいことから手をつけるのではなく、
今、プロダクトが次のフェーズへ進むために必要なことは何か。
それを考え、必要なことだけに集中しました。
やらなかったこと
1. ユーザーや友人の要望をすべて実装する
問い合わせフォームから要望をもらったり、友人にアプリを使ってもらい、機能のアイデアをもらったりすることがあります。
要望をもらえるのは、素直にうれしいです。
「実際に使ってくれているんだ」と実感できますし、すぐに実装したくなることもあります。
ただし、要望をすべて追加することはしませんでした。
機能が増えるほど、画面や操作が複雑になり、本来使ってほしいコア機能が分かりにくくなる可能性があるからです。
あるユーザーにとって便利な機能でも、ほかの多くのユーザーにとっては必要のない機能かもしれません。
2. ダウンロード数だけを追う
ダウンロード数が増えると、プロダクトが成長しているように見えます。
数字が伸びるとうれしいですし、自己肯定感も上がります。
しかし、ダウンロードされても、継続して使われなければ、ユーザーにアプリの価値は届いていません。
たとえ1,000人にダウンロードされても、ほとんどの人が次の日から使わなくなってしまえば、アプリの価値は届いていません。
それよりも、100人のうち多くの人がコア機能を使い、その後も継続してくれるほうが、プロダクトとしては良い状態だと思います。
3. 早すぎる収益化
個人開発をしていると、早く売上を作りたい気持ちが出てきます。
お金、欲しいですもん。
ただ、ユーザーがアプリの価値を十分に感じていない段階で課金を求めても、長期的な収益にはつながりにくいと考えました。
課金画面を追加すれば、一時的に売上が発生するかもしれません。
しかし、その影響でコア機能を使う前に離脱されてしまえば、継続率が下がり、プロダクトの成長を止めてしまう可能性もあります。
僕は、アプリ開発は超ロングゲームだと思っています。
だからこそおもしろい。
目先の売上を優先するのではなく、まずはユーザーが価値を感じ、長く使い続けられる体験を作る。
そのうえで、ユーザーが納得してお金を払える機能やタイミングを考える。
その積み重ねが、将来的に大きな売上につながると考えています。
4. 大バズを狙ったSNSマーケティング
SNSで大きくバズれば、一気にダウンロード数を増やせます。
そのため、大バズを狙うこと自体が悪いとは思っていません。
ただ、PMFを達成する前の段階では、大バズを狙う優先度は低いと考えました。
大バズするコンテンツを作るには、企画や投稿の改善に多くの時間がかかります。また、仮にバズってダウンロード数が増えても、アプリの体験が十分に整っていなければ、その多くが離脱してしまいます。
そこでPMF前は、一度の大バズを狙うのではなく、確実に一定数のダウンロードにつながるコンテンツを再現できる状態を目指しました。
投稿内容や切り口を少しずつ変えながら、
「どんな投稿ならダウンロードにつながるのか」
を検証しました。
大きなバズを一度起こすことよりも、アプリを必要としている人に届き、
一定数ダウンロードされるコンテンツを発信し続けることが大事だと思います。
最後に
DAU100人以上。
5週目継続率20%以上。
コア機能のCVR60%以上。
大きなサービスと比べると、小さな数字に感じるかもしれません。
（ただ現状の数値においてはDAU以外の継続率などは、本業で開発してるアプリを上回ってるんですよね。不思議な気持ちです。）
それでも、個人で作ったアプリが毎日100人以上に使われ、1ヶ月以上使い続けてくれる人がいて、過半数のユーザーがコア機能を利用してくれている。
これは、ただリリースしただけでは到達できない数字だと思っています。
個人開発は、ダウンロード数や売上など、分かりやすく目立つ数字を追いたくなります。
実際、僕も
「1万ダウンロードを達成しました」
「個人開発で月10万円を達成しました」
といったポストを見て、純粋にうらやましいと思います。
早く売上を作りたい。
もっと多くの人に使ってほしい。
そう思うことは何度もあります。
しかし、その前に見るべきなのは、
「プロダクトの価値が、本当にユーザーに届いているか」
です。
ユーザーがコア機能を使っているか。
翌週も使っているか。
1ヶ月後も残っているか。
この数字に向き合い続けたことが、今回の結果につながったと思います。
そして、PMFを達成した今、人生で一番ワクワクしています。
「海外対応したら、どんな国で使われるだろうか？」
「サブスクでどんな新しい価値を提供しよう？」
まだまだできることはいっぱいあります。
PMFを達成したことで、これまで見えていなかった、さまざまな可能性が見えるようになりました。
もちろん、ここがゴールではありません。
むしろ、ようやくスタート地点に立てた感覚です。
これから、このアプリがどこまで成長するのか。
自分自身が一番楽しみにしています。
