SaaS ベンダーの仕組みと契約の注意点

Terminal
Terminal

取引がオンラインで行われる場合も、対面で行われる場合も、一貫性のあるユニファイドコマース体験を構築できます。Stripe Terminal は、プラットフォームや大手企業向けの開発者ツール、認証済みのカードリーダー、 iPhone および Android デバイスに対応できる Tap to Pay、クラウドベースのデバイス管理を提供します。

もっと知る 
  1. はじめに
  2. SaaS ベンダーとは
    1. SaaS ベンダーの定義
  3. SaaS ベンダーの仕組み
    1. アプリケーションの開発とホスティング
    2. メンテナンス、更新、継続的デリバリー
    3. 拡張性
    4. セキュリティとコンプライアンス
    5. ユーザー登録とサポート
  4. 企業が SaaS ベンダーを選ぶ際に考慮すべきこと
    1. セキュリティとコンプライアンス
    2. 信頼性とパフォーマンス
    3. サポートとサービス
    4. 連携と互換性
    5. 価格設定とコストの透明性
    6. ベンダーの評判とロードマップ
    7. 出口戦略
  5. SaaS ベンダーとの契約のよくある落とし穴
    1. SLA が曖昧または欠落している
    2. データ保護条件が緩い
    3. 終了や更新の条件が不明瞭
    4. 隠れた手数料と不意の請求
    5. スケールアップまたはスケールダウンに関する柔軟性に欠ける条件
    6. 一方的な権利

2023 年には、平均的な企業で 112 のサービスとしてのソフトウェア (SaaS) アプリケーションが使用されました。SaaS ベンダーは、チームがタスクの追跡、クライアントへの請求、チャット、データの分析に使用するツールを強化します。このようなベンダーによって導入は容易になりますが、自社のどれだけの部分が自ら制御していないシステムに依存しているかを忘れがちです。シンプルな月額の サブスクリプション のように見えるものが、実際には隠れたコスト、厳格な契約、そして何かが壊れたときに初めて明らかになる脆弱性を抱えている可能性があります。

以下では、SaaS ベンダーの仕組み、契約する前に尋ねるべきこと、そして関係をうまく機能させる方法について説明します。

この記事の内容

  • SaaS ベンダーとは
  • SaaS ベンダーの仕組み
  • 企業が SaaS ベンダーを選ぶ際に考慮すべきこと
  • SaaS ベンダーとの契約のよくある落とし穴

SaaS ベンダーとは

SaaS ベンダーは、インターネット経由でアクセスするクラウドベースのソフトウェアを提供します。通常、月額または年額のサブスクリプション料金を支払い、ブラウザーまたはアプリからログインします。ベンダーは、ホスティング、更新、セキュリティなど、すべてを裏側で処理します。

これらのツールは、情報テクノロジー (IT) に関連するオーバーヘッドを伴うことなく、ビジネスに合わせて拡張 できます。サーバーを維持したり、ノート PC にソフトウェアを導入したりする必要がなく、チームはどこにいても同じ最新サービスにすぐにアクセスできます。Slack や Google Workspace などのプラットフォームでビジネスを運営している場合は、すでに SaaS ベンダーと連携していることになります。

SaaS ベンダーの定義

  • クラウドホスティング: ソフトウェアはベンダーのサーバー上で実行されるため、ローカルに何もインストールする必要はありません。ブラウザーを開いて作業に取り掛かるだけです。

  • 定期メンテナンス: ベンダーは、インフラ、更新、バグ修正を処理します。新しいバージョンとセキュリティパッチが自動的に適用されます。

  • アクセシビリティー: インターネット接続とデバイスさえあれば、どこでもソフトウェアを使用できます。

SaaS ベンダーの仕組み

SaaS ベンダーは、クラウドでホストされるアプリケーションを構築して実行し、それらのアプリケーションをインターネット経由で顧客に提供します。従来のソフトウェアとは異なり、インストール、手動更新はなく、ユーザー側でインフラを維持する必要もありません。ログインしてサービスにアクセスするだけです。

このビジネスモデルの仕組みは次のとおりです。

アプリケーションの開発とホスティング

SaaS ベンダー は通常、単一のコードベースで製品を構築するため、すべての顧客が同じインフラを使用します。データは分離されて安全に保たれますが、ソフトウェア自体は共有されます。このモデルは、マルチテナンシーと呼ばれます。

この設定により、ベンダーは次のことが可能になります。

  • 独自のクラウドインフラ上で、または Amazon Web Services (AWS) などのホスティングプロバイダーを通じて、アプリケーションを一元的にホストする

  • 新機能と修正を一度に全員にロールアウトする

  • バージョンの断片化や複雑なアップグレードパスを回避する

これは、顧客の視点から見ると、改善へのより迅速なアクセスとオーバーヘッドの削減を意味します。

メンテナンス、更新、継続的デリバリー

ソフトウェアの維持管理は、SaaS と従来のソフトウェアモデルの最大の違いの 1 つです。SaaS では、更新は自動的かつ継続的に行われます。バージョンのロールアウトを計画する必要はありません。

ベンダーは以下の責任を負います。

  • バグの修正とプラットフォーム全体へのパッチの展開

  • ダウンタイムを伴わない新機能やユーザーインターフェイス (UI) の変更の提供

  • ソフトウェアのパフォーマンス、負荷分散、可用性の管理

ソフトウェアの最新バージョンにいつでもアクセスできるため、アップグレードのスケジュールを設定する必要はありません。

拡張性

SaaS プラットフォームは、顧客の成長に合わせて拡張するように構築されています。チームがユーザーを追加したり、データストレージを拡張したり、トラフィックが急増したりした場合、システムはそれに応じて調整されます。

ベンダーは以下に対処します。

  • キャパシティプランニング

  • リソース割り当て

  • 使用傾向に応じたインフラの拡張

これは、中小企業 や変化の速い企業にとって SaaS を非常に魅力的にしている理由の 1 つです。構築やメンテナンスを行うことなく、エンタープライズグレードのインフラを手に入れることができます。

セキュリティとコンプライアンス

ベンダーは、ソフトウェア、ソフトウェアが稼働するインフラ、およびソフトウェアを通過するデータを保護する必要があります。通常、次のセキュリティ対策があります。

  • 暗号化 (転送中と保存中の両方)

  • アクセス制御と認証レイヤー

  • 定期的な脆弱性スキャンとシステム監視

  • データ保護規制の遵守

  • 第三者による監査と認証

セキュリティはアーキテクチャーの一部です。マルチテナント環境では、ベンダーは、ある顧客のデータを他のユーザーによるアクセスから大規模に保護するシステムを設計する必要があります。

ユーザー登録とサポート

SaaS プロバイダーは通常、チームが利用を開始して生産性を維持できるよう設計された、カスタマーサポートのライフサイクル全体を提供します。

多くの場合、次のものが含まれます。

  • 設定ガイダンスと文書

  • チュートリアル、トレーニングセッション、実装サポート

  • トラブルシューティングサポート

  • 大口クライアントに対応する専任のアカウントマネージャーまたはカスタマーサクセスチーム

すべてのユーザー間でアプリケーションが共有されるため、サポートチームはパターンをすばやく見つけることができます。ある顧客からのバグレポートが、すべての顧客にメリットをもたらす修正につながる可能性があります。

企業が SaaS ベンダーを選ぶ際に考慮すべきこと

SaaS ベンダーを選択するということは、継続的なサービス関係を結ぶことを意味します。適切なベンダーを選ぶことで、ビジネスをよりスピーディーに 拡大 し、より効率的に運営することができます。ここでは、プロバイダー候補を評価する際のポイントをご紹介します。

セキュリティとコンプライアンス

自社のデータが他の誰かのサーバーに保存されている場合、そのデータが安全であることを確認する必要があります。エンドツーエンドの暗号化、SOC 2ISO 27001 などの認証、一般データ保護規則 (GDPR) やカリフォルニア州消費者プライバシー法 (CCPA) などの関連するデータプライバシーフレームワークの遵守状況について確認します。また、セキュリティ文書や監査報告書の透明性も確認します。ベンダーがセキュリティモデルを明確に説明できなかったり、機密性の高い分野で認証を受けていなかったりした場合、それは警告サインです。

信頼性とパフォーマンス

洗練された UI は、チームが必要とするときにアプリが遅かったり、オフラインだったりした場合、ほとんど意味がありません。レビューを読み、フォーラムをチェックし、クライアントに問い合わせます。

次の点について質問します。

  • 公開されている稼働時間に関する指標: これらの指標は、ユーザーがソフトウェアを使用できる時間の割合を反映しています。

  • サービスレベル契約 (SLA): これらは、可用性に対する期待を形式化し、ベンダーがその期待を満たさなかった場合の救済策を概説します。

  • パフォーマンスの一貫性: これには、速い読み込み時間、応答性の高いダッシュボード、最小限の遅延が含まれます。

  • 災害復旧: これには、地理的な冗長性と自動データバックアップが含まれます。

サポートとサービス

優れたソフトウェアでさえ、サポートを必要とします。

以下を評価します。

  • サポートの対応状況: サポートは 24 時間年中無休か、それとも営業時間中のみ利用できるか。

  • 応答時間: 緊急の問題に迅速に対応できるか。応答時間は SLA に記録されているか。

  • チャネル: ベンダーにメール、チャット、電話で連絡できるか。

  • ユーザー登録と教育: ベンダーは導入をサポートしてくれるか。トレーニング資料やガイド付きセットアップはあるか。

連携と互換性

1 つのシステムだけを運用している企業はほとんどありません。SaaS プロバイダーは、すでに使用中のシステムと連携する必要があります。ツールがサイロ化されていると、手作業が発生し、スケーリングの妨げになります。

次の点を確認します。

  • ネイティブ連携: すでに使用中のプラットフォームとの事前構築済みの接続

  • オープンなアプリケーションプログラミングインターフェイス (API): 独自のワークフローを構築する必要がある場合に役立つ、柔軟で十分に文書化された API

  • ID の連携: アクセスとセキュリティを向上させるシングルサインオン (SSO) と Security Assertion Markup Language (SAML)

  • Webhook またはエクスポート機能: プログラムを利用してデータを自由に移動できるツール

価格設定とコストの透明性

料金体系モデルはさまざまです。重要なのは、明瞭さと使用量との整合性です。ニーズに合わせてカスタマイズされた見積もりを依頼し、規模が拡大するとどうなるかを常に確認します。

次の特性を評価します。

  • 透明性: レベル、使用制限、追加料金について説明してくれるベンダーを探します。

  • 予測可能性: 使用量のピーク、機能へのアクセス、API コールに関連する予期せぬ事態を回避します。

  • 総所有コスト: 月額料金が低い場合、追加料金 (ユーザー登録、サポート、データ超過など) が隠されている可能性があります。

  • 料金の変動: ユーザー数、データ量、機能数に応じて料金がどのように変化するかを把握します。

ベンダーの評判とロードマップ

プロバイダーが宣伝する機能は、そのプロバイダーを信頼できなければ意味がありません。既存のクライアントから情報を収集し、ベンダーの信頼性と将来の計画の記録を確認します。

以下の詳細を確認します。

  • 継続性: ベンダーはどのくらい前から存在しているか。役に立つか。最近資金を調達したか。

  • 参考情報: 誰が顧客か。業種や大規模セグメントでの例はあるか。

  • ロードマップ: 積極的に製品を構築し、改善を加えているか。確認できる最近または今後のリリースはあるか。

出口戦略

ビジネスを 1 つのプロバイダーに永久に縛り付ける必要はありません。将来別のシステムへの移行が困難になるという警告サインを確認します。

次の点を考慮します。

  • データポータビリティー: クリーンで使いやすい形式でデータをエクスポートできるか。

  • ユーザー登録解除のサポート: ベンダーは移行サポートを提供しているか、または移行の猶予期間を設けているか。

  • 契約条件: 切り替えを遅らせる可能性のある早期の契約終了や通知期間に対する罰則はあるか。

  • API と形式のオープン性: 契約の終了を困難にする独自の形式やクローズドシステムがあるか。

SaaS ベンダーとの契約のよくある落とし穴

SaaS ベンダーの規約への同意は、単純なクリックスルーや署名の少ない注文フォームのように見えるかもしれません。ただし、その書類には、ご自身の権利、責任、償還請求の概要が記載されています。

ソフトウェアが業務にとって重要な場合、または長期か高額の取引に署名する場合は、署名する前に法的な意見を聞き、事前にベンダーに質問します。常に次の点を明確にする必要があります。

  • サービスのサポート方法

  • 製品の機能が期待を下回る場合に起きること

  • 終了する必要がある場合の選択肢

  • ベンダーによるデータ保護の方法

  • 経時的な財務状況の全体像

ここでは、企業にとって想定外になる可能性のある状況を紹介します。

SLA が曖昧または欠落している

SLA では、製品の信頼性がどの程度であるか、信頼性がない場合にどうなるかを説明する必要があります。しかし、多くの契約では、その情報が曖昧であるか、完全に欠落しています。稼働時間のコミットメント、サポートが問題にどれだけ迅速に対応するか、およびそれらの約束が守られなかった場合の償還請求についての記載が SLA に含まれていることを確認します。明確な SLA がないと、ソフトウェアが不安定な場合やサポートを利用できない場合に活用できる手段が少なくなります。

データ保護条件が緩い

データセキュリティを軽視すると、規制コンプライアンスの問題やデータ侵害につながる可能性があります。契約では、データの所有者、ベンダーが従うことを約束するデータ セキュリティ 基準、およびベンダーがデータを匿名化された形式であっても独自の目的で使用できるかどうかを明確にする必要があります。

ベンダーから SOC 2 レポートなどのより詳細な情報の共有を申し入れられることもありますが、その場合は申し入れを承諾します。

終了や更新の条件が不明瞭

契約があるからといって、必ずしもサービスの利用を簡単に終了できるとは限らず、契約期間の把握が容易になるわけでもありません。明確なキャンセル条件、オプトアウトに必要な長い通知期間、契約終了に対する罰則、データの削除方法についての言及がない自動更新に注意します。契約の開始時期、終了時期、終了方法に関する明確な条件が必要です。

長期取引については、早期終了条項について交渉するか、サービスの質が悪い場合や製品の大幅な変更がある場合など、特定の条件下での終了を可能にするのが妥当です。一部のベンダーでは、早期終了した場合、使用した月の料金を支払うだけで済みます。そのような点が概説されていることを事前に確認してください。

隠れた手数料と不意の請求

基本料金はコストの一部にすぎません。データや使用量の制限を超えた場合、特定の連携や API を利用した場合、またはプレミアムサポートレベルを選択した場合に追加料金が発生する契約は珍しくありません。一部の契約には、事前に通知する必要がある、時間の経過とともに発生する値上げ (年間 5% の値上げなど) も組み込まれています。何が含まれているか、何が追加されるか、いつ価格が変更される可能性があるかについて、漏れなく確認してください。

スケールアップまたはスケールダウンに関する柔軟性に欠ける条件

時間の経過とともに、人員が増減する可能性があります。ユーザーを追加または削除した場合の 比例配分料金 や一定期間後に条件を見直す機会など、ある程度の柔軟性を持たせるとよいでしょう。特に長期契約では、状況が変わった場合に条件を調整できるかどうかを確認してください。

一方的な権利

一部の SaaS 契約では、ベンダーに機能、価格、または条件を変更する権利が与えられています。場合によっては、ほとんど警告なしにチームが利用している機能が削除され、その後も契約に縛られることがあります。

製品の変更がビジネスに重大な影響を及ぼす場合は、それに対応するための権利が必要です。ベンダーが主要な機能を削除したり、使用状況に影響を与える大きな変更を加えたりした場合に (罰則なしで) 契約を終了できる条項を探してください。

この記事の内容は、一般的な情報および教育のみを目的としており、法律上または税務上のアドバイスとして解釈されるべきではありません。Stripe は、記事内の情報の正確性、完全性、妥当性、または最新性を保証または請け合うものではありません。特定の状況については、管轄区域で活動する資格のある有能な弁護士または会計士に助言を求める必要があります。

今すぐ始めましょう

アカウントを作成し、支払いの受け付けを開始しましょう。契約や、銀行情報の提出などの手続きは不要です。貴社ビジネスに合わせたカスタムパッケージのご提案については、営業担当にお問い合わせください。
Terminal

Terminal

オンラインと対面のどちらにおいても、一貫性のある購入体験を構築することができます。

Terminal のドキュメント

Stripe Terminal を使用して対面支払いを受け付けて、 Stripe の支払いを POS ソリューションに拡大できます。