SaaS開発を小さく始める方法　Webサービスを作りたい人が最初に決めること

SaaSを「小さく始める」とはどういうことか

小さく始めるというのは、いちばん解きたい困りごとを1つだけ解ける形で、早めに公開することです。機能を全部そろえてから出すより、使う人の反応を見ながら育てたほうが、お金も時間も無駄になりにくいからです。

Webサービスを作りたいという相談では、最初の打ち合わせで機能の一覧を20個も30個も持ってこられる方がいます。会員登録、マイページ、ポイント、クーポン、チャット、ランキング、アプリ版。

どれも作れます。ただ、全部入りで作ると公開までに時間がかかり、その間に誰にも使われていないサービスの費用だけが積み上がっていきます。

小さく始めるときの考え方は、だいたい次のようなものです。

• 誰の、どんな困りごとを解くのかを一文で言える
• その困りごとを解く最短の手順だけを画面にする
• 人の手でできる作業は、最初は人の手でやる
• 公開してから、使われ方を見て次に作るものを決める

「小さく」は、品質を落とすという意味ではありません。少ない機能でも、迷わず使えてきちんと動くことが前提です。数を絞ったぶん、1つひとつの画面に手をかけられます。

3つ目は意外に思われるかもしれません。でも、たとえば申込みが月に数件のうちは、確認メールを担当者が手で送っても十分回ります。自動化するのは、件数が増えて手が回らなくなってからで遅くないんです。

最初に作る機能の絞り方

最初に作る機能は、「これが無いとサービスとして成り立たない」ものだけに絞ります。判断に迷ったら、利用者がお金を払う瞬間、またはサービスの価値を感じる瞬間までに必要な画面だけを残すと考えると分かりやすいです。

1. 利用者の流れを紙に書くサービスを知ってから、申込み、利用、支払いまでの流れを、利用者の目線で順番に書き出します。
2. その流れに要る画面だけ丸をつける流れのどこかで必ず通る画面だけに丸をつけ、それ以外は候補から外します。
3. 人の手で代わりにできるものを外す集計、お知らせ配信、細かい設定変更などは、最初は運営側が手作業でやる前提にします。
4. 残った機能で見積もるこの段階の一覧で開発会社に見積もりを頼み、予算と期間が合うかを確かめます。

たとえば、オンラインで専門家に相談できるサービスなら、最初に要るのは「相談内容を送る画面」「専門家が回答を返す画面」「支払い」くらいです。専門家の評価やおすすめ表示は、利用者が増えてから考えても困りません。

作らないもののリストを先に決める

作るものの一覧と同じくらい役に立つのが、「最初は作らないもの」の一覧です。打ち合わせのたびに「やっぱりあれも」と機能が増えていくのを防げますし、関わる人の間で優先順位がそろいます。

最初の段階で後回しにしやすいものを並べると、次のようになります。

このリストは捨てる機能の一覧ではありません。公開後に「これが無くて困った」という声が出たものから順に、作る側へ移していきます。声が出なかったものは、たぶん最初から要らなかったんだと思います。

会員・決済・管理画面はどこまで必要か

会員機能、決済、管理画面の3つは、多くのWebサービスで最初から必要になる部分です。ただし、どれも作り込もうとすると際限がないので、最初は「最低限これだけ」の線を決めておきます。

決済は自前で作らない

カード決済の仕組みを一から作ることは、まずありません。外部の決済サービスと連携するのが一般的で、そのほうが安全面でも費用面でも無理がないです。どの決済サービスを使うかで、手数料や入金のタイミングが変わるので、事業の計画と合わせて選びます。

管理画面は運営する人の毎日を考えて作る

管理画面は利用者からは見えないので、つい後回しにされがちです。でも、公開後に毎日触るのは運営する側です。

申込みの確認、問い合わせへの返信、利用者の情報の修正。これらが管理画面でできないと、開発会社に毎回頼むことになり、手間も費用もかさみます。

運営する人が1人で回すサービスなら、なおさらです。鑑定や講座の申込みが入ったら、担当者が外出先のスマホからでも確認できる。それだけで、返信の遅れによる取りこぼしはかなり防げます。

運営を担当する人に「毎朝まず何を確認したいか」を聞いて、それが1画面で見られるようにしておく。最初の管理画面はそれくらいで十分です。

事例 占い鑑定のWebサービスと自社運営のeラーニング

LaughRallyでは、お客様のWebサービスの開発と、自社で運営しているサービスの両方を手がけています。

鑑定のように、専門の知識はサービスを始める人の側にあって、システムの部分だけを外に頼みたい、という形の相談です。こういう場合こそ最初の機能を絞っておくと、公開後に自分たちで運営を回しやすくなります。保守の金額も、作る範囲が小さければそのぶん小さく収まります。

自社で運営していて実感するのは、公開した日が始まりだということです。中身を足したい、画面の文言を直したい、分かりにくいと言われた部分を書き直したい。こうした改善は、実際に使われてみないと見えてきません。

正直なところ、公開前に「これは要る」と思って作った機能があまり使われず、後から足した小さな機能のほうがよく使われる、ということは珍しくありません。作る前の予想は、思っているよりよく外れます。

だから最初は小さく出して、使われ方を見てから決めるやり方をすすめています。

公開後の改善の回し方

公開後は、利用者の声と使われ方を見て、次に作るものを決める流れを回します。最初の公開は「たぶんこう使われるはず」という予想を試す場で、開発の本番はむしろそこからです。

1. 使われ方を見る登録した人がどこまで進んだか、どの画面で止まっているかを管理画面などで確認します。
2. 声を集める問い合わせや、利用者に直接聞いた感想をメモしておきます。数人に話を聞くだけでも十分です。
3. 次に作るものを1つ決める「作らないもののリスト」と声を見比べて、いちばん求められているものから手をつけます。
4. 小さく直して、また見る直したら再び使われ方を確認します。この繰り返しで、サービスが利用者に合った形になっていきます。

たとえば、申込みフォームの入力項目が多くて途中でやめる人が目立つなら、新しい機能を作るより先に、項目を減らすほうが効きます。地味な改善ですが、こういう手直しの積み重ねが一番効くことが多いです。

反対に、声が大きい1人の要望だけで機能を足すのは慎重にしたほうがいいです。その人にとっては欠かせなくても、ほかの利用者には画面が複雑になるだけ、ということもあります。複数の人から同じ声が出たら作る、くらいの基準を決めておくと判断が楽になります。

改善を続けるには、保守や伴走の体制も考えておきます。サーバーの管理や不具合への対応、ちょっとした修正を誰が受け持つのか。公開前に決めておくと、困ったときに慌てずに済みます。

開発会社に相談する前に用意しておくもの

相談の前に用意しておきたいのは、立派な企画書ではなく、サービスの中身が伝わる簡単なメモです。手書きでも箇条書きでも構いません。これがあるだけで、最初の打ち合わせで話せることがぐっと増えます。

• 誰に使ってほしいか（年齢や職業、どんな場面で使うか）
• 今その人たちは、困りごとをどうやって解決しているか
• 料金をどうもらうか（1回ごと、月額、無料で始めて一部有料など）
• 最初に作りたい機能と、後回しでよい機能の仮の線引き
• 公開したい時期と、使える予算のおおよその上限
• 公開後に運営を担当する人と、使える時間

最後の項目は見落とされがちです。たとえば本業の合間に週に数時間しか運営に使えないなら、問い合わせ対応や申込みの確認をなるべく自動にしておく必要があります。反対に、毎日しっかり運営に時間を使えるなら、最初は手作業を多めにして開発費を抑える選択もできます。

似たサービスがあれば、そのサイトの名前やURLをメモしておくのもおすすめです。「この画面の流れが近い」「ここは違う」と具体的に話せると、開発会社との認識のずれが減ります。

スマホの画面を撮ったスクリーンショットでも十分です。打ち合わせでそれを見せながら「申込みボタンはこのくらい目立たせたい」と話してもらえれば、言葉だけで説明するより話が早く進みます。

予算は正直に伝えたほうがいいです。上限が分かれば、開発会社も「その予算ならここまでを最初の版に」と現実的な提案ができます。予算を伏せたまま機能の一覧だけで見積もりを取ると、出てきた金額を見てから機能を削る作業が始まり、二度手間になりがちです。

費用の目安と進め方

LaughRallyで業務システム・SaaSを開発する場合の目安は、50万円から、期間は1〜3か月です。公開後の改善を一緒に回す月額の伴走支援は月5万〜15万円。占い鑑定のサービスのように、開発のあと月額の保守だけを続ける形もあります。

開発中は途中で動く画面を見せながら進めます。実際に触って「ここは要らない」「ここは足りない」と判断できるので、小さく始めるやり方とは相性がいいと思います。大きな開発になる場合は提携の開発パートナーと体制を組みますが、窓口はLaughRallyがひとつで担当します。

作りたいサービスの形がまだぼんやりしていても大丈夫です。無料の業務診断（60分・オンライン）で、最初に作る機能の候補を一緒に整理できます。売り込みはしません。

ざっくりした金額を先に見たい場合は、見積もりシミュレーターで確かめられます。過去の開発は事例のページにもまとめています。