🍎

要件が固まっていない段階で、どう技術選定しているか

に公開
技術選定
webアプリ
スタートアップ
プロダクト開発
idea

はじめに：要件が固まっていない段階で、どう技術選定しているか

初投稿です。優しい目で見ていただけたら嬉しいです

この記事では、仕様がまだ固まっていないアイディア段階で、
自分がどのような考え方・順序で技術選定をしているかを言語化します。

React vs Vue、Next.js vs Vite のような
「どちらが優れているか」を決める記事ではありません。

多くのプロダクトでは、初期段階において
フレームワークの差が成否を分けることはほとんどなく、
それよりも 「どれだけ早く作り始められるか」「作り続けられるか」 の方が重要だと感じています。

そのためこの記事では、

  • 技術の良し悪しではなく
  • 自分（やチーム）が迷わず動けるか
  • 将来ちゃんと捨てずに済むか

といった観点を中心に、実際の選び方を書いています。

技術選定に正解はないと思っていますが、
この記事が誰かの 思考のたたき台 になれば嬉しいです。

技術選定を書く前提と自分の経験

この記事が前提としている開発経験

自分のこれまでの経験は以下の通りです。

  • 言語：TypeScript / Python を中心に Ruby, Go, Dart
  • フレームワーク：React, Vue, Django, FastAPI, Rails, React Native, Flutter
  • DB：Postgres（Supabase, Drizzle, Prisma, CloudSQL など）
  • Cache / Queue：Redis

この経験を前提に書いているため、
異なる技術スタックを主戦場にしている方とは意見が分かれる部分もあると思います。

今回想定しているプロダクトのフェーズ

この記事で想定しているのは、

  • 何かアイディアを思いついた
  • プロダクト化したいが、仕様はまだ曖昧
  • 作りながら考えたい

といった 初期フェーズ です。

自分が技術選定で大事にしている5つの評価軸

評価軸① 慣れているか・ワクワクするか

技術選定で一番重要なのは、
その技術に慣れているか、触っていて前向きな気持ちになれるかだと思っています。

多くの場合、技術そのものの優劣が初期の成否を分けることは少ないです。

評価軸② 仲間を集めやすいか（普及率）

どれだけ好きでも、極端にマイナーな技術は初期では避けることが多いです。

  • 将来チームを作る可能性
  • 情報の探しやすさ

といった点で、多少は普及率を意識します。

評価軸③ 車輪の再発明をしない

エンジニアリングの時間単価を過小評価しないことを意識しています。

  • 認証
  • DBホスティング
  • キャッシュ
  • インフラ

など、競争優位にならない部分は積極的に既存サービスを使うようにしています。

評価軸④ 本番レベルへちゃんと接続できるか

Quick and Dirty な実装を許容しつつも、

  • ちゃんとやりたくなったとき
  • 万が一ユーザーが増えたとき

に破綻しないかは初期でも考えます。

評価軸⑤ 思考負荷を増やさないか

システムを構成する要素数や、
それらの依存関係が複雑になりすぎないかを重視しています。

「できる」より「考えなくていい」を優先します。

技術比較は「正解探し」ではなく「制約の把握」

よくある比較例（React / Vue, Next.js / Vite など）

  • React vs Vue
  • Next.js vs Vite
  • Node vs FastAPI

といった比較はよく見かけますが、
初期段階では決定打にならないことも多いです。

初期段階では差分になりにくいポイント

SSR やオフライン対応なども、
技術的には多くの選択肢で実現可能です。

重要なのは「できるか」より「今考えるべきか」です。

技術的優劣より、チームとの相性を優先する理由

流行っているからという理由で、
慣れていない技術を選ぶと初速が落ちやすいと感じています。

実際の技術選定フロー（自分の場合）

Q1. 将来モバイル対応する可能性はあるか

  • Yes：pnpm + turborepo
  • No：bun

Q2. オフラインでどこまで動かしたいか

  • Yes：Vite（SPA）
  • No：Next.js（App Router）

Q3. APIはTSかPythonか

判断基準の例：

  • チームの得意分野
  • ML系タスクの有無
  • WebSocketの比重
  • 型共有の重要度

Q4. Postgresはどこでホスティングするか

  • Realtime / Cron がすぐ欲しい → Supabase
  • TS中心 → Prisma / Convex
  • 純粋な Postgres → Neon

技術スタック例①：Next.js × Node.js × Supabase

採用理由

  • 型共有
  • Realtime / Cron の初速
  • Next.js のお作法に乗れる

得られるもの

  • 開発スピード
  • 運用のシンプルさ

受け入れているトレードオフ

  • Supabase Auth への依存
  • 完全なオフライン体験は難しい
  • ダッシュボードにロジックが分散する

技術スタック例②：Vite × Python × Neon

採用理由

  • MLタスクとの接続性
  • オフライン前提の設計
  • Staging 環境の作りやすさ

得られるもの

  • 柔軟な設計
  • DB運用のしやすさ

受け入れているトレードオフ

  • 型共有ができない
  • API実装量が増える
  • メンタルモデルがやや複雑

詳細な技術選定（ライブラリ・ツール編）

フロントエンド（Next.js周辺）

  • pnpm
  • eslint / prettier
  • tanstack
  • zustand
  • zod
  • tailwind / shadcn
  • Vercel

バックエンド（FastAPI周辺）

  • uv
  • psycopg3
  • ruff
  • mypy
  • Celery
  • Cloud Run

DB / インフラ（Supabase）

  • 基本は素のまま利用

思考負荷という観点から見たアンチパターン

ホスティングを分散しすぎる問題

  • サービスごとに異なるホスティング
  • 安さや機能で選びすぎる

結果として、認知コストが増えがちです。

「安さ」より「認知コスト」を優先する理由

多少コストが上がっても、
考えることが減る方が結果的に進みが早くなります。

まとめ：技術選定は未来の自分への配慮

技術選定は、
その時点での「最強の技術」を選ぶ作業ではなく、
未来の自分（やチーム）が楽に判断し続けられる状態を作ることだと思っています。

初期段階では、

  • 完璧な設計
  • 技術的に尖った構成

よりも、

  • 慣れている
  • 迷わない
  • 捨てやすい
  • ちゃんと本番につながる

ことの方が、結果的にプロダクトを前に進めてくれます。

今回書いた内容は、
自分の経験にかなり強く依存したものなので、
そのまま真似しない方がいいと思います。

ただ、

「自分は何を大事にして技術を選んでいるのか」

を考えるきっかけになれば嬉しいです。

今後は、
個別の技術（Next.js / Supabase / Neon など）についても、
なぜそれを選んでいるのかをもう少し掘り下げて書いていきたいと思っています。

Discussion