サービスとしてのソフトウェア
クラウドコンピューティングのカテゴリ

サービスとしてのソフトウェア（SaaS / sæ s / [1]）は、プロバイダーが必要な物理リソースとソフトウェアリソースを管理しながら、アプリケーションソフトウェアをクライアントに提供するクラウドコンピューティングサービスのモデルです。 [ 2 ] SaaSアプリケーションは、Webアプリケーションまたはローカルにインストールされたソフトウェアを介してアクセスされます。他のソフトウェア配信モデルとは異なり、SaaSは「ソフトウェアの所有と所有権とその使用」を切り離します。[3] SaaSの使用は2000年頃に始まり、2023年までにソフトウェアアプリケーションの展開の主な形態となりました。

ほとんどの自己ホスト型ソフトウェア製品とは異なり、ソフトウェアのバージョンは 1 つだけ存在し[要出典] 、オペレーティング システムと構成も 1 つだけサポートされています。SaaS 製品は通常、レンタルのInfrastructure as a Service (IaaS) またはPlatform as a Service (PaaS) システムで実行されます。これにはハードウェア、場合によってはオペレーティング システムとミドルウェアも含まれ、使用量の急激な増加に対応しながら、顧客に即時かつ継続的な可用性を提供します。SaaS の顧客は無制限のコンピューティング リソースを抽象化できると同時に、規模の経済によってコストが削減されます。SaaS アーキテクチャは通常はマルチテナントです。通常は効率化のためにクライアント間でリソースを共有しますが、追加料金でサイロ化された環境を提供する場合もあります。一般的な SaaS の収益モデルには、フリーミアム、サブスクリプション、使用量ベースの料金などがあります。従来のソフトウェアとは異なり、特定のバージョンのソフトウェアの永久ライセンスを購入できることはほとんどありません。

SaaS と他のアプリケーション開発を区別する特定のソフトウェア開発手法はありませんが、頻繁なテストとリリースに重点が置かれることがよくあります。

クラウドコンピューティング

オンプレミス、IaaS、PaaS、SaaSの比較

IaaS（ Infrastructure as a Service ）はクラウドコンピューティングの最も基本的な形式で、物理コンピュータなどのインフラストラクチャリソースはユーザーが所有するのではなく、クラウドプロバイダーからリースされます。[4]その結果、コンピュータの出荷とセットアップに数週間待つことなく、インフラストラクチャリソースを迅速に増強できます。 IaaSでは、オペレーティングシステムとアプリケーションの形でインフラストラクチャを利用するために時間と専門知識が必要です。[5] PaaS（ Platform as a Service）にはオペレーティングシステムとミドルウェアが含まれますが、アプリケーションは含まれません。 [6] [7] SaaSプロバイダーは通常、PaaSまたはIaaSサービスを使用してアプリケーションを実行します。[6]

IaaSがなければ、顧客が期待する即時かつ継続的な可用性を提供しながら、可変数のユーザー向けにスケーラブルなSaaS製品を作成することは非常に困難です。[8] ほとんどのエンドユーザーはSaaS製品のみを利用し、物理的なハードウェアやオペレーティングシステムの技術的な複雑さを心配する必要はありません。[9]クラウドリソースは人間の介入なしにアクセスできるため、SaaSの顧客には無制限のコンピューティングリソースの抽象化が提供され、規模の経済によってコストが削減されます。[10]クラウドコンピューティングのもう1つの重要な特徴は、ソフトウェアアップデートをほぼ瞬時に展開してすべての顧客に提供できることです。[11] 2019年には、SaaSがクラウドコンピューティング市場の過半数（43％）を占めると推定され、IaaSとPaaSを合わせた割合は約25％でした。[12]

歴史

1960年代にはマルチタスクが発明され、メインフレームコンピュータは複数のユーザーに同時にサービスを提供できるようになりました。その後10年間で、タイムシェアリングがコンピューティングの主なビジネスモデルとなり、クラスタコンピューティングによって複数のコンピュータの連携が可能になりました。[10]クラウドコンピューティングは1990年代後半に登場し、Amazon（1994年）、Salesforce（1999年）、Concur（1993年）などの企業がインターネットベースのアプリケーションを従量課金制で提供しました。これらの企業はすべて、高い市場シェアを獲得するために単一の製品に注力していました。[13] 2004年のGmailに始まり、電子メールサービスは消費者向けに大量販売された最初のSaaS製品の一つでした。[14] SaaS市場は21世紀初頭を通じて急速に成長しました。[15] [12]当初は技術革新と見なされていましたが、SaaSはビジネスモデルとして認識されるようになりました。[16] 2023年までに、SaaSは企業がアプリケーションを提供する主な方法になりました。[17]

一般的な消費者向けSaaS製品には、あらゆるソーシャルメディアウェブサイト、Gmailや関連するGoogleドキュメントエディタなどの電子メールサービス、[18] Zoom、Dropbox、[19] NetflixやSpotifyなどのエンターテイメント製品などがあります。[20]エンタープライズSaaS製品には、Salesforceの顧客関係管理（CRM）ソフトウェア、SAP Cloud Platform、Oracle Cloud Enterprise Resource Planningなどがあります。[19]

収益モデル

一部のSaaSプロバイダーは、広告、アフィリエイトマーケティング、または消費者データの販売などの手段で資金を調達し、消費者に無料サービスを提供しています。 [21]インターネットの新興企業やモバイルアプリの最も一般的なモデルの一つはフリーミアムです。これは、企業が継続使用またはより高いレベルのサービスに対して料金を請求するものです。[22]ユーザーが有料版にアップグレードしなくても、企業がより高い市場シェアを獲得し、競合他社から顧客を奪うのに役立ちます。[23]ただし、有料版を使用するようにユーザーを誘導することに成功したかどうかに関係なく、ユーザー数が増えるにつれて、企業のホスティングコストが増加します。[24]もう1つの一般的なモデルは、無料版がデモのみを提供するものです（クリップルウェア）。オンラインマーケットプレイスは、SaaSプロバイダーのコストをカバーするために、取引に手数料を請求する場合があります。[21]かつてはSaaS製品が1回限りの費用で提供されるのが一般的でしたが、このモデルの人気は低下しています。[21]いくつかの[21] SaaS製品にはオープンソースコードがあり、オープンSaaSと呼ばれています。このモデルは、導入コストの削減、ベンダーの関与の軽減、アプリケーションの移植性向上などの利点をもたらす。[25]

SaaS の収益モデルとして最も一般的なのは、サブスクリプションと従量制課金です。[26]顧客にとってのメリットとしては、従来型の永久ソフトウェア ライセンスに比べて初期費用が安く、柔軟性が高く、総費用が安いことが挙げられます。[27]従来型ソフトウェアの販売者が要求する高額な 1 回限りの費用は中小企業には手が届かない場合もありましたが、従量制課金の SaaS モデルならソフトウェアを手頃な価格で入手できます。[3]使用量は、ユーザー数、トランザクション数、ストレージ使用量、その他の指標に基づいて課金される場合があります。[28]多くの購入者は、自分たちは比較的ソフトウェアをあまり使用しないと考えているため従量制課金を好み、販売者も通常はソフトウェアを購入しないようなたまに利用するユーザーにリーチすることで利益を得られます。[28]しかし、これは販売者の収益の不確実性を引き起こし、請求の諸経費を増加させる可能性があります。[29]

SaaSのサブスクリプションモデルは、解約されやすいという欠点はあるものの、プロバイダーに継続的かつ更新可能な収益源を提供します。[3]多数の解約が発生すると、事業の存続が危ぶまれる可能性があります。[3]サブスクリプションの解約や競合他社への切り替えが容易なため、顧客は販売者から譲歩を引き出すための影響力を持つことになります。[30]継続的な収益は事業に役立ち、投資家を引き付けることができますが、顧客にサブスクリプションの更新を説得するためのカスタマーサービススキルが必要となるため、他の収益モデルからサブスクリプションに切り替えるプロバイダーにとっては課題となります。[31]

採択

SaaS製品は通常、公開されているウェブアプリケーションとしてウェブブラウザ経由でアクセスされます。[32] [17]これは、顧客がアプリケーションをインストールしたりアップデートしたりすることなく、どこからでもどのデバイスからでもアクセスできることを意味します。[17] [33] SaaSプロバイダーは、多くの場合、製品へのサインアップの難易度を最小限に抑えようとします。[34]多くのプロバイダーは、サービス指向の構造を活用して顧客のフィードバックに対応し、需要に合わせて製品を迅速に進化させています。これにより、顧客は製品の継続的な改善を信頼でき、SaaSプロバイダーは、より詳細な機能セットを提供できる可能性のある確立された従来のソフトウェア会社から顧客を獲得するのに役立ちます。[35] [36]

オンプレミスのソフトウェアはSaaSの代替手段よりも安全性が低い場合が多いですが、[37]セキュリティとプライバシーは、SaaS製品を採用しない企業が挙げる主な理由の1つです。[38] SaaS企業は、公開されている製品をサービス拒否攻撃やハッキングなどの悪用から保護する必要があります。 [39]データの機密性を保護するために、アクセス制御、認証、暗号化などの技術をよく使用します。[38]ただし、すべての企業がSaaSプロバイダーが機密データを安全に保持していると信頼しているわけではありません。[38]ベンダーは、セキュリティパッチを含むソフトウェアの更新と、顧客データの保護に責任を負います。[33] SaaSシステムは、ネットワークパケットがクラウド施設に配信されるまでの時間のため、オンプレミスで実行されるソフトウェアよりも本質的に遅延が大きくなります。これは、時間に敏感な産業プロセスや倉庫保管などの一部の用途では法外な場合があります。[40]

SaaS製品の台頭は、多くの企業がIT予算を設備投資から運用費へとシフトする要因の一つとなっている。[41] SaaSへの移行とそのサポートのプロセスも、計上しなければならない大きなコストとなる可能性がある。[42] [31]

発達

SaaSアーキテクチャ。すべての顧客が同じプラットフォーム上で同じバージョンのソフトウェアを実行します。[43]

SaaSプロバイダーにとっての課題は、需要が事前に予測できないことです。システムには、すべてのユーザーを処理できるだけの余裕を持たせ、誰も拒否することなく対応できる一方で、不要なリソースに過剰な費用を支払わないようにする必要があります。リソースが静的であれば、ピーク時以外は確実に無駄になります。[44]負荷分散と無駄の削減のため、オフピーク時にはより安価な料金が提供されることもあります。[45]継続的なサービス提供への期待は非常に高いため、SaaSソフトウェアの停止はニュースで頻繁に報道されます。[46]

SaaS と他の種類のアプリケーション開発を区別する特定のソフトウェア開発手法はありません。 [47] SaaS 製品は、SaaS 配信モデルの柔軟性を活用するために、早期かつ頻繁にリリースされることがよくあります。[48] このリリーススケジュールをサポートするために、アジャイルソフトウェア開発が一般的に使用されています。 [49]多くの SaaS 開発者は、サービスの可用性と迅速な展開を確保する必要があるため、テスト駆動開発を使用したり、頻繁なソフトウェアテストを重視したりしています。 [50]ビジネス目標が開発を推進する ドメイン駆動設計が普及しているのは、SaaS 製品が有用であることで顧客にアピールする必要があるためです。[51] SaaS 開発者は、顧客がデスクトップコンピューター、タブレット、スマートフォンなど、どのデバイスから製品にアクセスしようとするかを事前に把握していないため、フロントエンド開発チームにとって、幅広いデバイスのサポートが重要な懸念事項となることがよくあります。[52] プログレッシブウェブアプリケーションでは、デバイスがオフラインの場合でも一部の機能を利用できます。[53]

SaaSアプリケーションは主に、広域ネットワーク上で動作する統合プロトコルとアプリケーションプログラミングインターフェース（API）を提供します。[54]

建築

SaaSアーキテクチャは製品によって大きく異なります。[55] しかし、ほとんどのSaaSプロバイダーはマルチテナントアーキテクチャを提供しています。[32]このモデルでは、単一の構成（ハードウェア、ネットワーク、オペレーティングシステム）を持つ単一のバージョンのアプリケーションがすべての顧客（「テナント」）に使用されます。[56]これは、企業が複数のバージョンと構成をサポートする必要がないことを意味します。[17]各顧客が独自のハードウェアで独自のバージョンのソフトウェアを実行するというアーキテクチャの変化は、アプリケーションの設計とセキュリティ機能の多くの側面に影響を与えます。[56]マルチテナントアーキテクチャでは、多くのリソースを異なるテナントで使用したり、複数のテナント間で共有したりできます。[57]

SaaS 製品のアプリケーション プレーンとコントロール プレーン

典型的なSaaSアプリケーションの構造は、アプリケーションプレーンとコントロールプレーンに分けることができます。[58] SaaS製品によって、これらのプレーンの分離方法は異なり、イベント駆動型またはメッセージ駆動型モデルで密接に統合されている場合もあれば、疎結合されている場合もあります。[59] コントロールプレーンはシステムの管理を担当し、テナントのオンボーディング、課金、メトリクスなどの機能に加え、SaaSプロバイダーがサービスの設定、管理、運用に使用するシステムもカバーします。[58]多くのSaaS製品は、異なるサービスレベルと異なる価格で提供されており、これをティアリングと呼びます。これは、一般的にコントロールプレーンに配置されますが、両方のプレーンのアーキテクチャにも影響を与える可能性があります。[60]アプリケーションプレーンとは異なり、コントロールプレーンのサービスはマルチテナント用に設計されていません。[61]

一部のサービスは共有され、他のサービスはテナントごとに割り当てられるアーキテクチャの例[62]

アプリケーションプレーンは製品の性質によって大きく異なりますが、SaaS製品のコア機能を実装します。[61]重要な設計上の課題としては、異なるテナントを分離し、他のテナントのデータやリソースを閲覧または変更できないようにすることが挙げられます。[63]最も単純なSaaSアプリケーションを除き、一部のマイクロサービスやその他のリソースは、すべてのテナント間で共有されるのではなく、テナントごとに割り当てられます。[64]テナントのリクエストを適切なサービスに誘導するには、ルーティング機能が必要です。[62]

プレミアム層での完全なサイロ化と他のテナントへの混合マイクロサービス展開を提供するSaaS展開アーキテクチャの例[65]

一部のSaaS製品では、テナント間でリソースを共有しません。これはサイロ化と呼ばれます。これによりSaaSの効率性に関するメリットの多くが打ち消されますが、レガシーソフトウェアをSaaSに移行しやすくなり[66]、場合によってはプレミアムサービスとして高価格で提供されます。[67]すべてのリソースをプールすることで、より高い効率性を実現できる可能性がありますが[68]、停止はすべての顧客に影響を与えるため、可用性をより優先する必要があります。[69]多くのシステムでは、一部のリソースをプールし、他のリソースをサイロ化するという両方のアプローチを組み合わせて使用​​しています。[70]他の企業では、複数のテナントをポッドにグループ化し、それらの間でリソースを共有しています。[71]

米国では、憲法上の捜索令状法は、動的に保存されるSaaSデータ全般を保護するものではありません。その結果、政府はSaaSプロバイダーに対し、所有者の同意なしにデータの提供を要求できる可能性があります。[72] [73]

GPL-2.0などの特定のオープンソースライセンスでは、ドイツではSaaS製品として配布することを許可する権利が明示的に付与されていません。[74]

参考文献

  1. ^ Panker, Jon; Lewis, Mark; Fahey, Evan; Vasquez, Melvin Jafet (2007年8月). 「ITってどう発音するの？」TechTarget . 2016年11月28日時点のオリジナルよりアーカイブ。 2012年5月24日閲覧。
  2. ^ ゴールディング2024、14ページ。
  3. ^ abcd デンプシー & ケリハー 2018、p. 2.
  4. ^ 「Infrastructure as a Service (IaaS) | クラウド情報センター」cic.gsa.gov . 2026年1月19日閲覧。
  5. ^ ロザティ＆リン 2020、22頁。
  6. ^ ロザティ＆リン 2020、23ページより。
  7. ^ イブラヒムら。 2023、p. 258.
  8. ^ デンプシーとケリハー 2018、p. 17.
  9. ^ デンプシー & ケリハー 2018、17–18 ページ。
  10. ^ ab デンプシー & ケリハー 2018、p. 19.
  11. ^ デンプシーとケリハー 2018、p. 33.
  12. ^ ロザティ＆リン 2020、20ページより。
  13. ^ デンプシー & ケリハー 2018、23、31 ページ。
  14. ^ ワット 2023、8ページ。
  15. ^ デンプシーとケリハー、2018 年、24、32 ページ。
  16. ^ デンプシーとケリハー 2018、p. 35.
  17. ^ abcd Watt 2023、4ページ。
  18. ^ ワット2023、4、8頁。
  19. ^ Clohessy et al. 2020, p. 40より。
  20. ^ ワット 2023、9ページ。
  21. ^ abcd デンプシー & ケリハー 2018、p. 48.
  22. ^ Kumar, Vineet (2014年5月1日). 「フリーミアムを成功させる方法」ハーバード・ビジネス・レビュー. ISSN  0017-8012 . 2026年1月19日閲覧。
  23. ^ デンプシー & ケリハー 2018、61–63 ページ。
  24. ^ デンプシー & ケリハー 2018、63–64 ページ。
  25. ^ バンダリ＆グプタ 2019、p. 21.
  26. ^ デンプシーとケリハー、2018 年、48、57 ページ。
  27. ^ Clohessy et al. 2020, 40–41頁。
  28. ^ ab デンプシー & ケリハー 2018、p. 57.
  29. ^ デンプシー & ケリハー 2018、57–58 ページ。
  30. ^ デンプシーとケリハー 2018、p. 11.
  31. ^ ab デンプシー & ケリハー 2018、p. 66.
  32. ^ ab Garbis & Chapman 2021、p. 185.
  33. ^ ab Kinnunen 2022、123–124 ページ。
  34. ^ ゴールディング2024、18ページ。
  35. ^ ゴールディング2024、20ページ。
  36. ^ ワット2023、15ページ。
  37. ^ ワット2023、6、16頁。
  38. ^ abc イブラヒム他 2023, pp.264, 266, 268.
  39. ^ ガービス＆チャップマン 2021、186頁。
  40. ^ 金年 2022, pp. 137, 139.
  41. ^ タロン他 2020年、2頁。
  42. ^ キンヌネン2022、124頁。
  43. ^ ゴールディング2024、25ページ。
  44. ^ デンプシーとケリハー 2018、p. 36.
  45. ^ デンプシーとケリハー 2018、p. 37.
  46. ^ デンプシーとケリハー 2018、p. 39.
  47. ^ ワット 2023、11ページ。
  48. ^ ワット2023、16ページ。
  49. ^ Younasら2018年、142頁。
  50. ^ ワット2023、11～12頁、16頁。
  51. ^ ワット 2023、12ページ。
  52. ^ ワット2023、13～14頁。
  53. ^ ワット 2023、13ページ。
  54. ^ マンヴィ＆シャム 2021、105頁。
  55. ^ ゴールディング2024、47ページ。
  56. ^ ゴールドイング2024、25～26頁。
  57. ^ ゴールディング2024、26ページ。
  58. ^ ゴールディング2024、27ページ。
  59. ^ ゴールディング2024、44ページ。
  60. ^ ゴールディング2024、40ページ。
  61. ^ ゴールディング2024、28ページ。
  62. ^ ゴールディング2024、38ページ。
  63. ^ ゴールディング2024、36-37頁。
  64. ^ ゴールディング2024、37ページ。
  65. ^ ゴールディング2024、76ページ。
  66. ^ ゴールディング2024、55ページ。
  67. ^ ゴールディング2024、55、74-75頁。
  68. ^ ゴールディング2024、69ページ。
  69. ^ ゴールディング2024、70ページ。
  70. ^ ゴールディング2024、75-76頁。
  71. ^ ゴールディング2024、78ページ。
  72. ^ Arthur, Charles (2010年12月14日). 「GoogleのChromeOSはデータの制御を失うことを意味する、とGNU創設者リチャード・ストールマンは警告」. The Guardian . UK . オリジナルより2014年2月28日アーカイブ. 2012年2月16日閲覧。
  73. ^ Adhikari, Richard (2010年12月15日). 「なぜリチャード・ストールマンはChromeに輝きを示さないのか」. Linux Insider . 2021年1月23日時点のオリジナルよりアーカイブ。 2015年3月24日閲覧。
  74. ^ ボールハウゼン 2014、61ページ。

出典

  • Ballhausen, Miriam (2014). 「OpenSaaS：フリー・オープンソース・ソフトウェアをSaaS（Software-as-a-Service）として利用する」. International Free and Open Source Software Law Review . 6 : 61–68 . ISSN  2666-8106.
  • バンダリ、グル・プラサド、グプタ、ラトネシュワー (2019).「クラウドおよびエッジコンピューティングアーキテクチャの概要と現状の課題」消費者中心のフォグコンピューティングアーキテクチャの推進. IGI Global. pp.  1– 37. ISBN 978-1-5225-7149-0。
  • デンプシー、デイビッド、ケリーハー、フェリシティ（2018年）『クラウドコンピューティングの業界動向：B2B収益モデルの代替』 Springer International Publishing. ISBN 978-3-319-87693-1。
  • ガービス、ジェイソン、チャップマン、ジェリー・W. (2021). 『ゼロトラスト・セキュリティ：エンタープライズガイド』Apress. ISBN 978-1-4842-6703-5。
  • Golding, Tod (2024).マルチテナントSaaSアーキテクチャの構築. O'Reilly Media. ISBN 978-1-0981-4061-8。
  • イブラヒム、アハメド・マムドゥフ・アブデルファタ、アブドラ、ノリス・サイード、バハリ、マハディ (2023).サービスとしてのソフトウェアの課題：体系的な文献レビュー. シュプリンガー・インターナショナル・パブリッシング. pp.  257– 272. ISBN 978-3-031-18344-7。
  • Kinnunen, Juha (2022). 『ERPをサービス型ソフトウェアとして：大企業におけるクラウド導入の要因』 Springer International Publishing. pp.  123– 142. ISBN 978-3-030-99191-3。
  • リン、テオ、ムーニー、ジョン・G、ロザティ、ピエランジェロ、フォックス、グレース（2020年）。クラウドコンピューティングのビジネス価値の測定。シュプリンガー・ネイチャー。ISBN 978-3-030-43198-3。
    • ポール・P・タロン、ジョン・G・ムーニー、マーヴィン・ダデック（2020年）「ITのビジネス価値の測定」クラウドコンピューティングのビジネス価値の測定、Springer International Publishing、pp.  1-17、ISBN 978-3-030-43198-3。
    • Rosati, Pierangelo; Lynn, Theo (2020). 「クラウドへのインフラ移行のビジネス価値の測定」.クラウドコンピューティングのビジネス価値の測定. Springer International Publishing. pp.  19– 37. ISBN 978-3-030-43198-3。
    • Clohessy, Trevor; Acton, Thomas; Morgan, Lorraine (2020). 「SaaSのメリット：SaaS技術のプロビジョニングによるビジネス価値の測定」.クラウドコンピューティングのビジネス価値の測定. Springer International Publishing. pp.  39– 55. ISBN 978-3-030-43198-3。
  • マンヴィ、スニルクマール、シャム、ゴパル（2021年）『クラウドコンピューティング：概念と技術』CRCプレス、105ページ。ISBN 9781000337952。
  • Watt, Andy (2023). 『C#と.NETによる最新のSaaSアプリケーションの構築：プロフェッショナルなSaaSアプリケーションの構築、展開、保守』 Packt. ISBN 978-1-80461-087-9。
  • Younas, Muhammad; Jawawi, Dayang NA; Ghani, Imran; Fries, Terrence; Kazmi, Rafaqut (2018). 「クラウドコンピューティング環境におけるアジャイル開発：体系的レビュー」情報ソフトウェア技術103 : 142–158 . doi : 10.1016 /j.infsof.2018.06.014. ISSN  0950-5849.

さらに読む

  • フォックス、アルマンド、パターソン、デビッド・A. (2020). 『サービスとしてのソフトウェアのエンジニアリング：クラウドコンピューティングを活用したアジャイルアプローチ』 Pogo Press. ISBN 978-1-7352338-0-2。
「https://en.wikipedia.org/w/index.php?title=Software_as_a_service&oldid=1333984008」より取得