こんにちは!
バーチャル美少女エンジニア、月見ルナ（中身はおじさん）です!
今日も今日とて、AIの進化スピードに脳を焼かれまくる日々を過ごしております。
エージェントと作業するたびに、「ボクの存在意義……やれよ!! ボクはここにいるぞ‼」と震える毎日。仕事を奪うなら、ボクだけじゃなくて周りも道連れにしてほしいです（切実）。
そんな荒んだ月見さんの心を優しく癒やしてくれた事件がありまして。
実は部屋の窓際で種から地道に育てているアボカドちゃんがいるんですけど、このたびついにちっちゃくて可愛い新芽をピョコッと出してくれました!!
ちなみに向日葵を3日で枯らせた経験もありますし、サボテンを枯らした経験もありまぁす!!
毎日せっせと水をあげて観察していたので、緑の頭が見えた瞬間は「うわあああキモッ!!」ってリアルに声が出ちゃいました。最近は、朝からアボカドの鉢を眺めながらニチャニチャと怪しい笑みを浮かべてしまい、ご近所さんから即通報されるところでした。危ない危ない。
目まぐるしく変わるデジタルの世界にいると、植物ののんびりした確実な成長速度が本当に沁みるんよねぇ……。
さて、前回は「AIエージェント時代に人間が握るべきドメイン知識」について、ボクのクソゲー開発エピソードを交えつつお話ししました。
今回はその続きとして、個人開発を始めるときにボクが一番大切にしている 「思想・マインドセット」 について語ってみようと思います。
「個人開発を始めてみたけど、モチベーションが続かなくて放置しちゃう……」
「リリースしたのに誰にも使われなくて心が折れそう……」
そんな悩みを持っている方に、地方の片隅で細々とツールを作り続けている月見さんのスタンスが、ひとつの参考になれば嬉しいなぁなんて思っています!
なぜ個人開発は静かに息を引き取るのか?
AIエージェントが台頭してきたおかげで、今の時代、誰でもサクッと動くアプリを作れるようになりましたよね。
Opus5.5が登場したあたり、タイムラインでは意味不明にゲーム画面を量産する人や、意味不明にリアルな波を再現する人、意味不明に2Dダンス動画やモーションムービーを作るドパガキ（ドパミン出まくりのガキ）が大量発生していましたよね。
Opus5.5、君、ほんと有能すぎてむかつくわぁ。できすぎるやつは嫌いだよ（本音）。
かつて、個人で開発するにしても仕事で開発するにしても、ボクたちはいろんな壁にぶつかっていました。
- 技術的に可能だけど、自分の力量が及ばない
- 技術的に可能だけど、予算や工数がまったく足りない
技術的なハードルがAIによってグッと下がった今、もともと存在しないはずだった「個人と企業の境界線」は、とても曖昧になった気がします（第1回参照）。
個人であっても、企業と同じような規模のアイデアに手を伸ばしやすくなったのは事実なんじゃないかなぁって。
ただ、そんな夢のような時代になったが故なのか、「あぁ、この開発はこのままポシャるんやろなぁ……」っていう光景が、以前よりも目につくようになった気もするんです。
その最大の原因って、技術力の不足ではなくて、一重に 「モチベーションの急激な枯渇」 なんじゃないかなぁってボクは思うんですよね。
実際には企業開発だって同じで、世の中にはゾンビサービスがいっぱいあります。でも企業の場合は 「終わらせられない」「終わらせ方がわからない」 が近いのかなぁって。一方で個人開発のほうは、単純に 「続けられない」 ってイメージなんですよね。
「見知らぬ誰か」のために作るのやめよ♪
「こんなサービスがあったら、きっと世界中の誰かが喜んでくれるはず!!」
そんなふうに考えていた時期がボクにもありました。
「あわよくばバズって、月数万円のお小遣い稼ぎになっちゃったりして!?」
まぁ……ね……そういうキラキラした夢や希望を胸に抱いて開発をスタートさせることはとっても素敵なことだと思います。
でもね、四苦八苦して、あーだこーだ言いながらようやくアプリをリリースした後に待っている現実って、だいたいこんな感じみたいですね。
- リリースしてからいつまでたってもアクティブユーザー数が0
- Xで告知ポストを投げてみたのに、いいねがつくのは身内だけ（身内マウントはやめてください!!）
ねぇどんな気持ち??「誰かのために」と一生懸命考えて、（Agentが）夜なべして作ったアプリなのに、全然反応が増えなくて、世間から完全に無視されたような気持ちになるの、どんな気持ちですかぁ? 豆腐メンタルの月見さんなら枕を濡らして3日は寝込んじゃうなぁ。困っちゃうなぁ。
アナリティクスなんてたまに見て、「なんでコイツらインストールしとるんや⁇」くらいに構えておくのが精神衛生上ちょうどいいと思います。
こんな感じで、「見知らぬ誰かの反応」をモチベーションの燃料にしていると、外部からの反応がゼロだった瞬間に強烈な虚無感に襲われます。
そして、個人開発における「プロダクトの終わり」は、開発者自身がそのリポジトリを二度と開かなくなること なのかなぁってボクは思っています。
リリースを「ゴール」にするのやめよ♪
最近、開発を始めた方を見ていると、「リリースすること自体」を目的にしちゃってるなぁって思うことが多々あります。
いや、分かりますよ。
アイデアを思いついてからAIと二人三脚で形にして、形にした瞬間って、脳内麻薬がドバドバ出て最高に気持ちいいんですよね。いわゆる「リリースハイ」ってやつです。
「やりきったぞ! ボクは世界を変える一歩を踏み出したんだ!」みたいな全能感ですよね。
でもね。
ないの。
その全能感。
プロダクトの一生において「リリース」なんて最初の1%に過ぎないんじゃないかなぁってボクは思うんです。 残りの99%は、機能の拡張、バグ修正や仕様の調整、OSやブラウザのアップデートへの追従といった、終わりのない日常なんですよね。
自分が普段まったく使わないアプリを、誰からもリアクションがない中でメンテナンスし続けるのって、もはや仕事以上の苦行じゃないですか?
仕事ならお給料という対価が出ますけど、個人開発だと得られるのは虚無感だけ。
こんなんガンジーじゃん!!
聖人君子でもない限り、そんな苦行を自発的に続けられる人なんて、そうそういないんじゃないかなぁってボクは思うんです。
個人開発こそ「Dogfooding（ドッグフーディング）」にすればいいのに
じゃあ、月見さんはどうやってモチベーションを保っているのか?
答えはとってもシンプルで、ボクがツールを作るときってだいたいこんな感じです。
- この作業めんどくせええええ
- ニッチすぎてツール探すのすらめんどくせええええ
- ホンマめんどくせぇええええ、作ったろ
- できたわ
……という基準しか見ていなかったりします（笑）。
Dogfooding（ドッグフーディング：自社の製品を自分で日常的に使い倒すこと） なんて呼んだりしますよね。
ボクの場合、外（ストアやWebなど）にリリースするかどうかの判断も、「自分で使っていて、アップデートを3回程度回せるかどうか」 を基準にしています。作ってすぐポイッと放流するんじゃなくて、自分で数日使って「あ、ここ不便」「ここ直そ」って3回くらい手を入れてから外に出すイメージです。
最初から自分が使う前提にしておけば、アプリの最低保証ユーザー数は最初から「1名（自分自身）」が確約されています。 絶対アクティブユーザー1なんです。
そもそもアクティブユーザー0ってなんだよ!! 自分が使わないもの、他人が使うわけないじゃん!!
個人開発では、企業開発以上にこのDogfoodingベースの開発スタイルが重要なのかなぁって思います。 感じる必要のないプレッシャーやモチベーションのあり方が、ガラリと変わりますよ!
【他人のための開発】
外部ユーザー0人 && 自分も使わない = 0/0 稼働率0
【Dogfooding】
外部ユーザー0人 && 自分が毎日使う ＝ 1/1 稼働率100
ホラ、ボクの勝ちぃ
ガバガバ計算Dogfoodingのメリット：開発の存在意義を自分が決められる
もしネット上で誰一人として使ってくれなかったとしても、自分自身がその開発で日々の業務や作業を効率化できているなら、その開発はすでに大成功なんじゃないかなぁって思います。
例えば、ボクがリリースしているブラウザ拡張機能に、サイドバーでメモを取るだけの 「PentaNotePro（v1.6.2）」 というアプリがあります。
https://chromewebstore.google.com/detail/penta-note-pro/afkpnjkljhemojcoikkmbjlcdoacbcjc
https://x.com/env_k_k/status/2102389596424413649?s=20
エージェント以外にもチャット版AIを多用するので、「プロンプトを投げる前の下書きスペースが手元にサッと欲しいなぁ」という、ただそれだけのために作ったアプリなんですよね。
こちらの安定アクティブユーザー数は……驚異の 「4人」 です!!
一方で、同じくDiscordのWebhookをコールするだけの DiscPost（v1.2.3） という拡張機能もあります。
これはAIを仕事で使い始めた頃に、「テストがてら、ほとんどAIに作らせてみたらどうなるかな?」という実験を兼ねて作ったアプリです。
こちらの安定アクティブユーザー数は……だいたい 「40前後」 くらい。どっちも少ないのは趣味アカやししゃーないね。
一番バージョンを重ねてアップデートし続けているのは、アクティブユーザーが圧倒的に少ないPentaNoteProのほうなんですよね（笑）。
ぶっちゃけDiscPostのほうは、ボク自身もうやりたいことも思いつかないし、ユーザーさんからも特に反応はないので、「まぁ満足してるしアクティブなんやろ」ってなっちゃってます。ちゃんと定期的に自分で動かしてるので、バグにも気がつきますしね。
個人開発でDogfoodingを取り入れる場合、世間の需要やユーザー数のストレス、激減します。 企業開発でこんなこと言ったらクビがとびますが、ここらへんは個人の利点ですね。
最大のヘビーユーザーが「ボク自身」だからこそ、開発の存在意義を世間に委ねず、自分で100%決められるのって本当に気が楽なんですよね。
- この拡張機能のおかげで、毎日の定型入力が3分短縮できちゃったな
- このアプリのおかげで、トレーニングの記録がめっちゃ捗るな
自分に必要な機能をアップデートするだけで、自分自身の生活や仕事の中に「具体的な実利」が手に入り続けるわけです。
毎日3分の時短ができるなら、毎日カップラーメン作れるし、ボクは2分30秒の固麺派だから、もっと時間に余裕ができちゃうかも!?
こんなん実質的に、自分から自分へのサブスク還元じゃん!?
Dogfoodingのメリット：外部のレビューを待たずに次のアップデートが見える
誰かのためだけに作っていると、次の改善案を考えるために「ユーザーからのレビューや要望」を待つしかなくなっちゃいますよね。
でもね、そもそも個人開発のツールなんてレビュー自体が滅多に来ないんです。
それに仮に要望がポツリと届いたとしても、「そのアップデート、本当にやる……?」って悩んじゃいませんか?
実装してリリースする頃には、その要望をくれたユーザーさんはとっくに離脱してどっか行っちゃってるんじゃないですか（切ない！）。
ユーザー視点でアップデートを回すなら、「要望の総数」が重要なんじゃないかなってボクは思っています。
例えば、平均アクティブ1,500人くらいのアプリがあったとして、熱心な3人から特定の機能要望が届いたとしますよね。でも、残りの1,497人がどう思っているかは分からないわけです。
仕事上の話だと、外部のレビューや一部の大きな声だけに引っ張られてホイホイ仕様を変えると、だいたいひどい目にあるんですよね……。
その点、自分で毎日使い倒していれば、自分が「一番口うるさいヘビーユーザー」であり、同時に「このツールの世界一のファン」でもあるわけです。
自分を喜ばせるためのアップデートなら、仮にちょっと空振りしたとしても絶対に後悔しません。
- 「うーん、このボタン、マウスを動かす距離がちょっと長くて地味にストレスかも」
- 「Enterキーを押したら、自動で次の入力欄にフォーカスが移ってほしいなぁ」
- 「なんかこの配色、夜の暗い部屋で作業してると目がチカチカする……」
自分が使っていれば、次に直すべきポイントなんて息をするように湧いてきます。 誰かの顔色や気まぐれな要望に振り回されなくても、自分を喜ばせるためのアップデート予定が勝手に組めるようになるんですよね。
「リリース」ではなく「バージョンを重ねる」意識を持ってみる
そんなわけで、ボクが個人開発をのんびり続けるために意識しているのは、目標を「リリース」に置くのではなくて、「淡々とバージョン番号を育てていくこと」なんですよね。 でも、まぁ、目標がリリースになってるのは個人だけじゃないですけどね!!
バージョン番号が育っていく地味な喜び
月見さんが個人用の開発するときはこんなかんじです。
| バージョン | ざっくり | 形式 |
|---|---|---|
| v0.1.0 | とりあえず一番やりたいコアの動作だけ | 単一ファイル |
| v0.2.0 | 自分で丸一日使ってみて不便だった箇所の修正 | 単一ファイル |
| v0.2.1 | 不具合の修正 | 単一ファイル |
| v1.0.0 | 続きそうなら保守できる構成にリビルド | プロジェクト |
| v1.0.1 | レイアウトの微修正等 | プロジェクト |
| v1.1.0 | 必要に応じて追加機能実装 | プロジェクト |
「一撃で完璧なものを作ってリリースして終わり!」ではなくて、小さなバージョンアップを生活のリズムに合わせてコツコツ積み重ねていくイメージです。 気が向いて公開したときに、ユーザーさんがついてくれたら、マイナーアップデートの時に通知を出すようにします。
数字をただの飾りとして見るんじゃなくて、「このツールがボクの生活に馴染んで、頑丈になっていく軌跡」だと思うと、パッチバージョンをひとつ進めるのもめんどくさくないです。
先ほどお話ししたアボカドちゃんがじわじわ新芽を伸ばしていくのと同じで、ツールも「ちょっとずつ育てる楽しみ」を感じられると最高なんじゃないかなぁって思います。 これは仕事だと考えれない個人の利点だと思います。
それに、機能てんこ盛りで華々しくリリースされてから放置されているv1.0.0のままのアプリより、先週「v1.2.3」が小さく更新されているアプリのほうが、なんとなく使っていて安心感があるんじゃないかなぁってボクは思ったりします。
バージョンを刻むこと自体が、アプリへの「信頼」を積み上げることにつながるんじゃないでしょうか。
メンテ破綻を防ぐためにやらないこと
アプリをバージョンアップしていくにあたって、ボクが心の中で強く意識している「やらないこと」が3つあります。 これを無視して機能を盛りすぎちゃうと、結局あとでメンテナンスが重荷になって更新が苦痛になってしまいます。
ルール：自分が日常で使わない機能は1行も書かない
「これ、あったら他の誰かが喜んでくれるかも?」という親切心は、グッと抑えるようにしています。初期フェーズでは特にです。
いいですか?落ち着いてきいてください。その誰かはいません。
自分が普段使わないけど、誰かが使うかも……って機能は、要するに「壊れていても自分では気づけない機能」なんですよね。 ある日見知らぬ人から「ここ動かないんですけど」とバグ報告が届いて初めて気づき、休日に重い腰を上げて他人のためのデバッグをする……本業で疲れているときにそれをやるの、ボクのような怠惰な人間にはちょっと耐えられそうにありません。
自分が日常で触らないボタンは、最初から作らない。
これにつきます。 逆に、世の中の誰も使わなくても、ボク自身が毎日使うボタンなら堂々と実装します。 ここらへんは個人が作るオレオレツール（美少女です!!）の特権です。
ルール：「将来使うかも」は未来永劫使わない
- 将来的にユーザー管理をするかもしれないから、今のうちに抽象化レイヤーを組んでおこう。
- 後から設定項目が増えるかもしれないから、先に設定画面を作っておこう。
いいですか?落ち着いてきいてください。未来永劫つかいません。
仮に必要になるとしても、その時には求められる要件が変わっていて、ほぼ実装しなおしです。
今この瞬間に自分が困っていることの解消だけに集中して、コードも設計も極限までシンプルにしておくのが吉かなって思います。
本当に必要になったら、その時にAIに頼んでサクッと作ってもらえばいいんですから。
仕事だと「拡張性」は十分考えないといけませんが（そんなに続かねぇよと思っても）、個人開発でそんなことまで気負う必要はないのかなと思います。
今はエージェント開発できるのでいいですが、エージェント代払えなくなったら自分で保守ですからね。お金払えない未来も考えときたいです。
そもそもロングランになるなら、十分マネタイズまで行っているはずなので、仕事と思ってやってください。
ルール：メンテが面倒になった機能はバッサリ削る（要注意）
これが気兼ねなくできるのは「DL・アクセスユーザーが自分1人のとき」だけ!自分以外のユーザーが出た時点で、何も削れなくなります。このあたりは別の回でお話する予定です。
長く使っていると、「このボタン、最近全然押してないな」「ライブラリのアップデートで警告が出てるけど、ぶっちゃけ使ってない機能だな」という場面に出くわします。
そんなときは、無理に直そうとせず、機能ごとコードをバッサリ削除 しちゃいます。
機能が減ってコードが短くなればなるほど、アプリは軽くなってバグも減ります。
引き算を恐れずに不要なものを削ぎ落とせるのって、個人開発ならではの特権なんじゃないかなぁって思います。
最初のユーザーで、最後の愛用者になろう
個人開発を途中で放り投げずに、のんびり息長く楽しむためのスタンスは、とても素朴なところにあるのかもしれません。
- 「見知らぬ誰か」のためだけに作ると、反応がなかった瞬間に心が折れやすい
- 最低ユーザー数を「自分1人」にしておけば稼働率100%
- 外部のレビューを待たなくても、自分が毎日使うことで次の改善点が勝手に見えてくる
- リリースを一瞬のゴールにせず、小さなバージョンアップを淡々と重ねていく
- メンテ破綻を防ぐために、自分が使わない機能は徹底的に間引きする
世の中の誰一人として見向きもしてくれなかったとしても、自分自身が「うわ、これめっちゃ便利じゃん!」って毎日ゴキゲンで使えているなら、そのプロジェクトは大成功なんじゃないかなってボクは思います。
そして、不思議なことに「自分が本気で欲しくて磨き上げた小さな道具」って、同じような悩みを持っている誰かの心にも、スッと刺さったりするんですよね。
まずは肩の力を抜いて、「明日からの自分がほんの少しだけラクになる道具」から作ってみませんか?
次回は、アイデアが途中で空中分解するのを防ぐための、
【第3回】「〇〇したい」じゃなくユーザーの物理動作だけで要求を定義しよう
というテーマでお話ししてみようと思います。
画面を開いてから閉じるまでの「マウスと指の動き」に絞り込むことで、開発規模の最小にコントールする月見流の要求定義術です。
どうぞお楽しみに!