専門領域SaaSを大きな構想からMVPへ落とす要件定義

専門領域向けのWebサービスを考えると、構想はすぐ大きくなります。設計、記録、発注、権限、履歴、公開ページ、動画、チーム運営、過去データの継承まで、必要に見える機能が一気に増えます。

しかし、最初から全部作ろうとすると、何から実装すべきか分からなくなります。この記事では、専門領域向けSaaSやWebプラットフォームを、大きな構想からMVPへ落とし込む要件定義の進め方をまとめます。

大きな構想は否定せず、最初の入口を決める

専門領域のサービスでは、最終構想を小さくしすぎると価値が見えなくなります。一方で、実装計画まで巨大なままだと着手できません。

そこで、最終構想と最初の実装対象を分けます。

最終構想
  設計ツール
  データベース
  チーム運営
  発注連携
  試験記録
  技術継承
  公開ページ

最初のMVP
  もっとも価値が高く、既存資料や計算根拠がある1機能

たとえば、工学系チーム向けのプラットフォームなら、全体運営ツールから始めるより、既にExcelで使っている設計計算をWeb化する方がMVPにしやすい場合があります。

1年・1製品・1プロジェクトの単位を決める

継続利用される専門領域サービスでは、データの単位を最初に決めます。

team
  ↓
project
  ↓
design / test / parts / orders / comments

重要なのは、単発データではなく、年度や世代をまたいで比較できることです。

保存するもの	理由
数値	年度比較や性能比較に使う
変更理由	後から判断根拠を追う
問題点	同じ失敗を繰り返さない
試験結果	設計値と実測値をつなげる
申し送り	メンバー交代後も知識を残す

特に学生チームや小規模組織では、数年で担当者が入れ替わります。操作データだけでなく、判断理由を残せる設計にすることが価値になります。

内部データと公開データを完全に分けすぎない

専門領域プラットフォームでは、内部向けの詳細情報と、外部に見せたい公開情報が共存します。

単純に「内部DB」と「公開Wiki」を別物にすると、同じ情報を二重管理することになります。初期設計では、同じデータに公開範囲を持たせる方が拡張しやすくなります。

visibility
  private
  members
  organization
  registered_users
  public

公開範囲は、画面だけで隠すのではなく、APIやDB設計の段階で扱います。内部情報、限定公開情報、一般公開情報が混ざるほど、権限設計は後回しにしない方が安全です。

計算系はUIと分離する

工学、会計、在庫、価格計算のように計算品質が重要なサービスでは、計算ロジックをUIに埋め込まないようにします。

Next.jsなどで画面を作る場合でも、計算部分は関数やモジュールとして分離し、同じ入力に対して同じ出力が返るようにします。

UI
  入力、表示、保存

Domain calculation
  単位変換
  妥当性検証
  計算
  エラー判定

Tests
  既存Excelや基準ケースとの比較

既存Excelがあるなら、代表ケースをJSONにして回帰テストに使います。

{
  "caseName": "benchmark-a",
  "input": {
    "spanM": 32,
    "massKg": 85,
    "speedMS": 8.0
  },
  "expected": {
    "requiredPowerW": 280
  },
  "tolerance": {
    "requiredPowerW": 0.5
  }
}

「それっぽい値が出た」ではなく、既存計算や手計算と一致するかを確認します。

解析エンジンはWeb本体から分離する

外部バイナリ、重い計算、長時間処理が必要な場合は、Webアプリ本体と解析APIを分けます。

Browser
  ↓
Next.js Web App
  ↓
Application API
  ├ PostgreSQL / Supabase
  └ Analysis API
      ├ external binary
      ├ numerical calculation
      └ convergence result

VercelのようなServerless環境に、長時間・外部プロセス実行・バイナリ依存を無理に載せると、制限にぶつかりやすくなります。通常画面はVercel、解析APIはDocker対応の環境やVPSへ分ける、という判断も現実的です。

解析結果には、数値だけでなく、収束、未収束、エラー理由、入力条件、実行バージョンを残します。後で比較できない解析結果は、設計履歴として弱くなります。

最初のデータモデルは広く置きすぎない

将来構想に合わせてテーブル候補を洗い出すことは重要です。ただし、MVP時点で全部作る必要はありません。

最初は、次のような核だけに絞ります。

users
teams
team_members
projects
project_revisions
core_designs
calculation_runs
attachments
comments
change_logs
permissions

発注、試験、公開プロフィール、動画、会計などは、MVPの利用状況を見てから追加します。

Supabaseを使う場合は、早い段階でチームID、プロジェクトID、作成者、公開範囲を持たせます。後から権限列を足すより、最初から全テーブルの基本列として考えた方が運用しやすくなります。

ロードマップは機能名ではなく検証目的で分ける

ロードマップは、実装したい機能の羅列になりがちです。MVPでは、各フェーズで何を検証するかを明確にします。

Phase	目的	例
0	利用者理解	現在のExcel、保存方法、困りごとのヒアリング
1	中核価値の検証	主要計算をWeb化し、保存と比較ができる
2	解析連携の検証	外部解析APIを呼び、結果を履歴化する
3	継承価値の検証	変更理由、コメント、過去版比較を使える
4	周辺業務の検証	部材表、発注、試験記録へ広げる

最初の成功指標も、売上だけにしない方がよいことがあります。保存されたプロジェクト数、継続利用、作成された設計数、比較機能の利用、フィードバック数など、MVPに合った指標を置きます。

エージェント分業では正本ドキュメントを先に作る

複数のAIエージェントや開発担当で並行作業する場合、全員に同じ前提を渡す正本ドキュメントが必要です。

最低限、次を固定します。

プロジェクトの目的
最初のMVP
対象ユーザー
主要データ単位
公開範囲と権限の考え方
技術構成候補
計算品質の基準
未決定事項
各担当の成果物

担当は、機能ではなく責務で分けます。

担当	成果物
要件定義	REQUIREMENTS.md、USER_FLOWS.md、SCREEN_LIST.md
DB/API	DATABASE.md、schema.sql、API_SPEC.md
計算エンジン	計算仕様、回帰テスト、ベンチマーク
解析連携	API仕様、Dockerfile、エラー仕様
UI/UX	画面仕様、コンポーネント構成、プロトタイプ
調査	出典URLつき調査メモ

共通ルールとして、既存仕様を勝手に変えない、変更提案は提案として分ける、計算式には根拠を書く、単位を明示する、テストを書く、といった基準を置きます。

未決定事項を明示しておく

大きな構想では、未決定事項を曖昧なまま進めると、後で手戻りになります。

未決定事項
  サービス名
  無料/有料範囲
  一般公開範囲
  チーム認証方法
  外部解析エンジンのライセンス扱い
  画像や動画の利用権
  身体情報などの慎重に扱うデータ管理

未決定であること自体は問題ではありません。問題は、決まっていないものを決まった前提で実装してしまうことです。

まとめ

専門領域SaaSは、最終構想を大きく持ちながら、最初の実装を小さく切る必要があります。

最終構想とMVPを分ける
年度、製品、プロジェクトなど、データの単位を先に決める
数値だけでなく、変更理由や申し送りを保存する
内部情報と公開情報は、同一データに公開範囲を持たせる形を検討する
計算ロジックはUIから分離し、既存Excelや基準ケースで回帰テストする
重い解析エンジンはWeb本体から分離する
ロードマップは機能名ではなく検証目的で切る
複数エージェントで進めるなら、正本ドキュメントと担当成果物を先に決める

大きなサービスほど、最初に全部作るのではなく、何を中核価値として検証するかを決めることが重要です。