A. 新規構築

Step.2 要件・方式検討

# 新規顧客

SaaSでは対応できない会員サイトとは?──8つの要件チェックリスト

会員サイトをSaaSで作ろうと検討している。デモも見たし、機能も揃っていそうだ。でも、自社の要件が本当に実現できるのか、どこか不安が残る──。この感覚は正しい警戒心です。SaaSには構造的に「できないこと」のパターンがあり、契約後に気づくと撤退コストが大きくなります。この記事では、SaaSで対応できない会員サイトの典型的な8つの要件を、事前に自己チェックできる形で解説します。

結論の要約

SaaSは、その製品がターゲットにしている会員サイト像の範囲内であれば優秀ですが、そこから外れる要件には対応できません。対応できない典型は次の8つです。①タイプの複合、②基幹システム連携、③差別化のためのオリジナル機能、④複雑な会員構造、⑤契約〜決済フローの独自性、⑥件数・ボリュームの上限、⑦帳票・情報の深さ、⑧認証基盤との連携。 1つでも当てはまるなら、SaaS以外の方式(パッケージ・CMSベース開発・スクラッチ)も含めて検討すべきです。

なぜSaaSには「できないこと」があるのか

前提として、SaaSの限界は製品の欠陥ではありません。SaaSは「想定した会員サイト像」に特化することで、安く・早く・安定したサービスを成立させています。想定内なら快適に使え、想定外のことをやろうとした瞬間に壁が現れる──これはSaaSというビジネスモデルの構造そのものです。

また、「あとから開発で足せばいい」も通用しにくい領域です。開発のしやすさには「SaaS<パッケージ<スクラッチ」という一般的な傾向があり、SaaSは使えるAPIが限られている、開発環境を別途用意する必要がある、APIの作法が独特、といった制約があります。APIが豊富なSaaSもありますが、「すべて自由にできる」わけではない点は共通です。

SaaSで対応できない8つの要件

自社の構想を次の8項目に照らしてみてください。

① タイプの複合。 リード獲得(オウンドメディア)も、既存顧客向けのサポートや手続きも、1つのサイトでやりたい──このような複数タイプの複合は、単一タイプに特化しているSaaSの最も苦手とするところです。

② 基幹システム連携。 販売管理・顧客マスタ・在庫などの基幹システムと繋ぎたい場合、SaaS側の連携手段が限られているため、大半は対応できません。基幹がオンプレミスにある場合はさらに難しくなります。

③ 差別化のためのオリジナル機能。 例えば標準のクーポン機能はあっても、「この条件のときだけポイント付与率を変える」「パーソナライズと連動してクーポンの出し方を変える」といった一歩踏み込んだ仕掛けはできません。本来こうした工夫こそが他社との差別化になるため、差別化を重視する企業ほどSaaSの標準機能では物足りなくなります。

④ 複雑な会員構造。 SaaSは多くの企業で使えるよう、シンプルな会員構造(1つの会員DBに個人がフラットに並ぶ形)で設計されています。法人の下に個人がぶら下がる、家族会員がいる、1人が複数の立場を持つ、といった構造は標準では持てないことがほとんどです。

⑤ 契約〜決済フローの独自性。 契約管理から請求・入金までの業務フローは会社ごとに驚くほど違います。BtoBの毎月自動課金や銀行引き落とし、ポイントと連動した決済、独自の確認手順などが絡むと、SaaSの決済機能では収まりません。

⑥ 件数・ボリュームの上限。 SaaSには想定ボリューム(会員数・データ件数・コンテンツ量)があります。明示的な上限がなくても、超えると動作が重くなる「実質的な上限」が存在します。ただしこの項目だけは、カタログからは判断できず、問い合わせて確認するしかありません。

⑦ 帳票・情報の深さ。 独自フォーマットの帳票を出したい、印刷に耐える形式にしたい、あるいは「自社は他社より細かい物流ステータスを管理しているので、それを会員に見せたい」──こうした要望に対して、SaaS側にそもそもその項目・ステータスが存在しない、ということが起こります。

⑧ 認証基盤との連携。 SSOや認証基盤との連携は、連携方式が多様で対応負荷が高いため、対象外としているSaaSが少なくありません。既存の認証基盤に繋ぎたい場合は、対応可否を必ず最初に確認すべき項目です。

チェック結果をどう使うか

8項目のうち1つも当てはまらないなら、適したSaaSを探すのが最善です。目的が1つで標準機能で足りるなら、SaaSの費用対効果は他の方式を上回ります。

1つでも当てはまるなら、SaaS単体では実現できない可能性が高く、「SaaSをあきらめる」か「SaaS+開発のハイブリッド」か「CMSベースやスクラッチでの開発」かの比較検討が必要になります。このとき大事なのは、当てはまった項目を隠さずにベンダーへ伝えることです。弊社に相談に来られるお客様の中には、「SaaS会社に要件を伝えたら断られた」という方が少なくありませんが、それは早い段階で構造的なミスマッチが分かったという意味で、むしろ幸運なケースです。契約後・構築途中に発覚するのが最も高くつきます。

まとめ

まとめ:SaaSでは対応できない会員サイトとは?──8つの要件チェックリスト

SaaSで対応できないのは、①複合②基幹連携③オリジナル機能④複雑な会員構造⑤決済の独自性⑥ボリューム上限⑦帳票・情報の深さ⑧認証基盤、の8パターンです。まずはこのチェックリストに自社の構想を照らし、当てはまった項目をメモにしてください。そのメモがそのまま、ベンダー選定と方式選定の要件リストになります。

8つのチェックで複数当てはまった方へ。SaaS以外の方式も含めた構成のご相談をお受けしています。会員サイト構築のご相談はこちら

よくある質問

Q1. SaaSは結局やめた方がいいのでしょうか?

いいえ。目的が単一で標準機能で足りる会員サイトなら、SaaSが最も合理的な選択です。この記事は「SaaSが悪い」という話ではなく、SaaSの想定範囲と自社要件のミスマッチを契約前に見つけるための話です。

Q2. SaaSで始めて、限界が来たら乗り換える戦略はアリですか?

アリです。ただし会員データ・コンテンツの移行コストと、乗り換え時の再構築費用を最初から織り込んでおくこと。「3年で乗り換える前提」と「10年使う基盤を作る前提」では、最初に選ぶべきものが変わります。

Q3. ⑥のボリューム上限はどう確認すればいいですか?

「会員数○万人・コンテンツ○万件・ピーク時アクセス○○の規模で、同等規模の導入実績はあるか」をベンダーに直接確認してください。実績ベースの回答が返ってこない場合は注意が必要です。