SaaSの受託開発の失敗事例 – リスクを回避し成功へ導くためのポイント

2023年5月8日2023年10月21日

近年、SaaS（Software as a Service）の需要が急速に高まっており、多くの企業が開発を検討しています。
とある調査では、2023年には国内パッケージソフトの市場規模をSaaSが追い抜くとの予想も出ています。（ITR社調べ）

しかし、システム会社がSaaSの受託開発を行う場合、必ずしも成功するとは限りません。
むしろ、いくつかの点で失敗すると「アイデアは素晴らしかったのに、開発は失敗した」という、悲しい事態に陥るかもしれません。

今回は、弊社で過去に取り組んだSaaS受託開発の事例から、いくつかの失敗をご紹介させていただきます。
ぜひ『SaaSの開発を検討しておられる企業さん』、『SaaSの受託開発を受けようと思っているシステム会社さん』に読んでいただき、これから行うSaaS開発に活かして貰えればと思います。

どんな開発事例か？

さて、『SaaS受託開発の失敗事例』をこれから書いていく訳ですが、少し混乱しそうなので、全体像を先に説明しておきます。

出てくるのは『クライアント』『弊社』『エンドユーザー』の３者です。

登場人物：クライアント

SaaSの開発を『弊社』に依頼
運用は『クライアント』と『弊社』が共同で行う。（名義は『クライアント』）
SaaSの運営とは別に、主たる事業がある。

登場人物：弊社

SaaSの開発を受注したシステム会社
カスタマイズや保守も任されている
細かい仕様の決定権も持っている

登場人物：エンドユーザー

SaaSの利用者
複数の企業

SaaS

Softwear as a Serviceの略。
おおよそ「クラウド上に作ったWebサービス」と考えてもOK。
※今回の事例で取り上げるSaaSは企業向けですが、おおよそどんなSaaS開発でも使える内容だと思います。

失敗１：使えるクラウドサービスを最大限利用しなかった

最近のクラウドサーバには、ただの領域だけでなく、あらゆるサービスやツールが用意されています。
例えばストレージやデータベース、コンテナやメディア変換、モニタリングやAPIの管理等、画期的なサービスもありますし、補助や手助けをしてくれるツールもあります。

こういったサービスを利用するか、それとも慣れた自分のやり方でインストールするか……、迷うかもしれませんが、使えるものは最大限利用しましょう。

今回の事例でもEC2上にサービスを構築していたのですが、
「Amazon RDS」や「Aurora」を使わず、自前で「PostgreSQL」をインストールして使ってしまいました。
なんとなくその方が「安全」で「手堅い」ように感じてしまったのです。

……しかしよく考えてみてください。
RDS等のサービスを使えば、インストールの手間を掛けずすぐにDBを使うことができます。
EC2で使う場合のお勧めの設定や、セキュリティの体制も整っており、安心して運用できます。
バックアップやログ保存の設定も、すでに手を回してくれているので細かく用意する必要がありません。

なんとなく「自分の知ってるやり方」「自分が全て調節できるやり方」を取ってしまいがちになりますが、もはやそこに価値はありません。
使えるクラウドサービスは最大限利用しましょう。

失敗２：初めから多岐にわたるニーズを吸収しようとし過ぎた

SaaSの開発は正直楽しいです！
『このサービスがいずれ世に出て、いろんな人に使ってもらえる！』と思うと、他の作業よりもワクワクしますし、
クライアントとそのことについて話していると、知らない間に機能が増え続けていたりします。

しかし、だからといって初期から多機能を目指すのはおすすめできません。
『機能を追加することで、いろんなニーズに応えられる！』と思うかもしれませんが、
機能を追加すればするだけ、システムは複雑になり、リリース日は伸び、UIもわかり難くなります。

更に、まだそのSaaSのことをエンドユーザーは知りません！
満を持してSaaSをリリースしたとしても、結局これは誰向けのサービスなんだろう？と認知できないまま、素通りしてしまうかもしれません。

まずは１つのニーズ、１つの機能に特化して開発を行いましょう。
技術的にもマーケティング的にも、それを強くお勧めします。

失敗３：DB、ドメイン、アプリバージョンを統合すること（マルチテナント）を意識しすぎた

すでに成功している有名なSaaSは、基本的に１つのドメインで運用されており、ユーザーは会員登録すればすぐに使い始めることができます。
また、１つのアプリバージョン、１つのデータベース上で運用されているため、ユーザー間のやり取りや、保守が行いやすくなっています。

……しかしそれは、すでに大量の顧客がいる、完成されたサービスだからこそメリットのある設計です。

今回の事例では、エンドユーザーの企業にフィードバックをもらいながら改良していく、いわばMVP開発に近いやり方を取っていました。

その状況で１つのドメイン、１つのデータベース、１つのアプリを使い、複数のクライアントへサービスを提供していたら、どうなったでしょうか？
１つ機能を追加するにも、全エンドユーザーのサービスを止めて実装する必要があります。新機能を簡単にテストするのは難しいです。
また、１社のエンドユーザーから新機能の要望をもらったとしても、他の顧客に影響が無いか考えなければなりません。

初期段階は統合を意識するよりも、『いかに柔軟に対応できるか』『いかに快適に運用できるか』といった点に注力したほうがいいでしょう。

需要が確認でき、顧客数が増えたなら、その時改めてスケールすればいいのです。

失敗４：見込み顧客がいない状態で開発を始めた

これはSaaSにかぎらず、あらゆる企画や商品開発に共通した話ですが、
多くの場合、提供側の技術・リソースを土台にしてサービスを開発する『プロダクトアウト』ではなく、
市場のニーズ・ユーザーの要望を元にサービスを開発する『マーケットイン』のほうが、成功しやすいでしょう。

『マーケットイン』のメリットはたくさんあります。

エンドユーザーの要望・市場の需要を確認した上で開発できる。
『本当に必要とされている機能』にリソースを集中させることができる。
競合他社の製品について、どこに問題があるのか把握し、差別化することができる。
テストユーザーがそのまま顧客になる。

特にSaaS開発においては、エンドユーザーが意識的に送ったフィードバックだけでなく、どの機能がどのぐらい使われたのか、という詳細な情報を収集することができます。
見込み客が確保できるのに、あえてそうしない利点は特に無いでしょう。

もちろん、まだ市場が育っていない分野（例えば今ならジェネレーティブAI等）ならば、『プロダクトアウト』のほうがスピード感や需要開拓の面で優れていますが、
すでにあらゆるサービスが存在している市場に切り込んでいくのならば、しっかりと需要を確認した上で製品開発を行う『マーケットイン』の手法を取るのが正解です。

失敗５：見た目にこだわり過ぎてしまった

開発中、私もクライアントも新しく作るSaaSに自信がありました。
だからこそ、デザインは格好良く仕上げたいと思っていましたし、『デザインのせいでこのサービスが敬遠されることは避けたい』と思っていました。

なのでデザインの１つ１つにこだわり、結果スタイリッシュでエレガントな見た目のSaaSが出来上がりました。

『……しかしそれは必要だったのだろうか？』と今では思います。
当たり前のことですが、エンドユーザーがSaaSに求めているのは機能であって、スタイリッシュなデザインではありません。

もちろん「見た目が悪い」ことは良くないことですが、今はBootStrapや、様々な優れたフレームワークがたくさん用意されています。
それらを使うなら、デザインを犠牲にすることなく、機能の充実や完成度にリソースを集中することができるのです。

ただし、ここで注意したい点は「見た目に力を入れない」ことと「使い勝手に力を入れない」ことは別です。
ユーザーが使いやすい・分かりやすいUIを用意することは、SaaSにおいて力を入れるべき重要な点と言えるでしょう。

失敗６：クライアントの本業が忙しくなって終了してしまった

さて、このSaaSの結末をお話すると……、
残念ながら、本格的なリリースを経ることなく、開発自体が終了してしまいました。

クライアントのメイン事業に転機が訪れ、そちらに少しでもリソースを割きたい、とのことでSaaSの開発に手が回らなくなったのです。

もちろんそういう事態が起こり得ることは覚悟の上でしたし、円満にプロジェクトは終了したため、特に『大きなアクシデント』というものではないのですが、
『もしこのSaaSを世に送り出せていたら……』と考えると、いささか残念な気持ちもあります。

また今回の事例では、代表者格の方と直接やり取りを行っており、開発にかかわるいろんな点を迅速に判断して頂いたのですが、
もしこれが担当の方を別に置いてもらい、重要な点だけ代表の方へ伺うという形を取っていれば、プロジェクト事態を終了しなくても済んだ可能性はあります。
その点は反省すべき点だったかもしれません。