週末でMVPを作るための技術選定 - バックエンドは本当に必要か？

前回記事の振り返り

以前、「アイデアを素早く形にすることの重要性」という記事を書きました。

そこで伝えたかったのは、アイデアの質 < 実行速度 ということ。完璧を目指して手が止まるより、まず形にしてフィードバックを得ることが大切だという話でした。

でも、「形にする」って具体的にどうやるの？という疑問が残りますよね。

今回は、その思想を技術面で実現する方法について書きます。

MVP開発の最大の敵は「考えすぎ」

個人開発でMVPを作ろうとすると、こんなことを考え始めませんか？

• 「スケールしたときのアーキテクチャは...」
• 「セキュリティ対策をしっかりと...」
• 「負荷が高くなったときのために...」
• 「コードは綺麗に書かないと...」

待って！それ、今考える必要ある？

MVP段階で最も重要なのは、ユーザーが本当にその機能を求めているか検証することです。

完璧なアーキテクチャを設計している間に、モチベーションが切れたり、誰も求めていない機能を作り込んだりしていませんか？

「考えないこと」を明確に決める。これが週末開発を成功させる鍵です。

バックエンドは本当に必要か？

ここで過激なことを言います。

MVPにバックエンドはいらない。

いや、正確には「最初は不要かもしれない」です。

バックエンドの役割って何？

一般的なWebサービスの構成を考えると、フロントエンド + バックエンド + DBという3層構造が「当たり前」になっていますよね。

でも、バックエンドの最大の役割ってDBアクセスなんです。（過激派理論）

もちろん、ビジネスロジックの実装やセキュリティの確保も重要な役割ですが、MVP段階では：

• 複雑なビジネスロジック → まだ必要ないかも
• セキュリティ → 後述の方法である程度担保できる
• DBアクセス → フロントから直接できる！

フロントから直接DBにアクセスする

「え、危なくない？」と思うかもしれません。

でも、Firebase や Supabase のようなサービスを使えば、**セキュリティルール（RLS: Row Level Security）**を設定することで、フロントから直接DBにアクセスしても安全に保てます。

// Supabaseの例
const { data, error } = await supabase
  .from('todos')
  .select('*')
  .eq('user_id', user.id) // RLSで自分のデータのみ取得可能

これだけで：

• バックエンドAPIの設計・実装が不要
• デプロイするサービスが1つ減る
• 開発速度が圧倒的に上がる

100人未満ならコントロールできる

「でもセキュリティが...」という声が聞こえてきそうです。

現実的に考えてみましょう。

• ほとんどのMVPは100人も来ません（辛いけど現実）
• 仮に100人来ても、悪意あるユーザーに当たる確率は低い
• 問題が起きても、個別対応できる規模

もちろん、決済情報や個人情報を扱う場合は最初からバックエンドを用意すべきです。

でも、CRUD中心のシンプルなアプリなら、最初はフロント + DB直結で十分です。

スケールしたら追加すればいい

「でも後からバックエンド追加するの大変じゃない？」

はい、大変です。でも、そもそもスケールしないアプリの方が圧倒的に多いのも事実。

スケールする問題に直面できたら、それは嬉しい悲鳴です。そのときに初めて、しっかりとしたバックエンドを実装すればいいんです。

最初から完璧を目指して手が止まるより、動くものを作ってフィードバックを得る方がはるかに価値があります。

MVP段階で考えなくていいことリスト

明確にしましょう。MVP段階では、以下のことは考えなくていいです。

❌ 考えなくていいこと

• セキュリティ監査 → RLSの基本設定だけで十分
• 負荷対策・スケーリング → 100人来ないのにスケーリング設計してどうする
• パフォーマンス最適化 → 3秒で返ってくれば十分。ミリ秒単位は後で
• 完璧なエラーハンドリング → 致命的なバグだけ潰す
• コードの美しさ → 動けば勝ち。リファクタは後
• インフラ冗長化 → サーバー落ちたら「ごめんなさい」で済む規模
• CI/CDパイプライン → 自動テスト10個とか過剰
• マイクロサービス化 → まだ早い

✅ 考えるべきこと

• ユーザーが求めている機能か？
• 使いやすいUI/UXか？
• フィードバックを集める仕組みがあるか？

以上。これだけです。

この「考えないリスト」を最初に作って、壁に貼っておくといいかもしれません。手を出しそうになったら自分を止める（笑）

週末開発を成功させる技術スタック

ここまでの思想を実現するための、具体的な技術スタックを紹介します。

フロントエンド：Vercel

なぜVercelか？

• GitHubと連携したら自動デプロイ
• 環境変数もWeb UIで簡単設定
• ドメインも無料SSL付き
• git push したら本番反映

デプロイで詰まって終わる、というパターンを完全に排除できます。

DB + Auth：Supabase

なぜSupabaseか？

• PostgreSQLベースで信頼性が高い
• 管理画面でテーブル作成が簡単
• 認証機能が標準装備
• RLS（Row Level Security）でセキュリティ担保
• URLとAPIキーをコピペするだけで使える

Firebaseも選択肢ですが、個人的にはSQLが使えるSupabaseの方が後々便利だと思います。

AI活用で開発速度3倍

これも重要なポイントです。

• Claude や ChatGPT に相談しながら開発
• 「Supabaseで認証とRLS設定して」→ コード生成
• 「このフロントからSupabase呼び出すコード書いて」→ 秒で完成
• Cursor などのAIコーディングツールを活用

バックエンドの知識が不足していても、AIが補完してくれます。

理想的な週末開発フロー

金曜夜: アイデア出し → Supabaseプロジェクト作成（5分）
土曜: コーディング（Cursor + Claude活用）
日曜午前: Vercel連携してデプロイ（10分）
日曜午後: 友達に共有してフィードバック収集

この構成なら、本当に週末で形にできます。

避けるべき構成（週末開発では）

逆に、以下は避けましょう。

• ❌ AWS EC2（SSH、セキュリティグループ、OSアップデート...）
• ❌ Docker + Kubernetes（完全にオーバーキル）
• ❌ 自前サーバー（IP固定、ドメイン設定、メンテナンス...）
• ❌ 複雑なCI/CD（過剰な自動テスト）

これらは素晴らしい技術ですが、MVP段階では不要です。スケールしてから考えましょう。

まとめ：引き算の美学

個人開発でMVPを作るとき、大切なのは引き算です。

• 技術スタックをシンプルに
• 思考をシンプルに
• まず動かして、フィードバックを得る

バックエンドが必要かどうかは、本当に考える価値があります。多くの場合、MVP段階では不要です。

「完璧なものを作る」より「動くものを作る」

これが、個人開発を成功させる最大のポイントだと思います。

---

それでは、良い週末開発を！🚀