SaaS新規事業の開発｜最初に作る範囲の決め方
SaaSを新規事業として立ち上げるとき、最初のシステムにどこまで入れるかで、開発の進み方も、事業の確かめやすさも大きく変わります。この記事では、確かめたい仮説を起点に、最初に作る範囲を決める手順と、SaaS特有の周辺機能の仕分け方を整理します。
SaaSの最初のシステムが「作りすぎ」になりやすい理由
SaaS（ソフトウェアをインターネット経由で継続的に提供する形態）は、一度作って終わりのシステムとは性質が違います。利用者に使い続けてもらうことが前提で、他のサービスと機能を並べて比べられやすい事業です。そのため、最初のシステムを考え始めると、次のような機能が次々に頭に浮かびます。
- ログインやアカウントの管理
- 会社ごとにデータを分ける仕組み
- 権限の設定（管理者・一般利用者など）
- 請求や決済の機能
- 管理者向けの画面
- 通知やメール配信
- 利用状況の分析画面
- 他のシステムとの連携
どれも、SaaSとして世に出すなら将来は必要になる機能です。ただ、全部を最初に揃えようとすると、開発に時間がかかり、肝心の「この事業は成り立つのか」を確かめる時期が遅れていきます。
新規事業の最初のシステムは、完成形の縮小版ではありません。事業の仮説を確かめるための道具です。この見方に立つと、範囲の決め方が変わってきます。MVP（最小限の機能で価値を確かめる製品）の考え方については、MVP開発の機能の絞り方｜最初に作るものと後回しの基準でも整理しています。この記事では、SaaSに絞って掘り下げます。
範囲を決める前に、確かめたい仮説を言葉にする
機能の一覧を作る前に、まず「何を確かめたいのか」を書き出します。SaaSの新規事業で確かめたいことは、おおむね次の4つに分けられます。
- 課題の仮説：想定している利用者は、本当にその課題で困っているか
- 解決の仮説：このシステムの使い方で、その課題は解決できるか
- 継続の仮説：一度使った人が、日常の業務の中で使い続けるか
- 収益の仮説：継続して使うことに対して、対価を払ってもらえるか
4つすべてを最初から確かめようとすると、範囲が広がります。そこで、「これが外れたら事業が成り立たない」という最も不安な仮説を1つ選び、まずそこを確かめられる範囲に絞ります。
たとえば、現場の担当者が日々の報告をシステムに入力し続けてくれるかが最大の不安なら、最初に作るべきは入力と閲覧の流れです。請求機能や詳細な分析画面ではありません。不安の大きい仮説から確かめる、という順番にすると、範囲を決める軸ができます。
新規事業のアイデアを動くシステムで確かめる手順は、新規事業のアイデア検証方法｜動くシステムで確かめる手順にまとめています。
最初の範囲を決める4つの手順
手順1：利用者と「最初の一回の成功」を決める
最初の利用者を、できるだけ具体的に1種類に絞ります。SaaSでは、管理者、現場の担当者、経営層など、複数の立場が登場しがちです。しかし、最初から全員に向けて作ると、画面も機能も増えます。
次に、その利用者が「使ってよかった」と感じる最初の一回の成功を決めます。たとえば「初回の入力から、結果が画面に出るまで」のように、できる限り短い一連の体験です。この最初の成功までの道のりが、最初のシステムの中心になります。
手順2：一連の流れを、薄くても一本通す
機能を一つずつ作り込むのではなく、利用の入口から成果が出るところまでを、粗くてもよいので一本つなげます。登録、入力、処理、結果の確認という流れです。
SaaSの価値は、個々の機能よりも、流れ全体で課題が解決されるかどうかに表れます。一部の機能だけが丁寧に作られていて、全体がつながっていない状態では、利用者の反応から得られるものが少なくなります。縦に薄く、一本通すことを優先します。
手順3：周辺機能を3つに仕分ける
SaaSには、事業の中心ではないが無視もできない周辺機能が多くあります。これらを次の3つに仕分けます。
- 最初から必要：なければ安全に使えない、または流れが成り立たないもの
- 手作業や代替手段で補えるもの：システム化せず、運営側が人の手で対応するもの
- 後に回すもの：仮説が確かめられてから作ればよいもの
仕分けの具体例は、次の見出しで表にまとめます。
手順4：確かめる期間と、見る指標を先に決める
範囲が決まったら、「いつまでに、何が分かれば次に進むのか」を先に決めます。たとえば「利用者が自分から2回目の入力をしたか」「現場の担当者が、案内なしで最後まで操作できたか」といった、観察できる事実です。
この判断基準がないと、動くものができても「もう少し機能が必要では」という議論に戻りがちです。基準があれば、機能が足りないのか、そもそも仮説が違ったのかを切り分けられます。
SaaSの周辺機能は、こう仕分ける
周辺機能の仕分けは、事業の内容によって答えが変わります。以下は、考え方を示すための一般的な目安です。
| 機能 | 最初の判断の目安 | 考え方 |
|---|---|---|
| ログイン・認証 | 最初から必要 | 利用者ごとのデータを守る土台のため |
| 会社ごとのデータ分離 | 最初から必要 | 他社のデータが見えると事業の信頼を失うため |
| 細かい権限設定 | 最小限にする | 最初は「管理者」と「一般」程度で足りることが多い |
| 請求・決済 | 手作業で補えることが多い | 請求書の発行などを運営側で対応し、仕組みは後で作る |
| 管理者向け画面 | 必要最小限 | 運営側が確認できれば足りる場合は、簡易な画面にとどめる |
| 通知・メール配信 | 流れに必要なものだけ | 継続利用に直結する通知のみ先に作る |
| 利用状況の分析画面 | 後に回す場合が多い | 最初は記録を残し、集計は手作業でも確かめられる |
| 外部システムとの連携 | 仮説の検証に必要なら | 連携先のデータがなければ価値が出ないときだけ先に作る |
| 多言語・多通貨対応 | 後に回す | 市場の広げ方が決まってから |
この表で特に注意したいのは、最初から必要な機能の中に、データの分離と認証が入っている点です。見た目や便利さに関わる機能は後に回せても、利用者のデータを守る土台を削ると、後から作り直す範囲が大きくなります。また、事業の信頼に直接関わります。
なお、AIを使って開発する場合も、セキュリティの確認は欠かせません。確認点はAI生成コードのセキュリティ｜確認点と人の役割で整理しています。
「手作業で補う」という判断は、SaaSの最初の検証でよく役立ちます。たとえば請求を運営側が手作業で行えば、請求機能を作る時間を事業の中心部分に使えます。逆に言えば、利用者が増えて手作業が回らなくなった時点が、その機能を作る合図になります。
範囲を決めるときに起こりがちな失敗
競合との機能比較で、範囲が広がっていく
同じ領域の既存サービスを調べると、機能の多さに圧倒され、「これくらいは必要だろう」と足していきたくなります。しかし、既存サービスの機能は、長い期間をかけて利用者の声を受けて育ってきたものです。最初のシステムが同じ機能数を備える必要はありません。
比較で見るべきなのは機能の数ではなく、「自分たちのSaaSが、どの利用者の、どの課題に、どの流れで応えるのか」という点です。
声の大きな要望を、そのまま全部入れてしまう
社内の関係者や、見込みの利用者から出る要望は、どれも理由のあるものです。ただ、すべてを取り込むと、最初に確かめたい仮説が見えなくなります。要望は「今回は入れない」と決めたものも含めて記録しておき、次の改善で優先度をつけて検討します。
言葉だけで範囲を決めて、後から食い違いが出る
機能一覧や仕様書の言葉だけで範囲を決めると、関係者ごとに頭の中の画面が違ったまま進んでしまいます。「ここまで入るはずだった」「そこは入らないと思っていた」という食い違いは、完成が近づいてから分かることが多く、直すのに手間がかかります。
こうした認識のずれを防ぐには、動く実物を触りながら確認する方法が有効です。詳しくはシステム開発の認識のズレを防ぐ、実物を見ながらのすり合わせで書いています。また、要件を整理する進め方は要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方が参考になります。
「あとで足せる」と考えて、土台を軽く見る
範囲を絞るときに、削ってよいものと削ってはいけないものを混同すると、後で大きな手戻りになります。機能は後から足せますが、データの持ち方や利用者の管理の仕組みなど、土台にあたる部分は後から変えにくいものです。
機能を削るときは、「後から足しても土台に影響しないか」を確認します。影響しそうなものは、最小限でも最初から設計に含めておくほうが安全です。
決めた範囲を、社内で合意するために
最初の範囲が決まっても、新規事業では社内の合意が次の関門になります。決裁をする立場と、現場で事業を立案する立場では、同じ目的を見ていても、判断の材料と進める速度が違うことがあります。この食い違いの背景は新規事業で経営陣と現場がすれ違う原因は進め方のズレで整理しています。
範囲を共有するときは、次の3点を1枚にまとめると、話が噛み合いやすくなります。
- 何の仮説を確かめるための最初のシステムか
- 今回入れるもの、入れないもの、手作業で補うもの
- 確かめる期間と、次に進むかどうかの判断基準
ただし、文書だけでは「実際に何ができるのか」が伝わりにくい場面もあります。その点は新規事業の決裁を企画書だけで取るのが難しい理由で触れています。動くプロトタイプを見せながら説明すると、決裁の場でも具体的な議論ができます。稟議での使い方は稟議を通すシステム開発｜プロトタイプの使い方を参照してください。
プロトタイプ、MVP、モックの違いが曖昧なまま話を進めると、期待するものが人によって違ってしまいます。用語の整理にはプロトタイプとMVP・モックの違いを整理｜新規事業の使い分けが使えます。
最初の範囲を決めたあと、機能を増やす順番
最初のシステムは出発点です。範囲を決めたあとは、実際の使われ方を見ながら、機能を足していきます。このとき、次の順番で考えると迷いにくくなります。
- 利用者が詰まったところ：流れの途中でやめてしまう場所を直す
- 手作業の負担が大きくなったところ：運営側で補っている作業を仕組みにする
- 継続利用に効く機能：使い続ける理由につながるものを足す
- 事業を広げるための機能：新しい利用者層や市場に向けた機能
最初の手順にあった「後に回すもの」は、この順番の中で必要になった時点で作ります。足す理由が、使われ方の事実にもとづいている点が大切です。
納品後の改善を前提にした考え方は、システムは納品後の改善で育てる｜新規事業の考え方でも紹介しています。小さく作って確かめながら投資を判断する進め方は、新規事業の開発は小さく作って確かめる投資判断の進め方が参考になります。
まとめ
SaaSの新規事業で、最初のシステムに入れる範囲を決めるポイントは次のとおりです。
- 最初のシステムは完成形の縮小版ではなく、仮説を確かめる道具として考える
- 機能の一覧より先に、「最も不安な仮説は何か」を1つ選ぶ
- 利用者を絞り、最初の一回の成功までを薄くても一本つなげる
- 周辺機能は「最初から必要」「手作業で補う」「後に回す」の3つに仕分ける
- 認証やデータの分離など、後から変えにくい土台は削らない
- 確かめる期間と判断基準を先に決め、範囲を1枚にまとめて社内で共有する
- 機能の追加は、使われ方の事実を見ながら順番に行う
範囲を決める作業は、言葉の上だけで進めるほど判断が難しくなります。企画書だけでは範囲の妥当性を確かめにくいときは、動くものを先に見る進め方が助けになります。
JustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断していただく受託開発サービスです。システムを軸に事業の形まで提案することを得意としており、仕様が固まっていない段階や、稟議の前の段階でもご相談いただけます。詳しくはJustFitのサービス紹介をご覧ください。