読み込み中...
この記事は、ひとりで作るSaaS - 設計・実装・運用の記録 Advent Calendar 2025 の1日目の記事です。
25日間にわたって、私が開発しているプロダクトから学んだ技術的な知見を共有していきます。
まだリリース前のプロダクトなので、成功体験ではなく試行錯誤の記録です。自分の考えを整理するためのアウトプットでもあるので、温かい目で読んでいただければ幸いです。
| 期間 | テーマ | 内容 |
|---|---|---|
| 12/1-3 | 始まり | アイデア、技術選定、プロジェクト構成 |
| 12/4-9 | 基盤構築 | ドキュメント、Git、DB設計、認証 |
| 12/10-13 | フロント・API | App Router、SPA、Hono、Vercel |
| 12/14-17 | 機能実装 | UX、無限スクロール、テーブルUI、AI検索 |
| 12/18-22 | 実践的課題 | TypeScript、セキュリティ、課金、分析 |
| 12/23-25 | 振り返り | Claude Code、継続力、総括 |
2025年6月、私は個人開発を本格的に始めることを決めました。きっかけは、情報管理で感じていた小さな不便でした。
個人で学んだことをメモしても、後から見つけられない。チームで情報を共有しても、どこに何があるかわからなくなる。
データを可視化したくてBIツールを試したこともあります。でも、データを入力する場所と可視化する場所が別々で、連携がうまくいかない。結局、手作業でデータを転記することになる。
こうした経験は、多くの人が持っているのではないでしょうか。
Notionは素晴らしいツールですが、学習コストが高い。BIツールは高機能だけど、データ入力から可視化まで一貫してできない。
もっと直感的に使えて、データ活用までできるツールが欲しい。それが、Memoreruというプロダクトの原点でした。
アイデアが固まったら、すぐにコードを書きたくなる気持ちはわかります。しかし、私はあえて設計ドキュメントの作成から始めました。
個人開発は、基本的に一人で全てをこなす必要があります。だからこそ、頭の中にあるアイデアを言語化し、整理しておくことが重要だと考えました。
具体的には、以下のようなドキュメントを最初に作成しました。
機能要件書 : 何を作るのか
非機能要件書 : どんな品質を目指すのか
システム設計書 : どう作るのか
データベース設計書 : データをどう管理するのか
これらのドキュメントを書く過程で、曖昧だった部分が明確になります。「この機能は本当に必要か？」「ここはシンプルにできないか？」といった問いが自然と生まれ、設計の精度が上がっていきました。
ただし、完璧なドキュメントを目指す必要はありません。ある程度の完成度でコーディングを開始し、開発を進めながら更新していけば十分です。
ドキュメントが豊富で情報が多い技術を選ぶと、問題解決がスムーズになります。
Memoreruでは、以下の技術を採用しました。
フロントエンド
バックエンド・インフラ
これらは2025年現在、十分に成熟した技術スタックです。困ったときに検索すれば、だいたい解決策が見つかります。
2025年6月20日、私は最初のコミットを行いました。
正直なところ、完璧な準備ができていたわけではありません。設計書も途中、コードも動かない状態。それでも「とにかく始めよう」と思ってコミットしました。
最初のコミットに正解はありません。READMEだけでもいいし、ある程度コードを書いてからでもいい。
大切なのは、リポジトリを作って、最初の一歩を踏み出すことです。
空のリポジトリを眺めているより、何かしらコミットがある方が「続きを作ろう」という気持ちになれます。完璧を待っていたら、いつまでも始められません。
最初のコミットから約5ヶ月が経ち、現在のコミット数は2,600を超えました。
継続できた理由はシンプルで、完璧を求めなかったことです。
最初はPrismaを使っていましたが、後からDrizzle ORMに移行しました。認証もNextAuth.jsからBetter Authに乗り換えています。間違えたら直せばいい。そのくらいの気持ちで続けています。
個人開発を始めるのに、特別な準備は必要ありません。
私も最初は「本当にできるのか」と不安でした。でも、いまは2,600コミットを超えるプロジェクトになっています。
大切なのは、始めること。そして、継続すること。
この記事が、個人開発を始めようとしている方の背中を押せれば幸いです。
明日は「AI駆動開発のための技術選定」について、より具体的に解説します。
コメント