前のエントリの最後に、

たとえば、「小規模のSaaSが共通課金基盤を持つ」というのも悪いことじゃないと思います。 PixivやBoothのノリで手軽にSaaSを公開して… ってあると面白いし嬉しいでしょうね。 課金が増え過ぎる問題もかなり解決するでしょう。

ということを書いたのですが、これを整理してメモにしておきます。

例によって単なるアイディアの公知化なので、先行例についての調査はしていません。 また、先発明の権利は主張しません。

課題

クラウドクライシスが起きる理由として、費用の増大を上げました。 このことについては、前エントリを読んでください。

それとは全く別の話ですが、オープンソースソフトウェアを開発した場合どう収益化するかは大きな課題となっています。 このための解決の一つがクラウドサービス化ですが、ある程度以上の企業の場合はさておき、個人や零細企業となると、

  • インフラをどうするか
  • 課金をどうするか
  • 信頼性(継続性)をどう担保するか

という問題があり、いくら便利なものでも利用が躊躇されたりします。 つまり、収益化のハードルはあまり下がってくれません。

解決

これらの課題を解決するアイディアとして、

小規模SaaSの提供と課金を統合した基盤

を提案します。

つまり、小規模SaaSのマーケットプレイス的なものを使い、ユーザーへのSaaSの提供はそのプラットフォームから行います。 そして、それぞれのタリフに応じた課金もそのプラットフォームから提供します。

将来的には、その課金インフラ自体をSaaS提供する方向もあるでしょう。

データベースやロードバランスと言ったインフラ部分をプラットフォームで提供することにすれば、インフラについての悩みを減らすこともでき、サービス提供へのハードルを下げます。

期待される効果

  • 開発したソフトウェアのSaaS展開のためのインフラの悩みがなくなる(減る)
  • 課金が容易になるため、収益化のハードルが下がる
  • 支払い先が集約化される
  • SaaSそのものの流動性が高まりM&A等が容易になる

前2つは説明の必要はないと思います。

「支払い先の集約化」については、

  • 支払いが明確になる
  • 小規模取引先が増えない
  • 従量制課金のハードルが下がり、固定支出が減るかも知れない

という効果が期待されます。 法人契約だとすると、細かい取引先(Saas)が増えないのは経理が嬉しいかも知れません。

事業者が小規模な場合、サ終や突然死というようなことがリスクとして上げられると思います。 流行らなかった結果としてそうなることは害がありませんが、中途半端に流行っているのにそうなってしまう場合は、事業譲渡されて復活という可能性もあります。 インフラそのままで事業譲渡できるのは、サービス継続性という意味も含めて都合いいですね。

また、「SaaSそのもののマーケットプレイス」としての機能も期待できます。

おわりに

単なるアイディアに過ぎませんので、やりたい人は御自由にどうぞ。 足りない部分は適宜補足すれば、「あなた」のものです。

ただし、ここで私がネットに公開してしまいましたから、このエントリは公知例となります。 特許取得はできませんので、御理解ください。

最近のエントリー

金曜ごはん #15 「フジツボ香るポトフと手作り肉まん」

ある冬の晴れた日、海岸でフジツボに出会いました

金曜ごはん #14 「手作りつくね鍋~スーパーに導かれて~」

SaaS基盤のアイディア (公知化情報)

第18回 3年以内に起きる「オンプレ回帰」の5つの具体的イベント予測

金曜ごはん #13 「醤油と塩の2種のお鍋」

CassetteOSのロードマップ

Orcinusを開発した理由

12月スタート!事務所をクリスマス仕様にしました

金曜ごはん #12 「リピートハンバーグ」

第17回 業務システムをオープンソースで作ること

金曜ごはん #11「タルタルチキン南蛮と、アボカドシュリンプの彩り晩餐」

金曜ごはん #10 「鶏肉祭り」

Hieronymus Ver 2.0.6 release

HieronymusとOJT後のgemini-cli

金曜ごはん #9 「お肉たっぷり700g!"欲張りハンバーグ"ディナー」

金曜ごはん #8 「ジェネリック山ちゃん再び」

金曜ごはん #7「冬の到来。カニとお鍋」

金曜ごはん #6 「最近忘れがちになっている金曜ごはん」

gemini-cliへの新人教育