企画ガイド · SaaS・Webアプリケーション

SaaS MVP の範囲設計

MVP はすべてを小さくしたものではありません。実際のユーザーが最後まで完了できる1つの導線と、その導線に必要な権限・データ・引き継ぎです。

中国、江門市。グローバルに働いています。

1つの導線を端から端まで

ユーザーの言葉で導線を書きます。何を持って来て、何をして、何を持ち帰るのか。ある手順に別の人や別のシステムが必要なら、それは範囲に含まれます。

依頼を受け付け、担当者に割り当て、進捗を示す顧客ポータルは完結した導線です。未完成の機能を6つ並べたダッシュボードはそうではありません。

誰が作成・編集・承認・削除できるのか。各権限はどのデータを見られるのか。画面を作った後に権限を決めると、たいてい画面の作り直しになります。

各権限を1文で書き出し、それぞれの立場で主導線をたどります。ここで見つかる穴は、テスト段階で見つかる穴よりずっと安く済みます。

製品が読み書きする必要のあるシステムと、利用できない場合の挙動を列挙します。回数制限、ページング、認証、同期失敗時にユーザーへ何を伝えるかも含めます。

既存の表計算や旧データベースがある場合は、匿名化したサンプルで構造を説明します。現状のデータが記録されていないため、移行工数は過小評価されがちです。

課金、レポート群、ネイティブアプリ、シングルサインオン、高度な検索は第2段階の定番です。範囲外と明記することは弱さではなく、最初のリリースを検証可能にします。

最初のリリースで行わないことを書面で合意すれば、受け入れ時に境界を初めて知る事態を避けられます。

導線の各手順について、期待する動作と失敗時の動作を書きます。誰が承認するのか、何を証拠とするのか（録画、テストアカウント、チェックリスト）も決めます。

この形で書いた条件は、「できた気がする」を、双方が1時間で判断できる決定に変えます。

MVP の機能はいくつ必要ですか？

関係するすべての権限が1つの導線を完了できるだけの数で、それ以上は不要です。その導線にも法令要件にも資さない機能は、後のリリースに回します。

先にデザインシステムは必要ですか？

完全なものは不要です。最初の導線に必要なレイアウト、フォームの型、コンポーネントの状態を決め、製品の成長に合わせて広げます。

MVP 公開後はどうしますか？

範囲を決める段階で引き継ぎも計画します。運用担当、不具合の修正担当、データのバックアップ、次段階の優先順位です。サポート条件は公開後より公開前に合意するほうが容易です。