建設現場で施工者側が作成する技術計算書を簡単に作れるWebアプリ『Calku』を個人開発でベータ版としてリリースしました。
自分のプロダクト・サービスをリリースして、「より多くの課題を少しでも解決したい」という思いで、個人開発はいくつか挑戦してきました。 しかし、開発中にもさまざまな壁に悩ませれ、これまでりりーすまでたどり着けたことがありませんでした。
今回、ようやくリリースを達成することができたのは、過去の挫折を振り返りながら、開発環境や技術選定を見直しただけでなくなく、自分なりの習慣を整えたかだと思います。
この記事では、私が個人開発をリリースまでやり遂げるために実勢した8つのことを共有します。
個人開発リリースまでに実践した８つのこと
個人既発ではじめてアプリをリリースできたのは、各種SaaSサービスの利用といった技術力そのものももちろんありますが、それだけではなく、続けるための習慣作りと、環境の整え方に意識を向けたことが大きかったです。
これまで何度も挫折してきた経験を踏まえ、今回こそリリースまで達成できたのは、次の8つの実践があったからだと思います。
- ひとまず開発を続ける
- 本業との開発環境の違いを知る
- すでに構築されているサービスを使う
- ビジョンボードの作成する
- 開発時間と場所を決める
- 進捗を発信する
- 開発中に悩んだら書き出す
- コア機能を決めて一度リリースする
振り返ってみると、シンプルな「技術選定」とリリースまでの「習慣化」が最大の要因だったと思えます。 次の章からは、それぞれの項目でどんな課題があり、乗り越えてきたか紹介していきます。
１．ひとまず開発を続ける
これまで作りかけたアプリは、サバゲーの記録アプリや、バドミントンの試合記録アプリ、積みゲーを管理するツールなど多岐にわたります。 どれも様々な要因で途中で止まってしまい、リリースまで至らなかったプロジェクトです。
一つのプロジェクトで開発が止まってしまっても、時間をおいて「こういうものがあったら便利そうだ」と思いつくたびに、開発メモとして残して、休日や隙間時間を使って少しずつ開発を続けました。 最初は、リリースまで至らなくても、本業での開発では触れない言語やサービスを試す、新技術の勉強になればいいかと思い、続けていました。気づくと、 ”コードを書くこと” が生活の一部になっていました。
最初は、副業もしたいけど、コードも書くかと時間の確保を無理やり頑張っていましたが、次第に「休日はとりあえず開発しよう」と思える習慣に替わっていました。
私がいつから個人開発やるぞと思い、実際に動き出したかを遡ってみると、X（旧Twitter）でのこのポストあたり原点だなと思います。
それ以降、途中長期で立ち止まることもありましたが、続けるモチベを保ち続けることができました。
個人開発は、成果よりもまず「やめないこと」が大切だと痛感しました。
1日10分でもいい、1行でもいい。なんなら一度止まってしまってもいい。
とにかく何かきっかけがあるたびに開発時間を積み上げること。いざ時間ができたり、私は何がやりたいのかと振り返ったときに「開発がデフォルト」な自分を見つけ出しました。
💬ポイント：立ち止まってもいい。何度でもやり直せ。
「続けること」は立派。「やり直すこと」も立派。リリースは自然とその先に見えてくる。
２．本業との開発環境の違いを知る
私は本業でもWEBアプリの開発がメインです。
内製向けのアプリが多く、「もっと社外でも役立つサービスを自分で作れないか」と思い、個人開発を始めました。
ただ、本業ではインフラはAWS中心で、体制もチーム開発。コストを厳密に意識する必要はなく、困ったときには相談できる人がいました。「まずはAWSで構築しよう」という発想が自然な世界です。
一方で、個人開発はすべて一人。
使える予算も時間も限られています。 「本業と同じやり方では通用しない」ということは理解していたつもりでしたが、想像以上に苦労しました。
個人開発では、コストネックになるのが、データベース（SQL）だろうと思って、ここはいくつか候補を調べました。 PlanetScale（現在は無料プラン廃止）、Supabase、Neonなど、無料で始められるクラウドサービスをいくつも試しました。
結果として、DB構築自体はスムーズに進められたものの、認証やデプロイで思わぬトラブルが続出しました。
認証では、本業で使っていたAWS CognitoやAuth.js（NextAuth）を導入しましたが、デプロイ先との環境変数の扱いなど、見落としやすい箇所でつまずきました。
こうした経験を通じて、「同じ知識でも、環境が違えば通用しない」という現実を実感しました。
とはいえ、これまでの経験に完全準拠するとコストがかかりすぎるため、すべて既知のサービスを使うことはできません。
そのぶん、どこで躓くのか、どのSaaSが相性がいいのかを学ぶ良いきっかけになりました。
小さな失敗を積み重ねながら、「どうやって動かすか」を考える力が養われたと思います。個人開発において、マイクロSaaSは欠かせない存在です。
ただ、それらをどう組み合わせて、「自分で環境を整え、維持する」かが腕の見せどころでもあります。
💬 ポイント： SaaSの組み合わせは、それぞれの親和性も視野に入れる。
「動くこと」を最優先に。 “オレの最強環境” は作れないけれど、**“自分に最適な環境”**は作れる。
３．すでに構築されているサービスを使う
前章とも少し重なるのですが、現在の個人開発はAIによるコーディング、多くのSaaSサービスがく登場したことで一気にハードルが下がりました。
ただ、そんな中でも技術選定では思わぬ落とし穴がいくつもありました。
一つ一つのサービスは公式ドキュメントや参考ブログを読み解き構築することはできますが、これらを組み合わせると情報が少なくなり、ドンピシャな解決策にたどり着けなくなります。
特に認証、デプロイ、決済などが絡むとlocalhostの開発環境では動くのに、いざリリースしようと思うと動かなくということもありました。
ここにもいくつか解決策があって、例えばT3スタック、JStackといったベースプロジェクトが公開されています。 私もこれらのサービスを使い始めたときは、その素晴らしさを感じました。
一方で「DBの管理にはPrismaを使いたい」、「再起はAPI管理はもっぱらHonoを利用している」といった自分なりの開発環境に合わせたくなります。
ベースプロジェクトを自分なりにカスタマイズしていこうと思うと、かなり苦労します。そしてその苦労が開発時点ではなく、リリース時点で分かったときの絶望感は計り知れませんでした。
StartPackとの出会いと開発の加速
そんな時、個人開発者として有名な入江さんが公開していた『StartPack』というボイラーテンプレートを知りました。
Next.jsをベースに、Stripe（決済）やResend（メール送信）などが最初から組み込まれており、個人開発としてマネタイズを意識したサービスが組み込まれており、最小限の構成でサービスをすぐに動かすことができました。
ここに、API管理としてだけHonoが簡単に組み込めそうだったので多少カスタマイズして自分自身の開発環境を整えていきました。 また、デプロイしてみたら動かないという経験もあったので、インフラもVercelを利用してまずは公開できることを確認しました。
あれもこれも自分仕様にカスタマイズするのではなく、「これをベースにすれば動く」ということを確認して開発することに集中できました。
最初は、これまでの経験もあったし、コストも最小限にしたいということから理解できる範囲でサービスを自ら組み合わせると考えていました。
でも、リリースすることをゴールとして考えると、”動くことを優先する”選択も立派な開発力だなと感じるようになりました。
もちろん、個人開発のついでに新たに使ったサービス、試してみたこともたくさんあります。ただ、枯れた技術や既存の構築済みサービスを使うことも立派な戦略なんだなと強く感じました。
💬ポイント：個人開発では、“作らない勇気”も実力の一部。
使えるものを使いこなして、リリースを最短距離で目指す。
４．ビジョンボードを作成する
個人開発を続ける上で、技術よりも大切だと感じたのが“モチベーションの維持”です。
毎日のように進捗があるわけではなく、仕事や生活が忙しい時期はどうしても開発から離れてしまう。そんなときに支えになったのが、ビジョンボードでした。
ビジョンボードとは、達成したい未来を“見える形”にするためのボードです。
やりたいことや理想の姿を写真や言葉で貼り出し、毎日目に入る場所に置くだけ。シンプルですが、「視覚化する」という行為が大きな効果を生みだしてくれました。
こうした可視化の習慣は『引き寄せの法則』や『モーニングメソッド』といった書籍の影響もあります。モーニングメソッドにあるような毎日朝の習慣とまでは定着できませんでしたが、やる気があったときにビジョンボードまで作成して掲示できたことで”開発を日常にするスイッチ”になりました。
ポチップ
私の場合は、年初に年末にこうありたい姿という形で全体のテーマでビジョンボードを作成しました。その一つに個人開発したプロダクトがWEBサービスとして動いていることを取り入れました。
プロダクト想定UIまでのものをPCのフレームに埋め込み、ブラウザで閲覧可能な形になっている状態としてます。この時はまだ誰かに使ってもらうとというありたい姿まではイメージできていなかったです。 サービスがリリースできていることがあるべき姿としてビジョンボードを作成しました。
ビジョンボードは毎日チラッとでも目に入るようにトイレ、TVの上に掲げました。毎日じっと眺めていたわけではありませんが、生活なのかで何度も目に入りました。
「あ、今日も少しだけ進めよう」と自然に気持ちが動く瞬間がありました。
面白いのは、ビジョンボードに貼っていたアプリは実はリリースしていません。
けれども、“個人開発でサービスを世に出す”という軸はそのままに、結果的に別のプロジェクト（Calku）で形になりました。
目的は変わらなくても、手段は変わってもいい。
ビジョンボードが、迷ったときの“原点”を思い出させてくれたのだと思います。
💬 ポイント： ビジョンボードは“宣言”ではなく“リマインダー”。
意志ではなく、**「見える仕組み」**が続ける力を支えてくれます。
５．開発時間と場所を決め、開発環境も揃える
個人開発さらには本業と別の学習時間・事業時間を確保し、続けるためにはモチベーションよりも仕組み作りが大事だと感じます。
その仕組みづくりの基本が、時間・場所・環境を固定することでした。
①時間を決める
私はフレックス制を活用することができたので、個人開発の時間は平日午前10～12時の時間としました。
夜は疲れていて集中できないです。定時になるとどうしてもそこからスイッチを入れることは難しいです。
本業の調整は必要ですが、本業の時間でサンドイッチすることで、スタートはスムーズに切り替えることができ、終わりも決まっているので集中して取り組むことができました。
本業の始業時間を早め、終業時間を遅らせる。そしてその間に個人開発の時間を設けることが私のベストの時間配分でした。
②時間を決める
休日は、朝のカフェをスタート地点にしています。
朝から活動することで個人開発の時間後もまだまだ休日はたくさんあります。どうしても家だとだらけてしまいますが、やはりカフェは最強です。 また、カフェで午前中に作業所していると、その後、夕方自宅でも個人開発時間の確保しやすいなと感じることが多くありました。
心理学でいうところのツァイガルニク効果でしょうか。続きが気になる、さっきのコードもう少しこうしたらいいんじゃないかと思うことと自然と自宅でも作業に取り掛かることができました。
休日は、朝カフェとすることで、迷いが消え、生活にもリズムがでて、午後も開発はできたという満足感が得られる。少しコストはかかりますが、開発スイッチを入れる環境として利用していたカフェが、良い休日にまで進化したことに十分な価値を感じました。
③環境を整える
カフェで作業すると、「自宅の方が快適に開発を行えるのではないか」という悩みが付きまといます。
そういった余計な感情に惑わされないようにカフェ用の開発環境は徹底して整えました。
まずは、カフェは朝から行くことでいつものポジションを確保する。
モニターはモバイルモニターを利用してさらに上下のデュアル構成として、カフェでの場所問題との折衷案を実現しました。
スタンドはいろいろなものを試してきましたが、現在はクラファンでも話題になっていたWING BINDERの類似品（パク…）を使っています。いつかは再販売を待って正規のWING BINDERを購入したいと思ます。
ただ、類似品だからといって二の足を踏んでいましたがひとまず購入して環境を整えることを優先したことはよかったです。
💬 ポイント： 習慣は意志ではなく仕組みで作る。
時間と場所を固定し、環境を整えれば、開発は「頑張ること」ではなく「当たり前のこと」になる。
６．進捗を報告する
開発を続けるうえで、「ヒトに見せる」、「ヒトに宣言する」仕組みを作ることは大きな力になりました。
誰かにやっていることを伝えたことで、たとえ反応がないとしても見てくれる人はいる。何も達成できずに辞めるということはできなくなります。
発信の場所は悩みました。 当初はそういった使われ方としてもタグ共有などができそうなX（旧Twitter）を利用しようと考えていましたが、タイムラインがどうしても開発の集中を奪ってしまいます。
そこで、もう少し落ち着いている半クローズドな環境を活用することにしました。
リベシティでのつぶやき
ひとつは、お金のコミュニティリベシティのつぶやき機能です。
リベシティはお金のコミュニティなので、個人開発をしている人やそれらのつぶやきをしている人は多くはありません。ただ、副業や自己投資、金融リテラシーなど前向きな人が多く、リアクションを多くもらえることが励みになりました。
引用：リベシティ
オフ会などで実際に会ったことある人もいるため、オンラインコミュニティですが、ネットより近い人たちに宣言していることでモチベの維持にもつながりました。
Work≠Build（Discord）でのつぶやき
もう一つのは、個人開発者が集まるDiscordサーバー「Work≠Build」での進捗報告です。
ここでは、自分用のチャンネルを作り、作業する前と後で進捗を投稿していきました。個人チャンネルなので個人開発有名人でもなければわざわざアクセスしてリアクションしてくれるということあまりないです。
ただ、サーバー内のもれなく全員が個人開発者である環境は非常に励みになりました。
進捗報告の目的は、「成果を見せること」ではありません。続けるためのリズム、開発開始のルーティンを作ることだと思います。
報告があることで、報告してタイマーセットしてスタート。何をやるかが明確になり悩みが一つ減る。
こういった小さな積み重ね、誰かに見てもらえていることが、孤独な努力ではなくなると思います。
💬 ポイント： 報告は、評価をもらうためではなく、 自分との約束を守るための仕組みとして使う。
小さなことから一歩一歩。
７．開発に悩んだら書き出す
個人開発をしていると、必ず壁にぶつかります。
「この機能って本当に必要？」
「別のアイデアをやった方がいいのでは？」
「コードが汚くなってきた気がする…」
そんなモヤモヤが出てくるのは、真剣に取り組んでいる証拠何だなと思うように有りました。
書き出すことで思考が動き出す。
頭の中だけで悩んでいると、考えがぐるぐると回って動けなくなってしまいます。
私は、そんなときこそ書き出すようにしています。
Notionに「悩みメモ」ページを作り、浮かんだことをすぐ言葉にする。
書きながら整理していくと、「これは今じゃないな」「この案は後で試そう」と自然に優先順位が見えてきます。
AIとの“壁打ち”も活用する。
最近では、ChatGPTなどのAIに相談することも増えました。
「この設計でスケーラビリティは問題ないか？」
「この機能、ユーザー目線ではどう感じるだろう？」
そんな問いを投げかけてみると、意外な視点や整理の糸口が見つかります。
AIは答えをくれる存在というより、自分の思考を言語化させてくれる相棒のような存在です。
悩みは敵ではなく、材料。
書き出しておくことで、悩みは「思考のゴミ」ではなく「次の行動の材料」になります。
あとから見返すと、当時の迷いや課題が次の改善点や新機能のヒントになっていることも多いです。
開発を止めないために、悩みもアウトプットしていく。
それが、思考を止めないコツだと感じています。
💬 ポイント：悩みは抱えず、書き出して外に出す。
言葉にすることで、思考は再び動き出す。
８．コア機能を決めてリリースする
個人開発をしていると、「もう少しここを直したい」「これも入れたい」と、完成を求めすぎてしまう瞬間があります。
でも、リリース前に完璧を目指すと、永遠に出せなくなります。
リリースをするためにやってことで一番重要なことは「リリースすること」です。やや頓智のようですが、リリースることでしか解決できないものがいくつもありました。
まず、“コア機能”を決める。
開発を進める中で、自分のアプリにとって「一番価値を出す部分はどこか」を明確にすることが大事だと気づきました。
それ以外の機能は一旦すべて後回し。
例えば、今回のアプリでは「ユーザーが目的を達成するために一番使うであろう操作」を中心に設計を組み直しました。
リリース後に拡張できる設計さえ意識しておけば、出すことを恐れる必要はないと感じました。
リリースのハードルを下げる。
最初のリリースでは、正直、完成度はまだ低いです。見た目も荒削りで、細かいUX改善も山ほど残っていました。
でも、「とりあえず動く」状態で出したことで、ようやくスタートラインに立てた感覚がありました。
人に見せて初めて気づける改善点や反応も多く、“リリースしてから磨く”ことの重要性を実感しました。
出して初めて見える景色がある。
公開後、友人に紹介したり、少しずつユーザーが付いてくることで直接感想や意見をもらえなくても、利用ログを見たりする中で、「自分が思っていた使い方とは違う」「想定外の使われ方をしている」と気づくことがありました。
リリースは“完成”ではなく“対話のはじまり”。
個人開発でも、ユーザーの反応を通じて初めて“サービス”になっていくのだと感じました。
開発後日談
リリースしたサービス 『Calku（カルク）』 は、建設現場で使える技術計算書作成ツールとして、少しずつ利用が広がってきました。
ただ、実際にサインアップしても一度使って終わってしまうケースも多く、継続利用につなげる難しさを実感しています。
これはリリースして初めて見えた課題です。
今後は、最初に目標としていた「必要機能を一通り実装する」ことを進めながら、ベータ版から正式版（サブスクリプション対応）への移行を目指しています。
同時に、これまでマーケティングができていなかったと課題もあります。私が運用している施工管理向けのブログサービスとも相性はよいので、まずは自分のコンテンツを中心に紹介していく予定です。
リリースは“終わり”ではなく、“次の開発サイクルの始まり”。
使ってもらう中で気づく課題や声こそ、今後の開発のヒントだと感じています。
おわりに
今回、目標としていた「個人開発からのリリース」を形にできたことは、長い挑戦の中で一つの大きな区切りになりました。
とはいえ、リリース後も悩みは尽きません。
「このサービス、本当に使われるのだろうか？」
「マネタイズの道筋は正しいのか？」
そんな問いが、今も頭の中にあります。
趣味だけでは続かない。でも収益だけでも続けたくない。その“間”で揺れながら、今も開発を続けています。
本記事を書いたのは、そんな悩みを言語化しながら前に進むためでもあります。
これからも迷いながら、試しながら、サービスを育てていきます。
『Calku』が、同じように個人で挑戦する誰かの背中を少しでも押せる存在になれば嬉しいです。
コメント