なぜRDBではなくNoSQLなのか？｜個人開発におけるFirestoreのデータ設計・ハマりポイント

個人開発で新規サービスを立ち上げる際、最初にぶつかる壁が「データベース選定」です。

業務システム開発の経験が長いエンジニアほど、慣れ親しんだMySQLやPostgreSQLといったリレーショナルデータベース（RDB）を選びがちです。「データ整合性が大事だから」「SQLなら何でもできるから」という理由はもっともです。

しかし、私はあえて「個人開発の初期フェーズこそ、RDBを捨ててFirestore（NoSQL）を選ぶべき」だと断言します。

今回は、なぜNoSQLが個人開発のスピード感を加速させるのか、そしてRDB脳のまま挑むと必ず踏み抜く「Firestoreの落とし穴」について解説します。

なぜ個人開発でNoSQL（Firestore）なのか

最大の理由は、「スキーマ変更のコストがほぼゼロだから」です。

個人開発は試行錯誤の連続です。「やっぱりこの機能も欲しい」「ユーザー属性に項目を追加したい」といった仕様変更が毎日発生します。

この圧倒的な手軽さが、開発リソースの少ない個人開発者にとっては最強の武器になります。さらに、インフラ管理不要（サーバーレス）で、勝手にスケーリングしてくれる点も、運用コストを下げたい私達には最適です。

ただし、Firestoreを「便利なRDB」だと思って使うと痛い目を見ます。設計思想が根本的に異なるからです。

RDBの常識では「データの重複を避ける（正規化）」のが正義ですが、Firestoreでは「読み取り回数を減らすために、あえてデータを重複させる（非正規化）」のが正義です。

例えば、「投稿（Posts）」一覧に「ユーザー名（User Name）」を表示する場合：

RDB： postsテーブルにはuser_idだけ保存し、表示時にJOINする。
Firestore： postsドキュメントの中に、userIdだけでなくuserNameやuserIconも直接保存してしまう。

「ユーザー名が変わったらどうするの？」と思うかもしれませんが、その時はCloud Functions等のバッチ処理で一括更新すれば良いのです。読み取り頻度の方が圧倒的に多いWebアプリにおいて、この設計は理にかなっています。

実際に私が開発中に直面し、時間を溶かしたポイントを共有します。

FirestoreはSQLのように柔軟なWHERE句が書けません。「タイトルに『個人開発』を含む記事を検索」といった LIKE %...% 検索は、標準機能では不可能です。

解決策： Algoliaなどの全文検索エンジンを併用するか、タグ検索のような「完全一致」で済む仕様に落とし込む必要があります。企画段階でこの制約を知っておくことが重要です。

「カテゴリがAで、かつ作成日順にソートしたい」といった複合的なクエリを投げると、Firestoreは即座にエラーを吐きます。

Error: The query requires an index. You can create it here: https://console.firebase.google.com/...

解決策： 幸い、エラーメッセージに出るURLをクリックすれば自動でインデックスを作成してくれます。しかし、インデックスが増えすぎると書き込みコストが上がるため、クエリの乱発には注意が必要です。

データ構造を整理しようとして、Users > Posts > Comments のように階層を深くしすぎると、後で「全ユーザーの最新コメント一覧を出したい」といった横断的な取得が面倒になります。

解決策： ネストは1階層まで（SubCollectionまで）に留めるか、検索要件が多いデータは最初からルート直下のコレクション（Top Level Collection）として配置するのが無難です。

Firestoreは「何でもできる魔法の箱」ではありません。「複雑な集計は苦手」「検索はシンプルに」という制約があります。

しかし、個人開発においては「この制約があるから、複雑な機能を実装しなくて済む（MVP開発に集中できる）」とポジティブに捉えることもできます。

「リレーション（結合）」の呪縛から解き放たれ、オブジェクトをそのまま保存する快適さを一度味わうと、もう個人のハッカソンやMVP開発でRDBには戻れなくなるはずです。