# SaaSus Platform > SaaS事業をワンストップで支援するSaaS開発プラットフォーム「SaaSus Platform」のマーケティングサイト。認証・課金・テナント管理等、SaaS共通基盤に関する技術記事や資料を公開しています。 --- # Blog articles --- ## 【導入事例】株式会社日立製作所 URL: https://saasus.io/blog/hitachi Date: 2026-07-03 鉄道DXの変革と、SaaS事業への戦略的転換 株式会社日立製作所（以下、日立製作所）の社会システム事業部が推進する「駅業務アプリケーションスイート」は、駅業務の多様化、多言語案内の増加、ベテラン社員の退職による知識継承の難しさといった、鉄道現場の深刻な課題を解決するためのサービスです。 日立製作所にとって重要な柱である従来の受託開発（SI）ビジネスを大切にしながら、さらなる成長を目指してリカーリング（循環型）ビジネスを新たに追加していくという大きな挑戦について伺いました。本インタビューでは、今回の事業を統括する肥田さんと、プロジェクトマネージャー（PM）として現場を指揮した向井さんを中心に、同席したプロジェクトメンバーの皆様にもお話を伺いました。 ー今回のプロジェクトが立ち上がった背景を教えてください。 肥田さん：鉄道業界においても、駅係員などのフロントラインワーカーに向けてスマートデバイスを活用した業務改善が進んでいます。しかし、現場には依然としてアナログな運用が根強く残っており、DX化の大きな課題となっている中、私たちはこれまで以上に現場に寄り添う必要がありました。 鉄道の駅業務という領域では、従来の競合とは異なる機動力のあるソフトウェアベンダーと競合することになります。一社ごとに一から構築する従来のSI手法では、スピードやコストで到底太刀打ちできません。ビジネスのやり方そのものを変えなければ、この領域全体が駆逐されてしまう。だからこそ、サービスプラットフォーマーとして複数の鉄道事業者をつなぐ”ハブ”になることを目指し、ビジネススタイルへの転換は必須だったのです。 ー社内で前例の少ないSaaS事業を推進するのは、容易ではなかったのではないでしょうか？ 肥田さん：確かに先行投資案件であり、社内の承認を得るのには苦労がありました。私は事業を実らせるには相応の覚悟と投資が必要だと理解していたため、あえて『強気』で貫き通しました。 その際、単に数字を積むだけでなく、関わる全員にとって意味のある巻き込み方を意識しました。会社にとっては「SIに続く新たな成長の柱」になり、顧客にとっては「継続的な業務改善とTCO削減」をもたらし、そして開発メンバーに対しては「これをやれば社会価値を直接創出できる」という、それぞれのステークホルダーにとっての価値を丁寧に整理したのです。最後は一対一の対話です。熱量を直接伝え、皆がこのプロジェクトに楽しさや貢献を感じられる構造を作ることが、結果として大きな組織を動かす力になったと感じています。 未踏の「スーパーアプリ構想」に挑むマルチベンダー体制とSaaSusの役割 プロジェクトが目指したのは、一つの親アプリの中に複数の業務ミニアプリを搭載する「スーパーアプリとミニアプリの構造」を持ったSaaS基盤でした。しかし、日立製作所内にもこの構造を構築したノウハウは限られており、開発は困難を極めることが予想されました。 ー複数のパートナー企業が関わるマルチベンダー体制かつアジャイル開発という難易度の高い環境で、PMとしてどのような工夫をされましたか？ 向井さん：私は以前、お客様の要望を叶えるための開発業務に携わっていましたが、もっと主体的に現場の課題を解決したいと考え、肥田のチームに加わりました。今回のプロジェクトは、仕様が定まりきっていない状態からアジャイルで進めるという、私にとっても非常にチャレンジングなものでした。 開発対象はスーパーアプリ、ミニアプリ、配信基盤、さらにSaaSus Platformとの連携と多岐にわたり、かつ専門性の異なるパートナー3社と同時に進める必要がありました。そこで私がPMとして最も重視したのは『個別最適ではなく全体最適』です。各チームの進捗管理だけでなく、『この判断が他のコンポーネントや将来の展開にどう影響するか』を常に問いかけました。毎週、全員で膝を突き合わせて共通認識を持つ時間を設けることで、役割の垣根を超えた『ワンチーム』として機能させることができたのです。 ーSaaS基盤の専門パートナーとして、SaaSus Platform（アンチパターン社）を選定した決め手は何だったのでしょうか？ 肥田さん：SaaSus Platformに類似したサービスが国内になかったこともありますが、何よりアンチパターン社の『SaaSのあるべき姿』というコンセプトに共感したことが最大の理由です。 アンチパターン社は単なるツール提供者ではなく、AWSの豊富な知見を活かして、日立が目指すSaaS事業を「共に形にする」という強い熱量を持っていました。日立にとってより良くなるような調整を粘り強く行い、我々と伴走してくれる姿勢があったからこそ、この不確実性の高いプロジェクトを預けられると確信し、彼らの熱い思いが私たちの背中を押してくれました。 向井さん：実務面では、認証、テナント管理、環境分離といったSaaS共通の基盤機能をSaaSus Platformに任せられたことが非常に大きかったです。これらを自前で設計・開発・試験するとなれば、膨大な時間がかかっていたでしょう。そのリソースを『駅業務そのもの』のロジックやユーザー価値に直結する領域へ集中できたことが、スピード感のある開発に繋がりました。 また、SaaSとして『汎用化』することと、初期のお客様の『個別ニーズ』に応えることのバランスにも腐心しました。肥田からの『共通化できる部分を明確に切り分けるべき』というアドバイスや、アンチパターン社からの実績ベースのアドバイスを受けることで、初期段階から拡張性の高い構成を採用することができました。 開発リソースの集中が生んだ価値と、社会インフラを支える今後のビジョン プロジェクトには、研究開発部門の藤平さんをはじめ、入社1年未満のフレッシュなエンジニアである上田さん、福嶋さん、松村さんらが参画しました。SaaS開発を通じて得た学びについて、それぞれに伺いました。 ープロジェクトを通じて、チーム全体でどのような変化や成果を感じていますか？ 藤平さん：私は約1年前に研究所からこのプロジェクトに合流しました。当初は仕様整理や開発体制の整備が十分ではなく、非常にタフな状況でしたが、共通化すべき領域を整理し、後から参加するメンバーがスムーズに参画できる基盤づくりに注力しました。その結果、若手メンバーへの引き継ぎも円滑に進められるようになったと感じています。 上田さん：私はこれまでSaaSを利用する側でしたが、作る側に回って初めてその難しさと奥深さを知りました。アンチパターン社の方々と議論しながら、自分たちでいかにSaaS化していくかを悩むプロセスは、エンジニアとして非常に貴重な経験になりました。 福嶋さん：インフラエンジニア出身の私にとって、SaaS開発は最初は『遠い世界』のように感じていました。しかし、SaaSus Platformを軸にすることで、テナント管理やAWS構成との連携が明確になり、自信を持ってプロジェクトに貢献できるようになりました。今後はさらに共通テーマのコミュニケーションを増やしていきたいです。 松村さん：前職では開発パートナーに近い立場でしたが、今回のように日立の新しい指標となるような革新的なプロジェクトにアジャイルで参加できていることに、今、凄くワクワクしています。 ー今後の展望と、このプロジェクトが日立製作所のビジネスに与えるインパクトについて教えてください。 向井さん：今後は技術的な効果にとどまらず、プロダクトを起点とした『営業レス販売』を実現したいと考えています。お客様が使いたいと思った時に自ら購入し、すぐに使い始められる仕組みを構築することで、フロントSEの不足という課題を解決し、販売力を爆発的に強化できると期待しています。 肥田さん：駅業務アプリケーションスイートは、司令員や駅係員、乗務員など、鉄道に関わるあらゆる現場の声を聞きながら進化し続けます。そしてこの成功モデルを、鉄道業界に留まらず、電力、航空、公共、産業分野など、日立が持つ広範なネットワークを活かして横展開していきたいです。 私たちはまだスタートラインに立ったばかりです。今後は本質的な汎用化と、新しいビジネス手法への挑戦がさらに重要になります。SaaSus Platformという心強いパートナーと共に、会社や業界の枠を超えて、世の中を良くする仕組みの『ベースライン』を創り上げていきたいと考えています。 --- ## SaaS開発の落とし穴 〜監視・ログ設計編〜 URL: https://saasus.io/blog/saas-development-issues-monitoring-and-logging Date: 2026-07-03 はじめに：見落とされがちな監視・ログ設計 「特定の顧客だけが遅い」「データが消えたので誰がやったか調べてほしい」。SaaSの運用が始まると、こうした問い合わせにエンジニアが追われがちです。 その多くは、オンプレミスや単一環境で通用していた「標準的なログ出力」を、マルチテナント前提のSaaSにそのまま持ち込んでしまうことが原因です。全顧客の挙動が混ざり合う環境では、ログやメトリクスに「どの顧客のものか」が紐づいていないと、状況把握そのものが難しくなります。 本記事では、監視・ログ設計の「落とし穴」と対策を見ていきましょう。 ① 「見えなくなる」マルチテナント監視 複数の顧客がリソースを共有するSaaSでは、「インフラが健全なら、アプリケーションも正常に動いているはず」という考え方が通用しません。 サーバーのCPUやメモリに余裕があっても、特定のテナントだけが遅延に悩まされていることは珍しくありません。全体の平均レスポンスタイムが100msでも、一部の顧客だけが5秒待たされている、という状況は「平均値」に隠れてしまうからです。 さらにSaaS特有の問題として、ノイジーネイバー（騒がしい隣人）問題があります。特定テナントの大量処理やバーストアクセスが、同じ基盤を共有する他テナントのパフォーマンスを下げてしまう現象です。 対策 システムの健康状態を顧客単位で把握するために、次の2つを設計に組み込みます。 テナントIDの付与 : メトリクスやログに「どのテナントか」を紐づけ、監視の死角をなくす テナント別のリソース計測 : 消費量をテナントごとに切り出し、暴走した「隣人」に制限（スロットリング）をかけられるようにする ② 障害調査で苦労しないためのログ設計 開発中は「デバッグに役立つから」と多くのログを流しがちですが、本番では複数テナントから大量のリクエストが押し寄せます。意味の薄いログが混ざると、障害時に必要な情報を探し出せなくなります。 特に問題になりやすいのは、次のようなログです。 スタックトレースだけで、「どのテナントの、どのユーザーか」が分からない プレーンテキストで、サービスをまたいだ挙動を追えない エンジニアしか読めず、CSや顧客が自分で確認できない 対策 調査を効率化する鍵は、ログの構造化とトレースIDです。 構造化ログ (JSON形式) : 「TenantID = 'A社' かつ Severity = 'Error'」といったフィルタリングを瞬時に行える トレースID : 一連の挙動をフロントエンドからDBまで「一本の線」として追跡できる あわせて、CSや顧客自身でも確認できるように可視化しておくと、調査依頼のたびに開発が止まる事態を避けられます。 ③ 事業継続を左右する監査ログ 区別しておきたいのが、不具合を直すためのデバッグ用ログと、サービスの正当性を示す監査ログ（操作ログ）の違いです。監査ログには、次の情報を改ざんできない形で記録する必要があります。 いつ : タイムスタンプ 誰が : ユーザーID どのテナントで : テナントID どのデータに : リソース名 何をしたか : アクション 特に金融・医療・公共などの分野では、コンプライアンス要件として次のような対応を求められることが珍しくありません。 SOC2などの外部認証の取得 操作ログの長期保存（1年〜数年） 特定テナントのログだけを抽出・出力できること リリース後に「過去3ヶ月分の全操作ログを提出してほしい」と求められ、デバッグ用の不完全なログしか残っていない、という事態は避けたいところです。 対策 監査ログは、アプリケーションを作り始める前から設計に含めておきましょう。記録項目（いつ・誰が・どのテナントで・どのデータに・何を）に加えて、改ざん防止・長期保存・テナント別の抽出まで見据えておくことが大切です。 「権限設定を変更した履歴をすぐ出力できるか」「そのログが特権管理者にも消されないか」といった問いに、仕組みとして答えられる状態を目指します。 ④ すべてを自前で抱える負担 これらの課題をすべて自力で解決しようとすると、共通基盤の構築にプロダクト本体と同じくらいの工数が必要になります。限られた開発リソースを基盤づくりに費やすことは、市場への参入を遅らせる要因にもなります。 対策 そこで検討したいのが、SaaS開発に特化したプラットフォームの活用です。例えば SaaSus Platform は、認証情報と「どのテナントに属するか」を紐づけて管理するため、テナントIDやユーザー属性をログに付与しやすくなります。ログの役割は次のように分かれます。 基盤側の操作ログ : ログイン、パスワード変更、テナント情報の変更など。SaaSus Platform が標準で自動収集します。 アプリケーション固有のログ : 文書の削除やデータのエクスポートなど。アプリケーション側で出力しますが、SaaSus Platform がテナントID・ユーザーコンテキストを管理するため、紐付けをゼロから設計せずに済みます。 収集したログは管理画面から検索・出力できるため、「CSからの調査依頼」や「顧客へのログ提供」を、エンジニアの手を介さずに完結させることもできます。 まとめ 監視・ログ設計は事後確認の手段にとどまらず、顧客の信頼を守り、サービスの品質を支える事業の土台です。マルチテナントを前提とした監視・ログ設計には、次のような落とし穴があります。 テナントIDが欠落した「見えない」監視 障害調査で苦労するログ設計 事業継続を左右する監査ログの不足 共通基盤をすべて自前で抱える負担 開発の早い段階でこれらに備え、必要に応じて SaaSus Platform のような外部基盤も活用しながら、メトリクスからアプリケーションログ、監査ログまでを顧客単位で把握できる体制を整えていきましょう。 --- ## SaaS開発の落とし穴 〜課金・請求編〜 URL: https://saasus.io/blog/saas-development-issues-billing Date: 2026-07-02 はじめに：課金・請求という落とし穴 Software as a Service (SaaS) の開発では、まず「顧客に提供するコア価値」の磨き込みに力を注ぎたいものです。 一方で、意外なほどリソースを奪われやすく、あとから成長の足かせになりやすい領域があります。それが課金・請求システムです。 「決済APIを叩くだけなら簡単だ」と思われがちですが、SaaSの継続課金モデルには特有の複雑さがあります。 本記事を通して、これからSaaSを構築する際に陥りやすい課金・請求まわりの「落とし穴」と、その対策について見ていきましょう。 ① 「決済ができる」と「ビジネスを運用できる」は別物 優れた決済APIの登場で、カード決済の組み込み自体はとても容易になりました。 しかし、SaaSのような継続課金モデルでは、「決済ができる」ことと「健全にビジネスを運用できる」ことのあいだには、思った以上の距離があります。 単発の決済と異なり、サブスクリプションでは契約の状態（ステート）を管理し続ける必要があります。例えば、 トライアル : 無料でお試し中の状態 有効 : 料金を支払い、正常に利用できている状態 支払い遅延 : 決済に失敗し、支払いを待っている状態 解約 : 利用を終了した状態 といった状態です。 カードの有効期限切れによる決済失敗時のリトライや、一時停止といった例外的な状態も、自前のDBで管理しつつ決済プラットフォーム側と常に同期をとる必要があります。これは単なるAPI連携にとどまらない、丁寧な設計が求められる部分です。 対策 まずは、契約の状態管理を設計の中心に据えることが大切です。 決済プラットフォーム側で起きたイベント（決済の成功・失敗、解約など）を受け取り、自社側の状態と同期する仕組みを、はじめから用意しておきましょう。 状態遷移を明確に定義しておくことで、例外的なケースにも落ち着いて対応できるようになります。 ② 日割り計算とプラン変更の複雑さ ビジネスが成長すると、月の途中でのプラン変更が必ず発生します。 このとき登場するのが日割り計算です。次のような要素を考慮する必要があり、実装は思いのほか複雑になります。 日数による按分 : 月の日数に応じて金額を割り戻す 消費税の端数処理 : 端数をどのように丸めるか 決済のタイミング : 即時決済か、次回請求への合算か これらのビジネス要件をコードに直接書き込んでしまうと、プラン体系を変更するたびに複雑な条件分岐と向き合うことになり、開発のスピードが落ちてしまいます。 対策 日割りやプラン変更のルールは、できるだけコードから切り離して扱えるようにしておきましょう。 プランの定義や価格のルールをデータとして持ち、ロジック側はそれを参照するだけにしておくと、料金体系の変更にも柔軟に対応できるようになります。 ③ 課金ロジックの密結合という負債 開発初期はスピードを優先し、アプリケーションのコアロジックの中に課金・請求の判定処理をそのまま書き込んでしまうことがあります。この状態を、ここでは密結合と呼びます。 一見すると手早く見えますが、SaaSが成長していく段階で足かせになりやすい部分です。 例えば「この機能はプロプラン限定」といった認可ロジックがソースコードの各所に散らばっていると、プラン体系を増やすたびに広い範囲の修正が必要になります。 また、「初月無料」や「特定条件での割引」といったマーケティング施策のたびにエンジニアの工数がかかり、ビジネスサイドの意思決定スピードにも影響してしまいます。 対策 ここで有効なのが、課金・請求の仕組みをプロダクトの「外側」に切り出すという考え方です。 システム全体を俯瞰して制御するコントロールプレーンという発想で、アーキテクチャを次のように分けて考えてみましょう。 データプレーン : ユーザーに直接価値を提供する、プロダクトのコア機能を担う領域 コントロールプレーン : 契約や課金・請求を司る、制御のための領域 この境界線を引くことで、コア機能の開発チームはビジネスロジックの変更に振り回されず、ユーザー体験の向上に集中できるようになります。 また、自社で作るか外部サービスを使うかを判断するときは、「その開発が競合に対する差別化要因になるか」を基準にするとよいでしょう。精緻な日割り計算や請求書の発行そのものが、顧客に選ばれる理由になることは多くありません。こうした機能は、自分たちにしか作れない価値へリソースを回すためにも、うまく力を抜きたい部分です。 ④ 「のりしろ」を自社で抱え続けるコスト コントロールプレーンを実現する方法は、大きく分けて二つあります。 内製アプローチ : 自作、または Stripe などの汎用決済プラットフォームを自社で組み込む 専用プラットフォームの活用 : SaaSに特化した基盤を利用する 汎用の決済プラットフォームは、決済処理そのものにはとても強力です。 一方で、自社プロダクトの「テナント（企業）」という概念と、決済側の「顧客情報」を紐付ける部分は、自社で実装する必要があります。この橋渡しの実装を、ここではのりしろ（Glue Code）と呼びます。 プラン変更に伴う日割り計算や、テナントごとの権限管理といったSaaS特有のロジックを、こののりしろとしてメンテナンスし続ける工数は、意外と無視できません。 対策 もう一つの選択肢として、汎用決済プラットフォームとプロダクトの間に立ち、SaaSに必要な機能をまとめて提供してくれる専用基盤を活用する方法があります。 例えば SaaSus Platform のようなサービスは、決済プラットフォームと連携しながら、この「のりしろ」の部分をパッケージとして提供します。 料金プランの定義を管理画面側に切り出せるため、アプリケーション側の実装は「API経由で利用可否を確認する」というシンプルな形にまとまります。その結果、ビジネスモデルの変更がソースコードに波及する範囲を小さく抑えられ、汎用プラットフォームを直接扱うよりも疎結合な設計を実現できます。 さらに、テナント情報と請求データが最初から紐付いて管理されていれば、データを手作業で照合したり、不具合調査のたびに場当たり的なSQLを書いたりする手間も減らせます。こうした地道な作業から解放されることは、結果として開発体験 (DX) の向上にもつながります。 まとめ SaaS開発の成功は、差別化につながらない部分をいかに上手に手放し、コア価値に集中できるかにかかっています。課金・請求システムはビジネスに欠かせないものですが、それ自体が顧客に選ばれる理由になることは多くありません。 本記事で見てきたように、課金・請求まわりには、 継続課金ならではのステート管理 日割り計算やプラン変更の複雑さ 課金ロジックの密結合という負債 「のりしろ」実装の運用コスト といった落とし穴があります。 これらに対しては、コントロールプレーンという発想で、早めに課金基盤をコアロジックから切り離しておくことが、将来のスケールに向けた着実な準備になります。 すべてを自前で抱え込む前に、SaaSus Platform のような専用プラットフォームも含めて、最適な手段を検討してみてはいかがでしょうか。 本記事が、皆様のSaaS開発において、課金・請求とうまく付き合っていくための一助となれば幸いです。 --- ## SaaS開発を支える「IaC」入門 URL: https://saasus.io/blog/introduction-to-iac-for-saas-development Date: 2026-06-29 はじめに SaaSを開発や運用していくと、開発環境や本番環境など、複数のインフラ環境を管理する場面が出てきます。 これらの環境を画面から手作業で構築していると、設定ミスや環境間の差分が生まれやすくなります。 本記事では、こうした課題を解決する Infrastructure as Code (IaC) について入門していきましょう。 IaCとは IaCとは、サーバーやデータベースといったインフラのリソースを、コードとして定義し作成する手法です。 画面をクリックして構築する代わりに、コードでインフラの構成を記述します。 インフラをコードで扱えるため、アプリケーションのソースコードと同じようにGitで管理できます。 AWSでは、代表的なIaCツールとして次の3つがあります。 CloudFormation：AWSが提供するサービス。YAMLやJSONでAWSリソースを定義でき、人間でも読みやすい CDK：AWSが提供する、CloudFormationをプログラミング言語で扱えるようにしたツール。TypeScriptやPythonなどが使える Terraform：HashiCorp社が開発したIaCツール。独自の記法を持ち、AWS以外の多くのサービスも扱える IaCを試してみる TerraformやCDKは事前にCLIなどのツールが必要になりますが、CloudFormationはセットアップなしで使えます。 ここでは、CloudFormationでS3バケットを作成するサンプルを見てみましょう。 Resources:   MyBucket:     Type: AWS::S3::Bucket     Properties:       BucketName: my-sample-bucket-20260629 このコードを記述したファイルを、AWSマネジメントコンソールの画面からアップロードするだけでS3バケットが作成されます。 CLIからも aws cloudformation deploy コマンドで同じことが実行できます。 IaCのメリット IaCを導入すると、次のような恩恵を受けられます。 同じ環境をすぐに作れる 開発環境、ステージング環境、本番環境を、同じコードから簡単に再現できます。 そのため、「ステージング環境と本番環境に差分があってテストの意味がなくなる」といった事態を防げます。 この恩恵は、テナントごとにインフラリソースを必要とするサイロ型のマルチテナントSaaSでも大きな力を発揮します。 サイロ型では、新しいテナントが増えるたびに同じインフラ一式を用意する必要があります。これを手作業で行うとミスが起きやすく、SaaSのスケールを阻害します。 IaCでインフラをテンプレート化しておけば、こうしたテナントオンボーディングを自動化できます。興味のある方は、テナントオンボーディングについての記事もあわせてご覧ください。 Gitで管理できる インフラも、アプリケーションと同じように逐次改善していくものです。 障害が起きたときに以前のバージョンへすぐ戻せるうえ、デプロイ前にレビューを挟めます。 CI/CDに組み込める PRをマージしたら自動でデプロイする、といったワークフローを構築できます。 上のGit管理と合わせると、GitHubなどのリポジトリでインフラのコードを扱えるようになります。例えばGitHubであれば、PRのマージをきっかけにGitHub Actionsからデプロイを実行できます。 デプロイ前に問題を検知できる 例えばCDKにはcdk-nagというツールがあり、構成がベストプラクティスに則っているかを自動で判定します。 近年はAIでIaCを生成する場面が増えていますが、こうしたスキャンは一つの安心材料になります。 まとめ IaCを使うと、インフラをコードとして定義し、再現性のある形で管理できます。 環境差分の防止、Gitによるバージョン管理、CI/CDへの組み込み、デプロイ前の問題検知など、SaaS開発を支える多くのメリットがあります。 まずはCloudFormationで小さなリソースを作るところから始めてみましょう。 --- ## 【導入事例】DigKnow株式会社 URL: https://saasus.io/blog/digknow Date: 2026-06-19 独自ロジックで挑む、AIコーディング時代の「仕様ブラックボックス化」という深い課題 伊藤 悠一 様  （代表取締役/CEO） 近年、生成AIの普及でコード生成が身近になった一方、開発現場では設計意図や仕様が属人化する「仕様のブラックボックス化」が深刻な課題となっています。この課題を構造的に解決すべく、2025年10月に設立されたのがDigKnow株式会社です。 同社は、長年ITエンジニアとして現場に携わってきたメンバーの経験をもとに、技術ドキュメント自動生成・追従サービス「Codeledge（コードレッジ）」を展開しています。 ▶ Codeledgeの詳細を見る ：https://codeledge.co/ ーまずは、貴社の事業内容やサービス「Codeledge」について詳しく教えてください。 伊藤さん（代表取締役/CEO）：  Codeledgeは、GitHubなどのソースコードリポジトリを連携するだけで、AIがコードを自動的に解析し、概要仕様書や詳細仕様書、フローチャート、シーケンス図といった技術ドキュメントを生成するサービスです 。最大の特徴は、リポジトリが更新されるとドキュメントも自動で最新の状態に追従し続ける点にあります 。現在はSaaSモデルのβ版をローンチしており、エンタープライズモデルの契約も随時受け付けています。 ー なぜ、このサービスを受託開発などではなく「SaaS」として展開しようと考えられたのでしょうか。 伊藤さん：  私たちが解決しようとしている『ドキュメントが整備されない、あるいは作ってもすぐに陳腐化してしまう』という問題は、特定の業界や企業規模に閉じたものではありません 。ソースコードを扱うすべての開発組織が抱えている普遍的な課題です 。だからこそ、特定のお客様向けの受託開発に留めるのではなく、広くアクセスできるSaaSとして提供することで、より多くの開発現場の生産性を底上げしたいと考えました。 コードは残るが、仕様は誰も知らないといった、属人化や技術的負債の蓄積、引き継ぎコストの増大は、AIコーディング時代においてむしろ加速しています。Codeledgeは、コードという最も信頼できる一次情報からドキュメントを生成し続けることで、この課題を構造的に解決し、開発現場の生産性と品質を同時に引き上げることを目指しています 。 ただ一方で、Codeledgeをできるだけ早く市場に投入するためには、大きな課題もありました。 それは、アプリケーションとしてのコアロジック開発と、それを広く届けるためのSaaS化の基盤構築をいかに両立させるか、というリソースの配分問題でした。 希少な「時間と集中力」の投資先──SaaS共通基盤を任せる「事業のパートナー」としての選択 桑原 脩 様 （CTO） CodeledgeのSaaS化を進める中で、当社は開発体制やリソース配分について重要な判断を迫られていました。特に立ち上げ期のスタートアップにとっては、開発に使える時間やエンジニアリソースが限られています。そのため、Codeledgeをできるだけ早く市場に届けることを前提に、どこに開発工数を集中させるべきかを慎重に検討していました。 ーSaaS化にあたって、技術的に自力で開発すると工数がかかると懸念していた機能や、当時のイメージはどのようなものでしたか？ 桑原さん（CTO）：  マルチテナント対応や課金基盤を自前で実装しようとすると、我々のコアである解析エンジンの開発リソースが削られてしまうという懸念がありました。具体的には、テナント、ユーザー、ロールといった3種類の情報を整合的に扱う管理機能やWebコンソール、さらには料金プランの定義やStripeなどの決済機能との連携部分です 。元々、SaaS開発はアプリケーションそのものを作るだけでなく、マルチテナント環境を安全かつ安定的に運用するための基盤づくりに大きな工数がかかるという認識がありました。 社内で、限られた開発リソースをどこに集中させるべきかを徹底的に検討した結果、自社での共通基盤開発をスキップし、外部の認証・マルチテナントSaaS基盤を活用する方針を選択しました。 その検討を進める中で、2025年開催の技術カンファレンス「Developers Summit 2025 Summer」で「SaaSus Platform」と出会いました。当時はまだ資金調達の直前フェーズであったため、すぐに実装へと移ることはできませんでしたが、調達完了後の本格的な開発スタートを見据え、水面下で最適な選択肢としての検証を進めていきました。 ー市場にある他の基盤サービスと比較して、最終的にSaaSus Platformを選んだ「決め手」は何だったのでしょうか。 伊藤さん：  単なるプロダクトとしての機能の充実度だけでなく、運営元であるアンチパターン社様が、実際のSaaS開発や運用に関する知見をしっかり持たれていた点が大きかったです。単に機能を提供するサービスというより、“SaaSを運営していく上で必要な考え方やノウハウも含めて相談できる存在”だと感じました。そうした部分も含めて、長期的に信頼できると感じたことが導入の決め手になりました。 開発期間を1ヶ月短縮し「正確性」へ集中、目指すはエンタープライズ領域への拡張 川井 郷史 様 （COO） 伊藤さん： SaaSus Platformを導入したことで、当社ではSaaS運営に必要な共通基盤の開発負担を大きく削減することができました。 初めて扱う基盤サービスだったため、導入初期には仕様確認などで試行錯誤する場面もありましたが 、メールやショートミーティングを通じた柔軟なサポートもあり、大きく開発が止まることはありませんでした。 ーSaaSus Platformの導入によって、本来自分たちで作らなければならなかった機能をどれくらいスキップでき、どの程度のリリース期間短縮に繋がりましたか？ 桑原さん：  テナント・ユーザー・ロール管理の画面や認証フロー、料金プラン管理、Stripe連携を含む請求処理など、SaaS運営に必要な共通機能を大幅に 任せることができました。管理コンソール周りまで含めて自前開発の範囲を減らせたので、開発負荷はかなり軽くなったと思います。実際、リリースまでの期間も約1ヶ月は短縮できた実感があります。 また、マルチテナント運用や課金基盤についても、こちらの運用イメージに合わせて柔軟に相談できたので、不安なく進めることができました。工数削減ももちろん大きかったのですが、それ以上に良かったのは、開発チームが“どこに集中するか”を明確にできたことです。導入前は、共通機能の設計・実装と、Codeledge独自のコアロジック開発を並行して進める想定でした。ただ、SaaSus Platformを導入したことで、共通基盤側の負担をかなり減らせたので、その分、私たちはCodeledgeならではの機能改善に集中できるようになりました。   伊藤さん：  最近は、AIにそのまま解析を任せるような類似サービスも増えてきていますが、私たちは“ドキュメントとしてどれだけ正確か”をかなり重視しています。そのため、CodeledgeではAIだけに依存するのではなく、ルールベースの解析ロジックも組み合わせながら、コード構造の変化を正確に捉えられるようにしています。こうしたコア部分の改善や精度向上に集中できたのは、SaaSus Platformで認証やマルチテナント管理などの共通基盤を支えてもらえていたことが大きかったと思います。   ー 今回SaaSモデルを無事にローンチされたことで、今後はどのようにサービスを成長させていきたいですか。今後の展望をお聞かせください。 川井さん（COO）：  これまでは、一部のお客様向けにサービスを提供していました。今回SaaSとして提供できる基盤が整ったことで、今後はより多くの開発組織に使っていただけるサービスにしていきたいと考えています。 具体的には、対応言語や生成できるドキュメント種別を増やしていくことに加えて、料金プランの柔軟化や、エンタープライズ向けの機能強化にも取り組んでいく予定です。 特に大手企業では、ソースコードを外部環境やAIに預けることへのセキュリティ面の懸念が大きいと感じています。そのため、オンプレミス環境への対応や、クローズド環境で利用できるローカルLLMの活用なども視野に入れながら検証を進めています。こうした要件にも柔軟に対応していきながら、より幅広い開発現場で使っていただけるサービスにしていきたいです。   ー最後に、SaaSus Platformの導入を検討している他のスタートアップや開発者の方々へメッセージをお願いします。 伊藤さん：  スタートアップは、どうしても開発リソースや時間が限られています。その中で、どこに集中するかはすごく重要だと思っています。 私たちの場合は、認証や課金、マルチテナント管理といったSaaSの共通基盤をSaaSus Platformに任せられたことで、Codeledgeのコア機能開発にしっかり集中することができました。 もし同じように、SaaSとして必要な機能をどこまで自前で作るべきか悩んでいれば、一つの有力な選択肢になると思います。 ▶ 技術ドキュメント自動生成・追従サービス「Codeledge」 ：https://codeledge.co/ --- ## 【導入事例】NTTタウンページ株式会社 URL: https://saasus.io/blog/ntt-tp Date: 2026-06-19 電話帳からデジタルへの大きな転換点  ーはじめに、今回のプロジェクトが立ち上がった背景を教えてください。 三上さん：  NTTタウンページは、長年『タウンページ（電話帳）』というメディアを通じて、地域社会の情報インフラとしての役割を担ってきました。しかし、社会全体のデジタル化が進む中で、紙媒体の役割は大きな転換期を迎えています。事実、電話帳は2026年3月末で発行を終了し、私たちにとってデジタルへの事業転換は、単なる新規事業の開発ではなく、会社の存続をかけた最優先事項でした。 現在は、これまでに培った信頼性と全国規模の事業者データベースを基盤に、中堅・中小企業の成長を支援するデジタルマーケティング企業への変革を目指しています。Web広告運用やホームページ制作など、提供サービスを広げる中で、私たちが保有する膨大な企業データをいかにデジタル時代に即した形で提供するかが、プロジェクトの大きなテーマとなりました。 ー具体的には、従来のデータ提供モデルにおいてどのような限界や課題を感じていたのでしょうか。 三上さん：  従来のデータベース販売モデルは、いわばアナログな注文販売でした。お客様からの要望を営業担当がヒアリングし、社内で条件に合うデータを抽出し、ファイル形式で納品するというプロセスです。これでは、お客様がデータの中身を実際に確認できるまでに数日のタイムラグが発生します。 また、情報の中身についても課題がありました。これまではエリアや業種といった基礎的な情報が中心でしたが、現代のマーケティングにおいて求められているのは、企業の売上高や従業員数、さらには「今、その企業が何に関心を持っているか」という動的な属性情報、いわゆるインテントデータです。 従来の仕組みでは、データの抽出作業そのものが社内の大きな工数となっており、多様化するニーズにスピード感を持って応えることが難しくなっていました。さらに、人手不足が深刻化するお客様の現場からは、「大量のリストに片っ端から電話をかけるのではなく、最初から精度の高いリストで効率的に営業したい」という切実な声が寄せられていたのです。 こうした「スピード」「利便性」「情報の付加価値」という3つの課題を一気に解決するためには、お客様自身がブラウザ上で24時間いつでも検索・抽出できるセルフサービス型のSaaS、すなわち『iタウンDBサーチ』の構築が不可欠であるという結論に至りました。   市場スピードに応えるための選択――外部プラットフォーム活用の決断 ーSaaS型の新サービスを構築するにあたって、技術面や体制面でどのような壁に直面されましたか？ 横山さん：  まず直面したのは、SaaSをビジネスとして成り立たせるための基盤機能をどう構築するか、という非常に現実的な課題でした。これまで当社では、システムごとに認証や管理機能を別個で運用していましたが、SaaSとして展開するとなると、話は別です。 具体的には、テナント管理、顧客ごとのID・パスワード管理、そして今の時代には欠かせない多要素認証といった機能を、一からクラウド上にセキュアに構築しなければなりません。社内にこうしたSaaS特有の仕組みをゼロから設計・実装した経験を持つメンバーは少なく、自分たちだけで取り組めば膨大な時間と試行錯誤が必要になることは明白でした。 しかしながら、市場環境は待ったなしの状態です。競合他社が次々と新しいサービスをローンチする中で、基盤部分の開発に半年も1年も費やしている余裕はありませんでした。私たちが本来注力すべきは、膨大な企業データの精度を高めることや、お客様が使いやすい検索UIを作り込むことであって、認証システムの開発そのものではない。この優先順位を明確にしたことで、自社の強みに集中するため、認証は外部のプラットフォームを活用するという選択肢が浮上しました。 ー多くの選択肢がある中で、最終的にSaaSus Platformを導入した決定打は何だったのでしょうか。 横山さん：  一言で言えば、SaaS運営に必要な共通機能が『パッケージとして完成されていたこと』です。私たちが悩んでいた認証や顧客管理、契約管理、さらには将来的な拡張性までが、導入するだけで手に入る点は非常に魅力的でした。 いくつかの候補を比較検討しましたが、SaaSus Platformは『シンプルに実装したい』という私たちの開発ニーズに最も真摯に応えてくれると感じました。実際に管理画面に触れてみると、操作感も軽快で直感的であり、情報の反映も早い。これなら開発現場の心理的なハードルも下げられ、スピーディーに市場へ投入できると確信しました。 この決断により、本来であれば数ヶ月を要する認証機能の実装にかかる工数を抑え、ユーザー価値に直結する検索機能やUI設計といった領域に、より注力できるようになりました。その結果、オンデマンドでデータを取得できるシンプルなUIの実装に繋がっています。   商談がその場で決まる。営業DXがもたらした「爆速」の成果 ーSaaSus Platformを導入したことで、具体的にどのような成果が得られましたか？ 三上さん：  本取り組みにより、基盤部分の開発負担を軽減できたことで、結果として短期間でのサービス提供が可能となりました。通常、一から構築する場合に比べ、認証機能などにかかる工数を抑えられたことにより、2～3か月でのローンチに至っています。これにより、競合他社が次々とサービスを打ち出す激しい市場環境において、遅れをとることなく市場投入できた意義は非常に大きいと感じています。 また、提供モデルをSaaS型へ移行したことで、お客様自身の利便性も劇的に向上しました。従来はお客様から条件を伺い、私たちがデータを抽出して納品するまでに数日を要していましたが、現在はログイン後にお客様が自らターゲットを絞り込み、その場でCSVデータをダウンロードできます。このオンデマンド性は、スピードを重視する現代のマーケティングにおいて、お客様から非常に高く評価されています。 ー現場の営業活動においても、変化があったとお聞きしました。 横山さん：  はい、当社の営業チーム自らもこのツールを活用しており、商談の質が劇的に変わりました。これまではお客様から条件を預かり、一度持ち帰って社内で件数を確認してから再提案するという流れが一般的でした。しかし現在は、商談中にタブレットを見せながら、例えば、「この業種で、この地域の新卒募集企業は〇〇件あります」とその場で件数を提示できます。 特にお客様の関心が高いのが、展示会出展や新商品リリースなどの企業の動きを捉えた『インテントデータ』を活用した絞り込みです。ターゲットがその場で可視化されることで、お客様も納得感を持って検討を進められ、場合によってはその場で即決、契約に至るケースも見られるようになりました セールスリードタイムの大幅な短縮という副次的効果は、私たちにとっても嬉しい驚きでした。 ー最後に、今後の展望とSaaSus Platformへの期待を教えてください。 三上さん：  今後は、ブラウザベースの提供に留まらず、外部システムとの連携を可能にするAPI開発を一層強化していきます。すでに、自社保有のデータに当社の新鮮な属性情報をリアルタイムで付与したいというエンタープライズ企業様からの引き合いも多くいただいています。日本最大級の約800万件という、信頼性の高いオプトインデータの強みを活かし、企業のマーケティング活動を支える不可欠なインフラへと育てていきたいと考えています。 SaaSus Platformには、今後も料金メニューの細分化や、管理機能のさらなるアップデートを期待しています。私たちが安心してサービス価値の最大化に集中し続けられるよう、今後も強力なパートナーとして支えていただきたいですね。   --- ## 【導入事例】三菱電機株式会社 URL: https://saasus.io/blog/mitsubishi-electric Date: 2026-06-19 製造業における「売り切りモデル」からの脱却と、AIビジネスが直面した「初期費用の壁」   三菱電機株式会社 名古屋製作所のオープンイノベーション推進部は、設立から約2年を迎えたばかりの比較的新しい組織です。組織のミッションは、単なるアイデア探索に留まらず、次の柱になる事業を創るため、「お金を払ってでも欲しい」と言ってもらえる状態まで育て、事業部門への「渡し船」となることです。今年度からは新たな人財活用の仕組みを構築し、新規事業の早期実現を目指しています。  現在取り組んでいるのは、3Dシミュレータ「MELSOFT Gemini」と、Realtime Robotics社が提供するクラウドAIサービス 「Resolver」を掛け合わせた新規事業です。誰でも簡単にデジタル空間でAIによってロボットの動作経路、作業順番などを最適化でき、お客様の経営課題である「人材不足」の解消を図ります。そして「フィジカル空間へワンストップで提供」することで、バーチャルコミッショニングを実現します。   ー既存のオンプレミス型、つまり「売り切り」の提供形態から、あえてSaaSという形を選択された背景には、どのような切実な課題があったのでしょうか？  佐藤さん：  最大の壁は、初期導入コストによるハードルの高さでした。製造業の世界では、高額な設備投資を行い、それを数年かけて減価償却していく『モノ売り』の商習慣が今も根強く残っています。しかし、ロボット最適化AIのような商材は、実際に現場で動かし、データが溜まって初めて真の価値が発揮されるものです。  お客様がその価値を実感する前に、多額の初期費用を求める従来のモデルでは、導入判断が非常に慎重になってしまいます。ROI（投資対効果）が見えにくい新しいソリューションだからこそ、初期費用を抑え、お客様の成功に合わせて収益をいただくリカーリング（継続課金）形式への転換が必要だと感じていました。SaaSという形態は、まず使い始めていただくための最善の選択肢だったのです。  本部さん：  サービス運用面でも、従来のメールベースのやりとりには限界を感じていました。これまではライセンスの発行や管理を個別のメールでやり取りしており業務負荷も高く、また、オンプレ型であることでお客様が実際に製品をどれくらい活用できているのか、どこで操作に迷っているのかといった利用状況が全く可視化されていなかったのです。  さらに、このビジネスには弊社とお客様だけでなく、現場での導入を担うSI（システムインテグレーター）パートナー様の存在が不可欠です。お客様、SIパートナー、メーカーの三者がWeb上でリアルタイムにプロジェクトの状況を共有できる基盤がなければ、スピーディな事業展開は望めません。データを資産として蓄積し、それを継続的な改善のフィードバックに繋げる。そのためには、単なるクラウド化ではなく、三者間連携を前提としたSaaS化が不可欠でした。    ー製造業における「モノ売りからコト売り」へのシフトは、昨今のキーワードでもありますが、現場での実感はいかがでしょうか？  佐藤さん：  正直なところ、お客様自身も「何をどう始めていいか分からない」というのが現状だと思います。ただ、昨今のフィジカルAIへの注目の高まりは、IT企業の視点でのみで語られてきたAIが、ようやく我々の領域である製造現場に降りてきたというチャンスでもあります。  現場には過去数十年にわたって培われた膨大なノウハウとデータがあります。それらをお客様自身の資産として活用し、AIと掛け合わせることで新しい価値を生み出す。この流れ自体は確実に来ていますし、その橋渡しをすることに我々の存在意義があると考えています。  わずか10日間でMVPを構築。「誰とやるか」を重視した共創パートナーの選定  SaaS化の構想はあったものの、検討や調整に時間を要する中で、より迅速に市場ニーズを検証できる進め方が求められていました。 そこで彼らは、10日間でMVPを構築する「10 Days SaaSification for AWS」を活用し、短期間での仮説検証に着手しました。     ー10日間という極めて短期間での開発に対し、社内での懸念や『本当にできるのか？』という声はありませんでしたか？  佐藤さん：  確かに、わずか10日間でどこまで作り込めるのかという疑念がなかったわけではありません。しかし、私が昨年のAWS Summit Japanのブースでこのサービスを知ったとき、直感的にこれだと思いました。  我々のような製造業では、製品開発のサイクルが10年、20年単位になることも珍しくありません。ですが、AIやSaaSの領域は変化が激しすぎます。社内の標準的なプロセスに乗せて時間をかけている間に、仮説自体が古くなってしまうのです。完璧な仕様書を積み上げるよりも、まずは一日でも早くお客様の前に持っていき、「触ってください」と言える動くソフトウェアが必要でした。  本部さん：  パートナー選定において最も重視したのはマインドセット、つまり誰とやるかという点でした。初日の対面打ち合わせで、昼食を共にしながら議論を重ねた際、アンチパターン社の皆様の熱量を肌で感じました。我々の認識が不足していた点もスピーディに指摘いただき、お互いに高め合えるチームだと確信できたことが大きな決め手です。  技術的にも、認証やテナント管理といったSaaSとして共通して必要な基盤部分（SaaSコントロールプレーン）を『SaaSus Platform』に任せられたことは非常に大きかったですね。もしこれらをゼロから自分たちで構築しようとしたら、セキュリティの設計だけで数ヶ月を要したはずです。SaaSus Platformを活用したことで、我々はプロダクト独自の機能開発や、お客様へのヒアリング、社内の合意形成といった「我々にしかできない仕事」に100%注力することができました。    ー実際にアジャイルな体制で開発を進めてみて、従来のウォーターフォール開発との違いをどう感じましたか？  本部さん：  正直、ピボット（方針転換）の連続でしたね。作ってみて提示したら「やっぱりこうじゃない」と言われることもありました。ですが、動くものがあるからこそ、具体的なフィードバックが得られ、正しい方向へ舵を切ることができたと感じます。  アンチパターンさんは、常に「どちらの選択肢も取れますよ」と柔軟な提案をしてくれました。大企業の論理でガチガチに固めるのではなく、まずはスモールチームでぐるぐる回す。このスピード感があったからこそ、承認プロセスの重さに押し潰されることなく、モダンなデザインで使い勝手の良いシステムを完成させることができました。  「工数削減」の先にある価値の発見と、全社へ波及するイノベーションのマインド  10日間で構築されたSaaS版のMVPは、直ちにSIパートナーや顧客の現場へ投入されました。そこで彼らが目にしたのは、当初想定していた「事務的な効率化」を遥かに超える、現場の切実な期待と喜びでした。  ー実際にMVPを運用し、現場の声に触れてみて、どのような手応えや気づきがありましたか？  佐藤さん：  最大の驚きは、ROI（投資対効果）の捉え方が変わったことです。当初、私たちは「このAIを導入すれば、これだけの工数が削減できますよ」という、人件費削減を主なメリットとして提示していました。しかし、実際にSIパートナー様と対話する中で、「削減した分、人を切りたいわけではない」という声を強くいただいたのです。  彼らが求めていたのは、AIによって生まれた余力を活用して、これまでは月に10件しか受けられなかった案件を15件、20件と増やし、会社としての利益を最大化することでした。つまり、ROIの本質はコストカットではなく受託キャパシティの拡大にあったのです。この現場目線の価値指標を可視化しようというアイデアは、動くソフトウェアを持って現場を駆けずり回ったからこそ辿り着けた真理でした。  本部さん：  SaaS化によって利用状況シグナルを把握できるようになったことも大きな成果です。これまで見落としていたお客様の躓きをリアルタイムで検知し、能動的なサポートを提供できる体制が整いました。これは単なるソフトウェアの提供ではなく、お客様の成功に寄り添う「コト売り」を実現するものです。  今後はAIエージェントの搭載による戦略的なレポート提示など、さらに高度な利活用も視野に入れています。データが取れることで開発も、営業も、そして何よりお客様も嬉しい。そんな「美味しさ」が詰まったサービスへと成長させていきたいですね。  ー今回のプロジェクトは、三菱電機という巨大な組織全体にとっても、重要な意味を持つのではないでしょうか？  佐藤さん：  三菱電機グループは今、「イノベーティブカンパニーへの変革」を掲げ、リスクを恐れず、新たな発想で価値を創出する変革の真っ只中にあります。私たちは長年、既存事業の延長線上でビジネスをしてきましたが、AI時代の到来により、変化し続けることこそが成長の原動力になると痛感しています。  今回の、顧客を巻き込んだSaaS化によるデータ活用のように、全社でも人財やデータ、技術の巡り合いから新たな価値創出につなげるデジタル基盤「Serendie®」 が進んでいます。大企業ならではのアセット（資産）を活かしつつ、スタートアップのようなアジリティ（俊敏性）を持って動く。このマインドが全社に波及し、三菱電機が真にイノベーティブな企業へと生まれ変わるための一助となれば、これほど嬉しいことはありません。  --- ## SaaS契約における覚書との向き合い方〜締結前に知っておくべきリスクと契約設計の考え方〜 URL: https://saasus.io/blog/saas-terms-of-service-unification Date: 2026-06-15 「受注を確定させるためなら、多少の条件変更（覚書）はやむを得ない」そう考えて安易にハンコを押そうとしていませんか？大手から中堅まで、商談の最終局面で突如現れる覚書の壁。しかし、安易な個別対応の積み重ねは、例外対応の工数を膨らませ、本来サービス改善に充てるべきリソースを圧迫する「負債」になり得ます。本記事では、SaaSの契約実務において、なぜ覚書対応がスケールの枷になるのかを、法務・技術・経営の多角的な視点から解説します。 そもそも覚書とは何か 「覚書」とは、すでに締結している契約内容を補足したり、一部を変更したり、あるいは当事者間で合意した事項を簡潔にまとめたりする際に用いられる文書です。名称こそ「メモ」のような響きがありますが、法的には契約書や合意書と何ら変わりない法的拘束力を持ちます。 ビジネス実務において覚書が使われるのは、主に「本契約（SaaSの場合は利用規約）を修正するほどではないが、特定の事項について合意を明確にしておきたい」という場面です。例えば、支払日の調整や、秘密保持の対象範囲の微修正、あるいは特定のプロジェクトにおける役割分担の明確化などが挙げられます。このように、本来はメインとなる契約を補完するための「柔軟な調整手段」として広く活用されている契約形態です。 従来型契約からSaaS契約へのパラダイムシフト 納品で終わる「点」の契約と、覚書の相性の良さ かつてのパッケージソフトや受託開発（SI）において、契約は「完成したモノを納品して完了する」という「点」の取引でした。仕様が固定されているため、特定の顧客の要望に合わせて支払い条件や検収基準を覚書で微調整しても、その後の運用に大きな影響を与えることは少なかったのです。 この「仕様固定・納品完了型」の取引に慣れ親しんだビジネス現場では、個別の要望を覚書で受けることは、むしろ「柔軟で顧客思いな対応」として肯定されてきました。顧客側の法務担当者にとっても、標準契約の不足分を覚書で埋める行為は、リスク管理のプロとしての正当な仕事だったのです。 「カスタム文化」が生んだ、個別対応＝高品質という呪縛 特に日本のエンタープライズ領域では、顧客の個別要件に合わせてシステムをカスタマイズする慣習が長く続いてきました。そのため、今でも多くの顧客は、「自社の社内規定に合わせて契約（覚書）をカスタマイズさせること」を当然の要求として捉えています。 しかし、この「一点物」を作る時代の成功体験をそのままSaaSに持ち込むと、サービスの本質と致命的な摩擦が生じます。SaaSは「顧客に合わせる」のではなく「画一的なサービスを全顧客に提供する」モデルだからです。旧来の「個別対応こそが至高」という価値観が、今やSaaSの進化を阻む足枷となっています。 SaaS契約の本質：仕様ではなく「標準化された仕組み」の継続利用 SaaSの契約は、特定時点の「モノ」を買う契約ではなく、「標準化されたサービス提供の仕組み（インフラ）」を利用する契約へと根本から変化しています。 事業者は、全ての顧客に対して同一のコードを動かし、一括したアップデートを提供します。利用規約はこの画一的な仕組みを維持し、全ユーザーに安定した品質を届けるためのルールブックです。つまり、SaaSの契約とは、個別のこだわりを反映させる場ではなく、事業者が定義した運用プロセスを長期間にわたって利用し続けるための合意なのです。この「線（継続）」の視点を持てるかどうかが、覚書のリスクを見極める境界線となります。 「覚書」によりシステムと組織に蓄積される致命的な負債 開発の自由度を奪う「仕様の固定」という名の枷 SaaSの最大の武器は、ユーザーの声や技術トレンドに合わせてプロダクトが進化し続けることです。しかし、覚書によって「契約締結時の画面構成を維持する」「特定の機能を削除しない」といった条件を個別に固定してしまうと、その瞬間、プロダクトチームの動きは縛られます。 SaaSの裏側では、データベースの構造やインフラ基盤も更新されます。特定の顧客に対して過去の仕様の維持を約束してしまうと、システム全体を最新にアップデートしたくても「A社とは覚書があるので、この基盤変更はA社向けに別対応が必要になる」という判断を迫られます。これは当然技術的に対応できないわけではありませんが、テナントごとに異なる挙動を維持するための分岐・テスト・検証コストが積み重なり、エンジニアのリソースが「新機能の開発」ではなく「例外対応の維持」に吸い取られていく構造が生まれます。 セキュリティ対応や機能改善が予期せぬ契約違反の火種に さらに深刻なのは、良かれと思って行った改善が法的なリスクに反転する点です。例えば、深刻な脆弱性が見つかり、セキュリティ強化のために特定の通信プロトコルを廃止する必要が生じたとします。標準テナントには一斉に適用できる対応ですが、覚書で古いプロトコルへの対応を明記しているテナントがいれば、そのテナントへの廃止は形式上「契約違反」を構成しかねません。契約違反にならないように廃止をする場合には、個別に通知を行ったり、状況の説明や覚書の再締結などが生じる可能性があります。テナント側が廃止を受け入れない場合、そのテナントは古いプロトコルを使い続けることになりセキュリティリスクを自ら抱えることになります。さらにサービス提供側も、例外的な維持対応のコストを負いながら、本来の改善対応に充てるべき工数が削られるという二重の負担を抱えることになります。 また、UI（操作画面）の刷新や、利用率の低い機能の整理も、覚書で細かく仕様を規定している顧客にとっては「合意なき変更」と受け取られかねません。本来、ユーザーに常に最高かつ安全な体験を提供するための企業努力が、個別の覚書というフィルターを通すことで「リスク」へと変貌してしまう。この構造的な矛盾こそが、SaaSにおいて安易に覚書を巻いてはいけない最大の理由です。 法務・営業・CSを疲弊させる「管理コストの雪だるま」 覚書による個別対応のツケは、契約締結から数年が経過した後に負債として顕在化します。1社、2社と例外が増えるたびに、社内には「規約と運用が異なる顧客」のブラックボックスが積み上がっていきます。 チームに新しいメンバーが入るたびに膨大な「過去の経緯（覚書）」を読み解かなければならず、CS（カスタマーサクセス）は常に「この案内はA社に送っても大丈夫か？」と法務へ確認を求めるようになります。本来なら新機能の活用提案に使うべき時間が、過去の契約との整合性を確認する作業に消えていく。この確認コストこそが、組織の生産性をじわじわと削り取る負債の正体です。さらに深刻なのは、確認フローが形骸化したり、担当者の引き継ぎ漏れが重なったりすることで、「覚書の存在自体が社内で忘れられる」ケースです。新しい担当者が覚書の存在を知らないまま標準の案内や機能変更の通知を送ってしまい、それが覚書違反として顧客からクレームになるそのようなトラブルは、覚書の枚数が増えれば増えるほど発生確率が上がります。 「リスクの不均一」が経営を縛り、組織の俊敏性を奪う 損害賠償上限の撤廃や仕様の固定といったリスク度合いのテナント間のギャップも、経営の意思決定を縛る枷になりえます。 SaaSの強みは、均一なルールのもとで「全テナントに対して同時に、素早く動ける」ことにあります。しかし、あるテナントは標準規約（リスク限定）、別のテナントは覚書で無制限（高リスク）といったバラつきが生まれると、組織の大胆さが失われます。 例えば、「来期から価格体系を刷新する」「不人気な機能を廃止してリニューアルに注力する」といった攻めの決断を下そうとしても、現場からは「B社との覚書との整合性を確認する必要があります」「C社の賠償リスクを考えると、影響範囲の精査に時間がかかります」と報告が上がる。アクションのたびに例外テナントに対する確認と個別対応の調整コストが発生する状態になってしまうのです。一社の要望に応えたはずの覚書が、結果として組織全体の意思決定スピードを落とし、市場の変化への適応を遅らせる最大の要因となってしまいます。標準化を放棄して得た短期的な「受注」という果実は、数年後には「変化できない組織」という重い足枷へと変貌するのです。 SaaSのスケールメリットは「画一性」から生まれる SaaSが成立する前提：全テナントに同一のサービスを提供すること SaaSというビジネスモデルが成立する最大の前提は、一つのシステムを数多くの顧客で共有する「マルチテナント」構造にあります。これは単にコードが同じであるという話にとどまりません。サーバーの運用、セキュリティ監視、不具合への対応、そして新機能のデリバリーにいたるまで、全ての顧客に対して同じプロセスを提供することで、圧倒的な効率化と高品質の両立を実現しています。 この画一性こそが、SaaSが安価かつ常に最新の状態を保てる源泉です。もし一社ごとに異なる要望（覚書）を受け入れてしまえば、それはもはやSaaSではなく、非効率な受託開発の集合体へと退行してしまいます。規約を統一し、サービスを画一的に保つことは、事業者のエゴではなく、SaaSというモデルが顧客に約束した持続的な価値提供を果たすために必要な要素なのです。 開発・インフラ・サポート、すべてが「同じもの」を前提に設計されている SaaSの裏側にある現場を想像してみてください。エンジニアは全顧客に影響するバグを一度の修正で解決し、インフラ担当者は全顧客のデータを同一のポリシーでバックアップし、CSは共通の仕様に基づいて迅速な回答を行います。これら全ての活動は、対象が同じものであるからこそ、プロフェッショナルな水準で自動化・最適化されています。 ここに覚書による例外が混じると、この歯車が狂い始めます。たった一社のための例外的な仕様変更や運用ルールは、テナントごとの差分が増える分だけテストや検証の組み合わせを増やし、その例外テナントにおける対応負荷を押し上げます。皮肉なことに、個別対応を求めた顧客自身が「標準の仕組みから外れた顧客」となり、サポートや変更対応のスピードで不利益を被りやすくなります。そしてその対応工数の皺寄せは、標準テナントへのサービス改善や新機能のデリバリーが遅れるという形で、じわじわと全体にも波及する可能性があります。 利用規約の統一はスケールの一部 プロダクトの機能やインフラ基盤が画一的であるべきなら、それを定義する契約（利用規約）もまた「画一的」でなければスケールは実現しません。SaaSにおいて、利用規約はプロダクトの仕様書であり、運用マニュアルでもあります。プログラムのコードに個別の分岐（if文）を増やすことがシステムを複雑にするのと同様に、契約に個別の分岐（覚書）を増やすことは、ビジネスモデルそのものを複雑にし、成長の鈍化を招きます。 利用規約の統一は、単なる法務上の手続きではなく、プロダクトの一部を標準化していると捉えるべきです。契約条件が全顧客で揃っているからこそ、事業者は一斉の価格改定や大胆な機能刷新に踏み切ることができ、その結果として得られた利益をさらなるプロダクトの進化へ再投資できます。規約の標準化を守り抜くことは、長期的に顧客に「より安く、より良い、より安全なサービス」を届け続けるための、方法論なのです。 まとめ SaaSの事業成長においてエンジニアがコードの品質にこだわるように、ビジネスサイドは契約の品質にこだわる必要があります。本記事で見てきたように、安易な覚書の締結は、短期的には顧客満足を高めるように見えて、長期的にはサービス改善のリソースを圧迫し、結果として顧客に不利益をもたらす「負債」へと変わります。 SaaSの契約設計を正しく理解し、標準化を貫くことは、決して顧客への拒絶ではありません。むしろ、全てのユーザーに等しく、最新かつ最高の価値を届け続けるというプロダクトの意志表明です。実務上のリスクを正しく把握し、契約の標準化を自社の方針として貫くこと。その一歩が、健全で力強いSaaSのスケールを実現する鍵となります。 --- ## 自社に合ったSaaSの見極め方：機能比較では見えない、成果につながる3つの判断軸 URL: https://saasus.io/blog/saas-selection-3-points Date: 2026-06-01 多機能なSaaSを選んだはずなのに、思ったほど成果が出ない。そんな経験はありませんか？機能の多さそのものが、導入後の成果を保証するわけではないからです。 SaaS選定で見るべきなのは、導入後にどれだけ早く価値を実感できるか、現場に無理なく定着するか、そして業務や組織の変化に合わせて使い続けられるかという点です。 比較表に表れる機能の多さではなく、そのツールが自社の業務にどれだけ摩擦なく馴染むかが重要になります。 この記事では、実務で明日から使える具体的な測定指標や評価ステップを交えながら、成果につながるSaaS選定の3つの判断軸を整理します。ツール導入を単なるコストで終わらせず、事業成長を支える基盤に変えるための現実的なアプローチを確認していきましょう。 なぜ多機能なSaaSでも成果につながらないのか 機能の多さと使いこなせることは別問題 「大は小を兼ねる」という考え方でSaaSを選ぶと、かえって現場が混乱することがあります。機能が豊富であることは、それだけ設定項目が増え、画面の情報量が多くなり、結果として運用が複雑になりやすいということでもあるからです。 たとえ高度な分析機能や自動化機能が備わっていても、現場の担当者が日常業務の中で使いこなせなければ、その価値は発揮されません。場合によっては、不要な入力や確認の手間だけが増え、かえって運用負荷を高めてしまうこともあります。重要なのは、機能の数ではなく、自社にとって必要な機能が過不足なく備わっているかどうかです。使わない機能の多さではなく、現場の運用に過不足なくなじむかを見極めることが大切です。 選定時の評価軸と導入後の現実はずれやすい SaaSの選定段階では、決裁者や情報システム部門が、将来の拡張性や管理のしやすさを重視することが少なくありません。一方で、導入後に実際にツールを使う現場の担当者が求めているのは、日々の業務をストレスなく進められるかという使い勝手です。 この評価軸のズレがあると、導入時には高く評価されたツールでも、現場では定着しにくくなります。たとえば「操作が難しくて結局Excelに戻る」「入力項目が多く、次第に使われなくなる」といったことは珍しくありません。SaaS選定で本当に目指すべきなのは、機能一覧を埋めることではなく、導入後の業務の中に自然に組み込まれる状態をつくることです。成果につながるかどうかは、選定時のスペックではなく、現場で無理なく使い続けられるかで決まります。 判断軸① 導入後、どれだけ早く価値を実感できるか 成果に直結する指標「TTV（価値実感までの時間）」の短さ SaaSの選定で近年重視されているのが、TTV（Time to Value：価値実感までの時間）です。これは、ツールを契約してから、現場のユーザーが「業務が楽になった」「課題が解決した」と最初の効果を実感するまでに、どれくらい時間がかかるかを示す考え方です。 TTVが短いツールほど、導入効果を早く社内で共有しやすく、現場にも定着しやすくなります。反対に、初期設定やデータ移行に想定以上の時間がかかるツールは、運用開始前に現場の期待がしぼみ、導入そのものが形骸化するリスクがあります。 では、TTVの短さはどう見極めればよいのでしょうか。ポイントは、実運用までに必要な準備工数を具体的に把握することです。 たとえば、ベンダーに対して、初期設定やデータ移行で発生する作業を、できるだけ細かい手順で示してもらう方法があります。必要な作業が見えれば、自社でどれだけの人手や期間を確保すべきか、現実的に判断しやすくなります。 無料トライアルが使えるなら、実際の業務データを一部だけ使って、基本的な操作を試してみるのも有効です。マニュアルを読み込まなくても基本フローを進められるか、少ない準備で使い始められるかを確認することで、導入後にどれだけ早く価値を実感できそうかが見えてきます。 現場の「使いやすさ」は、見るポイントをそろえて確かめる TTVを早く実感できるかどうかは、現場が迷わず使えるかにも左右されます。ただ、デモやトライアルを現場に渡して「自由に見てほしい」とするだけでは、導入後に「思ったより使いにくい」といったズレが起こりがちです。 大切なのは、検証方法を細かく決めることではなく、「何を見て判断するか」を事前にそろえておくことです。たとえば、「時間がかかっている作業がスムーズになりそうか」「次の操作が直感的にわかるか」といった観点を共有しておけば、現場からも実務に即したフィードバックを得やすくなります。 判断軸② 変化に対応できる柔軟性と、進化し続ける力があるか 運用変更に耐えられる柔軟性があるか 導入時には自社に合って見えるツールでも、組織変更や業務フローの見直しによって、使いにくさが出てくることがあります。そこで見たいのが、将来の変化に対して、どれだけ手間や追加費用をかけずに運用を調整できるかという柔軟性です。 ここでいう柔軟性は、「何でもできる多機能さ」ではありません。大切なのは、変化が起きたときに、自社で設定を見直しやすいか、運用の変更に無理なく対応できるかという点です。 たとえば、アカウントの追加や組織変更を自社でスムーズに設定できるか、データを簡単に取り出せるかといった点は、将来の運用負荷を大きく左右します。こうした基本的な自由度が低いツールは、変更のたびにベンダーへの依頼や追加費用が発生しやすく、結果として運用の見直しが重荷になりがちです。 見るべきなのは、「今の業務に合うか」だけではありません。運用の見直しが必要になったとき、手戻りの工数やコストが膨らみすぎないか。この視点を持っておくことが重要です。 アップデートと安定稼働は見えにくい重要指標 SaaSは、導入時点の機能だけで選ぶものではありません。契約後も継続的に改善され、自社の変化に合わせて使い続けられるかどうかも、重要な判断材料になります。 そのため、選定時には「いま何ができるか」だけでなく、「この先も改善され続けるか」を見ておきたいところです。たとえば、最近どのような機能改善が行われているか、ユーザーの要望がどの程度反映されているか、サポート情報や案内が継続的に更新されているかといった点を見ると、そのプロダクトが今後も育っていくかをイメージしやすくなります。 同時に、進化の速さと並んで重要なのが、システムの安定性です。どれだけ機能が充実していても、不具合や停止が多ければ、業務基盤として安心して使うことはできません。障害発生時の案内がわかりやすいか、稼働状況に関する情報が開示されているかといった点も含めて見ておくと、長く使えるSaaSかどうかを判断しやすくなります。 判断軸③ 料金の安さではなく、費用対効果を説明できるか 総コストと得られる効果をセットで見る SaaSの料金を比較する際、月額の安さだけで判断すると、導入後に「思ったよりコストがかかる」と感じることがあります。費用対効果を考えるうえで大切なのは、見積書に書かれた金額だけでなく、実際に運用が広がったときの支払い総額や、自社内で発生する導入・運用の負担まで含めて見ることです。 たとえば、多くのSaaSは利用人数や使える機能に応じて費用が変動します。導入時点では手頃に見えても、活用が広がるにつれて想定以上にコストが増えることもあります。そのため、いまの価格だけでなく、自社の成長や使い方にその料金体系が合っているかを見ておく必要があります。 また、見積書には表れにくい社内工数も無視できません。初期設定に時間がかかる、操作が難しく教育負担が大きい、といったツールは、月額料金が安くても、社内での対応コストがかさみ、結果的に高くつくことがあります。反対に、設定しやすくサポートも充実していて、現場にスムーズに定着するSaaSであれば、多少料金が高くても早く効果を回収しやすくなります。 つまり、見るべきなのは「安いかどうか」ではなく、「その金額でどれだけの効果を継続的に得られるか」です。月額料金の大小ではなく、導入後にどれだけ無理なく成果につなげられるかで判断することが重要です。 まとめ SaaS選定で重要なのは、機能の多さを比べることではなく、導入後にどれだけ早く価値を生み、変化に合わせて使い続けられるかを見極めることです。使いやすさ、柔軟性、進化の速さ、そして総コストに対する費用対効果まで含めて判断すれば、SaaSは単なるツールではなく、事業を前に進める強力な基盤になります。比較表の機能数を眺める前に、まずは「このSaaSは自社にとって無理なく成果を出せるか」を、具体的な評価ステップに則って問い直すことが大切です。 --- ## LTVとチャーンレートとは？SaaSマーケターが理解すべきこと URL: https://saasus.io/blog/saas-marketing-ltv-churn-rate Date: 2026-05-27 SaaSの現場では「LTV（顧客生涯価値）」と「チャーンレート（解約率）」という言葉が頻繁に登場します。意味は知っていても、自分の施策とどうつながるのか実感できていない人は、実は多いのではないでしょうか。リード獲得こそがマーケターの役割だと思っているなら、それはまだ入り口に過ぎません。SaaSでは、すべてのマーケティング活動が最終的にLTVとチャーンに直結します。本記事では、この2つの指標がなぜ重要なのか、そして明日から何を意識すべきかを解説します。 1. なぜSaaSは「売ってから」が本番なのか？継続収益の仕組みを理解する SaaSは「売ってから」が本番のビジネスです。従来のソフトウェア販売のように、販売した瞬間に売上の大半が確定する「売り切り型」とは異なり、SaaSは月額・年額で継続的に収益を得るサブスクリプションモデルが主流です。そのため、顧客獲得にかかる広告費や人件費（CAC）は初月の利用料では回収できず、数ヶ月から1年以上使い続けてもらって初めて利益が生まれます。契約はゴールではなく、収益化に向けたスタート地点なのです。 この構造は「穴の空いたバケツ」に例えられます。水を注ぐ行為が新規顧客の獲得、溜まった水が収益です。しかしバケツの底に穴が空いていれば、水は流れ出てしまいます。この“穴”こそがチャーンレート（解約率）です。いくら新規獲得を増やしても、解約が多ければ収益は積み上がりません。むしろ獲得コストだけが増え、事業は不安定になります。だからこそ、SaaSマーケターには「どう水を増やすか」だけでなく、「どう漏れを防ぐか」という視点が不可欠です。 ここで重要になるのがLTV（顧客生涯価値）です。LTVとは、1人の顧客が契約期間中にもたらす合計利益を指しますが、その本質は「顧客がどれだけ長く価値を感じ続けてくれるか」という信頼の積み重ねです。サービスに満足し、使い続けてもらうほどLTVは高まります。マーケターの役割は単なる認知拡大ではなく、顧客の課題や期待を正しく捉え、導入後の成功イメージを届けることです。LTVを高めることは、顧客との関係性を設計することに他なりません。 2. LTVとチャーンレートの基本計算法と、数字の「裏側」にある意味 LTVとチャーンレートは、SaaSマーケターにとって最も重要な指標です。まず基本の計算式を押さえましょう。LTVは、「1社あたりが平均して月々に支払う金額（ARPU）」を「月次の解約率（チャーンレート）」で割ることで算出できます。 LTV = \frac{ARPU（平均単価）}{Churn Rate（解約率）} 例えば、以下の条件でシミュレーションしてみます。 ARPU（月額単価）： 1万円 チャーンレート（解約率）： 5%（0.05） この場合、計算式は 1万円 ÷ 0.05 となり、LTVは20万円と導き出されます。 これは「平均して20ヶ月間契約が継続し、その期間に合計20万円の売上をもたらしてくれる」という将来予測の目安になります。 ここで重要なのは、単価（分子）を上げても、解約率（分母）がそれ以上に上がってしまえば、LTVは下がってしまうというバランスの妙です。SaaSの本質は「いかに高く売るか」ではなく、**「いかに価値を感じ、長く使い続けてもらうか」**にあることがこの式からも分かります。 特に注目すべきは、解約率のわずかな差が長期的な成長に大きく影響する点です。月次3%と2%では、数年後の顧客数に大きな差が生まれます。1%の改善は、新規獲得を大きく増やすのと同等以上の価値を持つこともあります。だからこそ、獲得数だけでなく継続率を見る視点が欠かせません。 さらに、これらの指標は過去の結果ではなく未来のヒントです。チャネル別にLTVを見れば、訴求と実態のズレが分かりますし、解約率が低い流入には良質な顧客を引き寄せる要素があります。数字を起点に顧客体験を見直し、メッセージを改善していく。この積み重ねが、LTV最大化につながります。 3. あらゆる発信が「ターゲティング」である。マーケターが作る期待値の正体 SaaSにおけるあらゆる発信は、実質的に「ターゲティング」の役割を果たしています。ターゲティングと聞くと広告設定を思い浮かべがちですが、本質は「メッセージによるフィルタリング」にあります。「無料で簡単」と伝えれば手軽さを求める層が集まり、「高度なセキュリティ」と伝えれば企業向けの顧客が集まります。つまり、言葉や事例、コンテンツのすべてが「誰を呼び、誰を呼ばないか」を決めています。LTVを高めるには、発信内容によって自社に合う顧客を選別しているという自覚が不可欠です。 一方で、獲得数を追うあまり「背伸びした訴求」をしてしまうケースも少なくありません。本来は特定領域に強いツールであるにもかかわらず、「これ一つで何でもできる」と伝えてしまうような状況です。こうした訴求は短期的にはCVを増やしますが、導入後の期待とのギャップが生まれ、結果として解約につながります。過度な期待値は、LTVを大きく損なう要因です。 だからこそ重要なのは、「使い続けてもらう前提」でのメッセージ設計です。機能の説明だけでなく、導入後の活用イメージや成功事例といったリアルな体験を伝えることで、期待値のズレを防ぐことができます。顧客が納得した状態で導入すれば、継続率は自然と高まります。さらに、実際のユーザーの声や活用例を発信することで、自社と相性の良い顧客が集まる好循環が生まれます。 4. 今日から意識を変える。LTVを指標に置いたマーケティング実践 カスタマーサクセスと「解約の理由」を共有する LTVを高めるためにまず意識すべきは、「解約の理由」を現場から学ぶことです。カスタマーサクセス（CS）に、解約顧客が導入前に何を期待していたのかを確認しましょう。「機能不足」が多ければ訴求の広げすぎ、「使いこなせない」が多ければ活用イメージの伝達不足が考えられます。解約理由をマーケティングの改善点として捉えることで、メッセージの精度は大きく向上します。 「ファン」の共通点を施策に反映する 次に注目すべきは、LTVの高いロイヤルユーザーです。彼らが継続する理由を分析すれば、再現性のある成功パターンが見えてきます。特定の業界や職種に偏りがあるなら、その層に響く言葉や事例を発信に取り入れましょう。また、実際の活用事例を通じて「成功後の姿」を具体的に想起させることが、相性の良い顧客の獲得につながります。 部門を越えて「理想の顧客体験」を議論しよう さらに重要なのは、部門を越えた連携です。マーケティング・セールス・CSはすべて「顧客の成功」を目的とした一つのチームです。LTVを共通指標として、商談の感触やオンボーディングの課題を共有し、一貫した顧客体験を設計しましょう。この連携が強まるほど、チャーンは自然と減少し、持続的な成長が実現します。 まとめ LTVとチャーンレートは、一見すると無機質な数字の羅列に思えるかもしれません。しかしその本質は**「いかにお客様に愛され、役に立ち続けられているか」**という、非常に人間味のある指標です。 SaaSビジネスの仕組みを学び始めた今、この視点を持てることは大きな強みになります。ただ認知を広げるだけでなく、その先にいるお客様がサービスを使いこなし、成功している姿を想像してみてください。その想像力こそが、将来的にあなたを「事業を育てるマーケター」へと成長させます。 まずは自社の数字を知り、現場の声に耳を傾けることから始めてみましょう。あなたの小さなアクションの積み重ねが、数年後の大きな事業成長を支える柱になるはずです。 --- ## SaaS成功の鍵「BizDevOps」とは？「課金モデルの変更」で終わらせない組織文化の作り方 URL: https://saasus.io/blog/saas-bizdevops-culture Date: 2026-05-20 「月額課金にすれば、毎月安定した売上が積み上がっていく」。SaaSビジネスに対して、そのような「ストックビジネス」としての魅力を感じて参入を検討される方は多いでしょう。 確かに収益の積み上げはSaaSの大きな武器ですが、それはあくまで結果論に過ぎません。SaaSの本質は、課金方法の違い以上に、利益が発生するタイミングが「販売時点」から「利用期間」へと後ろ倒しになるという構造変化にあります。 この変化は、これまでの開発・営業・運用のやり方を根本から変えることを要求します。従来の「作って売る」ビジネスの常識をそのまま持ち込むと、組織の歯車が噛み合わなくなるのです。本記事では、これからSaaS事業を立ち上げる方が理解しておくべきビジネスプロセスと組織文化の具体的な変化について解説します。 SaaSビジネスモデルの失敗要因：なぜ「課金モデルを変えるだけ」ではうまくいかないのか SaaS事業の立ち上げにおいて最も重要なのは、収益の「時間軸」が変わることを理解することです。従来の売り切り型ビジネスの感覚で「契約数」だけを追いかけると、穴の空いたバケツに水を注ぐような状態になり、事業は決して成長しません。その理由を解説します。 契約獲得は「利益確定」ではなく「投資回収」の始まり 従来のビジネス（SIerやパッケージ販売）では、納品や契約の瞬間が売上のピークであり、そこで開発・営業コストの多くを回収できました。 しかし、SaaSの場合、契約時に得られるのはわずかな初月利用料のみです。多くの場合、CAC（顧客獲得コスト）すら回収できていない「赤字」の状態からスタートします。SaaSにおける契約とは「利益の確定」ではなく、長い時間をかけた「投資回収のスタート地点」に過ぎません。まずはこの前提を直視する必要があります。 顧客が価値を感じなければ、翌月の売上はゼロになる SaaSの最大の特徴は、顧客が「いつでも解約できる」という点です。どんなに苦労して契約を取っても、顧客が「役に立たない」と感じれば、翌月の売上はゼロになります。 「一度売ってしまえばこちらのもの」という考えは通用しません。「毎月、顧客に再評価され続ける」という現実と向き合い、常に価値を提供し続けることだけが、将来の売上を保証するのです。 「使われ続ける」ことこそが、SaaSにおける本当の販売活動 上記のような構造である以上、「使われない機能」や「実態と乖離した期待値」で無理に契約をとっても、回収フェーズに入る前に解約され、自社の首を絞めることになります。 つまり、SaaSにおいては契約書へのサインはゴールではありません。顧客が製品を使いこなし、価値を感じ、契約を更新し続けてくれる状態を作ることこそが、本当の意味での「販売（セールス）」なのです。 【開発の変革】「完成品」ではなく「進化」を納品する SaaSにおいて「継続して利用してもらう」ためには、開発のスタイルも根本的に変える必要があります。具体的には、SIerや受託開発で一般的な「ウォーターフォール型」から、変化に柔軟に対応する「アジャイル型」への転換が求められます。 価値提供に直結する「コア機能」を最速で出す ウォーターフォール型開発では、最初に綿密な要件定義を行い、時間をかけて「100点の完成品」を作り上げてから納品します。しかし、SaaSでこれをやると命取りになります。時間をかけて作った機能が、顧客にとって価値があるとは限らないからです。 もし、1年かけて作った機能が「使いにくい」と判断されれば、その1年分の投資は無駄になり、解約リスクも高まります。 だからこそSaaS開発では、完璧さを捨ててスピードを優先します。「品質（深刻なバグのなさ）は維持しつつ、機能の豊富さは60点でもいいから、まず主要機能だけ（MVP）を市場に出す」。そして、実際の顧客の反応を見ながら、毎週のように改善を繰り返す。このアジャイルなサイクルこそが、顧客満足度を維持し続ける唯一の方法です。 ユーザーの声は「仕様変更」ではなく「成長の種」 従来の開発現場において、リリース後の「仕様変更」や「追加要望」は、手戻りを発生させるネガティブなものと捉えられがちでした。 しかし、SaaSにおいて、ユーザーからのフィードバックは「成長の種」そのものです。「ここが使いにくい」「こんな機能が欲しい」という声は、プロダクトが長く使われるために必要な改善点を教えてくれています。  「仕様変更は極力避けるべきもの」という従来の感覚から、「改善要望は製品を磨くチャンス」という前向きな姿勢へ。このように捉え方が変われば、現場は顧客の声に耳を傾けることを楽しみ、プロダクトはより速く進化していけるはずです。 エンジニアも「ビジネス数値（LTV・解約率）」を見る文化へ 「言われた通りの仕様で、バグなく実装したから終わり」。SaaS開発においては、そこで仕事は終わりません。 作った機能が実際にどれくらい使われているのか？ その機能によって解約率は下がったのか？ エンジニア自身がこうしたビジネス数値に関心を持つ文化が必要です。コードを書くこと自体を目的にせず、「顧客が価値を感じ、使い続けてくれるプロダクト」を作ることをゴールに据える。これは全社で共有すべき姿勢であり、開発チームも例外ではありません。全部署がこの視点を持てるかどうかが、強いSaaSを作れるかの分かれ目になります。 【販売・運用の変革】「契約獲得」よりも「顧客の成功」にリソースを割く 開発プロセスと同様に、販売（セールス）と運用（サポート）の現場でも大きな転換が求められます。SaaSにおいて利益の源泉は「継続利用」にあるため、リソース配分も「いかに売るか」から「いかに使い続けてもらうか」へ大胆にシフトする必要があります。 営業のゴールは「契約」ではなく「定着」への橋渡し 従来の営業スタイルでは、契約書にハンコをもらった瞬間がゴールであり、営業担当者の勝利でした。しかしSaaSでは、その瞬間はまだスタート地点に過ぎません。 もし、営業が目先の数字欲しさに「機能の過大説明」や「ターゲット外の顧客への強引な販売」を行ったらどうなるでしょうか。顧客は導入後にギャップを感じ、早期に解約します。これは前述の通り、会社に赤字を残す行為です。 SaaSにおける営業の真のゴールは、契約獲得そのものではなく、顧客が製品を使いこなし成果を出す「定着（オンボーディング）」の状態へスムーズにバトンを渡すことです。「売れるか」よりも「定着するか」を見極める視座が、営業担当者には求められます。 新規獲得よりも「解約阻止」が利益の最大化につながる 多くの企業が、売上を伸ばすためにまず「新規顧客の獲得」に予算と人員を割きます。しかしSaaSの収益モデルにおいては、「解約率（チャーンレート）を下げること」の方が、利益へのインパクトが大きいケースが多々あります。 穴の空いたバケツに水を注ぎ続けるように、どれだけ新規を獲得しても、既存顧客が流出してしまえば事業は成長しません。 「新規獲得」と「既存維持」。限られたリソースをどちらに優先すべきか迷ったときは、SaaSの鉄則として、まず「既存顧客の解約阻止」に足場を固めるべきです。 「BizDevOps」の実践：開発・販売・運用が「同じ数値」を追いかける組織へ ここまで解説した通り、SaaSビジネスでは全部署が連携しなければ「継続利用」という成果を生み出せません。販売（セールス）、開発、運用（サポート）が三位一体となって価値提供を行う、いわゆる「BizDevOps」の考え方が不可欠です。この連携を確実にするためには、精神論ではなく、組織の構造的な仕組みを変える必要があります。 「売上目標」だけでは部門間の連携がうまくいかない 多くの企業で部門間の対立が起きる原因は、追っている目標（KPI）がバラバラだからです。 例えば、営業が「新規契約数」だけを目標にしていると、多少無理をしてでも契約を取ろうとします。一方で、開発は「リリース数」や「品質」を追っている。 こうなると、営業は「売るためにこの機能が必要だ！」と開発に無理な要求をし、開発は「仕様にないものは作れない」と反発する。その結果、歪みのあるプロダクトが生まれ、板挟みになったカスタマーサクセスが疲弊する……という悪循環に陥ります。 全員が「継続率」を意識すると、意思決定が変わる この悪循環を断つ唯一の方法は、全社員が「継続率（または解約率）」や「LTV（顧客生涯価値）」という共通の指標を意識することです。 もし営業の評価軸に「契約後の継続率」が含まれていれば、無理な売り方はしなくなります。開発も「新機能リリース」だけでなく「既存機能の改善による解約阻止」を評価されるなら、地味でも重要な改善に意欲的に取り組めます。 「自分たちの仕事は、顧客の継続にどう貢献しているか？」という共通の問いを持つことで、初めて部門の利害が一致し、本当の意味でのチームワークが生まれるのです。 まとめ SaaSビジネスへの参入は、単なる収益モデルの変更ではありません。「作って売る」ビジネスから、「顧客と共に成長し続ける」ビジネスへの、組織文化の完全な書き換えです。 開発は「納品」ではなく「進化」を目指す。 営業は「契約」ではなく「定着」を目指す。 そして全社で「継続率」という一つのゴールを追いかける。 この変化は痛みを伴うかもしれませんが、それを乗り越えた先には、安定した収益基盤と、顧客から真に必要とされる強い組織が待っています。それはまさに、ビジネス・開発・運用の壁を取り払い、全社で顧客価値を最大化する「BizDevOps」の体現に他なりません。 まずは、目の前の業務が「顧客の継続利用」につながっているか、チーム全員で問い直すことから始めてみてください。 --- ## ストレージのテナント分離 ~S3バケット単位のサイロ化を試してみた~ URL: https://saasus.io/blog/s3bucket-tenant-silo Date: 2026-05-12 みなさんはどのようにストレージをテナント分離していますか？ また、正しくテナント分離を実装できていますでしょうか。 このブログでは、以前に「テナント分離のための過剰なサイロ化はやめよう」という内容を取り上げたことがあります。 一方で、データの保存要件などによっては、サイロ化を余儀なくされることもあると思います。 今回はAmazon S3を用いた「S3バケット単位のサイロ化」をテーマとし、テナント分離について考察していきます。 S3バケット単位のサイロ化は現実的か まず、S3バケット単位のサイロ化とはどういうことでしょうか？ 今回は、1つのAWSアカウントの中に、テナントごとのS3バケットが1つずつ作成される、という状況を想定します。 また、コンピューティング層 (以下の図ではEC2が該当します) が共有されているアーキテクチャも、今回の内容に含みます。 ここで、サイロ化にあたって考慮するべき内容の1つに、AWSの「クォータ」という概念があります。 AWSのクォータを確認する AWSのクォータとは、作成できるリソース数やAPIリクエスト数の上限を定めたものです。 今回は1つのAWSアカウント内に、テナントごとにS3バケットを作成するため、「AWSアカウントごとに作成できるS3バケット数」が問題になってきます。 以前は、デフォルトで100、上限緩和により1,000の汎用バケットが作成できるという、かなり小さめのクォータの内容だったため、S3バケット単位のサイロ化を諦めたSaaSもあったのではないかと思います。 しかしながら、2024年のアップデートにより、クォータが以下のように大幅に緩和されました。 デフォルト: 10,000 上限緩和時の最大: 100万 このアップデートを受けて、テナント数が100万以下のSaaSであれば、理論上はS3バケット単位のサイロ化が可能ということになります。 なお、該当のクォータはAWSマネジメントコンソールの 「Service Quotas」から確認できます。以下の画像では、作成できる汎用バケットの上限が10,000であることを表しています。 運用可能性を確認する それでは、実際に100万のテナントがSaaSに登録された際、サービスは運用可能でしょうか？ SaaSの特性の1つに「俊敏性」が挙げられますが、サイロ化によって運用効率が下がり、俊敏性が損なわれるケースは少なくありません。 例えば、テナントのオンボーディング時にはどのように対応するべきでしょうか？ エンジニアが1つ1つのバケットを手動作成することのないように、あらかじめIaCなどを用いた自動化を検討しておくことが望ましいです。 実際にテナント分離を試してみる ここまででS3バケット単位のサイロ化を見てきましたが、サイロ化だけではテナント分離は達成されません。 重要なのは、テナントごとに分けたバケットに対して、他テナントからアクセスできないようにすることです。 今回は以下の2ステップでテナント分離を実現していきます。 バケットの命名 (バケット名にテナントIDを含める) 権限を動的に生成する (IAMポリシーのテンプレート作成) バケットの命名 (バケット名にテナントIDを含める) まずはテナントごとのバケットを作成していきます。 ステップ2の権限管理のため、どのテナントのバケットなのかを識別できる命名にする必要があります。 これには複数の方法が考えられますが、最もシンプルなのが「バケット名にテナントIDを含める」という方法です。 今回は以下のような命名とします。 {{テナントID}}-{{アカウントリージョナル名前空間用のサフィックス}} 上記の「アカウントリージョナル名前空間」は、2026年3月に発表されたS3の機能です。 従来はグローバルで一意なバケット名を設定する必要がありましたが、この機能を使うことで該当アカウントの該当リージョン内で一意であれば良くなります。 実際に tenant001 というテナントIDでバケットを作成してみます。 同様に、 tenant002 でもバケットを作成しました。 また、アクセスの検証用に sample.txt というテキストファイルを両バケットにアップロードしました。 権限を動的に生成する (IAMポリシーのテンプレート作成) 次に、IAMポリシーのテンプレートを作成します。 ここでポイントとなるのが、AWS STSのセッションポリシーという仕組みの活用です。 セッションポリシーは、ベースとなるIAMロールが持つ広範な権限に対し、実行時に特定のテナントIDに一致するリソースのみを許可する「フィルター」として機能します。これにより、単一のコードで全テナントのバケットを安全に扱い分けることが可能です。 今回は、上で作成したsample.txtにアクセスできる権限を付与しますが、バケット名のテナントID部分をプレースホルダーとしておきます。具体的には以下の通りです: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::{{TENANT_ID}}-{{ACCOUNT_ID}}-ap-northeast-1-an", "arn:aws:s3:::{{TENANT_ID}}-{{ACCOUNT_ID}}-ap-northeast-1-an/*" ] } ] } デモ用に、AWSアカウントのIDもプレースホルダーとしています。 また、AssumeRoleを行うため、ベースとなるIAMロールを事前に作成しておきます。 名前は tenant-isolation-demo-role とし、以下のポリシーを与えています(アカウントIDは仮です)。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::tenant*-012345678901-ap-northeast-1-an", "arn:aws:s3:::tenant*-012345678901-ap-northeast-1-an/*" ] } ] } それでは、以下のシェルスクリプトを実行して、バケットへのアクセスを検証します。 このシェルスクリプトは、ログインしたユーザーがS3バケットにアクセスする挙動を模したものです。 使い方は、 ./demo.sh {{自身のテナントID}} {{アクセス先S3バケットのテナントID}} となります(コードは読み飛ばして良いです)。 #!/bin/bash set -euo pipefail TENANT_ID=${1:?Usage: $0 } TARGET_TENANT_ID=${2:?Usage: $0 } REGION="ap-northeast-1" ROLE_NAME="tenant-isolation-demo-role" ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) ROLE_ARN="arn:aws:iam::${ACCOUNT_ID}:role/${ROLE_NAME}" BUCKET="${TARGET_TENANT_ID}-${ACCOUNT_ID}-${REGION}-an" # テンプレートからセッションポリシーを動的生成 POLICY=$(sed -e "s/{{TENANT_ID}}/${TENANT_ID}/g" -e "s/{{ACCOUNT_ID}}/${ACCOUNT_ID}/g" policy-template.json) echo "🔐 セッションポリシー (許可テナント: ${TENANT_ID}):" echo "${POLICY}" echo "" echo "🪣 アクセス先: s3://${BUCKET}/sample.txt" # AssumeRoleでテナント制限付き認証情報を取得 CREDS=$(aws sts assume-role \ --role-arn "${ROLE_ARN}" \ --role-session-name "tenant-${TENANT_ID}" \ --policy "${POLICY}" \ --query 'Credentials' --output json) # 一時認証情報でS3にアクセス OUTPUT=$(mktemp) ERROR=$(mktemp) if AWS_ACCESS_KEY_ID=$(echo "$CREDS" | jq -r .AccessKeyId) \ AWS_SECRET_ACCESS_KEY=$(echo "$CREDS" | jq -r .SecretAccessKey) \ AWS_SESSION_TOKEN=$(echo "$CREDS" | jq -r .SessionToken) \ aws s3api get-object --bucket "${BUCKET}" --key sample.txt "$OUTPUT" > /dev/null 2>"$ERROR"; then echo "✅ 成功: $(cat "$OUTPUT")" else echo "❌ 拒否: $(cat "$ERROR")" fi rm -f "$OUTPUT" "$ERROR" まずは ./demo.sh tenant001 tenant001 としたときの挙動を試します。つまり、tenant001のユーザーがtenant001のバケットにアクセスする場合です。 tenant001用のポリシーが生成され、テキストを取得することができました。 次に ./demo.sh tenant001 tenant002 とし、tenant001のユーザーがtenant002のバケットにアクセスを試みます。 tenant001からはtenant002のバケットへアクセスできませんでした。 このようにして、動的にポリシーを生成することで、テナントごとに作成されたバケットへセキュアにアクセスすることが可能であることがわかりました。 まとめ この記事では以下の2点を検証しました。 AWSの制限が緩和され、テナントごとにS3バケットを作成することは現実的になってきた 動的にIAMポリシーを生成することで、サイロ化されたS3バケットにセキュアにアクセスすることができた また、「運用可能性を確認する」の項目でも述べましたが、テナント数が増えても運用に支障が出ないような体制や仕組みが重要であることにも注意してください。 --- ## エージェントに選ばれるSaaSの条件 ── to Aの設計思想とMCP/CLI URL: https://saasus.io/blog/saas-for-agents-mcp-cli Date: 2026-05-07 「SaaS is Dead」――。この刺激的なワードが、今業界を揺らしています。 しかし、その言葉が指しているのはSaaSというビジネスモデルの終焉ではありません。終わりを迎えつつあるのは、あくまで人間がポチポチと操作するためのUIの部分です。バックエンドに蓄積された業務プロセスやドメイン知識は、むしろAI時代においてこれまで以上にその価値を増していると感じています。 このような中でSaaS業界は、AIエージェント向けのインターフェース「to A（to Agent）」へと市場が傾いてきています。しかし、トレンドとしての概念を理解することと、実務においてエージェントが使いやすいプロダクトを「設計すること」の間には、依然として深い溝が存在します。 本ブログでは、一歩踏み込んだ設計思想の具体の部分を考察していきます。エージェント・ファーストなデータ構造の在り方から、MCPの採用、CLIの評価まで、次世代のto A像について考察していきます。 to Aとは ── 「SaaS is Dead」の再解釈 現在、多くのSaaSは「UIを操作して業務解決（報酬）を得る」モデルですが、ツールの乱立による認知負荷も存在しています。本来の目的は業務プロセスの解決であり、人間によるUI操作はそのための「手段」であり、時にはコストとなります。 昨今、AIのエージェント化が進み、フローは「UI→API→業務解決」から「AI→API→業務解決」へと変容してきていると感じている方も多いのではないでしょうか？ユーザーがClaudeやChatGPT、Cursorといった一元管理プラットフォームなどから指示を出し、AIが各SaaSのAPIを直接叩く形です。 このシフトにおいて、人間による操作を前提とした設計はボトルネックとなってきます。 AIエージェントに選ばれる道具として機能を提供できるか、つまりto Aへの対応が、SaaSプロダクトの生存を左右する戦略的分岐点となってきます。 to Aの設計思想 実装手段を問わず、to Aプロダクトが共通して持つべき設計の根幹は、大きく分けて以下の2つの軸に整理できます。 AIフレンドリーであること 安全であること 前者はエージェントが迷わず動くための構造化された指示書、後者は事故を防ぐためのガードレールに相当します。 ① AIフレンドリーであること：セマンティックなAPI設計 LLMはAPIの名称や説明（description）を読み取り、現在のタスクに最適かを判断します。update_status のような曖昧な命名を避け、言語としての意味（Semantic）を明確にすることが、エージェントの判断精度に直結します。 以下は、AIが理解しやすいAPI定義の例です。OpenAPI（REST APIの仕様をYAML/JSON形式で記述するための業界標準）で書くと、descriptionフィールドにそのままエージェント向けの「使い方の説明」を仕込めます。 yaml # AIが理解しやすいAPI定義（OpenAPI） paths: /invoices/{id}/approve: post: summary: "請求書の承認" description: "指定されたIDの請求書を承認し、支払いを確定させます。実行には経理権限が必要です。" parameters: - name: "id" in: "path" description: "承認対象の請求書ID" required: true ポイントは、summary と description を人間のための補足コメントではなくエージェントへの実行指示書として書き直すことです。権限要件や副作用、実行タイミングの注意点まで明示することで、エージェントは自律的に「このエンドポイントを今呼ぶべきか」を判断できるようになります。 ② 安全であること：エージェントが「壊さない」ための設計 エージェントを業務に組み込む上で、安全性は機能性と同じくらい重要なテーマです。自律的に動くエージェントには、誤操作のリスクが常に伴います。本章では、AIに自律的な操作を任せながらも事故を防ぐ、2つの設計原則を紹介します。 権限スコープの制限：そもそもAIが触れる範囲を絞る 冪等性の担保：リトライしても安全な状態を保つ 権限スコープの制限 本番環境への直接干渉を避け、AI専用のスコープ制限を設ける設計が不可欠です。スコープの実装レイヤーは複数あり、一般的には次の3層を組み合わせます。 APIキー / OAuthスコープ：トークン発行時に「このトークンで何ができるか」を縛る IAM / ロール：ユーザーやサービスアカウントに紐づく権限を制御する アプリケーション層：APIエンドポイント側で「AIエージェント由来のリクエスト」を検知し、追加の検証を行う 下記のJSONは、このうち「AI専用のAPIキー発行時に紐づけるロール定義」のイメージです。require_approval のように、重要な処理にはAPIレベルで人間の承認を要求する（Human-in-the-loop）フラグを仕込んでおくと、自律性と安全性を両立しやすくなります。 json // AI専用APIキーの権限スコープ定義例 { "role": "ai_agent_limited", "permissions": ["read:all", "write:invoices"], "require_approval": ["delete:all", "transfer:funds"], "environment": "sandbox" } 冪等性の担保 AIの運用において、ネットワークエラーやLLMの判断ミスによるリトライは避けられません。同じ操作が何度呼ばれても、結果が一度しか実行されない冪等性の担保は、二重決済などの不整合を防ぐ砦です。 Idempotency-Key を標準実装し、AIのループをシステム側で安全に受け止める必要があります。 typescript // 冪等性を担保するAPI実装の簡潔なイメージ app.post('/api/orders', async (req, res) => { const key = req.headers['idempotency-key']; // 既に処理済みのキーであれば、保存されている前回の結果を返す const existing = await db.orders.findUnique({ where: { key } }); if (existing) return res.status(200).json(existing); // 新規処理を実行 const order = await db.orders.create({ data: { ...req.body, key } }); return res.status(201).json(order); }); エージェントは人間と違い、タイムアウトや一時的なエラーに対して機械的にリトライを繰り返します。冪等性の設計が甘いと、その「機械的なリトライ」がそのまま業務上の事故に直結します。 to Aを実現するインターフェースの種類 ── MCP vs CLI ここまで設計思想の話をしてきましたが、to Aを実装する際に最終的に問われるのは「エージェントとSaaSをどう繋ぐか」というインターフェース選定です。 重要な前提として、to AのコアはあくまでAPIです。MCPもCLIも、それ自体が業務ロジックを持つわけではなく、APIをエージェント向けにラップする方法の違いに過ぎません。問われているのは、そのラッパーの形をどう選ぶかです。 ここでは現在有力な2つの選択肢、MCP（Model Context Protocol）とCLIを比較します。 MCPがもたらす「標準化」の恩恵と、運用上の検討事項 エージェントとSaaSを繋ぐ一つ目の手段は、MCPによる標準化です。JSON-RPCを介した「共通言語」により、エージェントは接続した瞬間に機能を理解し、APIドキュメントを読み込ませる手間を省けます。型定義が厳格で、既存のエコシステム（Claude、Cursorなど）との即時接続に優れるため、安定性とセキュリティを重視するエンタープライズ領域では有力な選択肢です。 MCPには大きくローカルMCPサーバーとリモートMCPサーバーの2つの形態があり、近年は後者が主流になりつつあります。AtlassianやNotion、Stripe、Azure DevOpsといった主要SaaSは既にリモートMCPサーバーをホスト提供しており、ユーザーはOAuth認証でログインするだけで利用開始できます。導入のハードルは劇的に下がりました。 一方で、SaaSプロバイダ側にはいくつかの検討事項があります。MCPサーバーを実装・運用する責務を自社で負うこと、リモート提供の場合は継続的なホスティングコストが発生すること、そしてMCPサーバーが提供するツール定義やスキーマ自体が、利用者側のAIエージェントのコンテキストウィンドウ（＝LLMに一度に渡せるトークンの上限枠）を一定量消費することです。MCPは接続時にツール一覧や引数の型情報をエージェントに渡すため、その分だけエージェントの作業領域が圧迫され、結果的にユーザー側のトークンコストや応答品質に影響します。「MCP対応する」という意思決定は、to A戦略の中でも比較的重い投資になります CLIという「シンプルさ」がAIの推論を引き出す 一方で、高度な推論能力を持つ現代のLLMにとって、MCPは時に過保護になりつつあります。そこで再評価されているのが、CLIをツールとして直接エージェントに渡す手法です。 UNIX哲学に基づいた grep や jq をパイプで繋ぎ、標準出力を直接受け取るCLIは、AIにとって最も「試行錯誤」がしやすいインターフェースです。--json 出力や充実した --help さえあれば、AIは自律的にコマンドを組み合わせ、現場の状況に合わせたアドリブの操作を最適化していきます。 bash # AIが自律的にCLIをパイプで繋ぐイメージ # 「直近の顧客5件のメールアドレスを取得する」 $ stripe customers list --json --limit 5 | jq '.data[] | {id, email}' # 必要な情報はすべて --help から自己発見できる $ stripe customers list --help Usage: stripe customers list [options] --limit A limit on the number of objects to be returned --json Output results in JSON format ... エージェントは --help を読んで使い方を学び、--json で機械可読な出力を受け取り、jq でフィルタする ── この一連の動作はLLMにとって極めて自然です。SaaSプロバイダ側も、既存のCLIに --json フラグと丁寧な --help を整備するだけで済むため、MCPサーバーの構築・運用と比べて初期投資を大幅に抑えられます。 「Push型の定義」から「Pull型の探索」への転換 この対立の本質は、AIを「APIを叩くクライアント」と見るか、「OSを操作するユーザー」と見るかの思想の違いにあります。 MCPはサーバー側が見せられるデータを事前に定義して提供するPush型ですが、CLIはエージェントが必要な情報を自ら cat や grep で探しに行くPull型です。WasmやFirecrackerといった軽量サンドボックス技術により、AIに汚してもいい実行環境を瞬時に提供できるようになった今、構造化された不自由さよりも、非構造化な自由度を推論能力で乗りこなす方が、開発速度と柔軟性において勝るケースが増えています。 もちろんこれはどちらかが絶対的に優れているという話ではなく、プロダクトの性質と顧客層によって最適解は変わります。エンタープライズ向けで監査性・セキュリティが最優先ならMCP、開発者向けで柔軟性・速度を重視するならCLI、というのが現時点での大まかな目安だと考えられます まとめ to Aへの転換は、単なるトレンドではなく、ソフトウェアの「あり方」そのものの再構築だと感じています。 設計思想のレベルでは、セマンティックなAPI設計と、権限・冪等性による安全性の担保が、すべてのto Aプロダクトに共通する土台になります。その上で、MCPとCLIという具体的なインターフェース選定が、プロダクトの性質に応じた次の意思決定として待っています。 私たちが問われているのは「人間への見せ方」ではなく「機械への伝え方」の質です。このブログが、あなたのプロダクトを次世代のスタンダードへと引き上げる一助となれば幸いです。 参考文献 ITソリューション塾：SaaSの次の形：AIエージェントが操作する「to A」の世界（ITmedia） --- ## SaaSにおけるインサイドセールスの真の重要性とは？LTVを最大化する戦略的ナーチャリングのポイント URL: https://saasus.io/blog/saas-inside-sales-strategic-nurturing-ltv Date: 2026-04-30 「リードへの架電が追いつかない」「商談は設定できるが受注に繋がらない」……。多くのSaaS企業が直面するこの課題は、インサイドセールスを単なる「アポ取りのための作業部隊」と定義していることに起因しているかもしれません。 サブスクリプションモデルであるSaaSにおいて、インサイドセールスの重要性は単なる効率的な分業に留まりません。顧客の属性やプロダクトの利用状況を読み解き、最適なタイミングで価値を届ける「戦略的ナーチャリング」こそが、その本質です。本記事では、エンジニア向けアプローチの最適化やユーザーメトリクスの活用など、実務に即した高度なインサイドセールス戦略を、最新の統計データとともに解説します。 なぜ今、SaaSにおいてインサイドセールスの「定義」をアップデートすべきなのか 「アポ数」だけを追う組織が陥る、負のスパイラル 多くのSaaS企業において、インサイドセールスのミッションは「いかに多くの商談をフィールドセールスに供給するか」という一点に集約されがちです。しかし、この「アポ数」というKPI（重要業績評価指標）のみを追いかける姿勢が、実は組織全体に負のスパイラルを招いているケースは少なくありません。 数だけを目標にすると、インサイドセールスは「今すぐ話を聞いてくれるか」を優先してしまい、結果として質の低い商談が営業リソースを浪費させます。さらに、検討度合いが低い時期の強引な架電は、ブランド価値を毀損させるリスクを孕んでいます。 SaaSの成長エンジンは「成約数」ではなく「LTV（顧客生涯価値）」にある B2B SaaSにおける新規顧客獲得コスト（CAC）は年々上昇しており、2025年の調査では前年比で14%増加したと報告されています（出典：Benchmarkit「2025 B2B SaaS Performance Metrics」）。この状況下で重要なのは、目先の成約数ではなく、顧客がどれだけ長く使い続けてくれるかを示す「LTV（顧客生涯価値）」です。 インサイドセールスが「自社プロダクトで成功できる見込みの高い顧客」を見極め、質の高い商談を創出することは、解約率（チャーンレート）の抑制に直結します。 インサイドセールスのパラダイムシフト これからの時代に求められる「現代型インサイドセールス」の姿を、従来型と比較して整理しました。 主要な評価指標（KPI）の転換 従来型： 架電数・アポ獲得数（「行動量」と「数」の追求） 戦略的： 有効商談数・受注寄与度（「成約への貢献度」と「質」の追求） アプローチ手法の変化 従来型： 一律のスクリプトによる「点」のアプローチ 戦略的： プロダクト利用ログに基づく、文脈を捉えた「線」の提案 コミュニケーションチャネルの最適化 従来型： 電話主軸（オフィス代表番号への架電） 戦略的： 個別メール・SNS・非同期コミュニケーションのマルチチャネル活用 組織としての役割定義 従来型： 営業プロセスにおける分業・効率化のためのツール 戦略的： 顧客体験を最適化し、LTV（顧客生涯価値）最大化を担う戦略的ハブ ターゲットに合わせた「チャネル選定」：エンジニア向けアプローチを例に 「電話を嫌う層」にどうリーチするか？リモート時代の接続率の壁 現代のSaaS市場、特にエンジニアをターゲットとするプロダクトでは、従来の「架電モデル」が通用しなくなっています。 2025年後半の調査では、若手ビジネスパーソンの約80%が電話に対して苦手意識を持っており、知らない番号に出ない理由の第1位は「営業電話への警戒」でした（出典：Graffer「電話とAI自動音声の活用に関する意識調査」）。さらに、エンジニアの多くがリモートワークを継続しているため、会社代表番号への接続率は2020年比で約65%減少しています（出典：amptalk「営業コミュニケーション実態調査」）。ターゲットのワークスタイルに合わせ、メール等の非同期コミュニケーションを主軸に置く柔軟性が不可欠です。 評価指標の転換：「架電数」から「接続数・ヒアリング数」へ 電話が繋がりにくくなっている現状では、活動を「架電数（行動量）」だけで評価するのは危険です。むしろ、どれだけ実質的なコミュニケーションが発生したかを示す「接続数」や、課題の深掘りができた「ヒアリング数」をKPIにセットすべきです。 量（Activity）ではなく、質を伴う接触（Engagement）にフォーカスすることで、メンバーは「どうすれば相手の反応を引き出せるか」という戦略的な思考へとシフトできるようになります。 定型文を脱却し、コンテキストを込めた「個別メール」の価値 電話での接続が難しいターゲットに対し、強力な武器となるのが「個別メール（1to1メール）」です。 「なぜ今、あなたに連絡したのか」という文脈（コンテキスト）を言語化し、「貴社の技術構成を拝見し、現在の課題に対し弊社の機能が解決の糸口になると考えました」といった、相手の状況に深く踏み込んだ内容は、リテラシーの高い層に非常に高く評価されます。 プロダクト活用データ（PQL）を起点にした「文脈営業」の実践 「熱量」は行動に現れる：ユーザーメトリクスから読み解く商談の好機 プロダクトの利用状況から商談の好機を探る「PQL（Product Qualified Lead）」の考え方が、現代のインサイドセールスでは主流となっています。具体的なPQLの閾値（しきいち）の設定例は以下の通りです。 アクティブ状況： フリートライアル開始後、14日間で5回以上のログイン。 組織内展開： ユーザー自身がチームメンバーを3名以上招待。 重要機能の活用： 「API連携設定」など、プロダクトの核となる機能の初回セットアップ完了。 リアクティベーション： 30日以上未ログインだった休眠ユーザーが、新機能ドキュメントを3分以上閲覧。 これらをフラグ化し、インサイドセールスがリアルタイムに把握することで、「お困りごとはありませんか？」ではなく「〇〇の設定でお悩みではないですか？」という、一歩踏み込んだ提案が可能になります。 データ活用がもたらす「押し売り」からの脱却 データに基づいたアプローチが定着すると、営業は「推測」から「確信」へと変わります。例えば、特定の機能でエラーを繰り返しているユーザーがいれば、それはサポートが必要なタイミングです。 こうした「顧客の状況に寄り添うアプローチ」は、特に業務の合理性や効率性を重視する開発現場の担当者にとって、一方的な営業活動ではなく「有益な情報提供」として受け入れられやすい傾向にあります。 戦略的インサイドセールス組織を構築するための3ステップ 1. 評価軸を「有効商談数・受注寄与度」へシフトする まずはKPIの再定義です。ターゲットの特性に応じて「接続数」や「メールからのヒアリング数」といった指標を組み合わせ、メンバーの意識を「アポ取り」から「顧客の課題解決」へと向かわせましょう。 2. プロダクト開発チームと「顧客の声」を共有する インサイドセールスが得た「商談化前の顧客の生の声」を、プロダクト開発チームへフィードバックする仕組みを作ります。これにより、プロダクトのUI/UX改善やオンボーディング資料の拡充が促進され、プロダクト自体の「売りやすさ」も向上します。 3. 現場の武器となる「データ基盤」の整備 高度な戦略を支えるのは、適切なデータ基盤です。特にマルチテナント型のSaaSをスケールさせる過程では、ユーザーごとのメトリクスを収集・分析し、ビジネスサイドが使いやすい形で提供する共通基盤の存在が不可欠です。こうした基盤を整えることで、インサイドセールスが科学的に動ける組織を迅速に構築することが可能になります。 まとめ SaaSにおけるインサイドセールスは、もはや電話をかける部隊ではありません。顧客の属性を理解し、プロダクト活用データという顧客からのシグナルを的確に捉えることで、信頼を積み上げる「戦略的パートナー」へと進化しています。 今回ご紹介したユーザーメトリクスの活用を第一歩として、ぜひ「量」から「質」、そして「顧客の成功」にフォーカスした組織への一歩を踏み出してください。その積み重ねが、揺るぎない事業成長の基盤となるはずです。 --- ## SaaSpocalypseとは？「SaaS is Dead」の誤解と、AI時代におけるSaaSの価値 URL: https://saasus.io/blog/truth-about-saaspocalypse-saas-is-dead Date: 2026-04-20 「SaaSpocalypse（SaaSポカリプス）」あるいは「SaaS is Dead」という言葉を近年のテック業界のカンファレンスやSNSで目にすることが増えてきました。生成AIの急速な普及により、従来のSaaSが提供してきた価値が相対化され、これまでのビジネスモデルが崩壊するのではないかという懸念が背景に生まれた言葉だと考えられます。 確かに、AIエージェントが複数のツールをまたいで検索し、入力し、更新までやってのけるようになると、「もうアプリ画面は要らないのでは」「SaaS事業者は先細るのでは」と感じてしまうのも頷けます。利用者の目線でも、「いま使っているSaaSへの投資は無駄になるのか」という不安があるはずです。しかし、結論から言えば、SaaSは死ぬのではなく、「再定義」のプロセスに入ると考えられます。これからのSaaSの未来で起こるのは「SaaSが死ぬ」ことではなく、「SaaSに求められる価値の水準が一段上がり、そこに届かないSaaSが使われなくなる」ことです。 本記事では、SaaSpocalypseの正体を解き明かすとともに、AI時代にむしろ拡大するSaaSの真の価値について深掘りします。なぜ、特定のSaaSが淘汰され、一方で特定のSaaSが不可欠なインフラとして再評価される未来が予想されるのかについて考察します。 SaaSpocalypseとは何か この言葉が広がる背景には、実は性質の異なる複数の変化が同時に起きていることがあります。 一つ目は、ソフトウェアの形そのものが変わるという話です。私たちは「ソフトウェア」と聞くと、つい「画面」を思い浮かべます。検索して、画面を行き来して、フォームに入力して、転記する。その仕事をエージェントが代わりにやれるなら、「画面の価値が下がる」のは当然のことです。 しかし、SaaSの本質は画面だけではありません。SaaSは本来、継続的に更新される業務基盤です。顧客情報や契約履歴、権限設定、ワークフロー、他システムとの接続、監査や運用の責任まで含んでいます。画面はその入口にすぎません。 つまり、SaaSの本質を正しく捉えた上で考えるのならば、SaaSpocalypseは「SaaSが終わる」という意味にはなり得ません。正確に表現するのであれば「画面の便利さだけでは、もう差別化にならない」という局面を指す言葉です。「SaaS is Dead」も同様に、AI時代におけるSaaSのあり方の変遷を示したものと言えるでしょう。 二つ目は、株式市場の急激な反応です。2026年2月、AIエージェント製品のデモをきっかけにSaaS銘柄が急落しました。Forresterが2026年2月に発表したレポート『SaaS As We Know It Is Dead』では1週間で1兆ドル超の時価総額が消失したと報じています。これは「SaaSのビジネスモデルが終わる」という話ではなく、AIエージェントの台頭によってSaaS企業の参入障壁が下がり、成長率が鈍化するのではないかという投資家の反応です。 そして三つ目は、ソフトウェアの開発コスト構造が変わるという話です。AIによって開発の生産性が劇的に上がれば、これまで膨大な投資で積み上げてきたソフトウェア資産を、はるかに少ないコストで再現できる後発プレイヤーが現れます。既存SaaSの価格優位性や参入障壁が揺らぐ構造変化です。 これらは関連していますが、同じ話ではありません。技術の変化、市場の反応、競争構造の変化。この3つが同時に語られるので「SaaSpocalypse」や「SaaS is Dead」という言葉が必要以上に混乱を生んでいます。 SaaSの明暗を分けるもの では、AI時代にSaaSの明暗を分けるのは何でしょうか。4つの側面において検討します。 ①独自のデータと業務文脈を持っているか 最も根本的な分かれ目はここです。そのSaaSにしか存在しない「独自のデータ構造」や、業界特有の「泥臭い業務ロジック」を持っていなければ、LLM（大規模言語モデル）があらゆる汎用タスクをこなせる以上、AIエージェントにその座を奪われるのは時間の問題でしょう。 逆に、固有のナレッジ、顧客固有のデータ、承認ルール、履歴、責任の境界、業務の前後関係を蓄積しているSaaSは、エージェント時代でもただのUIにはなりません。WorkdayがAgent System of Recordを打ち出しているのは、まさにこの軸で勝負する宣言です。これはベンダーロックインの話ではありません。そのSaaSを止めたときに「業務が回らなくなるデータと文脈」があるかどうか、という話です。 単にデータを右から左へ流すだけの、あるいは既存のデータベースにUIを被せただけの「薄いSaaS」は、エージェントが直接APIを叩けるようになれば経由する理由が薄れます。 ②ワークフローを実行できるか、エージェントから呼び出せるか 情報を見せるだけでなく、承認、更新、起票、手続きの一連の実行まで担えるかどうか。顧客が本当にお金を払うのは、表示ではなく前進です。SalesforceがAgentforceをFlowsやApexにつないでいるのは、この条件を重視している例になるでしょう。 ここで重要なのは、エージェントがSaaSにアクセスするインターフェースがREST APIだけとは限らないことです。CLI（Command Line Interface）によるバッチ処理や自動化スクリプトとの連携、さらにはMCP（Model Context Protocol）のようなAIエージェント向けの標準プロトコルへの対応も視野に入ります。MCPは、AIエージェントが外部のツールやデータソースと安全にやり取りするための共通規格として注目されており、対応することでエージェントから「呼び出される側」としての間口が一気に広がります。API・CLI・MCPといった複数のインターフェースを整備し、エージェントが自社SaaSの機能を呼び出せる状態を作ることが、ワークフロー実行力の土台になります。 ③権限、監査、責任を持てるか エージェントが動いても、誰の代理で何を実行し、どのログが残り、どの統制で守られるかが明確でユーザーがコントロール可能であること。ここが弱いと、AIは便利でも意図しない挙動や操作のリスクから業務には乗せにくくなります。 ④シート数ではなく成果で価値を説明できるか エージェントが複数人分の操作を肩代わりし始めると、「何席使っているか」より「どれだけ仕事が進んだか」のほうが自然な問いになります。実際、SalesforceはFlex CreditsやConversationsなど複数の価格モデルを出し始めていますし、IntercomのFinは成果課金を前面に打ち出しています。 誤解のないように言えば、シート課金がすぐ消えるという話ではありません。現時点では、主要ベンダーの一部が座席課金と成果課金を併用し始めた段階です。ポイントは、席数以外に価値の説明ができないSaaSが苦しくなる、ということです。 大手と中小で事情は異なる これらの条件に当てはまらないSaaSは、大手よりも中小規模のベンダーに多いかもしれません。大手は業務データやワークフローの蓄積があるぶん、エージェント時代への転換余地があります。一方、画面操作や単純連携だけで勝負していた中小SaaSは、転換の足場自体が薄いことがあります。もっとも、規模が小さくても特定業務の深い文脈やデータを握っているSaaSは話が別です。明暗を分けるのは会社の大きさではなく、本セクションで検討した4つの側面において十分な価値が提供できているかです。 SaaS提供事業者のこれからとは 見落とされがちですが、AIが強くなるほど、条件を満たすSaaS提供事業者が出せる価値も深くなりえます。悲観すべきは「SaaS」ではなく、「形だけのSaaS」です。 提供事業者にとっての希望は、AIがプロダクトを空洞化するのではなく、「どの業務結果まで責任を持てるか」を問い直す機会になることです。顧客固有のデータを持ち、業務フローを回し、実行責任まで引き受けられるSaaSには、まだやれることがあります。 前述のSalesforceがAgentforceをData Cloudや既存のFlows、Apex、APIにつないでいるのは、AIを別物として載せているのではなく、もともとの業務基盤をエージェントの実行土台に変えているからです。WorkdayがAgent System of Recordを打ち出しているのも同じ発想で、エージェントの世界でも「誰が何をし、どこまで権限があり、どう追跡するか」を握る基盤は価値を持ち続けます。 提供事業者にとって、より深い差別化の源泉は「AI機能を足すこと」そのものではありません。AIがどの業務データを握るか、どのワークフローを回すか、どの結果まで責任を持つか。この3つをどこまで深くできるかです。 言い換えれば、AI時代の希望とは、SaaSが「便利な画面」から「業務を前に進める実行基盤」へ進化できることにあります。 もうひとつ、見方を変えれば、開発コストの低下はこれからSaaSを作る側にとっての追い風でもあります。これまで大手の牙城だった領域に、より安く、よりエージェントフレンドリーな設計で参入できる余地が生まれています。同等の機能をより低コストで、かつエージェントから操作しやすい形で提供できるプロダクトが現れれば、既存プロダクトからの移行の可能性も十分にあり得ます。 顧客の期待が変わる — 提供事業者が適応すべき新しい選定基準 提供事業者が見落としてはいけないのは、顧客側の期待そのものが変わりつつあることです。SaaSpocalypseやSaaS is Deadという言葉が広がるなかで、顧客は「ツール選定をやり直すべきなのか」と疑問を抱いているかもしれません。その裏にあるのは「もっと少ない操作で、もっと早く成果に近づきたい」というシンプルな欲求です。 つまり、顧客がSaaSに求めるものが変わります。「いくつの機能があるか」ではなく、どれだけ操作を減らせるか、どこまで安全に任せられるか、どの成果に近づけるか。ベンダー選定の軸が「機能の数」から「業務がどれだけ前に進むか」へ移っていきます。 IntercomのFinが成果課金で価値を見せているのは、この変化に先回りした例です。顧客が求めているのは「AIが入ったこと」ではなく、「問い合わせ対応がどれだけ早く終わるか」「人手をもっと大事な仕事に戻せるか」です。Atlassian RovoやMicrosoft Dynamics 365が見せているのも同様で、自社のナレッジや業務データに安全につながることで、「検索して貼り付ける」仕事から顧客を解放しています。 提供事業者にとっての示唆は明確です。顧客は「便利な画面」ではなく「業務の前進」にお金を払うようになります。この変化に適応できないSaaSは、機能がどれだけ豊富でも選ばれにくくなるでしょう。 まとめ SaaSのあり方が変わるということは、自社プロダクトの「コア」を問い直す機会が来たということです。画面の使いやすさや機能の多さではなく、自社のSaaSが握っているデータ、回しているワークフロー、引き受けている責任のどこに本当の価値があるのか。それを言語化し、AIエージェントが活用できる形で顧客に届けられるかどうかが、これからの分かれ目になります。 SaaSpocalypseは脅威ではなく、問いです。「自社のSaaSは、画面がなくなっても顧客に選ばれるか？」。この問いに自信を持って答えられるプロダクトを作ること。それが、AI時代のSaaS事業者に求められる最初の一歩です。 --- ## 成長投資を阻む「個別最適化」の罠 なぜ今、SaaSというビジネスモデルが必要なのか URL: https://saasus.io/blog/pitfalls-of-individual-optimization-in-saas Date: 2026-04-15 「個別最適化」モデルが招いたビジネス成長の停滞 自社の業務に合わせた「個別最適化」のシステムは、長らくビジネスの現場で理想とされてきました。しかし、「システムの維持・運用に予算や人員が割かれ、新たな成長施策にリソースを回せない」と悩む企業は少なくありません。 現在、ビジネスソフトウェアの主流は、オンプレミス環境での買い切り型から、クラウド経由で利用する「SaaS（Software as a Service）」へと大きく移行しています。しかし、これは単なる技術的な変化ではありません。SaaSへの移行は、本質的に、継続的な価値提供を前提とする「サブスクリプション型のビジネスモデル」への転換を意味しています。 本記事では、なぜ従来の個別最適化モデルが限界を迎えたのか、そしてSaaSとサブスクリプションの両輪がどのようにベンダーと顧客双方に「持続的な価値」をもたらすのかを紐解きます。 維持費が増大する理由：カスタマイズが招く『技術的負債』とコスト構造 パッケージシステムの導入においては、「個別最適化」、すなわち特定の顧客企業の特殊な業務プロセスや既存システムに合わせてソフトウェアを深くカスタマイズすることが一般的でした。カスタマイズすることは、当時の企業にとって、自社の固有の課題を解決するための最適な選択肢の一つとして広く受け入れられていました。 しかし、カスタマイズ費用を含む多額の導入費用をかけて構築されたシステムは、その個別性ゆえに、ベンダーが提供する標準的な機能アップデートやセキュリティ対応の恩恵を受けにくくなるという構造的な問題を抱えます。市場の変化や技術の進化が起きても、この「個別最適化」されたシステムを更新するには、その都度、相応の追加費用と工数を要しました。結果として、本来であれば企業の成長や変革のために使われるべき予算や人的リソース(日本企業のIT予算の約8割)が現行システムの維持管理に費やされていると言われています（出典：経済産業省『DXレポート』）。この構造こそが、企業の機動性や競争力に影響を及ぼす一因となっているのです。 ベンダー：持続的な価値創出を妨げたビジネスモデル上の構造 顧客企業が直面していた「維持管理へのリソース偏重」の問題は、ソフトウェアベンダー側の持続的な価値創出を妨げる構造に直結していました。顧客ごとに個別最適化されたシステムを抱えるベンダーは、多数のコードベース（システムのソースコード管理単位）を管理しなければなりません。 これにより、開発リソースの大部分が、市場全体に向けた革新的な機能開発よりも、既存顧客ごとの特殊な保守対応や個別アップデートに分散してしまうことになります。こうしたリソースの分散は、結果として製品全体の進化スピードを鈍化させ、ベンダー側の管理コストを高止まりさせる要因となります。そして、かさんだコストは、最終的にライセンス費用や保守費用として価格に反映せざるを得なくなるため、顧客側のシステム維持コストも高くなるという、双方にとって負担が増す循環を生むリスクが高まっていたのです。ベンダーの収益源が「一過性のライセンス販売」に大きく依存し、「顧客の成功」よりも「販売完了」に焦点が当たりやすいというビジネスモデルそのものに、持続的な成長のための限界があったのです。 このように、個別最適化モデルは顧客とベンダー双方を疲弊させる『負のサイクル』に陥っていました。この構造的な行き詰まりを打破し、双方が持続的に成長するために必然的に求められたのが、SaaSという提供形態へのシフトであり、それは本質的にサブスクリプションという新たなビジネスモデルへの転換を意味していました。 顧客価値の最大化を追求した結果としてのサブスクリプションモデル SaaSの導入や提供に向き合うということは、単にクラウドツールを扱うということではなく、『サブスクリプション』というビジネスモデルそのものに向き合うことと同義です。 SaaSのメリット：ベンダーとの『利害の一致』が品質向上を保証する理由 SaaSの根底にあるサブスクリプションモデルへの移行がもたらした最大の変革は、ベンダーと顧客の間に強固な「利害の一致」を生み出した点にあります。従来の買い切り型モデルでは、ベンダーのゴールは「製品を納入すること」になりがちでしたが、サブスクリプションモデルでは、顧客に継続して利用してもらうことが収益の基盤となります。 これにより、ベンダーと顧客の関係性は大きく変わりました。ベンダーが自社のARR（年間経常収益）を維持・成長させるためには、顧客による解約（チャーン）を何よりも避けなければなりません。顧客がサービスを利用してビジネス上の目的を達成し続けることができなければ、契約は維持されないからです。つまり、顧客の事業成長（成功）なしには、ベンダー自身の成長も成り立たないという「共存共栄」の関係が、ビジネスモデルの中に構造的に組み込まれているのです。このパートナーシップのような関係性こそが、顧客に対して常に使いやすく、価値ある機能が提供され続けるための保証となります。 普遍的価値の提供と、市場全体で進化する高速なフィードバックサイクル SaaSモデルでは、原則としてすべての顧客が単一のコードベース（同じプロダクト）を利用します。かつては自社の業務にシステムを合わせる「個別最適化」が最適解とされていましたが、SaaSは多様な顧客が利用する中で常に「業界のベストプラクティス」を吸収し、標準機能として昇華させ続けています。そのため、企業側もあえて「個別最適化」を捨て、自社の業務プロセスをSaaSの標準に合わせていく「Fit to Standard」のアプローチをとることで、最新のノウハウを享受できるのです。 こうして標準化された「普遍的価値」を提供することで、ベンダーは開発リソースを一点に集中させることができます。これにより、ある一社の顧客から得られたフィードバックや改善要望が、機能アップデートとして即座にすべての顧客に反映されるようになります。 これは、一社の知見が市場全体の知見としてプロダクトに還元される、いわば「集合知による高速な進化」です。個別にカスタマイズされたシステムでは数年かかったような機能追加が、SaaSでは数週間、あるいは数日で実装されることも珍しくありません。 このように、SaaSは常に市場の最先端のノウハウを取り込みながら進化し続けるため、導入企業は「システムの陳腐化」を恐れることなく、本来の業務価値向上に集中できるのです。 まとめ かつて「個別最適化」は、企業の独自性を守るための盾でした。しかし、変化の激しい現代において、最も重要なのは「現在の最適を固定」することではなく、市場や顧客の要望に合わせて最適化し続けることです。 ソフトウェアからSaaSへの移行は、単なるシステムの置き換えや支払い方法の変更ではありません。SaaSに向き合うことは、すなわち『ビジネスモデルの転換』に向き合うことであり、ベンダーと顧客が「ビジネスの成功」という共通のゴールに向かって走り続ける、新しいパートナーシップへのシフトなのです。もし今、システムの維持管理が成長への投資を圧迫していると感じるなら、SaaSという選択肢を検討することは、貴社のビジネスを次のステージへ進めるための大きな一歩となるはずです。 --- ## 【導入事例】株式会社オルタナティブ URL: https://saasus.io/blog/alt-nat Date: 2026-04-10 「作らなくていいもの」を見極め、本質に集中する。 「デジタルの力」と「オルタナティブな発想」で、地域の可能性を無限にする ー今回開発された「KAMUY（カムイ）」について、サービスの概要と、開発に至った経緯を教えていただけますか？ 谷藤さん： 私たちは「デジタルの力とオルタナティブな発想で挑戦する企業と人の可能性を無限にする」という理念を掲げ、ITコンサルティングやDX支援、システム開発を幅広く展開しています。私自身のエンジニアとしてのキャリアは食材卸会社の情報システム部門から始まりましたが、一貫して大切にしているのは「システムを作ること自体を目的にしない」ということです。経営と現場の双方が、ITを意識せず「自然に使える」状態こそが理想であり、それを成し遂げるための現場の業務理解を前提とした一気通貫の支援を強みとしています。 今回開発した「KAMUY」は、新聞販売店向けのAIコンタクトセンターSaaSです。きっかけは、ある販売店経営者様からの「早朝の電話対応や人員確保が限界に近い」という切実な相談でした。新聞販売店では今も電話・FAXが主要な顧客連絡手段で、早朝の未配達問い合わせへの対応や、顧客対応履歴が残らないといった課題が深刻です。新聞配達は地域の見守り役も兼ねる重要な社会インフラですが、現場は今、深刻な人手不足とアナログな業務に悲鳴を上げています 。こうした「地域のラストワンマイル」を支えるインフラをデジタルで再構築することが、「KAMUY」の原点です 。 AIを活用して電話対応を自動化し、問い合わせをデータ化して可視化できる仕組みを作れば、販売店の業務を持続可能な形に進化させられると考えました。最初は一つの販売店向けの業務改善として最小機能で開発を行いましたが、全国に向けて紹介したところ大きな反響があり、SaaSとして全国展開するプロダクトへと発展していきました。 ーSaaSとして立ち上げるにあたって、どのような課題に直面されましたか？ 谷藤さん： 最大の課題は、限られた開発リソースを「どこに集中させるか」という点でした。「KAMUY」は、デジタルに不慣れな従業員やお客様も利用するサービスです。そのため、AIの応答精度や直感的な操作性といった「コアな価値」のブラッシュアップに、可能な限り時間を割きたいと考えていました。 しかし、SaaSとして提供するためには、マルチテナント対応のデータベース設計、ユーザー認証、契約管理、請求処理といった共通基盤が不可欠です。これらは「あって当たり前」の機能ですが、自前で作るとなると膨大な工数がかかります。専門知識が必要な上に工数も読みづらく、スタートアップである我々にとって大きな重荷になっていました。 私自身、過去に多くのシステム開発に関わってきた中で、「開発側が納期に追われ忙殺されると、どうしても完成させることが目的になって、UI/UXが後回しになり、現場で使われないシステムになってしまう」という場面を何度も見てきました。私たちが目指す、「ITを意識せず「自然に使える」状態」を実現するには、限られたリソースの中でサービスの価値を最大化するということが不可欠でした。 SaaSは魅力的なビジネスモデルであり、個人的にもずっとやりたかったことでしたが、一方で、技術的にもビジネス的にも難易度が高いものだと考えていました。また資金調達や急拡大する組織、熾烈な開発競争なども非常に厳しい世界だと考えています。私たちは巨大なSaaS企業のような戦い方はできません。だからこそ、業界に深く入り込み、バーティカルSaaSとして存在感を出していきたいと考えています。スタートアップの機動力と少数精鋭のメンバーでSaaSを開発・運用していく上で、サービスの本質にフォーカスするというのはとても重要なことだと考えています。 SaaSus Platformによる開発1.5倍高速化の実現 ーSaaSus Platformを知ったきっかけと、導入を決められた理由を教えてください。 谷藤さん： もともと10年ほど前からAWSのイベントに参加しており、AWSのご担当者からSaaSus Platformをご紹介いただいたのがきっかけです。アンチパターンさんとの最初の打ち合わせで、こちらのやりたいことをホワイトボードで鮮やかに整理してくださったのが非常に印象的でした。その後もAWS Summitでお会いする機会があり、プロダクトの構造についての理解をさらに深めていただく中で、私もSaaSus Platformについて知ることができました。 何よりも、SaaSus Platformを提供するアンチパターンさんから「エンジニアを大事にしている企業」という空気感を強く感じたことが大きかった。数多くのSaaS立ち上げに関わってきた知見から「よくある落とし穴」を熟知されている。直感的に「この人たちなら信頼できる」と感じ、すぐに導入を決めました。 ー特にどの点が谷藤様のニーズに合致しましたか？ 谷藤さん： SaaSのコア機能ではない「認証」や「課金」といった共通基盤を、自分たちでゼロから構築することは絶対に避けたかったのです。これらは実装にプレッシャーがかかる一方で、ユーザーから見れば「できて当たり前」の機能であり、サービスの差別化には繋がりません。認証、テナント管理、課金といった共通機能はSaaSus Platformに任せることで、私たちは「KAMUY」のコア機能であるAIコンタクトセンター、問い合わせデータの可視化、現場の使いやすさの向上のための開発に集中できると確信しました。 ー実際に導入してみて、開発工程や期間にはどのような変化がありましたか？ 谷藤さん： もし認証やテナント管理などの共通基盤をすべて自社で開発していたら、今回の約半年という開発期間は、少なくとも1.5倍は延びていたと思います。共通機能をSaaSus Platformに切り出したことで設計がシンプルになり、セキュリティ面での不安も解消されました。 その結果、浮いたリソースをすべて「KAMUY」のコア機能と現場の使い勝手の向上に集中させることができました。私たちが目指したのは、単なるシステムの提供ではなく、現場のストレスをなくす「サービス」の提供です。サービスとしての品質、使用感を追求するには机上の理論だけではなく、実際に使ってみる必要があります。例えば、人間は「読む情報」と「聞く情報」では理解の仕方が異なります。AIの応答タイミングや話し言葉の文言、スピードなど、何度も現場でテストして微調整を繰り返しました。さらに開発の最終盤には、当初の予定にはなかった「AIエージェント機能」も短期間で実装できました。これは、「KAMUY」が「単なるAI電話番」ではなく、現場に寄り添うパートナーであることを伝えるための重要な機能といえます。基盤部分をSaaSus Platformに任せていたからこそ、ギリギリまでコア機能の改善に集中できたと感じています。 今後の展望——地域のラストワンマイルを支えるインフラへ ー今後の「KAMUY」の展開や、貴社が描いているビジョンをお聞かせください。 谷藤さん： まずは「KAMUY」を全国の新聞販売店へ展開することを進めていきます。並行して新聞社ブランドでのOEM提供や共同展開も視野に入れており、その際はSaaSus Platformの強固なテナント管理機能が大きな安心材料になると確信しています。複数ブランドでの運用を想定した設計になっている点は、スケールを考えたときに非常に重要です。 新聞販売店での実証を通じて、これは地域課題であり他業種でも課題があることが見えてきました。「地域のラストワンマイルを担うサービス」「地域DXの実現」を支える基盤システムとして、KAMUYを発展させていきたいと考えています。 札幌のIT業界は受託開発やSESが多いので、「KAMUY」を旗印に自らの手でプロダクトを生み出す動きをもっと盛り上げていきたいと思っています。バーティカルSaaSとして業界に深く入り込み、地域に根ざしながら全国で通用するプロダクトを作る。KAMUYはその挑戦の第一歩です。 ー 最後に、SaaS開発に挑もうとしている企業やエンジニアの方々へメッセージをお願いします。 谷藤さん： SaaSを立ち上げ、継続していくには、相応の覚悟が必要です。だからこそ「自分たちが本当に作るべきものは何か、作らなくていいものは何か」を最初に見極めてほしいと思います。認証や課金といった共通基盤を自前で作ることに時間をかけるのは、必ずしも正解とは限りません。 私は、SaaS開発においては、自社の情熱や強みが詰まった「コア機能」にリソースを集中させることが、結果としてユーザーに愛されるサービスを生む近道になると信じています。信頼できるパートナーやツールを積極的に活用することを、ぜひ検討してみてください。 --- ## マルチテナントSaaSは危険なのか？データ漏洩について考える URL: https://saasus.io/blog/defining-and-protecting-saas-tenant-boundaries Date: 2026-04-08 デプロイモデルとテナントデータ漏洩を正しく理解する マルチテナントSaaSの話をすると、ほぼ必ずと言っていいほど「データ漏洩が怖い」という懸念が出てきます。特にプール型のように複数テナントが同じアプリケーションやデータベースを共有する構成では、「論理分離で本当に大丈夫なのか」という不安が生まれやすいものです。 しかし、ここで重要なのは「リソースを共有しているかどうか」そのものではありません。重要なのは、どこにテナントの境界を置き、どのレイヤーでそれを強制し、事故が起きたときにどこまで影響を閉じ込められるかです。逆に言えば、サイロ型、いわゆるシングルテナントに見える構成であっても、それだけで安全が保証されるわけではありません。 本稿では、マルチテナントSaaSの基本的なデプロイモデルを整理したうえで、なぜテナントデータ漏洩が起こるのか、そしてなぜ「サイロ型だから安全」という理解が危ういのかを考えていきます。 マルチテナントSaaSとは何か SaaSにおけるテナントとは、一般に顧客企業や部署、チームなどの契約単位を指します。SaaS提供事業者は、複数のテナントに対して同じサービスを継続的に提供しながら、それぞれのデータや権限を適切に分離しなければなりません。つまりSaaSとは、単にソフトウェアを提供するだけではなく、運用と分離の責任まで引き受けるサービス型の事業モデルだと言えます。 この時、スケーラビリティや運用効率を得るためには、できるだけ共通のリソースで多くのテナントを扱いたくなります。一方で、共通化を進め過ぎれば、境界の設計やアクセス制御の精度がより重要になります。マルチテナントSaaSにおける設計は、常にこの緊張関係の中にあります。 なお、顧客ごとにアプリケーションだけでなく、契約管理や請求、テナント管理といった管理基盤まで丸ごと複製していくと、共通の運用基盤を持つSaaSというより、MSP的なモデルに近づいていきます。どこまでを共有し、どこからを個別化するのかは、単なる技術論ではなく事業モデルの設計そのものなのです。 デプロイモデルは「安全性」ではなく「トレードオフ」で見る サイロ型 サイロ型は、テナントごとにコンピュートやデータベースを分ける構成です。分離レベルが高く、ノイジーネイバーの影響も受けにくいため、厳しいセキュリティ要件やコンプライアンス要件を持つ顧客には適しています。一方で、テナント数が増えるほど環境数も増え、運用負荷とコストが重くなります。 プール型 プール型は、複数テナントでアプリケーションやデータベースを共有する構成です。クラウドネイティブなSaaSではもっとも基本的な選択肢であり、コスト効率と運用効率に優れます。データ分離の実装としては、行分離、スキーマ分離、データベース分離などがあり、PostgreSQLのRow Level Security(RLS)のような仕組みも有力です。ただし、テナント境界をアプリケーションとデータストアの両方で正しく表現しなければなりません。 ハイブリッド型 実際のSaaSでは、サイロとプールを組み合わせたハイブリッド型もよく採用されます。例えば、コンピュートは共有しつつデータベースはテナントごとに分離する、あるいは通常プランは共有基盤、上位プランだけ専有基盤にする、といった形です。これはセキュリティ、性能、価格、運用のバランスを取るための現実的な設計です。 つまり、どのモデルが「正しい」かではなく、どのリスクをどこまで受け入れ、どのコストを払うのかが重要なのです。 テナントデータ漏洩はどこで起きるのか テナントデータ漏洩は、プール型だから起きるのではありません。多くの場合は、テナントコンテキストの扱いを誤ることで発生します。典型例は、書き込み、読み込み、キャッシュです。 1. 書き込み時のミス 同じワーカーや接続プールの中でテナントコンテキストを曖昧に扱うと、別テナントの領域にデータを書き込んでしまう危険があります。 // NG: テナント情報の受け渡しが暗黙的 $db = getConnection(); $orderRepository->save($db, $order); このような実装では、どのテナントに保存されるべきデータなのかがコード上で明示されません。安全側に倒すなら、リポジトリやデータアクセス層が tenant_id の受け取りを必須にし、保存前に検証するべきです。 // OK: tenant_id を明示的に渡す $orderRepository->save($tenantId, $order); 2. キャッシュによる漏洩 AIとのやり取りやFAQ応答でキャッシュを使う場合、キーにテナント情報が含まれていないと危険です。 NG: cache_key = hash(question) OK: cache_key = tenant_id + user_id + hash(question) 一見便利な共通キャッシュも、テナント境界を失った瞬間に情報漏洩の媒体になります。特に生成AIでは、似た質問に対して高速化のために応答を再利用したくなるため、この論点は今後さらに重要になるでしょう。 3. 読み込み時のミス もっとも典型的なのは、SQLのWHERE句から tenant_id が抜け落ちるケースです。 -- NG SELECT * FROM invoices WHERE status = 'open'; -- OK SELECT * FROM invoices WHERE tenant_id = :tenant_id AND status = 'open'; ただし、アプリケーション側の注意だけに依存するのは危険です。可能であれば、RLSやビュー、権限分離などを活用し、アプリケーション層でミスをしてもデータベース側で越境を防げるようにしておくべきです。境界は一箇所ではなく、多層で守るのが基本です。 サイロ型でも漏洩は起こる 1. 共通アプリケーション脆弱性による漏洩 たとえばRemote Code Execution(RCE)や認証バイパス、Server Side Request Forgery(SSRF)の脆弱性が共通アプリケーションに存在すると、攻撃者は個別テナント環境の外側から横断的に侵入できます。管理APIや内部メタデータ、テナント切替機能に到達されると、別テナント環境への接続情報や一時資格情報を取得される危険があります。サイロ型であっても、同じアプリケーションバージョンを全テナントに配っていれば、脆弱性は全テナントに共通です。結果として、ある脆弱性が「1テナントの事故」ではなく「全顧客横断の事故」になりえます。対策としては、一般的なWebアプリ対策に加えて、コントロールプレーンの分離、Instance Metadata Service(IMDS)v2の活用、最小権限の徹底、Web Application Firewall(WAF)の導入、脆弱性診断、依存ライブラリ更新の継続が必要です。さらに、テナント切替や内部管理機能は通常機能より厳しく監査し、特権操作を多要素認証や承認付きにするなども考えられます。 2. IAM / 認証基盤の侵害による漏洩 ソーシャルハッキングやフィッシング、トークン窃取により、運用者やContinuous Integration(CI)用の認証情報が奪われると、攻撃者はインフラへ正規ユーザーのように侵入できます。この場合、サイロ型でデータベースが個別に分かれていても、十分な権限を持つアカウントなら複数環境を横断して参照できます。特に、全テナント共通の管理者ロール、秘密情報ストア、踏み台、SSO管理画面が侵害されると被害は一気に広がります。「物理的に分かれているから安心」と考えていても、認証の入口が共有されていれば境界は簡単に跨がれます。対策としては、多要素認証の強制、短命資格情報、Just-In-Time権限付与、ブレイクグラス管理、操作監査などが考えられます。加えて、人とシステムの権限を分離し、テナントごとの管理権限も極力スコープダウンする設計が重要です。 3. CI/CD・デプロイパイプライン侵害による漏洩 ビルド環境やGitHub Actions、アーティファクトレジストリ、署名鍵が侵害されると、攻撃者は正規リリースに見える形でマルウェアや不正コードを混入できます。そのコードが監視回避やデータ外送信を行うものであれば、サイロ型で分かれている各テナント環境から順番に情報を吸い上げることが可能です。これは「環境が分かれていても、同じソフトウェアを配っている」というSaaSの宿命に近いリスクです。侵害が発覚しにくいまま全顧客へ展開されると、被害の検知も封じ込めも遅れます。対策としては、ブランチ保護、レビュー強制、ビルドの再現性確保、成果物署名、デプロイ承認、CIシークレット分離、サプライチェーン監査が必要です。さらに、テナントごとに段階展開できる仕組みを持つと、異常時のロールバックと影響の局所化がしやすくなります。 4. 共通ログ・バックアップ・運用ツールからの漏洩 本番データそのものを分離していても、ログ基盤、分析基盤、バックアップ、サポート用管理画面が共通であれば、そこから漏洩することがあります。例えば、アプリケーションログに個人情報やトークンを出力していたり、バックアップに複数テナント分のデータが集約されていたりすると、閲覧権限のある担当者や侵入者が横断的に取得できます。特に障害対応やカスタマーサポート用のツールは、利便性を優先して広い参照権限を持ちがちです。この種の漏洩は、本番DBの分離だけを見ていると設計レビューから抜け落ちやすいのが厄介です。対策としては、ログのマスキング、機微情報の非出力、バックアップ暗号化、閲覧権限の分離、サポート操作の監査証跡、テナント単位の検索制御が必要です。「運用のための共通基盤」こそ、サイロ型の盲点になりやすいと理解しておくべきです。 つまり、サイロ型は「いくつかの事故のBlast Radiusを小さくする」ための有効な手段ではあっても、「それだけで安全」という意味ではありません。重要なのは、どの脅威に対して何が効くのかを切り分けて理解することです。データの分離モデルはあくまで防御の一層であり、認証、配布経路、監査、運用統制まで含めてはじめて実効的なテナント保護になります。 おわりに マルチテナントSaaSの安全性は、プール型かサイロ型かというラベルだけでは決まりません。大切なのは、テナントの境界を明確に定義し、アプリケーション、データベース、キャッシュ、認証、監査ログ、運用手順に至るまで、その境界を一貫して守り続けることです。 サイロ型だから安全、プール型だから危険、という単純な話ではありません。事業目標、顧客要件、コスト効率、運用体制に応じてモデルを選び、そのうえで漏洩を前提に多層防御を設計する。SaaS提供事業者に求められているのは、まさにその責務です。 だからこそ、私たちが向き合うべき問いは「どのモデルが絶対に安全か」ではなく、「自分たちのSaaSは、どこにテナントの境界を置き、それをどう守り、どう監視し、どう改善し続けるのか」なのです。 --- ## マルチプロダクト戦略とコンパウンド戦略の違い、そして共通基盤をどこまで持つべきか URL: https://saasus.io/blog/multi-product-vs-compound-strategy Date: 2026-04-01 B2B SaaS事業がPMF(プロダクトマーケットフィット)を達成し、次なる成長を模索するフェーズにおいて、多くの経営者やプロダクトリーダーは「単一プロダクトの限界」に直面します。顧客の深い課題に向き合うほど、解決すべき業務ドメインは隣接領域へと広がり、自ずと第2、第3のプロダクトの検討が始まるからです。しかし、ここで安易に製品を増やすだけでは、将来的に開発の鈍化やデータの分断を招く「マルチプロダクトの罠」に陥りかねません。本稿では、近年注目を集めるコンパウンド戦略との違いを整理し、持続的な成長を支えるための共通基盤の境界線をどこに引くべきか、その意思決定の極意を論じます。 マルチプロダクト戦略とコンパウンド戦略の違い マルチプロダクト戦略とは：数の拡大と市場拡張 マルチプロダクト戦略とは、複数の異なる製品を一つの法人が展開していく戦略を指し、いくつかの実現方法があります。ひとつは、事業の成長過程で顧客の別のニーズを発見し、既存のソリューションだけでは解決できない領域に対してセカンドプロダクト、サードプロダクトを自ら生み出していくパターンです。もうひとつは、買収や事業提携によってポートフォリオを埋めていくパターンです。 この戦略を採る理由も一様ではありません。市場拡張、既存顧客に対するLTVの最大化、特定事業への依存を避けるためのリスク分散、営業チャネルの活用、あるいは将来的な事業価値の向上など、目的は多岐にわたります。つまり、マルチプロダクト戦略とはまず「複数プロダクトを持つこと」に重心のある概念であり、プロダクト同士がどの程度連携しているかどうかは必須条件ではありません。 極端に言えば、同じ会社が複数のSaaSを持っていても、それぞれが異なる顧客層、異なる業務ドメイン、異なるブランドで展開されているなら、それは十分にマルチプロダクト戦略といえます。そこでは「複数あること」自体が本質であり、「どれだけ統合されているか」は二次的なテーマになり得ます。 コンパウンド戦略とは：データの複利とプロダクト間の相互作用 これに対してコンパウンド戦略は、単に複数プロダクトを持つことではなく、それらが相互に価値を増幅し合うことを前提に設計された戦略です。最初から複合的なソリューションを提供する前提で、ビジネスモデルやソフトウェアのアーキテクチャ、データ構造、販売導線まで含めて設計されます。 そのため、コンパウンド戦略における各プロダクトは、隣接するビジネスドメインを対象にしていたり、顧客属性が近かったりすることが多くなります。共通の顧客基盤、共通のデータモデル、共通の業務文脈があることで、単体プロダクトの足し算ではなく、組み合わせによる複利的な成長が可能になるからです。ここで重要なのは、プロダクト横断でデータが蓄積され、プロダクト間の連携によって導入効果やスイッチングコストが高まることです。 したがって、コンパウンド戦略はマルチプロダクト戦略の一種として理解することもできますが、両者は同義ではありません。マルチプロダクト戦略の中には、各製品がかなり独立して存在しているものもあります。一方でコンパウンド戦略は、独立性よりも相互作用を重視します。言い換えれば、マルチプロダクト戦略が「数」の概念に近いのに対し、コンパウンド戦略は「関係性」と「設計思想」の概念です。 どこに向けて価値を提供するのか ソフトウェアにおけるマルチプロダクト戦略を考える際に難しいのは、どこまでを共通基盤として持ち、どこからを個別最適に任せるかという線引きです。ここで重要なのは、技術的に共通化できるかどうかではなく、顧客価値の観点から見て共通であるべきかどうかです。 たとえばPlatform Engineeringの発想で考えれば、インフラ管理、CI/CDパイプライン、監視、セキュリティ基盤、開発者向けテンプレートなどは、プロダクトの市場や業務ドメインが異なっていても比較的共通化しやすい領域です。これらは顧客から直接見える差別化要素ではなく、ソフトウェアを継続的に届ける事業者としての基盤能力だからです。内部の生産性や品質を高めるために共通化する価値は大きいでしょう。 しかし、B2B SaaSにおいて重要なSaaSコントロールプレーンについては、もう少し慎重な検討が必要です。SaaSコントロールプレーンとは、テナント管理、認証認可、料金プラン設定、契約、課金、監査ログなど、運用上共通して必要になりやすい機能群を指します。表面的にはどのプロダクトにも共通して見えるため、まとめて共通基盤化したくなります。 参照：「SaaSコントロールプレーンとは？コントロールプレーンの役割と重要性」 https://saasus.io/blog/saas-control-plane-importance ところが実際には、認証認可ひとつ取っても、B2B SaaSにおいてはテナント情報と強く結びついています。そして「テナントをどう定義するか」はビジネスドメインによって異なります。企業単位なのか、部門単位なのか、拠点単位なのか、あるいはサプライチェーン全体を跨ぐのか。その違いは単なる実装の差ではなく、製品の価値そのものに関わる設計上の前提です。 このため、安易に共通基盤化を進めると、本来は各プロダクトごとに持つべきビジネス上の自由度を奪い、設計レベルの制約を強く生み出してしまうことがあります。共通化によって短期的な効率は得られても、長期的には市場適応力を落とし、アジリティを損なうリスクがあるのです。 ブランドは統一された方が望ましいのか ここで関連してくるのが、ブランド統一の問題です。複数のプロダクトがあるなら、ブランドもひとつにまとめた方がよいのか。あるいは別ブランドで持つべきなのか。これもまた、一律に決められる話ではありません。 ブランドは単なるロゴや名称ではなく、「誰にどのような価値を届けるのか」という約束そのものです。顧客課題、購買プロセス、導入主体、運用責任者、競合環境が大きく異なるのであれば、ブランドを無理に統一することで、かえって価値提案がぼやけることがあります。逆に、顧客が同じで、複数製品を連続的に評価・導入する文脈が強いなら、ブランド統一は信頼や拡張性の訴求に役立ちます。 つまり、ブランドを統一するかどうかも、内部都合ではなく顧客の認知構造から考えるべきです。同じ会社が提供していることが顧客価値になるのか、それとも見えない裏側で統合されていれば十分なのか。その見極めが必要です。例えば、ブランドを顧客に意識させることで新規事業の仮説検証においては、ブランドの持つイメージ自体がノイズになってしまうリスクも存在します。課題そのものの解決に至るプロダクトかという観点よりも、ブランドの持つイメージが先行してしまい、認知の歪みが生じて仮説検証の精度が著しく下がるのです。その場合、スタートダッシュこそブランドの力を借りて実現できる可能性はありますが、課題解決に至っていない場合は失速してしまうでしょう。 ホテルブランドのメタファー この点を考えるうえで、マルチプロダクト戦略はホテルブランドの構造に少し似ています。同じ系列が運営するホテルであっても、ラグジュアリー、ビジネス、長期滞在、リゾートなど、ブランドごとに価値観も対象顧客も異なります。系列全体としては会員基盤やオペレーション、人材プール、購買、システム基盤を一部共有しているかもしれませんが、顧客から見える体験は必ずしも統一されていません。 むしろ重要なのは、どこを統合し、どこをブランドごとに独自化するかが丁寧に設計されていることです。系列横断のIDが便利に働くケースもあれば、それぞれのブランドが独立した世界観を持つことで価値を発揮するケースもあります。これはソフトウェアでも同じで、認証や課金が統合されていることが必須の体験なのか、それとも内部の効率化にとどめるべきなのかを見極める必要があります。 共通基盤にするとき・しないときのメリット、デメリット、リスク 共通基盤にするメリットは明確です。重複開発を減らせること、運用やセキュリティ水準を揃えやすいこと、横断データを活用しやすいこと、組織としての学習を積み上げやすいこと。特に顧客接点やデータモデルが近い場合には、クロスセルやアップセルの導線まで含めて大きな効果を生みます。 一方でデメリットもあります。共通基盤は、一度作ると多くのプロダクトに影響を及ぼすため、変更コストが高くなりがちです。また、その中で最も複雑な要件に引っ張られて、全体が過剰に重たくなることもあります。本来は軽く始められたはずの新規プロダクトが、既存基盤への適合を求められることで立ち上がりを遅らせることもあります。 リスクとして特に大きいのは、「共通化そのものが目的化すること」です。共通であることは手段であって、目的ではありません。顧客価値を高めるため、あるいは事業の俊敏性を高めるために共通化するのであって、統一感があるから、管理しやすいから、という理由だけで進めると失敗しやすい。逆に、共通化しない場合にも、各プロダクトがバラバラに似た機能を持ち、後から統合コストが膨らむリスクがあります。 おわりに マルチプロダクト戦略において重要なのは、複数の製品を持つこと自体ではなく、それぞれのプロダクトがどの顧客にどの価値を届けるのかを明確にし、そのうえでどこを共通化し、どこを分けるかを意思をもって設計することです。 コンパウンド戦略は、その中でも特に、プロダクト間の関係性とデータの複利を重視する考え方です。しかし、すべてのマルチプロダクト企業が最初からコンパウンドである必要はありません。むしろ重要なのは、自社が目指す価値提供の形に対して、ブランド、アーキテクチャ、コントロールプレーンの境界が整合しているかどうかです。 共通基盤にすべきか否かという問いに万能な正解はありません。ただひとつ言えるのは、技術からではなく、顧客価値と事業戦略から逆算して決めるべきだということです。その視点があって初めて、マルチプロダクト戦略は単なる製品数の拡大ではなく、持続的な事業の厚みへと変わっていきます。 --- ## SaaSファーストの実践に向けた選定・導入・運用のヒント URL: https://saasus.io/blog/saas-first-implementation-guide Date: 2026-01-29 開発スピードの向上とコスト最適化のために「SaaSファースト」は非常に有効な手立てとなります。しかし、市場には数多くのSaaSが存在しており、選定の失敗リスクも少なからずあります。 SaaSファーストとは？ 本記事では、選定で失敗しないための6つの重要なチェックポイントを、技術的、人的、そして経営的な側面から具体的に解説します。さらに、選定したツールを組織の力として定着させ、その効果を可視化するための導入プロセスについても触れ、SaaSファースト実践の確実な第一歩をサポートします。 ツール選定で失敗しないための6つのチェックポイント 前述の通り、世の中には無数のSaaSが存在します。その中から自社に最適なツールを選ぶには、どのような基準で判断すればよいのでしょうか。単に機能の多さだけで選んでしまうのは、必ずしも良い選択とは言えません。ここでは、長期的な成功を見据えたツール選定のための6つのチェックポイントを解説します。 ポイント①：API連携とエコシステムの拡張性 SaaSは単体で使うよりも、他のSaaSと連携させることでその価値が飛躍的に高まります。利用するSaaSが、自社で既に利用しているバージョン管理システム（GitHubなど）やコミュニケーションツール（Slackなど）とスムーズに連携できるかは、必ず確認すべき最重要項目です。優れたエコシステムを持つSaaSを選ぶことは、自社で連携処理を開発する手間を省き、SaaSファーストの思想を加速させます。 ポイント②：開発者体験（Developer Experience, DX）  これは「そのSaaSを使っていて、開発者が心地よいか」という、非常に重要な指標です。具体的には、導入のしやすさ、ドキュメントの分かりやすさ、UIの直感性などが含まれます。開発者体験が悪いSaaSは、たとえ高機能でもチームに浸透せず形骸化するリスクがあります。この問題に向き合うために、無料トライアル期間中に実際に複数の開発者に触ってもらい、「このSaaSとなら長く付き合えそうか」という定性的なフィードバックを集めるのが非常に効果的です。 ポイント③：セキュリティとコンプライアンス要件 B2B SaaSを提供する上で、利用する外部SaaSのセキュリティ体制を精査することは、顧客に対して果たすべき重要な責務です。しかし、必ずしもあらゆる認証を網羅的に取得しているかを確認する必要はありません。重要なのは、自社のビジネスモデルとターゲットの市場に応じて、取り組むべきコンプライアンスとその優先順位を適格に見極めることです。以下にセキュリティに関する主要な指標をいくつか紹介します。 ・SOC 2 Type II: エンタープライズ顧客へのサービス提供が中心の場合、継続的な運用統制を証明するこの報告書は、信頼獲得の鍵となります 。    ・ISO 27001: 組織全体の情報セキュリティ管理体制を国際標準に準拠させたい場合に適しており、幅広い顧客層への信頼性向上に寄与します 。    ・GDPR: EU市場の顧客を対象とする場合、GDPRの遵守が不可欠です。遵守は法的な必須要件です 。    ・HIPAA: 米国のヘルスケア市場に関連するデータを扱う場合、HIPAAの遵守が不可欠です。 セキュリティが担保されたSaaSを利用することは、そのSaaSが持つ「信頼性」を自社のサービスに組み込むことであり、自社単独で対応する莫大なコストを節約できます。 ポイント④：サポート品質とコミュニティ  問題が発生した際に、迅速で的確なサポートを受けられるかは、SaaSの価値を大きく左右します。特にスタートアップでは、ベンダーのサポートは実質的な「外部の専門チーム」として機能します。サポートチャネルの豊富さや応答時間に加え、ユーザー同士で情報交換できる公式のSlack/Discordコミュニティやフォーラムが活発かどうかも、実践的な情報を得られる貴重な場として重視すべきです。 ポイント⑤：料金体系と総所有コスト（TCO） Webサイトに記載されている月額料金だけでなく、導入から運用までにかかる総費用、すなわち総所有コスト（TCO）で評価する視点が重要です。また、事業の成長予測に基づき、「ユーザー数が10倍になったら？」「データ量が100倍になったら？」といったコストシミュレーションを行いましょう。特に使用量課金モデルは、シミュレーション不足による予期せぬ高額請求に繋がるリスクがあるため、慎重な検討が必要です。 ポイント⑥：ベンダーロックインとデータのポータビリティ  これは「将来、そのSaaSの利用をやめたくなった時に、どれだけスムーズに移行できるか」という視点です。特定のベンダーの独自技術に深く依存すると、将来の乗り換えが困難になる「ベンダーロックイン」状態に陥るリスクがあります。OpenAPIのような業界標準のフォーマットに対応しているか、ツールに蓄積したデータを簡単にエクスポートできるかを確認し、将来の技術選定の柔軟性を保つことが賢明です。 最適な導入プロセスで開発体制を強化する 自社に最適なSaaSを選定できたら、次はいよいよ導入のフェーズです。しかし、焦って全社に一斉導入しようとすると、現場の混乱や反発を招きかねません。新しいSaaSを定着させ、その効果を最大化するためには、戦略的な導入プロセスと効果を可視化する仕組みが重要になります。 まずは特定チームでの導入から始める 新しいツールを導入する際は、まずは特定のチームでの試験的な導入から始めるのが定石です。 重要ではあるものの、ミッションクリティカルではない実在のプロジェクトを対象に選び、「4週間で手動デプロイの時間を50%削減する」といった明確な目標を設定してスタートします。この小規模な導入体験と、そのチームから得られる「実際に使ってみてどうだったか」という定性的なフィードバック、そして導入プロセスで得られた知見こそが、その後の全社展開をスムーズに進めるための重要な情報となります。 導入効果をDORAメトリクスで可視化する 「開発が速くなった気がする」といった感覚的な評価だけでは、ツールの導入効果を客観的に判断することは困難です。そこで活用したいのが、DORAメトリクスという、開発生産性を測るための業界標準の4つの指標です。これらの指標は、開発チームのパフォーマンスを「速度（Speed）」と「安定性（Stability）」という2つの重要な側面から定量的に評価することを目的としています。 デプロイの頻度: 本番環境へのリリース頻度。 変更のリードタイム: コードのコミットから本番リリースまでにかかる時間。 変更障害率: デプロイが原因で本番環境で障害が発生する割合。 サービス復旧時間: 障害発生から復旧までにかかる時間。 例えば、CircleCIのようなCI/CDツールを導入し、継続的インテグレーションのプラクティスを組織に定着させることで、「デプロイの頻度」や「リードタイム」といった指標の改善が期待できます。これらの指標をツール導入の前後で計測・比較することで、SaaSへの投資がビジネスの速度と安定性にどれだけ貢献したかを、誰の目にも明らかなデータとして示すことができます。 SaaSの効果を測定し、組織に定着させる運用プロセス 小規模な導入が成功し、いよいよ全社展開という段階は、SaaSファースト戦略における第二の関門とも言えます。一部のチームでの成功体験が、必ずしも組織全体の成功に直結するとは限りません。 SaaSは「導入したら自動的に効果が出る」ものではなく、組織に定着させ、継続的にその価値を引き出して初めて「実践できている」と言えます。このセクションでは、導入したSaaSの効果を最大化し、定着させるためのプロセスについて解説します。 全社展開（ロールアウト）で直面する「浸透の壁」 特定チームでの導入の成功は、あくまで「最適な環境下での成功」であることが往々にしてあります。全社展開のフェーズでは、利用者のリテラシーのばらつき、既存業務フローへの固執、ツールの管理責任者の不在など、予期せぬ「浸透の壁」に直面することが少なくありません。 「便利なはずなのに、一部のチームしか使ってくれない」 「既存のツールと機能が重複し、現場が混乱している」 「誰が管理者なのか、トラブル時にどこへ聞けば良いか不明確」 こうした事態を避けるためには、技術的な移行作業と並行して、「組織的なチェンジマネジメント」が不可欠です。なぜこのツールを導入するのかという目的を、経営層や管理職からも粘り強く発信し続けること。そして、ツールの使い方やトラブルシューティングをまとめた社内ドキュメントを整備し、推進担当者を明確に設置することが、全社へのスムーズな浸透を後押しします。 SaaS導入効果の「見える化」：何をKPIに設定すべきか？ SaaSの導入効果を可視化することは、導入の検討時だけでなく運用が始まってからも重要な要素になります。 全社での導入自体には成功したものの、「なんとなく便利になった気がする」という曖昧な評価で終わらせてしまっては、継続的な改善にはつながりません。SaaSファーストを推進する上で、導入効果の「見える化」は極めて重要です。 ここで立ち返るべきは、選定チェックポイントの1つ目「『なぜ』導入するのか？」で設定した課題です。 もし「開発リードタイムの短縮」が目的だったなら、「デプロイの平均所要時間」や「月間デプロイ回数」がKPIになるでしょう。「手作業によるミスの削減」が目的なら、「インシデント発生件数」や「手戻り工数」を測定すべきです。 また、開発効率やコストといった定量的な指標だけでなく、「ツール導入後の業務満足度」や「コラボレーションの円滑さ」といった定性的なアンケートを現場から取ることも有効です。これらのKPIを定期的に観測することで、初めてSaaS導入の投資対効果（ROI）を客観的に評価できます。 継続的な改善サイクルと「攻め」のSaaS運用体制 SaaSは一度導入したら終わりではありません。市場のトレンドは変わり、自社のビジネスも成長に伴い変化したり、SaaSベンダーも日々機能をアップデートしています。導入から半年後には、もっと効率的な使い方が生まれているかもしれません。 大切なのは、導入効果のKPIを定期的にモニタリングし「もっとうまく使えないか」「他の業務にも応用できないか」と問い続ける、継続的な改善サイクル（PDCA）を回す体制です。 とはいえ、日々の業務に追われる中で、複数のSaaSの利用状況やコストを横断的に把握し、最適な運用を維持し続けるのは大きな負担となります。特に、気づかぬうちにライセンス費用が膨らんでいたり、使われていない機能のためにコストを払い続けていたりするケースは少なくありません。運用の課題に対するアプローチとして、以下を実施してみるのも良いでしょう。 ・明確なオーナーシップと役割分担:  まず、「誰が、どのSaaSの管理者で、何に責任を持つのか（契約更新、アカウント管理、セキュリティ設定など）」を定義します。責任者の不在は、ツールの形骸化やセキュリティリスクの温床となります。 ・定期的なレビューサイクルの導入: 「四半期ごとのアカウント棚卸し」や「契約更新前の利用状況評価」を制度化します。使われていないライセンスや重複する機能がないかを確認し、コストの最適化を図ります。 ・社内ドキュメントの整備:  ツールごとの運用ルール、トラブルシューティング手順、推奨される使い方などを文書化し、社内の誰もが参照できるようにします。これにより属人化を排除し、新しいメンバーのオンボーディングもスムーズになります。 SaaSを「導入する」段階から「使いこなし、改善し続ける」段階へと移行することが、SaaSファースト戦略の真のゴールと言えるでしょう。 まとめ 本記事では、SaaSファーストを実践するための重要な「選定チェックポイント」 から、戦略的な「導入プロセス」 、そして導入後にSaaSの価値を最大化するための「運用プロセス」 までを解説しました。 最適なSaaSの選定は、単なるツール導入ではなく、自社の開発体制やビジネスの未来を左右する戦略的な一手です 。しかし、SaaSファーストの真の成功は、「導入して終わり」ではなく、その効果を継続的に測定・改善し、組織の血肉として定着させていくプロセス にかかっています。 今回ご紹介したチェックポイントや導入・運用プロセスを参考に、自社の課題に真に寄り添うツールを見極め、SaaSファーストの成功に向けた確実な一歩を踏み出してください . --- ## SaaS開発の落とし穴 〜データパーティショニング編〜 URL: https://saasus.io/blog/saas-development-issues-data-partitioning Date: 2025-12-31 はじめに SaaS（Software as a Service）の開発において、アーキテクチャ設計の初期段階で最も重要な意思決定の一つが「データパーティショニング（テナントデータの分割戦略）」です。 「テナントのデータをどのように保存し、分離するか」という問いに対し、単に技術的な好みだけで決めてしまうと、サービスが成長した段階で深刻なパフォーマンス問題やコスト超過、運用崩壊を招くことになります。 今回は、マルチテナントSaaSにおけるデータパーティショニング戦略、特に「プールモデル」と「サイロモデル」それぞれに潜む、代表的な落とし穴について解説します。 データパーティショニングの基本戦略 本題に入る前に、SaaSにおけるデータ配置の2つの主要なアプローチを整理します。 プールモデル（共有モデル）： すべてのテナントデータを共有のリソース（同じデータベース、同じテーブルなど）に保存し、テナントIDで区別する方式。 サイロモデル（分離モデル）： テナントごとに独立したリソース（専用データベース、専用インスタンスなど）を用意する方式。 これらは一長一短あり、「どちらか一方が正解」というものではありません。しかし、それぞれの特性を理解せずに採用すると、以下のような「落とし穴」にはまることになります。 ① プールモデル（共有モデル）における落とし穴 「効率性が高い」としてデフォルトで採用されやすいプールモデルですが、リソースを共有するがゆえの重大なリスクがあります。 ノイジーネイバー（Noisy Neighbor）問題 プールモデル最大の課題は、ある特定のテナントの振る舞いが、他のテナントに悪影響を及ぼす「ノイジーネイバー（騒がしい隣人）」問題です。 例えば、ある大規模なテナントが大量のデータ処理や複雑なクエリを実行してリソース（CPU、メモリ、I/O）を占有してしまうと、同じデータベースに同居している他のテナントのレスポンスが極端に遅くなってしまいます。 分離実装の難易度とセキュリティリスク 「すべてのデータが同じ場所にある」ため、アプリケーションレベルでの論理的な分離が必須となります。 実装の複雑さ： すべてのクエリに対して、必ず WHERE tenant_id = ? のようなフィルタリングを徹底する必要があります。開発者が一箇所でもこの記述を漏らせば、他テナントのデータが見えてしまう重大な情報漏洩事故につながります。 認証・認可の徹底： RLS（Row Level Security）のようなデータベース機能を活用するか、アプリケーションコードで厳格なガードレールを設ける必要があり、サイロモデルに比べて実装難易度は高くなります。 ライトサイジング（適正規模）の難しさ テナントごとのワークロードは予測が難しく、変動しやすいものです。プールモデルでは複数のテナントが混在するため、データベース全体の負荷予測がさらに困難になります。 パフォーマンス低下を恐れて過剰なリソースを確保（オーバープロビジョニング）してしまい、結果的にコスト効率が悪化するケースも少なくありません。 ② サイロモデル（分離モデル）における落とし穴 セキュリティ要件の厳しいエンタープライズ顧客向けに採用されることが多いサイロモデルですが、運用とコストの面で課題が生じやすくなります。 運用と管理の複雑化 テナント数が少ないうちは問題になりませんが、ビジネスが成長しテナント数が数百、数千と増えた時、サイロモデルは牙を剥きます。 デプロイと更新の重荷： スキーマ変更やパッチ適用を、数千個のデータベースに対して行う必要があります。1つの変更が失敗した場合のリカバリや、全テナントへの適用時間の増大など、DevOpsチームに大きな負担が掛かります。 監視の分散： 監視対象のリソースが膨大になるため、システム全体の健全性を把握するための可観測性（Observability）の確保が難しくなります。 コストの非効率性とリソース制限 サイロモデルでは、テナントごとにリソースを確保するため、以下の問題が発生します。 アイドル状態のコスト： あまり利用されていないテナントであっても、専用のデータベースインスタンスを用意していれば、その分の料金が発生します。リソース稼働率が低いままコストだけが積み上がる「過剰プロビジョニング」の状態になりやすいのが特徴です。 クラウドのリソース上限： AWSやAzureなどのクラウドプロバイダには、1アカウントあたりに作成できるリソース数（例：RDSインスタンス数やDynamoDBテーブル数）に上限があります。テナント数が急増した際、このハードリミットに直面し、アーキテクチャの変更を余儀なくされる可能性があります。 まとめ：ビジネス要件と技術のバランス データパーティショニングにおいて、「万能なモデル」は存在しません。 プールモデルはコスト効率と運用効率に優れますが、分離レベルの確保とパフォーマンス干渉への対策が必要です。 サイロモデルは強力な分離とパフォーマンス予測が可能ですが、運用コストとインフラコストが高騰します。 成功している多くのSaaSでは、これらを二者択一で考えるのではなく、要件に応じて組み合わせるアプローチを取っています。 例えば、基本的なティアのテナントには効率的な「プールモデル」を適用し、コンプライアンス要件が厳しく高単価なプレミアムテナントには「サイロモデル」を提供する、といった「ティアリング戦略」です。 開発初期においては、まずは効率性の高いプールモデルを基本としつつ、将来的に特定のテナントをサイロへ切り出せるような柔軟性を持った設計にしておくことが推奨されます。 E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 --- ## SaaS開発の落とし穴 〜テナント分離編〜 URL: https://saasus.io/blog/saas-development-issues-tenant-isolation Date: 2025-12-02 はじめに：SaaSアーキテクチャの心臓部、テナント分離とは SaaS環境におけるテナント分離とは、各テナントのデータアクセス、管理、保存方法を決定し、論理的・物理的に隔離するための「保護の仕組み」です。これは、マルチテナントモデルの設計においてセキュリティ、コスト効率、運用効率に直結する、心臓部とも言える重要なプロセスです。 本記事では、SaaSをスケールさせる上で見落とされがちな、設計上の落とし穴と、どうすれば安全かつ効率的に回避できるのかを、具体的な視点から解説します。 落とし穴①：テナント分離とデータパーティショニングの混同 データ分離の議論における最も一般的な誤解の一つは、データパーティショニング（ストレージ戦略）をテナント分離（保護の仕組み）と同義と見なしてしまうことです。 定義の違い テナント分離：あるテナントが別のテナントのリソースにアクセスできないようにするための保護の仕組みを指します。 データパーティショニング：データをどこに、どのように保存するかというストレージ戦略です。 データパーティショニングの主なモデルは以下の通りです。 プールモデル：複数のテナントがストレージリソースを共有する構成。 サイロモデル：テナントごとに専用のストレージ構造を持つ構成。 サイロ化だけでは分離は不十分 たとえストレージをサイロモデルで構築したとしても、それだけではテナント間のアクセスを防ぐリソース分離は達成されません。テナント間のアクセスを防ぐ仕組みは、アプリケーションがデータを処理するアプリケーションプレーンに導入する必要があります。 テナント分離は、アーキテクチャの設計や実現方法にかかわらず、テナントのリソース（データを含む）を確実に保護するために不可欠な、SaaSの基礎となる要素です。分離ポリシーを適用するためには、アプリケーションレベルでの仕組みが必要になります。 落とし穴②：過剰なサイロ化による効率性と俊敏性の喪失 コンプライアンスやセキュリティを重視するあまり、「すべてをサイロ化すれば安全」という思考に陥り、本来サイロ型の体験を必要としない構成要素までサイロモデルに移行してしまうことは、大きな落とし穴です。 割り勘効果の低下 サイロモデルを採用すると、インフラストラクチャの共有によって生じる割り勘効果を最大限に活用する能力が制限されます。テナントの負荷が低い場合でも、各テナント専用のインフラストラクチャに対してコストが発生する可能性があります。 運用負荷の増大と俊敏性の低下 サイロモデルは、プールモデルよりも管理と運用の体験に複雑さを加えます。データ変更や移行の適用時に、DevOpsツールが各テナントのサイロに対して個別にプロセスを実行する必要が生じます。これは、SaaSビジネスの俊敏性を損なう結果となります。 回避策： サイロ化の決定は、明確な要件（コンプライアンス、極端な分離要件など）が正当化できるかどうかを厳しく評価した上で、その都度、前提条件を確認して適用する必要があります。 落とし穴③：開発者に依存した分離ロジック 分離を実現するために、開発者がデータアクセスを行うたびに分離ロジックを意識してコードに組み込むと、以下のような問題が発生します。 コードの肥大化：アプリケーションコードに分離ロジックを直接書き込むと、定型的な繰り返しコード（ボイラープレート）が増加し、コード全体が肥大化・複雑化していく可能性があります。これにより、本来集中すべきビジネスロジックが埋もれてしまいます。 分離の脆弱化： 開発者がこの分離ロジックの組み込みを忘れた場合、テナントの境界線を越えたデータアクセス（データ漏洩）が発生する重大な脆弱性につながります。 理想的なテナント分離は、開発者がビジネスロジックの実装に専念できるように「開発者が意識しなくて済む」仕組みを提供することです。 分離の仕組み（テナントIDの抽出、アクセス範囲の制限、ポリシーの適用など）は、専用のライブラリやフレームワーク、あるいはサービスレイヤーのミドルウェア/ヘルパーに集約し、開発者の目から隠ぺい・一元化する必要があります。これにより、堅牢な分離を維持しつつ、開発者の体験を損なわないモデルを構築できます。 まとめ SaaSアーキテクチャ設計におけるテナント分離は、セキュリティと拡張性を両立させるための最重要課題です。本記事では、以下の3つの主要な落とし穴とその対策を解説しました。 パーティショニングと分離の混同： ストレージ戦略（サイロ化）だけでは不十分であり、アプリケーションプレーンで分離ロジックによる保護機構を導入することが不可欠です。 過剰なサイロ化：SaaSが目指す俊敏性、運用効率、コスト効率を最大化する鍵は、プールモデルから着手し、明確な要件によってのみサイロ化へと移行するというマインドセットにあります。 分離ロジックの開発者依存： データ漏洩リスクとコードの肥大化を防ぐため、分離ロジックは専用のライブラリやミドルウェアへの集約を検討する必要があります。 マルチテナント環境におけるデータ戦略は、技術的な特性だけでなく、ビジネス、コスト、運用上のトレードオフを慎重に比較検討することが求められます。 --- ## BtoB SaaSの認証認可において重要な「SaaSアイデンティティ」とは？ URL: https://saasus.io/blog/btob-saas-auth-saas-identity Date: 2025-10-29 はじめに：単なる「ログイン機能」ではない、SaaS認証基盤の本質 ユーザー認証やログイン機能は、SaaS開発において当たり前のように実装される機能です。しかし、「ログインできればそれで良い」という考え方は、特にBtoB SaaSではうまくいかないことがあります。 BtoB SaaSでは、「誰が」サービスを利用しているかというユーザー情報だけでは十分ではありません。本当に重要なのは、「誰が、どの組織(テナント)の一員として」サービスを利用しているか、という情報です。 これは、ただSaaSのコア機能群（アプリケーションプレーン）で使うだけの認証情報にとどまりません。テナントの管理、オンボーディング、課金・請求などといったSaaSのビジネス運営を支える「コントロールプレーン」においても重要な役割を果たします。 この「ユーザー」と「テナント」の情報を組み合わせて定義する概念こそが、SaaSの設計の基礎となる 「SaaSアイデンティティ」 です。 多くの開発チームが、開発初期にこの概念を見過ごした結果、サービスの成長と共に大きな技術的負債を抱えることになります。本記事では、SaaSアイデンティティとは何か、なぜそれがSaaS開発の根幹をなすのか、そしてこの設計を怠った場合にどのような問題が起こるかについて見ていきます。 1. SaaSアイデンティティとは？ SaaSアイデンティティとは、単一の概念ではなく、以下の2つの要素を組み合わせたものです。 ユーザーアイデンティティ: サービスを利用する個人を識別し、その属性を記述するもの (例: 氏名、メールアドレス、役職など) テナントアイデンティティ: サービスを利用するテナントを識別し、その属性を記述するもの (例: 組織名、契約プラン、支払い情報など) BtoB SaaSでは、ユーザーは必ず特定のテナントに所属してサービスを利用します。例えば、「A株式会社の山田さん（管理者権限）」や「B製作所の鈴木さん（一般ユーザー権限）」といった形で、ユーザーアイデンティティとテナントアイデンティティは常にセットで扱われます。 2. なぜSaaSアイデンティティが重要なのか？ SaaSアイデンティティは、単なるユーザー情報管理の枠を超え、SaaSアプリケーションのコア機能を支える基盤となります。それは、ログイン処理のためだけに存在するのではなく、以下で挙げるようなSaaSのビジネス運営そのものを管理・制御するための中心的な役割を担っています。 テナントオンボーディング 新しいテナントがサービス利用を開始する際、まずテナントアイデンティティが作成されます。そのテナントの管理者として最初のユーザーアイデンティティが紐付けられ、ここからテナントのセットアップが始まります。 なお、このプロセスが自動化されているかどうかが、以前の記事で解説したとおり、SaaSビジネスのスケールを大きく左右します。 データ分離とアクセス制御 BtoB SaaSの最も重要な要件の一つが、テナント間のデータを厳密に分離することです。つまり、テナントAのユーザーが、テナントBのデータにアクセスできてはいけません。 具体的な実装としては、例えば、テナントアイデンティティに「テナントID」を持たせてデータ分離を実現する方法が考えられます。リレーショナルデータベースの場合であれば、テーブルにテナントIDカラムを持たせることで実現できるでしょう。 このような「常に自テナントのデータにしかアクセスできないよう制御する実装」は、基本的ながら極めて重要です。 権限管理 BtoB SaaSでは、一人のユーザーが複数のテナントに所属し、さらにテナントごとに異なる役割を持つことが頻繁にあります。 例えば、Slackを例に考えてみましょう。自社のワークスペースでは「管理者」かもしれませんが、別のコミュニティのワークスペースでは「一般ユーザー」ということがあります。 そのため、SaaSアイデンティティを用いて、「誰が」「どのテナントで」「どの権限で」アクセスするかを適切に制御する必要があります。 課金・請求 ユーザーが特定の機能を利用する際、システムはテナントの契約プランに基づき、機能へのアクセスを制限したり、従量課金のために利用量を計測したりする必要があります。ここでも、「ユーザーの行動」と「テナントの契約情報」を正確に結びつけ、適切な課金処理を行うためにSaaSアイデンティティが必要になります。 3. 「テナント設計」なくして認証基盤は作れない BtoB SaaSの認証基盤を考えるとき、まずテナントの設計を固めることが非常に重要です。なぜなら、上で述べてきたように、認証基盤の根幹をなすSaaSアイデンティティはテナントの概念と切り離せない関係にあるからです。 テナントの設計が定まらないまま認証機能だけを先行して実装してしまった場合、どのような問題が起こるでしょうか。 例えば、システム全体に後付けのマルチテナント対応コードが散在してしまい、これが大きな技術的負債となることも考えられます。 そして、この問題は単にコードが複雑になるだけでは終わりません。設計の根幹にテナントの概念がないことで、意図せず他のテナントのデータにアクセスできてしまうといったセキュリティリスクの高い構造を生んでしまいます。さらに、ログインのたびにテナント選択を求めるなどユーザー体験の悪化を招いたり、運用負荷を増大させたりと、ビジネスの成長を直接的に妨げる要因にもつながるのです。 まとめ SaaSアイデンティティは、スケーラブルでセキュアなマルチテナントSaaSを構築するための設計の出発点です。それは単なる機能要件ではなく、アプリケーション全体のアーキテクチャ、そしてSaaSビジネスの基本となる重要な原則です。 多くの開発チームが、目の前の機能開発を優先するあまり、この基本的な設計を後回しにしがちです。しかし、テナント設計・SaaSアイデンティティの設計と認証基盤の設計は不可分であり、システムの根幹に関わる部分を後から修正するコストは非常に大きくなります。 E-Book「SaaS開発ガイド」では、本記事で扱いきれなかったテナント設計に関する詳しい内容や、SaaS開発に取り組む前に知っておきたい重要ポイントを扱っています。SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 --- ## クラウドを活用したSaaS開発が実現する柔軟性とスケーラビリティ URL: https://saasus.io/blog/cloud-base-saas-scalability Date: 2025-10-22 はじめに SaaS（Software as a Service）とクラウドコンピューティングは、現代のソフトウェア業界において切っても切り離せない関係にあります。特に日本のソフトウェア市場では、SaaSの採用が急速に進んでおり、単なるソフトウェアの提供方法を変えるだけでなく、企業のあり方そのものに大きな変革をもたらしています。 この記事では、SaaSとクラウドの深い関係性とそのビジネス上のメリット、そしてSaaSの成長を支える主要な概念について解説します。 SaaS開発にクラウドを活用するメリット クラウドベースのSaaS開発がもたらすビジネス上の具体的なメリットを、4つの観点からご紹介します。 コスト オンプレミス型の場合、自社でサーバーを用意するため、たとえ利用率が低い時間帯でもコストが発生します。 これに対し、クラウドの場合は、大量のリソースを共有利用することで全体の利用効率を大幅に高めています。その結果、クラウドを利用する企業は、必要なときに必要な分だけリソースを利用することが可能になります。オンプレミス型と比べ、初期に必要となる設備投資も大幅に抑えられます。 俊敏性 クラウドを活用することで、必要なリソース（サーバー、ストレージなど）を瞬時に利用開始でき、インフラの準備を待たずにすぐに開発やテストに取り掛かることができます。 これにより、開発サイクル全体が大幅に短縮されます。新機能の追加や価格変更を迅速にデプロイできるため、企業は市場トレンドや顧客ニーズに素早く対応し、優位性を築くことができます。 スケーラビリティ クラウドベースのSaaSは、コストの項目でも述べたように、共有インフラストラクチャを利用することで、予測不可能なテナントの需要にも柔軟に対応し、リソースの効率的な利用を実現します。 SaaSのスケーリングに合わせて必要なリソースも増えていきますが、クラウドの活用により自動化し、人手を介さずリソースを増やすこともできます。 運用効率 スケーラビリティの項目でも述べたように、スケーリングの責任をクラウドの提供するマネージドサービスに委ねることで、SaaSチームが機能開発に集中できるようになります。 特にクラウド上の概念として、「サーバーレス」という言葉があります。これは物理的なサーバーを意識せずともリソースを扱えることを表しており、AWS Lambdaなどに代表されます。サーバーレスのサービスを利用することで、需要に応じてコンピューティングリソースを自動でスケールアップ・ダウン可能になり、効率的な運用が期待できます。 クラウドが支えるSaaSアーキテクチャの基礎 これらの大きなビジネスメリットは、SaaS独自のアーキテクチャと、それを実現する具体的な仕組みによって支えられています。 SaaSのアーキテクチャは、以下の2つの要素に分けて考えることができます。 ①アプリケーションプレーン ユーザーが直接利用する、SaaSのコア機能を提供する構成要素です。テナントごとのデータ分離や、マルチテナント環境での効率的なリソース利用が求められます。 活用事例：クラウドのデータベースサービスを活用することで、テナントごとのセキュリティ要件を満たしつつ、データのバックアップ、リカバリ、監視といった煩雑な管理をクラウドに委ねることができます。これにより、SaaSの競争力を生み出すコア機能の開発にフォーカスすることができます。 ②コントロールプレーン テナントのオンボーディングや請求など、SaaS環境の基盤を管理する仕組みです。コア機能ではないものの、アプリケーションプレーンを支える重要な構成要素です。 活用事例：クラウドの認証サービスやAPIゲートウェイ、請求サービスといったマネージドサービスを組み合わせることで、新規テナントの受け入れ、利用状況の監視、料金の請求処理といった、管理基盤となる一連のプロセスを自動で、かつ安定して実行できます。 まとめ クラウドベースのSaaSは、クラウドコンピューティングの特性を最大限に活用することで、ビジネスに大きく貢献します。 従量課金制によりコストを最適化し、迅速なリソース確保で市場の変化に素早く対応できる俊敏性を実現します。また、需要に応じたスケーラビリティと、サーバーレスなどの技術による運用効率の向上は、開発者がコア機能に集中できる環境を提供します。 E-Book「SaaS開発ガイド」では、SaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 --- ## 【調査レポート】Horizontal SaaS 1226種のAPI提供・公開状況からみるAPIエコノミーの展望 URL: https://saasus.io/blog/horizontal-saas-api-report Date: 2025-10-03 まえがき API（Application Programming Interface）は、ソフトウェアやアプリケーション同士を連携させるためのインターフェースです。近年、SaaSサービスの普及や生成AIエージェントの発展が加速する中で、利便性向上やイノベーションの推進においてAPIの重要性が高まっています。金融、医療、物流など多様な業界がシステム間のデータ連携を実現し、新たな価値を創出する現在、誰でも接続可能なAPIの実装はグローバル標準となり、企業の競争力向上に不可欠な要素となっています。 そこで今回は、SaaS比較サイト「BOXIL」を運営するスマートキャンプ株式会社が公開した「SaaS業界レポート2024」のSaaSカオスマップにに掲載されているHorizontal SaaS企業1,226サービスを対象に、APIの提供状況/公開状況について独自調査を実施しました。 その結果、国内外でAPI公開状況に大きな差が見られました。 なお、APIの重要性や国内外のSaaSの動向については、CData社のブログ記事「Horizontal SaaS 647種類のAPI提供状況を調査：そこから見えてきた国産 SaaS APIの今」を参考にさせていただきました。 調査対象 このカオスマップには合計1,669のサービスが掲載されており、Horizontal SaaS (業界を問わず特定の部門や機能に特化したもの) が1,288サービス、Vertical SaaS (特定の業界に特化したもの) が381サービスでした。 なお、本調査レポートにおいて、Horizontal SaaS は以下のカテゴリに属するものとし、中でも、サービスサイトの存在が確認できた企業1,226サービスを最終の調査対象としております。 Back Office HR Collaboration Marketing & Sales Security SaaS for SaaS 調査手順 以下の手順にて調査しました。 Horizontal SaaS の製品ロゴをそれぞれ画像検索し、製品URLの存在が確認できたサービス1,226サービスを抽出 サービスの運営会社を調べ、本社が日本国内のものは「国内製品」、国外のものは「海外製品」と定義 以下のいずれかに当てはまる場合、「API提供サービス」と判断 「製品名　API」と検索し、APIの提供が確認できるページがある 製品ウェブサイト内機能一覧に、API提供について言及がある APIがあることが確認できた場合、以下のいずれかの手順でAPIドキュメントの有無を確認 3よりAPIの提供が確認できたページより、ドキュメントの遷移先URLの掲載がないか確認 「製品名　API documentation」と検索し、ヒットするものがないか確認 調査結果 調査対象とした1,226サービスのうち、1,080サービスが国内製品、146サービスが海外製品でした。各APIの提供状況および公開状況について、以下に示します。 ＜補足：「API提供」と「API公開」について＞ ■API提供とは APIが何らかの形で利用可能な状態を指します。利用者の範囲や条件は問わず、公開されているもの、契約者限定のもの、特定のサービス連携に限定されたものなど、あらゆる形態を含みます。 ■API公開とは APIが一般に公開され、誰でも利用できる状態を指します。具体的には、APIドキュメントが公開されており、外部の開発者が自由に利用できる状況を指します。 API提供状況は海外製品が90%超に対して国内製品は約40%という結果に まず、国内外問わずのAPIの提供状況は48.2%でした。 しかし、内訳を見ると、海外製品のAPI提供率92.5%と比べ、国内製品は42.4%と、大きな差があります。 (件数にすると海外製品は135/146件、国内製品は466/1100件) API提供状況 API公開状況は海外製品が85%超え、国内製品は15%未満とその差が拡大 さらに、公開状況ともなると、海外製品の86.3%に対し、国内製品は14.7%と、その差はさらに顕著になります。 (件数にすると海外製品は126/146件、国内製品は162/1100件) API公開状況 ちなみに、APIを提供しているサービスのうち、そのAPIを公開している割合は、海外で93.3%、国内で34.5%という結果になりました。 　 国内SaaS企業のAPI公開状況に関する考察 今回の独自調査で、日本のSaaS企業がAPIの公開において、海外企業と異なる傾向にあることが明らかになりました。調査対象となった日本のSaaS 1,080サービスのうち、APIを公開しているのは14.7%にとどまり、海外SaaSの86.3%と比較して圧倒的に少ないことが明らかになりました。この傾向には、いくつかの要因が考えられます。 ■市場の特性とユーザーのニーズ  日本の市場は、単一のサービス内で完結する「パッケージ型」のソリューションが主流であり、複数のサービスを連携させて利用するニーズが海外に比べて限定的だった側面があると思われます。その背景には、長らく個別カスタマイズを中心としたSIer（システムインテグレーター）が主導してきた日本のIT市場の特性が考えられます。SIerが顧客の要望に合わせてシステムを個別に構築・運用してきたため、サービスをAPIでオープンに連携させるという発想が定着しにくかったのでしょう。 一方、海外では人材流動性の高さなどを背景に、ユーザー自身がサービスを導入・設定する「セルフサーブ」モデルが一般的です。ユーザーが自身の業務に合わせて複数のツールを自由に組み合わせて使うことを前提としているため、サービス間の円滑な連携は必須の要素となります。また、海外製品は最初からグローバル市場をターゲットにしていることが多く、世界中の多様なサービスとの連携を可能にするAPI公開は、競争力を高める上で不可欠な戦略といえます。 ■企業文化と技術的背景 こうした市場の特性に加え、APIの公開と維持には、セキュリティ対策や継続的な運用、そして技術的なサポート体制が不可欠です。日本の多くのSaaS企業は、先述の市場環境からしてAPI公開による具体的なビジネスメリットを得られる環境が整っていないことから、これらのコストやリスクを慎重に検討していると考えられ、API公開の決断に時間を要している可能性があります。また、それによってAPIの実装や運用に関する社内の知見がまだ十分に蓄積されていないことも、公開が進まない一因として考えられます。 今後の展望と「AI Ready」への課題 AIエージェントエコノミーが今後発展していく中、日本のSaaS業界にはいくつかの懸念すべき点が見受けられます。今後のSaaSがさらに成長するためには、AIエージェントが活用できる「AI Ready」な状態であることが重要です。そのためには、APIが公開され、豊富なドキュメントが整備されていることが不可欠となります。もしAPIをまだ公開していない企業があるならば、これは早急に改善すべき課題となるでしょう。 自社のSaaSと外部サービスをシームレスに繋ぐAPIは、新たなビジネスチャンスを切り拓く鍵になると考えられます。外部サービスとの連携はもはや単なるオプションではなく、APIをコアビジネスに据えることで、より広範なユーザーの獲得に繋がり、市場での競争優位性を確立できるのではないでしょうか。 また、今後は金融や医療といった機密性の高いデータを保持する業界でも、データ連携の波は避けられないと想像できます。金融分野では改正銀行法によるオープンAPIの整備が努力義務とされ、医療分野では医療DX推進を通じた電子カルテ情報共有サービスの活用などが促されています。こうした法整備や国家戦略が、この波を強く後押ししていると言えるでしょう。APIを通じて、安全で信頼性の高いデータ流通の仕組みは、これからのSaaSに求められてくるのではないでしょうか。 APIという武器を手に、外部サービスと協力して業界全体のイノベーションを加速させることで、日本のSaaSが次なる成長フェーズへと進み、グローバルな競争力を獲得する鍵となるのではないでしょうか。 お問い合わせ support@saasus.io : 株式会社アンチパターン SaaSus Platform お問い合わせ窓口 --- ## SaaS開発の落とし穴 ~テナントオンボーディング編~ URL: https://saasus.io/blog/saas-development-issues-tenant-onboarding Date: 2025-08-31 はじめに：手動テナントオンボーディングの限界 新規テナントがSaaSの利用を開始するまでには、アカウント作成、初期設定、リソースのプロビジョニング、データのインポートなど、さまざまな準備作業が必要になります。この一連のプロセスをテナントオンボーディングと呼びます。 SaaS開発の初期段階では、これらの作業を手動で行うケースがあります。顧客情報の収集、環境構築、初期設定支援などを人手で対応することで、個別の要望に柔軟に対応できると考えられがちです。 しかし、手動でのテナントオンボーディングは、SaaSビジネスの成長を阻害する重大なボトルネックとなります。スケールできない運用体制は、SaaSモデル本来の利点を損ない、競争力を低下させます。特にタイムトゥバリュー（Time to Value: 顧客がSaaS製品の実際の生産性と価値を実感するまでに要する時間）の観点から見ると、手動プロセスは致命的な遅延を生み出します。 本記事では、手動テナントオンボーディングがなぜ問題なのか、その具体的な「落とし穴」を明らかにし、自動化による解決策について解説していきます。 手動テナントオンボーディングの問題点 ① 運用コストの増大 手動オンボーディングには、営業、カスタマーサクセス、エンジニアなど、多くの人的リソースが必要です。 顧客数が増えるにつれて、これらのコストは線形的に増加し、SaaSビジネスの最大の利点であるスケールメリットを享受できなくなります。 ② 俊敏性の低下 手動でのテナントオンボーディングは、新規顧客の獲得から実際の利用開始まで数日から数週間を要することがあります。 特にセルフサービス型のSaaSでは、ユーザーは即座にサービスを試したいと考えているため、サインアップ後に「担当者からの連絡をお待ちください」などとして利用可能になるまでに時間をかけることは、顧客の熱意を冷ますリスクとなります。 ③ ヒューマンエラーの誘発 手動作業は遅いだけでなく、設定ミスやデータの入力ミスといったヒューマンエラーを誘発します。特に以下のようなミスは深刻な問題につながります： 権限設定の誤り（他テナントのデータへのアクセス許可） リソース制限の設定漏れ（無制限のAPI利用など） 課金設定のミス（誤った料金プランの適用） データベースの接続設定ミス 環境変数の設定誤り これらのミスは顧客の信頼を損なうだけでなく、セキュリティインシデントや収益の損失にもつながりかねません。 特にサイロ型アーキテクチャにおいては、テナントごとに独立した環境を構築するため、環境間での設定の不整合が発生しやすくなります。これらの問題は運用チームの負担を増大させ、障害発生時の原因特定も困難にします。 自動化による解決策 ①  ワークフローエンジンの導入 複雑なオンボーディングプロセスには、ワークフローエンジンの導入が効果的です。AWS Step Functionsなどのツールを使用することで、以下が実現できます： プロセスの可視化: オンボーディングの各ステップの状態を把握できる エラーハンドリング: 失敗時の自動リトライや通知が可能 並列処理: 独立したタスクを並列実行して時間短縮 条件分岐: 料金プランや地域に応じた処理の分岐 ② セルフサービスポータルの提供 テナント管理者が自身で設定を行えるセルフサービスポータルを提供することも重要です。これにより、以下のような作業をテナント側で実施できるようになります： チームメンバーの招待と権限管理 支払い情報の更新 利用状況の確認とプラン変更 API キーの発行と管理 データのインポート/エクスポート ③ Infrastructure as Code (IaC) の活用 特にサイロ型のテナントオンボーディングでは、Infrastructure as Code (IaC) の活用が不可欠です。TerraformやAWS CDKなどのツールを使用することで、以下のメリットが得られます： 再現性の確保: 同一の設定で確実に環境を構築できる バージョン管理: インフラ設定の変更履歴を管理できる ロールバック: 問題発生時に以前の状態に戻せる レビュープロセス: コードレビューによって設定ミスを防げる IaCを活用することで、テナントごとのリソース作成を宣言的に定義し、料金プランに応じたデータベースサイズ、ストレージ制限、API利用制限などを自動的に設定できます。これにより、手動設定によるミスを排除し、一貫性のある環境構築が可能になります。 自動化されたオンボーディングフローの例 ここまで説明した要素を組み合わせると、理想的な自動化されたテナントオンボーディングは以下のようなフローになります： ユーザー登録の自動化 ・ユーザーがサービスにサインアップすると、即座にユーザーアカウントが作成される ・メールアドレスの検証やMFA設定も自動的に案内される テナント作成の自動化 ・ユーザーが組織情報を入力すると、自動的にテナントが作成される ・初期ユーザーは自動的にテナント管理者権限が付与される 料金プランとの連携 ・ユーザーが選択した料金プランに基づいて、請求サービス（Stripeなど）と連携される リソースのプロビジョニング ・選択された料金プランやテナントの要件に応じて、必要なリソースが自動的にプロビジョニングされる まとめ テナントオンボーディングは、SaaSビジネスの成長において極めて重要な要素でありながら、しばしば見過ごされがちな領域です。手動でのオンボーディングは、運用コストの増大、俊敏性の低下、ヒューマンエラーの誘発といった深刻な問題を引き起こします。 これらの課題を克服するためには、設計段階からオンボーディングの自動化を考慮し、IaCやワークフローエンジン、セルフサービスポータルなどの適切なツールと技術を活用することが不可欠です。 自動化されたテナントオンボーディングは、単なる効率化の手段ではなく、SaaSがスケールし、競争力を維持するための戦略的投資です。顧客がサインアップしてから価値を実感するまでの時間を最小化し、優れた顧客体験を提供することで、持続的な成長を実現できます。 E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 --- ## SaaSファーストとは？ URL: https://saasus.io/blog/what-is-saas-first-for-saas-development Date: 2025-08-29 1. はじめに：SaaS開発を取り巻く環境 近年、あらゆる業界でSaaS（Software as a Service）の利用が浸透し、ビジネスに不可欠な存在となっています。これに伴い、自社で新たなSaaSを開発し、市場に価値を提供しようとする動きも活発です。SaaS開発は大きな可能性を秘めていますが、成功のためにはSaaS特有の課題を乗り越える必要があります。 本記事では、SaaS開発におけるアプローチとして注目される「SaaSファースト」について解説します。 2.「SaaSファースト」とは？クラウドファーストとの違いについて 「SaaSファースト」とは、システムを導入・刷新する際に、「SaaSを最優先の選択肢として検討する」という、具体的かつ実践的なアプローチを指します。 一方、クラウドファーストは、より広範な概念であり、物理的なサーバーを自社で管理する従来のオンプレミス型ではなく、クラウドサービス（IaaS, PaaS, SaaSの全てを含む）の利用を第一に考えるという企業全体の戦略方針です。 つまり、「SaaSファースト」とは「クラウドのメリットを最大限に享受するために、最もユーザーの手間がかからず、サービス化が進んだSaaSから検討しよう」という、クラウドファーストの思想を最も推し進めた、現代的な実践方法であると言えます。 このアプローチはSaaSの開発においても非常に重要です。 3.SaaS開発における「SaaSファースト」とは？ SaaS開発における「SaaSファースト」とは、一言で言えば、「SaaS開発において『すべてを自社で作る』のではなく、『活用できるものは賢く使う』」という戦略的なアプローチです。 具体的には、認証、課金、監視といった多くのSaaSに共通して必要となる機能の構築を、その分野に特化した実績のある外部の専門SaaSに任せることを意味します。これにより、自社の開発リソースを、サービスの独自性や競争力の源泉となるコア機能の開発に集中させることを目指します。 この「選択と集中」こそが、SaaS開発におけるSaaSファーストの基本的な考え方です。ではなぜ今、このようなアプローチがSaaS開発において重要視されているのでしょうか？ それは、SaaS開発において直面する、特有の課題と深く関係しています。 4. なぜSaaSファーストが重要なのか？ SaaS開発特有の課題 SaaS開発においてSaaSファーストというアプローチが重要となる理由の1つに、SaaSならではの難しさがあります。これらを正しく理解することが、なぜSaaSファーストが有効なのかを示す鍵となります。 (1) テナントを前提とした横断機能の複雑さ SaaSの中心には「テナント」という概念が存在します。ユーザー管理、権限設定、契約や課金、監査など、あらゆる仕組みはテナントを基点として組み立てられます。逆に言えば、テナントという単位をどう定義し、どう扱うかによって、SaaS全体の難易度や設計の方向性が大きく変わります。この「テナント中心の設計」という前提がSaaS開発をより複雑かつ難解にする要因と言えます。 たとえば、SAMLやOIDCによるシングルサインオン、SCIMによるユーザー自動連携、契約プランに応じた機能提供は、いずれもテナント単位での制御を前提としています。さらに、利用量に基づくメータリングや複雑なサブスクリプション課金、請求処理も、すべてテナント単位で正確に管理しなければなりません。加えて、監査証跡を残し「誰がいつ何をしたか」を追跡可能にすることは、顧客からの信頼や法令遵守のために重要な仕組みです。 こうした機能群は一見すると周辺的に見えますが、実際にはSaaSを事業として成立させる基盤であり、SaaS開発における複雑性を高めています。 (2) 規制対応と継続的キャッチアップの難しさ SaaSの難しさはリリースして終わりではなく、その後も続きます。サービスを安定して運用しつつ、常に変化する規制や法令等の外部環境へのキャッチアップが求められるからです。 例えば、データ保護やプライバシーに関する規制は国や地域ごとに異なり、しかも厳格化・多様化が進んでいます。EUのGDPR、米国のCCPA、日本の個人情報保護法など地域ごとに異なるルールに対応しなければならず、遅れれば法的リスクや顧客からの信頼低下を招きます。もちろん、プライバシー以外の面でも、その地域の法令等に合わせた対応が必要になります。 そして、この課題はグローバル展開するSaaSに限りません。国内のみで提供するSaaSであっても、法改正への対応は不可欠です。例えば、請求・決済に関連して言えば、近年では消費税率の変更やインボイス制度の導入といった国内法改正が直接的に影響し、開発・運用チームに継続的な対応を迫られたケースが記憶に新しいでしょう。法改正だけでなく、金融・医療・公共といった業界を対象とする場合は、さらに業界固有の監査基準やセキュリティ要件への対応も必要になります。 これらの外部環境に対する高度な専門知識をキャッチアップし、開発に反映させる必要があるという点はSaaS開発における難しさの1つと言えます。 これらの課題は内製に頼るほどリスクとコストが膨らみやすく、SaaSファーストというアプローチが強く求められる背景となっています。 5. SaaS開発における「SaaSファースト」の実践：共通機能はSaaSを活用 SaaSを開発・運用するには、エンドユーザーに直接価値を提供する「アプリケーションプレーン」の機能に加え、SaaS自体の運用・管理を担う「コントロールプレーン」の機能が必要不可欠です。 コントロールプレーンには、テナント管理、ユーザー管理、認証認可、利用量計測、請求、ログ収集といった、多くのSaaSに共通して求められる機能が含まれます。これらをすべて自社で開発するには、膨大な工数とコスト、そして専門知識が必要です。 そこで「SaaSファースト」の考え方に基づき、これらのコントロールプレーン機能を、その領域に特化した外部のSaaSを活用して構築します。このようにSaaS開発を支援する目的で提供されるSaaSは、「SaaS for SaaS」（特にSaaS提供者向けという意味で「SaaS for SaaS Provider」） と呼ばれることもあります。具体的な活用例としては、以下のようなものが挙げられます。 ① 認証・認可SaaS: (例) Auth0 - セキュアで高機能な認証基盤を迅速に導入。 複雑な認証認可処理を専門SaaSに任せることで、開発負担を軽減しセキュリティを高めます。 ② サブスクリプション・請求管理SaaS: (例) Stripe - 多様な料金体系や決済処理に対応。 変動する料金プランやグローバルな決済にも柔軟に対応可能になります。 ③ パフォーマンス監視・運用管理SaaS: (例) Datadog, New Relic - サービスの安定稼働を支援。 24時間365日の監視体制や障害対応、パフォーマンス分析を効率化します。 ④ SaaS開発プラットフォーム: (例) SaaSus Platform - コントロールプレーン機能を包括的に提供。 複数のSaaSを組み合わせる手間を省き、より開発に集中できる環境を構築します。 このように、SaaS開発における共通的かつ専門性の高い領域で外部SaaSを活用することが、「SaaSファースト」の具体的な実践となります。 6. SaaSファーストがSaaS開発にもたらすメリット SaaS開発において「SaaSファースト」のアプローチ、すなわち外部のSaaS（開発支援SaaS）を活用することは、単なる効率化に留まらず、事業成長に直結する多くのメリットをもたらします。 (1) 開発スピードの向上: コントロールプレーンの共通機能を外部SaaSで代替することで、その開発・テストにかかる工数を大幅に削減できます。 結果として、開発チームは自社サービスのコアとなる「アプリケーションプレーン」の機能開発にリソースを集中でき、プロダクトの市場投入までの時間を短縮できます。 (2) 運用負荷の軽減とスケーリング対応: 監視、障害対応、負荷分散といった運用業務や、サービスの成長に伴うスケーリング対応は、専門SaaSが提供する機能を利用することで、自社での運用体制構築・維持の負担を軽減できます。 専門知識や人的リソースが限られていても、安定したサービス運用を実現しやすくなります。 (3) プロダクト品質と事業スピードの両立: すべてを内製する場合、開発リソースが分散し、特にコントロールプレーンの品質担保やセキュリティ対策が後手に回るリスクがあります。 実績のある外部SaaSを活用することで、堅牢なプロダクト基盤を迅速に構築でき、開発スピードを維持しながら高い品質とセキュリティを確保することが可能になります。 (4) 専門領域のベストプラクティスの活用: 認証、決済、セキュリティなどの専門領域では、常に最新の技術動向や法規制への対応が求められます。これらを自社だけで追い続けるのは困難です。 Auth0やStripeのような専門SaaSを利用することは、単に機能を導入するだけでなく、その分野のプロフェッショナルが持つ知見やベストプラクティスをサービスとして享受することを意味します。 自社で開発すべきは独自性や差別化につながるコア機能に絞り、変化の激しい専門領域は外部SaaSに任せる方が、スピードと品質の両面で有利になります。 7. まとめ：SaaS開発の成功のために「SaaSファースト」を意識する 本記事では、SaaS開発における「SaaSファースト」の考え方、すなわち認証・課金・監視といった共通基盤機能を外部の専門SaaSで構築するアプローチについて解説しました。 SaaS提供企業には、スピーディな開発、安定運用、柔軟なスケーリングが常に求められます。こうした要求に応える上で、「SaaSファースト」の考えに基づき、外部SaaSを賢く活用することは、開発リソースの最適化と事業のスケールを両立する極めて有効な戦略です。 「すべてを自社でつくる」のではなく、「活用できるものは賢く使う」。この発想転換こそが、開発チームを本来注力すべきコア機能の開発へと導き、競争力の高いSaaSを迅速に市場へ届けるための鍵となります。SaaS開発に取り組む際には、ぜひ「SaaSファースト」の視点を取り入れてみてください。 --- ## SaaS開発の落とし穴 ~マルチテナント編~ URL: https://saasus.io/blog/saas-development-issues-multitenant Date: 2025-05-07 はじめに：マルチテナントアーキテクチャとは Software as a Service (SaaS) では、複数の顧客 (テナント) に対して単一のアプリケーションを提供することが一般的に行われますが、この状態をマルチテナントと呼んでいます。 本記事を通して、マルチテナントアーキテクチャ特有の「落とし穴」について入門していきましょう。 ① データ分離 マルチテナントのアーキテクチャは複数ありますが、デプロイモデルの観点では プール型 : 複数のテナントが同じコンピュート/ストレージを共有する サイロ型 : テナントごとにコンピュート/ストレージを用意する ブリッジ型 / ハイブリッド型: 共有するリソースと共有しないリソースが混在する のように分けられ、それぞれにメリット・デメリットがあります。 プール型のようにデータストレージを複数テナントで共有する場合、アプリケーションの実装不備によって、テナント間でデータが意図せず混在したり、他のテナントのデータへ不正アクセスできてしまったりする可能性があります。 他のアーキテクチャでも同様です。例えばテナントごとにデータストレージを分けるサイロ型は、プール型に比べて安全だと思ってしまいそうですが、ストレージの公開範囲やテナントごとのアクセス権限を誤るといったリスクは常に存在します。 対策 マルチテナントSaaSにおけるユーザーの認証・認可では、個人単位の識別や権限だけでは足りません。該当ユーザーがどのテナントに所属し、そのテナントにおいてどのような権限が割り当てられているのかを判断する情報 (テナントコンテキスト) が必要になります。 テナント間のデータ混在や不正アクセスを防ぐには、このテナントコンテキストに基づく厳格なデータ分離を設計段階から考慮する必要があります。 これにはデータベース固有のセキュリティ機能やID管理サービス（IDaaS）の活用も有効です。 例えば、代表的なRDBMSの一つであるPostgreSQLには、Row Level Security (RLS) という機能があります。RLSをテナントIDに対して有効化することで、データベース側でのテナント分離が可能になります。 ② パフォーマンス プール型のアーキテクチャなどにおいて、複数のテナントが計算資源 (CPUやメモリ)、データベース接続、ネットワーク帯域などのリソースを共有することを考えます。このとき、あるテナントの利用量が急増すると、他のテナントのパフォーマンスが低下するリスクがあります。 このように、あるテナントが他のテナントのパフォーマンスに影響を与えてしまう問題を、「ノイジーネイバー問題」といいます。 対策 このようなパフォーマンスの問題への対策としては、まずは負荷に応じて柔軟にスケールできるアーキテクチャ設計が基本となります。必要に応じてテナントごとのリソース制限 (スロットリング) の導入も検討します。 また、運用においては、テナントごとのリソース使用状況を継続的に監視し、異常を早期に検知することが重要です。 また、非常に利用量の大きいテナントのみ別リソースに切り出し、サイロとする方法も考えられます。この場合、後述のテナントオンボーディングなどにおいて複雑性が増すというトレードオフに注意する必要があります。 ③ カスタマイズ マルチテナントSaaSは、単一のアプリケーションを複数の顧客が使うことでスケールするビジネスモデルです。 しかしながら、SaaSを利用するテナントは、それぞれ独自の業務要件やブランディングに合わせて、UI、機能、ワークフロー、データ項目などのカスタマイズを要求することがあります。 これらのカスタマイズ要求に対してすべて答えようとすると、迅速な開発を阻害し、SaaSがスケールしづらくなる恐れがあります。特に、テナントごとにソースコードが別になるような設計をしてしまうと、SaaSのスケールメリットが大きく損なわれてしまいます。 対策 カスタマイズ要求に対応しつつ効率的な管理を維持するためには、テナントごとのソースコード分岐を伴わない手法が強く推奨されます。 例えば、フィーチャーフラグ (機能フラグ) を用いることで、テナントごとの機能の分岐が可能になります。 また、料金プランによって使える機能が異なるような設計も考えられます。 その他に、APIを提供することで、顧客が自らSaaSの機能を柔軟に組み合わせて利用することができるようになります。より発展的には、SaaSがModel Context Protocol (MCP) に対応することで、SaaS本体のUIにとらわれず、ユーザーごとにカスタマイズされたAIエージェントがSaaSの機能を扱える、といった新しい潮流もあります。 ④ テナントオンボーディング 新規テナントがSaaS利用を開始するためには、複数の準備項目が必要になる場合があります。 例えば、 テナントの情報を入力する 初期データをインポートする テナント用のリソースを用意する (サイロなどの場合) などのプロセスが考えられます。これらのテナントの準備プロセスをテナントオンボーディングといいます。 テナントオンボーディングを毎回手動で行う場合、非常に時間がかかり、SaaSのスケールを阻害する要因になります。また、設定ミスなどのヒューマンエラーも発生しやすくなります。 対策 テナントオンボーディングはアプリケーション実装よりも優先度が低く見積もられがちですが、スケールするSaaSをつくるために最も重要な項目の1つです。自動化可能な部分を増やすべく、設計当初から検討することが求められます。 テナントオンボーディングに必要なことを事前に洗い出し、スクリプト化やワークフロー化を進めましょう。テナント自身が設定を行える画面の提供も有効な手段となります。 サイロ型の場合でも、インフラ構成管理ツールを用いることでリソースの用意を自動化することができます。Terraform や CDK といった Infrastructure as Code (IaC) の利用が推奨されます。 まとめ マルチテナントという考え方はSaaSを提供する上で重要な位置を占めますが、本記事で見てきたように、データ分離、パフォーマンス、カスタマイズ、テナントオンボーディングなど、多岐にわたる特有の課題が存在します。 これらの課題は決して無視できるものではなく、サービス品質や信頼性、運用効率に直結します。 しかし、 設計段階からの綿密な計画 自動化を積極的に取り入れた効率的な運用体制の構築 適切なツールや技術の活用 といった取り組みによって、これらの課題を克服することが可能です。 また、最初からすべてを完璧に対応する必要はありません。SaaSのスケールに合わせて段階的に対応していきましょう。 本記事で解説した課題とその対策が、皆様のSaaS開発・運用において、より安全でスケーラブルなマルチテナント戦略を検討・実践するための一助となれば幸いです。 E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 --- ## 【導入事例】株式会社JERA URL: https://saasus.io/blog/jera Date: 2025-04-04 株式会社JERA は、「JERAゼロエミッション2050」を掲げ、2050年時点での国内外の同社の事業から排出されるCO₂実質ゼロに挑戦する。 今回は発電所構内で利用される避難誘導システムのSaaS化への取り組みについて、株式会社JERAの大澤さんと小澤さんにお話を伺いました。 ＜プロフィール＞ 大澤さん： 発電設備エンジニアとして、O&M、建設工事、制御設備設計などの設備関連業務に従事。その後、企画部門にて発電所のデジタル化プロジェクト推進を担当。現在は、IT・デジタル戦略の新モデル構築や、デジタル技術を活用した業務変革の推進に取り組んでいる。 小澤さん： 発電設備エンジニアとして、O&Mに従事。現在は、デジタル技術を活用した業務変革の推進に取り組んでおり、DPPを初めとしたプロダクト開発を担当している。 安全確保のためのSaaS化という選択 ーまずは貴社の事業内容やサービス（プロダクト）について教えてください。 大澤さん： 弊社は燃料の上流開発・調達から発電、卸売までのバリューチェーン全体に関わる事業を展開しております。その中で、ICT部門では、事業開発、O&M（運用・保守）･E（エンジニアリング）、最適化、コーポレートの各分野にて並行してプロジェクトを進めており、バリューチェーン全体のDXを推進しております。O&M･Eの領域においては、「発電所の設備と人の仕事」をパッケージ化し、データやAIを活用した高度なO＆Mをアプリケーションに実装し、価値を確実に生む仕組みを構築するDigitalPowerPlant(DPP)に取り組んでいます。 私たちはDPPのうちHSSE(Health/Safety/Security/Enviroment)領域の開発に携わっています。今回の取り組みにおいては、災害時に発電所入構者の安全を守る避難誘導サポートシステムを構築しております。 ー避難誘導サポートシステムの開発に至った背景を教えてください。 大澤さん： JERAでは、「JERAゼロエミッション2050」の実現のために、水素やアンモニアを大量に取り扱うことになります。その一環として、世界初となる大型商用石炭火力発電機における**燃料アンモニア転換の大規模実証試験（熱量比20%）**を、JERA碧南火力発電所（愛知県碧南市）にて実施しました。（本実証試験は2024年4月から6月まで実施） アンモニアは毒劇物であるため、万が一発電所構内で漏洩が発生した場合でも、構内で働く全ての方が安全に避難できるよう、避難および誘導を目的とした機能の提供を計画しました。 JERA碧南火力発電所における燃料アンモニア転換実証試験を開始―世界初となる大型の商用石炭火力発電機でのアンモニア20％転換の実証― | プレスリリース（2024年） | JERA また、働き方改革の推進も理由の一つです。属人化された業務を、体系化された仕組み（システム）として構築し、安全確保に関わる情報の提供および情報収集の時間を最短化することは働き方だけでなく、より安全性を高める上でも重要なポイントでした。 ー避難誘導サポートシステムで実現したいことは何でしたか？ 小澤さん： 発電所構内に入構するすべての方が、自身の安全を確保できるようなサービスを提供することです。 そのためにはいくつかの壁を乗り越えなければなりませんでした。まず、発電所には社内の人間はもちろん、社外の方の出入りもあるので、構内の全ての人がアクセスできる環境を整備する必要がありました。その上で、セキュリティを担保する必要もありますし、有事の際に不具合で使えないというようなことが起こらないように、維持・保守が容易なシステムである必要があります。 スクラムチームとSaaSus Platformで開発を加速 ーSaaSやSaaS開発についてはどのようなイメージをお持ちでしたか？ 小澤さん： SaaSについては、汎用的なものでより多くのユーザーが簡単に利用できるようなイメージを持っていました。またSaaS開発に関しては、弊社のような事業会社ではなく、IT会社がよりスピーディーに市場に合わせて開発をしているイメージだったので、我々の業務やナレッジをバーティカルSaaSとしてリニューアルするというのは興味深かったです。 ープロジェクトの体制について教えてください。 大澤さん： JERAのICT部門にとっても新しい取り組みであるため、各所からのサポートを受けながら、スクラムチーム体制で取り組みました。 企画・体制組成：デジタルトランスフォーメーションU 専門家チーム：セキュリティ、ネットワーク 技術サポート：AWS社（ソリューションアーキテクト）、アンチパターン社（SaaSus Platform開発支援） 商品企画：営業部門 プロダクトオーナー：O&M部門 開発チーム：ICT部門（＋開発ベンダー） ーSaaSus Platformを利用した感想を教えてください 小澤さん： SaaSus Platformは非常に直観的で分かりやすく、ユーザー管理に関しては不慣れな私でも簡単に利用できるものでした。SaaSなのでユーザーが増える前提ですが、操作としては少ないリソースで対応できるように感じております。また、今回はJERA保有の発電所入退構システムに連携して、ユーザー管理を行っていますが、そのシステムに乗らない一時的なユーザーへの対応も実施しております。こちらについてはQRを用いた権限付与となりますが、これまで対応外としていた方々にサービス提供ができるようになったため効果があったと感じております。 また、認証や請求といったSaaSとして必要な一般機能が網羅されており、業務的に必要な機能開発に注力できる部分がメリットと感じました。 SaaSを展開し成長させていく ー貴社の事業の今後や避難誘導サポートシステムの見据える未来について教えてください。 大澤さん： 今回開発した避難誘導システムについては、現在、社内の26発電所への展開を進めており、発電所構内で働くすべての方の安全確保に注力しています。一方で、実際に利用される社外のお客様のご意見を伺いながら、お客様のニーズに沿ったサービスの提供を検討していきます。 ーSaaSus Platformに今後期待することは何ですか？ 小澤さん： JERAは日本国外でも事業を展開しているため、社内では国内外で活用できる標準環境の設計を推進しています。今後は、日本国外でも利用可能な環境やサービスの提供を期待しています。 ーSaaSus Platform、10Days SaaSificationの導入を検討している方に何か一言ありますか？ 大澤さん： SaaSサービスの提供を検討する際、以下の2点が大変心強いと感じました。 まずSaaSus Platformに関しては、SaaS開発に必要な機能を標準的に提供してくれることです。SaaS開発を経験していないと、そもそもどんな機能が必要なのか？というところから考えなくてはいけませんが、SaaSus Platformを利用すれば開発の工数だけでなく、リサーチや検討の手間や時間も削減できます。10Daysについては、SaaS環境の開発サポートを受けられることは大きな魅力だと感じました。 開発スピードが劇的に向上し、当社の通常の開発期間の約1/3の期間で提供することが可能となりました。SaaS開発に不安があったり、課題を感じている方には、10Days SaaSificationそしてSaaSus Platformの活用をおすすめしたいです。 ーありがとうございました！ --- ## SaaSコントロールプレーンとは？コントロールプレーンの役割と重要性 URL: https://saasus.io/blog/saas-control-plane-importance Date: 2025-03-05 はじめに SaaS（Software as a Service）は、単なるクラウド上で動くアプリケーションではなく、継続的に提供される「サービス」です。SaaSを成功させるためには、ユーザーが直接利用するアプリケーションだけでなく、その裏側でサービスを管理し、運用する仕組みが不可欠です。 このサービスを支える仕組みが 「コントロールプレーン」 です。 多くのSaaS開発者やプロダクトマネージャーは、直接的に価値をもたらす部分である「アプリケーションプレーン」（ユーザー向けの機能）に注目しがちです。しかし、実際にスケールし、成長するSaaSを作るには、適切に設計された「コントロールプレーン」が欠かせません。 本記事では、 SaaSにおけるコントロールプレーンとは何か？ アプリケーションプレーンとの違いは？ コントロールプレーンが担う役割とは？ なぜコントロールプレーンがSaaSの成長にとって重要なのか？ といった点について解説します。 SaaSにおける「アプリケーションプレーン」と「コントロールプレーン」 アプリケーションプレーンとは？ SaaSの「アプリケーションプレーン」とは、ユーザーが利用するサービスのコアとなる機能のことを指します。例えば、 会計SaaSなら 「見積書作成・請求書作成」 CRMなら 「顧客管理・レポート作成」 といった具体的なサービス部分が該当します。 アプリケーションプレーンは、あくまで「ユーザーに価値を提供する部分」であり、SaaSの中核となる機能ですが、それだけでは十分ではありません。 コントロールプレーンとは？ 一方、コントロールプレーンは 「SaaSを運用・管理するための仕組み」 を担います。 SaaSは単に提供して終わりではなく、継続的な運用が求められます。コントロールプレーンの主な役割として、 テナント管理（複数企業・ユーザーのデータ管理と分離） ユーザー管理（認証・認可、アクセス制御） 課金・請求管理（サブスクリプションの管理と決済） 監視・運用管理（パフォーマンス監視、障害対応） などが挙げられます。 これらの機能が適切に設計されていないと、SaaSの成長とともに管理の負荷が増大し、運用が困難になります。 次の章では、コントロールプレーンの具体的な役割について詳しく見ていきます。 コントロールプレーンの主な役割 (1) テナント管理 SaaSでは、複数の企業やユーザーが同じシステムを利用します。そのため、各テナントのデータを適切に管理・分離し、セキュリティを確保することが重要です。 テナントごとのデータ分離（共有データベースでのアクセス制御、専用インスタンスの管理） テナントごとの設定管理（契約プランに応じた機能、数量等の制限） (2) ユーザー管理 SaaSでは、さまざまなユーザーが異なる権限で利用します。コントロールプレーンには、ユーザーの識別・管理を行う役割があります。 認証・認可の管理（SSO、OAuth、RBAC） (3) 課金・請求管理 SaaSのビジネスモデルでは、定期課金や従量課金が一般的です。そのため、課金処理の自動化が求められます。 サブスクリプションの管理（プラン変更、アップグレード・ダウングレード） 利用量に応じた従量課金（APIコール数やストレージ使用量に基づく課金） (4) 監視・運用管理 SaaSの安定運用を支えるために、システムの監視や運用が不可欠です。 パフォーマンス監視（レスポンスタイム、エラーレートの監視、ノイジーネイバーの検出） 障害対応（ログ管理、異常検知、アラート） 以上のような役割を担うコントロールプレーンが適切に設計され、機能していることで、SaaSのスムーズな運用が実現でき、スケーラビリティが実現できます。 次の章では、コントロールプレーンの重要性について詳しく見ていきます。 コントロールプレーンがSaaSの成長に必要な理由 SaaSが成長するにつれて、コントロールプレーンの適切な設計がより重要になります。拡張性が不十分なコントロールプレーンは、長期的に以下の課題を引き起こす可能性があります。 (1) スケーラビリティの問題 SaaSの成長に伴い、顧客数やデータ量が増加すると、リソースの動的な割り当てが求められます。コントロールプレーンが適切に設計されていない場合、負荷分散がうまく機能せず、パフォーマンスの低下を招くことになります。 【対策】 動的リソース管理：リソースの自動スケーリングや負荷分散を実装し、顧客の急増にも対応できる仕組みを整える。 APIレートリミットの適用：各テナントが公平にリソースを利用できるようにする。 (2) セキュリティリスク SaaSでは、複数のテナントが同じインフラを共有することが一般的です。そのため、適切なデータ分離とアクセス制御を行わなければ、情報漏洩や不正アクセスのリスクが高まります。 【対策】 厳格なアクセス制御の実施：RBAC（ロールベースアクセス制御）やIAM（アイデンティティ・アクセス管理）を活用する。 適切なデータ分離：テナントごとに独立したデータ領域を確保したり、同じデータストアであっても行レベルセキュリティなどを活用したりすることで、テナントごとのデータ分離を徹底する。 (3) 運用コストの増大 コントロールプレーンが十分に機能しておらず手動での管理が行われている現場では、運用チームの負担が増し、運用コストの増加と人的ミスによるリスク増加につながります。 【対策】 自動化の導入：インフラの管理、障害対応、パフォーマンス監視を自動化することで、人的リソースの消費を抑える。 セルフサービス機能の提供：顧客が自らテナント管理やプラン変更を行えるようにすることで、運用負荷を軽減する。 (4) 柔軟なサービス展開の実現 SaaSの成長には、新機能の迅速なリリースや、新しい課金プランの導入が不可欠です。コントロールプレーンの設計が固定的すぎると、ビジネスの変化に適応しづらくなります。 【対策】 柔軟な課金システムの設計：新しいプランや従量課金モデルを迅速に適用できる仕組みを整える。 マルチリージョン展開のサポート：各地域の規制やパフォーマンス要件に適応するための設計を行う。 適切なコントロールプレーンを構築することで、これらの課題を解決し、持続的なSaaSの成長を実現できます。 次の章では、SaaS開発の初期からコントロールプレーンを意識すべき理由について詳しく見ていきます。 SaaS開発の初期からコントロールプレーンを意識すべき理由 SaaSの開発初期において、コントロールプレーンの設計を軽視すると、後の運用やスケールが困難になります。長期的にスムーズなサービス提供を実現するために、初期段階からコントロールプレーンを設計に組み込むことが重要です。 『マルチテナントSaaSアーキテクチャの構築 ―原則、ベストプラクティス、AWSアーキテクチャパターン』（著：Tod Golding、訳：河原 哲也、櫻谷 広人）においても、SaaSのコントロールプレーンを初期段階に適切に設計する重要性を説いています。 「アーキテクトやビルダーは、アプリケーションのマルチテナントの側面からSaaSの議論を始めたいと思うことがよくありますが、SaaSアーキテクチャの基礎はコントロールプレーンから始まります。多くの点において、コントロールプレーンは強制的な機能として働き、エンジニアは開発の初期段階からテナントのさまざまな側面を考慮し、対応することが求められます。」 なお、著者であるTod Golding氏はAWSのシニアプリンシパルソリューションアーキテクトであり、SaaS分野における世界的な技術リーダーとして知られています。彼は、AWS SaaS Factoryチームの一員として、SaaSアーキテクチャのベストプラクティスやパターンに関する豊富な知識と経験を持ち、数多くの企業やパートナーと協力して、AWS上でのSaaSソリューションの構築、提供、最適化に取り組んできました。さらに、Golding氏はAWS re:Inventなどの主要なイベントで講演を行い、SaaSアーキテクチャに関する最新の知見や実践的な戦略を共有しています。彼の専門知識と洞察は、日本企業がAWS上で効果的なSaaSを設計・導入する際の強力な指針となるでしょう。 例：SaaS meets cell-based architecture: A natural multi-tenant fit (SAS315) (1) 早期設計のメリット SaaSの初期段階からコントロールプレーンを適切に設計することで、以下のメリットが得られます。 スムーズなスケール対応：初期の設計から拡張性を考慮することで、将来的な負荷増加に柔軟に対応できる。 セキュリティリスクの軽減：データ管理やアクセス制御を早期に整備することで、テナント間のセキュリティ課題を回避できる。 運用の効率化：管理業務の自動化や統合ツールの導入により、長期的な運用コストを削減できる。 (2) 後付け対応のリスク 開発の後半や運用段階でコントロールプレーンの不足を補おうとすると、以下のようなリスクが発生します。 アーキテクチャの大幅な変更が必要になる：基本的な構造が固まった後でコントロールプレーンを導入すると、システムの大規模なリファクタリングが必要になり、時間とコストが増大する。 サービス提供の遅延や品質低下：適切な監視や管理機能がないまま顧客が増えると、パフォーマンスの問題や障害発生時の対応遅れが生じる。 ユーザーエクスペリエンスの低下：テナント管理や課金管理の不備により、顧客対応が遅れたり、不適切な請求が発生する可能性がある。 (3) コントロールプレーン設計のベストプラクティス SaaS開発の初期からコントロールプレーンを設計するためのポイントを以下に示します。 マルチテナント対応を想定する：データの分離やテナントごとの設定管理を適切に設計する。 自動化を前提にする：ユーザー管理、課金処理、パフォーマンス監視などのプロセスを自動化する。 スケーラブルなアーキテクチャを採用する：負荷分散やコンテナ技術を活用し、拡張しやすい構造を構築する。 これらのポイントを意識することで、SaaSの成長に耐えうるコントロールプレーンを設計し、持続可能なサービス提供が可能になります。 まとめ ビジネススケールしていくSaaSには、アプリケーションプレーンだけでなく、コントロールプレーンが不可欠です。コントロールプレーンが適切に設計されていないと、スケーラビリティの問題、セキュリティリスク、運用コストの増加、柔軟なサービス展開の妨げなどの課題が生じます。どれほどアプリケーションプレーンが優れていたとしても、コントロールプレーンが十分に機能しなければ、ユーザーエクスペリエンスが低下し、解約などのリスクに繋がります。 開発の初期段階からコントロールプレーンを意識し、スケーラブルでセキュアな設計を取り入れることで、持続的な成長と安定した運用を実現できます。 E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 --- ## 【導入事例】株式会社ペイミー URL: https://saasus.io/blog/payme Date: 2024-07-18 給与の前払いサービス「Payme」で知られる株式会社ペイミー。セールステック参入への第一歩として「セールススクラムAI」でのSaaS開発にSaaSus Platformをご活用いただいています。 今回は株式会社ペイミーのCTOを務める白井英さんにSaaSus Platform導入の背景とその効果についてお聞きしました。 スピード感のある開発の実現のために ーまずは会社や事業の概要と白井さんの本事業におけるポジションを教えてください。 白井さん： 弊社はこれまで社名にもなっている「Payme」という給与の前払いサービスを手がけてきました。今回は「Payme」ではなく、新しく始める事業であるAIを使ったセールステックサービス「セールススクラムAI」にSaaSus Platformを使っています。「セールススクラムAI」は営業活動の中でAIを活用して、ワークフローの効率化を目指すサービスです。 私自身は、CTOとして開発の責任者という役割で「セールススクラムAI」に携わっています。技術選定やアーキテクティングの部分を主に担当しています。SaaSを作るのは初めてですが、私もこれまでエンジニアとしてキャリアを歩んできたので、サービスの核となる重要な部分については自分でやるようにしています。 ーありがとうございます。「Payme」と「セールススクラムAI」ではだいぶ毛色が違うように感じるのですが、異なる分野でのサービス展開を始めた背景など伺えればと思います。 白井さん： 新しく事業を始める上で、もちろん既存事業の発展という想定もありましたが、弊社の強みやメンバーの特性を生かした分野を模索していたところ、セールステックに可能性を感じました。社内でも営業人材が多く、「Payme」での営業活動を通じて培った経験やノウハウがあるので、セールスの分野には明るいと自負しています。 ーSaaS開発の体制についてですが、エンジニアの数やSaaS経験者はいましたか？ 白井さん： 現状は少人数で開発を行っています。プロダクトマネージャー、デザイナー、フロントエンド担当とバックエンド担当のエンジニアがそれぞれ1人ずつですね。SaaS開発の経験者はいませんでしたが、そこはあまり重視しすぎず、どちらかと言えば新規事業の立ち上げ経験の有無を重視しましたね。SaaS開発経験者はまだまだ少なく採用難度が高いので、0→1ができる人材とともにSaaSと向き合っていく方が合っているのかなと。 ー事業を進めるにあたっての課題は何でしたか？ 白井さん： PDCAのサイクルを早くして開発を進めることで成果に繋がりやすくなるというのがこれまでの経験で肌感覚としてあったので、少人数でスピード感のある開発の実現のために何が必要かをまず最初に考えると、利用できるものをどんどん活用していくことが必要だなと思い至りました。SaaSus Platformの利用もそういった背景があり決断しました。 我々はエンジニアなので、自分たちで作ってしまおうという考えももちろんありましたが、スタートアップだと限られたリソースでどのように価値を提供していくかが重要なので、自社の開発力だけで価値を提供することに拘らず、外部サービスを活用することで近道をしていくというのが重要になります。 そういった背景もあり、外部サービスの選定を行っている時期にAWS Summit TokyoでSaaSus Platformを知りました。AWS Summit Tokyoで様々なサービスを見ながら、SaaS開発について吟味してみると、やはり1から全てを作るということは大変だろうなと漠然と感じました。 初めてSaaSを作るので、標準機能を予め備えているという期待感が導入の後押しになりました。ユーザー登録や課金などの共通部分を毎回作ることの大変さは理解していたので、自分たちで作るよりもアウトソースできるのであれば、その方がリソースを有効活用できると考えました。 根本にあるのは「働く人に幸せになってほしい」という思い ー「セールススクラムAI」ではどんなことを実現したいですか？ 白井さん： 「Payme」もそうですが、弊社の理念として「働く人に幸せになってほしい」という思いがベースにあります。 セールスとして働く人が働きやすくなったり、より業務に集中するためにはどうしたら良いのかを考えながら日々開発をしています。人が仕事できる時間は有限ですから、本来やるべき作業に集中した方が良いですよね。タイミング的にもAIの精度の向上など関心が高まっていたので、そういったテクノロジーに任せられる部分が増えることで、人がエネルギーを割くべき業務に集中できるのではないかと考えています。人とAIをはじめとするテクノロジーで役割分担をすることで、新しいセールスの形を生み出すことができれば、それによって働き方を変化させ、働く人を幸せにすることができれば良いなと願っています。 ーSaaSus Platformを導入時に懸念していた点はありますか？ 白井さん： 導入時に気にしていたのはベンダーロックインが起こらないかというところですね。サービスへの依存度が高すぎると、将来的に足枷になる可能性を孕むので。ただ、SaaSus Platformは最終的にSaaSusが担っている部分を「セールススクラムAI」側で巻き取るという選択肢があり、リソースが充足したタイミングで完全に自社運用に切り替えることも可能です。最初期の限られたリソースでの開発時には手間や時間をかけずに開発が進められますし、プロダクトが成長してからは自分たちでより発展させることもできます。もちろん、成長してからもSaaSus Platformを使い続けることもできます。その時の状況に応じていいとこ取りの選択肢ができるという点はとても魅力的でした。コントロールできる部分が多いので、共倒れのリスクなども低いと判断しました。 ーSaaSus Platformを導入してみて効果などは実感されていますか？ 白井さん： SaaSの開発が初めてで比較対象がないということもあり、具体的なことはお伝えできないのですが、手間やコストの面で楽ができている実感はあります。特にユーザーのログインや管理の部分については、これまでのエンジニアキャリアを通じて大変さを知っているので、そこを作らなくていいのは大きなメリットかなと思います。同じようなことが今後、課金の部分でも起こる想定ですが、そこもSaaSus Platformを使って楽ができると期待しています。当初はSaaSの課金についてのノウハウがなく不安でしたが、SaaSus Platformを使ってStripeと連携すれば自分たちで考えることが大幅に減るので、開発に入る前の時点で不安なことが潰せている状態で、将来的な怖さがなく開発を進められる安心感があります。 機能的な話ではありませんが、ソリューションアーキテクトの方には定例ミーティングを始め、よく相談に乗ってもらっているので、不安要素があってもすぐに解消ができています。SaaS開発経験がない身からすると、経験者に相談ができるというのはとても安心感があります。 ーSaaSus Platformのメリットは何だと思いますか？ 白井さん： コア機能であるAIの部分に殆どのリソースを割けているので、SaaSとしての共通部分に関しては初期には少し考えることもありましたが、現在は特に意識せずに開発が進められています。 大変そうだなと予め感じていた部分が手を離れることで、時間やリソースの使い方が大きく変わっているように感じます。SaaS開発未経験で勘所がなくてもSaaSus Platformを使うことでセオリーを抑えられるので、それらの趣旨をしっかり理解して反映させていくことで、SaaS開発のリスクを回避するための「土地勘」みたいなものが自然に備わる印象です。 「セールススクラムAI」でセールス活動全体を変革する ー事業の今後の展望について聞かせてください。 白井さん： 最初の機能は限定的なものになりますが、将来的には「セールススクラムAI」でセールス活動全体を変えていくというところを目指しています。SaaSらしく運用しながら、お客様のニーズを汲みつつ開発を走らせていく形になるかと思います。 セールス活動は所謂THE MODELのようにマーケティング、インサイドセールス、フィールドセールス、カスタマーサクセスという複数の段階に渡って行われます。その中のあらゆる領域で「セールススクラムAI」が使われ、効率化やワークフローの改善に寄与するようなサービスを目指しています。 サービスの在り方としては柔軟性を持たせるために、「セールススクラムAI」をセールス活動の領域ごとに切り分けて提供したりする場合もあるかもしれません。ユーザーの使い勝手やセールスを行っていく際に改めて検討が必要かと考えています。そういった場合に備えて、現時点からモジュラーモノリスの考え方を参考に将来的に切り分けをしやすいように開発を行っています。 ーSaaSus Platformに今後、期待することは何かありますか？ 白井さん： 開発している時に大変だなと感じるのものの一つに外部サービスとの連携があります。 Stripeのように、SaaSを開発する際に連携頻度の高い、ある種定番のような外部サービスとの連携機能を予めSaaSus Platform側で標準的に備えていてくれると、とても助かりますね。 弊社の場合だとAIを活用するサービスなので、導入企業様ごとに独自のAIモデルを作る際にAzure OpenAI Serviceを繋ぎ込むなどですかね。汎用的なものだとDatadogやNew Relicのようなパフォーマンス監視サービスを連携して、テナントごとの状況がみやすくなると良いかもしれません。SaaS運用が始まっていないので、ノイジーネイバーがどれくらいの頻度で起こるのか？や、その影響度合いなどが実感できていないので、モニタリングができたり、事前にリスクに備えられているような形だと土地勘がない人からすると安心に繋がるのかなと思います。 ー最後にSaaSus Platformの導入を検討している方に向けて何か一言をお願いします！ 白井さん： Saasの開発スピードを上げたい方、SaaSを作ること自体に懸念がある方はSaaSus Platformをぜひ検討してみてください。私がそうだったように、SaaS開発を行っていく上での有用な選択肢の一つになりうるので、ぜひまずは一度触ってみてほしいです。 SaaSの土地勘を身につけるための地図でありガイド、それがSaaSus Platformではないかと思います。 ーありがとうございました！ E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 --- ## 【導入事例】三菱電機株式会社FAシステム事業本部（10 Days SaaSification for AWS） URL: https://saasus.io/blog/melco-mailabo Date: 2024-06-17 重電システム、産業メカトロニクス、情報通信システム、電子デバイス、家庭電器など多岐にわたる製造や販売を行う三菱電機株式会社。 今回は、同社FAシステム事業本部の岩田さんと中野さんにお話を伺いました。 10 Daysをきっかけに一歩踏み出した ーまずは事業内容や、今回10 Daysに取り組んだプロダクトについて教えてください。 岩田さん： 当社FAシステム事業本部は、主に製造業のお客様に対して生産設備の自動化、つまりファクトリー・オートメーションの機器やソリューションを提供しています。その中で私たちが所属するDX推進プロジェクトグループでは、ソフトウェア技術を用いて工場をスマート化するデジタルマニュファクチャリングを推進しています。私たちは、データ分析やデータの活用に関する領域を担当しており、お客様へのソリューション提案やソフトウェア開発に従事しています。 今回、10 DaysでPoCを行った『MELSOFT MaiLab』も、AIを活用して製造業のお客様の生産現場の改善を支援するプロダクトです。既存ビジネスであるFA機器に加えて、ソフトウェア技術を活用したSaaSという新しい形態のビジネスの可能性を模索するために参加させていただきました。 FAの分野においても、近年ではソフトウェア技術の重要性が国内外問わず高まっており、ソフトウェアをいかに活用していくかという課題は避けては通れません。実際にお客様に接する中でもそういったソフトウェアへの関心と期待が広がっていると感じます。 当社FA事業で扱ってきたのは主に生産設備の制御機器や加工機などのハードウェアになりますが、それらの根幹にはソフトウェアの技術があります。従来、制御のために使用していたソフトウェア技術をAIやデータ分析といった新たな領域で活用し、FA分野におけるソフトウェアの在り方を再定義するということが必要なのではないかと考えています。 中野さん： もちろん、お客様が明確にハードウェアやソフトウェアを分けて考えることはほとんどありません。生産現場からデータを収集し、いわゆる見える化することが一般的になってきて、生産現場データを活用する可能性が見えてきたというのが現在のフェーズだと考えています。データが収集できたら、次にそれを活用したいというニーズが生じるのは当然です。しかし、データ活用には専門的な知識が必要な場合があるため、データを収集できたからといって、それを活用できるかはまた別の話です。生産現場データを活用すれば色んなことができるという漠然としたイメージ・期待が先行している反面、それが必ずしも容易ではないというギャップが生じています。 そういった背景もあり、『MELSOFT MaiLab』は生産現場データの分析と活用を誰でも簡単にできるようにするというコンセプトを重視しています。お客様に直接ヒアリングして課題を探ってプロダクトに反映し、コンセプトを実現できるような製品作りが重要であると考えています。 ー10 Days実施に至った背景などお聞かせいただけますか？ 岩田さん： 元々、社内でもSaaSやクラウドへの関心が高まっており、その流れでAWSさんとの連携を強めていこうという話がありました。その活動の一環として、 AWSを活用し、現状もオンプレミスで提供しているソフトウェアプロダクトのSaaS化について事業・技術の両面で検討を行い、SaaSビジネスの解像度を上げるために10 Daysをご紹介いただきました。 中野さん： それ以前にも『MELSOFT MaiLab』をお客様が保有するクラウド上に載せるというような話自体はありましたが、なかなか検討が進んでいない状況でした。SaaS化の話もありましたが、果たしてSaaSというビジネス形態が合っているのか？という疑問から議論が進んでいませんでした。漠然と検討を進めなければならないという意識はあるものの、動き出せていないというもどかしさを感じていました。 10 Daysを通じたSaaS化の検証プロジェクトのオファーをいただいて、足踏みをしていた現状から、最初の一歩を踏み出すために丁度良さそうだなと感じました。 ー10 Daysの実施に際して感じていた不安や期待などを教えてください 岩田さん： 10 Days以前から、SaaSやクラウド技術、AIや機械学習と言った新しい技術を活用して、新しい事業を企画・検討したいと考えていました。しかし、長年「形のあるハードウェアを売る」という事業に携わってきた私たちにとって、「ソフトウェア使用体験・サービスを売る」というSaaSビジネスはまさに未知の領域でした。技術や事業の知見がない状態で、10日間でSaaS化を検証するというスピード感についていくことができるのか？という不安がありました。 中野さん： どうやってSaaSにするのか？という疑問が解決できれば良いなと考えていました。仮想マシンに載せるくらいは自分たちでも行えると考えていたので、10 Daysを通じてSaaS化には他に何が必要なのか理解できるのではないか、と。社内でもSaaSやクラウドの話題は上がるものの、足踏み気味で進展がない中で実際にサービスとして動くものを見てみたら、それが大きな一歩になるのではないかと期待していました。 ー『MELSOFT MaiLab』のSaaS化についてはどのように考えていますか？ 中野さん： 世間的にもSaaSの話題性や機運が高まっているのは感じていましたが、それに流されるのではなく、『MELSOFT MaiLab』をSaaS化する場合、それによってお客様にどんな価値をもたらすのかが最も重要な観点だと考えていました。SaaSというものの解像度が低かったこともあり、SaaS化を検討する目的が曖昧で『MELSOFT MaiLab』にとって本当に必要なことなのか？という疑問が議論の枷になっていたのかもしれません。課題に対する打ち手としてのSaaS化という理解が進んでおらず、SaaS化することで強みがなくなるのではないかとすら考えていました。実際に、10 Daysを進めていく中で議論していくと、SaaS化をした場合でも強みを十分に発揮できることに気づいたので、具体的な検討や手を動かして検証することの重要性を改めて感じました。 岩田さん： SaaSは、サービスの追加や改善を繰り返しながらプロダクトを提供していくビジネスモデルなので、お客様の実体験から来る真の課題を汲み取り、改善策を提供することができます。SaaS化によって、お客様とより密接かつ双方向的な関係を築き、私たちの製品・提案の価値を継続的かつ迅速に向上させることができるのではないか、そのように私たち自身のプロダクトづくりを変革できるのはないかという可能性を感じています。 ー10 Days前後でSaaSについての印象に変化はありましたか？ 岩田さん： 元々、私は、SaaSというものはソフトウェアの置かれる場所・処理が実行される環境の違いでしかないと考えていました。オンプレミスのソフトウェアと本質的な違いはないと考えており、SaaS化をする必要性や意義については疑問を持っていました。 10 Daysを経て、SaaSはビジネスモデルを変革し拡大できる可能性を持つ手段だと考えられるようになりました。10 Daysでの議論を通じてSaaSへの解像度が上がったことで、「SaaSにすると何かよくなるかも」という漠然としたイメージだけで語り合うのではなく、事業の上でSaaSという仕組みをいかに利用するかという具体的な検討とアクションを伴った議論ができる下地ができたと思います。10 Daysによって、そうしたナレッジを得ることができたのは貴重な経験であったと思います。 中野さん： 私も、流されてとりあえずSaaS化するということに対しては懐疑的に感じていました。SaaS化という手段と目的がマッチしている必要があり、時代の潮流や一般論に流されてとりあえずSaaS化というのは本質的ではないと思います。 もちろん、SaaS化の取り組み自体に対して否定的な思いはありません。ただ、10 DaysのようなSaaS化プロセスの疑似体験をすることで、SaaSへの認識を改め、理解を深めて、その上で議論できる状態にしていく必要があると感じます。手応えを持ってない段階での議論は空を掴むようなもので、疑問や懸念が浮かび上がっても解決する術を持たず停滞してしまいます。実践的な経験によってSaaSの表層的な部分に囚われた議論から抜け出し、本質的な議論を展開することができるようになるのではないでしょうか。 ー10 Daysの感想をお聞かせください。 岩田さん： 10 Daysで『MELSOFT MaiLab』SaaS版のMVPが完成して、自分のスマホ上で『MELSOFT MaiLab』が動くのを見た時には感動しましたね。しかも、わずかな期間・工数でスピード感を持って実現できて驚きました。 中野さん： ビジネスに関するヒアリングでは私たちの考えや要望を上手く引き出してもらえた感覚はあります。おかげで、どういったものを作っていくか？というコアの部分を自分たちで具体化できましたし、そこに至るまでの考え方や方法論も学ぶことができました。 それを踏まえて、デモとして実際に動くものを実装していただき、実装内容や方法などを説明していただいたので理解が深まりました。ビジネスと実装の二段構えが充実していて良いプログラムだなと感じました。 また、10 Daysを通じてAWSのサービスやSaaSus Platformの存在を知ることができ、1人のエンジニアとして刺激を受けましたし、新しい技術や知識を使って色々なことができそうでワクワクしています。 10 Daysで1の壁を超えた ー10 Daysを終えて意識や考え方に変化はありましたか？ 岩田さん： 「あ、ほんとにできるんだな」と実感しましたね。AWSのサービス群やSaaSus Platformのように作るための機能やサービスは数多く世の中にあるので、実施前は理論上は可能なのかもしれないけど本当にSaaS化できるのか？という疑問を持っていました。それが実際にやってみたらできるんだという実感に変わりました。 実感を得る前は、例えばテレビの番組表を読んだだけで、番組を見た気になっているようなものだったかと思います。言葉で概要を知っているだけではなく、実際に目で見て触れて話し合うことでしか得られない理解の深さというものがあり、そうした深さがさらなる次の発想へ結びつく可能性が高いということを改めて感じました。同時に、この不確実・複雑な世相において、自分達の内部知識から来る想像だけで議論を完結させてしまうことの危うさも感じました。 中野さん： 私も似たようなことにはなりますが、やってみたらできるという実感を得られたというところが大きいですね。それはつまり、やってみないと分からないということも表しているなと感じています。やる前に議論だけしていても、本当に考えるべきポイントや課題が見つかるとは限りません。課題を見つけるためにもやってみるという意識は重要で、迷ったら動いてみるという感覚が身につきました。 例えるとすると、これまでの活動は数字で表すと0.8とか0.9とかのイメージで、1を超えない数字にどんな数字をかけても大きくなっていかないのと同じで、事業を推し進める上でも1の壁を超えるというのが重要だなと感じています。今回の取り組みにおいて、10 Daysを通じてSaaSやAWSについて議論するための下地をつくれたおかげで、1の壁を超えられたように感じています。まだまだ1.1くらいかもしれませんが、ここに議論やアイデアを掛け合わせていくことで、ビジネスとして大きく進んでいけるという手応えがあります。 もちろん、すぐに事業に還元されることではありませんが、将来を見据えて今、一歩目を踏み出せたというのは価値のあることだと思っています。目先の利益ではなく、長い目で見た価値や効果を私たち以外のメンバーに伝えていきたいです。そうした活動を説得力を持って行っていくために、実際に動くものを見せるというのは重要です。私たち自身、頭の中のものが目の前に現れた時の衝撃や感動を味わっているので、それは強く思いますね。 『MELSOFT MaiLab』SaaSで視野を広げていく ー今後の『MELSOFT MaiLab』や貴社の展望について教えてください 岩田さん： 今後は、SaaSやクラウドに関する知識・知見だけでなく、10 Daysのような実践的なビジネス検討の進め方・考え方の重要性や、「まずはやってみる」というマインドを啓蒙し、自部署内や社内に還元するということをしっかりと行っていきたいです。FA分野におけるSaaSやクラウド、ソフトウェアに関してはこれからより深く検討や議論を進め、道の無い所を開拓していく領域だと考えています。私たちがガムシャラに獣道を切り開いて、議論の深化や活性化を促していきたいです。私たちだけでなくFA制御機器やロボットに携わるメンバーも含めて、当社全体で中野さんの言うように0.9の繰り返しから1の壁を突破していけたら良いなと考えています。 すぐに大規模サービスを展開するという訳ではなく、次のステップとして『MELSOFT MaiLab』SaaS版 MVPを実際にお客様に体験していただくテストマーケティングを行いたいと考えています。それにより、ユーザ循環型のプロダクトづくりへのシフトを進めて行くとともに、組織として徐々にSaaSの運用経験を蓄積していくのが必要だと考えています。それと並行して『MELSOFT MaiLab』とFA機器など他のプロダクトを統合したSaaSビジネスの可能性についても検討を進めたいですね。『MELSOFT MaiLab』SaaS版 MVPを運用して知識や経験・お客様の声を得て、そこで生まれた新たな仮説や課題を再び『MELSOFT MaiLab』SaaS版 MVPによって検証していく、そうした循環をつくっていきたいです。 『MELSOFT MaiLab』SaaS版 MVPは、私たちがお客様と繋がり、お客様の本当の悩みや困りごとを汲み取るための手段になり得ると考えています。市場や顧客の真のニーズ・ペインをキャッチする「ビジネスの触角」として、得られた情報を上手く活用しながら、『MELSOFT MaiLab』だけでなく他のプロダクト、ソリューションも含めて事業を発展させられたらと考えています。 中野さん： 10 Days内でも今のシステム構造と将来の在り方について議論したこともありましたが、『MELSOFT MaiLab』SaaSという在り方に固執せずに、他のソフトウェアとの垣根を崩していきながら、会社としてFAソリューションをどうしていくのか考えていきたいですね。データ分析の実際のデータやノウハウを社内で一元管理するような動きも始まっていて、社内に蓄積されている情報をアプリケーションやサービスに落とし込むために、何をどうすべきなのか？というところを『MELSOFT MaiLab』MVPを使って模索していけたらと考えています。 もちろんデータやシステムのみに依存するのではなく、これからもお客様を直接尋ねてコミュニケーションをしていきたいと考えています。現場とシステム、どちらかだけでは不十分で、両方をしっかりと考えながら進めていきたいと思います。 ー最後に導入検討者に向けて一言をお願いします 岩田さん： 「やってみりゃいいじゃん」という言葉を伝えたいです。 これは、私が以前上司に言われてよく覚えている言葉なのですが、今回の10 Daysでも「やってみる」「体験する」ということの重要さ・強さを改めて感じました。 誰でもやったことがないことには不安を抱きます。ですが、0.9で滞って迷っている時に、必要なのは＋0.1を踏み出す勇気だけです。勇気じゃなくても、気合、パッション、覚悟、エイヤア、好奇心、なんでもいいですけど。＋0.1さえ踏み出してみれば、応援してくれる人や後に続く人はきっと現れます。 実際に体験して得られる感覚や知識が10 Daysにはあります。「やってみりゃいいじゃん」精神で、ぜひ体験して欲しいですし、体験させてあげて欲しいですね。 中野さん： 初めの一歩を踏み出すと、それにつられて後ろの足もついてきますよね。人は意外と、歩き始めれば歩き続けられるものなのだと思います。大事なのは一歩目を踏み出せるかではないでしょうか？SaaS化という文脈において、10 Daysは初めの一歩のための背中を押してくれる、あるいは手を引いてくれるような取り組みです。 物理的な制約が少ないのがSaaSで、そのメリットやスピード感を体感できるのが10 Daysです。その場で足踏みするよりも、初めの一歩を踏み出してみてはいかがでしょうか？ ーありがとうございました！ --- ## 【導入事例】ニッセイ情報テクノロジー株式会社共済保険ソリューション事業部（10 Days SaaSification for AWS） URL: https://saasus.io/blog/nissay-it Date: 2024-05-09 保険や共済を中心とした様々なITソリューションの提供を行うニッセイ情報テクノロジー株式会社。10 Days SaaSification for AWSを通じて、従来製品のクラウド化に取り組みました。 インタビューにご協力いただいたのは、同社共済保険ソリューション事業部の堀内さんと須田さんです。 SIからSaaSという未知の領域へ －まず初めに貴社の事業内容やプロダクトについて教えてください。 堀内さん： 弊社の事業内容としては保険・共済、年金、ヘルスケア領域を中心とするシステムの提供をメインに行なっています。私が所属している共済保険ソリューション事業部では共済団体様に対して、共済業務をサポートするためのシステムの開発やサービスの提供を行なっています。私は共済団体様の福利厚生、共済契約管理業務をサポートする製品である『Tomte』(トムテ)の開発に携わっております。現在は従来オンプレまたは自社のプライベートクラウド環境を基本として提供してきた『Tomte(*1)』の次期バージョンの検討を主導しています。 (*1) 共済向け　福利厚生支援システム『Tomte』(トムテ) 「Tomte/福利厚生支援」は、福利厚生事業を運営する共済団体向けに、本部および会員企業（団体）の事務をペーパーレスで実現するシステムをクラウド形式で提供するサービス。 須田さん： 当事業部で構築している共済団体様のシステムの運用管理及びインフラの開発を担当しています。また、全社でのクラウド推進を行うCCoE室の窓口も兼務しています。 弊社は日本生命グループ内だけでなく、グループ外のお客様向けのシステム開発も行なっており、グループ内外ともにクラウドでの開発の裾野を広げる意味でも各事業部に対してクラウドの理解と利用の浸透を推進する役割を担っています。 －次期『Tomte』に関しては最初からSaaSとして開発する想定でしたか？ 堀内さん： 既存のASPの形からクラウドで管理する領域を広げていくという程度の想定だったので、SaaS化ということは意識していませんでした。従来の製品を元に、より多くのお客様にご利用いただくために、どうしていくべきか？というところの検討から始まったので、今回、10 Daysの提案をいただいて初めて、SaaSという選択肢が見えた気がしています。 当初、SaaSに関する知識が少なく、オンプレをベースとした従来の方式でも十分な認識でしたが、10 Daysの説明を聞いているうちにSaaS化していくべきだという考えが強まりました。 須田さん： 私自身はASPに関しては20年以上前から知ってはいましたが、漠然と大規模なシステムのイメージがありました。10 Daysを通じてSaaSへの理解が深まると、SaaSではクラウドを活用したリソースの有効活用によって、スモールスタートで進めることができることに気付き、想定していたよりも敷居が低いように感じました。 10 DaysはSaaSのビジネス的な観点、クラウドアーキテクチャ、テナントモデルに関する理解や知見を深めるきっかけになったと思います。 －社内でSaaSやクラウドの有識者などはいたのでしょうか？ 堀内さん： 他の事業部ではAWSを使っているところもありますが、私達の事業部ではAWSをはじめとするパブリッククラウドサービスを活用した製品が無いので、SaaSやクラウドについて深く理解している人はいませんでした。会社としては、社員のクラウド技術者を増やしていくための取り組みを積極的に行っているのですが、当事業部としては、現状、パブリッククラウドを利用した具体的なシステム開発、サービスがほとんどないことから、実業務としてクラウドに取り組む機会が乏しいのが実情でした。 私達の事業部はSI開発が主体で、なかなかクラウドに接する機会がありませんでしたが、SaaS化を見据えた時に、実際に使っていくために考えるべきことがたくさんあり、これまで少し遠い世界の話のように感じていたクラウドが身近に感じて、自分ごととしてクラウドと向き合えている実感があります。これから事業部内でクラウドを先導していく立場になるのでとてもワクワクしています。 須田さん： 私も、特にSaaSやクラウドへの関心や意識が強くなっています。また、SaaS化を突き詰めて考えていくと、共済保険SaaSの需要の秘められたポテンシャルを感じていて、事業部の柱にしていく上でもSaaSという在り方に可能性を感じています。SaaS未開拓の業界や業種に展開することで、SaaSそのものを活性化させられるという点で、社会的な意義も感じています。 －AWSについてどのようなイメージを持たれていましたか？ 堀内さん： AWSに初めて触れたのは、3年ほど前の社内の研修でした。受講予定だった人が参加できなくなり代打で受講した形だったので、そこで得る知識やスキルを業務で利用するイメージが持てず、その当時担当している業務での必要性を感じられませんでした。AWSについて学ぶことに対しての積極的な動機はありませんでしたね。 事業の特性上、個人情報を多く取り扱うので、当時はお客様としてもパブリッククラウドへの抵抗感があったように感じます。近年では世の中的にパブリッククラウド利用の機運が高まって、それに伴って抵抗感も薄れているように感じます。 これまではパブリッククラウドの利用に対する無意識の抵抗感や不安があったのかもしれません。ただ、現在においては、クラウドのメリットを生かして価値提供していく可能性を模索し、それを実現していくことができなければ、淘汰されるリスクが高まっています。クラウドを積極的に利用していくことが重要になってきているように感じ、私達も向き合う時が到来したのだと考えています。 須田さん： AWSはやはり汎用性が高いなと感じています。また、 AWS Black BeltやAWS Skill BuilderなどクラウドやAWSのサービスに関する教材が充実していて学びやすく、疑問を解決するための手段が豊富で、知識がないところからでも学習を進められる点は魅力的でした。 パブリッククラウドへの挑戦 －10 Days実施を決断した経緯についてお聞かせください 堀内さん： 従来のプロダクトは自社のプライベートクラウドを使用しているので、AWSなどのパブリッククラウドに比べてコストが高く、それによってお客様の費用もかさんでしまうという課題がありました。パブリッククラウドに乗り換えることで、安く済むのではないかという漠然とした想定はありましたが、実際にどの程度インパクトがあるのか分からなかったり、移行するための手段についても、不鮮明で二の足を踏んでいたところに、須田さんから10 Daysの紹介を受けて、すぐにでも始めたいと考えていました。知識や経験が不足していて、何から手をつけるべきかも分からない中で、10 DaysをきっかけとしてSaaS化に取り組んだことで道筋が見えてきたように感じます。 須田さん： 私はAWSさんからのご紹介で10 Daysを知りました。当時、CCoE室の担当として堀内さんと打ち合わせをしている時に、どこから手をつけるべきかと困っていたことを知っていたので、資料を見て、これだと思い堀内さんに提案しました。その時点ではSaaS化の想定はありませんでしたが、国内のSaaSがまだまだ未発展だということや、社内でのSaaSの利用が進んできている背景から、SaaSの将来性に可能性を感じ、その足がかりとして10 Daysは適していると思いました。 －10 Days推進時の様子についてお聞かせください。 堀内さん： SaaSの立ち上げを体験するという、貴重な機会ということもあり多くのメンバーが参加しました。開発を委託している協力会社のメンバーにもAWSについて知見を得て欲しいと思ったので、声をかけたら積極的に参加してくれました。新しい経験や知識を身につける機会ということで、開発メンバーのモチベーションのアップにも繋がったと感じています。 須田さん： 私自身もクラウド案件は未経験だったので、従来の開発に慣れて凝り固まっている知見をほぐす機会になりました。正直なところ、SaaSというものが未知数だったので、10日間でSaaS？という不安もありましたが、AWSとSaaSus Platformを活用して、実際に動くものを見せてもらうと、これらを活用すれば早く仕上がるというイメージが沸いてきました。そのスピード感を体感したおかげで、よりクラウドファーストへの意識が高まったように感じます。 クラウド推進の立場になったので、AWSの認定資格を取得しましたが、それだけでは十分でなく実践の必要性を感じました。貴社のソリューションアーキテクト(SA)の方が実際に作ったものを見て、感動しました。実際の成果物を見せてもらったり、それを真似るというのはとても勉強になりますね。 －10 Daysのコンテンツで印象的だったものはありますか？ 堀内さん： AWSのサービスを使ってシステムをいかにして構築するか？というところが全くピンときていなかったので、貴社SAの方が実際に作ってくれたお手本を見せてもらえたことですかね。それらを通じて、私達も実際に動くものを作れるところまでいけたので、サービスの組み合わせ方や開発の進め方、考え方の理解が深まりました。作ろうとしているサービスの要件や課題をヒアリングしていただき、それを踏まえたサービス選定もお手伝いいただけてありがたかったです。 10 Daysは合計80時間の確保が必要だったので、その時間を捻出するのは大変でしたが、10日間短期集中ではなく、空き時間を柔軟に活用しながら進めることができてよかったです。個人的な体感としては毎週1日ずつ進めるのがちょうど良いかなと思いました。 須田さん： 設計図を見せてもらうと、サービスの部分だけでなく、監視やデプロイの仕組みなどの部分も考慮されていて、短期間で素早くリリースし、継続的なデリバリーを実現することについて考えられていました。クラウドを利用することで、人に依存せずに運用ができることをデモンストレーションを通じて視覚的に理解できました。実際に動くものを見るのと、概念だけ理解するのとはだいぶ違うなと感じました。SIの業務に慣れていたので、とても新鮮でしたね。 SaaS開発を体感することで視界がクリアに －10 Daysを実施してみて、感じる効果などはありますか？ 堀内さん： 今後の方向性や課題、それを実現する具体的な方法などがクリアになりました。 AWSに移行する時はIaaS的なイメージで単なるコスト削減の手段という認識でしたが、10 Daysで学んだことを踏まえるとそれはクラウドのメリットのほんの一部分でしかないと気付きました。クラウドのメリットを生かすために、より積極的にクラウドサービスを利用していくべきという考えに変わっていきつつあります。それにより、アプリケーションの部分に集中していくことが重要だと感じています。 クラウド上でサービスを作ることで、他のサービスと連携を見据えた開発に変わっていくと思うので、自社内で完結するSI開発の考え方からは変えていく必要があると気付きました。 また、従来の製品では顧客ごとのカスタマイズを前提としていましたが、SaaSでは統一のサービスを画一的に提供していくことが主流になるので、顧客ターゲットや幅広いニーズを満たすためのプロダクトの方向性や在り方について考えていく必要があるなと強く感じました。プロダクトマネジャーを立てて、この辺りの思考に力を入れていくべきだと考えており、体制の変更も視野に入れています。 須田さん： 最近ではプロダクトマネジメントに関する情報がたくさんあり、世間の潮流としてその重要性が高まっているように感じます。SI的な開発ではなく、自分たちでニーズを見極め、それに対応したサービスを提供していく必要があります。私達はSI主体として活動してきた組織なので、10 Daysで得たSaaS化やクラウド化についての知見や認識を事業部に還元して理解を深めていけたらと考えています。 堀内さん： 10 Daysに参加したメンバー内では意識改革が起こっており、これを事業部全体に広げていきたいと考えています。次期『Tomte』を成功させることで、説得力を持って訴えていけるようになると思うので、プロダクトを成功させてより広い範囲での組織や個人のマインドチェンジに繋げていきたいですね。私達の活動によって、変わるきっかけを与えていけたらと思います。 須田さん： 実際に、参加したメンバーの間ではAWSの知識への意識向上を感じます。資格取得に動き出しているメンバーもいますね。 私自身も、資格を取得しましたが、積極的に情報収集するというところまではできていませんでした。10 Daysをきっかけに、 AWS Black BeltやAWS Skill Builderを見て、能動的にSaaSのアーキテクチャやビジネスに関する知見を得るようになりました。SaaSの理解度が上がったことで、視野が広がり、日常的なキャッチアップへの意識が変わったように感じます。 －では、実際に触れてみてAWSのメリットは何だと感じましたか？ 堀内さん： これまでの開発との違いで感じるのは、インフラ周りの煩雑さがなくなるので、すぐに開発に移れるという点ですね。AWSを利用することで、より早く安くお客様に提供できる様になります。また、開発に着手するハードルが下がったことで、実験的な試みもしやすくなり失敗した時のリスクを抑えられるのは大きなメリットだと感じています。 須田さん： 試行錯誤ができることで提供できる価値の向上とスピードアップにも繋がりますね。ハードウェアなど物理的な物を購入するとなると、それらを無駄なく活用できる見込みがないとそもそも動き出せなかったりもします。コスト面での無駄がなくなることで、費用対効果の検証にシビアにならなくてもよくなるので、それによって意思決定のスピードも上がるという効果もありますよね。 －SaaSus Platformのメリットは何だと思いますか？ 堀内さん： 私達としては共済のためのシステムに集中したいので、いわゆるコントロールプレーンのようなSaaS共通部分に手間をかけたくないというのが本音です。そもそもSaaS共通部分に関しても、どういった検討が必要なのかなど勘所がないので、それらを自前で用意するとなるとかなりのリソースが必要になると思います。そういった部分をSaaSus Platformを使うことで、手離れできるのはありがたいですね。 須田さん： AWSにも当然、認証サービスはありますが、使える形にするには手間がかかります。それを使える状態にして提供できるのはSaaSの知見や技術によるところだと思います。 個人的にはSaaS for SaaS(SaaS Control Plane as a Service)というコンセプトも素晴らしいなと感じています。 サービスを成功させて事業をリードする －事業の今後について教えてください 堀内さん： 直近では、次期『Tomte』を具体的に製品化していくために活動します。事業部としても『Tomte』だけでなく、他の製品もクラウド上で提供できるように、組織全体がSaaSやクラウドの知見を高められるようにスキルアップしていきたいと考えています。それによってお客様にさらなる価値を提供していきたいですね。 『Tomte』をまずは成功させるというのが現時点での目標ですが、それにとどまらず、経験を他のサービスに生かすというところまで念頭に置きながら進めていきたいです。 須田さん： 私はインフラ周りの仕事に携わってきたので、今後、それらの発展を見据えて知識の研鑽を行っていきたいですね。ビジネスサイドでは『Tomte』以外の隠れた需要を掘り起こせるように、アンテナを張っていきたいです。今以上にSaaSやクラウドの知見を身につけることでアイデアにも繋がると考えているので、積極的にキャッチアップしていきたいです。 －最後に10 Days推進検討者に一言をお願いします 堀内さん： 貴社SAの方を含め、SaaS化への多大な支援に感謝しています。とても素晴らしい取り組みなので、興味があればぜひチャレンジして欲しいです。SaaSをまだまだ知らない人が最初に取り組むには最適なプログラムです。 須田さん： 教科書的なSaaS開発として、これからSaaSに取り組むために必要な知識や考え方を一通り学ぶことができます。挑戦を迷っているのなら、チャレンジして損はないと思います。 －ありがとうございました！ --- ## 【導入事例】富士通Japan株式会社EDIソリューション事業部（10 Days SaaSification for AWS） URL: https://saasus.io/blog/fjj Date: 2024-04-12 本日は富士通Japan株式会社EDIソリューション事業部におけるSaaS化のご支援として行った10 Days SaaSificationについて、事業部のシニアディレクターの大関様、ビジネス担当の蓮様、開発担当の牛込様にお話しを伺いました。 SaaS化は必然の流れだった ーまずはEDIソリューション事業部での事業内容について教えてください。 大関さん： EDIソリューション事業部はその名の通り、EDIサービスとその周辺サービスを取り扱っており、主に6つのプロダクトを手がけています。今回、10 Days SaaSification for AWSでSaaS化に取り組んだのは『EDILiNK』というEDIソリューションです。 ーEDiLINKについて簡単に教えてください。 蓮さん： EDIは簡単に説明すると電子データをやり取りするものなのですが、EDiLINKの特長はWeb-EDIとファイルEDIを組み合わせて利用できる点ですね。プロダクトの特性上、特定の顧客層というよりも様々な業種・業界でご利用いただいています。あらゆる業種・業界でご利用いただけるので、多様なニーズや要望にお応えできるようにプロダクト作りを行っています。 具体的なご利用シーンとしては受発注業務や購買業務において、Webやファイルを使ったEDIの取引で使われることが多いですね。 ーSaaS化に至った経緯など教えてください 牛込さん： まず、ここ数年でSaaSという言葉が広く浸透しつつあり、それに伴って世の中全体でSaaS化の機運が高まったように感じています。社内でもSaaSビジネスの推進という意識の高まりがあり、事業部全体でSaaS化に取り組もうとなった経緯があります。 蓮さん； 弊社は株式会社富士通マーケティングと富士通エフ・アイ・ピー株式会社の統合後、富士通株式会社のエンジニアが合流しているという発足時の背景があります。我々の事業部の母体となった組織が特にサービス化を推進していたということもあり、かなりの熱量がありました。そのため、社内でも特にSasS化への意識は高いのではないでしょうか。 大関さん： 元々EDIに携わっていた組織は30年ほど前からVANセンターというデータの預かりサービスに携わっていて、それが時代とともに、よりオープンなサービスへと移り変わっていきました。EDIはそういった流れを汲んでいるものなので、大きな歴史の流れの中でSaaS化というのは必然的なものなのではないかと考えています。 ー組織的な背景と歴史的な背景によるものが、昨今のSaaS化の潮流に後押しされたということですね。 ー10 Daysの活動の中で、特に顧客への価値提供の部分にフォーカスしている印象を受けましたが、何か特別な思いがあったのでしょうか？ 大関さん： EDIは他社との差別化が難しいと考えています。他社製品と比較して自社製品にどういった魅力や利点があるのかということを伝えていくことがとても難しいです。お客様が競合とEDiLINKを比較する際に、利点や将来性を評価していただくには、EDiLINK単独での価値提供には拘らず、社内の他のサービスとの連携での価値提供を行い、総合力で勝負していきたいと考えます。弊社は多様なプロダクトやサービスを取り扱っていますので、それらを組み合わせることで相乗効果をもたらすことができたら面白いなと考えています。 ーSaaSビジネスについてはどのようなイメージを抱いていましたか？ 蓮さん： 直感的な話にはなりますが、サービスの構築やマーケティング、セールスなどの導入の壁を超えたら、マネタイズが容易という印象がありました。実態として違うことにはすぐに気がつきましたが… ーSaaS化に際してSaaS有識者はいましたか？ 牛込さん： 自部門にSaaSに精通した、有識者はいませんでした。そのため文字通り手探りの状態で始まりました。当時はSaaSという言葉を聞くようになり始めたくらいの時期で、社内でもSaaSを取り扱っておりませんでしたし、SaaSとASPとの違いもよくわからないような状態でSaaSに関する知識や経験の面が十分に備わっている状態ではありませんでした。 ーSaaS化を推し進める上で組織体制などについてのお考えは現時点でありますか？ 蓮さん： SaaS化を進めるにあたって、体制変更の必要性を強く感じています。 SaaS化を進める前から従来のインフラ基盤のあり方については議論をしていて、バラバラの基盤を統一する必要性は私も大関も感じていました。 それらを統一するためにはまず、事業部内の体制をクリアにする必要があります。 大関さん： 現在は製品ごとの縦割りで動くことが多いですが、今後は製品の枠に囚われることなく、事業部全体で横軸（ファンクション軸）でタスクを分担したり、能力やスキルに合わせた業務に事業部内でアサインしていくのがよいと考えています。そうすることで、基盤だけでなくこれまで製品ごとに独自に取り扱っていた部分をなくし、事業部内で足並みをより揃えられると考えています。 横軸として見た時に開発や運用のリーダーとして牛込を、セールスやビジネスのリーダーとして蓮をまずはAWS様とのPOCにアサインしました。 ーAWSについてはどのようなイメージをお持ちでしたか？ 蓮さん： 機能やサービスが多いだけでなく、データセンターのキャパシティ、設備が良さそうな印象があったので、クラウド選定についてはAWSを利用するのが間違いないだろうと考えました。知名度もシェアも高く実績も多いので顧客からの心象も良いのではとも思いました。SLAが公開されていることも安心感に繋がると考えました。 自社で提供しているプロダクトが多いので、どうしても自社のプロダクトを使いたくなりますが、自社の強みとAWSの強みは異なりますし、視野を広く持って状況に合わせたサービス、プロダクトを使っていくことも大事で、価値を提供していくためには外部のサービスやプロダクトを上手く活用することも必要だなと考えています。 課題と現在地を理解する重要性 ー10 Days推進以前の様子や課題についてお聞かせください。 蓮さん： 現状、運用負荷が高いという課題を抱えていたので、AWSを活用し、運用や監視のレベルを向上させたいと考えていました。また、アーキテクチャの整理もしたいと考えていて、それに伴ってサービスレベルについても検討したいというタイミングで今回の10 Daysの機会をいただきました。 牛込さん： 最初はAWSにおけるアプリケーションのデプロイの組み込みや費用対効果を検討したいという考えでした。アプリケーションの作り方やインフラアーキテクチャなどによる運用の複雑化という課題を効率化して、スケールさせていくためにAWSを活用してどのような改善策があるのかを模索したいという背景がありました。 ー10 Days実施を検討する上で懸念などはありましたか？ 蓮さん： 当初は10 Days全てに参加するのは難しいのではと率直に思いました。10日間に渡ってこのプロジェクトに参加するために、普段の業務から離れられるのか？というこちら側のリソースの懸念ですね。実際には10日間通して実施するという形ではなく、10人日のタスクを無理なくこなせるスケジュールで調整し、進めることができたので安心しました。他の業務との折り合いもつけやすく、スムーズに進められたと思います。 コンテンツとして印象的だったのは「AWS SaaS Journey Framework」（※AWSの提供するSaaS ソリューションの最適化のためのガイダンス）の振り返りです。振り返りによって、自分たちが今現在いる位置を再確認できましたし、それによってやるべきことを考えさせられました。網羅的な見直しと共通認識を取るために非常に効果的な時間だったと思います。 時期的にはインボイス対応などもあり、業務調整が大変な時期もありましたが、お手伝いいただいたおかげで、想像していたよりもかなりスムーズに進んだと思います。 牛込さん： 10 Daysという名称の通り10日で本当に終わるのか？というのは私も最初に思いました。SaaS化への道のりが曖昧だったこともありますし、業務負荷的なところも懸念でした。 やってみた感想としては、10 DaysのコンテンツはSaaS化へのプロセスが体系化されていたので、必要なことや考えるべきことを順序立てて整理しながら進めることができました。自分たちの気づきや考え方の整理がしやすかった印象です。 10 Days推進効果 ー今後目指すべき方向性や課題や具体的な方法などがクリアになりましたか？ 牛込さん： 今回のプロジェクトではSaaS化を進めていくために考えるべき観点を知識として得られたと考えています。運用に関しては自動化が必要な意識はありましたが、具体的に何をするのか、どうするのかというところは漠然としていました。実際に自動化して動くのを見せていただいたことで効果を実感し、その重要性についてしっかりと理解できました。 10 Daysに挑戦したことで課題が明らかになり、その課題を解決することによる効果が明確になりました。AWSの知識が少なかった中で、10 Daysを通じてAWSのサービスの具体的な機能などが分かり、とても参考になりました。 ー10 Daysを通して社内で何か変化したことはありますか？ 牛込さん： 将来的に、既存環境をAWSに移行することで中長期的にコストメリットを享受できる可能性が見えたので、AWSの利用推進への動機がさらに明確になって、より動きやすくなったように感じます。 ー他にAWSのメリットは見つかりましたか？ 蓮さん： やはり信頼性は大きなメリットだと感じましたし、自動拡張などによって拡張性が担保される点や監視などの機能も豊富で、必要な機能、部品が揃っているという印象です。標準で欲しい機能が備わっているので、別のサービスを契約して導入などの必要が少なく、その点でもスケールメリットを感じました。 もちろん、移行時や慣れるまでは大変だと思いますが、そこを乗り越えたらコスト面での大きな改善が期待できます。 ーSaaSus Platformのメリットはどのように感じましたか？ 牛込さん： 認証認可の統一ができるというところはEDiLINKだけでなく他のソリューションにも活用できるのではないかと感じました。多要素認証があらかじめ使えるというのも、かなり手間がかかる部分ではあるのでそこが簡略化されるのは大きなメリットだと思います。 料金請求のところに関しては全自動化が理想ですが、社内で調整が必要な部分ではあるので、近々でメリットを享受できるかは分かりませんが、ID課金やデータ量の監視による課金フローが実現できれば請求フローの簡素化に繋がるのではないでしょうか。 サービス連携することで、開発しなくてもビジネスの選択肢を増やせるというのは、開発コスト面だけでなく、品質面でもメリットがあると考えています。今後は、より深い知見や高いスキルを持つ専門サービスを活用するという選択も積極的にしていきたいと考えています。 SaaSは契約が増えていくにつれて煩雑化するので、そういった局面に対して人力で望むのではなく、統合管理して自動化していく必要を強く感じました。なるべく人が関与するところを減らして、統合と自動化を行わないとSaaSビジネスは回らないと感じています。 SaaSを契機に組織の改革を ー事業の今後の展望について教えてください。 牛込さん： まずは、動き始めているEDiLINKを着実に進めていくことが第一かなと思います。そのためにもAWSに強い人材の確保などに動き始めています。AWSをはじめとする有用な外部サービスを活用しながら運用とアーキテクチャの効率化を図っていきたいと考えています。 組織改革に伴って私自身もEDiLINK以外のソリューションに参画したり、動き方が変わっていくのではないでしょうか。 大関さん： EDiLINK以外のソリューションもあるので、将来的には効率化のために基盤を共通化してAWSへの集約を検討しています。それを見据えて、体制構築やリソースの確保など組織の改革を進めています。 ー最後に10 Days推進検討者に何か一言いただけますでしょうか 大関さん： まず、10 Daysという言葉が衝撃的で興味を持ちました。プロダクトやサービスを広めていく上でインパクトやイメージというのは我々も大切にしているところなのでそういった点でとても気合いが入ったプロジェクトなのだなと感じました。我々のソリューションは社内で完結することが多い中でAWSという新しいサービスを利用していくことはチャレンジでもありましたが、10 Daysを通じて様々なことを教えていただき、外部サービスへと目を向けることの重要性に気づくきっかけにもなりました。 牛込さん： 10 Days SaaSificationをやって良かった1番のポイントはプロジェクトを通じて考え方やマインドを整理し、変えることができる点です。 SaaS化推進のために、SaaS化のために必要なことは何なのか、漠然としていたことがクリアになりました。SaaS移行時の観点だけでなく、運用やSaaSとしてのあり方、コストやビジネス、アーキテクチャなど様々な観点での考え方が身につくだけでなく、自分たちの状況を理解することで、より効率的に進めることができるという気づきに繋がったと感じています。 ー本日はありがとうございました！ --- ## 【導入事例】『セールススイート』グロービング株式会社 URL: https://saasus.io/blog/globe-ing Date: 2024-03-27 ベータ版開発でSaaSus Platformを利用し、速やかなプロダクト検証を実現！ 戦略コンサルティングファームとして、質の高いコンサルティングサービスを提供しているグロービング株式会社。新しいサービスとしてコンサルティングのなかで得た様々なナレッジのクラウドプロダクト化に取り組んでいます。 今回はクラウドプロダクトのベータ版としてSaaSus Platformを利用した背景や所感についてお話しいただきました。 インタビューにご協力いただいたのは上級Manager/CTOの上田慶祐さんです コンサルティングの高度なナレッジをプロダクトへ ーまずはじめに、貴社の事業と上田さんの業務内容について教えてください 上田さん： グロービングは経営コンサルティングを主軸事業として行っています。代表を始め、大手の総合コンサルティングファーム出身のメンバーを中心に事業を行っています。コンサルティングチームは現在、150人ほどが在籍しています。他にも経営者向けにEAS（エグゼクティブアドバイザリサービス）と呼んでいる、企業の役員クラスを実際に務めた人間の経験や知識を元に行うグレイヘアコンサルティングも行っております。 それらと並行してクラウドプロダクトの開発を事業として行っており、私はその事業内で上級Manager/CTOとして、エンジニアリングを主導しています。 ーありがとうございます。貴社のクラウド事業について教えてください。 上田さん： まずは、弊社の『オクタゴン』と称するクラウドプロダクト群のコンセプトについてご説明させていただければと思います。 オクタゴンは我々がコンサルティングを行っていく中で、業務の中で共通化されている部分をSaaS化するというコンセプトになります。コンサル業務の中で再利用可能な要素をプロダクトとして提供することで、コストの削減や工数の削減を行い、人間がより価値を生むことができる領域に注力できるようになることを目標にしています。コンサルのインダストリアライズとして、コンサル経験者の経験やナレッジをサービスに落とし込むことで価値を提供していけたらと考えています。 特に大手のコンサルティング報酬は大企業でないと手が出せない金額であることも多く、中小企業にとっては縁遠い存在になってしまっているかと思います。SaaSとして提供することで、中小企業にもグローバルファームのナレッジを比較的安価に提供することができれば、国内の企業の力を底上げすることに繋がるのではないでしょうか。 ークラウドプロダクトの構想はいつ頃からあったのでしょうか？ 上田さん： 構想自体は設立当初からありましたが、実際に立ち上がり始めたのは2023年ごろからですね。その前から少しずつ構想を練ってはいました。私自身もプロダクトを作るタイミングでコンサルとエンジニア両方の知見を生かしてプロダクトの企画などを行うポジションでジョインしましたが、エンジニアチームの体制変更に伴ってテックリードを務めるようになりました。 ーありがとうございます。現在は、SaaSus Platformをどのようなプロダクトで利用しているのでしょうか？ 上田さん： 現在は『セールススイート』というプロダクトの開発にSaaSus Platformを利用しています。 セールススイートはコンサルティングの中でも営業分野に特化したプロダクトです。 元々、大手事業会社をキャリアに持つメンバーがPMとしてジョインしたという背景があります。経験と実績に基づいたノウハウをサービス化するという観点で考えると、主軸になるメンバーが明るい領域から着手するのが良いと考えました。プロダクトによって提供する価値に対して、既に経験と実績を積んだメンバーがいることで、事業検証がある程度進んだ時点から構想を開始できるというメリットもありました。 セールススイートでは「営業の生産性を劇的に向上させる」というのが大きな目標です。 例えば、顧客の属性を新規と既存で分けた時に、新規の営業の方がハードルが高いというのは想像に難くないと思います。新規顧客をいきなり増やすことは困難なので、そうではなく既存の営業先からの成果をいかにして最大化していくか、ということを考えていく必要があります。つまりはLTVの最大化ですね。既存営業先と一口に言っても、当然それぞれ状況が異なります。相性や質の面でもそうですし、それに加えて時期的な良し悪しなども存在するので、様々な要因を考慮した上で、今現在どこに注力すべきかという分析を行う必要があります。その時に営業をかけるべきところがわかれば、闇雲に営業をかける必要はなくなり無駄が抑えられますよね。時間がかかる新規を開拓するよりも、既存の営業先をしっかり抑えることで、確実に売上を伸ばしていくということをまずは実現したいです。 ーサービス化に伴う課題はありましたか？ 上田さん： セールススイートに関しては大きく2つの課題がありました。 1つはデータアベイラビリティに関する課題です。会社によって手に入る情報、持っている情報の種類にばらつきがあるというのが、プロダクトとして画一的なフローを用いる際に壁になりました。例えば、ネットプロモータースコアのような、我々が従前よりコンサルティングを行う際に用いていたデータを必ずしも全ての企業が保持しているわけではありません。そのようなデータと相関し代替しうるデータは何かを考え、またそれに合わせて分析も変える必要がありました。 2つ目が、元々大手事業会社で活用していたノウハウなので、別の業種や業態でもその知識と経験を活用できるのか、合う業態は何なのかの見極めが必要という点です。特定の企業、業種、業態のみでしか利用できないとなるとビジネスとしてスケールしないので、人材紹介で培ったノウハウをいかにして横展開できるのかというのを検証していく必要があります。 現在、人材紹介以外の業態の企業で実際に利用してもらい、検証を進めている段階です。 少人数体制、経験者不足が開発の課題 ー実際に開発を見据える中でどのような活動をしていましたか？ 上田さん： 最初にソリューション選定を行う必要があったので、AWS Summit Tokyoに参加してみました。0から立ち上げることになるので、内製のエンジニアが少ないことや新規領域への大規模な投資は難しいという組織的な背景に対して、少数のエンジニアでどのようにして開発と運用を行っていくかというのが課題でした。 SaaS開発の一部に携わったことのあるメンバーはいましたが、SaaS全体の開発に携わった経験のあるメンバーはいませんでした。ビジネスサイドでSaaSに携わったメンバーはいましたが、テックサイドでは十分な経験があるメンバーがいない状況でした。 当初は認証画面やユーザーデータベースは自社で開発していましたが、とりあえず正常系を作っておいて異常系に関しては後回しにしてしまっていました。最初のうちはエンジニアしか使わないので、テナントセットアップやユーザー追加をCLIベースにしていましたが、PMサイドが見るための画面などの必要性も感じ始めている段階で、SaaSus Platformを利用することで、その辺りの手間が省けるのではと感じました。 ー実際に利用してみていかがでしたか？ 認証やユーザー管理の開発の手間は明確に減っていると感じています。導入以前の工数について細かく把握はしていなかったので、実際に導入前後での比較はできていませんが、ログイン周りの画面や機能をしっかり作るとなると、1人月は最低でもかかると思いますし、ユーザー管理の部分に関してもそれなりの時間とコストがかかると思われるので、そこの工数や運用負荷を低減できたというのは実感としてありますね。 現状、検証のフェーズということもあり利用企業が少ないので請求機能に関してはまだ使用していませんが、今後、顧客数が増えていったら請求機能も使いたいと考えてます。SaaSはユーザー数に応じた課金が一般的かと思いますが、セールススイートは売上を上げることが主たる価値提供なので、プライシングも売上の増加に応じた分を料金とする形や売上上昇見込みのパーセンテージに応じた課金なども面白いかなと考えています。 ドメインナレッジを持った開発組織へ ーありがとうございます。オクタゴンの今後について教えてください。 上田さん： オクタゴンに関しては、スタートはセールスから入りましたが、将来的にはマネジメント領域のプロダクトを中心にした展開を考えています。経営ボードのようなイメージで企業の予実や売上やコストを分解してダッシュボード化し、会社全体の管理を行い、それを通じて可視化された課題に対して、オクタゴン内のプロダクトを活用して解決策を提示していく、ある種コンパウンド的な事業を考えています。 オクタゴンの構想にはこれまで、実務に携わってきたメンバーの経験と実績という強みがあります。ソリューションが提供する価値が課題を解決できるであろうという点については検証が既に済んでいる状態です。そのソリューションをプロダクト化した時に、変化する部分がどの程度価値提供に影響するのかの検証で済むので、検証に要する時間やコストが少ない点は他のプロダクトと異なる点かもしれません。検証が手軽なので、それに開発が追いつかないということを避けるためにもソフトウェアのアジリティも重要だと感じています。 プロフェッショナルのナレッジという最大の武器をプロダクトに落とし込むために、エンジニア組織についても、業務領域ごとのプロフェッショナルのドメインナレッジを浸透させていくことが重要になると考えています。単に開発のみを行うエンジニアではなく、プロダクトの扱う領域のナレッジを持ったエンジニアが開発を行うという形が理想かなと思います。プロダクトと開発メンバーが紐づいていて、ドメインナレッジを持ったメンバーで組織化を行うことは、我々の持つ武器を最大限に生かしつつ、ソフトウェアのアジリティの担保にも繋がると考えています。 私個人としては、今後複数のプロダクトがオクタゴンの中で誕生していくことが想定されるので、それらの全体像を把握しながら1つの統一されたコンセプトとしての整合性を保つポジションとしてテックサイドをリードしていくことになると考えています。 ーSaaSus Platformの今後について期待することはありますか？ 上田さん： 機能面で言えばユーザーのアクティビティを可視化するような機能が実装されると嬉しいですね。ユーザーの動きが把握できればCSの高度化にも繋がりますので。 あとは、オクタゴンは複数のサービス群で成り立っていく想定なので、プロダクトを横断したIDやテナント、料金プランなどの管理ができると良いですね。そうなると、プロダクトのマイクロサービス化への対応がしやすくなるので、複数のプロダクトを扱う企業には刺さるのではないでしょうか？ ー最後にSaaSus Platformの導入を検討している方に向けてメッセージをいただけますでしょうか？ 上田さん： SaaSus Platformはエンジニア不足の会社にとって、開発立ち上げ時のショートカットには最適です。 ーありがとうございました！ E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 --- ## 【導入事例】『matomeru』株式会社グリーンロード URL: https://saasus.io/blog/green-road Date: 2024-03-26 花や植物の販売を通じて様々なサービスを展開する株式会社グリーンロード。今回はお祝花のあらゆるフローをワンストップで提供する『matomeru』のリニューアルにおけるSaaSus Platformのご活用についてお話しいただきました。 インタビューにご協力いただいたのは取締役の加藤雄太さんです。 コロナをきっかけに生まれたサービス ーまずは、貴社の事業内容やプロダクトについて教えてください。 加藤さん： 株式会社グリーンロードは、社名にもある通り観葉植物などの「グリーン」やアレンジメントなどの「お花」に関する事業を中心に展開しています。元々はtoC向けの店舗でのお花屋さんから始まりましたが、代表が長年BtoBのキャリアを歩んでいたこともあり、徐々にBtoBのお花屋さんがメインにシフトしていきました。現在では、移転や就任パーティーなどのお祝い事の際のお花の製作から納品までをメインに、法人向けのECサイト運営、その他、お花やグリーンを活用した空間プロデュース事業も行っています。 私自身、元々は不動産業界でITを活用した新規事業の企画などを行なっていましたが、花とITとを掛け合わせた事業構想があるということに惹かれ、グリーンロードにジョインしました。花×ITの本格的な一歩として立ち上がったのが『matomeru』になります。 『matomeru』は空間プロデュース事業から派生して生まれたサービスです。空間プロデュース事業では、空間のデザインとそれに伴うお花等の納品を行なっておりましたが、新型コロナウイルスの影響が、当該事業への売上にも影響が及ぶようになりました。 お祝い事をすること自体が減っただけでなく、お祝いをするにしても、各社が手配した業者が出入りするという状態が感染予防の観点で望ましくなく、お祝いを受け付けず内々で済ますというケースも増え、人と人との距離感だけでなく、企業同士の距離すらも遠くなっているように感じており、そういった課題への対策として『matomeru』の構想が立ち上がりました。 お祝いをしたい企業様がそれぞれ業者を手配するのではなく、『matomeru』が依頼を受けて弊社が一括で納品することで、会場への人の出入りを減らし、不特定多数の出入りという状況を回避し、安全にお祝花を送ることができます。それだけでなく、お祝花のフローを『matomeru』で一括管理することで、受け取る企業様とお花を送る企業様それぞれの作業の手間を低減することが可能です。 コロナ禍を契機に誕生したサービスですが、企業の作業負荷の軽減というメリットは大きく、それ単体でも十分な価値を提供できると考えています。実際に『matomeru』を始めてみると、ニーズの強さを感じました。お祝花という文化は素晴らしいものですが、花や植物という物理的なもののやり取りが必要になるので、贈る側も贈られる側も手間がかかってしまいます。『matomeru』を使うことで、簡単にお祝花を贈ることができるようになるので、企業同士のお花を通じたコミュニケーションがより活発になるのではないでしょうか。 リソース不足、ナレッジ不足、経験不足という課題 ー『matomeru』は最初からSaaS化を見据えて立ち上げられたのですか？ 加藤さん： 最初はSaaS化どころかサイトすらない状態から始めました。とにかく、スピード重視でアイデアの検証を行いたかったので、個別に受注して『matomeru』のサービスを提供していました。そこからサイトを作ってフォームで問い合わせや申込を受けるようになり、次のステップとしてSaaS化に辿り着きました。 『matomeru』のサービスはお祝花をもらう企業がお祝花を受け付けるような形になるので、若干、日本人の感性として受け入れられづらいかなという懸念はありましたが、実際にご利用いただくことでその便利さを体感していただけます。今後、顧客数の増加が見込まれるため、システム化によるスピーディな対応を可能にすることで、お客様の利便性を高めるだけでなく、売上の増加にも寄与すると考えています。 ーSaaS化への課題についてお聞かせください 加藤さん： そもそもですが、お花屋さんが主軸なのでシステムに理解がある人間がほとんどいませんでした。構想はあるものの、それを作れる人がいないという状態でしたので、2年くらいは最低限のサイトとフォームだけで事業を行なってきました。私は数年、エンジニアリングを担当した経験がありますので、ビジネスサイドとして要件や要望を伝える上でのエンジニアとのコミュニケーションはある程度できますが、構想を具体化したり開発のディレクションまでを行うことは難しいというのが実情でした。今後の事業の拡大を見据えた時に、システム投資への必要性を感じていましたが、リソースも限られている中で、開発の全部を外部に委託するのは単純な委託のコスト面だけでなく、開発のディレクションなどコミュニケーションにも多大な工数がかかりそうだなと感じていました。単なる委託ではなく、工数を最小限に抑えつつ、事業構想の段階から一緒にサービスを具現化できるパートナーを探していました。 今後の事業の拡大を見据えた時に、システム投資への必要性を感じていましたが、リソースも限られており、自社のIT部門の体制も十分ではないため、開発リソースは外部に委託しようと考えていました。とはいえ開発の全部を外部に委託するのは単純な委託のコスト面だけでなく、開発のディレクションなどコミュニケーションにも多大な工数がかかりそうだなと感じていました。 ーSaaSus Platformを導入いただいた決め手などはございましたか？ 加藤さん： 元々、SaaSus Platformは、いかに小さく始め、コストを抑えていくかという課題への一つのアプローチとして有用なのではと考えていました。いかにロスをなくすかという観点で計画を立てようとすると、作りたい機能とその開発期間や工数を事前に細かくシミュレーションしなくてはいけません。しかし、スピード感を持って進めたいとも考えていたので、「早く小さく」を実現できるようなサービスがあれば良いなと考えていました。自分たちで作るよりもサービスを使うことで課題を解決して、本当に必要な機能に集中して開発をしていくという要望にピッタリだと思い、導入しました。 ー実際に利用した感想をお聞かせください。 加藤さん： SaaSus Platformはユーザー管理の部分についてはほとんど考えずに、最初期にエンジニアチームと認識が揃えられたらあとは特に具体的なオーダーを出す必要がありませんでした。そのおかげでビジネスのところに注力できています。必要な機能はSaaSus Platformに任せて、欲しい機能やサービスの価値を高めるための機能に集中できるので、時間がない中でビジネスにとってより重要なところに時間を使いたいという当初のニーズをしっかりと満たしているように感じます。 ＜実際にSaaSus Platformを活用したサービスの構成図＞ ＜設計のポイント＞ OGPタグ対応のため、AWS Amplifyを利用しSSG/SSRを使い分けている。 GitHub Actionsを利用したAmazon ECSへの自動デプロイを構成。 デプロイ時の認証にはOIDCによるIAMロールを利用。 お花×ITをさらに進化 ー貴社や『matomeru』の今後について教えてください。 加藤さん： 会社としては花×ITのITの部分を伸ばしていけると良いかなと考えています。まだまだ、人の手に依存する部分が多いのが現状ですが、ITの領域を広げていくためにも、ゆくゆくは内部にエンジニアチームを持ちたいと考えています。今は花屋としての側面が強く、人材の確保が難しいこともあり、外部に委託しながら社内にナレッジを蓄積していく段階だと考えています。 近々では、大きな開発は委託、UI/UXなど日々改善が必要な部分については社内で改善という動き方になるかと思います。 『matomeru』については、今はお花に特化したサービスですが、お祝花以外のお祝いを贈れるような形にできたら良いかなと思っています。あらゆるお祝いシーンに活用できるお祝いプラットフォームへの進化にご期待いただければと思います。 ーSaaSus Platformに今後期待する点はございますか？ 加藤さん： 請求機能の柔軟さが上がると嬉しいですね。現状、Stripeを使った請求機能はありますが、 Stripe形式での請求書の送付になるので、そこの自由度が高まると社内の請求フローや所定の形式に合わせた利用ができるのではないかと感じています。 また、メール配信やメルマガ機能などのマーケティングをアシストする機能があると、今後、顧客数が増えてきた時にありがたいと思います。 ー最後にSaaSus Platformの検討者へ一言をお願いします。 加藤さん： 新規事業の立ち上げの際に、リソース不足に悩む企業は多いのではないでしょうか？ SaaSus Platformを使えば、開発工数だけでなく、ビジネスサイドの時間の有効活用にも繋がります。必要なところに集中できて、より価値の高いサービスを提供することに繋がるので、費用対効果は抜群です！ ーありがとうございました！ E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 --- ## 【導入事例】『Sylphina』株式会社ギークフィード URL: https://saasus.io/blog/geekfeed Date: 2024-02-22 工数削減とSaaS開発の知識、経験の補完で安全かつスピーディなリアーキテクティングを実現！！ ソフトウェア開発を中心に様々な事業を展開する株式会社ギークフィード。 近年ではAWS アドバンストティア サービスパートナーの認定を取得するなど、クラウド事業にさらに力を入れています。 今回は、既存SaaSのリアーキテクティングという課題にSaaSus Platformを活用し取り組んだ経緯とその効果についてお話しいただきました。 インタビューにご協力いただいたのはAWS テックリードの西山一平さんです。 コンタクトセンター関連システムのプロフェッショナル ーまずは貴社の事業内容と西山さんの業務内容について教えてください。 西山さん： 株式会社ギークフィードは現在創業13期目でソフトウェア開発をメインの事業としています。事業内容としてはWebアプリケーションや基幹システム、業務システムなどのシステムの受託開発、自社サービスの販売・運用や自社クラウドサービスの開発・販売、AWSの構築、クラウドに関するコンサルティング、AWS上の開発を行うクラウドサービスなど多岐に渡ります。代表が通話録音やコンタクトセンターシステムのソフトウェア開発の事業に携わっていたこともあり、コンタクトセンターや通話に関するシステムを扱うことが多いです。 私はクラウドサービスの事業に携わっており、既にAWS上で提供している『Sylphina』というシステムのSaaS版の開発の統括を行っています。 ーありがとうございます。 今回、『SaaSus Platform』を利用して『Sylphina』のSaaS版の開発に着手されたとのことですが、まずは『Sylphina』ついて詳しく教えてください。 西山さん： 『Sylphina』は端的に説明するとAmazon Connect（AWSが提供するクラウドコンタクトセンター構築サービス）の機能を補完・拡張するアプリケーションです。Amazon Connectでは一般的な電話の受信や発信の機能自体は備えているものの、そのままでは機能や仕様の面で実際にコンタクトセンターで業務を行う人たちのニーズを満たせないことがあります。実は、日本のコンタクトセンターの独自の文化に即した機能や要件というものが存在します。主要なものでいうと、オフィスの座席の配置をPrivate Branch Exchange(PBX)の画面上に表示させて、オペレーターの状況を直接視認して把握するというのが日本のコンタクトセンターでは一般的です。これはオンプレからクラウドに移行するといったケースのRFP(Request for Proposal)にも高頻度で載るものですが、日本独自の慣習なのでAmazon Connectにはそのようなことを実現する機能がありません。 日本特有のニーズや要望がある中でAmazon Connectをそのまま使うと要件を満たせないことがあるので、それを補完するためのアプリケーションが『Sylphina』です。 『Sylphina』機能一覧 カスタムブラウザフォン AIソリューションとの統合 ユーザー管理 ヒストリカルレポート／分析ツール リアルタイムダッシュボード カレンダー営業時間設定 『Sylphina』の機能にはAmazon Connectで実現可能なものも含まれます。例えばカレンダーの営業時間設定などはAmazon Connect上で設定することができますが、AWSやエンジニアリングの知識がないコンタクトセンターの管理者がそれを行えるかというとそうではないケースが多いので、『Sylphina』を使用することで直感的にAmazon Connectの機能を使えるようにする、という補助的な役割も担います。 ーなるほど。一口にコンタクトセンターといっても国によって必要な機能が異なるのですね。コンタクトセンターシステムをクラウドサービスで提供し始めた背景は何だったのでしょうか？ 西山さん： クラウドサービス化を後押しした要因としては、やはり新型コロナウイルスの影響というところが大きいかと思います。それ以前からオンプレサーバーや業務システムのクラウド化の流れというのは始まっていましたが、コンタクトセンターを構えていてもオペレーターが出社できない、業務に使うPCもオフィスにあるというような状況で、オンプレのPBXをクラウド化するというニーズが爆発的に増えました。 ー『Sylphina』をはじめとするコンタクトセンターのクラウドサービスにエンドユーザーが求めるものや解消したい課題というのはどんなものがありますか？ 西山さん： 大きく分けて3つあると考えてます。1つ目は複数業務への対応が可能であることです。コンタクトセンターでは1人のオペレーターに対して複数の窓口業務をアサインすることがあります。そのため、業務や相手方に応じて発信番号を切り替える必要がありますが、Amazon Connectにはそのような機能が標準搭載されていないので、『Sylphina』を使うことでそういったニーズに応えることが可能です。 2つ目はオペレーターの業務の効率化です。他のオペレーターに転送する必要がある際に、そのオペレーターが転送を受けられるかを瞬時に把握することができる必要があります。 先ほどもお話ししましたが、オフィスで業務を行う際には実際にオペレーターの状況を視認して判断できますが、リモートだとそれができません。そういったケースに対応するために『Sylphina』ではオペレーターのリストとリアルタイムのステータスを表示し、判断ができるようにしています。また、電話を掛けてこられたお客様を待たせることは基本的に避けたいので、自身の業務の着信に待機時間が発生していないかも画面上に表示し、待機中のお客様がいる場合にはアラートを出すことで待機時間を最小限にすることが可能です そして3つ目がレポート関連です。 リアルタイムのレポートや各業務ごとの状況を管理者が把握できるようにする必要があります。確認すべきKPIは日本独自のものもあり、必要な情報のみを瞬時に取得できるようにレポートのカスタマイズ性も重要なポイントになります。SaaS版では今後、ヒストリカルレポートのカスタマイズ機能の実装も予定されており、レポート関連のニーズをさらに満たせるのではないかと考えています。 知識と経験の不足がSaaS化の壁に ーありがとうございます。サービスについてよく理解できました。 続いてSaaS化の部分についてご質問させていただきたいのですが、SaaS化の構想自体はいつ頃からあったのでしょうか？ 西山さん： 初期段階から理想としてはマルチテナントの形で作りたいという思いはありました。しかし、当初は2人体制で開発を行っていたので、リリースのスピード感や開発人員不足などの課題もあったため、個別のテナントとリソースを用意して、必要や要望に応じてカスタマイズをしながら提供していました。2,3件実際にお客様に提供していく過程で、部署が大きくなって人的リソースも増えたため、将来的な拡張性や安定性を高めるために大幅なリファクタリングを実施し、2023年5月に最新バージョンがリリースされました。 その後、事業部内で『Sylphina』を今後どのように展開していくかについて考えた時に、従来のように大規模な顧客に対して個別にカスタマイズを施して提供していく形は維持しつつ、SaaS化してセルフサインアップができるようにして裾野を広げていくという決断に至りました。既にAmazon Connectを利用している方の中には、小規模のコンタクトセンターやオフィスなど、個別にカスタマイズを行わずとも標準の『Sylphina』で十分に価値を提供できるのではないかと考えています。 ーSaaS化において課題となっていたのはどのようなところでしたか？ 西山さん： 端的に申し上げると、知識と経験の不足ですね。 SaaS開発と通常のソフトウェア開発が別物であるということは漠然と理解していましたが、テナント分離やオンボーディング、リソース共有の際のセキュリティの辺りが重要になることは分かっていても具体的にどのように考えるべきか、というところは明確にありませんでした。 ーSaaSus Platformの体験会にご参加いただきましたが、そこでの発見などはありましたか？ 西山さん： そうですね、体験会で実際にSaaSus Platformを触ってみて、開発コンソールと運用コンソールを別で用意する必要があることに気づきました。よくよく考えれば当然必要なものなんですが、SaaS開発の経験がない状態では実際に必要な部分を知らなかったり、見落としていたりということに気づかないまま、開発を進めていたかもしれません。仮に自分たちで1から考えて作っていたら、数ヶ月かかっていたかもしれない機能群を、自前で作らず利用できるので、コストメリットが非常にあると感じました。 開発工数の削減だけでなく、検討漏れのリスクにも対処できるという点は魅力的でした。 ーSaaS化については完全な内製も検討していたのでしょうか？ 西山さん： ちょうどSaaS化の検討を始めた段階でSaaSus Platformのご紹介を受けたのもありますが、コストメリットが明らかだったのでそれほど考えずにSaaSus Platformの利用を選びました。今回は定例MTGを設けていただいたり、必要に応じて相談を受けていただけるなどサポート体制も提供いただいたので、是非にという感じで、利用への障壁は特段ありませんでした。 ーSaaSus Platformを利用する上で期待していたポイントや達成したい目的は何でしたか？ 西山さん： 従来の『Sylphina』はアウトバウンドではなくAWS様やパートナー企業からの紹介で顧客を獲得していました。大規模かつ個別のカスタムを要するケースが多いので、紹介数が多いと人的リソース的に対応できないという状況も起こりえます。 ですので、SaaSus Platformを利用することでセルフサインアップを可能にして、最小限のリソースで顧客を獲得することができればと考えています。2ヶ月無料のプランを用意しているので、トライアルからお試しいただき、評価していただくことでより『Sylphina』の価値を高めて行けたらと考えています。 ーSaaS化の過程でつまづいた点やSaaSus Platformを利用する上で苦労したポイントなどはありましたか？ 西山さん： 開発に取り掛かった最初の月はあまり進捗が芳しくなかったです。認可のリゾルバーやマルチテナント化のためのスキーマ変更など具体的なアクションがわからず、なかなか進みませんでしたが不明点について相談させていただいて、理解してからはスムーズに開発を進めることができました。 SaaSus Platformを使う上で苦労したのは認証の部分ですね。従来の『Sylphina』はAWS Amplifyをベースに作られていて、その中でAmazon Cognitoを利用していましたが、SaaSus Platformが管理するCognitoに認証することになったので、自分の所有していないアカウントに対してクロスアカウントで、AWS AppSyncやAmazon API Gatewayからの認可で利用するところでハマってしまいましたね。AWS Amplifyはその中で完結するので、他のリソースを組み合わせて作るというのが難しかったです。 ー貴重なご意見ありがとうございます。AWS Amplifyと組み合わせるケースは今後も想定されるので、スムーズに実装できるようドキュメントやサポート体制など整えていければと思います。 ー現時点でのSaaSus Platformの導入効果など感じられましたか？ 西山さん： やはり開発におけるコスト削減の効果は大きいかと思います。 開発・運用コンソールや請求関連機能の部分など、既存のメンバーで作っていた場合、おそらく半年以上時間を要する上に、SaaSus Platformと同等のものを作れるかは分かりません。開発費用を毎月1人につき100万円と仮定した場合、それだけで1200万かかっていたと考えると、コストメリットは圧倒的かなと思います。また、サポートが手厚かったおかげで開発を加速することができたと思います。 ーAWSのサービスと組み合わせて活用している機能にはどんなものがありますか？ 西山さん： SaaSus PlatformのAmazon EventBridge連携機能とAWS Cloud Development Kit (CDK)を組み合わせて活用し、テナントオンボーディングを自動化しています。テナントの契約ごとに環境作成を手動で実施しているとサービスの提供までにリードタイムがかかってしまいますし、差異が生まれる人的ミスのリスクもあります。そういった課題に対応すべく自動化に取り組んでおります。これにより課題の解決はもちろんビジネスのスケールにも耐えられる体制になったと考えております。 SaaS版『Sylphina』の機能拡張によって小中規模事業者の課題を解決していく ー今後の事業の展望などお伺いできればと思います。 西山さん： 先ほどもお話しした通り、従来の『Sylphina』で個別のお客様へのカスタマイズ提供とSaaS版の提供を組み合わせることで『Sylphina』というサービスをより発展させていけたらと考えています。 また、SaaSus Platformをご紹介いただいたのもAWSパートナーネットワーク経由ということもあり、AWSパートナーネットワークに可能性を感じています。Amazon Connectや『Sylphina』をはじめ、コンタクトセンター関連を得意とするパートナーはそれほど多くないので、より多くのパートナー企業に『Sylphina』を認知していただき、Amazon Connectと『Sylphina』がセットで提供されるようなサービスにしていけたらと思います。 SIできるパートナーが少ないこともありますが、国内では中規模向け、小規模向けの領域が手薄になっているように感じます。SaaS版の『Sylphina』の機能を拡充しながら、そういった層の課題を解決し、SaaS版で得た知見やフィードバックを元に従来の『Sylphina』の基本機能を拡充し、多様性や充実性を高めて、AWSや大手のプレミアパートナーなどのより大規模な顧客のAmazon Connectに対するニーズに『Sylphina』で応えていけたらと考えています。 ー今後、SaaSus Platformに期待することはございますか？ 西山さん： 将来的には『Sylphina』をAWS Marketplace経由での提供ができたらと考えています。SaaSus PlatformをAWS Marketplace経由で契約しましたが、利用開始までがスピーディーで感動したので、ぜひ利用したいです。『Sylphina』はAmazon Connectの補完・拡張を行うので、AWS前提のビジネスになるので、顧客との親和性も高いため期待しています。 ー最後にSaaSus Platformの導入を検討している方への一言をお願いします。 西山さん： SaaSに関する経験や知識がない状態からサポートを受けながら『Sylphina』のSaaS化を行ってきました。SaaSを作る前には気づいていませんでしたが、SaaSを作る上で必要な機能や検討事項というのは実際には予想以上にたくさんあります。 SaaSus Platformはそういった部分をカバーしてくれるので、ぜひご利用を検討してみてはいかがでしょうか。 E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 --- ## 国内SaaSの公開しているAPIまとめ URL: https://saasus.io/blog/saas-api-list Date: 2023-07-31 日本のSaaS市場は急速に成長しており、多くの企業が効率的なビジネス運営を支援するためにSaaSソリューションを導入しています。APIを活用することで複数SaaSを連携して業務効率を高めたり、自社で開発するサービスの一部をAPI連携したSaaSに委ねたりなど、APIを活用することでSaaSはさらに拡張性が高まります。 この記事では、SaaSが提供しているAPIを紹介します。 APIとは API（Application Programming Interface）は、異なるソフトウェア同士が情報をやり取りするための手段や取り決めです。イメージとしては、APIはソフトウェア同士がコミュニケーションするための窓口やルールブックのようなものです。 具体的には、APIはソフトウェアやアプリケーションが他のソフトウェアとやり取りするための方法を提供します。例えば、ウェブサイト上の天気情報を表示する場合、気象情報の提供元がAPIを公開しています。開発者はそのAPIを利用して、自分のウェブサイトに天気予報を表示することができます。他にも、APIは私たちが利用するアプリやサービスの多くに使われています。例えば、地図アプリは位置情報サービスのAPIを使用して地図や経路情報を提供し、オンラインショッピングサイトは決済サービスのAPIを利用して安全な決済処理を行っています。 APIが重要な理由 APIがなぜ重要なのか、その代表的な理由を3つ紹介します。 機能の拡張と統合 APIを使用することで、異なるSaaS同士を統合し、相互の機能を拡張することができます。たとえば、プロジェクト管理ツールとタスク管理ツールをAPIで連携させると、プロジェクトの進捗状況に基づいてタスクの自動更新や通知が可能になります。これにより、効率的な作業フローを構築し、生産性を向上させることができます。 データの一元化と共有 SaaS同士をAPIで連携すると、異なるシステム間でのデータの一元化や共有が容易になります。例えば、CRM（顧客関係管理）ツールとメールマーケティングツールをAPIで連携させると、顧客の情報や購買履歴を自動的にメールマーケティングに活用することができ、パーソナライズされた施策を打つことが可能になります。 カスタマイズと柔軟性 APIを使用することで、SaaSを自社のニーズに合わせてカスタマイズすることができます。APIを介してデータや機能にアクセスすることで、開発者は独自のアプリケーションやツールを作成し、ビジネスプロセスを最適化することができます。例えば、SaaSのプロジェクト管理ツールにAPIを組み込んで、自社のタスク管理ツールとの連携を実現することができます。 これらのメリットにより、APIを使用してSaaS同士を連携させることで、効率的な業務フローの構築、データの一元化と共有、柔軟なカスタマイズが可能になります。また、APIの利用は開発者にとっても魅力的であり、新たなアプリケーションやサービスの開発が促進されることもあります。 では、次の段落からAPIを公開しているSaaSを紹介します。 会計SaaS freee freeeのAPIの代表的な例として、会計データの取得と更新ができます。会計データ（取引、勘定科目、税金情報など）にアクセスし、取得や更新を行うことができます。これにより、他のシステムやアプリケーションとの統合が容易になります。例えば、顧客管理システムや在庫管理システムとの連携などが可能です。 他にも、請求書や経費の作成と管理、税務関連のデータ（源泉徴収票や確定申告書など）を取得できます。 詳しくはこちら：https://developer.freee.co.jp/reference/accounting FX4クラウド FX4クラウドのAPIの代表的な例として、取引先の取得ができます。取引先の担当者情報などを取得でき、手動でのデータ入力作業を省略し、正確性と効率性を向上させることができます。 他にも、勘定科目や収支区分の取得が可能です。 詳しくはこちら：https://www.tkc.jp/api/fxcloud/dev/ 勤怠管理SaaS KING OF TIME KING OF TIMEのAPIの代表的な例として、勤怠データの取得ができます。従業員の出勤・退勤時間や休暇の情報など、勤怠関連のデータを取得することができます。他にも、勤怠データの登録・更新など既存のデータを更新したりすることができ、外部のシステムから従業員の勤怠情報を自動的に送信する場合などに利用できます。 詳しくはこちら：https://developer.kingtime.jp/ Zoho People Zoho PeopleのAPIの代表的な例として、従業員データの取得があります。従業員の基本情報（氏名、連絡先情報、雇用形態など）を管理することができます。 他にも、休暇申請や勤務スケジュールの管理などができます。 詳しくはこちら：https://www.zoho.com/people/api/overview.html kincone kinconeもKING OF TIMEやZoho Peopleと似たようなデータを取得することができます。他にも、勤怠申請や交通費申請なども取得することができます。 https://kincone.com/api_docs/ 経費精算SaaS ジョブカン経費精算 ジョブカン経費精算のAPIの代表的な例として、ユーザー情報の取得ができます。新規登録、更新や停止が可能です。 他にも申請書の取得や交通系ICカードのアップロードも可能です。 詳しくはこちら：https://ssl.wf.jobcan.jp/api_doc staple stapleのAPIの代表的な例として、領収書の金額や日付、カテゴリーなどの情報を取得することができます。他にも請求書などその他の書類のデータを取得することができます。 詳しくはこちら：https://documentation.staple.io/ チャットSaaS ChatLuck ChatLuckのAPIの代表的な例として、ログインデータの取得があります。その他にもシステム通知、チャットボットのAPIがあります。 詳しくはこちら：https://www.chatluck.com/help/ja_JP/api/index.html LINE WORKS LINE WORKSのAPIの代表的な例として、組織やグループのデータの取得があります。他にも、カレンダー機能やファイルのアップロード、ダウンロードができます。 詳しくはこちら：https://developers.worksmobile.com/jp/docs/api Slack slackのAPIの代表的な例として、メッセージの送受信があります。他にも、メッセージの編集や削除、グループ管理なども可能です。 詳しくはこちら：https://api.slack.com/docs CRMSaaS、SFASaaS HubSpot HubSpotsのAPIの代表的な例として、リードおよび顧客データの作成・更新・削除ができます。他にもチャット機能などがあります。 詳しくはこちら：https://developers.hubspot.jp/docs/api/how-to-use-hubspot-api Freshsales FreshsalesのAPIでは、HubSpot同様、リードおよび顧客データの作成・更新・削除ができます。他にも連絡先や営業活動の記録などのデータも取得可能です。 詳しくはこちら：https://developer.freshsales.io/api/ Web接客SaaS KARTE KARTEのAPIの代表的な例として、外部チャットボットとの連携があります。これにより、チャットボットとユーザー間でのメッセージの送受信が可能になります。他にもユーザーの行動データの取得などもできます。 詳しくはこちら：https://developers.karte.io/reference/api-v2-overview#api-overview Repro ReproでのAPIの代表的な例として、プッシュAPIがあります。これにより、プッシュ通知をReproの管理画面からではなく、自社サービスのサーバーや、アプリなどから行うことができるようになります。他にもユーザー情報の変更などができます。 詳しくはこちら：https://docs.repro.io/ja/dev/index.html#id1 Freshchat FreshchatのAPIでは、会話の取得だけでなく、アカウントやユーザーの管理、画像のアップロードなどができ、既存のワークフローのカスタマイズや特定のビジネス構造への調整などの課題に役立ちます。 詳しくはこちら：https://developers.freshchat.com/api/ プロジェクト管理SaaS Backlog BacklogのAPIでは、更新の履歴やアクティビティなどのプロジェクトに関するデータやユーザー情報の取得や追加。更新、削除などブラウザ上で操作できることの大部分をAPIから行うことが可能です。 詳しくはこちら：https://developer.nulab.com/ja/docs/backlog/# Lychee Redmine Lychee RedmineのAPIの代表的な例として、プロジェクトの作成や編集があります。新しいプロジェクトを作成したり、既存のプロジェクトの情報を編集したりすることができます。他にもチケット管理やファイルのアップロード、ダウンロードなどのファイル管理も可能です。 詳しくはこちら：https://www.redmine.org/projects/redmine/wiki/Rest_api 名刺管理SaaS Sansan SansanのAPIの代表的な例として名刺情報の取得があります。登録した期間で取得や名前の条件一致での取得が可能です。また、名刺画像の取得や登録することもできます。他にも、ユーザーの取得などができます。 詳しくはこちら：https://docs.ap.sansan.com/ja/api/openapi/index.html SaaS for SaaS SaaSus Platform SaaSus PlatformはSaaSの開発/運用/販売を支援するSaaSです。マルチテナントSaaSを前提にしたテナント管理機能、ユーザ管理機能、役割(ロール)管理機能、料金プラン機能など、どのSaaSにも必要な管理機能を WebアプリケーションにSaaSus SDK/APIを組み込んでいただくことにより利用できます。 詳しくはこちら：https://docs.saasus.io/docs まとめ 紹介したもの以外にもAPIを提供しているSaaSはたくさんあります。導入の際には、どのようなAPIが提供されているかもチェックしてみてください。 E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 また、ブログやE-bookで扱って欲しいSaaSに関するトピックやSaaSus Platformについてもっと知りたいことなどへのリクエストを広く募集しています。コンテンツに関する要望や感想がございましたら、こちらからぜひお寄せください。 --- ## SaaSのメリット・デメリット〜ユーザー目線＆ベンダー目線で解説〜 URL: https://saasus.io/blog/saas-merit-demerit Date: 2023-05-30 近年、SaaSの注目度が高まっているように感じますが、SaaSが実際に有用なのか、そのメリットやデメリットが気になる方もいるかと思います。また、SaaS導入への関心が高まると共に、自社でもSaaSサービスを展開させようと考えている企業も増えているかと思います。そこで、SaaSのメリットとデメリットを利用者と提供事業者の双方の視点から解説してみます。利用者のメリットやデメリットを知ることは提供事業者側にとっても有益な情報となるでしょう。 ユーザーにとってのSaaSのメリット メリット①インターネットがあれば使える SaaSの特徴として、インターネットを経由してサービスが提供されるという点が挙げられます。従来のパッケージ型のソフトウェア提供モデルでは端末にソフトウェアをインストールして利用するという形が主流だったので、ソフトウェアを利用するためにオフィスに出向いたり、決まった端末でないと利用ができないということがありました。 SaaSではSoftware as a Service（サービスとしてのソフトウェア）という名称の通り、所有から利用にフォーカスしてソフトウェアが提供されます。SaaSはブラウザを搭載していればインターネット経由でいつでもどこでも利用ができ、デバイスも依存しません。なので、テレワークやリモートワークなどの働き方との親和性も高く、ニーズが高まりつつあります。 メリット②複数人で同時ログイン可能 パッケージソフトの場合は端末ごとにデータが保有されるため、社内外でのデータ共有の際に手間が多いなどの問題がありました。例えば、ドキュメントを編集したら、ファイルをメールで送付し、それをダウンロードして自分のPCで確認する。というようなことがありました。 それがGoogle documentのようなSaaSを利用することで、複数人でドキュメントが同時に編集できるだけでなく、共有の際にいちいちダウンロードする手間もなくなります。また、最新ファイルが不明から起こるデグレ対策にもなります。データの置き所を端末に依存することがないので、やりとりがよりスムーズになり、作業の効率も大きくアップします。 他にも、複数人のスケジュールを調整するときには、グループウェアを利用すれば、個人に確認しなくても、関係者のスケジュールをすぐに把握することができます。開発の現場では、タスク管理ツールでタスクや進捗情報を確認することで、スムーズなプロジェクト進行に貢献しています。 メリット③導入コストを抑えられる SaaSのメリットとして、導入コストの安さも重要なポイントです。 例によってパッケージ型と比較しますが、パッケージ型では基本的に買い切りとなり、場合によってはオーバースペックになる場合も多々ありました。また、ソフトウェアの他にも導入に必要なハードウェアが必要だったりと、想定外の費用が必要な場合もあります。 SaaSでは、利用の前にフリーミアムと言ってお試し利用ができるパターンがほとんどなので、そのプロダクトが自身のニーズにマッチしているかを実際に利用しながら確認することができます。加えて、作業するデバイスとインターネットの接続ができれば、それ以外の設備の費用は必要ありません。 そのため、お金を支払った後で使えない、不要といった事態に陥りづらいです。また、利用量や利用人数などに応じて料金を選択できるため、無駄なく導入ができる点も魅力的です。パッケージ型のように買った後で不要になった場合などのリスクが少ないので、まずは使ってみようという選択ができ、製品を吟味する時間の短縮にも一役買います。 メリット④コストの予測がしやすい SaaSの支払いは、ソフトウェアの利用に対して月額または年額で支払うサブスクリプションが一般的です。この定期的な支払いモデルにより、使用料金が事前に明確に定義されているため、将来のコスト予測が容易です。また、プラン化された価格設定のためアップグレードする際にも、見積りが出しやすくなります。 メリット⑤継続的なアップデートのメリットを享受できる SaaSは「製品を販売する」という買い切り型ではないため、継続的なアップデートで機能の向上などのメリットを受けることができます。 買い切り型の製品だと、不具合があったり機能に物足りなさがあった場合には新しい製品を購入したり、追加で費用がかかる場合がありますが、SaaSでは継続的に機能改善がなされる場合がほとんどなので、将来への期待も持てます。 例えば会計SaaSの場合では、インボイス制度や電子帳簿保存法のような法改正によるフォーマットの変更なども必要なタイミングでアップデートされるなど、業務に関連する法改正があった際のユーザーの負担を減らすための機能追加が定期的に実施されることで、業務負担が少なくなることが見込まれます。 メリット⑥SaaS同士は連携も可能 SaaSはAPIを活用して複数のソフトウェアを連携させることができます。業務に必要なデータをサービスごとに抽出したり加工する手間を省けるので、より効率的に業務を遂行することが可能になります。例えば、CRM（顧客管理システム）やメール配信ツールなどを統合すれば、営業担当に依存せず、一斉にメールが送れるようになります。 メリット⑦カスタマーサクセスの対応が充実 SaaSを提供する上ではユーザーの声というのは非常に大事なものになります。ユーザーのニーズを満たす機能の提供は解約率を下げることにつながるからです。ユーザーの満足度を高めることがSaaSを運営していく上で重要な要素になるため、ユーザーとのコミュニケーション窓口であるカスタマーサクセスも重要視されています。継続的な機能改善が必要なSaaSは作ってからが本当のスタートと言えるので、ユーザーからのニーズの吸い上げや満足度の改善など、利用開始時だけでなく利用開始してからのサポートが手厚いのもSaaSの良いところです。SaaSを利用する際にはカスタマーサクセスも活用しましょう。 メリット⑧セキュリティの安全性 SaaSではユーザー側で監視する必要はなく、ベンダー側で制御・監視を行います。ベンダーはサービス維持のため、最新のセキュリティ技術を学びアップデートし続けています。また、データのバックアップと復元についても、契約によりますが一般的にベンダーが責任を持っていることが多く、ユーザーが管理する必要はありません。データの損失や破損が発生した場合は、カスタマーサポートへ連絡しましょう。 SaaSユーザーにとってのデメリット デメリット①移行が大変な場合もある SaaSを乗り換える場合に移行が大変な場合もあります。データをCSVなどで出力できる場合もありますが、移行先がその形式に対応してないなどのケースも起こり得ます。 また、利用を停止するとデータの削除などが行われるため、移行時に完全な形で情報を移し替えないと困ることもあります。他サービスと連携させていたりすると、その辺りとの兼ね合いも考える必要があります。 移行期間は移行先と二つのSaaSと同時に契約する状態になるので、コスト面も考えてスピーディーに移行作業を行う必要があります。 デメリット②急なサービスの仕様変更・終了もある SaaSは継続的なアップデートのメリットを受けられる反面、アップデートによる仕様変更が必ずしもプラスに働くとは限りません。使いづらくなったり、よく使っていた機能が提供されなくなったりする場合もあります。しかしSaaSはユーザーのニーズに応じた改善を行うため、重要な機能に関してこのような問題が起こることは稀です。 デメリット③いろんなSaaS使ってると管理が大変になる SaaSは便利ですが、並行して複数のSaaSを同時に使う場合、ログイン情報をはじめとする必要情報の管理やアップデートや仕様変更の業務への影響確認の継続的な実施の必要もあります。また、新規導入時には社内用にマニュアルを残したりなどの作業が発生する場合もあります。ツールを使うための学習コストもあり、ユーザー自身のリテラシーが問われます。使い方は一度理解してしまえば大きな問題ではなく、カスタマーサポートを利用するなど、すぐに問題を解決できるしょう。 デメリット④カスタマイズが難しい SaaSは、多くの場合、複数ユーザーに対して同じインフラストラクチャとアプリケーションインスタンスを利用し、共通の機能を提供しています。個別のカスタマイズが他のユーザーに影響を与える可能性があるため、提供事業者にとって、アプリケーションの一貫性とメンテナンスの容易さを確保するために、個別のカスタマイズを受けることは推奨されません。そのため、ユーザーの抱える要望に個別に柔軟に対応してもらえるケースは少ないでしょう。 なぜ、個別のカスタム要望への対応が推奨されないのか？についてはこちらの記事を参照していただくと理解が進むかもしれません。 デメリット⑤データの移行が難しい SaaSそれぞれデータの形式や構造に関して独自の方法を使用している場合があります。そのため、データを別の環境にシームレスに移行することは困難になることがあります。また、大量のデータを移行する際の負荷など、さまざまな技術的な課題が発生する可能性があります。 ユーザーにとってのSaaSのメリット・デメリットのまとめ SaaSは、社内の業務負荷の軽減に役立ちますが、利用頻度が高いほど、万が一起こるかもしれないサービス仕様変更・終了の影響を受けやすくなります。 複数のツールを取り入れると管理も大変になるので、より業務に役立つものを見極める必要があります。トライアルを活用し最も使いやすいものを導入するようにしましょう。 デメリットは一時的な問題で解決できることの方が多く、導入コストやテレワークの拡大、業務効率の改善の面からも、デメリットよりもメリットの方が大きいと考えられます。 SaaSベンダーにとってのメリット メリット①市場規模が拡大中 SaaSは、前述のユーザーのメリットの豊富さに加え、テレワーク拡大の潮流に後押しされて、近年需要が高まりつつあります。以前であれば、自社で開発することを検討していましたが、SaaSで対応できるという認知も拡大してきました。業務上の課題をSaaS製品で解決できないかと探す顧客の母数が増えることで提供事業者側のターゲットも増えていくため、ビジネスチャンスも比例して拡大するでしょう。 メリット②サブスクリプションモデルで安定収益を得られる SaaSはサブスクリプション型で提供されることが多いです。 サブスクリプションはユーザー側にとっても、導入費用を抑えられるだけでなく、提供事業者も、安定した売上を見込めるメリットがあります。また、売上の見通しが立てやすく事業計画などを立てやすいというメリットもあります。 メリット③顧客の動向に合わせてアップデート SaaSでは顧客の動向や利用状況のデータを提供事業者側が保有することになるので、顧客が求めている機能などを把握するのに役立ちます。顧客のニーズに合わせたアップデートは無駄な機能の開発に時間やコストを取られるという状況を防げるだけでなく、顧客の満足度の向上にも繋がり、解約のリスクを低減させることができます。 メリット④市場への早期投入が可能 SaaSはリリースしてからも継続的なアップデートや機能追加を行うことが可能なので、市場に出すまでの期間が短くて済みます。 市場に投入した後も顧客の動向を見ながら継続的にアップデートを行うことが可能なので、パッケージ型と違って、販売までに膨大な費用と開発リソースを費やしたのに、顧客のニーズに合わず、売れないといったリスクも少なく済みます。 メリット⑤使い始めると離脱しづらく解約されにくい ユーザー側のデメリットとして移行の難しさがあげられますが、SaaS事業者にとっては一度使い始めたら一定期間の継続を見込めるということにもなります。ただし、ユーザーの満足度を満たしていることが前提条件です。ユーザーが離れて行かないように常に工夫を凝らして満足度を高めていくことが必要です。 解約率（チャーンレート）は顧客がサービスにどれくらい満足をしているかの指標になる数値ですので、しっかりと数字を追って改善を目指したいポイントです。 ベンダーにとってのSaaSのデメリット？ デメリット①セキュリティや顧客管理が大変 SaaSを提供する上で困難なポイントとして、提供事業者のやることが非常に多いという点が挙げられます。顧客ごとのテナント管理や、マルチテナント対応、セキュリティも万全にする必要があります。 また、ツールが利用できない状況が続いてしまってはいけません。トラブルが起きた際にはすぐに対応できるよう対策する必要があります。 デメリット②SaaS開発のナレッジが無いと開発が大変 SaaSの開発は一般的なソフトウェア開発と異なる点も多く、それらに関する知識が不足していると、開発が難航する場合があります。 SaaS開発のもっとも大きな特徴としてマルチテナントが挙げられますが、それ以外にもAPIや、顧客の要望をスピーディーにサービスに反映させるためのチーム体制の構築なども含まれます。 デメリット③プライシングなど考えることが多い SaaSを提供する上では検討すべきことが多々あります。サービスの利用料金を決めたり（プライシング）、利用状況のデータの分析、など開発以外の面でも困難は多いです。利用状況を計測し、課金するためのメータリングなど数値管理が必要なものを考えるビジネスサイドとデベロッパーサイドの調和が不可欠と言えます。 また、競合サービスの動向や、親和性の高いサービスとの連携なども考えながら、常にアップデートしていく必要があります。 デメリット④SaaS市場の激化 SaaSというキーワードが世間一般に浸透しつつある中で、今後あらゆるソフトウェアがSaaSとして市場に出回ることが予想されます。競争が激化する中で、競合に有利なポジションを確立するには、市場への投入だけでなく、機能のアップデートなどにおいて競合に負けないスピード感が必要です。 そのためには、競合にはないオプションを調査し、自社サービスの優位性を高める必要があります。まだ世に出てないようなサービスであれば、競合が出る前にリリースできれば有利になります。 ベンダーにとってのSaaSのメリット・デメリットのまとめ 以前であれば、膨大な費用をかけてオンプレミスで自社開発していたユーザーも、SaaS導入までの手軽さやコスト削減などメリットに気が付き始め、さまざまな業種、職種で導入する企業が増えて来ました。需要の増加に比例してSaaSツールの開発に取り組む企業も増え、競合が増えているのが現状です。ですので、有利なポジションを築くためにも企画からリリースまでなるべく短期間で実現するのがおすすめします。開発にはナレッジが必要というデメリットがありますが、SaaS開発のナレッジがある企業に依頼すれば解決することができます。 ニーズにマッチすれば解約されにくく、サブスクによる安定した収益を得ることができるSaaSツール開発は、企業の発展に大きく貢献するのではないでしょうか。 日本のSaaS遅れをとっている！？ SaaSはユーザーにとっても提供事業者にとってもメリットが多いソフトウェアの提供体系ということを説明してきましたが、日本のSaaS市場は、海外と比較すると実はまだ遅れているのが現状で、「SaaS後進国」と言われることもあります。 Gartnerの発表によると、2019年の時点で、日本のIT支出に占めるクラウド支出の割合は3.0%、アメリカでは14%と4倍以上の差があり、アメリカよりも7年遅れているという結果となっています。 では、なぜ日本は遅れをとってしまっているのでしょうか。その理由をいくつか考えてみました。 理由①セキュリティ上の懸念 企業が機密情報や個人情報を取り扱う場合、データの保護とセキュリティ対策が重要となるため、セキュリティを懸念し、企業はSaaSの導入に慎重な姿勢をとることがあります。 理由②SaaS開発企業の少なさ ユーザー側の理由だけでなく、オンプレミス製品に比べ、まだ歴史が浅いSaaS開発は、開発・運用ナレッジを備えた企業がまだ少ないという問題もあります。開発する企業が増えることも、今後のSaaS市場拡大の鍵となってきます。 【まとめ】SaaSはユーザー・ベンダー双方にとってメリット多い！ SaaSの利用はメリットも多く、業務の改善につながります。SaaSの導入が遅れていると感じる方は、社内で不便を感じている業務アンケートをとるなどし、導入を検討してみてはいかがでしょうか。 ユーザーがデメリットと感じる部分の多くは、提供事業者の努力によってある程度解消できるものになります。つまり、ユーザーがSaaSの恩恵を享受できるかどうかは、提供事業者次第とも言えます。事業提供者側は、ユーザーが抱えるデメリットを十分に理解し、解消していかなければなりません。それは、提供事業者にとっては困難な点も多く、なかなか開発に踏み切れないと言ったこともあるかもしれません。 SaaS提供事業者やSaaS開発に踏み切れない企業をサポートするのが「SaaSus Platform」です。SaaSを作るためのSaaSとして、あらゆるSaaSに共通する機能を手早く実装することを可能にし、SaaS開発・運用の経験がない場合でも、将来発生するリスクを抑えながらSaaSビジネスを始めることができます。 E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 --- ## SaaSの利用規約作成時に意識すべきポイントと注意点 URL: https://saasus.io/blog/tos-for-saas Date: 2023-05-22 何かビジネスを行う際に、顧客と契約を結ぶというのは非常に重要なプロセスです。それはSaaSにおいても例外ではなく、契約書あるいは利用規約を用いて顧客との契約関係を築きます。 SaaSを利用したことはあっても、実際にビジネスとして立ち上げ、運営を経験している人はまだまだ少ないように思います。そんな中で、SaaSの利用規約をどう作成したらいいのか？また、SaaSの利用規約と他のサービスやプロダクトの利用規約との違いはなんなのか？といった疑問をお持ちの方のために、弊社のSaaSus Platformの規約作成時の経験をもとにSaaSの利用規約を作成する際のポイントをまとめてみました。 利用規約の目的と役割 まずは、利用規約の目的についてしっかりと理解しておく必要があります。 利用規約の目的は平たく説明すると契約事項の明確化です。本来、事業を行うなかで、契約を結ぶ際には契約書を用いますが、SaaSなどの数多くの顧客と契約することが見込まれる場合、全ての顧客と毎回契約書の内容を擦り合わせて締結するという手順を踏むとなると、業務が煩雑になるだけでなく契約までのスピードが落ちる恐れがあります。 そこで、利用規約を用いることで、全ての顧客に画一の内容を提示し、同意の有無を以って契約書と同等の効力を発揮することができます。 同意取得について 利用規約によって契約を明確にしても、相手方の同意を確認できなければいざトラブルなどが生じた場合に契約の実態を主張できない可能性があります。契約は口頭でも成立しますが、実際には書面やその他の方法で契約に関して合意が取れている証拠を残す必要があります。 SaaSなどでは一般的には利用登録のページに利用規約とプライバシーポリシーのリンクを設置し、そこに同意のチェックボックスを設けることが多いようです。サービスの利用をした時点で同意とみなす内容を規約上で明文化しておけば、チェックをした時点で規約の内容に同意したとみなされます。 規約の内容を変更した際に、変更前の同意取得のログはあるものの変更後の同意については取得できていない。といったことになると、トラブルになりかねませんので、そのような事態を避けられるように同意取得の手段を構築する必要があります。 例えば、変更の際にはログイン画面にポップアップで変更内容を表示してチェックボックスで改めて同意取得をして、同意をしてからじゃないとサービス利用に進めない形にするなどの方法があります。 利用規約の重要性 利用規約は顧客と提供事業者との契約書の代わりとなりますが、契約を明確にすることが何の役に立つのかを理解しておきましょう。目的や重要性を理解せずに規約を作成すると将来的なリスクになりかねません。 トラブル時に会社を守れるようにする 利用規約があることで、万が一トラブルになった際に会社を守ることに繋がります。 損害賠償や免責事項など、もしもの時に責任の負荷を低減させたり、理不尽な要求をされた際に、突き返すための盾になります。事業者と顧客双方の責任範囲を明確にすることで、リスクをコントロールすることが可能になります。 規約違反や不正利用への対策をしっかりとする また、サービスの利用方法に問題のあるユーザーが存在する場合や反社会的勢力などと関係のある組織、個人の利用が発覚した際に、規約に従ってそういった不安因子を排除することができます。また、そういった体制を規約に明記することで、ユーザーにとっても、安心感を与えることに繋がります。 SaaSの利用規約に入れておくことが望ましい条項 サービスの変更に関する条項 SaaSはサービスをリリースした後も継続的にアップデートや機能追加を行うケースが多いかと思います。そのため、サービスの追加、変更、停止などに関して事業者側の裁量で行えるようにしておくと良いでしょう。この条項が欠けてしまうと、サービス変更などでユーザーに不都合が生じた場合にトラブルに発展する恐れがあります。 単なる機能の追加（ユーザーにデメリットのない変更）や軽微な修正（誤字の修正やデザインの変更など）については事業者側の裁量で問題ありませんが、サービスの停止などの重要な変更は事前に通知を行うことが望ましいです。また、緊急の変更であれば事後通知でも可とする内容があればさらに良いでしょう。 利用規約の変更に関する条項 サービスの変更だけでなく規約の変更も自社の裁量で行えるようにしたほうが良いでしょう。ただし、裁量で変更ができると言っても事前の通知は必要です。ユーザーの知らないところで規約の変更を重ねることは不信感にも繋がりますし、同意取得が十分になされない可能性もあります。 ユーザーに対する通知方法に関する条項 サービスの変更、規約の変更について定めた上で、それをユーザーにどのように通知するのかを明確にしておくことをお勧めします。通知について規定する際には、顧客がどの時点で通知を受領したとするかを明確に定めておく必要があります。 例えばメールで通知を行って、そのメールが迷惑メールに入っていた場合に、方法のみを規定していて受領時点を明らかにしていなかった場合、通知は無効と主張する余地を与えてしまうことになります。事前に「メールの送信が行われた時点を受領とみなす」という文言が規約内で提示されていれば、こういった認識の齟齬によるトラブルを回避できるので、通知の手段だけでなく、それがいつ有効になるのかについてもしっかりと定めておくことが重要です。 データプライバシーとセキュリティに関する条項 SaaSを提供する場合、事業者はユーザーの個人情報やそれに関連する情報を収集・活用する場面があるかと思います。そのような前提において、ユーザーのプライバシーや権利を保護するための措置を明記することが一般的です。例えば、個人情報の収集とその利用について、情報のセキュリティや保管方法、第三者との情報共有に関して規定することがあります。これらの条項は自社で用意しているプライバシーポリシーとの整合性も考える必要があります。 また、個人情報の取り扱いに関するルールや法規制は国によっても異なるので、海外のユーザーの利用が想定される場合には、対象となる地域の基準を遵守した情報の収集・活用が求められます。国内のみを想定している場合でも、海外のユーザーが利用した場合にはその地域の基準での取り扱いを求められるので、そういった不測の自体が起こらないように、事前に国際水準の規定にしておく、もしくは国外からのアクセスができないようにするなどの対策が必要です。違反した場合のペナルティが事業の運営にも大きく影響する場合があるので、事前に入念に調べた上で定める必要があります。これらはかなり専門的な内容になるので自社で判断せずに専門家の知見やアドバイスを受けながら策定する必要があります。 ユーザーの責任、および禁止事項に関する条項 ユーザーの責任にはアカウントやID、パスワードの管理や第三者利用の禁止、利用環境の整備などが含まれます。SaaSの中にはAPIを使用して外部のサービスとの連携が可能な場合もあるので、そういった第三者サービスの使用に際しての自己責任を規定するものもあると良いでしょう。 禁止事項にはサービスを利用する上で起こりうる不正を網羅的に記載しておくことが求められます。それだけでなく、それらが発生した場合に契約の解除やそれに伴う違約金の請求、アカウントの停止、損害が生じた場合には損害賠償請求などができる建て付けになっていることが望ましいです。 請求、キャンセル、および返金ポリシーに関する条項 支払いや請求などのお金周りの取り扱いについてもしっかりと利用規約内で定めておきましょう。支払い方法や支払い時の手数料の負担者や日割りの有無など基本的な内容の他に、SaaSではサブスクリプションを採用するケースも多いのでその場合は自動引き落としに関する記載もつけておくと良いでしょう。 未払い時の対応やキャンセル、契約終了時の返金などのイレギュラーに関する規定も必要です。遅延損害金の発生や未払い時の契約解除について定めておくことで、未払いへの抑止として働く側面もあります。また、返金については日割りを採用しないのであれば基本的に不要かと思いますが、例えばサービス開始から短期間で解約した場合の返金や、1年分のまとめ払いなど残存期間が発生するケースには返金規定を設けておく方がユーザーにとっては親切な設計になります。 一般的な条項 一般的なWebサービスの利用規約やその他の契約にも記載される条項についてはなるべく記載するようにしましょう。もちろん、サービスに不要なケースもありますが、他の規約との矛盾やサービスの邪魔にならない範囲であれば、削除せずに残しておいても良いでしょう。後に必要になるかもしれませんし、使わないだけである分には問題はないので、ないよりはあった方が不測の事態に備えることができます。 また、損害賠償やアカウントの削除などは問題になりやすい箇所なので細かくチェックしましょう。これらの条項を適当にしてしまうと、問題が生じた際に会社に多大な損害を生じさせる可能性も考えられます。 サービスの特性に合わせた条項 一般的な条項だけでなく、サービスに合わせた内容も記載するようにしましょう。類似サービスを参考にするとどんな項目が必要なのか見えてきます。 たとえば労務系のSaaSであればマイナンバーに関する取り決めを規約内で定めていたり、電子契約系のSaaSはやりとりされる契約の内容について関与しないなどの立場を宣言していたりします。SaaSによって提供されるサービスによって変わるので、自社のサービスの特徴や機能の詳細を明らかにした上で、弁護士などの専門家にアドバイスをもらうと良いでしょう。 特約 もし、サービスのアップデートを続けていく中で、既存の規約では不十分になってしまった場合やアカウントごとに扱いが異なるような場合には特約のような形で、規約とは別に項目を設置する形が良いでしょう。基本的なルールについては規約の内容を適用し、部分的に特約を優先して適用することで、このようなケースに対応することができます。 そのためにあらかじめ規約内で「矛盾が生じた場合は特約を優先する」といった旨の記載が必要です。そうすることで相反する内容だとしてもサービスやプランに応じて対応を分けることができます。よくある例として、無料版と有料版での差異を特約などの形で設けることがあります。 SLAについて SLAはサービスレベルアグリーメントの略で、サービスの動作保証を記載したものになります。SLAは規約外に別途で定めることもありますが、不具合時の返金対応などを規約に記載する場合の参照先として規約内にリンクを設けることもあります。 「SLAを満たさなかった場合、不具合発生月の翌月末に利用料の何％を返金いたします」のように、不具合発生時の補償の対象を明らかにするための基準に当たります。不具合発生の有無が数値で表現されるため、顧客にとってもサービスの安定性や補償の請求判断が容易になるため、信用を得ることにもつながります。 SLAでは主に下記の内容について記載することが一般的です。規約内に落とし込む形でも問題はありません。 サービスの可用性に関する規定 サポートサービスに関する規定 サービスレベル目標の設定 利用者によるサービス利用の制限 サービス提供者の免責事項 1.サービスの可用性に関する規定  サービス利用の開始・終了時刻、システムメンテナンスなどに伴うサービス停止時期がある場合は明確に記載し、通知方法や通知時期についても合わせて記載することが望ましいです。また、災害発生時のシステム復旧／サポート体制、早期復旧が不可能な場合の代替措置などの障害が発生した際の対応や問い合わせ先なども記載することが望ましいでしょう。 アップグレード方針として頻度や事前通知方法、履歴管理、公開、利用者の負担についても明示すると良いでしょう。 2. サポートサービスに関する規定  お客様からの問い合わせに対して、どのような対応が行われるかについて記載します。オンラインでのサポート、メールや電話での対応、また返信までの時間の目安などを明示することが一般的です。 3. サービスレベル目標の設定  「99.9%の可用性を維持する」など、サービスレベル目標を設定することで、顧客に対して提供するサービスの品質を保証することができます。サービスの稼働率は「(計画サービス時間－停止時間)÷計画サービス時間」で表されます。また、サービス提供者が定めた目標に達成できない場合、その理由やユーザーの権利や補償措置についても記載することが重要です。 4. 利用者によるサービス利用の制限  サービス利用に関して、使用内容、回数、容量、期間などに上限がある場合は、その規定を明確に記載します。また、違反行為に対する罰則についても明示することが一般的です。 5. サービス提供者の免責事項  サービス停止やデータの紛失の原因がサービス提供者ではない場合、またはユーザーの違反行為によって生じた損害や不利益については、サービス提供者が免責されることがあります。その際、免責される範囲を明確に定めることによって、顧客の理解を促進することができます。 規約作成時の注意点 サービスの詳細を把握している人を巻き込む SaaSの規約を作成する際はプロダクトオーナーなど、サービスの全体像を把握している人を巻き込むようにしましょう。サービスの中身を知らない法務担当が作った規約ではサービスの細かい仕様との齟齬が生じて、実際にサービスをリリースしてから問題が発生するということも考えられます。 そのため、細かくサービス内容や契約の流れ、各種用語の定義、利用のルールや懸念事項などを吸い上げた上で作成するようにしましょう。規約の変更を自社の裁量で行えるようにしても、あまりにも変更が多いとなると顧客側の不信感に繋がる恐れがあります。 足枷にならないような建て付けを意識する パッケージ型のソフトウェアであれば、規約作成時点で完成形が見えているため、それにあわせたものを作成すれば問題はありません。しかし、SaaSの場合、もちろん事前にある程度の方針は決まっていても、それが必ずしもその通りにいくわけでなく、サービスを提供しながら方針やサービス内容が変化していく可能性が十分にあります。 前述の通りSaaSは変更を前提とした提供体制なので、その変更を行う際に規約が邪魔をするということはなるべく避けたいです。そのためにもプロダクトオーナーなどと綿密に打合せを行い将来的なサービスの展開や機能のイメージを早い段階で共有することが重要です。規約自体の変更はしやすい建て付けにするのが大前提ですが、細かい変更を重ねていると改訂履歴が多くなってしまい、サービスの不安定さを感じさせてしまうこともあります。 定義は明確にする 規約内に登場する用語の定義はわかりやすく明確にしましょう。用語に対する認識の齟齬によって顧客とトラブルになることも十分に考えられます。事業者側の目線では当然だと思うことも、一度顧客目線に立った時に認識違いが起きないかをじっくりと考えてみると良いでしょう。 例えば「会員」「ユーザー」など一見したら同一に思えるような表現には特に注意が必要です。また、そのサービス独自の表現などにも注意が必要です。 なるべくわかりやすい用語を用いることも重要です。規約内に登場する用語が複雑だと、規約の理解の妨げになる恐れもあります。 個別契約は極力避ける 提供するサービスがどういったサービスなのかにもよりますが、基本的には個別で契約を結ぶような契約フローにはしないことをお勧めします。 個別契約にすることで、各企業との契約内容の交渉に応じたり、それを検討する手間が発生します。また、契約書に変更が生じた場合に、それぞれの顧客に対して通知を行なったり、変更の打診を行う必要が出てくるので、サービスの成長にブレーキをかけてしまうことにもなりかねません。契約企業の数が少なければ問題ありませんが、多数の顧客と毎回契約を結ぶのは非常に大変です。その契約で大きなリターンを期待できる顧客であれば個別契約もやむなしですが、前述の手間と得られるリターンのバランスを慎重に考える必要があります。 基本的には個別契約は行わないというスタンスを貫くことが重要です。 規約と別に用意するもの 料金表 料金表などは改訂が見込まれる箇所なので、規約内に設けずに別途定めておく方が良いでしょう。料金や支払いに関する条項内に「料金表を参照」のような表現で記載しておくと良いかと思います。プランが増えたり、金額が変わるたびに規約も修正が必要となると機動力が落ちてしまいます。 なお、金額の変更などは事前に通知をし、相当の猶予期間を設けた上で実施するようにしましょう。 サービスマニュアル サービスマニュアルも外部に作成したものをリンクでおく形が良いです。変更や追加などが見込まれるので、規約内で細かく機能ごとの解説や使用方法を明記するのは現実的ではありません。その際に、サービスマニュアルやWebページの記載も規約と同様に顧客が遵守するものとして位置付けておくことをお勧めします。 【まとめ】SaaSの利用規約は作って終わりじゃなくて継続的に見直しが必要！ SaaSの利用規約は作って終わりではなく、サービスの成長と共に定期的に見直す必要があります。そのため、サービスの成長や変更に合わせて規約の見直しが必要ということを法務部門だけでなく、ビジネスサイドや開発サイドにも浸透させておくことが重要です。機動力を重視するあまりに法務担当に適切なタイミングで相談されずに、気づいたら規約と実際のサービスの内容が噛み合わない、というような状況になってしまうとトラブルのタネになります。 利用規約は契約書と同様に法的拘束力を持ちますが、表現や内容によっては法的に無効とされる場合があるので、作成の際には専門知識を有する弁護士に相談しながら作成することをお勧めします。 E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 また、ブログやE-bookで扱って欲しいSaaSに関するトピックやSaaSus Platformについてもっと知りたいことなどへのリクエストを広く募集しています。コンテンツに関する要望や感想がございましたら、こちらからぜひお寄せください。 --- ## SaaSとは？意味や特徴をわかりやすく解説！ URL: https://saasus.io/blog/whats-saas Date: 2023-05-19 近年、目にすることが増えた「SaaS」という言葉ですが、まだまだ認知や理解などが浸透していないように感じます。SaaSはその利用者だけでなく、現在別形態でサービスを提供している事業者にとっても注目度が高く、今後自社サービスをSaaS化するといったケースも増えてくるかと思います。この記事では、SaaSの意味や特徴など初歩的な内容を解説していきます。 SaaSとは 近年、目にすることが増えた「SaaS」ですが、まだまだ認知や理解などが浸透していないように感じます。 そもそも、SaaSとは、Software as a Service（ソフトウェア・アズ・ア・サービス）の略であり、インターネットを介して提供されるソフトウェアの利用形態の一つです。自社内にソフトウェアを導入する必要がなく、インターネットに接続し、必要なソフトウェアを使用することができます。このようなビジネスモデルは、導入コストを抑えることができ、利用者にとって柔軟性があります。 SaaSはその利用者だけでなく、現在別形態でサービスを提供している事業者にとっても注目度が高く、今後自社サービスをSaaS化するといったケースも増えてくるかと思います。 読み方 SaaSは「サース」または「サーズ」と読みます。 一般的には「サース」と発音する場合が多いですが、「サーズ」でも間違いではありません。 意味・定義 先にも述べたように、SaaSはSoftware as a Serviceの略称です。直訳すると「サービスとしてのソフトウェア」を意味します。 クラウドサーバー上のソフトウェアを、インターネットを経由して提供するサービスで、従来のパッケージソフトと異なり、パソコンにソフトウェアをインストールする必要はありません。SaaSにおいてはソフトウェアを利用する際に購入ではなく利用料を支払う形で費用が発生します。つまり「サービスとしてのソフトウェア」とは、ソフトウェアの価値を「もの」ではなく「サービス」の形で提供することを意味します。 一般的に、顧客は、月額固定料金または利用量に応じた従量課金の方法でサービスを利用します。SaaSを導入する目的には、業務プロセスの自動化、生産性の向上、コスト削減などがあげられます。 SaaSの歴史 クラウドサーバー上のソフトウェアをインターネット経由で利用するのがSaaSですが、どのような経緯で誕生したのか簡単に説明します。 まず、SaaSを利用するのに不可欠なインターネットの誕生が1960年代後半と言われています。そこから、数十年後、1990年代になってSaaSの先駆けであるASPが誕生しますが、機能的な制限や当時の技術的な課題もあり徐々に下火になっていきました。そんな中、1990年代後半になって、Webブラウザの一般的な利用が始まる頃にSaaSという在り方が見出され始めました。その他にも、インターネット接続環境の向上や技術進歩による操作性の向上などにより徐々に必要な要素が整備されていきました。 アメリカなどでは2000年代中盤頃からSaaSという言葉が広く使われ始めました。日本でも2000年代後半にかけてSaaSの注目度は上がっており、それから企業におけるDXの機運が高まるとともにSaaSへの関心も高まりました。2018年はSaaS元年と言われ、広く知られるようになりました。 当初は、メールやカレンダー、連絡先管理などのビジネスアプリケーションがSaaSとして提供されていましたが、現在では、財務会計、マーケティング、人材管理、eコマースなどの様々な業務領域でSaaSが利用されています。 SaaSの種類 SaaSにはバーティカルSaaSとホリゾンタルSaaSの二つの種類が存在します。 バーティカルSaaSは「業界特化型SaaS」と言われ、特定の業種や業界での利用を想定したものを指します。例えば、医療機関向けの電子カルテや、人事管理ソリューションなどがあります。 ホリゾンタルSaaSは「業務特化型SaaS」と言われ、例えば総務や経理などどの企業においても活用が見込まれる業務での利用を想定したものを指します。例えば、会計クラウドサービスや人事クラウドサービスなどがあります。 業界問わず使えるため、ホリゾンタルSaaSの方が市場規模は大きくなる傾向にあります。 SaaSの市場規模について ここで市場規模の話が出てきましたが、SaaSがなぜ今注目されているのかは、市場規模の拡大の様相を見ると一目瞭然です。『富士キメラ総研「ソフトウェア新市場2020年版」2019年度実績』によると、日本ではSaaSの市場規模は年13％の勢いで急成長を遂げており、2019年の時点では約6000億円だったものが5年後の2024年には約1兆1200億円に到達する見込みです。 SaaS市場の拡大は日本のみならず、世界規模で伸びており、Fortune Business Insightsのレポートによると、2021年の世界市場規模は2,151億ドルと評価されています。2029年までには、8,833億4000万ドルに成長すると予測もされています。 急速に拡大するSaaS市場。日本だけでなく、世界の動きにも注目が必要です。 SaaSの代表例 テレワークが増えたこともSaaSの広がりを後押しした要因と言えるでしょう。テレワークをより効率的に実施するために、企業ではさまざまなSaaSの導入が進められています。 では、SaaSには具体的にどのようなものがあるのでしょうか？代表的なSaaSを紹介します。新しくSaaSを考えるときには、既にあるサービスも調査し、他社の強みがあるサービスを企画するようにしましょう。 ①会計SaaS 会計ソフトは、売上や仕入れ、給与などの帳簿や請求書の発行などの業務をデジタル管理で経理業務の効率化や業務の見える化を目指すサービスです。経費精算や請求書の自動作成などの機能もあり、手作業での業務時間を削減することができます。家庭でも使える家計簿サービスもあります。開発の際には、法改正の対応も必須です。 freee 楽々会計 マネーフォワード会計 Zaim Biz ②勤怠管理SaaS 勤怠管理サービスは、オンラインで社員の勤務時間を効率的に管理するサービスです。勤務時間や残業時間だけでなく、休暇や給与計算なども自動化され、経理業務の効率化に貢献しています。 SmartHR 楽楽勤怠 HReasily KING OF TIME ③チャットSaaS チャットツールは、社内や外部とのコミュニケーションを円滑に行うためのサービスです。チャットやビデオ通話、ファイル共有などの機能もついていることがほとんどです。テレワークやリモートワークの普及により利用者が増えました。複数の人とのコミュニケーションを簡単に行うことができるため、業務の効率化やコミュニケーションの改善に貢献しています。 Slack Microsoft Teams Chatwork ④オンラインストレージSaaS ストレージとは、データをインターネット上に保存するためのサービスです。ストレージは、複数人での共有ができるため、チーム内での情報共有やファイルの管理に利用されます。また、外出先でもスマートフォンやタブレットからアクセスすることができるため、業務の効率化やリモートワークにも対応できます。 Dropbox Google Drive Microsoft OneDrive Amazon S3 ⑤Web会議SaaS Web会議SaaSとは、遠隔地にいる人たちとビデオ通話や音声通話で会議をするためのサービスです。Web会議SaaSSaaSは、場所や時間に関係なく参加できるため、リモートワークや海外とのビジネスでも活用されます。また、画面共有やチャット機能、ホワイトボード機能が備わっていることも多く、それらは業務の効率化に役立っています。 Zoom Microsoft Teams Google Meet 類似するクラウドサービスについて そもそもクラウドサービスとはなんなのか？という方やSaaSと何が違うのか？と混乱している人もいるかもしれませんので、まずは簡単にクラウドサービスについて説明します。 クラウドサービスとは、インターネットを通じてストレージ、ネットワーク、サーバー、データベースなどのITサービスを利用する技術や仕組みを指します。所説ありますが、クラウドは顔の見えないインターネットの世界を雲の向こう側のサービスに例えたことから呼ばれるようになったとも言われています。 クラウドサービスとSaaSの違いは、サービス内容の範囲にあります。ソフトウェアを提供するSaaSと比べ、クラウドサービスはインターネットを通じて提供される全てのサービスと広義な範囲のサービスを意味しています。つまり、SaaSもクラウドサービスの一種と言えます。 前述の通り、SaaSをはじめとするクラウドを経由して提供されるサービスをクラウドサービスと言います。クラウドサービスには他にも、SaaSと共通する「◯aaS」を含む用語のPaaSとIaaSや機能面でSaaSと類似するASPなどがあります。それぞれSaaSと混同されやすい単語ですので、その3つについて簡単にご説明します。 PaaS PaaSはPlatform as a Serviceの略で「パース」と読みます。 アプリケーションソフトが稼働するためプラットフォーム一式が提供されるサービスのことを指します。開発において、PaaSを利用した場合、用意するのはプログラムだけとなります。しかし、データベースの設定などをはじめとするプログラムの実行環境が制限されるので、自由度という点ではやや物足りない場合があります。インフラから開発する時間や労力を軽減したいけれども、ある程度柔軟にカスタマイズしたいという場合に有用です。 IaaS IaaSはInfrastructure as a Serviceの略で「イアース」「アイアース」と読みます。IaaSはクラウド上のネットワークやサーバ（CPU・メモリ・ストレージ）などのコンピューティングリソースを提供するサービスです。リソース構成を自由に選択して利用することができ、その上に任意のアプリケーションを構築できます。IaaSを利用することで、ユーザーはインフラを所有する必要がなく、コストを抑えることができます。 SaaSやPaaSなどと違って自由度が高く、ハードウェアのスペックやOSを好きなように選べます。その分、セキュリティ対策についても考慮する必要があるなど時間や労力も多くかかることになります。 ASPとの違い ◯aaSの形ではありませんがSaaSとよく似た存在としてASPがあげられます。ASPはApplication Service Providerの略で、インターネット上で利用できるアプリケーションを提供する事業者を指す言葉ですが、サービス事態をASPと呼ぶこともあります。 サービスをインターネットを介して利用するという点ではSaaSとASPの根本的には同質のものと言えますが、ASPが発展した形としてSaaSがイメージされることもあります。ASPが生まれた当初は、安価で安定したインターネット回線が構築されていなかったことやセキュリティ面での課題が多く、なかなか普及には至りませんでした。その後、技術革新が進み、それらの問題が改善されたことで、SaaSという形に移行していきました。 SaaSとASPの大きな違いをあげるとするとSaaSはマルチテナントと言って、複数のユーザーが同じサーバーやアプリケーション、データベースといったシステムやサービスを共有して利用する方式です。対するASPはユーザーごとに専用の環境を用意する形になります。 この管理の違いから、SaaSでは変更を複数のユーザーに同時に施すことが可能であり、変更や機能の追加などが容易で変更を加えながらサービスを提供していくことが可能で、対するASPはサービス開始の時点である程度完成形で提供されるという差異が生じました。 もちろん現在でもASPは存在しており、ユーザー数が少ない場合やマルチテナントでの環境の共有を忌避するケースでは有用です。SaaSかASPかという選択はあくまでも用途や規模感の違いによって判断されるに過ぎません。 SaaSビジネスのコツ SaaSビジネスにおいて、独自のナレッジも必要です。より実践的な、SaaSビジネスのコツをまとめました。 ①販売方法 SaaSのビジネスモデルは大勢の営業チームを作らず、インターネット上で契約終了まで完了することが一般的です。なので、営業マンに依存しない販売方法を考える必要があります。例として、一部サービスは無料で使える、トライアル期間を設けるなど、実際に利用してもらい契約を検討してもらう方法があります。 ②継続的なアップデート サービスを開始したら終わりではありません。継続して利用してもらうためにも、利用者の声に耳を傾け、定期的なアップデートが必要です。また、収益増加を見込むならオプション機能の開発も行った方が良いでしょう。 ③カスタマーサポートの整備 サービスを開始したら、カスタマーサポートの体制を整えなければなりません。カスタマーサポートは利用者の不明点を解決するだけではなく、使い方がわからないことによる解約を防ぐためにも重要です。 また、丁寧なサポートは利用者の好感度をあげ、継続利用だけではなく、他者へのおすすめなど利用者数増加のきっかけにもつながります。 ④セキュリティ対策の徹底 SaaSは、クラウド上で提供されるため、セキュリティ対策が非常に重要です。顧客データの漏洩や不正アクセスが発生した場合、信頼を失い、サービス提供を継続することが難しくなる可能性があります。セキュリティに対する取り組みを徹底し、適切な対策を行いましょう。 ⑤コスト管理 SaaSを提供する場合、サービス提供・維持に必要なコストが多くかかることがあります。そのため、コスト管理を徹底し、収益性を確保することが重要です。開発前に、コストを見積もり、収益性の高いビジネスモデルを確立するようにしましょう まとめ　なぜ今SaaSなのか？ SaaSについて基本的な内容が分かったところで、最後になぜ今SaaSビジネスが拡大しつつあるのかを説明します。 まず第一にインターネット技術をはじめとするIT全般技術の発展があげられます。中でもクラウド技術の浸透や発展などにより手軽になったことは大きな要因の一つです。前述のASPにおける技術的な課題をSaaSという形でクリアできるようになったのです。 また、サブスクリプションという形態が普及したこともまたSaaSの急成長を後押ししていると言えます。これまでものを所有するという形が一般的であったのに対して、サービスを利用するという形が一般的にも浸透したことで、SaaSにおけるサブスクリプションというビジネスモデルが受け入れられ易くなったと言えます。ユーザーは必要な時に必要な分だけ利用することができるため、導入の手軽さ、コスト削減の面からもSaaSは求められるようになりました。 そして、ユーザーニーズの多様化という点もSaaSが注目される要因です。これまで、作って売ってで完結していたものが、ニーズの多様化によってそれだけでは顧客を十分に満足させることが難しくなってきました。SaaSはニーズに合わせてサービス内容を変えていける点で、従来のパッケージ製品よりも顧客の満足度を高めることが可能になりました。それだけでなく、サービスを提供する企業側もそれによって継続利用の利益や、ニーズにそぐわない製品を作って損失を生むと言ったリスクを回避できるため、その柔軟性とスピード感が顧客と提供事業者の双方にとって都合が良いのです。 昨今のリモートワークの普及などもSaaSビジネスへの追い風になっていることもあり、今後、あらゆるソフトウェアがSaaSとして提供されていくことが見込まれます。SaaSは顧客だけでなく提供事業者にとってもメリットが多いですが、まだまだ自社で1からSaaSを開発し、提供することは技術的、構造的な課題や困難が多いことも確かです。 --- ## 国内・海外のSaaS関連展示会・カンファレンスまとめ2023 URL: https://saasus.io/blog/saas-event-list Date: 2023-05-17 国内外で行われるSaaS関連の展示会やカンファレンスについてまとめました。 展示会の参加はマーケティング施策としてではなく、トレンドを知ることや競合サービスを知ることもでき勉強の場としても有益です。興味のあるイベントは見逃さないようにしましょう。 また、展示会・カンファレンス出展のメリットデメリットもまとめました。参加や出展を迷ってる方は参考にしてみてください。 国内SaaS関連イベント ※2023年4月現在の情報となります。 Digital Business Days SaaS EXPO Digital Business Days SaaS EXPOは、SaaS（Software as a Service）を中心としたビジネスイベントです。経営企画・総務・財務経理・営業・マーケティング領域等で自業務におけるITツールの導入、 SaaS 活用を検討している方、業務改革を推進したい方がターゲットとなっており、クラウドベースのソフトウェアやサービス、ビジネスアプリケーションなどを提供する企業の方の出展がおすすめです。オンライン開催のため、全国の参加者と出会えるのも魅力です。 2023年は冬(終了)と夏に開催。冬のイベントでは、元テレビ東京プロデューサーの佐久間宣行氏やTURING株式会社CEOの山本一成氏の特別講演が行われました。 夏 https://promotion.itmedia.co.jp/lp/dbdsaasexpo2023summer 冬 https://enq.itmedia.co.jp/on24u/form/saas2023w 開催日 / 開催場所 2023年8月22日(火)～9月10日(月) / オンライン 出展・展示企業 夏： 募集中 冬：マネーフォワードｉ株式会社、GMOグローバルサイン・ホールディングス株式会社、株式会社NTTデータ・ビズインテグラル…など 登壇者 夏 未定 冬 重松 裕三 氏(株式会社SmartHR)、小暮 剛史 氏(株式会社セールスフォース・ジャパン)…など 主催 アイティメディア株式会社 Japan IT Week (クラウド業務改革EXPO) Japan IT Weekは、クラウド製品の他にもAIやメタバースなど、最新のIT製品・サービスが一堂に集まる、日本最大のIT展示会です。東京だけでなく、オンライン、関西などでも開催されます。2023年春には4万名以上が来場しました。 デモを見て気になれば、そのまま商談もできるブースが準備され、見積りや導入時期など、その場で打合せが可能です。導入意欲の高い方の参加が見込まれます。 過去の展示会の様子や今後の情報はtwitterで#JapanITWeekで検索することができます。 Twitter https://twitter.com/JapanITWeek 開催日 / 開催場所 2023年4月5日(水)～4月7日(金) / 東京ビックサイト 2023年6月7日(水)～6月9日(金) / オンライン 2023年7月19日(水)～7月21日(金) / ポートメッセなごや 2023年10月25日(水)～10月27日(金) / 幕張メッセ 2024年1月17日(水)～1月19日(金) / インテックス大阪　　　　　　　　 出展・展示企業 株式会社NTTデータ、業務改善クラウド株式会社、サイボウズ株式会社、Sansan株式会社…など 登壇者 池照 直樹一氏(株式会社カインズ)、澤 円氏(株式会社圓窓)、河本 薫氏(滋賀大学データサイエンス学部　教授 )…など ※2023年春開催時 主催 RX Japan株式会社 BOXIL EXPO 2023年のBOXIL EXPOは、東京でIT・DX展(11月)、人事・総務・法務展、財務・経理展、営業・マーケティング展がオンライン(3月、9月)が開催されます。オンラインでも開催され、出展しやすい展示会です。主催のスマートキャンプ株式会社は、SaaS 比較サイト『BOXIL SaaS』もてがけており、SaaSに強い企業です。 また、オンライン展示会のコツのセミナーも開催しています。出展サポートも手厚く、開催後には振り返り面談で次回施策検討のヒントも共有してるそう。 オンライン展示会がなかなかうまく結果に結びついていない方は、セミナーを受けてから参加してみてはいかがでしょうか？ 開催日 / 開催場所 2023年11月21日(火)～11月22日(水) / パシフィコ横浜 2023年3月、9月 / オンライン　　　　　　　　 出展・展示企業 株式会社ユーザベース、コミューン株式会社、株式会社アール・アンド・エー・シー…など 登壇者 髙田 明 氏(株式会社 A and Live)、フィリップ・コトラー 氏(ノースウエスタン大学 ケロッグビジネススクール教授)、伊藤 邦雄 氏(一橋大学 CFO教育研究センター長 )…など　※過去登壇者 主催 スマートキャンプ株式会社 デジタル化・DX推進展 デジタル化・DX推進展は、デジタル化を推進したい自治体と、テレワーク・在宅勤務を常態化させ、新たなセールス方式を構築し、新しいオフィス環境を整備したい企業に向けたBtoB展示会です。講演では、地方自治体特別講演もあり、地方でのDX促進事例を知ることができます。地方のIT、DX促進に興味のある企業におすすめの展示会です。 https://odex-telex.jp/lp/ 開催日 / 開催場所 2023年5月25日(木)～5月26日(金) / 東京ビックサイト 2023年6月5日(月)～6月9日(金) / オンライン 2023年11月1日(水)～11月2日(木) / インテックス大阪　　　　　 出展・展示 株式会社ギフティ、グーグル・クラウド・ジャパン 合同会社、さくらインターネット株式会社…など 登壇者 吉原 優貴氏(経済産業省 商務情報政策局 情報技術利用促進課 課長補佐)、長尾 飛鳥氏(岐阜県下呂市役所 まちづくり推進部デジタル課 主査)、完山 祐司 氏(エコノス株式会社)…など 主催 株式会社イノベント  デジタル化・DX推進展 実行委員会 管理部門ITソリューション総合展(通称バックオフィスDXPO) 管理部門向けの業務改革・生産性向上を支援するソリューション・サービスを一堂に集めた展示会です。テレワーク支援、人事システム、電子契約などバックオフィスに関するサービスなどがあります。東京・大阪・福岡で開催されています。 リアル展とオンライン展のハイブリット展示会となっており、オンライン展は365日開催、リアル展の開催前1ヶ月、開催後2ヶ月はオンライン展でも集中的にマッチングすることで「見込客獲得の量」と「商談の質」を高めつつ、かつ年間を通じて継続的なマッチングの機会を提供する新サービスとなっています。 Twitter https://twitter.com/fox_box_dxpo 開催日 / 開催場所 2023年3月14日(火)～3月15日(水) / インテックス大阪 2023年8月22日(火)～8月23日(水) / 東京ビックサイト 2023年10月10日(火)～10月11日(水) / 東京マリンメッセ福岡 出展・展示 Chatwork株式会社、株式会社クロスユーアイエス、応研株式会社…など　 登壇者 石崎 真弓氏(株式会社ザイマックス不動産総合研究所)、齋藤 敦子氏(コクヨ株式会社)、湯田 健一郎氏(株式会社パソナ)…など ※東京開催時 主催 ブティックス株式会社 DX EXPO 人事、総務、経理などのＤＸ化を考えてる方向けの業務効率化・働き方改革・経営基盤強化に関するDXソリューションが集う展示会。後援に総務省、デジタル庁・総務省・東京都などが入っています。約750種類出展があり、日本最大級のDX総合展です。 アンケートによると、来場者の76%が導入権限に関与し、54%が課長クラスとなっており、導入意欲の高い来場者が見込まれます。また、来場者データをリアルタイムで蓄積しており、そのデータを元に来場者フォローがしやすいのもこのEXPOの魅力です。 Twitter https://twitter.com/dx_expo 開催日 / 開催場所 2023年2月6日(火)～2月8日(木) / 東京ビックサイト、オンライン 2023年3月7日(火)～3月9日(木) / 大阪ATCホール、オンライン 2023年7月11日(火)～7月13日(木) / 東京ビックサイト、オンライン 2023年12月13日(水)～7月15日(金) / 大阪ATCホール、オンライン　　　　　　　　　 出展・展示 ブレインズテクノロジー株式会社、スターティアレイズ株式会社、株式会社東海理化…など ※東京春開催 登壇者 福田 譲氏(富士通株式会社)、藤崎 忍氏(株式会社ドムドムフードサービス)、佐藤 雅志氏(サッポロホールディングス株式会社)…など ※東京春開催時 主催 DX EXPO、経営支援EXPO、ニューノーマル ワークスタイルEXPO実行委員会 SaaS Design Conference SaaS Design Conferenceは、BtoBサービスのデザインに興味のある方、SaaS事業に興味のあるデザイナー、スタートアップや事業会社のデザインに挑戦したい方向けのカンファレンスです。業界独自の課題、デザイナーがユーザーの利用シーンを理解しにくいなどの課題に対し、SaaS業界の第一線で働くデザイナーの方々が工夫や想いを語ります。 twitterで#SaaSデザインでイベントの様子や感想を見ることができます。 開催日 / 開催場所 2022年11月26日(土) / オンライン 登壇者 山下 祐樹氏(Figma，Inc. )、國光 俊樹氏(株式会社グッドパッチ)、望月 勇輔氏(ウォンテッドリー株式会社)、杉江 美祥氏(株式会社リンクアンドモチベーション)…など 主催 Uzabase SaaS Design Division "DESIGN BASE"、株式会社ユーザベース、株式会社ニューズピックス ALL STAR SAAS CONFERENCE【開催未定】 ALL STAR SAAS CONFERENCEは、SaaSに特化したVCファンドALL STAR SAAS FUNDが主催。2016年から開始し、2022年で7回目を迎えたカンファレンス。SaaS業界のプロフェッショナルを国内外から招き、彼らの知識、実際に実践している戦略やアイデアなどを学ぶことができます。SaaS起業家、SaaS経営者、SaaS企業で働く方など、SaaS事業に携わる全ての方向けのカンファレンスです。 過去の参加者の声では「開始してからずっとメモとスクショが止まらない。100本ノックを受けてる気分」「SaaS先駆者の皆様から、非常に実践的な情報を共有していただけた。」などよせられています。 開催日 / 開催場所 ※2023年度開催未定 登壇者 Nate Forster氏(Mochary Method)、佐渡島 隆平氏(セーフィー株式会社)、Frank Slootman氏(Snowflake)…など ※2022年度開催実績 主催 ALL STAR SAAS FUND AWS Summit Tokyo【終了】 Amazon Web Services（AWS）が主催する日本で最大規模のクラウドコンピューティング関連イベント。2023年は4年ぶりの開催となります。最新の技術に触れることができ、エンジニアの方なら見逃せないイベントです。エキスパートのエンジニアだけでなく、初心者向けのセッションもあり、クラウド導入を検討中の方、すでに導入されている経験者の方、ビジネス層の方、技術者の方などクラウドに興味がある人全員におすすめです。 参加者の様子はTwitterで#AWSSummitで検索してみましょう。5月22日〜6月23日までオンデマンド配信もあります。 Twitter https://twitter.com/awscloud_jp 開催日 / 開催場所 2023年4月20日(木)、21日(金) / 幕張メッセ、オンライン 出展・展示 株式会社サイバーエージェント、株式会社MIXI、株式会社リクルート…など 登壇者 高橋 誠氏(KDDI)、加藤 恭子氏(全日本空輸株式会社)、鈴木 洋史 氏(SAPジャパン株式会社)…など 主催 アマゾン ウェブ サービス Eight Networking EXPO【終了】 Eight Networking EXPOは、DXサービスをはじめ、業務改善につながるITサービスが集うイベントです。「ビジネスを加速する人脈づくりの場」と謳っており、ブースツアーやブース訪問予約など参加者と出展社を積極的につなげてくれるイベントとなっています。 1万人以上の参加者が見込まれ、150以上のサービス、50名以上の講演者とコンテンツが充実しています。 人事や経理などのバックオフィス系のサービスだけでなく、営業やマーケティング、カスタマーサービス、DX促進のフロントオフィスのサービスまで幅広く参加者が集ります。 5月2日(火)10:00〜5月15日(月)18:00までアーカイブ配信があります。 開催日 / 開催場所 2023年4月27日(木)～4月29日(土) / 東京ビックサイト 出展・展示 トビラシステムズ株式会社、株式会社Faber Company、株式会社ラクス、株式会社ラクロー…など 登壇者 落合陽一氏、三村真宗氏(株式会社コンカー)、板谷隆平氏(MNTSQ株式会社)…など 主催 Sansan株式会社 海外のSaaS関連イベント SaaStock SaaStockは、世界中のSaaS企業のリーダーや専門家、投資家が一堂に集まり、SaaS業界の最新のトピックスや動向、成功事例などについてのプレゼンテーションが行われるイベントです。ヨーロッパ、北米、アジアで開催され、「SaaS企業のディズニーランド」と呼ばれるほど。参加国は70ヵ国以上と世界中から数千人の参加者が集まります。世界で活躍するSaaS創業者が登壇し、400人以上の投資家も参加。ARR 1,000 万ドル以上を目指す SaaS 創業者を対象としたイベントとなっています。 Twitter https://twitter.com/SaaStock 開催日 / 開催場所 2023年5月31日(水)～6月2日(金) / テキサス州オースティン マリオット ダウンタウン、オンライン 2023年10月16日(月)～10月19日(木) / ダブリン、オンライン　　　　 登壇者 スコット・エルンスト氏(Drift)、スティービー・ケース氏(Vanta)、ジェイソン・コーエン氏(WP Engine)…など　※USA開催時 主催 SaaStock re:invent re:Inventは、Amazon Web Services（AWS）が主催する、世界最大規模のクラウドコンピューティングに関するカンファレンス。通常はラスベガスで毎年11月に開催され、数十万人の参加者が集まります。AWSが提供する各種サービスや新機能、成功事例、セキュリティなどについての発表やデモなどが紹介されます。AWSの世界規模の影響力やテクノロジーの進歩に対する関心の高さから、re:Inventは、クラウドコンピューティング業界にとって重要なイベントの一つとなっています。コミュニティもあり、AWSを利用する方必見のイベントです。2022年の様子もオンデマンドで見ることができます。 Twitter https://twitter.com/AWSreInvent 開催日 / 開催場所 202311月27日(月)～12月1日(金) / ネバダ州ラスベガス、オンライン　　 登壇者 アダム・セリプスキー氏(アマゾン ウェブ サービス)、ピーター・デサンティス氏(アマゾン ウェブ サービス)、スワミ・シバスブラマニアン氏(アマゾン ウェブ サービス)…など 主催 アマゾン ウェブ サービス SaaStr APAC【終了】 SaaS の経営者、創設者、起業家の世界最大のコミュニティであるSaaStrによるイベント。コミュニティの形成とナレッジの共有でSaaS市場を盛り上げることが目的です。アメリカやヨーロッパでも開催されています。既にサービスを立ち上げた人向けのイベントとなっており、イベント参加者の平均的な売上げは1～100万ドルとなっているそう。海外でのSaaSの動向を知りたい、今後拡大を考えている経営者向けのイベントとなっています。 YouTubeでも動画を配信しているので、是非チェックしてください。 Twitter https://twitter.com/saastr 開催日 / 開催場所 2023年2月23日(水)～2月23日(木) / シンガポール、オンライン　　　　 登壇者 アナント ヴィドゥル プリ氏(ベッセマー・ベンチャー・パートナーズ)、エイナット・ゲズ氏(パパイヤ・グローバル)、エド・レンタ氏(データブリック)…など　 主催 SaaStr 展示会やカンファレンスに参加・出展するメリットとデメリット メリット ①トレンドの把握 展示会やカンファレンスには、業界の最新のトレンドや技術動向を知ることができるセッションやセミナーが多数あります。自社の製品やサービスを改善し、競合他社との差別化を図るために、業界の最新情報をキャッチアップする良い機会です。 ②ビジネスチャンス  展示会やカンファレンスは、多くの同業者や関連企業が一堂に会する場であり、新しいビジネスパートナーや顧客との出会いの場として有用です。自社の製品やサービスを宣伝し、新たなビジネスチャンスを見つけることができます。 また、その場で契約してもらえるなど、スピーディに進められる場合もあります。 ③ブランド認知度の向上  展示会やカンファレンスに参加することで、自社の製品やサービスを展示し、多くの参加者に知ってもらうことで、ブランド認知度を向上させることができます。 また、自社の製品やサービスを宣伝するためのプロモーションの場として有効です。自社の製品やサービスを実際に使ってもらったり、その場で質問に答えることで、より顧客の興味を引きつけることができます。 デメリット ①費用対効果  展示会やカンファレンスに参加するには、参加費やブースの出展費、遠征する場合は旅費などがかかります。また、準備や物品の準備、スタッフの手配など、多くの時間とリソースを必要とします。来場者の印象に残るためにも自社の強みが伝わりやすい資料作りなどの準備が重要です。目標が達成できないと費用対効果が合わず、赤字になる可能性もあります。 ②競合他社の存在 同じ業界や類似サービスを提供する多くの競合他社が参加します。情報が多いため、埋もれてしまわないように自社の強みをきちんと伝え、他社との違いを理解してもらう必要があります。 ②契約完了までの期間 来場するのが決裁者とは限りません。一度社内に持ち帰り決裁者の確認が必要なため、すぐに契約にならない場合が多いです。すぐに契約に繋がらずとも、契約見込み度で整理するなど、アフターフォローが大切です。 まとめ 展示会やカンファレンスには参加することで得られるメリットもありますが、費用や時間・リソースの投入などのデメリットも考慮する必要があります。参加の際には、事前に目的や戦略を明確にし、効果的な参加計画を立てることが重要です。また、顧客獲得以外にも学びの場としても有効です。トレンド把握のためにも出展以外でも興味のあるものは積極的に参加してみてはいかかでしょうか。 ※海外のイベントは時差がありますのでお気をつけください。 E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 また、ブログやE-bookで扱って欲しいSaaSに関するトピックやSaaSus Platformについてもっと知りたいことなどへのリクエストを広く募集しています。コンテンツに関する要望や感想がございましたら、こちらからぜひお寄せください。 --- ## SaaSビジネスにおける重要KPIまとめ URL: https://saasus.io/blog/saas-important-kpi Date: 2023-04-14 この記事では、SaaSビジネスでよく使われるKPIをまとめて解説します。 SaaSは従来の買い切り型のソフトウェアと異なり、継続利用を前提としたサブスクリプションモデルを採用することが多いです。そのため、買い切り型とは異なるKPIが必要です。 また、サービス内容によっても必要なKPIは異なります。例えば、オプションの収益が多いのであれば、サブスクリプションの定額料金だけでなく、オプション費用も加味したKPIを立てる必要があり、定額料金が低価格であれば、収益の解約率がより重要なKPIとなるでしょう。KPIの目的を理解し、自社に必要なKPIを設定してください。 E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 また、ブログやE-bookで扱って欲しいSaaSに関するトピックやSaaSus Platformについてもっと知りたいことなどへのリクエストを広く募集しています。コンテンツに関する要望や感想がございましたら、こちらからぜひお寄せください。 顧客獲得と収益性に関する指標 収益性に関係するKPIをまとめました。収益性を把握することでビジネスの持続可能性を評価することが可能になります。収益性に関する数値は資金調達の際にも重要視されるので、しっかりと数値管理をすることがSaaSビジネスを推進する上で肝要になります。 CAC (Customer Acquisition Cost) マーケティングや営業など顧客獲得にかかったコストを指します。コストパフォーマンスの悪いチャネルを見つけ、マーケティング施策の最適化に役立ちます。「顧客獲得コスト/ 新規獲得顧客数」で計算します。 CACペイバックピリオド CAC(顧客獲得コスト)を回収するまでにかかった期間。「CAC/顧客の平均単価」で計算します。目安は6ヶ月から12ヶ月以内と言われており、短いほど費用対効果が良いと言えます。ユニットエコノミクスとセットで判断する必要があります。 LTV (Lifetime Value) 顧客生涯価値。特定の顧客がSaaSビジネスにどれだけの価値をもたらすかを評価する指標。長く利用してもらいたいSaaSビジネスにおいて、LTVは重要な指標となります。サブスクリプションモデルの場合、解約率が収益へ影響しやすいため「顧客の平均単価×粗利÷解約率」で求めることが一般的です。 ユニットエコノミクス CAC(顧客獲得コスト)とLTV(顧客生涯価値)より求める顧客1人あたりの収益率。「LTV/CAC」で計算します。さらに資本を投下してユーザ数を増やす(CACを上げる)べきか、LTVを上げる方向性の施策を打つべきかなど、事業投資の効率性や健全性を測るために使用されます。 MRR (Monthly Recurring Revenue) 月間で課金されたサブスクリプション料金の合計、月間定期収益。 ARR (Annual Recurring Revenue) 年間で課金されたサブスクリプション料金の合計、年間経常収益。 ARPA (Average Revenue Per Account) 1つのアカウントあたりの平均収益。「MRR(or ARR)/全アカウント数」で計算します。同一ユーザーがPCとスマホの2つの端末でログインしても、同一アカウントとなるためカウントは1となります。複数端末で利用される場合、ARPUよりもARPAの方が実態を反映することができます。 ARPU (Average Revenue Per User) ユーザー1人あたりの平均収益。「MRR(or ARR)/全ユーザー数」で計算します。同一ユーザーがPCとスマホの2つの端末でログインしても、別ユーザーとなるためカウントは2となります。 ASP (Average Selling Price) 一定期間内の1人あたりの新規顧客から得られる平均収益。「一定期間内のMRR/その期間内新規獲得顧客数」で計算します。 SaaSクイックレート／クイックレート ビジネスの成長の健全性を示す指標。「増加分のMRR/損失分のMRR」で計算します。目安は、SaaSクイックレートが4を超えていれば良好、0～4の間であれば、大きな問題はないが、今後新規顧客獲得・アップグレードによる単価改善が必要、0以下は衰退しているということになります。 顧客維持に関する指標 顧客の獲得、解約に関するKPIをまとめました。サブスクリプションモデルを用いるSaaSビジネスでは、継続して使ってもらうことが重要です。解約率の他にも満足度に関するKPIを持つことで、サービスの改善、新たなニーズの発見にもつながります。 NPS (Net Promoter Score) 顧客がサービスをどの程度勧めたいと思うかを測定する顧客満足度を表す指標。アンケート調査などを使用して、顧客が企業をどのように評価しているかを把握します。 NRS (Net Repeater Score)  サービスを利用している顧客が、どの程度サービスを継続して利用したいと思っているか顧客継続度を表す指標。顧客に1年後もサービスを継続利用したいと思うか質問し、1～5で評価してもらうなど、アンケート調査を行います。 チャーンレート (Churn rate) ある期間内に解約した顧客数の割合、解約率。サブスクリプションモデルを採用しているSaaSビジネスでは、解約は収益に大きな影響を与えるため重要なKPIとなります。チャーンレートの平均値は3~10%で、理想は3%以下が目安とされています。しかし、サービスに依存するため自社で目標値を設定する必要があります。 チャーンレートには、収益ベースのレベニューチャーンレート(MRRチャーンレート)と顧客ベースカスタマーチャーンレートがあります。低価格のサービスであれば、顧客の解約の方が影響が大きいなど両方のチャーンレートを見なければなりません。 レベニューチャーンレート/MRRチャーンレート 収益ベースで算出される解約率。その中でも、一定期間内に発生した解約やダウングレードによる損失金額をベースに算出するものを「グロスレベニューチャーンレート」、損失だけでなく、サービスのアップグレードやクロスセルの利益も含めて算出するものを「ネットレベニューチャーンレート」と呼びます。 カスタマーチャーンレート 顧客ベースで算出される解約率。「(ある期間内に解約した顧客数/期間前の顧客数)×100(%)」で計算します。 エクスパンション サービスのアップグレードやアドオンの購入など、既存顧客からの追加の売上。 コントラクション 契約終了やキャンセルなどによる、売上の減少。 CRR (Customer Retention Rate)  一定期間内にどの程度契約を継続できたかを示す指標。顧客維持率。「((期間終了時の顧客数－期間中の獲得顧客数)/期間開始時の顧客数)×100(%)」で計算します。 NRR (Net Revenue Retention) /NDR (Net Dollar Retention) 一定期間内に既存顧客の売上がどれだけ増減したのかを示す指標、売上継続率。「(月初のMRR＋アップグレードなどの追加購入の収益)-解約などによる損失/月初のMRR」で計算します。 ユーザーの活動に関する指標 ユーザーの動きに関するKPIをまとめました。ユーザーの利用状況を知ることで、新たなニーズや顧客のロイヤリティ把握に役立ちます。また、追加サービスや新たなマーケティング施策を行った際に、ユーザーエンゲージメントにどのような影響がでたのかを知り、施策の評価をすることができます。 DAU (Daily Active User)   1日あたりのアクティブユーザー数。日常的に使用してほしいのであれば、DAUをKPIに置くといいでしょう。「1日でサービスを利用したユーザー数/登録者数」で計算します。 WAU (Weekly Active Users) 1週間あたりのアクティブユーザー数。毎週更新するようなものは、WAUをKPIに置くといいでしょう。「1週間の間でサービスを利用したユーザー数/登録者数」で計算します。 MAU (Monthly Active Users) 1ヶ月あたりのアクティブユーザー数。長期間の利用を目指すのであれば、MAUをKPIに置くといいでしょう。「1ヶ月の間でサービスを利用したユーザー数/登録者数」で計算します。 スティッキネス スティッキネス(Stickiness)とは、粘着性という意味があり、ある期間内にどの程度頻繁に戻ってきてアクティブに利用しているか、つまりユーザーがどのぐらい熱中しているかを表す指標です。ユーザーのサービスの利用時間に対し、滞在時間を指標にする場合もあります。 RFV (Recency・Frequency・Volume) R (Recency): 直近の利用状況、F (Frequency): 利用頻度、V (Monetary Value): 利用量の3つの指標の総称。これらの指標を組み合わせ、顧客のランク付けやマーケティング施策の検討などを行います。 企業の成長に関する指標 企業の収益、経営戦略に関連するKPIをまとめました。サービスの収益から今後の成長や継続の検討、市場内でのサービスの立ち位置を理解し、サービス改善やマーケティング戦略の検討を行う際に必要となります。 CMRR (Committed Monthly Recurring Revenue) 既決月間定期収益のこと。契約により確約された月間収益額を示します。初期費用など1回限りの支払いなどを含まず、今後の解約・アップグレード・ダウングレードも考慮します。より正確な収入を予測するために重要な指標です。一般的に「MRR + 新規確定MRR – チャーンMRR – ダウングレード + アップグレード」で計算されます。 ACV (Annual Contract Value) 顧客が1年間に支払う金額の合計、年間契約金額。初期費用やオプション費用も含まれます。ACVは、顧客1人ずつに着目し、初期費用まで含まれるためARRより正確な収益となります。「月間利用料 × 契約期間(最大12ヶ月) ＋ 初期費用やオプション料金など」で計算します。 TCV (Total Contract Value) 顧客が契約期間内に支払う金額の合計。初期費用、オプション費用も含まれます。ACVは最大1年間の収益に対し、TCVは契約期間すべてで得られる収益となります。 Rule of 40 売上高成長率+営業利益率の値が40%を超えるのが望ましいという、SaaS企業を評価する際の基準となる数値。Rule of 40を達成するためには、企業が収益性と成長性の両方をバランスよく維持する必要があります。例えば、営業利益がマイナスであっても売上成長率が大きくプラスであれば大きな心配がないと判断することができます。 Burn rate (バーンレート) 会社が1ヶ月あたりにどの程度コストを消費しているかを示す指標。支出が収入を上回っている場合、この指標はマイナスの値になります。毎月使用した現金の合計額をグロスバーンレート、毎月使用した現金の合計額をネットバーンレートといいます。 TAM (Total Addressable Market) 事業者がターゲットとしている市場の全体的なユーザー規模を示します。TAMを把握することで、企業は、自社の製品やサービスが市場全体でどの程度需要があるかを理解し、市場シェアの拡大や収益成長の機会を見つけることができます。そのため、TAMは重要な指標です。 SAM (Service Addressable Market) 企業が直接的に提供可能な市場の規模を示します。SAMは、TAMよりも小さな数値であり、TAMは、市場全体の規模を示していますが、SAMは、企業が実際にアプローチできる市場の範囲を示しています。サービスに最も適した市場セグメントを特定し、より効果的にマーケティング活動を行うためにSAMを検討する必要があります。 SOM (Service Obtainable Market) 企業が実際に販売可能な市場の範囲を示します。TAMやSAMよりもより現実的な売上目標となります。 SOMを決定するために、市場の需要、自社の強み、自社で可能な営業活動(プロモーション戦略、人員)などを検討します。 PMF (Product-Market Fit) 提供しているサービスが市場のニーズに合っているかどうかを示します。PMFを評価するために、市場調査、顧客フィードバック、顧客の継続利用率、顧客の紹介数、顧客満足度などの指標を使います。 TTV (Time to Value) 顧客がサービスを導入して、その価値を実感するまでの時間を示す指標です。SaaSのような長期間利用してもらうことが重要なサブスクリプション型ビジネスでは、次の支払いタイミングまで継続してもらうためにも、TTVは短いのが理想です。顧客の解約率を最小限に留めるためにも、TTVに注意する必要があります。 SaaS Magic Number 営業やマーケティングにかかるコストに対して販売効率を測る指標のこと。企業がどれだけ効率的に成長しているか確認するのに使われます。「今四半期の経常収益 – 前四半期の経常収益) × 4 / 前四半期の営業マーケティングコスト」で求めることができます。 目安として、SaaS Magic Numberが0.75以上であれば営業・マーケティングへの投資を検討・実行、0.75以下であれば営業・マーケティングへの投資や戦略の改善が必要と言われています。 T2D3 ARR(年間収益)を毎年Triple(3倍),Triple(3倍),Double(2倍),Double(2倍),Double(2倍)に成長させ、5年間で売上72倍を目指すというモデル。 まとめ 使う場面によってニュアンスが異なる場合もあります。KPIを定めることで事業の計画が明確になるだけでなく、ユーザーニーズの把握などにも生かせます。SaaSは軌道に乗るまではコスト面での負荷が大きくなりがちなので、無駄を省きつついかに目標を達成していけるかがビジネスの成功の鍵になるでしょう。基本的な用語を整理しながら、チーム内での認識を合わせていきましょう。 --- ## SaaS、PaaS、IaaS？◯aaSで終わる用語について解説 URL: https://saasus.io/blog/saas-paas-iaas-and-others Date: 2023-04-12 近年、よく目にするようになったSaaSをはじめとする○aaSという言葉。aaSは"as a Service"の略で、インターネット上で提供されるハードウェアやソフトウェアをサービス化したものに使われます。 ○aaSには「XaaS(X as a Servuce)」や「EaaS(Everything as a Service)」、「AaaS(Anything as a Service)」という言葉もあります。全てのもの、あらゆるものがサービスとして提供されうるという言葉から分かる通り、○aaSのその種類や数はどんどん広がりを見せています。本記事では○aaSの代表格であるSaaS、PaaS、IaaSを始め、様々な○aaSについて解説します。 E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 また、ブログやE-bookで扱って欲しいSaaSに関するトピックやSaaSus Platformについてもっと知りたいことなどへのリクエストを広く募集しています。コンテンツに関する要望や感想がございましたら、こちらからぜひお寄せください。 SaaS、PaaS、IaaS ○aaSでよく比較される「SaaS」「PaaS」「IaaS」。この3つの違いは、事業者が管理する範囲にあります。 一般的には、SaaSがアプリケーション、ミドルウェア、OS、ハードウェアまで、PaaSが開発環境のミドルウェア、OS、ハードウェア、IaaSがハードウェアの保守を管理します。 SaaS SaaSとは、「Software as a Service」の略称。「サース」や「サーズ」と読みます。スマホやWebブラウザ上などで、既に出来上がったソフトウェアをインターネットを通じて利用できるサービスのことを指します。インターネットに接続できれば利用することができ、複数のユーザーの同時利用が可能で利便性に優れています。また、ソフトをインストールせず利用が可能、メンテナンス不要、必要な期間だけ利用できるためコストを抑えることができます。 例えば、Slack、kintone、freee会計があります。 PaaS PaaSとは、「Platform as a Service」の略称。「パース」と読みます。インターネット経由で、アプリケーションを開発・実行するためのプラットフォームを提供するサービスのことを指します。PaaSは、アプリケーション開発を迅速かつ効率的に行うためのプラットフォームが提供されるため、アプリケーションコードに集中することができ、必要なインフラストラクチャやミドルウェアの管理をプロバイダーに任せることができます。 例えば、Amazon Web Services（AWS）、Google Cloud Platform（GCP）があります。 IaaS IaaSとは、「Infrastructure as a Service」の略称。「イアース」や「アイアース」と読みます。クラウドで、ネットワークや、ストレージ、サーバーなどハードウェアリソースのみを提供するサービスです。必要な分だけ利用できる他にも、物理サーバーの保有がないため経年劣化による交換、維持に必要な設備、電気代などコストを抑えることができます。 例えば、Amazon Web Services（AWS）のAmazon EC2（仮想サーバ）、Microsoft AzureのVirtual Machines（仮想サーバ）があります。 まだまだある○aaS 「SaaS」「PaaS」「IaaS」以外にも多くの○aaSが存在します。その一部を紹介します。 ※読み方は複数ある場合もあります。 BaaS/mBaaS（Backend as a Service） BaaSとは、「Backend as a Service」の略称。「バース」と読みます。mBaaSのmはMobileを指し、「エムバース」と読みます。 認証基盤、プッシュ通知、位置情報連携、データベース、ストレージ機能、外部サービス連携などのバックエンド機能をクラウドを通じて提供することを指し、これらの機能をAPIで呼び出すだけで利用できるため、サーバーの開発・運用が不要になりコストカットや工数削減に有用です。 BaaS/mBaaSは基本的に同じ意味です。サービスには、AWS Mobile Hub、Firebaseがあります。 BaaS（Banking as a Service） BaaSとはBanking as a Serviceの略称。「バース」と読みます。銀行が提供しているサービスや機能を、APIを利用して第三者の企業が自社サービスに組み込んで利用できるようにしたサービスを指します。 非金融業でも自社サイト・サービス・アプリなどに金融機能を組み込むことができるため、ECの発展とともに注目されています。代表例に、ZOZOTOWNの「ツケ払い」があります。商品を受け取ったあとに後払いすることができ、最大二か月後まで支払いができるサービスです。 DBaaS（Database as a Service） DBaaSとは、「Database as a Service」の略称。「ディービーアース」と読みます。データベースをクラウド上で提供するサービスのことを指します。 DBaaSを利用することで、開発者はデータベースのセットアップや管理に時間をかける必要がなくなります。また、必要に応じてスケーリングすることができるので、大量のデータも格納することができるメリットもあります。 iPaaS（Integration Platform as a Service） iPaaSは、「Integration Platform as a Service」の略称。「アイパース」と読みます。複数の異なるクラウドサービス間の統合を行うためのプラットフォームを指します。PaaSと似ていますが、アプリケーションの開発・実行が目的のPaaSとは用途が異なります。 分散されたサービスを統一化でき効率化が図れるが、APIが公開されていないサービスは連携することができないため注意が必要です。 aPaas（Application Platform as a Service） aPaaSとは、Application Platform as a Serviceの略称。「エイパース」と読みます。アプリケーションの開発や実行に必要なプラットフォームをクラウド上で提供するサービスのことを指します。ソースコードの記述をほとんど、または一切行わずにアプリ開発することができます。そのため短期間での開発が可能です。 中でも特に生産性の高さに特化したものをhpaPaaS（High Productivity Application Platform as a Service）といいます。 FaaS（Function as a Service） FaaSとは、Function as a Serviceの略称。「ファース」と読みます。サーバレスでアプリケーション開発でき、アプリケーションの実行に必要なリソース（メモリ、CPU、ストレージなど）を必要に応じて自動的に割り当てることができるサービスを指します。 例えば、AWS Lambda、Microsoft Azure Functions、Google Cloud Functionsがあります。 サーバレスによるコスト削減だけでなく、オートスケーリング機能によりインフラ周りの管理の負荷が減少することができます。また、インフラ周りをサービス提供事業者が管理するためBCP対策（※）にも効果的です。 ※Business Continuity Planの略称。事業継続計画のこと。 CaaS（Containers as a Service） CaaS とは Containers as a Service の略称。「カース」と読みます。コンテナオーケストレーション（コンテナを用いたアプリケーションのデプロイ、管理、スケーリングなどを自動で行うこと。）をクラウド上で提供するサービスを指します。例えば、KubernetesやDockerがあります。 開発環境の移動や複製がしやすく、開発を高速で行うことができる反面、学習コストが高いデメリットもあります。 HaaS（Hardware as a Service） HaaSとは、Hardware as a Serviceの略称。「ハース」と読みます。サーバ、ストレージ、ネットワーク回線などのハードウェアを提供するサービスを指します。仮想サーバーなどを提供するIaaSに対し、HaaSは物理的なハードウェアを貸し出します。 STaaS（Storage as a Service） STaaSとは、Storage as a Serviceの略称。必要なストレージを使用料に応じて料金を支払うサービスを指します。柔軟にストレージスペースを調整できるメリットがありますが、大量すぎると高額になる場合があるので注意が必要です。 MaaS（Mobility as a Service） MaaSとは、Mobility as a Serviceの略称。「マース」と読みます。マイカー以外の手段、例えば公共交通機関、タクシー、カーシェアリング、自転車シェアリングなど、さまざまな交通手段を最適に組み合わせて検索・予約・決済等を一括で行うサービスを指します。例えば、Izuko、my routeがあります。 MaaSの普及によりアクセスが不便な地域にも行きやすくなることが期待されます。 TaaS（Testing as a Service） TaaSとは、Testing as a Serviceの略称。「タース」と読みます。ソフトウェア開発のテスト作業をクラウド上で提供するサービスのことを指します。TaaSには、単体テスト、結合テスト、総合テスト、受け入れテスト、負荷テストなどが含まれます。テスト計画の立案や網羅性など、エンジニアコストや時間の削減などのメリットがあります。 SECaaS（Security as a Service） SECaaSとは、Security as a Serviceの略称。クラウド上で提供されるセキュリティ対策サービスを指します。ウイルス対策、ファイアウォール、セキュリティ監視、脆弱性診断などが含まれます。セキュリティの専門家である事業者側が最新技術を提供することで、常に最新の状態で利用することができます。 UCaaS（Unified Communications as a Service） UCaaSとは、Unified Communications as a Serviceの略称。「ユーキャス」と読みます。業務上のコミュニケーションのためのクラウドサービスを指します。ビデオ会議、音声通話、Eメール、チャット、などが含まれます。インターネット環境下であれば、どこにいても連絡することができる、場所を問わずウェブ会議ができるなど在宅勤務の環境整備が図れます。 DaaS（Desktop as a Service） DaaSとは、Desktop as a Serviceの略称。「ダース」と読みます。クラウド上で提供されるデスクトップ環境のサービスを指します。企業が独自に構築するプライベートクラウドタイプ、事業者が提供するバーチャルクラウドタイプ、複数企業が利用するパブリッククラウドタイプの3種類にわけられます。インターネット環境下であれば、どこにいてもデスクトップ環境に接続できるためテレワークの不便さ解消に役立ちます。 IDaaS（Identity as a Service） IdaaSとは、Identity as a Serviceの略称。「アイダース」と読みます。ユーザーの認証、認可などのID管理、シングルサインオンなどをクラウド上で提供するサービスを指します。っ例えば、Okuta、ID Federationがあります。 IDaaSの主な目的は、複数のアプリケーションやサービスを利用する場合に必要な認証情報を管理し、ユーザーの利便性とセキュリティを両立させることにあります。IDaaSを導入することで、ユーザーは一度のログインで複数のサービスにアクセスできるようになるメリットがあります。 DRaaS（Disaster Recovery as a Service） DRaaSとは、Disaster Recovery as a Serviceの略称災害やサイバー攻撃などの緊急時に備えて、データやシステムを仮想サーバー上にミラーリングし復旧させるサービスを指します。緊急時に迅速に復旧するために役立ちます。 GaaS（Games as a Service）  GaaSとは、Games as a Serviceの略称。従来の買い切り型ソフトと異なり、オンライン上でソフトダウンロード、アップデートし継続プレイを提供するサービスを指します。ゲーム内での課金システムによって、長期的な収益が見込める、ゲームの定期的なアップデートや新しいコンテンツの提供によって、プレイヤーを長期的に囲い込むことができるなどのメリットがあります。 一方で、定期的なアップデートや新しいコンテンツの提供が必要であるため、開発コストが高くなるデメリットがあります。また、定期的にアップデートをし、ユーザーが離脱しない工夫が必要です。 NaaS（Network as a Service） NaaSとは、Network as a Service略称。「ナース」と読みます。 クラウド上で提供されるネットワークサービスを指します。ネットワーク機器の準備が不要、コスト・管理工数の負荷が少ないなど、テレワークの拡大も要因のひとつとなり、市場が拡大しています。 BDaaS（Big Data as a Service） BDAaaSとは、Big Data as a Serviceの略称。ビッグデータをクラウド上で管理・分析するためのサービスを指します。 例えば、AWSのAmazon EMR、Google Cloud PlatformのBigQueryがあります。 AIaaS（Artificial Intelligence as a Service） AIaaSとは、Artificial Intelligence as a Service略称。AIを活用したアプリケーションやサービスを提供するために必要な機能やリソースをクラウド上で提供するサービスを指します。企業がAI技術を簡単に利用できるようになり、時間とコストを節約し、効率的にAI活用を行うことができます。 例えば、自然言語処理、画像認識、予測分析などがあります。 APIaaS（API as a Service） APIaaSとは、API as a Serviceの略称。APIサービスの設計とデプロイをサポートするサービスを指します。APIの開発や運用を簡素化し、迅速にサービスを展開することができます。APIaaSには、APIのデザイン、テスト、ドキュメント化、セキュリティ、監視、分析などの機能が含まれます。 APIの開発、運用、管理のコストを削減するだけでなく、事業会社が提供するAPIを利用するため品質向上、エラー削減が見込めます。また、APIの利用者が増えた場合に、スケーリングが容易になります。 RPAaaS（Robotic Process Automation as a Service） RPAaaSとは、Robotic Process Automation as a Serviceの略称。反復的な作業を、機械学習を活用し、自動化するためのサービスを指します。業務プロセスの自動化による生産性の向上、作業時間の短縮によるコストの改善に有効です。また、作業の精度が向上し、エラーを減らせるメリットがあります。 GRCaaS（Governance, Risk, and Compliance as a Service） GRCaaSとは、Governance, Risk, and Compliance as a Serviceの略称。ガバナンス、リスク、コンプライアンスのリスク管理をサポートするサービスを指します。企業は、法令を遵守しさまざまなリスクを回避しなければなりません。これらを統合管理し企業の透明性、安全性を保持していくことに有効です。 IoTaaS（IoT as a Service） IoTaaSとは、IoT（Internet of Things） as a Serviceの略称。「アイオーティーアズ」と読みます。IoT（インターネットを経由してあらゆる物が通信を行なう技術）を用意に利用できるようにするサービスを指します。 例えば、スマートホームデバイスの制御や監視、製造プロセスの自動化や品質管理、設備監視、農業の自動化や遠隔モニタリング、品質管理などに利用されます。 RaaS（Robotics as a Service） RaaSとは、Robotics as a Serviceの略称。ロボットを提供するサービスを指します。例えば、倉庫管理などの作業を自動化することによる従業員の負荷の軽減、製造行程を自動化することによる生産性の向上などに利用されます。人材不足の解消にも有効で、必要なときに必要なだけ導入可能なため導入コストが軽減されるメリットがあります。 VaaS（Video as a Service） VaaSとは、Video as a Serviceの略称。インターネット経由でビデオ通話を行うことを可能にするホストされたサービスを指します。例えば、Zoom、Google ハングアウトがあります。 テレワークなどの働き方改革の普及や、国際ビジネスなどでの遠隔会議、オンライン教育など、さまざまな用途で利用されます。インターネット回線の不具合などによる通信品質の低下や、プライバシー、セキュリティの問題も気を付けなければなりません。 SCMaaS（Supply Chain Management as a Service） SCMaaSとは、Supply Chain Management as a Serviceの略称。従来企業内に構築していたシステムをクラウド上で提供することをサービスを指します。SCMaaSには、在庫管理、物流管理、生産管理、調達管理、予測分析などの機能が含まれます。 企業がサプライチェーンの可視性、効率性、生産性を向上させるために必要なものであり、低コストで簡単に導入することが可能です。一方で、クラウドベースのサービスであるため、ネットワーク接続の問題や障害によって、サプライチェーンの停止などのリスクがあります。 MLaaS（Machine Learning as a Service） MLaaSとは、Machine Learning as a Serviceの略称。 クラウド上で機械学習を提供するサービスを指します。MLaaSの用途としては、画像認識や音声認識、自然言語処理などがあります。 MLaaSを利用することで、高度な数学やプログラミング知識がなくても、簡単に機械学習を実行できます。クラウド上で実行されるため、大量のデータでも高速に処理でき、導入コストも抑えることができるメリットがあります。 代表的なものに、Amazon Machine Learning、Google Cloud Platformがあります。 まとめ SaaS、PaaS、IaaSという代表的なサービスだけでなく今後あらゆるものがサービスとして提供されていくことが見込まれます。トレンドをおさえていきましょう。 --- ## BtoB SaaSがカスタム開発の要望と向き合うには URL: https://saasus.io/blog/how-btob-saas-can-stand-up-to-the-demands-of-custom-development Date: 2023-04-11 BtoB SaaS企業にとって、顧客からの開発要望をヒアリングし、適切に機能として提供することは、ビジネスの成功に欠かせません。しかし、特定顧客の要望だけを叶えるようなカスタム開発には多くの問題が伴い、プロダクトのメンテナンスや将来的なアップグレードにも影響を与える可能性があります。本記事では、1つのコードベースを保ちつつ、フィーチャーフラグを導入することで、適切に顧客からの要望に対応する方法について説明します。 BtoB SaaSにおけるプロダクトマネジメントの難しいポイント BtoB SaaSにおいて顧客をティア(層)ごとに適切に扱うことは大変重要です。BtoB SaaSはある意味で飛行機のようなもので、一つのプロダクトを様々なテナント(≒契約企業)が相乗りをしながら価値を享受するモデルになっています。 当然、ファーストクラスのテナントもいれば、エコノミークラスのテナントもいます。これらを適切に分離しながら、それぞれのティア(クラス)に応じたサービスを提供をしつつも、十分にテストされ一定の品質が担保されたサービスを提供していくことになるわけです。 ここで重要なのは、より上位のティアのテナントが収益性の源泉となっているという構造そのものです。 つまり、如何にして上位のティアにより多くのテナントが移行できるか、また、上位のティアのテナントが解約せずにSaaSを利用し続けてもらえるかがビジネスの成長に大きく関わってきます。 ここでプロダクトマネジメントとして難しいのが「上位ティアの顧客からのカスタム要望をどこまで叶えていくか」という点です。 当然、収益性の高いテナントからの要望ですので、叶えて収益が確保されるなら取り組むべきであると考えがちですが、果たして本当にそのようにすべきでしょうか。一度立ち止まって検討を重ねる必要があります。 SaaSが1つのコードベースを保つべき理由 前提として、SaaSは1つのコードベースを保つべきであるとされています。それには様々な理由があります。 1.コスト削減 複数のコードベースにすることは、開発コストやメンテナンスコストがかかります。1つのコードベースを保持することで、開発チームやメンテナンスチームのコストを削減することができます。 2.一貫性の維持 複数のコードベースにすることで、バージョン管理が複雑になり、バグの発生原因を特定することが困難になる場合があります。1つのコードベースを保持することによって、一貫性のあるプロダクトを維持することができます。 3.迅速なリリース 複数のコードベースにすることで、バグ修正や新機能のリリースに時間がかかる場合があります。1つのコードベースを保有することによって、迅速なリリースを実現することができます。 4.セキュリティの強化 複数のコードベースを保有することは、セキュリティ管理が複雑になる場合があります。1つのコードベースを保有することによって、セキュリティ管理の強化にも繋がります。 5.スケーラビリティの向上 複数のコードベースを保有することは、場合によって環境ごとに別コードベースを適応する必要が出てくるなど、インフラストラクチャの複雑性を高め、スケーラビリティの問題を引き起こす場合があります。1つのコードベースを保有することによって、スケーラビリティを向上することができます。 以上のように、SaaSが1つのコードベースを保つことによって、コスト削減、一貫性の維持、迅速なリリース、セキュリティの強化、スケーラビリティの向上などのメリットがあります。 加えて、SaaSはいわばベストプラクティスの集約であり、様々な顧客の業務をソフトウェアによって効率化したり変革するようなモデルであるため、特定の顧客だけの機能を提供すべきではないという思想的な面も考慮すべきでしょう。 SaaS企業として成功を収めているといえば、やはり有名なのはセールスフォースでしょう。そのセールスフォースは当初から1つのコードベースを保つことを重要視しており、米国の計算機学会として知られるACMが主催したクラウドコンピューティングのシンポジウム「ACM Symposium on Cloud Computing 2010」において、”CRMのSaaSをシングルコードで提供し、成功してきた。”としています。(出典：https://www.publickey1.jp/blog/10/post_116.html) 解決策としてのフィーチャーフラグとは 特定のテナントからの要望が他のテナントにも有用であるかは要件をしっかりとヒアリングを重ね、慎重に検討すべきです。 しかしながら、その要望を叶える機能開発が仮説検証のためであったり、どうしても叶えないとビジネス上問題になる場合、どう対応すれば良いのでしょうか。 1つのコードベースを保ちながら特定のテナントもしくはテナント群にのみ機能を提供するとなった場合には、フィーチャーフラグの導入を検討するのが良いでしょう。 フィーチャーフラグとは、プロダクトの機能を有効にしたり無効にしたりするために使用するフラグのことです。例えば、特定のテナントが必要とするカスタマイズ機能が、あるメニュー項目の表示／非表示である場合、メニュー項目を管理するフラグを導入することでそのメニューの出し分けを制御することができるようになります。 フィーチャーフラグは、テナントティアごとの機能の出し分けだけでなく、実験の機能、運用のための機能、リリースタイミングの調整などにも活用できます。 参考：https://martinfowler.com/articles/feature-toggles.html フィーチャーフラグを導入するにあたっての注意点 フィーチャーフラグのテストを実施する フィーチャーフラグを導入する場合、それをテストする必要があります。特定のテナントの要望に応じてフラグを切り替えることによって、プロダクトが適切に動作することを確認するため、テストを実施する必要があります。テストを実施することによって、フィーチャーフラグの設定ミスやプロダクトの品質低下を防ぐことができます。 フィーチャーフラグを適切にドキュメント化する フィーチャーフラグを適切にドキュメント化することによって、プロダクトの品質を維持することができます。特定のテナントの要望に応じてフラグを切り替えることによって、プロダクトの機能が増えるため、それらの機能がどのように機能するかをドキュメント化する必要があります。また、フラグを誤って設定することによって、プロダクトの品質が低下する可能性があるため、適切にドキュメント化することが必要です。 フィーチャーフラグを管理する フィーチャーフラグを適切に管理することによって、プロダクトの品質を維持することができます。フラグの追加や削除を行う場合には、適切な承認プロセスを導入し、適切に管理することが必要です。また、フラグの設定ミスによってプロダクトの品質が低下する可能性があるため、適切な管理を行うことが重要です。 フィーチャーフラグSaaSの紹介 フィーチャーフラグは自身で実装することもできますが、それ自体をSaaSで実装することもできます。以下は代表的なフィーチャーフラグSaaSです。 ・LaunchDarkly(https://launchdarkly.com/) ・Split(https://www.split.io/) ・Optimizely Experimentation(https://www.optimizely.com/products/experiment/feature-experimentation/) フィーチャーフラグ以外の方法 機能をメタデータ化し、ユーザ自身が変更可能にすることによって、ユーザが自らニアカスタマイズが出来るようになるようにアプリケーションを作ることによって、同等の効果を得ることもできます。この方法は機能開発が必要になりますので、コストや効果を見合わせながら検討をしましょう。 【結論】 BtoB SaaS企業が顧客からのカスタム開発の要望と向き合うためには、適切なプロダクトマネジメントが必要です。その上で、1つのコードベースを保ちつつ、フィーチャーフラグを導入することで様々なシチュエーションに対応ができます。フィーチャーフラグを適切に運用することによって、顧客の属性などに合わせて適切に機能を提供することができるようになります。しかし、フィーチャーフラグを導入・運用するにあたっては、適切なテストやドキュメント化、管理が必要となりますので、その点は注意しましょう。 E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 --- ## 【導入事例】エンプラス株式会社 URL: https://saasus.io/blog/enplus Date: 2023-04-05 外国人材受入支援サービスに係る新規SaaS事業の立ち上げを効率化！SaaSus Platformにより開発工数だけじゃないコスト削減と市場への投入を実現 　 グローバルリロケーション事業を手がけるエンプラス株式会社。 BtoBtoC向けの外国人材受入支援サービスのプロトタイプをSaaSus Platformで開発をされました。今回は、ビジネスサイドから見たSaaSus Platformの手応えについてお話しいただきました。 インタビューにご協力いただいたのは事業企画に携わる江さんです。 海外採用ニーズの開拓を機にマンパワーからシステムへの移行が鍵に 　 ーまずは今回SaaSus Platformをご活用いただいたサービスについて教えてください！ 江さん： 今回、開発をしたのはグローバルリロケーション事業の外国人材受入支援サービスのSasSです。 グローバルリロケーションは簡単に説明すると、採用、赴任、転籍、プロジェクトアサインメント等を背景に企業のグローバル人材が国境を跨いで異動する際の一連の渡航手続きをワンストップで対応するサービスです。就労資格やビザ手続き、海外引越、航空券、住まい探しや生活立上げなど多岐にわたります。 今回開発したプロトタイプは、日本に拠点を持つ企業が海外から人材を採用（直接雇用）する際、採用された方（ユーザー）が各種渡航手続きを進める上でのタスク管理をしたり、弊社のコンサルタントとコミュニケーションを取るためのツールです。 ー江様のプロフィールや社内での業務内容について教えてください。 江さん： 私は現在、事業企画部に所属しています。 開発したプロダクトについて営業サイドと連携し、提案方法などの検討、実績の管理をしています。プロダクト開発時にはプロダクトオーナーとして、開発のプロセスに関わっていました。 ー外国人材受入支援サービスのプロトタイプを開発するに至った経緯はなんですか？また、当該サービスで実現したいことは何でしたか？ 江さん： これまで、日本国内にて採用される外国人材を除き、就労目的で来日する外国人材の多くは、受入企業の海外拠点からの赴任者が多く、弊社もその方々のニーズに合わせた形でサービス提供をしてまいりました。赴任は一定の任期を前提に基本的に会社都合の異動となることから、企業として赴任者本人のみならずお子様の学校探し等その帯同家族も含め日本で円滑な生活の立ち上げや任期中の生活を手厚くフォローすることで、費用も高めのサービスでした。例えば、住民登録や銀行口座開設等にはバイリンガル担当を同行させるなど、多くのサービスは人の手で行っていました。 しかし、直接雇用という形で海外人材を採用した場合、国内採用との公平性という観点から、必要な支援を行いつつも必要最低限の範囲に収めコスト面においても最小限に抑えたいというニーズがありました。そのため、人の手がかかる同行サポートを標準化されたガイダンスに沿ったセルフ対応に置き換えたり、プロセスを可視化してコミュニケーションの工数を抑えたり、最適となるサービス内容と料金のバランスを模索する中、それに対応するインターフェースの開発が急務になりました。 これまで海外赴任をターゲットにしていたところから、新たに海外採用という領域に対してシステムでアプローチすることができれば、スケールメリットの確保と外国人材の海外採用という市場開拓を同時に実現できると考えました。 ーサービスを始めるにあたっての課題は何でしたか？ 江さん： 今までのサービス提供方法を根本的に変えないといけないということですね。人の手を介していたことで、フローが抽象的で柔軟に対応できていたところもあったので、そういった抽象的な箇所を具体的なフローに落とし込むということ、ソフトウェアに落とし込んだ時にどう変わるのかをイメージするのに苦労しました。 あとは新しいサービスなので実際にどれくらいニーズがあるのかを把握できていなかったところですね。まずは市場にプロトタイプとして投入する必要がある中で、どこまで開発を実施するかが悩みどころでした。試験段階なので早くユーザーの声を聞きたいという要求もあったので、動き出すまでに検討することが多かったですね。 運用コストを考えると複雑な開発方法はリスクだった ーSaaSus Platformの導入に至った経緯を教えてください。 江さん： 私はこれまでに2回ほどプロダクトオーナーとしてシステム開発に携わった経験がありますが、要件定義から全ての機能を自社で考えて開発をするのは大変でした。 また、開発が一通り終わっても、社内にIT人材がそれほど多くいないこともあり、工数と人を十分に充てるのは難しく、継続的にシステムをアップデートする運用工数・コストが気になりました。 SaaSus PlatformにはSaaSに必要な基本的な機能が揃っており、これまで社内で管理を行なっていた機能を委ねられる点が時短とコストの低減に繋がると感じました。 新規プロダクトを立ち上げるとなると、開発ももちろん大変ですが、開発リソースの少ない弊社のような企業では、実は運用が大変でカスタマイズや修正に時間がかかることが大きなリスクになり得ると感じていました。専任のIT担当が不在だと、開発を何とかクリアできても、何かあった時に私のようなプロダクトオーナーに相談や依頼がきます。私も専門知識は持ってないので、開発を委託した業者に問い合わせたり、サービスプロバイダに問い合わせたりせざるをえません。そうすると必然的にとても時間がかかりますし、専門知識がないと、そもそも何をすればいいのか把握できないということもあります。 ー実際にSaaSusPlatformを使用してみた感想を教えてください 江さん： SaaSに必要な機能を搭載しているので、気にしなければいけないところが少ない感覚はあります。他のソフトウェア開発と比べて、こちらからリクエストしなくてもログイン機能のアップデートがあったので、自分たちが行っていないのに自然に進化しているように感じました。自社でアップデートするとなると前述の通り余分な工数がかかるので、そういった負担が軽減されているように感じます。 ー本サービスのメリットは何だと思いますか？ 江さん： 以前に携わったシステム開発では管理系機能の要件定義に時間がかかっていたのですが、SaaSus Platformでは少しの議論で簡単に設定できた感覚があります。感覚値にはなってしまいますが、工数は半分以下になっているように感じました。具体的なところで言うと、パスワードの設定とかログイン画面とか規約のカスタマイズなどがスピーディーにできた印象です。 開発そのものもそうですが、要件を決めるところの工数が削減できていると思います。SaaSus Platformの提供する機能をベースに何が必要か？を考えるだけでいいので、0から要件を考えなくても、選択肢を与えられた状態から検討を始められる点は工数削減に大きく影響すると思います。 「More Value, Less Barrier」の実現のために ー御社の事業の今後やプロダクトの見据える未来について教えてください。 江さん： 現在、プロトタイプは一部のお客様にお試しいただく段階になっています。既にユーザーの方へ一通り使っていただきましたが、コメントではサービス含めての満足度が高く、今後に期待が持てました。社内の担当者が実際に運用しながら、想定オペレーションとの差を検証している最中です。 私たちの事業は海外人材の受入支援という特性上、人が動いているという前提が必要な事業です。創業以来、リーマンショック、大震災、コロナ禍、という危機を迎えてきました。 特にコロナ禍においては海外人材の受け入れの動きがとまってしまいっておりましたが、ようやくグローバル規模で行動制限が緩和され、現在はコロナ禍からの回復を肌で感じています。2023年4月以降はこの流れがさらに加速すると考えており、弊社としてもグローバルリロケーション事業を加速させていく予定です。 当社は、今後も増加が加速する海外採用に向けたサービスを強化する予定です。そのためには、今回開発したプロトタイプをより多くの人に使ってもらう必要があります。利用実績を積み上げることで、本格的な開発を進めていくことになりそうです。 今も社内に専任者はいない状態ですので、専門の会社に相談しながらメンテナンスしやすい状態にしていくのを考えていきたいです。SaaSus Platformはサービス提供者側の管理画面の使い勝手が良さそうなので、機能の理解を深めながら活用していきたいと考えています。 手前味噌ではありますが、累積8,000社を超える企業のサポート実績をもつ当社が展開する外国人材受入支援サービスは、必ず市場に受け入れられるものだと感じています。このサービスを軸に私たちの掲げるビジョンである「More Value, Less Barrier」を実現したいと考えています。海外の方から見て、日本という国は文化や言語や習慣に至るまで異なる点が非常に多く、それらが日本で暮らす、働く上での障壁（バリア）になりやすいです。そのため、私たちは「住まう」、「暮らす」、「働く」を軸にどんどんバリアを取っ払い、日本のグローバル化に貢献して行きたいと考えています。 そのために、まずは実績No1を目指します。それが多くの人に私たちのサービスが届いていると言う一つの指標になりうるからです。これから競合が増えていくことが見込まれる業界なので、認知拡大や機能改善には積極的に取り組んでいきたいと考えています。 ーSaaSus Platformに今後期待することは何ですか？ 江さん： 事業に関して言えば、「住まう」、「暮らす」、「働く」を軸に展開していくので、当社が中心となり、これらに関連する専門サービスを提供する事業者を巻き込んでエコシステム全体で多くのバリアをなくしていけたらと考えています。そのため、顧客企業、その従業員だけでなく、専門サービス事業者も紐づくようなシステムに発展させていきたいと思います。それに伴って他のアプリケーションとの連携などが必要になるかもしれないので、SaaSus PlatformのEventBridge連携には期待しています。 また、弊社のサービスは国を跨ぐものなので、ISMSの取得など情報の管理やセキュリティの担保が証明されていると安心感があって良いと思います。他には請求機能では多数の通貨に対応されているとありがたいです。中長期的にはインバウンドだけでなく日本から海外に展開する、というのも見据えているので機能追加には期待しています。 ー本サービスの導入を検討している方に何か一言ありますか？ SaaSus Platformを活用すれば社内にエンジニア・IT人材を揃えられない会社でもSaaSのプロの知見を得られ、開発・運用の課題を解決できます！ 外国人材活用のトレンドでもある海外採用をご検討いただいている企業様はぜひご連絡ください。ユーザーの使い勝手の良さを考え抜いた設計です。 採用した外国人材を初めて受け入れる企業様や既に社内で受入れ対応を実施して困難を感じているという企業様、他社サービスで工数が減らせていないと感じる企業様もぜひお問い合わせいただければと思います。 https://enplus.co.jp/contact/ E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 --- ## 【導入事例】一般社団法人才幹書院 URL: https://saasus.io/blog/saikanshoin Date: 2023-04-04 オンライン競書の先駆者のスタートダッシュを加速！SaaSus Platformで実現する開発ナレッジの補完 日本初の完全オンライン型の競書サービスの提供を開始した一般社団法人才幹書院。開発のナレッジ不足という課題に対し、SaaSus Platformの活用を決意した経緯とその後についてお話しいただきました。 インタビューにご協力いただいたのは 才幹書院 オンライン競書「才幹」プロダクトオーナーの北嶋冬夜さんです。 オンライン競書のパイオニア ーまずは貴団体と「オンライン競書 才幹」について教えてください。 北嶋さん： 一般社団法人 才幹書院は書道を愛する人々の人生を豊かにするために3つの事業を展開しています。1つが実力を有する書道家のプロダクション事業、2つが書道に特化したスキルシェア事業、そして3つめがオンライン完結型の競書サービスです。 今回 SaaSus Platform を活用させていただいた事業は、3つの事業であるオンライン完結型の競書サービスで導入させていただきました。 オンライン競書「才幹」は、書道教室に通いたくても通えない方や、教室には通えるけど決められたお稽古時間の融通がなかなかつけにくい方など物理的な制約がある方でも、自宅で好きな時間に学び書道に触れることができるサービスです。 近年、書道に特化したオンラインスクールやオンラインサロンが増えていますが、中でもオンライン競書「才幹」は、言わば正統派な書を学ぶ環境を提供しています。半紙各書体や条幅、臨書に仮名、そして実用書まで幅広い書体の揮毫動画と豊富な解説付きで学ぶことができ、段級位は書体ごとに付与しております。※認定試験や師範試験の受験も可能 才幹書院は、従来の書道教室や紙媒体が当たり前である「競書」の枠を超えて、書道を楽しみ続ける環境づくりを書道業界全体に波及させていくことをミッションとして活動をしています。 ーオンライン競書というのは従来の通信講座や YouTube やSNSで配信されてる書道の動画コンテンツとは違うのですか？ 北嶋さん： 通信講座やYouTubeの動画などの形でお手本をみながら練習したり、添削を受けられたりするサービスやコンテンツはありますが、競書誌としてやっているところはありません。 オンライン競書「才幹」の特徴は、①才幹書院主幹の書家が監修のもと筆の角度や墨量、筆運び速度など充実した解説が繰り返し視聴できる「手本揮毫動画」、②出品券の作成や郵送続きなどの手間が一切不要、オンラインで完結する「課題提出」、③提出課題に対して定量的な評価とカスタマイズの効いた評価コメントをもらうことができる充実した「個人成績表」、④生長の足跡をひと目で把握することができる「成績管理」、⑤他の競書生の作品や成績を見て学び学ばれるコミュニティを提供しています。 書道が好きな人、書道を頑張りたいすべての人のために、時間や場所に縛られず好きな時に好きなだけ書道を楽しめるような機会を創出するために、ソフトウェアを活用し独自の価値を”機能”として提供しているのは当社だけなのではないでしょうか。 ー北嶋様はどのような形で才幹書院様に参画なさっているのでしょうか？簡単なプロフィールや社内での業務内容について教えてください。 北嶋さん： 実は私自身も小学校1年生の時から細く長く書道を続けています。「冬夜」は雅号であり、師事する才幹書院主幹の先生より命名いただきました。現在は書道を学びながら、才幹書院の競書運営メンバーとして参画しています。役割は、主にオンライン競書「才幹」のプロダクトオーナーとして、ビジネス側のビジョンを明確にしてプロダクトチームに共有し、開発のバックログを作成し、全体的な戦略とビジネス目標に基づいて開発の方向性を定めています。私自身、本業でもプロダクト開発に関わっているということもあり、才幹書院においても本役割を担わせていただいています。このあたりは、幼い頃から趣味として続けてきたことと今やっている仕事との点と点が線で繋がった感覚があり、非常にやりがいを感じています。 見据えるビジョンと開発ナレッジの乖離が課題 ーオンライン競書サービスを立ち上げるにあたっての課題は何でしたか？ 北嶋さん： 率直に言うと、開発のノウハウがなかったことですね。書道を愛する人のために何をすべきか、というビジョンは見えていたもののそれを実現するサービスの在り方を模索していました。ソフトウェア化を行う前段階で、WordPressを使ったサイト上でのサービスをα版として関係者向けに提供したこともあります。 その段階でユーザーの求めるものは見えてきたので得るものはありましたが、事業としてスケールするのが難しいという課題がありました。例えば、ログインする箇所が多くなってしまったり、ユーザーの管理をサイト外のスプレッドシートで行なっていたりで、煩雑になっていました。サイト自体も単なる閲覧用のコンテンツの提供になっていたこともあり、ユーザーと教室との双方向性が欠けていて、書道教室、学習サービスとして十分な価値提供が難しい状態でした。 ーそこでソフトウェア化に踏み切ったのですね。それにあたってSaaSus Platformの導入に至った決め手はあったのでしょうか？ 北嶋さん： 一番は開発の工数を抑えられそうだったという点です。減らした工数の分をサービスのコアの部分、価値を高める部分に充てられるので、本当に必要な機能に注力ができると考えました。SaaSus Platformに開発の一部を委ねることができるので、使わない手はないなと思いました。 ー北嶋さんは別のSaaSプロダクトにも携わったことがあるとお聞きしましたが、SaaSus Platformを活用した場合とそうでない場合の違いはありますか？ 北嶋さん： 工数の削減でユーザーに価値を提供できる部分の開発に注力できているという実感があります。従来はプロダクトを作る上で、ユーザーに必要な機能を見極めて、それを実現するために必要な機能の開発を進めていく形だったので、本当に必要で作りたい機能の開発が後回しになるというジレンマがありました。その部分をSaaSus Platformが担ってくれるので、冒頭でもご紹介した本来は一刻も早くユーザーに価値を提供したい機能の開発までのプロセスが短縮されて、開発への近道になったように感じます。 ーより具体的な使用感についてもお話しいただけますか？ 北嶋さん： 認証部分に関してはユーザーの登録状況が見えるのがありがたいです。 実際に開発を行うメンバーの声としては、ログイン周りは意外と考えることや開発の手間がかかる箇所なので、そこに手をかけなくて良いことで負担が減っているとのことです。 また、現在はSDKとAPIを活用し開発を行なっていますが、従来の自前のデータベースを用いる場合と遜色ない使用感で扱えており、全体的に開発工数を削減しつつ、使用感も十分に担保されているようです。 2Cから2Bへ ープロダクトの今後の展望についてもお話いただけますか？ 北嶋さん： 現在は書道教室の生徒さん向けのB2Cのサービスですが、今後はB2Bとして競書誌向けのサービスも提供していくことも検討中です。才幹書院のお手本や教材を活用する書道教室を増やしたり、オンライン書道教室のシステムを各競書誌団体に提供したりなど、いくつか方法があるかなと思います。各教室や競書誌団体を1テナントとして管理し、それぞれに対してシステム利用料のような形で請求を行う時にSaaSus Platformの請求機能を活用する場面が出てくると考えています。 競書誌団体のほとんどはオンラインの仕組みを持っていないため、才幹書院が構築したオンラインのシステムを活用してもらうことで、書道界のオンライン化が一気に進むのではないか、それによってさらに盛り上げることができるのではないかと考えています。ソーシャル機能とか成長プロセスが可視化できるようなコンテンツを導入して、書道をより楽しんだりモチベーションを高めるための機能が追加できるといいかもしれません。 また、書道未経験者や教室に入るのを迷っているような人たちに興味を持ってもらうために無償の教材公開などをするのも検討中です。 ー開発の体制について何かお考えはありますか？ 北嶋さん： 開発に関して言えば、内製化はしていきたいなと考えています。そのためにも、SaaSus Platformを活用することでアンチパターン社の保有するSaaS開発のナレッジを内部の開発者たちにも浸透させていけたらいいですね。 今回、SaaSus Platformを活用することで、SaaS開発のナレッジを十分に持たないエンジニアでもSaaS開発に参画しやすくなるように感じました。実際に、才幹の開発には開発経験の少ないエンジニアも参画しています。経験の浅いエンジニアへの機会提供を行うという意味でもSaaSus Platformは有用なのではないかと思います。 ー元々コスト最適化・工数削減として導入していただいたと思いますが、今後、SaaSus Platformに今後期待することは何ですか？ 北嶋さん： SaaSに必須な機能として浮かぶのはカスタマーサクセスやサポートに使える機能ですね。サービス内でのユーザーの動きが見えると分析やサービス改善に生かせると思います。 例えばログイン頻度と書の上達の相関があるのか？などの分析に使うなどして、書道を生きがいにしてもらうためのヒントにしたいと思っています。 また、現在はお客様の声については、Google FormsをメルマガやLINEで定期的に配信して収集していますが、これはユーザーのアクションに委ねられるため、システム側で動きを把握することで全体像を可視化できるとありがたいです。あとは、Googleアカウントでのログインやログイン時間の継続（リフレッシュトークンの実装）ができるとユーザー体験がさらに向上するかと思います。 ー最後に本サービスの導入を検討している方に何か一言ありますか？ 北嶋さん： SaaSus Platformにはアンチパターン社の持つSaaS開発のナレッジが詰まっていると思います。SaaS開発の経験がない人や開発での失敗経験がある人は、SaaSus Platformを通じてアンチパターンのナレッジやチームの技術力を取り入れることができます。SaaS開発の「渡りに船」なのではないでしょうか？ 最近、プロダクトやサービス開発の書籍を読んでいると、海外では「いかに自分たちで作らないか？」を重視しているという文脈をよく目にする気がします。もしかしたら、日本は自分たちの手で作りたい職人気質が多いのかもしれませんね。SaaSはユーザーの声を聴きながら成長し続けることが求められるので、開発には終わりがなく常に作り続けていくサービスだと思います。「本当に職人の手が必要なところに開発の手が行き届く」。SaaSus Platformはそれを実現するためのサービスなのだと思います。 E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 --- ## microSaaSとは？〜メリットデメリットから見るビジネスモデルの特徴と成功の秘訣を解説〜 URL: https://saasus.io/blog/whats-microsaas Date: 2023-03-20 はじめに：SaaSの基本 SaaS（Software as a Service）は、クラウド上で提供されるサービスのことを指します。ビジネス分野でも広く使われ、顧客管理や販売管理、人事管理など、様々な分野でSaaSが導入されています。 SaaSの中でも、特定の業界や業種に特化した「バーティカルSaaS」や、複数の業界にまたがる「ホリゾンタルSaaS」があります。 一方、近年注目を集めているのが「microSaaS」です。microSaaSとは、小規模なソフトウェアサービスを提供するビジネスモデルのことで、個人や小規模企業が開発・提供することが多いものです。 近年注目されている「microSaaS」とは？ microSaaSの特徴は下記のようなことがあげられます。 ①小規模なサービス microSaaSは、名前の通り小規模なサービスです。開発に必要な資金や時間が少なく、少数の開発者で開発できるため、個人や小規模企業に向いています。 ②ニッチな市場 microSaaSはニッチな市場となるため、ユーザーも一般的なSaaSより少ない場合がありますが、致し方ありません。 ③短期間での開発・リリース microSaaSは小規模なため、開発期間が短く、リリースまでの期間も短いです。そのため、開発したサービスをすぐに提供することができ、市場に早期に投入することができます。 ④独自性が求められる 既に数多く参入しているSaaSサービス。それらと差別化するため、microSaaSでは独自性が求められます。例えば、よりニッチなニーズを満たす機能や、顧客のニーズに合わせたカスタマイズが必要です。 ⑤コストパフォーマンスの高さ 開発費用や運営費用が少ないため、microSaaSはコストパフォーマンスの高いビジネスモデルとなっています。また、小規模なサービスであるため、個人や小規模企業でも参入しやすくなっています。 microSaaSのメリットデメリットは下記のようになります。 microSaaSのメリット ①低リスクで参入しやすい 小規模なサービスであるため、開発・運営に必要な資金や人員が少なくて済みます。そのため、低リスクで参入することができます。 ②市場に求められるサービスを提供できる 市場に参入している既存のSaaSサービスでは満たせていない、本当に求められるサービスを提供することができます。また、特定のニーズを満たすための小規模な設計であることから、改善や改良がしやすいという利点があります。 microSaaSのデメリット ①小規模であるため、収益性が低い 小規模なサービスであるため、一定のユーザー数に達するまでに時間がかかり、収益性が低いリスクがあります。 ②運営に必要なスキルが多岐にわたる 個人や小規模企業が開発・運営する場合、プログラミングやマーケティング、カスタマーサポートなど、必要なスキルが横断的に必要になるため、スキル不足による運営の難しさがあります。 バーティカルSaaS・ホリゾンタルSaaSとの違い 「バーティカルSaaS」は「垂直の」という意味を持ち、医療や不動産など特定の業界や業種に特化したサービスのことを指します。介護事業者を対象とした経営支援サービス「カイポケ」、不動産オーナーと管理会社をつなぐ業務支援システム「WealthParkビジネス」などがあります。 「ホリゾンタルSaaS」は「水平の」という意味を持ち、あらゆる業界に対応した汎用的なサービスのことを指します。コミュニケーションツール「Slack」やクラウド会計ソフト「freee」などがあります。 バーティカル・ホリゾンタルSaaSとmicroSaaSは、SaaSという提供形態は同じです。しかし、microSaaSは、一般的な業界や業種に特化したサービスよりも、範囲を絞ったニッチな市場を狙い、より小規模なユーザーベースに焦点を当てています。 また、microSaaSは、特定の業界向けであるバーティカルSaaSと混同されやすいです。microSaaSが「業界にとらわれず、ユーザーのニッチな課題を解決すること」を目的とすることに対し、バーティカルSaaSは、「特定の業界」の課題を解決するというようにターゲットが広いサービスとなります。 microSaaSを構築する手順 次に、microSaaSを構築する手順について解説します。 ①アイデアを練る まずは、自分が興味を持ち、自分のスキルに合ったアイデアを練ります。microSaaSではニッチな市場を狙い、既存のサービスとは異なる新しい価値を提供することが重要です。 ②プロトタイプを作成する アイデアが固まったら、プロトタイプを作成します。プロトタイプは、実際に動作する機能の最小限のバージョンです。プロトタイプを作成することで、アイデアが実現可能かどうかを検証し、フィードバックを受けやすくなります。 ③開発を進める プロトタイプが完成したら、実際のサービスを開発します。開発は、自分自身で行うか、開発会社やフリーランスのエンジニアに依頼することができます。 ④サービスの公開・リリース 開発が完了したら、サービスを公開・リリースします。公開したら、ユーザーからのフィードバックを受け取り、改善・改良を行っていくことが重要です。 ⑤運用・改善 SaaSは提供し始めてからしっかり運用することが重要です。規模が小さいmicroSaaSでもそれは同じです。 microSaaSの事例 「HYPERFURY」 HYPERFURYは、テキストマーケティングツールを提供するmicroSaaSビジネスです。テキストメッセージを用いた個別のマーケティングキャンペーンの作成、管理、実行を行うことができます。例えば、予め作成したキャンペーンの自動送信機能があります。企業は手間を省き、自動的にメッセージを送信することができます。また、データ解析機能により、キャンペーンの効果測定やアクセス解析が可能です。 「Plausible」 Plausibleは、IPアドレスやユーザーエージェントを収集せず、EU一般データ保護規則（GDPR）にも準拠し、プライバシーに配慮したGoogleアナリティクスの代替手段となる軽量なオープンソースのWeb分析プラットフォームです。Google Analyticsのように画面遷移を追跡することはできないものの、リアルタイムでのデータ収集と分析に特化しています。 「Calendly」 Calendlyは、Google、Outlook、iCloud Calendarなど複数のカレンダーと連携することができ、会議の日程調整などのスケジュール調整の手間を軽減することができるサービスで、microSaaSの一種とされることがあります。まだ日本語版はありませんが（2023年3月時点）、世界で1000万人以上に使われています。microというワードとのギャップを感じるユーザー規模のサービスですが、「日程調整」という限られたニーズに応えているという点で、これもmicroSaaSの一種とされる場合もあります。 成功するための秘訣 ①ニッチな市場を狙う microSaaSは、大企業が手がけるような大規模な市場を狙うのではなく、ニッチな市場を狙うことが重要です。業界や業種、特定のユースケースに特化したサービスを提供することで、より専門的なニーズに応えることができ、競合他社との差別化もしやすくなります。 ②ユーザーの声に耳を傾ける ユーザーの声に耳を傾けることはどのビジネスでも重要ですが、特にmicroSaaSにおいてはユーザーからのフィードバックを重視することが必要です。ユーザーのニーズに合わせた機能の開発や改善を行うことで、ユーザーの満足度が高まり、リピート率も向上することが期待できます。 ③マーケティング戦略の構築 効率的なマーケティング戦略を構築することも大切です。有料広告やSEO対策、SNSなどを活用し、ユーザーを集めましょう。他にも、既存のユーザーからの紹介や口コミを増やすことで、継続的なユーザー獲得につなげることができます。また、ProductHunt(https://www.producthunt.com/)のような新規プロダクト掲載サイトへの投稿なども検討して認知拡大を図りましょう。 まとめ microSaaSは、今後も更なる成長があると予測されます。身近なところにアイディアがあるはずです。どんなサービスがあると便利になるか考え、形にしてみませんか？ microSaaSのアイディアをブラッシュアップするサイト(https://microsaashq.com/)もあるようなので、参加してみてもいいかもしれません。 是非、あなたの「あったらいいな」を実現させましょう。 E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 また、ブログやE-bookで扱って欲しいSaaSに関するトピックやSaaSus Platformについてもっと知りたいことなどへのリクエストを広く募集しています。コンテンツに関する要望や感想がございましたら、こちらからぜひお寄せください。 --- ## SaaSにおけるプライシング（価格設定）の考え方について URL: https://saasus.io/blog/saas-pricing Date: 2022-11-24 SaaSのビジネスモデルにおいては、料金プランの設計や請求方法を確立させることは非常に重要な視点となります。ビジネス毎に適切な料金プランは異なります。全てのユーザに定額利用料を毎月請求することもあれば、利用量に応じて利用料も変わる従量課金を選択しているサービスもあるでしょう。 これらは、ビジネスのフェーズや提供する業務の種類やターゲットなど、さまざまな要素を考慮して自社のサービスに適した設定をする必要があります。 SaaSの料金設定の種類 SaaSでよく使われる料金設定は大きく3つあり、「定額制」「従量課金制」「階層制」です。それぞれ解説します。 定額制 文字通り1つの価格設定で、すべてのユーザーが同じ価格で同じ機能を利用することができます。定額制は1つのプランでシンプルに販売することができ、ユーザーとのコミュニケーションがとりやすいメリットがあります。しかし、価格が高い、機能が足りないなどのユーザーの全ての要望に答えることが難しいデメリットがあります。 階層制 階層制とは、機能やユーザー数に応じて複数のプランを提供します。SaaSで最も多く利用されている料金体系です。 使える機能が多くなるほど料金が高くなるものを機能ベース、ユーザーのアカウント数に応じて料金が高くなるものをユーザーベースと言ったりします。機能ベースとユーザーベースをかけ合わせたハイブリット型もあります。 ユーザーの状況に応じてプランを選んでもらえるので、定額制に不満を感じていたユーザーの要望に応じることができます。 しかし、プランが多すぎたり複雑になると、管理が大変なだけではなく、ユーザーも適したプランがわかりにくくなるので、注意が必要です。 従量課金制 従量課金制は、使用量によって料金が決まるシステムです。代表的なものとして、クラウドストレージサービスであればストレージ容量、メール配信サービスであればメールの配信数、ウェブ会議ツールであれば使用時間や参加人数、などがあります。ユーザーの成長とともに収益が増加します。ユーザーはコストを抑えたいとき利用を控えることもあり、収益の予測がしづらいデメリットもあります。 SaaSの販売形態 SaaSは、状況にもよりますが営業担当が直接ユーザーと対話することは少ないことが多く、オンライン上で契約されることが一般的です。そのため、ユーザーからどれだけサービスを理解してもらえるかが重要となります。 また、SaaSは買い切り型ではなく、サブスクリプションモデルを採用することがほとんどです。 サブスクリプションモデルとは、ユーザーが月額または年額の料金を支払いを行い、一定期間サービスや製品を利用できるビジネスモデルです。一般的な例として、音楽ストリーミングサービスや映画・テレビ番組の視聴サービスがあります。 ユーザーは、自分のニーズに合わせてプランや料金を選択し、必要な期間だけサービスを利用することができるメリットがあります。 ベンダーにとっても、サブスクリプションモデルは、安定かつ継続的な収益が見込めるというメリットがあります。継続的に機能アップデートを行うSaaSと親和性の高い販売体系と言えます。 サブスクリプションモデルをベースとしたSaaSの販売形態をご紹介します。 フリーミアム 基本的なサービスを無料(フリー)で提供し、より高度な機能をプレミアムとし、収益を得るモデルです。有料プランはサブスクリプションモデルで提供することが一般的です。 フリーミアムでは一般的に期間の制限がなく、限られた機能の中での利用であれば無料で使い続けられます。無料機能しか使わないユーザーもいますが、無料で使えることから、試してもらいやすいのがメリットです。 有料プランへ移行してもらうためには、有料機能が無料機能よりも魅力的であることが大切です。移行するケースとして、無料で使える機能では満たせない要件がでてきた、無料で作れるアカウント数では足りなくなった、無料で使えるストレージ容量が足りなくなった、などが考えられます。 無料期間を設定する 期間ではなく機能を制限するフリーミアムと対照的に、無料の期間を設け、有料プランと同様の機能を一度体験してもらい、契約を検討してもらう販売形態もあります。無料期間終了後、有料プランへ移行します。 無料プランを提供することで、多くのユーザーがサービスに触れ、サービスへの理解を深めることができます。 無料で提供することは本当に必要？ 最近のSaaSは、ほとんどの場合、フリーミアムまたは無料期間を提供しています。 先にも述べましたが、SaaSは、営業担当と直接対話することは少ないので、対話の少ない中、どれだけサービスを理解してもらえるかが重要です。なので、サービス理解を深めるために、実際に使ってもらうことは有用です。 また、競争力の観点から無料で提供することは重要な役割を果たす場合があります。競合他社が既に無料で提供している場合、ユーザーは選択肢を比較する際に無料プランの存在を重視することがあります。このような場合、無料プランを提供しないと競争力が低下し、ユーザーの獲得やキープに影響を及ぼす可能性があります。 ただし、無料で提供することの課題もあります。例えば、収益を上げるためには有料プランへのアップグレードが必要です。無料プランのユーザーを有料プランにアップグレードしてもらうための戦略を検討する必要があります。 無料プランが必要かどうかは、市場状況、競合他社の存在、マーケティング戦略などを総合的に考慮しましょう。 パッケージングの考え方(料金プラン作成) プライシングを考える上で、最初にどんな料金プランを提供するかを決定する必要があります。サービスリリース初期は、一つの料金プランで提供することもありますが、ビジネスのフェーズが進むと幅広いユーザーのニーズに対応する必要が出てきます。その場合には、複数の料金プランを提供することになります。 プランに応じて機能や提供する価値と価格の釣り合いを取るためには、そのプランを誰に向けて提供するのかを明確にする必要があります。ターゲットが誰なのかの解像度を上げるために、ペルソナを定義する方法があります。 例えば、スタートアップ企業のCEOをターゲットにしたプランを提供したいとなった場合には、そのペルソナに対してどんな価値を提供するかを明確にし、その対価としてどんな料金プランを作成するかを考える必要があります。 ペルソナが見えてくると、必要なプランの数が見えてきます。サービスリリース初期は、一つの料金プランで十分な場合もあります。ペルソナに合わせて必要なプランを準備しましょう。 エンタープライズ 最初はスタートアップ企業に提供していたサービスも、プロダクトの成長と共に、エンタープライズ企業向けにニーズにも応えられることがわかってくることがあります。 例えばエンタープライズ企業の部長というペルソナに対して、同一の価値を同一の料金で提供するケースもあれば、エンタープライズ企業に向けて別の価値を別の料金で提供する場合も出てきます。マルチテナントで提供されるSaaSをエンタープライズ向けにサイロ型マルチテナントで提供したり、独自のカスタマイズを提供したりが考えられます。 サービスの成長速度に合わせ、開発コストと見込まれる収益を慎重に検討してください。 アップセル アップセルは、既存のユーザーに対して現在利用しているプランや機能のアップグレードを提案することです。ユーザーがより高額なプランに移行することで、より多くの価値を提供することが目的です。例えば、追加の機能やリソースを提供し、基本プランからプロフェッショナルプランへのアップグレードする、より多くのデータやトランザクションを処理できるように月間利用制限の増加プランを提案する、などです。 アップセルのメリットは収益の増加だけではなく、追加の機能やリソースを提供することで、満足度の向上もあげられます。一方で、高額なアップグレードに関心を持たないユーザーが、競合他社の低価格プランに移行する可能性があります。アップセルを検討する際には、ユーザーの現在の利用状況やニーズを把握することが重要です。 価格設定のポイント 次に、上記で設定したプランに価格を設定していく必要があります。ここでは、価格設定のポイントとして３つをあげてみます。 プロダクト開発に要したコストから料金を設計する 競合プロダクトをベースに料金を設計する プロダクトが提供する価値から料金を設計する 以下に詳しく説明します。 プロダクト開発に要したコスト、サービス運用に必要なコストから料金を設計する プロダクト開発に伴い発生したコストを基に、料金を設計する方法をコストプラスアプローチとも言います。 開発にかかったコストには、直接的にかかる開発の人件費、サーバー運用費、アップグレードにかかる費用コスト以外に、間接的にかかるマーケティング費用、人件費なども含まれます。 1. コスト評価 まずは、提供する製品やサービスにかかるコストを算出する必要があります。開発にかかった人件費、ツールやソフトウェアにかかる費用、インフラの使用料、マーケティングコスト、製造コストなど、すべてのコストを評価することが重要です。 2. 単位コスト評価 次に、提供する製品やサービスの単位コストを評価する必要があります。SaaSプロダクトの場合、利用者数や時間、帯域幅などに基づいて単位コストを評価することが多いです。単位コストを正確に評価することで、単価を決定する際に正確性を担保することができます。 3. 利益率の評価 最後に、単位コストに割り増しを加え、利益率を決定する必要があります。利益率は企業ごとに異なるため、自社のトップラインやユーザーのニーズに合わせて設定しなければなりません。 コストをベースに料金を設計するメリットとしては、シンプルさと予測のしやすさが挙げられますが、料金設計の柔軟性に課題があるため、SaaSプロダクトには必ずしも適しているわけではありません。SaaS開発では、追加機能やアップグレード、開発要員の増減などコストが変動する要素が多い一方、料金はサブスクリプションのような定額制であることが多いため、場合によっては利益を確保できないリスクが生じます。 また、コストベースプライシングのみに頼って価格を設定する場合、ユーザーのニーズや競合他社のプライスポイントなどの重要な要素を無視してしまう可能性があるため、単にコストだけで価格を決めてしまうと、顧客獲得が難しい場合があります。 競合プロダクトをベースに料金を設計する 競合他社のプロダクト料金を参考に料金を設計することを競合ベースプライシングとも言います。 新規参入時などで市場の費用相場に精通していない場合、競合他社のWebサイトなどを調査することで料金の目安を掴めます。簡単かつスピーディに料金設計を行える点がメリットです。競合と類似の料金設計にすることもあれば、競合より安価な設定で差別化を図ることもあります。 次に、競合ベースプライシングで調査、考慮すべき項目を説明します。 1.  競合他社の価格調査 競合他社の価格を調査し、自社の製品やサービスと比較します。この調査には、市場調査や競合分析などが含まれます。 2. プライスマッチング 競合他社と同等の製品やサービスを提供する場合、競合他社の価格を参考にすることで市場での競争力を確保します。ただし、コスト構造やブランド価値など、他の要素も考慮する必要があります。 3.他社優位性 自社の製品やサービスが競合他社よりも優れている場合、競合他社よりも高い価格を設定することがあります。これは、製品やサービスの差別化を通じて高品質や独自性をアピールする戦略です 4. ディスカウントプライシング 競合他社よりも低い価格を設定し、市場でのシェア拡大や新規顧客獲得を目指すこともあります。ただし、価格競争が激化する場合や利益率への影響を懸念する場合は注意が必要です。 競合ベースプライシングは、競争激化する市場や価格に敏感なユーザーを対象とする場合に有効な戦略とされています。ただし、他社の価格だけに依存するのではなく、自社のビジネス目標やコスト構造、ニーズなども総合的に考慮することが重要です。 プロダクトが提供する価値から料金を設計する ユーザーがプロダクトから得られる価値をベースに料金を設計する方法をバリューベースプライシングとも言います。ユーザーがどれだけの価値を受け取るかを考慮し、その価値に見合った価格を設定することを目指します。 価値を決める基準となるものの代表例を説明します。 1.  顧客価値の評価 ユーザーが製品やサービスにどれだけの価値を見出すかを評価します。これには、ユーザーのニーズや要求、競合他社との比較、提供される利益や効果などを考慮します。 2. 価値ベースの価格設定 ユーザーが得られる価値を考慮し、その価値に見合った価格を設定します。価値が高い場合は、競合他社よりも高い価格を設定することもあります。一方で、価値が低い場合は、価格を下げることで競争力を維持することもあります。 3. 付加価値の提供 ユーザーがより高い価値を享受できるように、製品やサービスに付加価値を提供します。これにより、ユーザーは価格を支払う価値があると感じることができます。 自社のプロダクトの価値を精緻に計ることは容易ではないため、料金設計に複雑性を伴うことが懸念点ですが、多くのSaaS企業が価値に基づいた料金プランを採用しています。 自社のSaaSプロダクトに十分な価値を乗せることができれば、競合他社と比べて競争力のある料金設計が可能です。ユーザーが価値を感じ、継続して利用してもらうことができれば、解約のリスクも軽減できます。また、継続的な機能アップデートやサービス改善に伴い、料金を段階的に上げていくこともできるでしょう。 バリューベースプライシングは、TAMの拡大、すなわち製品やサービスがユーザーにもたらす価値を最大化し、利益を最適化するための戦略とされています。ユーザーのニーズや要求を理解し、ユーザーにとっての価値を重視することが重要です。市場環境や競合状況も考慮に入れながら、適切な価格を設定するようにしましょう。 価格設定でよくある失敗 価格設定で陥りがちな失敗と、その解決方法について説明します。 過度な価格設定 SaaS企業が自社の価値を過大評価し、高額な価格を設定することで、新規顧客獲得の機会を逃す場合があります。 これを防ぐためには、 マーケットや競合他社の価格設定を調査し、ユーザーの受容可能な範囲内で競争力のある価格を設定することが重要です。また、初期の価格モデルは柔軟性を持たせ、フィードバックやマーケットの反応に基づいて調整できるようにしましょう。 また、料金プランはベンダー側の都合で自由に変えていいものではなく、ユーザーに納得感のある変更でないと、解約につながることがあります。特に価格を上げるなどのユーザーの不利益になる場合は注意が必要です。機能の追加などの明確な理由がなく、単に利益をあげたいというベンダーの動機だけで行うべきではありません。そのため、過度に安価に設定することも枷になりうることを理解しておく必要があります。 複雑な価格プラン 多くの複雑な価格プランやオプションを提供することで、ユーザーが選択に迷ったり、理解しづらくなり、購買意欲が低下する場合があります。 これを防ぐためには、 シンプルで明確な価格プランを提供することで、ユーザーの理解と意思決定を容易にすることが重要です。選択肢を最小限に抑え、基本的なプランと追加オプションを明示的に提示することで、ユーザーのニーズに応えることができます。 やむを得ずプランが複雑になってしまった場合、販売ページに質問チャートを設置し、質問に答えることで適切なプランがわかるようになるなどし、ユーザーが理解しやすくなる工夫をしましょう。 ユーザーの成長に対応しない価格設定 SaaS企業が、ユーザーの利用人数の増加や売上増加などの企業成長に対応できないなどと、柔軟性のない価格設定を行うことで、ユーザーが成長に伴いサービスを離れる可能性があります。 これを防ぐためには、成長段階やニーズに合わせてスケーラブルな価格モデルを構築することが重要です。ユーザーの成長や利用量に応じた柔軟なプランや割引、アップグレードオプションを提供することで、満足度を高め、長期的な関係を築くことができます。 透明性の欠如 価格設定に関する情報が不透明であったり、隠されていたりすると、ユーザーの信用性や信頼性に影響を与える可能性があります。 これを防ぐためには、価格設定に関する情報を透明かつ明確にユーザーと共有することが重要です。価格プランやオプションの詳細をウェブサイトやマーケティング資料で提供し、料金体系や変更に関するポリシーを明示します。また、ユーザーとのコミュニケーションや契約段階で、価格に関する質問に迅速かつ正直に回答することも大切です。 競合に対する価値差の不明確さ SaaS企業が自社のサービスの価値差を明確に伝えられない場合、ユーザーは競合他社のオプションを検討する可能性があります。 これを防ぐためには、 自社のサービスが他社とどのように異なるか、明確に伝えることが重要です。ユニークな機能や利点、課題解決への貢献などを強調し、付加価値を示すことが必要です。競合比較やユーザーの成功事例を活用して、自社の優位性を裏付けるようにしましょう。 まとめ 料金を決めることは、ローンチのタイミングだけでなく、成長フェーズにおいてもとても重要な項目です。しかし、価格設定には確立した方法はありません。自社内で様々な状況を想定してベストな料金を考えましょう。 料金体系についてはバリューベースで料金の大枠を作り、コストや競合の視点から見て微調整をしていくなど、1つ基準となる設定方法を定めた上で、他の二つの方法の視点を取り入れることもできるでしょう。バリューベースに依存しすぎて、コストとの兼ね合いが上手くいかなくなったり、競合の取り組みと大きく乖離してユーザーがついてこないなどの状況も考慮しつつ、適正な価格設定を行うことが重要になります。 E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 また、ブログやE-bookで扱って欲しいSaaSに関するトピックやSaaSus Platformについてもっと知りたいことなどへのリクエストを広く募集しています。コンテンツに関する要望や感想がございましたら、こちらからぜひお寄せください。 --- ## SaaSベンダーが負うべき責任について URL: https://saasus.io/blog/saas-venders-responsibility Date: 2022-11-03 従来型パッケージ提供事業者とSaaS提供事業者の責任範囲の違い 従来型のパッケージ（※オンプレミス型のパッケージソフトウェア）提供事業者と比べて、SaaS提供事業者の責任範囲は多岐にわたり、構築や管理の難易度も高くなります。下図は、従来型のパッケージ提供事業者とSaaS提供事業者の責任範囲および管理難易度の違いを示したものです。 従来型のパッケージでは、システムの構築や運用は顧客企業が責任を持って行うことになります。一方、SaaSにおいては、システムの構築や運用はSaaS提供事業者の責任範囲となるため、責任分界点が異なっている点が大きな特徴です。また、SaaSでは契約している顧客企業の数だけテナント環境が増え、管理・運用する範囲も拡大していくため、SaaS提供事業者にとっては管理の難易度が格段に高まります。 このことから、責任範囲や管理難易度の増大によって、SaaS提供事業者の負荷が非常に高いことがわかります。 SaaSにおける責任範囲の明確化の重要性 セキュリティというAWSのような世界的な企業も常に意識している重要なポイントに対して、AWSは責任共有モデルという責任範囲の分割によって、セキュリティリスクの分担を明確にしています。SaaS提供事業者も自社の責任範囲を明記した上で、それらの理解と遵守を徹底する必要があります。SaaSにおいては上位レイヤーまで責任範囲があるため、責任が事業者サイドに偏りがちです。そのためセキュリティリスクへの対応が広い範囲で求められます。加えて複数テナントにおけるテナントの境界という視点も必要になるため、管理の複雑性も高くシステム開発の難易度が高いです。 AWSは「責任共有モデル」の仕組みを導入することでAWSの責任範囲を明確化し、ユーザーの責任範囲においてもサポートする機能を提供して、ユーザー自らがセキュリティを担保できる環境を備えています。 引用：AWS「責任共有モデル」 https://aws.amazon.com/jp/compliance/shared-responsibility-model/ SaaS提供事業者においても、責任範囲を明確化した上で、その内容を遵守しなければなりません。 そして、SaaSを展開する場合、基本的にSaaS提供事業者の責任範囲はAWSにおける責任共有モデルのものよりも広くなります。具体的には、SaaS提供事業者側がハードウェア、ネットワーク、OS、ミドルウェア、アプリケーション、そしてデータの保護における責任を持ち、ユーザーはアプリケーション上で保存するデータとアクセス権限に責任を持つ形が多いでしょう。 また、SaaS製品はそのセキュリティ対策に加え、複数テナントの管理も必要なため、開発・運用におけるハードルが従来型のパッケージと比較して高くなる点も特徴です。 まとめ SaaSにおいては提供事業者の責任範囲は広く、管理の難易度は高くなります。その上で多くの顧客データを管理するため堅牢なセキュリティ環境が必要です。それだけでなく、SaaS提供においてはセキュリティに加え、複数テナントに関する対策も求められ、開発・運用のハードルは高くなります。発生する課題や脅威に対して、SaaS提供事業者は継続的かつ俊敏性の高いサービス改善を行うことが不可欠になります。 E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 --- ## 成長ステージごとに考慮すべきSaaS運営のポイント URL: https://saasus.io/blog/saas-grouth-stage Date: 2022-10-13 SaaSにおけるソフトウェア開発では、大きく「立ち上げ期」「運用期」「成長期」の成長ステージに分かれます。ここでは、成長ステージ毎の概要や考慮すべきポイントを解説します。 立ち上げ期 まずは、立ち上げ期で考慮すべきポイントについて、顧客を獲得する前後に分けて述べていきます。 顧客を獲得する前 顧客を獲得する前の最初の段階では、将来的なSaaS開発を成功させるための事前準備が重要です。具体的には、潜在顧客のニーズ調査、ビジネスプランの立案、プロトタイプの準備などが挙げられます。 ここでポイントとなるのはユーザーインタビューを通して初期ターゲットのニーズを把握して、できるだけ早くプロダクトを市場に投入することです。潜在顧客のニーズ調査やビジネスプランの立案も重要である一方で、実際に顧客にSaaSプロダクトを提供して市場の反応を直接検証できるとより効果的です。そのため、まずは簡易なアーキテクチャ設計で素早くプロトタイプを準備するとよいでしょう。市場投入時には、提供するSaaSが持つ強みを全面に出します。最低限必要な機能に絞りつつも、強みは削らないようにすることが重要です。 顧客を獲得した後 プロトタイプを市場に投入した後は、実際にサービスを利用する顧客があらわれます。この段階ではまだ顧客数が少なく、市場ニーズが捉えきれていない状況のため、まずは少しでも多くの顧客に使ってもらうことが大切です。顧客に利用してもらう際には、ユーザー体験（UX）に関する調査も重要です。ユーザー体験を反映させた製品の開発や検証を繰り返すことで、顧客の感情も理解することができます。獲得した顧客が当初のペルソナと合致しているか、ユーザー継続率はどの程度かなど、顧客から得られる実際の情報を確認しましょう。 運用期 運用期では、立ち上げ期に比べて顧客数が増加していきます。ここで考慮すべきポイントは、顧客数の増加につれて運用コストが増大しないようにすることです。 顧客数に比例して運用コストが増えると、SaaSの特徴の1つであるスケールメリットによるコスト効率性の実現が難しくなってしまいます。 運用コストの効率化を図るためには、顧客数の増加に伴う対応をソフトウェア内で自動化させることが重要です。例えば、ソフトウェア内で新規顧客が自ら会員登録やログインをできるようにする、顧客が増えてもインフラが自動的に拡張されると運用コストも線形に増えないように、拡張性を意識したソフトウェア開発がポイントとなります。 成長期 運用期を乗り越えると、大幅に顧客数が増加する成長期に入ります。この段階では、多くの企業や顧客を抱えることになるでしょう。収益は拡大していく一方で、顧客が多い分、各顧客と直接的な接点を持つことが難しくなっていきます。 ここで考慮すべきポイントは、顧客データに基づくプロダクトマネジメントや継続的なアップグレード・改善活動を続けていくことです。従来のパッケージ型ソフトウェアでは顧客に売るまでが勝負であったのに対し、SaaSでは顧客と接点を持った後からが勝負といえます。顧客データを収集・分析し、さらなる機能改善につなげていく継続的な取り組みが不可欠です。なお、顧客の数が多い場合は、すべての顧客の声を反映することは現実的に難しいため、要望が与えるビジネスインパクトに従って優先順位づけをする必要があるでしょう。 競合に打ち勝ち、SaaSが提供する領域のベストプラクティスであり続けるためには、成長期に入った後こそ開発すべき機能を顧客データを元に検討をしていくことが不可欠です。 まとめ SaaSはいくつかのステージで分けられ、そのステージに応じて対処すべき問題や考慮すべきポイントが異なります。また、SaaSを運営するにつれて見えてくる課題やそのSaaSの強みなどもあります。ステージごとに変化していくポイントに対して柔軟に対応していくことが肝要です。 E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。 SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。 --- # Resources --- ## 【無料アーカイブ動画】SaaS開発を一気通貫で考える流れとポイント解説 URL: https://saasus.io/resource/archive-video/seminar-archive-20221019 ★限定アーカイブ動画公開中！（視聴無料）★ 2022年10月19日に開催した、新規SaaS事業推進責任者様向けにSaaS開発の流れと開発を進める前に考慮したいポイントを徹底解説したウェビナー「SaaS開発を一気通貫で考える流れとポイント解説」のアーカイブ動画を限定で公開しています。 以下に当てはまる方はぜひこの機会にご視聴ください！ ・セミナーに参加できなかった ・これからSaaS開発を始める予定 ・SaaSの”テック部分”の知見をより深めたい ＜セミナー概要＞ SaaS というのはサービス提供形態の１つです。そのため、実際に提供されるサービスやアプリケーションの作り方は千差万別です。 しかし、少なからず SaaS 開発において共通の部分もあります。こういった共通部分にはベストプラクティスやアンチパターンが存在しているので、それを前もって踏まえておき進めていくのが効率的です。 また、 SaaS ビジネスの要件によってアーキテクチャや開発ポイントも変わってきますので、エンジニアも SaaS ビジネスをある程度理解しておくことが開発効率に寄与します。 どのようなポイントがあるのかの一例をご紹介し、どのように効率化していけばよいかを一緒に考えていきたいと思います。 ＜スピーカー情報＞ 株式会社アンチパターン CTO兼COO, SaaSus Platform プロダクトオーナー 矢ヶ崎 哲宏 幼少時のマイコン時代からプログラミングを続け、近年では中国での IaaS サービス立ち上げや、マルチリージョン・マルチサービスの統合インフラ設計・構築などに従事。その後、SaaS ベンダーでの技術責任者に従事した後に、アマゾンウェブサービスジャパンにて SaaS 領域専門のパートナーソリューションアーキテクトに従事。現在は、株式会社アンチパターンにて SaaSus Platform のプロダクトオーナー兼エンジニアとして SaaS 開発/運用の知見を SaaS に搭載することにチャレンジ中。 --- ## 7/14(火)11:30「マルチテナントAgentic AIサービスの実装」 URL: https://saasus.io/resource/webinar/seminar-20260714 ＼事前登録7日間アーカイブ視聴も可能です！／ ──────────────────────── ＜こんな方におすすめ＞ ・マルチテナント型のAIサービス、SaaS、業務アプリケーションの設計・開発に関わっているエンジニアの方 ・Agentic AIやAIエージェントを、自社サービスやプロダクトにどう組み込むか検討しているPdM・プロダクト責任者の方 ・Amazon Bedrock AgentCoreを活用した実装方法や、テナントごとの最適な設計・運用ポイントを知りたい方 ・AI機能をPoCで終わらせず、実運用を見据えたアーキテクチャやコントロールプレーン設計を学びたい方 ──────────────────────── マルチテナントなAgentic AIサービスはあらゆる産業で新たなビジネス機会を生み出しつつあります。 本セミナーでは、その実装に不可欠となるコントロールプレーンの重要性を解説し、Amazon Bedrock AgentCoreを活用したテナント最適な設計手法を紹介します。 さらに、実践的なアーキテクチャ例を通じて、実装と運用のポイントを具体的に解説します。 30分間のショートセミナーです。ぜひこの機会にご視聴ください。 --- ## マルチテナントAIエージェント開発ガイド【基礎設計編】 URL: https://saasus.io/resource/e-book/multi-tenant-ai-agent-development-guide 全52ページのE-Bookを現在無料公開中です！ 生成AIの急速な進化により、AIエージェントを組み込んだSaaSが競争力の源泉となる時代が到来しています。 本書は、マルチテナントでAIエージェントを安全に提供するための設計指針を解説。「Zero Trust for Agents」を核心思想に、プロンプトインジェクションや情報漏洩などAI固有のリスクに対応する5層多層防御モデルと設計原則を体系的に解説します。 目次 1.なぜSaaSにAIエージェントが必要か - SaaSの進化と「SaaS is Dead」議論 - MCPとA2Aの登場 2. AIエージェントの基礎とマネージド基盤 - AIエージェントの構成要素 - Amazon Bedrock AgentCore - モデル選定 - Strands Agents SDK 3. マルチテナントAIエージェントの課題 - マルチテナントAIエージェントの全体像 - テナント分離の2つの目的 ── OWASP LLM Top 10 2025対応 - サイロ vs プール - Zero Trust for Agentsの5原則 4. 多層防御によるテナント分離 - 5層多層防御モデルの全体像 - OWASP LLM Top 10 × 5層防御 対応マトリクス - 第1層: ゲートウェイ（テナント識別・アクセス制御方式） - 第2層: 認証・認可（JWT/Cedar/Pre-Token Generation Lambda） - 第3層: 実行環境（On Behalf Ofパターン・Exfiltration対策・IAM強制） - 第4層: データの分離（RLS・Lake Formation・メモリ名前空間） - 第5層: 監査・モニタリング（ログ設計・8つの異常パターン検知） 4. 2プレーンモデル - Control Plane / Application Planeの分離設計 --- ## エンタープライズSaaS開発ガイド URL: https://saasus.io/resource/e-book/enterprise-saas-dev-guide 全34ページのE-Bookを現在無料公開中です！ スタートアップ・SaaS事業者がエンタープライズ市場に参入する際に直面する、セキュリティ・コンプライアンス・可用性・ガバナンスの追加要件を体系的に解説！ 「全部実装」の罠を避け、ターゲット顧客に応じた優先順位付けと段階的な対応ロードマップで、SMB市場を手放さずにエンタープライズを攻略するための意思決定フレームワークを公開します。 目次 1. エンタープライズSaaSとは - 一般SaaSとの違い・要件比較 - エンタープライズSaaSの4つの罠 - 本書の位置づけ 2. エンタープライズが求めるSaaSの条件 - 信頼性・事業継続性（SLA要件） - コンプライアンス要件（ISO/SOC 2/FISC/ISMAPほか） - データ主権・データレジデンシー - 運用・統合・組織対応の要件 3. セキュリティ・ガバナンス要件 - 認証・認可の強化（SAML/OIDC/MFA） - 監査ログ・証跡 - インシデント対応体制 - APIセキュリティ 4. 業界別の追加要件 - 金融業界 - 医療業界 - 公共 4. コストと実装のトレードオフ - 全部実装すると何が起きるか - 段階的対応のロードマップ --- ## 2/26(木)11時「マルチテナントAI エージェント（Agent as a Service）の実装AI解説」 URL: https://saasus.io/resource/webinar/seminar-20260226 ────────────────────────────────── ＼こんな方におすすめ！／ ・AIエージェントの商用化・プロダクト化を目指すエンジニア・アーキテクト ・「Agent as a Service（AaaS）」の事業開発を検討しているPM・新規事業担当者 ・従来のSaaS開発から、一歩進んだAI活用アーキテクチャを学びたい技術責任者（CTO/VPoE） ────────────────────────────────── ＼事前登録で7日間アーカイブ視聴も可能！／ 現在、AIエージェントの開発は空前の活況を呈していますが、「マルチテナント」環境での運用ノウハウは依然としてブラックボックスの中にあります。 AIエージェントは従来のSaaS以上に、各テナント固有のコンテキスト（背景・データ）を厳密に扱う必要があります。しかし、その実現パターンは多岐にわたり、アーキテクティングの難易度を押し上げているのが現状です。 本講演では、「Agent as a Service（AaaS）」という次世代の概念から、具体的なテナント分離・コンテキスト管理の実装手法まで、現場で使える知見を徹底解説します。 --- ## 11/26(水)11時「B2B向けAIプロダクト開発入門 ～マルチテナント対応の考え方と実装ポイント～」 URL: https://saasus.io/resource/webinar/semina-20251126 ────────────────────────────────── ＼こんな方におすすめ！／ ・AIエージェントサービスをマルチテナントで提供したいと考えているエンジニアやPdM ・自社のB2B SaaSにAI機能を組み込みたいと検討している方 ・AIサービス開発の設計から運用まで、全体像を把握したい方 ────────────────────────────────── ＼事前登録で7日間アーカイブ視聴も可能！／ ◆本ウェビナーは、10/2に開催しご好評いただいたウェビナーの録画配信です◆ 「SaaS is Dead」といった言葉が象徴するように、AIプロダクトはあらゆる業界で数多くリリースされて、発展してきています。 利用者側は便利になる一方で、法人向けにAIサービスを提供する場合、従来のSaaSと同じように、マルチテナントを前提とした設計や運用がより一層重要になってきます。 本ウェビナーでは、法人向けAIサービスを構築する際に押さえておくべき基本設計や、マルチテナント対応で注意すべきポイントを中心に解説します。 サービスの構成や運用イメージなど、実際のユースケースにも触れながら、設計の勘所をわかりやすくお伝えします。 単なる技術論ではなく、AIを組み込んだプロダクトとしてどう提供価値を設計するかを知りたい方はぜひご参加ください。 ※AIコーディング支援ツール（例：GitHub Copilotなど）を使った開発手法には触れませんのでご留意ください。 --- ## 10/29(水)11時『SaaS is Dead？〜生成AI時代に問われる「事業作り」と「作らない技術」〜』（録画ウェビナー） URL: https://saasus.io/resource/webinar/seminar-20251029 ────────────────────────────────── ＼こんな方におすすめ！／ ・生成AI/AIエージェントを活用したソフトウェアエンジニアリングにご関心のある方 ・AI時代のSaaSの在り方を学びたい方 ・これからSaaS事業の立ち上げを検討している方 ────────────────────────────────── ◆本ウェビナーは、7/24に開催しご好評いただいたウェビナーの録画配信です◆ 生成AIの進化により、ソフトウェア開発のスピードは劇的に加速しました。 こうした時代において、むしろ開発者に問われるのは「何を作るか」以上に「何を作らないか」の判断です。複数のSaaSやAIエージェントをどう組み合わせ、素早く、品質高く、顧客に価値を届け続けるのか──それがこれからのソフトウェアエンジニアリングの潮流となります。 本ウェビナーでは、マルチテナントの意義やComposabilityを通じて、新しいSaaSの在り方とそれを前提にした事業作りの勘所について探ります。 --- ## 10/2(木)11時「B2B向けAIプロダクト開発入門 ～マルチテナント対応の考え方と実装ポイント～」 URL: https://saasus.io/resource/webinar/semina-20251002 ────────────────────────────────── ＼こんな方におすすめ！／ ・AIエージェントサービスをマルチテナントで提供したいと考えているエンジニアやPdM ・自社のB2B SaaSにAI機能を組み込みたいと検討している方 ・AIサービス開発の設計から運用まで、全体像を把握したい方 ────────────────────────────────── ◆事前登録で7日間アーカイブ視聴も可能！◆ 「SaaS is Dead」といった言葉が象徴するように、AIプロダクトはあらゆる業界で数多くリリースされて、発展してきています。 利用者側は便利になる一方で、法人向けにAIサービスを提供する場合、従来のSaaSと同じように、マルチテナントを前提とした設計や運用がより一層重要になってきます。 本ウェビナーでは、法人向けAIサービスを構築する際に押さえておくべき基本設計や、マルチテナント対応で注意すべきポイントを中心に解説します。 サービスの構成や運用イメージなど、実際のユースケースにも触れながら、設計の勘所をわかりやすくお伝えします。 単なる技術論ではなく、AIを組み込んだプロダクトとしてどう提供価値を設計するかを知りたい方はぜひご参加ください。 ※AIコーディング支援ツール（例：GitHub Copilotなど）を使った開発手法には触れませんのでご留意ください。 --- ## 8/22(金)13時「SaaSの未来？AIエージェント関連技術解説」録画ウェビナー URL: https://saasus.io/resource/webinar/semina-20250822 ────────────────────────────────── ＼こんな方におすすめ！／ ・AIエージェントに関する知識を深めたい方 ・MCP、A2A、LAMなどの共通規格、モデルについて学びたい方 ────────────────────────────────── ◆本セミナーは過去開催したセミナーの録画配信です◆ ChatGPTの登場からわずか2年半。 企業においては業務効率化やコンテンツ生成を中心に、AI活用が急速に普及し始めています。 生成AIの活用が一般化し、業務支援や文書生成などの用途が定着する一方、今注目を集めているのが「AIが自ら“行動し”“連携する”」次のフェーズです。 タスク自動化を担うエージェント技術は、現在、エージェントがSaaSなどのツールを効率的に利用するためのMCP（Model Context Protocol）や、複数のAIが協調して動くためのA2A(Agent to Agent)など、”共通規格”が整備されてきたことにより、実用レベルでの社会実装が現実味を帯びてきています。 本ウェビナーでは、AIエージェントの実用化に必要なMCP、A2A、LAM（Large Action Model）といった最新技術/モデルについて解説します。 さらに、当社が提供する「SaaSus Platform」のMCPサーバー公開新機能についても活用方法をご紹介します。 --- ## 7/24(木)12時『SaaS is Dead？〜生成AI時代に問われる「事業作り」と「作らない技術」〜』 URL: https://saasus.io/resource/webinar/semina-20250724 ────────────────────────────────── ＼こんな方におすすめ！／ ・生成AI/AIエージェントを活用したソフトウェアエンジニアリングにご関心のある方 ・AI時代のSaaSの在り方を学びたい方 ・これからSaaS事業の立ち上げを検討している方 ────────────────────────────────── ◆事前登録で7日間アーカイブ視聴も可能！◆ 生成AIの進化により、ソフトウェア開発のスピードは劇的に加速しました。 こうした時代において、むしろ開発者に問われるのは「何を作るか」以上に「何を作らないか」の判断です。複数のSaaSやAIエージェントをどう組み合わせ、素早く、品質高く、顧客に価値を届け続けるのか──それがこれからのソフトウェアエンジニアリングの潮流となります。 本ウェビナーでは、マルチテナントの意義やComposabilityを通じて、新しいSaaSの在り方とそれを前提にした事業作りの勘所について探ります。 --- ## 7/15(火)13時「SaaSの未来？AIエージェント関連技術解説ウェビナー」 URL: https://saasus.io/resource/webinar/semina-20250715 ────────────────────────────────── ＼こんな方におすすめ！／ ・AIエージェントに関する知識を深めたい方 ・MCP、A2A、LAMなどの共通規格、モデルについて学びたい方 ────────────────────────────────── ★事前登録で7日間アーカイブ視聴も可能★ ChatGPTの登場からわずか2年半。 企業においては業務効率化やコンテンツ生成を中心に、AI活用が急速に普及し始めています。 生成AIの活用が一般化し、業務支援や文書生成などの用途が定着する一方、今注目を集めているのが「AIが自ら“行動し”“連携する”」次のフェーズです。 タスク自動化を担うエージェント技術は、現在、エージェントがSaaSなどのツールを効率的に利用するためのMCP（Model Context Protocol）や、複数のAIが協調して動くためのA2A(Agent to Agent)など、”共通規格”が整備されてきたことにより、実用レベルでの社会実装が現実味を帯びてきています。 本ウェビナーでは、AIエージェントの実用化に必要なMCP、A2A、LAM（Large Action Model）といった最新技術/モデルについて解説します。 さらに、当社が提供する「SaaSus Platform」のMCPサーバー公開新機能についても活用方法をご紹介します。 --- ## 6/19(木)11時『コアドメインに集中できる「SaaS開発/運用」の考え方』 URL: https://saasus.io/resource/webinar/semina-20250619 ────────────────────────────────── ＼こんな方におすすめ！／ ・これから自社サービスをクラウド化（SaaS化）したい事業者様 ・新たにクラウドでサービス開発（SaaS開発含む）していきたい事業者様 ・クラウドサービス、SaaSを提供していて、運用に課題のある事業者様 ────────────────────────────────── ◆本セミナーは過去開催したセミナーの録画配信です◆ SaaSは、開発してリリースをしたら終わりではなく、リリースをしてお客様に提供が開始されてからがスタートです。 サービス提供開始後、お客様からのフィードバックや外部環境の変化に柔軟に対応し続けて、プロダクトの価値を高めていくには、アジリティを獲得する必要があります。 アジリティの獲得のために内製化を進めることも検討できますが、全てを内製で実現するかどうかは慎重に検討が必要です。 本セッションでは、どういった領域を内製で取り組むべきかについて、「SaaS開発の効率化」という観点を交えて解説いたします。 本セミナーは30分で学べるショートセミナーです。ぜひこの機会にご参加ください！ --- ## 6/11(水)11時「AWSを活用したパッケージ製品のSaaS化事例解説」｜録画ウェビナー URL: https://saasus.io/resource/webinar/semina-20250611 ────────────────────────────────── ＼こんな方におすすめ！／ ・パッケージ製品を提供している事業者さま ・自社のパッケージ製品のSaaS化をご検討中の企業さま ・AWSを活用したパッケージ製品のSaaS化についてご興味をお持ちの方 ────────────────────────────────── ◆本セミナーは過去開催したセミナーの録画配信です◆ DXを進める上で、SaaS活用は非常に重要です。 SaaSは業務ナレッジ・ベストプラクティスの集合で、導入する過程であらゆる業務の変革を期待できます。 SaaS活用の波に乗るべく、自社で提供されているパッケージ製品のSaaS化を進めている/検討されている事業者さまも少なくありません。 しかし、従来のパッケージ製品をただそのままクラウドに乗せるだけでは、SaaSの恩恵を受けられない場合もあります。そのため、SaaSの恩恵を受けるためのポイントをあらかじめしっかりと理解しておく必要があります。 本ウェビナーでは、AWSを活用してパッケージ製品をSaaS化するプロセスや、SaaS化する際に考慮すべきポイントなどを事例を交えながら解説します。 SaaSへの移行がビジネスにとってなぜ重要なのか、AWSの採用がどんな価値をもたらすのかをご紹介。具体的な戦略と事例を通じて、開発から運用までのポイントを解説しますので、ぜひこの機会にご参加ください！ --- ## 4/30(水)12時開催『コアドメインに集中できる「SaaS開発/運用」の考え方』 URL: https://saasus.io/resource/webinar/semina-20250430 ────────────────────────────────── ＼こんな方におすすめ！／ ・これから自社サービスをクラウド化（SaaS化）したい事業者様 ・新たにクラウドでサービス開発（SaaS開発含む）していきたい事業者様 ・クラウドサービス、SaaSを提供していて、運用に課題のある事業者様 ────────────────────────────────── ◆本セミナーは過去開催したセミナーの録画配信です◆ SaaSは、開発してリリースをしたら終わりではなく、リリースをしてお客様に提供が開始されてからがスタートです。 サービス提供開始後、お客様からのフィードバックや外部環境の変化に柔軟に対応し続けて、プロダクトの価値を高めていくには、アジリティを獲得する必要があります。 アジリティの獲得のために内製化を進めることも検討できますが、全てを内製で実現するかどうかは慎重に検討が必要です。 本セッションでは、どういった領域を内製で取り組むべきかについて、「SaaS開発の効率化」という観点を交えて解説いたします。 本セミナーは30分で学べるショートセミナーです。ぜひこの機会にご参加ください！ --- ## 4/22(火)11時開催『既存アプリケーションのSaaS化による顧客起点のDX』 URL: https://saasus.io/resource/webinar/semina-20250422 =================================================== ＼こんな方におすすめ！／ ・SaaS事業を始めたい事業者様 ・既存のパッケージ製品のSaaS化を検討している事業者様 =================================================== ◆本セミナーは過去開催したセミナーの録画配信です◆ ストック型のビジネスとして引き続き多くの事業者で注目されている【SaaS事業】を始める方法は、何も“新しいものを立ち上げる”だけではありません。 パッケージソフトのSaaSへの移行や、社内業務システムのSaaS化による外販展開など、既存の資産を活かすという方法もあるのです。 本セッションではそういった取り組みについて、事例を交えてご紹介いたします。 本セミナーは30分で学べるショートセミナーです。ぜひこの機会にご参加ください！ --- ## 3/26(水)12時開催「AWSを活用したパッケージ製品のSaaS化事例解説」｜録画ウェビナー URL: https://saasus.io/resource/webinar/semina-20250326 ────────────────────────────────── ＼こんな方におすすめ！／ ・パッケージ製品を提供している事業者さま ・自社のパッケージ製品のSaaS化をご検討中の企業さま ・AWSを活用したパッケージ製品のSaaS化についてご興味をお持ちの方 ────────────────────────────────── ◆本セミナーは過去開催したセミナーの録画配信です◆ DXを進める上で、SaaS活用は非常に重要です。 SaaSは業務ナレッジ・ベストプラクティスの集合で、導入する過程であらゆる業務の変革を期待できます。 SaaS活用の波に乗るべく、自社で提供されているパッケージ製品のSaaS化を進めている/検討されている事業者さまも少なくありません。 しかし、従来のパッケージ製品をただそのままクラウドに乗せるだけでは、SaaSの恩恵を受けられない場合もあります。そのため、SaaSの恩恵を受けるためのポイントをあらかじめしっかりと理解しておく必要があります。 本ウェビナーでは、AWSを活用してパッケージ製品をSaaS化するプロセスや、SaaS化する際に考慮すべきポイントなどを事例を交えながら解説します。 SaaSへの移行がビジネスにとってなぜ重要なのか、AWSの採用がどんな価値をもたらすのかをご紹介。具体的な戦略と事例を通じて、開発から運用までのポイントを解説しますので、ぜひこの機会にご参加ください！ --- ## 11/21(木)13時開催『既存アプリケーションのSaaS化による顧客起点のDX』｜無料ウェビナー URL: https://saasus.io/resource/webinar/semina-20241121 =================================================== ＼こんな方におすすめ！／ ・SaaS事業を始めたい事業者様 ・既存のパッケージ製品のSaaS化を検討している事業者様 =================================================== ストック型のビジネスとして注目されるSaaS事業を始めるには、何も“新しいものを立ち上げる”だけではありません。 パッケージソフトのSaaS移行、社内業務システムのSaaS化による外販展開など、既存の資産を活かした始め方も存在します。本セッションではそういった取り組みについて事例を交えてご紹介いたします。 本セミナーは30分で学べるショートセミナーです。ぜひこの機会にご参加ください！ --- ## 11/14(木)16時開催『コアドメインに集中できる「SaaS開発/運用」の考え方』｜無料ウェビナー URL: https://saasus.io/resource/webinar/semina-20241114 =================================================== ＼こんな方におすすめ！／ ・これから自社サービスをクラウド化（SaaS化）したい事業者様 ・新たにクラウドでサービス開発（SaaS開発含む）していきたい事業者様 ・クラウドサービス、SaaSを提供していて、運用に課題のある事業者様 =================================================== SaaSは開発してリリースをしたら終わりではなく、リリースをしてお客様に提供が開始されてからがスタートです。 そして、お客様からのフィードバックや外部環境の変化に柔軟に対応し続けて、プロダクトの価値を高めていくには、アジリティを獲得する必要があります。 アジリティの獲得のために内製化を進めることも検討できますが、全てを内製で実現するかどうかは慎重に検討が必要です。 本セッションでは、どういった領域を内製で取り組むべきかについて、「SaaS開発の効率化」という観点を交えて解説いたします。 本セミナーは30分で学べるショートセミナーです。ぜひこの機会にご参加ください！ --- ## 10/24(木)13時開催「SaaSがAPIを公開するメリットと具体的な公開手法」｜無料ウェビナー URL: https://saasus.io/resource/webinar/semina-20241024 =================================================== ＼こんな方におすすめ！／ ・APIの公開に悩むSaaS提供事業者様 ・パッケージ製品を提供していて、SaaS化とAPI活用にお悩みの事業者様 ・これからB2B SaaSを開発しようと思っているスタートアップの方々 =================================================== APIファーストという考え方も徐々に浸透してきており、APIを活用しSaaS同士が連携するケースも増えてきています。 さらに、昨今では生成AIエージェントが各SaaSのAPIを活用し、業務の自動化や効率化を行うケースも見受けられます。 こういったトレンドがある中、APIが公開されていないとAPIエコシステムに参入できず、ビジネス機会を損失するリスクが高まっていると言えます。しかし、B2B SaaSがAPIを公開するには考慮すべき点も多く、簡単に進められるものではありません。 本ウェビナーでは、SaaSがAPIを公開するメリットと具体的な公開手法について解説いたします。ウェビナーを通して、API公開のメリットとコストについて具体的なイメージを持てる状態になっていただきます。 B2B SaaSにとってAPIの公開がなぜビジネス上重要なのか、API公開がどのように価値をもたらすのか、公開の具体的な手法などをお伝えいたします。 ぜひこの機会にご参加ください！ --- ## 10/17(木)11時開催「AWSを活用したパッケージ製品のSaaS化事例解説」｜録画ウェビナー URL: https://saasus.io/resource/webinar/semina-20241017 =================================================== ＼こんな方におすすめ！／ ・パッケージ製品を提供している事業者様 ・パッケージ製品のSaaS化にお悩みの企業様 ・AWSを活用したパッケージ製品のSaaS化についてご興味をお持ちの方 =================================================== ◆本セミナーは8/22に開催したセミナーの録画配信です◆ DXを進める上で、SaaS活用は非常に重要です。SaaSは業務ナレッジ・ベストプラクティスの集合で、導入する過程であらゆる業務の変革を期待できます。 SaaS活用の波に乗るべく、パッケージ製品を提供する事業者様の中には、自社製品のSaaS化を進めている事業者様も少なくありません。 しかし、従来のパッケージ製品をただそのままクラウドに乗せるだけでは、SaaSの恩恵を受けられない場合があるため、SaaSの恩恵を受けるためのポイントなどをあらかじめ理解する必要があります。 本ウェビナーでは、AWSを活用してパッケージ製品をSaaS化するプロセスやSaaS化する際に考慮すべきポイントなどを事例を交えながら解説します。 SaaSへの移行がなぜビジネスにとって重要なのか、AWSの採用がどのように価値をもたらすのかを解説し、具体的な戦略と事例を通じて、開発から運用までのポイントをご紹介しますので、ぜひこの機会にご参加ください！ --- ## 10/3(木)13時開催『クラウドを駆使した「サービス開発・運用の内製化」』 URL: https://saasus.io/resource/webinar/semina-20241003 ================================= ＼こんな方におすすめ！／ ・これから自社サービスをクラウド化（SaaS化）したい事業者様 ・新たにクラウドでサービス開発（SaaS開発含む）していきたい事業者様 ・クラウドサービス、SaaSを提供していて、運用に課題のある事業者様 ・上記を内製化で行いたい事業者様 ================================= クラウド環境という武器により、世の中の動きに合わせて迅速に変化するビジネスを支えるためのサービス開発基盤の構築が可能となりました。加えて、開発コストの削減、市場の変化に即応できる開発・運用保守対応の迅速化、さらには独自のノウハウ・ナレッジの蓄積といった要因から、開発・運用の内製化を推進する企業が増加しています。 本ウェビナーでは、クラウド環境を最大限に活用した「サービス開発・運用の内製化」を実現するための具体的な戦略と方法論を解説します。 SaaSus Platformを活用し、SaaSの開発プロセスを効率化する方法、Mackerelを用いたクラウド監視のベストプラクティスについても、具体例を交えながら詳しくご紹介しますので、クラウドを活用し内製化を進めたい企業や、既存のクラウド運用をさらに最適化したいと考えている企業の方は、是非ご視聴ください。 プログラム内容 ▼第1部：株式会社アンチパターン コアドメインに集中できる「SaaS開発/運用」の考え方 SaaSは開発してリリースをしたら終わりではなく、リリースをしてお客様に提供が開始されてからがスタートです。そして、お客様からのフィードバックや外部環境の変化に柔軟に対応し続けて、プロダクトの価値を高めていくには、アジリティを獲得する必要があります。アジリティの獲得のために内製化を進めることも検討できますが、全てを内製で実現するかどうかは慎重に検討が必要です。本セッションでは、どういった領域を内製で取り組むべきかについて、「SaaS開発の効率化」という観点を交えて解説いたします。 ▼第2部：株式会社はてな クラウド上での運用を支える「Mackerelを用いたクラウド運用・監視のベストプラクティス」 クラウド環境におけるシステムの安定性とパフォーマンスを保つためには、クラウドの特性を深く理解し、それに適した運用と監視戦略が不可欠です。このセッションでは、特にWebサービスやSaaSを提供しながら運用上の課題に直面している事業者向けに、「Mackerelを用いた効果的なクラウド運用と監視の実践」を深掘りしてお伝えします。実際の事例とデモを交え、クラウド運用の内製化を支えるMackerelの活用方法を詳しく解説し、実用的な知見をご提供します。 開催概要 クラウドを駆使した「サービス開発・運用の内製化」戦略 ～SaaS開発の効率化、クラウド運用の安定化を実現する監視のベストプラクティス～ 日時：2024年10月3日（木） 13:00〜14:00 主催：株式会社はてな（Mackerelチーム）/ 株式会社アンチパターン 会場：Zoom Webinar 参加費用：無料 --- ## 9/19(木)13時開催「AWS re:Invent 2023 セッションから学ぶ、SaaS開発に潜む5つの落とし穴」｜無料ウェビナー URL: https://saasus.io/resource/webinar/semina-20240919 【事前登録で7日間オンデマンドでもご視聴いただけます！】 ＼こんな方におすすめ！／ ・新たにSaaS開発をご検討中の企業様 ・SaaS開発における重要な検討事項を学びたい企業様 ・SaaS開発を進める中でつまづいてしまった企業様 === 日本経済の発展において、DX化を迅速に進めることは必要不可欠です。 中でもSaaS活用は、多くの企業が取り組みを始めており、また、新たなSaaSの開発も日々進められています。 しかし、SaaS開発にはSaaS特有の検討事項も多く、「いざ開発を進めたものの、途中でつまづいてしまった」「開発後にトラブルが発生してしまった」というお悩みやご相談も少なくありません。 そこで本ウェビナーでは、2023年12月に開催された“AWS re:Invent 2023”のセッションを基に、よくあるSaaS開発の5つの落とし穴について解説いたします。 SaaS開発を進める前によくある課題を理解しておくことで、開発開始後のトラブルを最小限に抑えることができます。 ぜひこの機会にご視聴ください！ --- ## 8/29(木)13時開催「コア機能開発に集中できてますか？SaaS開発効率化のための、APIファーストな考え方」 URL: https://saasus.io/resource/webinar/seminar-20240829 ★事前登録で7日間のオンデマンド配信視聴可能！★ =================================================== ＼こんな方におすすめ！／ ・新たにSaaS開発をご検討中の企業様 ・SaaS開発における重要な検討事項を学びたい企業様 ・APIを活用したSaaS開発の取り組みについて知りたい企業様 =================================================== 日本経済の発展において、DX化を迅速に進めることは必要不可欠です。 中でもSaaS活用は、多くの企業が取り組みを始めており、また、新たなSaaSの開発も日々進められています。 しかし、SaaS開発にはSaaS特有の課題も多く、また、従来型パッケージと比較して運用まで行う必要があるため、カバー範囲も多岐に渡ります。そのため開発に係る工数や検討事項も非常に多く、一からすべての機能を自社開発すると莫大なコストがかかります。 こうした課題を背景に、自社で開発するべき箇所を検討しそれ以外を既存のテクノロジーとのAPI連携で補うという考え方が、現在米国を中心に潮流となりつつあります。 本ウェビナーでは、既存のテクノロジーのAPIを活用したSaaS開発の考え方とその事例について解説いたします。 APIを上手に活用することで、SaaSのコア機能開発に集中できる環境・仕組みの構築をしませんか？ ぜひこの機会にご参加ください！ --- ## 8/22(木)11時開催「AWSを活用したパッケージ製品のSaaS化事例解説」｜無料ウェビナー URL: https://saasus.io/resource/webinar/seminar-20240822 ★事前登録で【7日間】オンデマンド視聴可能！★ =================================================== ＼こんな方におすすめ！／ ・パッケージ製品を提供している事業者様 ・パッケージ製品のSaaS化にお悩みの企業様 ・AWSを活用したパッケージ製品のSaaS化についてご興味をお持ちの方 =================================================== DXを進める上で、SaaS活用は非常に重要です。SaaSは業務ナレッジ・ベストプラクティスの集合で、導入する過程であらゆる業務の変革を期待できます。 SaaS活用の波に乗るべく、パッケージ製品を提供する事業者様の中には、自社製品のSaaS化を進めている事業者様も少なくありません。 しかし、従来のパッケージ製品をただそのままクラウドに乗せるだけでは、SaaSの恩恵を受けられない場合があるため、SaaSの恩恵を受けるためのポイントなどをあらかじめ理解する必要があります。 本ウェビナーでは、AWSを活用してパッケージ製品をSaaS化するプロセスやSaaS化する際に考慮すべきポイントなどを事例を交えながら解説します。 SaaSへの移行がなぜビジネスにとって重要なのか、AWSの採用がどのように価値をもたらすのかを解説し、具体的な戦略と事例を通じて、開発から運用までのポイントをご紹介しますので、ぜひこの機会にご参加ください！ --- ## 7/31（水）まで「B2B SaaSの最新トレンドと成長戦略徹底解説セミナー」｜オンデマンドセミナー URL: https://saasus.io/resource/webinar/seminar-20240719 ★7/31（水）までオンデマンドでご視聴いただけます ＼こんな方におすすめ！／ ・B2B SaaSエンジニアの方 ・これからSaaSの開発を進めたい企業のご担当者様 ・B2B SaaSのトレンドを学びたい方 === 技術者とエンジニアを対象に、B2B SaaS業界の最新トレンドと成長戦略を解説！ 現在、SaaS市場は急速に拡大しており、技術革新とデジタルトランスフォーメーション（DX）が進む中で、企業はますます競争力を求められています。 セミナーでは、これらの背景を踏まえ、B2B SaaSを「Horizontal/Vertical」と「Global/Local」の2軸で整理し、業界特有の動向と競争優位性をどのように築くかを解説します。 実践的な知識を得て、日々の業務にすぐに活かせる内容をお伝えします。 これからのSaaS市場での競争力を高めたい企業様にとって、絶対に見逃せないセミナーです。 ぜひご参加ください！ --- ## 7/26（金）まで「適切なアクティビティデータ収集とそれに伴う利用規約策定のポイント」｜オンデマンドセミナー URL: https://saasus.io/resource/webinar/semina-20240712 ＼こんな方におすすめ！／ ・SaaSのプロダクトオーナーの方 ・これからSaaS提供を考えてる企業のご責任者様 ・SaaSにおけるデータ収集の方法や必要性について学びたい方 ★7/26（金）までオンデマンドでご視聴いただけます === SaaSを提供するにあたり、お客様の利用状況が分かるアクティビティデータは、プロダクト改善の指針となり、顧客体験を向上させるための貴重な情報資源です。 そのため、ユーザーごとやテナントごとのアクティビティを把握することは、SaaSビジネスを成長させるために必要不可欠です。 ■アクティビティデータの例 ・どんな画面でどんな操作をしているか ・どのようなAPIをどう活用しているか ・利用頻度 ・使われている機能/使われていない機能 ・利用人数/回数 ・利用効率 など 本ウェビナーでは、SaaSビジネスを成功させるためのアクティビティデータの収集にまつわる基本的な考え方を解説。また、データ収集・利活用に欠かせない適切な利用規約の策定ポイントもあわせてお伝えします。 ぜひこの機会にご参加ください。 --- ## 6/27(木)13時開催「AWSを活用したパッケージ製品のSaaS化事例解説」 URL: https://saasus.io/resource/webinar/seminar-20240627 ＼こんな方におすすめ！／ ・パッケージ製品を提供している事業者様 ・パッケージ製品のSaaS化にお悩みの企業様 ・AWSを活用したパッケージ製品のSaaS化についてご興味をお持ちの方 ★事前登録で【7日間】オンデマンド視聴可能！ === DXを進める上で、SaaS活用は非常に重要です。SaaSは業務ナレッジ・ベストプラクティスの集合で、導入する過程であらゆる業務の変革を期待できます。 SaaS活用の波に乗るべく、パッケージ製品を提供する事業者様の中には、自社製品のSaaS化を進めている事業者様も少なくありません。 しかし、従来のパッケージ製品をただそのままクラウドに乗せるだけでは、SaaSの恩恵を受けられない場合があるため、SaaSの恩恵を受けるためのポイントなどをあらかじめ理解する必要があります。 本ウェビナーでは、AWSを活用してパッケージ製品をSaaS化するプロセスやSaaS化する際に考慮すべきポイントなどを事例を交えながら解説します。 SaaSへの移行がなぜビジネスにとって重要なのか、AWSの採用がどのように価値をもたらすのかを解説し、具体的な戦略と事例を通じて、開発から運用までのポイントをご紹介しますので、ぜひこの機会にご参加ください。 --- ## 6/18(火)13時開催「コア機能開発に集中できてますか？SaaS開発効率化のための、APIファーストな考え方」 URL: https://saasus.io/resource/webinar/seminar-20240618 ＼こんな方におすすめ！／ ・新たにSaaS開発をご検討中の企業様 ・SaaS開発における重要な検討事項を学びたい企業様 ・APIを活用したSaaS開発の取り組みについて知りたい企業様 【事前登録で7日間のオンデマンド配信視聴可能】 === 日本経済の発展において、DX化を迅速に進めることは必要不可欠です。 中でもSaaS活用は、多くの企業が取り組みを始めており、また、新たなSaaSの開発も日々進められています。 しかし、SaaS開発にはSaaS特有の課題も多く、また、従来型パッケージと比較して運用まで行う必要があるため、カバー範囲も多岐に渡ります。そのため開発に係る工数や検討事項も非常に多く、一からすべての機能を自社開発すると莫大なコストがかかります。 こうした課題を背景に、自社で開発するべき箇所を検討しそれ以外を既存のテクノロジーとのAPI連携で補うという考え方が、現在米国を中心に潮流となりつつあります。 本ウェビナーでは、既存のテクノロジーのAPIを活用したSaaS開発の考え方とその事例について解説いたします。 APIを上手に活用することで、SaaSのコア機能開発に集中できる環境・仕組みの構築をしませんか？是非この機会にご参加ください！ --- ## 5/30(木)11時開催「B2B SaaSの最新トレンドと成長戦略徹底解説セミナー」｜無料ウェビナー URL: https://saasus.io/resource/webinar/seminar-20240530 ★事前登録で【7日間】オンデマンド視聴可能！ ＼こんな方におすすめ！／ ・B2B SaaSエンジニアの方 ・これからSaaSの開発を進めたい企業のご担当者様 ・B2B SaaSのトレンドを学びたい方 === 技術者とエンジニアを対象に、B2B SaaS業界の最新トレンドと成長戦略を解説！ 現在、SaaS市場は急速に拡大しており、技術革新とデジタルトランスフォーメーション（DX）が進む中で、企業はますます競争力を求められています。 セミナーでは、これらの背景を踏まえ、B2B SaaSを「Horizontal/Vertical」と「Global/Local」の2軸で整理し、業界特有の動向と競争優位性をどのように築くかを解説します。 実践的な知識を得て、日々の業務にすぐに活かせる内容をお伝えします。 これからのSaaS市場での競争力を高めたい企業様にとって、絶対に見逃せないセミナーです。 ぜひご参加ください！ --- ## 5/9(木)13時開催「AWS re:Invent 2023 セッションから学ぶ、SaaS開発に潜む5つの落とし穴」｜無料ウェビナー URL: https://saasus.io/resource/webinar/seminar-20240509 ＼こんな方におすすめ！／ ・新たにSaaS開発をご検討中の企業様 ・SaaS開発における重要な検討事項を学びたい企業様 ・SaaS開発を進める中でつまづいてしまった企業様 ★事前登録で【7日間】オンデマンド視聴可能！ === 日本経済の発展において、DX化を迅速に進めることは必要不可欠です。 中でもSaaS活用は、多くの企業が取り組みを始めており、また、新たなSaaSの開発も日々進められています。 しかし、SaaS開発にはSaaS特有の検討事項も多く、「いざ開発を進めたものの、途中でつまづいてしまった」「開発後にトラブルが発生してしまった」というお悩みやご相談も少なくありません。 そこで本ウェビナーでは、2023年12月に開催された“AWS re:Invent 2023”のセッションを基に、よくあるSaaS開発の5つの落とし穴について解説いたします。 SaaS開発を進める前によくある課題を理解しておくことで、開発開始後のトラブルを最小限に抑えることができます。ぜひこの機会にご視聴ください！ --- ## 4/18(木)13時開催「適切なアクティビティデータ収集とそれに伴う利用規約策定のポイント」｜無料ウェビナー URL: https://saasus.io/resource/webinar/seminar-20240418 ＼こんな方におすすめ！／ ・SaaSのプロダクトオーナーの方 ・これからSaaS提供を考えてる企業のご責任者様 ・SaaSにおけるデータ収集の方法や必要性について学びたい方 ★事前登録で【7日間】オンデマンド視聴可能！ === SaaSを提供するにあたり、お客様の利用状況が分かるアクティビティデータは、プロダクト改善の指針となり、顧客体験を向上させるための貴重な情報資源です。 そのため、ユーザーごとやテナントごとのアクティビティを把握することは、SaaSビジネスを成長させるために必要不可欠です。 ■アクティビティデータの例 ・どんな画面でどんな操作をしているか ・どのようなAPIをどう活用しているか ・利用頻度 ・使われている機能/使われていない機能 ・利用人数/回数 ・利用効率 など 本ウェビナーでは、SaaSビジネスを成功させるためのアクティビティデータの収集にまつわる基本的な考え方を解説。また、データ収集・利活用に欠かせない適切な利用規約の策定ポイントもあわせてお伝えします。 ぜひこの機会にご参加ください。 --- ## 4/11(木)13時開催「AWSを活用したパッケージ製品のSaaS化事例解説」｜無料ウェビナー URL: https://saasus.io/resource/webinar/seminar-20240411 ＼こんな方におすすめ！／ ・パッケージ製品を提供している事業者様 ・パッケージ製品のSaaS化にお悩みの企業様 ・AWSを活用したパッケージ製品のSaaS化についてご興味をお持ちの方 ★事前登録で【7日間】オンデマンド視聴可能！ === DXを進める上で、SaaS活用は非常に重要です。SaaSは業務ナレッジ・ベストプラクティスの集合で、導入する過程であらゆる業務の変革を期待できます。 SaaS活用の波に乗るべく、パッケージ製品を提供する事業者様の中には、自社製品のSaaS化を進めている事業者様も少なくありません。 しかし、従来のパッケージ製品をただそのままクラウドに乗せるだけでは、SaaSの恩恵を受けられない場合があるため、SaaSの恩恵を受けるためのポイントなどをあらかじめ理解する必要があります。 本ウェビナーでは、AWSを活用してパッケージ製品をSaaS化するプロセスやSaaS化する際に考慮すべきポイントなどを事例を交えながら解説します。 SaaSへの移行がなぜビジネスにとって重要なのか、AWSの採用がどのように価値をもたらすのかを解説し、具体的な戦略と事例を通じて、開発から運用までのポイントをご紹介しますので、ぜひこの機会にご参加ください。 --- ## 3/21(木)13時開催「AWS re:Invent 2023 セッションから学ぶ、SaaS開発に潜む5つの落とし穴」｜無料ウェビナー URL: https://saasus.io/resource/webinar/seminar-20240321 ＼こんな方におすすめ！／ ・新たにSaaS開発をご検討中の企業様 ・SaaS開発における重要な検討事項を学びたい企業様 ・SaaS開発を進める中でつまづいてしまった企業様 ※事前登録で7日間オンデマンド配信もご視聴いただけます === 日本経済の発展において、DX化を迅速に進めることは必要不可欠です。 中でもSaaS活用は、多くの企業が取り組みを始めており、また、新たなSaaSの開発も日々進められています。 しかし、SaaS開発にはSaaS特有の検討事項も多く、「いざ開発を進めたものの、途中でつまづいてしまった」「開発後にトラブルが発生してしまった」というお悩みやご相談も少なくありません。 そこで本ウェビナーでは、2023年12月に開催された"AWS re:Invent 2023"のセッションを基に、よくあるSaaS開発の5つの落とし穴について、テナントやTierなどの概念に触れながら、よりテクニカルな課題/解決策をお話します。 SaaS開発を進める前によくある課題を理解しておくことで、開発開始後のトラブルを最小限に抑えることができます。ぜひこの機会にご視聴ください！ --- ## 3/6(水)13時開催「コア機能開発に集中できてますか？SaaS開発効率化のための、APIファーストな考え方」｜無料ウェビナー URL: https://saasus.io/resource/webinar/seminar-20240306 ＼こんな方におすすめ！／ ・新たにSaaS開発をご検討中の企業様 ・SaaS開発における重要な検討事項を学びたい企業様 ・APIを活用したSaaS開発の取り組みについて知りたい企業様 === 日本経済の発展において、DX化を迅速に進めることは必要不可欠です。 中でもSaaS活用は、多くの企業が取り組みを始めており、また、新たなSaaSの開発も日々進められています。 しかし、SaaS開発にはSaaS特有の課題も多く、また、従来型パッケージと比較して運用まで行う必要があるため、カバー範囲も多岐に渡ります。そのため開発に係る工数や検討事項も非常に多く、一からすべての機能を自社開発すると莫大なコストがかかります。 こうした課題を背景に、自社で開発するべき箇所を検討しそれ以外を既存のテクノロジーとのAPI連携で補うという考え方が、現在米国を中心に潮流となりつつあります。 本ウェビナーでは、既存のテクノロジーのAPIを活用したSaaS開発の考え方とその事例について解説いたします。 APIを上手に活用することで、SaaSのコア機能開発に集中できる環境・仕組みの構築をしませんか？是非この機会にご参加ください！ --- ## 2/28(水)13時開催「AWSを活用したパッケージ製品のSaaS化事例解説」｜無料ウェビナー URL: https://saasus.io/resource/webinar/seminar-20240228 ＼こんな方におすすめ！／ ・パッケージ製品を提供している事業者様 ・パッケージ製品のSaaS化にお悩みの企業様 ・AWSを活用したパッケージ製品のSaaS化についてご興味をお持ちの方 === DXを進める上で、SaaS活用は非常に重要です。SaaSは業務ナレッジ・ベストプラクティスの集合で、導入する過程であらゆる業務の変革を期待できます。 SaaS活用の波に乗るべく、パッケージ製品を提供する事業者様の中には、自社製品のSaaS化を進めている事業者様も少なくありません。 しかし、従来のパッケージ製品をただそのままクラウドに乗せるだけでは、SaaSの恩恵を受けられない場合があるため、SaaSの恩恵を受けるためのポイントなどをあらかじめ理解する必要があります。 本ウェビナーでは、AWSを活用してパッケージ製品をSaaS化するプロセスやSaaS化する際に考慮すべきポイントなどを事例を交えながら解説します。 SaaSへの移行がなぜビジネスにとって重要なのか、AWSの採用がどのように価値をもたらすのかを解説し、具体的な戦略と事例を通じて、開発から運用までのポイントをご紹介しますので、ぜひこの機会にご参加ください。 --- ## SaaS開発ガイド【テナント編】 URL: https://saasus.io/resource/e-book/saas-dev-guide-tenant 全33ページのE-Bookを現在無料公開中です！ SaaS開発支援プラットフォーム「SaaSus Platform」の開発者の視点から、初めてのSaaS開発に向けて必要な心得をE-Bookにまとめました。こちらの資料では、SaaSにおけるテナントの概念からテナント分離の設計～運用などを分かりやすく解説しています。このE-Bookがより効率的なSaaS開発の一助になれば幸いです。 目次 1. SaaSにおけるテナントの概念を知ろう - SaaS提供事業者の責任 - テナント分離の必要性 　1）セキュリティ対策として 　2）ノイジーネイバー対策として - テナント分離のポイント（設計・構築編） 　1）セキュリティ・ガバナンスの担保 　2）サービス継続性担保のためのテナントの活動状況可視化 　3）テナントティアの考慮 　4）価格モデルとコスト効率 　5）テナントを意識したテスト 　6）カスタマイズの考え方 - テナント分離のポイント（運用編） 　1）テナントオンボーディング 　2）モニタリング 　3）インフラ間でのテナント移動 　4）テナントの統合・分割 　5）オフボード 2. テナントの分離モデルを知ろう -それぞれのテナント分離モデル -データパーティショニング -テナント分離のポイント --- ## SaaS開発ガイド【基礎編】 URL: https://saasus.io/resource/e-book/saas-dev-guide-basic 全43ページのE-Bookを現在無料公開中です！ SaaS開発支援プラットフォーム「SaaSus Platform」の開発者の視点から、初めてのSaaS開発に向けて必要な心得をE-Bookにまとめました。SaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。このE-Bookがより効率的なSaaS開発の一助になれば幸いです。 目次 1.SaaSにおけるソフトウェア開発の重要性 - SaaS提供事業者の責任 - 成長ステージ毎に考慮すべきSaaS運営のポイント - SaaS立ち上げ前に知っておきたい開発の進め方 2.SaaSにおけるソフトウェア開発の勘所 SaaS立ち上げ前に知っておきたい開発の進め方 -BizDevOps -MVP / プロトタイプ SaaS開発時に考慮すべき6つのポイント 01. テナントという概念の考慮 02. 迅速なサービス改善を実現するアーキテクチャの検討 03. セキュリティの強化 04. 拡張性の担保 05. 料金プランの設計と請求方法の確立 06. データの活用 --- ## [PHP(Laravel)版]7/27(木)SaaSus Platform体験会開催@表参道のお知らせ URL: https://saasus.io/resource/offline-event/saasus-experience-session-20230727 こんにちは！SaaSus Platform運営チームです。 実際にSaaSus Platformを用いてサンプルアプリをSaaS化する「SaaSus Platform体験会」のPHP(Laravel)版をご案内いたします！ 対面(@表参道)による少人数制での開催のため、参加枠には限りがございますので、 SaaS開発にご興味ある方や、SaaSus Platformを実際に触って体験してみたい方は、ぜひお早めにお申し込みください。 [SaaSus Platform とは] 一般的なwebアプリと比較してSaaSの提供は課題が沢山あり、難易度が格段に高いです。 これらの課題を解決するために、SaaS開発に最低限必要な共通部分のベストプラクティスやアンチパターンを考慮して、SaaS開発に必要な機能を幅広く提供するのがSaaSus Platformです。 SaaSus Platform体験会では、実際にSaaSus Platformを用いてサンプルアプリをSaaS化することで、SaaSus Platformの魅力を体験していただきます。 SaaS開発で考慮すべき点を抑えながら、WebアプリをSaaS化する過程をSaaSus Platformで一緒に体験してみませんか？ [日程] 7月 27日 (木)　17:00～20:00 [開催場所] HarborS表参道(エンジニア特化型コワーキングスペース) (〒107-0062 東京都港区南青山３丁目１５−９ MINOWA表参道 ３階) ※会場のエレベータは３階のボタンが２つ付いております。「3F 会議室」のボタンを押してください。 [メンター] 株式会社アンチパターン　SaaSus Platform インフラエンジニア　小谷 [こんな方へおすすめ] これからSaaSの開発に関わりそうな方 SaaSus Platformに興味がある方/実際に触れてみたい方 SaaSus Platformのチュートリアルを説明を聞きながらやりたい方 [当日のアジェンダ] 体験会の中でSaaS化するサンプルアプリのセットアップ SaaSus Platformのご紹介 SaaS開発のポイントを簡単にご紹介 本日のSaaSus Platfrom体験会でできること SaaSus Platformのチュートリアル Q&A [注意事項] 使用言語はPHP(Laravel)となっておりますので、ご承知お願いいたします。 お申し込み人数が3人を超えた場合、別日程でお願いする可能性がございますので、ご了承ください。 [準備事項] 当日までに以下のご準備をお願いいたします。 PCにインストールしていただくアプリ ・Docker ・VScode その他ご用意いただくもの ・SaaSus Platformのフリープランアカウント 　※以下リンクよりセルフサインアップでご登録いただけます。(https://auth.saasus.io/sign-up) なお、アカウント有効化まで最短1時間程度お時間がかかるため、【当日13:00】までに以下をお済ませください。 　　１）セルフサインアップ 　　２）アカウントの有効化（検証コード入力） 　　３）初回ログイン [備考] 体験会は今後も定期的に開催予定です！ 開催日に予定が合わない方は、ぜひトップページの最新情報を受け取るボタンからフォーム登録して、今後のイベント情報を取得してください！ --- ## [PHP(Laravel)版]7/20(木)SaaSus Platform体験会開催@表参道のお知らせ URL: https://saasus.io/resource/offline-event/saasus-experience-session-20230720 こんにちは！SaaSus Platform運営チームです。 実際にSaaSus Platformを用いてサンプルアプリをSaaS化する「SaaSus Platform体験会」のPHP(Laravel)版をご案内いたします！ 対面(@表参道)による少人数制での開催のため、参加枠には限りがございますので、 SaaS開発にご興味ある方や、SaaSus Platformを実際に触って体験してみたい方は、ぜひお早めにお申し込みください。 [SaaSus Platform とは] 一般的なwebアプリと比較してSaaSの提供は課題が沢山あり、難易度が格段に高いです。 これらの課題を解決するために、SaaS開発に最低限必要な共通部分のベストプラクティスやアンチパターンを考慮して、SaaS開発に必要な機能を幅広く提供するのがSaaSus Platformです。 SaaSus Platform体験会では、実際にSaaSus Platformを用いてサンプルアプリをSaaS化することで、SaaSus Platformの魅力を体験していただきます。 SaaS開発で考慮すべき点を抑えながら、WebアプリをSaaS化する過程をSaaSus Platformで一緒に体験してみませんか？ [日程] 7月 20日 (木)　17:00～20:00 [開催場所] HarborS表参道(エンジニア特化型コワーキングスペース) (〒107-0062 東京都港区南青山３丁目１５−９ MINOWA表参道 ３階) ※会場のエレベータは３階のボタンが２つ付いております。「3F 会議室」のボタンを押してください。 [メンター] 株式会社アンチパターン　SaaSus Platform インフラエンジニア　小谷 [こんな方へおすすめ] これからSaaSの開発に関わりそうな方 SaaSus Platformに興味がある方/実際に触れてみたい方 SaaSus Platformのチュートリアルを説明を聞きながらやりたい方 [当日のアジェンダ] 体験会の中でSaaS化するサンプルアプリのセットアップ SaaSus Platformのご紹介 SaaS開発のポイントを簡単にご紹介 本日のSaaSus Platfrom体験会でできること SaaSus Platformのチュートリアル Q&A [注意事項] 使用言語はPHP(Laravel)となっておりますので、ご承知お願いいたします。 お申し込み人数が3人を超えた場合、別日程でお願いする可能性がございますので、ご了承ください。 [準備事項] 当日までに以下のご準備をお願いいたします。 PCにインストールしていただくアプリ ・Docker ・VScode その他ご用意いただくもの ・SaaSus Platformのフリープランアカウント 　※以下リンクよりセルフサインアップでご登録いただけます。(https://auth.saasus.io/sign-up) なお、アカウント有効化まで最短1時間程度お時間がかかるため、【当日13:00】までに以下をお済ませください。 　　１）セルフサインアップ 　　２）アカウントの有効化（検証コード入力） 　　３）初回ログイン [備考] 体験会は今後も定期的に開催予定です！ 開催日に予定が合わない方は、ぜひトップページの最新情報を受け取るボタンからフォーム登録して、今後のイベント情報を取得してください！ --- ## [PHP(Laravel)版]7/13(木)SaaSus Platform体験会開催@表参道のお知らせ URL: https://saasus.io/resource/offline-event/saasus-experience-session-20230713 こんにちは！SaaSus Platform運営チームです。 実際にSaaSus Platformを用いてサンプルアプリをSaaS化する「SaaSus Platform体験会」のPHP(Laravel)版をご案内いたします！ 対面(@表参道)による少人数制での開催のため、参加枠には限りがございますので、 SaaS開発にご興味ある方や、SaaSus Platformを実際に触って体験してみたい方は、ぜひお早めにお申し込みください。 [SaaSus Platform とは] 一般的なwebアプリと比較してSaaSの提供は課題が沢山あり、難易度が格段に高いです。 これらの課題を解決するために、SaaS開発に最低限必要な共通部分のベストプラクティスやアンチパターンを考慮して、SaaS開発に必要な機能を幅広く提供するのがSaaSus Platformです。 SaaSus Platform体験会では、実際にSaaSus Platformを用いてサンプルアプリをSaaS化することで、SaaSus Platformの魅力を体験していただきます。 SaaS開発で考慮すべき点を抑えながら、WebアプリをSaaS化する過程をSaaSus Platformで一緒に体験してみませんか？ [日程] 7月 13日 (木)　17:00～20:00 [開催場所] HarborS表参道(エンジニア特化型コワーキングスペース) (〒107-0062 東京都港区南青山３丁目１５−９ MINOWA表参道 ３階) ※会場のエレベータは３階のボタンが２つ付いております。「3F 会議室」のボタンを押してください。 [メンター] 株式会社アンチパターン　SaaSus Platform インフラエンジニア　小谷 [こんな方へおすすめ] これからSaaSの開発に関わりそうな方 SaaSus Platformに興味がある方/実際に触れてみたい方 SaaSus Platformのチュートリアルを説明を聞きながらやりたい方 [当日のアジェンダ] 体験会の中でSaaS化するサンプルアプリのセットアップ SaaSus Platformのご紹介 SaaS開発のポイントを簡単にご紹介 本日のSaaSus Platfrom体験会でできること SaaSus Platformのチュートリアル Q&A [注意事項] 使用言語はPHP(Laravel)となっておりますので、ご承知お願いいたします。 お申し込み人数が3人を超えた場合、別日程でお願いする可能性がございますので、ご了承ください。 [準備事項] 当日までに以下のご準備をお願いいたします。 PCにインストールしていただくアプリ ・Docker ・VScode その他ご用意いただくもの ・SaaSus Platformのフリープランアカウント 　※以下リンクよりセルフサインアップでご登録いただけます。(https://auth.saasus.io/sign-up) なお、アカウント有効化まで最短1時間程度お時間がかかるため、【当日13:00】までに以下をお済ませください。 　　１）セルフサインアップ 　　２）アカウントの有効化（検証コード入力） 　　３）初回ログイン [備考] 体験会は今後も定期的に開催予定です！ 開催日に予定が合わない方は、ぜひトップページの最新情報を受け取るボタンからフォーム登録して、今後のイベント情報を取得してください！ --- ## [PHP(Laravel)版]6/29(木)SaaSus Platform体験会開催@表参道のお知らせ URL: https://saasus.io/resource/offline-event/saasus-experience-session-20230629 こんにちは！SaaSus Platform運営チームです。 実際にSaaSus Platformを用いてサンプルアプリをSaaS化する「SaaSus Platform体験会」のPHP(Laravel)版をご案内いたします！ 対面(@表参道)による少人数制での開催のため、参加枠には限りがございますので、 SaaS開発にご興味ある方や、SaaSus Platformを実際に触って体験してみたい方は、ぜひお早めにお申し込みください。 [SaaSus Platform とは] 一般的なwebアプリと比較してSaaSの提供は課題が沢山あり、難易度が格段に高いです。 これらの課題を解決するために、SaaS開発に最低限必要な共通部分のベストプラクティスやアンチパターンを考慮して、SaaS開発に必要な機能を幅広く提供するのがSaaSus Platformです。 SaaSus Platform体験会では、実際にSaaSus Platformを用いてサンプルアプリをSaaS化することで、SaaSus Platformの魅力を体験していただきます。 SaaS開発で考慮すべき点を抑えながら、WebアプリをSaaS化する過程をSaaSus Platformで一緒に体験してみませんか？ [日程] 6月 29日 (木)　17:00～20:00 [開催場所] HarborS表参道(エンジニア特化型コワーキングスペース) (〒107-0062 東京都港区南青山３丁目１５−９ MINOWA表参道 ３階) ※会場のエレベータは３階のボタンが２つ付いております。「3F 会議室」のボタンを押してください。 [メンター] 株式会社アンチパターン　SaaSus Platform インフラエンジニア　小谷 [こんな方へおすすめ] これからSaaSの開発に関わりそうな方 SaaSus Platformに興味がある方/実際に触れてみたい方 SaaSus Platformのチュートリアルを説明を聞きながらやりたい方 [当日のアジェンダ] 体験会の中でSaaS化するサンプルアプリのセットアップ SaaSus Platformのご紹介 SaaS開発のポイントを簡単にご紹介 本日のSaaSus Platfrom体験会でできること SaaSus Platformのチュートリアル Q&A [注意事項] 使用言語はPHP(Laravel)となっておりますので、ご承知お願いいたします。 お申し込み人数が3人を超えた場合、別日程でお願いする可能性がございますので、ご了承ください。 [準備事項] 当日までに以下のご準備をお願いいたします。 PCにインストールしていただくアプリ ・Docker ・VScode その他ご用意いただくもの ・SaaSus Platformのフリープランアカウント 　※以下リンクよりセルフサインアップでご登録いただけます。(https://auth.saasus.io/sign-up) なお、アカウント有効化まで最短1時間程度お時間がかかるため、【当日13:00】までに以下をお済ませください。 　　１）セルフサインアップ 　　２）アカウントの有効化（検証コード入力） 　　３）初回ログイン [備考] 体験会は今後も定期的に開催予定です！ 開催日に予定が合わない方は、ぜひトップページの最新情報を受け取るボタンからフォーム登録して、今後のイベント情報を取得してください！ --- ## [PHP(Laravel)版]6/15(木)SaaSus Platform体験会開催@表参道のお知らせ URL: https://saasus.io/resource/offline-event/saasus-experience-session-20230615 こんにちは！SaaSus Platform運営チームです。 実際にSaaSus Platformを用いてサンプルアプリをSaaS化する「SaaSus Platform体験会」のPHP(Laravel)版をご案内いたします！ 対面(@表参道)による少人数制での開催のため、参加枠には限りがございますので、 SaaS開発にご興味ある方や、SaaSus Platformを実際に触って体験してみたい方は、ぜひお早めにお申し込みください。 [SaaSus Platform とは] 一般的なwebアプリと比較してSaaSの提供は課題が沢山あり、難易度が格段に高いです。 これらの課題を解決するために、SaaS開発に最低限必要な共通部分のベストプラクティスやアンチパターンを考慮して、SaaS開発に必要な機能を幅広く提供するのがSaaSus Platformです。 SaaSus Platform体験会では、実際にSaaSus Platformを用いてサンプルアプリをSaaS化することで、SaaSus Platformの魅力を体験していただきます。 SaaS開発で考慮すべき点を抑えながら、WebアプリをSaaS化する過程をSaaSus Platformで一緒に体験してみませんか？ [日程] 6月 15日 (木)　17:00～20:00 [開催場所] HarborS表参道(エンジニア特化型コワーキングスペース) (〒107-0062 東京都港区南青山３丁目１５−９ MINOWA表参道 ３階) ※会場のエレベータは３階のボタンが２つ付いております。「3F 会議室」のボタンを押してください。 [メンター] 株式会社アンチパターン　SaaSus Platform インフラエンジニア　小谷 [こんな方へおすすめ] これからSaaSの開発に関わりそうな方 SaaSus Platformに興味がある方/実際に触れてみたい方 SaaSus Platformのチュートリアルを説明を聞きながらやりたい方 [当日のアジェンダ] 体験会の中でSaaS化するサンプルアプリのセットアップ SaaSus Platformのご紹介 SaaS開発のポイントを簡単にご紹介 本日のSaaSus Platfrom体験会でできること SaaSus Platformのチュートリアル Q&A [注意事項] 使用言語はPHP(Laravel)となっておりますので、ご承知お願いいたします。 お申し込み人数が3人を超えた場合、別日程でお願いする可能性がございますので、ご了承ください。 [準備事項] 当日までに以下のご準備をお願いいたします。 PCにインストールしていただくアプリ ・Docker ・VScode その他ご用意いただくもの ・SaaSus Platformのフリープランアカウント 　※以下リンクよりセルフサインアップでご登録いただけます。(https://auth.saasus.io/sign-up) なお、アカウント有効化まで最短1時間程度お時間がかかるため、【当日13:00】までに以下をお済ませください。 　　１）セルフサインアップ 　　２）アカウントの有効化（検証コード入力） 　　３）初回ログイン [備考] 体験会は今後も定期的に開催予定です！ 開催日に予定が合わない方は、ぜひトップページの最新情報を受け取るボタンからフォーム登録して、今後のイベント情報を取得してください！ --- ## [PHP(Laravel)版]6/8(木)SaaSus Platform体験会開催@表参道のお知らせ URL: https://saasus.io/resource/offline-event/saasus-experience-session-20230608 こんにちは！SaaSus Platform運営チームです。 実際にSaaSus Platformを用いてサンプルアプリをSaaS化する「SaaSus Platform体験会」のPHP(Laravel)版をご案内いたします！ 対面(@表参道)による少人数制での開催のため、参加枠には限りがございますので、 SaaS開発にご興味ある方や、SaaSus Platformを実際に触って体験してみたい方は、ぜひお早めにお申し込みください。 [SaaSus Platform とは] 一般的なwebアプリと比較してSaaSの提供は課題が沢山あり、難易度が格段に高いです。 これらの課題を解決するために、SaaS開発に最低限必要な共通部分のベストプラクティスやアンチパターンを考慮して、SaaS開発に必要な機能を幅広く提供するのがSaaSus Platformです。 SaaSus Platform体験会では、実際にSaaSus Platformを用いてサンプルアプリをSaaS化することで、SaaSus Platformの魅力を体験していただきます。 SaaS開発で考慮すべき点を抑えながら、WebアプリをSaaS化する過程をSaaSus Platformで一緒に体験してみませんか？ [日程] 6月 8日 (木)　17:00～20:00 [開催場所] HarborS表参道(エンジニア特化型コワーキングスペース) (〒107-0062 東京都港区南青山３丁目１５−９ MINOWA表参道 ３階) ※会場のエレベータは３階のボタンが２つ付いております。「3F 会議室」のボタンを押してください。 [メンター] 株式会社アンチパターン　SaaSus Platform インフラエンジニア　小谷 [こんな方へおすすめ] これからSaaSの開発に関わりそうな方 SaaSus Platformに興味がある方/実際に触れてみたい方 SaaSus Platformのチュートリアルを説明を聞きながらやりたい方 [当日のアジェンダ] 体験会の中でSaaS化するサンプルアプリのセットアップ SaaSus Platformのご紹介 SaaS開発のポイントを簡単にご紹介 本日のSaaSus Platfrom体験会でできること SaaSus Platformのチュートリアル Q&A [注意事項] 使用言語はPHP(Laravel)となっておりますので、ご承知お願いいたします。 お申し込み人数が3人を超えた場合、別日程でお願いする可能性がございますので、ご了承ください。 [準備事項] 当日までに以下のご準備をお願いいたします。 PCにインストールしていただくアプリ ・Docker ・VScode その他ご用意いただくもの ・SaaSus Platformのフリープランアカウント 　※こちらよりセルフサインアップでご登録いただけます。 なお、アカウント有効化まで最短1時間程度お時間がかかるため、【当日13:00】までに以下をお済ませください。 　　１）セルフサインアップ 　　２）アカウントの有効化（検証コード入力） 　　３）初回ログイン [備考] 体験会は今後も定期的に開催予定です！ 開催日に予定が合わない方は、ぜひトップページの最新情報を受け取るボタンからフォーム登録して、今後のイベント情報を取得してください！ --- ## [PHP(Laravel)版]6/1(木)SaaSus Platform体験会開催@表参道のお知らせ URL: https://saasus.io/resource/offline-event/saasus-experience-session-20230601 こんにちは！SaaSus Platform運営チームです。 実際にSaaSus Platformを用いてサンプルアプリをSaaS化する「SaaSus Platform体験会」のPHP(Laravel)版をご案内いたします！ 対面(@表参道)による少人数制での開催のため、参加枠には限りがございますので、 SaaS開発にご興味ある方や、SaaSus Platformを実際に触って体験してみたい方は、ぜひお早めにお申し込みください。 [SaaSus Platform とは] 一般的なwebアプリと比較してSaaSの提供は課題が沢山あり、難易度が格段に高いです。 これらの課題を解決するために、SaaS開発に最低限必要な共通部分のベストプラクティスやアンチパターンを考慮して、SaaS開発に必要な機能を幅広く提供するのがSaaSus Platformです。 SaaSus Platform体験会では、実際にSaaSus Platformを用いてサンプルアプリをSaaS化することで、SaaSus Platformの魅力を体験していただきます。 SaaS開発で考慮すべき点を抑えながら、WebアプリをSaaS化する過程をSaaSus Platformで一緒に体験してみませんか？ [日程] 6月 1日 (木)　17:00～20:00 [開催場所] HarborS表参道(エンジニア特化型コワーキングスペース) (〒107-0062 東京都港区南青山３丁目１５−９ MINOWA表参道 ３階) ※会場のエレベータは３階のボタンが２つ付いております。「3F 会議室」のボタンを押してください。 [メンター] 株式会社アンチパターン　SaaSus Platform インフラエンジニア　小谷 [こんな方へおすすめ] これからSaaSの開発に関わりそうな方 SaaSus Platformに興味がある方/実際に触れてみたい方 SaaSus Platformのチュートリアルを説明を聞きながらやりたい方 [当日のアジェンダ] 体験会の中でSaaS化するサンプルアプリのセットアップ SaaSus Platformのご紹介 SaaS開発のポイントを簡単にご紹介 本日のSaaSus Platfrom体験会でできること SaaSus Platformのチュートリアル Q&A [注意事項] 使用言語はPHP(Laravel)となっておりますので、ご承知お願いいたします。 お申し込み人数が3人を超えた場合、別日程でお願いする可能性がございますので、ご了承ください。 [準備事項] 当日までに以下のご準備をお願いいたします。 PCにインストールしていただくアプリ ・Docker ・VScode その他ご用意いただくもの ・SaaSus Platformのフリープランアカウント 　※公式サイトよりセルフサインアップでご登録いただけます。（https://www.saasus.io/） なお、アカウント有効化まで最短1時間程度お時間がかかるため、【当日13:00】までに以下をお済ませください。 　　１）セルフサインアップ 　　２）アカウントの有効化（検証コード入力） 　　３）初回ログイン [備考] 体験会は今後も定期的に開催予定です！ 開催日に予定が合わない方は、ぜひトップページの最新情報を受け取るボタンからフォーム登録して、今後のイベント情報を取得してください！ --- ## [PHP(Laravel)版]5/25(木)SaaSus Platform体験会開催@表参道のお知らせ URL: https://saasus.io/resource/offline-event/saasus-experience-session-20230525 こんにちは！SaaSus Platform運営チームです。 実際にSaaSus Platformを用いてサンプルアプリをSaaS化する「SaaSus Platform体験会」のPHP(Laravel)版をご案内いたします！ 対面(@表参道)による少人数制での開催のため、参加枠には限りがございますので、 SaaS開発にご興味ある方や、SaaSus Platformを実際に触って体験してみたい方は、ぜひお早めにお申し込みください。 [SaaSus Platform とは] 一般的なwebアプリと比較してSaaSの提供は課題が沢山あり、難易度が格段に高いです。 これらの課題を解決するために、SaaS開発に最低限必要な共通部分のベストプラクティスやアンチパターンを考慮して、SaaS開発に必要な機能を幅広く提供するのがSaaSus Platformです。 SaaSus Platform体験会では、実際にSaaSus Platformを用いてサンプルアプリをSaaS化することで、SaaSus Platformの魅力を体験していただきます。 SaaS開発で考慮すべき点を抑えながら、WebアプリをSaaS化する過程をSaaSus Platformで一緒に体験してみませんか？ [日程] 5月 25日 (木)　17:00～20:00 [開催場所] HarborS表参道(エンジニア特化型コワーキングスペース) (〒107-0062 東京都港区南青山３丁目１５−９ MINOWA表参道 ３階) ※会場のエレベータは３階のボタンが２つ付いております。「3F 会議室」のボタンを押してください。 [メンター] 株式会社アンチパターン　SaaSus Platform インフラエンジニア　小谷 [こんな方へおすすめ] これからSaaSの開発に関わりそうな方 SaaSus Platformに興味がある方/実際に触れてみたい方 SaaSus Platformのチュートリアルを説明を聞きながらやりたい方 [当日のアジェンダ] 体験会の中でSaaS化するサンプルアプリのセットアップ SaaSus Platformのご紹介 SaaS開発のポイントを簡単にご紹介 本日のSaaSus Platfrom体験会でできること SaaSus Platformのチュートリアル Q&A [注意事項] 使用言語はPHP(Laravel)となっておりますので、ご承知お願いいたします。 お申し込み人数が3人を超えた場合、別日程でお願いする可能性がございますので、ご了承ください。 [準備事項] 当日までに以下のご準備をお願いいたします。 PCにインストールしていただくアプリ ・Docker ・VScode その他ご用意いただくもの ・SaaSus Platformのフリープランアカウント 　※公式サイトよりセルフサインアップでご登録いただけます。（https://www.saasus.io/） なお、アカウント有効化まで最短1時間程度お時間がかかるため、【当日13:00】までに以下をお済ませください。 　　１）セルフサインアップ 　　２）アカウントの有効化（検証コード入力） 　　３）初回ログイン [備考] 体験会は今後も定期的に開催予定です！ 開催日に予定が合わない方は、ぜひトップページの最新情報を受け取るボタンからフォーム登録して、今後のイベント情報を取得してください！ --- ## [PHP(Laravel)版]第22回SaaSus Platform体験会開催のお知らせ URL: https://saasus.io/resource/offline-event/saasus-experience-session-20230518 こんにちは！SaaSus Platform運営チームです。 実際にSaaSus Platformを用いてサンプルアプリをSaaS化する「SaaSus Platform体験会」のPHP(Laravel)版、第22回をご案内いたします！ 少人数制での開催のため参加枠には限りがございますので、 アプリのSaaS化にご興味ある方や、SaaSus Platformを実際に触って体験してみたい方は、ぜひお早めにお申し込みください。 [SaaSus Platform とは] 一般的なwebアプリと比較してSaaSの提供は課題が沢山あり、難易度が格段に高いです。 これらの課題を解決するために、SaaS開発に最低限必要な共通部分のベストプラクティスやアンチパターンを考慮して、SaaS開発に必要な機能を幅広く提供するのがSaaSus Platformです。 SaaSus Platform体験会では、実際にSaaSus Platformを用いてサンプルアプリをSaaS化することで、SaaSus Platformの魅力を体験していただきます。 SaaS開発で考慮すべき点を抑えながら、WebアプリをSaaS化する過程をSaaSus Platformで一緒に体験してみませんか？ [日程] 5月 18日 (木)　17:00～20:00 [開催場所] HarborS表参道(エンジニア特化型コワーキングスペース) (〒107-0062 東京都港区南青山３丁目１５−９ MINOWA表参道 ３階) ※会場のエレベータは３階のボタンが２つ付いております。「3F 会議室」のボタンを押してください。 [メンター] 株式会社アンチパターン　SaaSus Platform インフラエンジニア　小谷 [こんな方へおすすめ] これからSaaSの開発に関わりそうな方 SaaSus Platformに興味がある方/実際に触れてみたい方 SaaSus Platformのチュートリアルを説明を聞きながらやりたい方 [当日のアジェンダ] 体験会の中でSaaS化するサンプルアプリのセットアップ SaaSus Platformのご紹介 SaaS開発のポイントを簡単にご紹介 本日のSaaSus Platfrom体験会でできること SaaSus Platformのチュートリアル Q&A [注意事項] 使用言語はPHP(Laravel)となっておりますので、ご承知お願いいたします。 お申し込み人数が3人を超えた場合、別日程でお願いする可能性がございますので、ご了承ください。 [準備事項] また、当日までに以下のご準備をお願いいたします。 PCにインストールしていただくアプリ ・Docker ・VScode その他ご用意いただくもの ・SaaSus Platformのフリープランアカウント 　※公式サイトよりセルフサインアップでご登録いただけます。（https://www.saasus.io/） なお、アカウント有効化まで最短1時間程度お時間がかかるため、【当日13:00】までに以下をお済ませください。 　　１）セルフサインアップ 　　２）アカウントの有効化（検証コード入力） 　　３）初回ログイン [備考] 体験会は今後も定期的に開催予定です！ 開催日に予定が合わない方は、ぜひトップページの最新情報を受け取るボタンからフォーム登録して、今後のイベント情報を取得してください！ --- ## [PHP(Laravel)版]第21回SaaSus Platform体験会開催のお知らせ URL: https://saasus.io/resource/offline-event/saasus-experience-session-20230511 こんにちは！SaaSus Platform運営チームです。 実際にSaaSus Platformを用いてサンプルアプリをSaaS化する「SaaSus Platform体験会」のPHP(Laravel)版、第21回をご案内いたします！ 少人数制での開催のため参加枠には限りがございますので、 アプリのSaaS化にご興味ある方や、SaaSus Platformを実際に触って体験してみたい方は、ぜひお早めにお申し込みください。 [SaaSus Platform とは] 一般的なwebアプリと比較してSaaSの提供は課題が沢山あり、難易度が格段に高いです。 これらの課題を解決するために、SaaS開発に最低限必要な共通部分のベストプラクティスやアンチパターンを考慮して、SaaS開発に必要な機能を幅広く提供するのがSaaSus Platformです。 SaaSus Platform体験会では、実際にSaaSus Platformを用いてサンプルアプリをSaaS化することで、SaaSus Platformの魅力を体験していただきます。 SaaS開発で考慮すべき点を抑えながら、WebアプリをSaaS化する過程をSaaSus Platformで一緒に体験してみませんか？ [日程] 5月 11日 (木)　17:00～20:00 [開催場所] HarborS表参道(エンジニア特化型コワーキングスペース) (〒107-0062 東京都港区南青山３丁目１５−９ MINOWA表参道 ３階) ※会場のエレベータは３階のボタンが２つ付いております。「3F 会議室」のボタンを押してください。 [メンター] 株式会社アンチパターン　SaaSus Platform インフラエンジニア　小谷 [こんな方へおすすめ] これからSaaSの開発に関わりそうな方 SaaSus Platformに興味がある方/実際に触れてみたい方 SaaSus Platformのチュートリアルを説明を聞きながらやりたい方 [当日のアジェンダ] 体験会の中でSaaS化するサンプルアプリのセットアップ SaaSus Platformのご紹介 SaaS開発のポイントを簡単にご紹介 本日のSaaSus Platfrom体験会でできること SaaSus Platformのチュートリアル Q&A [注意事項] 使用言語はPHP(Laravel)となっておりますので、ご承知お願いいたします。 お申し込み人数が3人を超えた場合、別日程でお願いする可能性がございますので、ご了承ください。 [準備事項] また、当日までに以下のご準備をお願いいたします。 PCにインストールしていただくアプリ ・Docker ・VScode その他ご用意いただくもの ・SaaSus Platformのフリープランアカウント 　※公式サイトよりセルフサインアップでご登録いただけます。（https://www.saasus.io/） なお、アカウント有効化まで最短1時間程度お時間がかかるため、【当日13:00】までに以下をお済ませください。 　　１）セルフサインアップ 　　２）アカウントの有効化（検証コード入力） 　　３）初回ログイン [備考] 体験会は今後も定期的に開催予定です！ 開催日に予定が合わない方は、ぜひトップページの最新情報を受け取るボタンからフォーム登録して、今後のイベント情報を取得してください！ --- ## [PHP(Laravel)版]第20回SaaSus Platform体験会開催のお知らせ URL: https://saasus.io/resource/offline-event/saasus-experience-session-20230427 こんにちは！SaaSus Platform運営チームです。 実際にSaaSus Platformを用いてサンプルアプリをSaaS化する「SaaSus Platform体験会」のPHP(Laravel)版、第20回をご案内いたします！ 少人数制での開催のため参加枠には限りがございますので、 アプリのSaaS化にご興味ある方や、SaaSus Platformを実際に触って体験してみたい方は、ぜひお早めにお申し込みください。 [SaaSus Platform とは] 一般的なwebアプリと比較してSaaSの提供は課題が沢山あり、難易度が格段に高いです。 これらの課題を解決するために、SaaS開発に最低限必要な共通部分のベストプラクティスやアンチパターンを考慮して、SaaS開発に必要な機能を幅広く提供するのがSaaSus Platformです。 SaaSus Platform体験会では、実際にSaaSus Platformを用いてサンプルアプリをSaaS化することで、SaaSus Platformの魅力を体験していただきます。 SaaS開発で考慮すべき点を抑えながら、WebアプリをSaaS化する過程をSaaSus Platformで一緒に体験してみませんか？ [日程] 4月 27日 (木)　17:00～20:00 [開催場所] HarborS表参道(エンジニア特化型コワーキングスペース) (〒107-0062 東京都港区南青山３丁目１５−９ MINOWA表参道 ３階) ※会場のエレベータは３階のボタンが２つ付いております。「3F 会議室」のボタンを押してください。 [メンター] 株式会社アンチパターン　SaaSus Platform インフラエンジニア　小谷 [こんな方へおすすめ] これからSaaSの開発に関わりそうな方 SaaSus Platformに興味がある方/実際に触れてみたい方 SaaSus Platformのチュートリアルを説明を聞きながらやりたい方 [当日のアジェンダ] 体験会の中でSaaS化するサンプルアプリのセットアップ SaaSus Platformのご紹介 SaaS開発のポイントを簡単にご紹介 本日のSaaSus Platfrom体験会でできること SaaSus Platformのチュートリアル Q&A [注意事項] 使用言語はPHP(Laravel)となっておりますので、ご承知お願いいたします。 お申し込み人数が3人を超えた場合、別日程でお願いする可能性がございますので、ご了承ください。 [準備事項] また、当日までに以下のご準備をお願いいたします。 PCにインストールしていただくアプリ ・Docker ・VScode その他ご用意いただくもの ・SaaSus Platformのフリープランアカウント 　※公式サイトよりセルフサインアップでご登録いただけます。（https://www.saasus.io/） なお、アカウント有効化まで最短1時間程度お時間がかかるため、【当日13:00】までに以下をお済ませください。 　　１）セルフサインアップ 　　２）アカウントの有効化（検証コード入力） 　　３）初回ログイン [備考] 体験会は今後も定期的に開催予定です！ 開催日に予定が合わない方は、ぜひトップページの最新情報を受け取るボタンからフォーム登録して、今後のイベント情報を取得してください！ --- ## [PHP(Laravel)版]第19回SaaSus Platform体験会開催のお知らせ URL: https://saasus.io/resource/offline-event/saasus-experience-session-20230413 こんにちは！SaaSus Platform運営チームです。 実際にSaaSus Platformを用いてサンプルアプリをSaaS化する「SaaSus Platform体験会」のPHP(Laravel)版、第19回をご案内いたします！ 少人数制での開催のため参加枠には限りがございますので、 アプリのSaaS化にご興味ある方や、SaaSus Platformを実際に触って体験してみたい方は、ぜひお早めにお申し込みください。 [SaaSus Platform とは] 一般的なwebアプリと比較してSaaSの提供は課題が沢山あり、難易度が格段に高いです。 これらの課題を解決するために、SaaS開発に最低限必要な共通部分のベストプラクティスやアンチパターンを考慮して、SaaS開発に必要な機能を幅広く提供するのがSaaSus Platformです。 SaaSus Platform体験会では、実際にSaaSus Platformを用いてサンプルアプリをSaaS化することで、SaaSus Platformの魅力を体験していただきます。 SaaS開発で考慮すべき点を抑えながら、WebアプリをSaaS化する過程をSaaSus Platformで一緒に体験してみませんか？ [日程] 4月 13日 (木)　17:00～20:00 [開催場所] HarborS表参道(エンジニア特化型コワーキングスペース) (〒107-0062 東京都港区南青山３丁目１５−９ MINOWA表参道 ３階) ※会場のエレベータは３階のボタンが２つ付いております。「3F 会議室」のボタンを押してください。 [メンター] 株式会社アンチパターン　SaaSus Platform インフラエンジニア　小谷 [こんな方へおすすめ] これからSaaSの開発に関わりそうな方 SaaSus Platformに興味がある方/実際に触れてみたい方 SaaSus Platformのチュートリアルを説明を聞きながらやりたい方 [当日のアジェンダ] 体験会の中でSaaS化するサンプルアプリのセットアップ SaaSus Platformのご紹介 SaaS開発のポイントを簡単にご紹介 本日のSaaSus Platfrom体験会でできること SaaSus Platformのチュートリアル Q&A [注意事項] 使用言語はPHP(Laravel)となっておりますので、ご承知お願いいたします。 お申し込み人数が3人を超えた場合、別日程でお願いする可能性がございますので、ご了承ください。 [準備事項] また、当日までに以下のご準備をお願いいたします。 PCにインストールしていただくアプリ ・Docker ・VScode その他ご用意いただくもの ・SaaSus Platformのフリープランアカウント 　※公式サイトよりセルフサインアップでご登録いただけます。（https://www.saasus.io/） なお、アカウント有効化まで最短1時間程度お時間がかかるため、【当日13:00】までに以下をお済ませください。 　　１）セルフサインアップ 　　２）アカウントの有効化（検証コード入力） 　　３）初回ログイン [備考] 体験会は今後も定期的に開催予定です！ 開催日に予定が合わない方は、ぜひトップページの最新情報を受け取るボタンからフォーム登録して、今後のイベント情報を取得してください！ --- ## [PHP(Laravel)版]第18回SaaSus Platform体験会開催のお知らせ URL: https://saasus.io/resource/offline-event/saasus-experience-session-20230323 こんにちは！SaaSus Platform運営チームです。 実際にSaaSus Platformを用いてサンプルアプリをSaaS化する「SaaSus Platform体験会」のPHP(Laravel)版、第18回をご案内いたします！ 少人数制での開催のため参加枠には限りがございますので、 アプリのSaaS化にご興味ある方や、SaaSus Platformを実際に触って体験してみたい方は、ぜひお早めにお申し込みください。 [SaaSus Platform とは] 一般的なwebアプリと比較してSaaSの提供は課題が沢山あり、難易度が格段に高いです。 これらの課題を解決するために、SaaS開発に最低限必要な共通部分のベストプラクティスやアンチパターンを考慮して、SaaS開発に必要な機能を幅広く提供するのがSaaSus Platformです。 SaaSus Platform体験会では、実際にSaaSus Platformを用いてサンプルアプリをSaaS化することで、SaaSus Platformの魅力を体験していただきます。 SaaS開発で考慮すべき点を抑えながら、WebアプリをSaaS化する過程をSaaSus Platformで一緒に体験してみませんか？ [日程] 3月 23日 (木)　17:00～20:00 [開催場所] HarborS表参道(エンジニア特化型コワーキングスペース) (〒107-0062 東京都港区南青山３丁目１５−９ MINOWA表参道 ３階) ※会場のエレベータは３階のボタンが２つ付いております。「3F 会議室」のボタンを押してください。 [メンター] 株式会社アンチパターン　SaaSus Platform インフラエンジニア　小谷 [こんな方へおすすめ] これからSaaSの開発に関わりそうな方 SaaSus Platformに興味がある方/実際に触れてみたい方 SaaSus Platformのチュートリアルを説明を聞きながらやりたい方 [当日のアジェンダ] 体験会の中でSaaS化するサンプルアプリのセットアップ SaaSus Platformのご紹介 SaaS開発のポイントを簡単にご紹介 本日のSaaSus Platfrom体験会でできること SaaSus Platformのチュートリアル Q&A [注意事項] 使用言語はPHP(Laravel)となっておりますので、ご承知お願いいたします。 [準備事項] また、当日までに以下のご準備をお願いいたします。 PCにインストールしていただくアプリ ・Docker ・VScode その他ご用意いただくもの ・SaaSus Platformのフリープランアカウント 　※公式サイトよりセルフサインアップでご登録いただけます。（https://www.saasus.io/） なお、アカウント有効化まで最短1時間程度お時間がかかるため、【当日13:00】までに以下をお済ませください。 　　１）セルフサインアップ 　　２）アカウントの有効化（検証コード入力） 　　３）初回ログイン [備考] 体験会は今後も定期的に開催予定です！ 開催日に予定が合わない方は、ぜひトップページの最新情報を受け取るボタンからフォーム登録して、今後のイベント情報を取得してください！ --- ## [PHP(Laravel)版]第17回SaaSus Platform体験会開催のお知らせ URL: https://saasus.io/resource/offline-event/saasus-experience-session-20230302 こんにちは！SaaSus Platform運営チームです。 実際にSaaSus Platformを用いてサンプルアプリをSaaS化する「SaaSus Platform体験会」のPHP(Laravel)版、第17回をご案内いたします！ 少人数制での開催のため参加枠には限りがございますので、 アプリのSaaS化にご興味ある方や、SaaSus Platformを実際に触って体験してみたい方は、ぜひお早めにお申し込みください。 [SaaSus Platform とは] 一般的なwebアプリと比較してSaaSの提供は課題が沢山あり、難易度が格段に高いです。 これらの課題を解決するために、SaaS開発に最低限必要な共通部分のベストプラクティスやアンチパターンを考慮して、SaaS開発に必要な機能を幅広く提供するのがSaaSus Platformです。 SaaSus Platform体験会では、実際にSaaSus Platformを用いてサンプルアプリをSaaS化することで、SaaSus Platformの魅力を体験していただきます。 SaaS開発で考慮すべき点を抑えながら、WebアプリをSaaS化する過程をSaaSus Platformで一緒に体験してみませんか？ [日程] 3月 2日 (木)　17:00～20:00 [開催場所] HarborS表参道(エンジニア特化型コワーキングスペース) (〒107-0062 東京都港区南青山３丁目１５−９ MINOWA表参道 ３階) ※会場のエレベータは３階のボタンが２つ付いております。「3F 会議室」のボタンを押してください。 [メンター] 株式会社アンチパターン　SaaSus Platform インフラエンジニア　小谷 [こんな方へおすすめ] これからSaaSの開発に関わりそうな方 SaaSus Platformに興味がある方/実際に触れてみたい方 SaaSus Platformのチュートリアルを説明を聞きながらやりたい方 [当日のアジェンダ] 体験会の中でSaaS化するサンプルアプリのセットアップ SaaSus Platformのご紹介 SaaS開発のポイントを簡単にご紹介 本日のSaaSus Platfrom体験会でできること SaaSus Platformのチュートリアル Q&A [注意事項] 使用言語はPHP(Laravel)となっておりますので、ご承知お願いいたします。 [準備事項] また、当日までに以下のご準備をお願いいたします。 PCにインストールしていただくアプリ ・Docker ・VScode その他ご用意いただくもの ・SaaSus Platformのフリープランアカウント 　※公式サイトよりセルフサインアップでご登録いただけます。（https://www.saasus.io/） なお、アカウント有効化まで最短1時間程度お時間がかかるため、【当日13:00】までに以下をお済ませください。 　　１）セルフサインアップ 　　２）アカウントの有効化（検証コード入力） 　　３）初回ログイン [備考] 体験会は今後も定期的に開催予定です！ 開催日に予定が合わない方は、ぜひトップページの最新情報を受け取るボタンからフォーム登録して、今後のイベント情報を取得してください！ --- ## [PHP(Laravel)版]第16回SaaSus Platform体験会開催のお知らせ URL: https://saasus.io/resource/offline-event/saasus-experience-session-20230216 こんにちは！SaaSus Platform運営チームです。 実際にSaaSus Platformを用いてサンプルアプリをSaaS化する「SaaSus Platform体験会」のPHP(Laravel)版、第16回をご案内いたします！ 少人数制での開催のため参加枠には限りがございますので、 アプリのSaaS化にご興味ある方や、SaaSus Platformを実際に触って体験してみたい方は、ぜひお早めにお申し込みください。 [SaaSus Platform とは] 一般的なwebアプリと比較してSaaSの提供は課題が沢山あり、難易度が格段に高いです。 これらの課題を解決するために、SaaS開発に最低限必要な共通部分のベストプラクティスやアンチパターンを考慮して、SaaS開発に必要な機能を幅広く提供するのがSaaSus Platformです。 SaaSus Platform体験会では、実際にSaaSus Platformを用いてサンプルアプリをSaaS化することで、SaaSus Platformの魅力を体験していただきます。 SaaS開発で考慮すべき点を抑えながら、WebアプリをSaaS化する過程をSaaSus Platformで一緒に体験してみませんか？ [日程] 2月 16日 (木)　17:00～20:00 [開催場所] HarborS表参道(エンジニア特化型コワーキングスペース) (〒107-0062 東京都港区南青山３丁目１５−９ MINOWA表参道 ３階) ※会場のエレベータは３階のボタンが２つ付いております。「3F 会議室」のボタンを押してください。 [メンター] 株式会社アンチパターン　SaaSus Platform インフラエンジニア　小谷 [こんな方へおすすめ] これからSaaSの開発に関わりそうな方 SaaSus Platformに興味がある方/実際に触れてみたい方 SaaSus Platformのチュートリアルを説明を聞きながらやりたい方 [当日のアジェンダ] 体験会の中でSaaS化するサンプルアプリのセットアップ SaaSus Platformのご紹介 SaaS開発のポイントを簡単にご紹介 本日のSaaSus Platfrom体験会でできること SaaSus Platformのチュートリアル Q&A [注意事項] 使用言語はPHP(Laravel)となっておりますので、ご承知お願いいたします。 [準備事項] また、当日までに以下のご準備をお願いいたします。 PCにインストールしていただくアプリ ・Docker ・VScode ・CLI(ターミナル) その他ご用意いただくもの ・SaaSus Platformのフリープランアカウント 　※公式サイトよりセルフサインアップでご登録いただけます。（https://www.saasus.io/） なお、アカウント有効化まで最短1時間程度お時間がかかるため、【当日13:00】までに以下をお済ませください。 　　１）セルフサインアップ 　　２）アカウントの有効化（検証コード入力） 　　３）初回ログイン [備考] 体験会は今後も定期的に開催予定です！ 開催日に予定が合わない方は、ぜひトップページの最新情報を受け取るボタンからフォーム登録して、今後のイベント情報を取得してください！ --- ## [新規SaaS事業推進責任者向け] SaaS開発の課題解決ウェビナー開催のお知らせ URL: https://saasus.io/resource/webinar/saas-development-flow-20230215 こんにちは！SaaSus Platform運営チームです。 SaaS 開発のポイントと効率化の方法について学べるウェビナー 「SaaS開発を一気通貫で考える 流れとポイント解説」をご案内いたします！ [イベント概要] SaaS というのはサービス提供形態の１つです。そのため、実際に提供されるサービスやアプリケーションの作り方は千差万別です。 しかし、少なからず SaaS 開発において共通の部分もあります。こういった共通部分にはベストプラクティスやアンチパターンが存在しているので、それを前もって踏まえておき進めていくのが効率的です。 また、 SaaS ビジネスの要件によってアーキテクチャや開発ポイントも変わってきますので、エンジニアも SaaS ビジネスをある程度理解しておくことが開発効率に寄与します。 どのようなポイントがあるのかの一例をご紹介し、どのように効率化していけばよいかを一緒に考えていきたいと思います。 [日程] 2月15日(水)(13:00-14:00) [場所] オンライン(視聴用URLは参加登録後に送付いたします) [登壇者] 株式会社アンチパターン CTO兼COO,  SaaSus Platform プロダクトオーナー 矢ヶ崎 哲宏 幼少時のマイコン時代からプログラミングを続け、近年では中国での IaaS サービス立ち上げや、マルチリージョン・マルチサービスの統合インフラ設計・構築などに従事。その後、SaaS ベンダーでの技術責任者に従事した後に、アマゾンウェブサービスジャパンにて SaaS 領域専門のパートナーソリューションアーキテクトに従事。現在は、株式会社アンチパターンにて SaaSus Platform のプロダクトオーナー兼エンジニアとして SaaS 開発/運用の知見を SaaS に搭載することにチャレンジ中。 --- ## [PHP(Laravel)版]第15回SaaSus Platform体験会開催のお知らせ URL: https://saasus.io/resource/offline-event/saasus-experience-session-20230209 こんにちは！SaaSus Platform運営チームです。 実際にSaaSus Platformを用いてサンプルアプリをSaaS化する「SaaSus Platform体験会」のPHP(Laravel)版、第15回をご案内いたします！ 少人数制での開催のため参加枠には限りがございますので、 アプリのSaaS化にご興味ある方や、SaaSus Platformを実際に触って体験してみたい方は、ぜひお早めにお申し込みください。 [SaaSus Platform とは] 一般的なwebアプリと比較してSaaSの提供は課題が沢山あり、難易度が格段に高いです。 これらの課題を解決するために、SaaS開発に最低限必要な共通部分のベストプラクティスやアンチパターンを考慮して、SaaS開発に必要な機能を幅広く提供するのがSaaSus Platformです。 SaaSus Platform体験会では、実際にSaaSus Platformを用いてサンプルアプリをSaaS化することで、SaaSus Platformの魅力を体験していただきます。 SaaS開発で考慮すべき点を抑えながら、WebアプリをSaaS化する過程をSaaSus Platformで一緒に体験してみませんか？ [日程] 2月 9日 (木)　17:00～20:00 [開催場所] HarborS表参道(エンジニア特化型コワーキングスペース) (〒107-0062 東京都港区南青山３丁目１５−９ MINOWA表参道 ３階) ※会場のエレベータは３階のボタンが２つ付いております。「3F 会議室」のボタンを押してください。 [メンター] 株式会社アンチパターン　SaaSus Platform インフラエンジニア　小谷 [こんな方へおすすめ] これからSaaSの開発に関わりそうな方 SaaSus Platformに興味がある方/実際に触れてみたい方 SaaSus Platformのチュートリアルを説明を聞きながらやりたい方 [当日のアジェンダ] 体験会の中でSaaS化するサンプルアプリのセットアップ SaaSus Platformのご紹介 SaaS開発のポイントを簡単にご紹介 本日のSaaSus Platfrom体験会でできること SaaSus Platformのチュートリアル Q&A [注意事項] 使用言語はPHP(Laravel)となっておりますので、ご承知お願いいたします。 [準備事項] また、当日までに以下のご準備をお願いいたします。 PCにインストールしていただくアプリ ・Docker ・VScode ・CLI(ターミナル) その他ご用意いただくもの ・SaaSus Platformのフリープランアカウント 　※公式サイトよりセルフサインアップでご登録いただけます。（https://www.saasus.io/） なお、アカウント有効化まで最短1時間程度お時間がかかるため、【当日13:00】までに以下をお済ませください。 　　１）セルフサインアップ 　　２）アカウントの有効化（検証コード入力） 　　３）初回ログイン [備考] 体験会は今後も定期的に開催予定です！ 開催日に予定が合わない方は、ぜひトップページの最新情報を受け取るボタンからフォーム登録して、今後のイベント情報を取得してください！ --- ## [PHP(Laravel)版]第14回SaaSus Platform体験会開催のお知らせ URL: https://saasus.io/resource/offline-event/saasus-experience-session-20230126 こんにちは！SaaSus Platform運営チームです。 実際にSaaSus Platformを用いてサンプルアプリをSaaS化する「SaaSus Platform体験会」のPHP(Laravel)版、第14回をご案内いたします！ 少人数制での開催のため参加枠には限りがございますので、 アプリのSaaS化にご興味ある方や、SaaSus Platformを実際に触って体験してみたい方は、ぜひお早めにお申し込みください。 [SaaSus Platform とは] 一般的なwebアプリと比較してSaaSの提供は課題が沢山あり、難易度が格段に高いです。 これらの課題を解決するために、SaaS開発に最低限必要な共通部分のベストプラクティスやアンチパターンを考慮して、SaaS開発に必要な機能を幅広く提供するのがSaaSus Platformです。 SaaSus Platform体験会では、実際にSaaSus Platformを用いてサンプルアプリをSaaS化することで、SaaSus Platformの魅力を体験していただきます。 SaaS開発で考慮すべき点を抑えながら、WebアプリをSaaS化する過程をSaaSus Platformで一緒に体験してみませんか？ [日程] 1月 26日 (木)　17:00～20:00 [開催場所] HarborS表参道(エンジニア特化型コワーキングスペース) (〒107-0062 東京都港区南青山３丁目１５−９ MINOWA表参道 ３階) ※会場のエレベータは３階のボタンが２つ付いております。「3F 会議室」のボタンを押してください。 [メンター] 株式会社アンチパターン　SaaSus Platform インフラエンジニア　小谷 [こんな方へおすすめ] これからSaaSの開発に関わりそうな方 SaaSus Platformに興味がある方/実際に触れてみたい方 SaaSus Platformのチュートリアルを説明を聞きながらやりたい方 [当日のアジェンダ] 体験会の中でSaaS化するサンプルアプリのセットアップ SaaSus Platformのご紹介 SaaS開発のポイントを簡単にご紹介 本日のSaaSus Platfrom体験会でできること SaaSus Platformのチュートリアル Q&A [注意事項] 使用言語はPHP(Laravel)となっておりますので、ご承知お願いいたします。 [準備事項] また、当日までに以下のご準備をお願いいたします。 PCにインストールしていただくアプリ ・Docker ・VScode ・CLI(ターミナル) その他ご用意いただくもの ・SaaSus Platformのフリープランアカウント 　※公式サイトよりセルフサインアップでご登録いただけます。（https://www.saasus.io/） なお、アカウント有効化まで最短1時間程度お時間がかかるため、【当日13:00】までに以下をお済ませください。 　　１）セルフサインアップ 　　２）アカウントの有効化（検証コード入力） 　　３）初回ログイン [備考] 体験会は今後も定期的に開催予定です！ 開催日に予定が合わない方は、ぜひトップページの最新情報を受け取るボタンからフォーム登録して、今後のイベント情報を取得してください！ --- ## [新規SaaS事業推進責任者向け] SaaS開発の課題解決ウェビナー開催のお知らせ URL: https://saasus.io/resource/webinar/saas-development-flow-20230124 こんにちは！SaaSus Platform運営チームです。 SaaS 開発のポイントと効率化の方法について学べるウェビナー 「SaaS開発を一気通貫で考える 流れとポイント解説」をご案内いたします！ [イベント概要] SaaS というのはサービス提供形態の１つです。そのため、実際に提供されるサービスやアプリケーションの作り方は千差万別です。 しかし、少なからず SaaS 開発において共通の部分もあります。こういった共通部分にはベストプラクティスやアンチパターンが存在しているので、それを前もって踏まえておき進めていくのが効率的です。 また、 SaaS ビジネスの要件によってアーキテクチャや開発ポイントも変わってきますので、エンジニアも SaaS ビジネスをある程度理解しておくことが開発効率に寄与します。 どのようなポイントがあるのかの一例をご紹介し、どのように効率化していけばよいかを一緒に考えていきたいと思います。 [日程] 1月24日(火)(13:00-14:00) [場所] オンライン(視聴用URLは参加登録後に送付いたします) [登壇者] 株式会社アンチパターン CTO兼COO,  SaaSus Platform プロダクトオーナー 矢ヶ崎 哲宏 幼少時のマイコン時代からプログラミングを続け、近年では中国での IaaS サービス立ち上げや、マルチリージョン・マルチサービスの統合インフラ設計・構築などに従事。その後、SaaS ベンダーでの技術責任者に従事した後に、アマゾンウェブサービスジャパンにて SaaS 領域専門のパートナーソリューションアーキテクトに従事。現在は、株式会社アンチパターンにて SaaSus Platform のプロダクトオーナー兼エンジニアとして SaaS 開発/運用の知見を SaaS に搭載することにチャレンジ中。 --- ## [PHP(Laravel)版]第13回SaaSus Platform体験会開催のお知らせ URL: https://saasus.io/resource/offline-event/saasus-experience-session-20230119 こんにちは！SaaSus Platform運営チームです。 実際にSaaSus Platformを用いてサンプルアプリをSaaS化する「SaaSus Platform体験会」のPHP(Laravel)版、第13回をご案内いたします！ 少人数制での開催のため参加枠には限りがございますので、 アプリのSaaS化にご興味ある方や、SaaSus Platformを実際に触って体験してみたい方は、ぜひお早めにお申し込みください。 [SaaSus Platform とは] 一般的なwebアプリと比較してSaaSの提供は課題が沢山あり、難易度が格段に高いです。 これらの課題を解決するために、SaaS開発に最低限必要な共通部分のベストプラクティスやアンチパターンを考慮して、SaaS開発に必要な機能を幅広く提供するのがSaaSus Platformです。 SaaSus Platform体験会では、実際にSaaSus Platformを用いてサンプルアプリをSaaS化することで、SaaSus Platformの魅力を体験していただきます。 SaaS開発で考慮すべき点を抑えながら、WebアプリをSaaS化する過程をSaaSus Platformで一緒に体験してみませんか？ [日程] 1月 19日 (木)　17:00～20:00 [開催場所] HarborS表参道(エンジニア特化型コワーキングスペース) (〒107-0062 東京都港区南青山３丁目１５−９ MINOWA表参道 ３階) ※会場のエレベータは３階のボタンが２つ付いております。「3F 会議室」のボタンを押してください。 [メンター] 株式会社アンチパターン　SaaSus Platform インフラエンジニア　小谷 [こんな方へおすすめ] これからSaaSの開発に関わりそうな方 SaaSus Platformに興味がある方/実際に触れてみたい方 SaaSus Platformのチュートリアルを説明を聞きながらやりたい方 [当日のアジェンダ] 体験会の中でSaaS化するサンプルアプリのセットアップ SaaSus Platformのご紹介 SaaS開発のポイントを簡単にご紹介 本日のSaaSus Platfrom体験会でできること SaaSus Platformのチュートリアル Q&A [注意事項] 使用言語はPHP(Laravel)となっておりますので、ご承知お願いいたします。 [準備事項] また、当日までにご準備をお願いいたします。 PCにインストールしていただくアプリ ・Docker ・VScode ・CLI(ターミナル) その他ご用意いただくもの ・SaaSus Platformのフリープランアカウント 　※公式サイトよりセルフサインアップでご登録いただけます。（https://www.saasus.io/） なお、アカウント有効化まで最短1時間程度お時間がかかるため、【当日13:00】までに以下をお済ませください。 　　１）セルフサインアップ 　　２）アカウントの有効化（検証コード入力） 　　３）初回ログイン [備考] 体験会は今後も定期的に開催予定です！ 開催日に予定が合わない方は、ぜひトップページの最新情報を受け取るボタンからフォーム登録して、今後のイベント情報を取得してください！ --- ## [エンジニア向け]SaaS開発の課題解決ウェビナー開催のお知らせ URL: https://saasus.io/resource/webinar/saas-development-flow-and-points-to-consider-in-a-single-step こんにちは！SaaSus Platform運営チームです。 SaaS 開発のポイントと効率化の方法について学べるウェビナー 「SaaS開発を一気通貫で考える 流れとポイント解説」をご案内いたします！ [イベント概要] SaaS というのはサービス提供形態の１つです。そのため、実際に提供されるサービスやアプリケーションの作り方は千差万別です。 しかし、少なからず SaaS 開発において共通の部分もあります。こういった共通部分にはベストプラクティスやアンチパターンが存在しているので、それを前もって踏まえておき進めていくのが効率的です。 また、 SaaS ビジネスの要件によってアーキテクチャや開発ポイントも変わってきますので、エンジニアも SaaS ビジネスをある程度理解しておくことが開発効率に寄与します。 どのようなポイントがあるのかの一例をご紹介し、どのように効率化していけばよいかを一緒に考えていきたいと思います。 [日程] 10月19日(水)(10:30-11:30) [場所] オンライン(視聴用URLは参加登録後に送付いたします) [登壇者] 株式会社アンチパターン CTO兼COO,  SaaSus Platform プロダクトオーナー 矢ヶ崎 哲宏 幼少時のマイコン時代からプログラミングを続け、近年では中国での IaaS サービス立ち上げや、マルチリージョン・マルチサービスの統合インフラ設計・構築などに従事。その後、SaaS ベンダーでの技術責任者に従事した後に、アマゾンウェブサービスジャパンにて SaaS 領域専門のパートナーソリューションアーキテクトに従事。現在は、株式会社アンチパターンにて SaaSus Platform のプロダクトオーナー兼エンジニアとして SaaS 開発/運用の知見を SaaS に搭載することにチャレンジ中。 --- # Terms --- ## SaaSus Platform 利用規約 URL: https://saasus.io/terms 1条 適用 1. SaaSus Platform利用規約(以下「本規約」といいます。)は、株式会社アンチパターン(以下「当社」といいます。)が提供するSaaS 開発支援プラットフォーム「SaaSus Platform」のサービス(以下「本サービス」といいます。)の利用に関する条件を、本サービスをご利用される会員及びユーザーと当社の間で定めるものです。会員及びユーザーは、本規約の全文をお読みいただいた上で、本サービスをご利用ください。 2. 利用希望者が当社又は当社の販売パートナー(以下、合わせて「当社等」といいます。)に対して本サービスのご利用に関するお申込書を提出した時点で、本規約の内容に同意したものとします。 3. 当社が当社ウェブサイト上で掲載する本サービスの利用に関する記載は、本規約の一部を構成するものとします。ただし、当該記載と本規約の内容とが異なる場合は、本規約の規定が優先して適用されるものとします。 4. 本規約以外に個別のサービスごとに別途定められた規約を含む特約がある場合、当該特約を優先するものとします。 2条 サービス概要・目的 1. 本サービスは、会員に対し、SaaS 開発支援プラットフォームを提供するサービスであり、ユーザー企業のソフトウェア開発内製化を支援し、デジタルトランスフォーメーションを推進することを目的とするサービスです。なお、本サービスには、本サービスの機能一覧に記載される機能の他、オプションサービスを包含するものとします。 2. 当社は、本規約に定める条件に従い、本サービスを提供します。 3. 本サービスの内容及び提供条件等の細目については別途当社が定め、マニュアル等の形式で会員及びユーザーに対して提示します。会員及びユーザーは、本規約の他、マニュアル等に従い、本サービスを利用するものとします。 4. 当社は、本サービスに付随関連して、オプションサービスを提供する場合があります。オプションサービスについても、当社が別段の定めをしない限り、本規約の規定が本サービスと同様に適用されるものとします。 3条 定義 「会員」 当社との間で本サービスの利用に関する契約を締結した法人その他の契約当事者 「ユーザー」 会員の従業員その他本サービスを利用する者 「利用希望者」 本サービスの利用を希望する者 「販売パートナー」 本サービスの販売のために当社が指定する代理店 「本契約」 本規約に基づき当社と会員の間で締結される本サービスの利用に関する契約 4条 規約の変更 1. 当社は、当社が必要と認めた場合には、本規約の内容の変更又は追加、及び一部廃止等(以下「規約改定」といいます。)をすることができます。 2. 当社が規約改定を行う場合には、規約改定後の本規約の効力発生時期を予め定めたうえ、当該効力発生時期までに、会員に当該改定内容を当社ウェブサイトへの掲載又は電子メールの送信若しくは文書の送付その他当社が適当と判断する方法にて通知するものとし、通知において指定された期日以降は、改定後の本規約が適用されます。なお、会員又はユーザーが通知において指定された期日以後に本サービスを利用した場合には、会員は改定後の本規約に同意したものとみなします。 3. 当社は、誤記訂正や形式的修正など変更が軽微な場合及び本契約締結中の会員に効力を及ぼさない場合には、会員に対して規約改定を通知しないことができます。 5条 通知・公表 1. 当社は、本サービスに関連して会員に通知又は公表をする場合には、当社ウェブサイトへの掲載又は電子メールの送信若しくは文書の送付その他当社が適当と判断する方法で実施します。 2. 当社が会員の登録事項に含まれる電子メールアドレスに宛てて電子メールの送信をした場合その他電磁的方法によって会員に通知又は公表を行った場合には、会員はこれをもって当該通知を受領したものとみなします。 3. 本サービスに関する問い合わせその他会員及びユーザーから当社に対する連絡又は通知は、当社の定める方法で行うものとします。 6条 本契約の成立 1. 本契約は、利用希望者が、本規約を遵守することに同意し、かつ登録情報を当社の定める方法で当社に提供し、当社が利用希望者に対して、本サービスを利用するためのアカウントを発行したとき、又は当社が利用を認めたときに、利用希望者と当社の間に成立し、これ以降、サービスの利用を開始できるものとします。 2. 利用希望者は、当社に対し、本契約を締結する正当な権利及び能力を有していること、本契約を締結するについて第三者から何らの異議申立てもなされないこと並びにかかる事態が生じた場合、第三者からの一切の要求に対し自己の責任と負担においてこれに対処し、当社に対して何らの迷惑及び損害を与えないことを保証するものとします。 3. 当社は、利用希望者に対し、正当な権利及び能力を有していることを証明する書類の提示を求めることがあります。但し、当社は、利用希望者からの申込みについて、正当な権利及び能力を有していることを調査する義務を負いません。本サービスの申込みをする各個人が、本契約を締結する正当な権利及び能力を有していなかったとしても、利用希望者が本サービスの利用を開始した場合、その時点において、当該申込みについての会員の追認があったものとみなし、利用希望者による当社に対する本契約の申込みは申込み時から有効に成立しているものとします。 4. 当社は、当社の基準に従って、利用希望者の登録の可否を判断し、当社が登録を認めた利用希望者に限り、本サービスを提供するものとします。 5. 利用希望者が未成年である場合には、法定代理人の同意が必要になります。 また、本契約が成立した時点で未成年者であった利用希望者が、成年に達した後に本サービスを利用した場合、未成年者であった間の利用行為を追認したものとみなします。 6. 利用希望者は、登録情報の登録にあたっては、真実かつ正確な情報を送信しなければなりません。当社は、利用希望者自身が登録した登録情報を前提として、本サービスを提供いたします。登録情報の内容に虚偽、誤り又は記載漏れがあったことにより会員及びユーザーに生じた損害について、当社は一切責任を負いません。登録情報の変更が生じた場合も同様とし、当社は会員及びユーザーによる本サービス利用時点において登録情報を前提として、本サービスを提供いたします。 7. 利用希望者は、当社の定める方法で登録情報を提供した時点以降、本契約に関する申込みを撤回することができないものとします。 7条 サービスの利用 1. 会員及びユーザーは、本契約の有効期間内において、日本国内での利用に限り、本規約の目的の範囲内でかつ本規約に違反しない範囲内で、当社の定める方法に従い、本サービスを利用することができるものとします。 2. 会員及びユーザーは、本サービスの利用開始に際し又は本サービスの利用中に、当社ウェブサイトからのダウンロードその他の方法によりソフトウェア等を会員及びユーザーのコンピュータ等にインストールする場合、 会員及びユーザーが保有する情報の消滅若しくは改変又は機器の故障、損傷等が生じないよう十分な注意を払うものとし、 当社は、かかる事象に基づき会員及びユーザーに生じた損害について、当社の故意又は重大な過失による場合を除き、その責任を負わないものとします。 3. 当社は、本契約期間中、会員及びユーザーが本規約に従い、本サービスを使用し、又は本サービスによって提供されるソフトウェア(以下「本ソフトウェア」といいます。)を組み込んで会員のソフトウェアを開発及び配信することを許諾します。 4. 前項により会員及びユーザーに許諾される権利は、譲渡不可、再許諾不可の非独占的なものとします。 5. 次の各号に定める場合、会員及びユーザーによる本ソフトウェアの利用の一部又は全部が制限されることがあります。 (1) 利用資格等の確認を目的としたライセンス認証、ID等の認証機能において、利用資格等の確認ができない場合 (2) インターネット接続ができない場所において本ソフトウェアを利用する場合 (3) リアルタイム通信ができない通信状況において本ソフトウェアを利用する場合 6. 当社は、本ソフトウェアに関するサポート、修正版(アップデート版を含みます。)の提供を行う義務を負いません。 7. 会員及びユーザーによる本サービスの利用により、本サービス用設備その他本サービスの提供に用いられる設備に過度の負荷が与えられている場合又はそのおそれのある場合、当社は、全ての会員及びユーザーに対して安定した本サービスの提供を確保するために必要とされる限りにおいて、当該会員及びユーザーによる本サービスの利用の制限その他適当な措置を講ずることができます。当社が特定の利用者による本サービスの利用の制限その他適当な措置を講ずる場合、当社は当該会員及びユーザーに対して当社が適切と判断する方法により事前に通知をします。但し、当社が緊急やむを得ないと判断した場合には、事後速やかに通知及び報告することをもって足りるものとします。 8. 当社は、前項の規定に基づく措置を講じたことにより会員及びユーザーが損害を被った場合であっても、当該損害につき一切の責任を負いません。 9. 本サービスにサービスレベルが定められている場合、当社は、当該サービスレベルを満たすよう努めるものとします。 10. 当社は、当社が必要と認めた場合は、サービスレベルを随時変更することができるものとします。なお、この場合には第 ４条2項及び同条3項の規定を準用するものとします。 11. 当社は、本サービスを通じて発生する会員及びユーザーのデータ等の保管義務を負わず、会員及びユーザーは、本サービスを通じて発生する過去のデータ等を利用することができない場合があることを予め了承した上で本サービスを利用するものとします。会員及びユーザーが本サービスを通じて発生する過去のデータ等が利用することができない場合であっても、当社は一切の責任を負いません。 8条 利用料金等・支払方法 1. 本サービスの利用料金等は、別途料金表を参照するものとします。本サービスの利用料金については利用日数の程度にかかわらず月単位とし、日割計算を行いません。 2. 会員は、当社等からの請求に基づき、利用料金等を当社の指定する期限までに当社の指定する方法で当社に支払うものとします。振込手数料は会員の負担とします。 3. 当社は、経済事情の変動又は本サービスの内容の変更、拡張等によって利用料金等を変更する必要が生じた場合には、利用料金等を改定することができるものとします。この場合、第４条2項及び同条3項の規定を準用するものとします。 4. 有料プランについて、上位プラン(基本料金がより高額のプラン)への変更は、既存プランと変更先のプランの差額を支払うことで、サービス期間の途中であっても随時行えます。下位プラン(基本料金がより低額のプラン)への変更は、同一のプランにおいて、プラスプランから通常プランへの変更のみ可能とし、変更申請を行うことで、次の利用期間以降、当該変更が適用されます。 5. 会員は、利用料金等の支払を遅延した場合、支払期限の翌日から完済に至るまで、年14.6％の遅延損害金を当社に支払うものとします。 9条 販売パートナー 1. 会員が販売パートナーからの提案を受けて本サービスの申込みをする場合、本契約は当社と会員との間で成立します。 2. 当社は、販売パートナーに対し、本規約の規約改定にかかる権限を与えておらず、販売パートナーが会員及びユーザーに対して本規約と矛盾抵触する利用条件を提案した場合でも、本規約が優先して適用されます。 10条 会員の責任 1. 会員は、自己の責任において、会員又はユーザーごとに指定されたアカウントを厳重に管理するものとし、これらを用いてなされた一切の行為についてその責任を負います。 2. 会員は、自己の責任において、会員又はユーザーごとに指定されたID(当社が会員又は会員が指定するユーザーごとに割り当てる識別子で、当該利用者が本サービスを利用するために用いるものをいいます。以下同じ。)及び当該IDにかかるパスワードを厳重に管理しなければなりません。会員は、会員又はユーザーによる行為であるか否かにかかわらず、会員又はユーザーのID又はパスワードを用いてなされた一切の行為について責任を負います。 3. 会員及びユーザーは、第三者に本サービスを利用させ、又はアカウントの貸与、譲渡若しくは名義変更等をしてはいけません。 4. 会員は、ユーザーに本規約の内容を遵守させるものとします。ユーザーの本規約違反は、会員の本規約違反とみなし、会員がユーザーによる行為について責任を負うものとします。 5. 会員及びユーザーは、自己のアカウントを第三者に知られた場合、又はそのおそれがある場合は、直ちに当社に対してその旨を連絡してください。当社は、当該連絡を受け付けた後、直ちに該当のアカウントの停止措置を行うよう努めます。なお、当社は、これらの措置が正常に行われたことを確認した後、会員及びユーザーに対し、新たなアカウントの発行手続を行います。 6. アカウント及び APIキーの管理不十分、使用上の過誤、第三者の使用等により発生した直接的、間接的、その他すべての損害に関する一切の責任は利用者が負うものとします。 7. 本サービスの提供を受けるために必要なコンピュータ、ソフトウェアその他の機器、通信回線その他の通信環境等の準備及び維持は、会員及びユーザーの費用と責任において行うものとします。 8. 会員及びユーザーは、登録情報に変更があった場合、速やかに当社所定の変更手続を行うものとします。会員及びユーザーが当該変更手続を怠ったことにより当社からの通知が不到達となった場合、当該通知は通常到達すべき時に会員に対して到達したものとみなされます。この場合、会員に生じた損害に関する一切の責任は、会員が負うものとします。 9. 会員、ユーザー及び当社は、本サービスの利用に際して知り得た情報の漏えい、滅失及び毀損の防止その他安全管理のため、合理的な範囲で、社内規程の整備等の組織的安全管理措置、従業者に対する教育・訓練等の人的安全管理措置、及びアクセス制御、アクセス者の識別と認証、外部からの不正アクセスの防止等の技術的安全管理措置を講じなければならないものとします。 10. 会員及びユーザーは、当社が前項の措置の整備状況について報告を求めた場合、合理的な範囲でこれに応じるものとします。 11. 本サービスを利用するために必要となる通信費、及び通信機器等は、会員及びユーザーの負担と責任により準備するものとします。但し、会員及びユーザーの使用する通信機器等において、本サイト及び本ソフトウェアが正常に動作することを保証するものではありません。 11条 第三者サービス 1. 本サービスと、当社以外の第三者がウェブサイト又はアプリケーション・ソフトウェアを介して運営するサービス(以下「第三者サービス」といいます。)との連携は、当社と第三者サービスの運営者との間の提携、協調、授権その他の一切の協力関係を意味するものではなく、会員及びユーザーは、第三者サービスとの連携により取得されるデータ等の正確性、完全性等につき、適宜、連携先サイトにおいても確認を行うものとします。 2. 会員及びユーザーは、第三者サービスを自己の責任において利用するものとし、会員は、第三者サービスとの連携に起因する当該サイト・サービスの運営者又は第三者との間での紛争その他一切の債権債務関係について、自己の責任と費用で解決するものとし、当社に何ら迷惑をかけず、またこれにより当社が被った損害(弁護士費用を含みます。)を補償します。 3. 会員及びユーザーは、第三者サービスとの連携により取得するデータが、通信設備等の異変により本サイトにおいて正確に表示されない可能性があることを予め了承します。 4. 会員及びユーザーは、諸規程において別段の定めがある場合を除き、本サービスと連携した API サービスを含む第三者サービスの利用が、会員及びユーザーと第三者サービス提供事業者間の契約に基づく利用であることを理解した上で第三者サービスを利用するものとし、また、当該第三者サービス提供事業者の定めるサービス利用規約等の諸規程その他利用者と第三者サービス提供事業者との間で合意した事項を遵守するものとします。 5. 本サービスと第三者サービスとの連携機能に、口座情報や取引履歴の照会、振込や決済指示など振込情報の送信等を行う機能が含まれている場合、会員及びユーザーは、自己の責任において当該機能を利用するものとし、当社は、当該機能の利用により会員及びユーザーに発生した一切の損害(本サービスの停止・中断等に伴い当該機能の利用に支障が生じた場合を含みます。)について、いかなる責任も負わないものとします。 6. 会員及びユーザーが本サービスと第三者サービスの連携を利用するためには、別段の定めがある場合を除き、第三者サービス提供事業者に対する申込手続が必要となります。この場合、第三者サービスの申込要綱その他第三者サービス提供事業者の指示に従い、会員及びユーザーの責任において申込みをするものとします。 第11条の2 人工知能を利用した機能 1. 本サービスでは、契約者が送信するソースコードその他一定の情報（以下「送信情報」といいます）に対し、人工知能を活用し、ソースコードの生成、API定義や各種ドキュメントの作成、その他開発支援を目的とした処理（以下「本人工知能機能」といいます）を提供する場合があります。本人工知能機能の利用は任意であり、契約者の判断により選択・利用することができます。 2. 本規約（例えば、本規約第7条（サービスの利用）、第10条（会員の責任）、第11条（第三者サービス）、第19条（サービスの中止・終了）、第20条（知的財産権）、第21条（保証の否認・免責）、第22条（損害賠償）を含みますがこれらに限られません。）は、本人工知能機能の提供においても適用されるものとし、会員及びユーザーが本サービスにおいて本人工知能機能を利用する場合、会員及びユーザーは、以下の各号の全てにつきあらかじめ承諾するものとします。 (1) 会員及びユーザーが本人工知能機能を用いて送信した送信情報が Amazon Web Services, Inc.又はAnthropic, PBC、その他本人工知能機能を提供するために不可欠の第三者サービス提供事業者に送信され、保存及び利用されること (2) 会員及びユーザーが本人工知能機能を用いて送信した送信情報が人工知能（Anthropic, PBCの提供する「Claude」等を含みますが、これに限られません。）によって学習され、人工知能や機能改善の目的で利用され得ること なお、当社が本サービスの運営において意図的に『Claude』の学習等のために、会員の入力した各種情報をAnthropic, PBCに提供することはございませんが、これは2025年6月11日時点における仕様に基づいた、設定およびサービス設計を前提としています。本項は、当社の意図しないところで会員の入力する各種情報が『Claude』の学習等に利用された場合等を想定しての定めとなります。 12条 バックアップ 1. 会員及びユーザーは、登録情報、その他本サービスを通じて収集、利用する情報全般の全てについて、自己の責任において記録し、保存・管理します。当社は、バックアップデータが存在しないこと、又は利用者がバックアップ作業を適切に実施しなかったこと等により発生した会員及びユーザーの損害及び不利益につき、一切の責任を負いません。 2. 当社は、会員及びユーザーの情報をバックアップとして記録することがあります。当社は、当社が必要と判断する範囲で災害対策のためのデータ等のバックアップを実施しますが、当社においてバックアップの義務を負うものではなく、会員及びユーザーの責任において行うバックアップを補完するものではなく、会員及びユーザーの情報の復旧を保証するものではありません。また、当該データの消失、改ざん、及び不正アクセス等による外部流出に関しては、当社は、法令の定めにより明示的に責任を負うものとされる場合を除き一切の責任を負わないものとします。 13条 禁止行為 1. 会員及びユーザーは、本サービスに関連して次の各号に定める行為を行ってはならず、これに該当する行為がなされた場合、当社は、当該会員及びユーザーに対して、利用停止措置等をとることができるものとします。なお、利用停止措置等は、当社の判断に基づき行うことができるものとし、当社は、利用停止措置等を行った理由について、開示する義務を負いません。また、利用停止措置等に起因して生じた損害について、当社は、一切の責任を負いません。 (1) 法令に違反する行為、法令違反を助長する行為又はそれらのおそれのある行為 (2) 当社、本サービスの他の会員及びユーザー又はその他第三者に対する詐欺又は脅迫行為 (3) 公序良俗に反する行為 (4) 当社又は本サービスの他の会員及びユーザー又はその他の第三者の知的財産権、肖像権、プライバシーの権利、名誉、信用その他の権利又は利益を侵害する行為 (5) 本サービスを通じ、以下に該当し、又は該当すると当社が判断する情報を送信する行為、及び、以下に該当するコンテンツをサービス会員ウェブサイト等に掲載し、第三者に開示、提供、送付し、又は電子メールなどの方法で送信・発信する行為   (ア) 法令等に違反するもの   (イ) 過度に暴力的又は残虐な表現を含むもの   (ウ) 他人に経済的・精神的損害を与える内容又は脅迫的な内容   (エ) コンピューター・ウィルスその他の有害なプログラムを含むもの   (オ) コンピュータのソフトウェア、ハードウェア、通信機器の機能を妨害、破壊、制限するようにデザインされたコンピュータウィルス、コンピュータコード、ファイル、プログラム等   (カ) 当社、本サービスの他の会員及びユーザー又はその他の第三者の名誉又は信用を毀損する表現を含むもの   (キ) 他人の権利を侵害するもの   (ク) 猥褻・猥雑な内容又は未成年者に悪影響を与えるもの   (ケ) 差別を助長する表現を含むもの   (コ) 自殺、自傷行為を助長する表現を含むもの   (サ) 薬物の不適切な利用を助長する表現を含むもの   (シ) 反社会的な表現を含むもの   (ス) 他人に不快感を与える表現を含むもの   (セ) いやがらせ、他人を誹謗・中傷する内容又は事実に反するもの   (ソ) 虚偽の内容を含むもの   (タ) 迷惑メール、スパムメール、無限連鎖講等不特定多数の者に対してその意思に反し、もっぱら勧誘・営利等を目的とするもの   (チ) その他当社が不適当であると判断するもの (6) 本サービスのネットワーク又はシステム等に過度な負荷をかける行為 (7) 本サービスの他の会員及びユーザーの情報の収集を目的とする行為 (8) 本利用契約に基づき当社から提供された本サイト及び本ソフトウェアを含む情報及び役務を本サービスの利用以外の目的のために使用する行為 (9) 本サービスに接続しているシステム全般について、権限なく不正にアクセスする行為、当社の設備に蓄積された情報を不正に書換え若しくは消去する行為、その他当社に損害を与える行為 (10) 他の会員及びユーザー又は第三者に成りすます行為 (11) 当社に対して虚偽の申告をする行為 (12) 当社による本サービスの運営を妨害するおそれのある行為 (13) 本規約及び本サービスの趣旨・目的に反する行為 (14) 各号の行為を直接又は間接に惹起し、又は容易にする行為 (15) 別途当社が承諾した場合を除き、第三者に対して本サービスを利用する権利を許諾したり与えたりすること (16) アカウント等の複製、頒布及び貸与、第三者への漏洩、リース、担保設定 (17) 本サービスに関連するドキュメントやプログラムの修正、変更、改造、解析、複製、翻訳、翻案等の改変 (18) 当社の許諾なく派生サービスを作成し配布する行為 (19) 知的財産権表示を削除又は改変すること (20) 当社が会員及びユーザー又は会員のサービスに推奨を与える又は後援していると、当社に無断で示唆する行為(一括送信時の問い合わせ先を当社にする行為等を含みます。) (21) 当社が書面又は電磁的方法により承諾した場合を除き、無料アカウントとして複数アカウントを作成する行為 (22) 当サービスを複製、改変し、本ソフトウェアの一部又は全部のリバースエンジニアリング、逆コンパイルもしくは逆アセンブルを行い、又はその他の方法でソースコードを抽出すること (23) プログラムのモニタ画面表示等を出版等に使用する行為 (24) 本ソフトウェアに設けられたコピーガード等の技術的な保護手段を回避する方法で使用すること (25) 第三者が複製できるように本ソフトウェアを公開すること (26) その他、当社が不適切と判断する行為 2. 会員は、前項各号のいずれかの事由に該当した場合、本サービスの月額の利用料金の合計金額の36か月分を違約金として、当社の定める方法により、直ちにこれを当社に対して支払わなければならないものとします。なお、この違約金の定めは、当社の会員に対する損害賠償請求を妨げるものではありません。 3. 会員は、第1項各号のいずれかの事由に該当した場合、当社に対して負っている債務の一切(本規約上の債務のみならず、利用者の当社に対する全ての債務を含みます。)について当然に期限の利益を失い、直ちに当社に対して全ての債務を履行しなければなりません。 4. 会員は、第1項に基づく措置がなされた後も、当社及びその他の第三者に対する本サービス利用上の一切の義務及び債務(損害賠償債務を含みますが、これに限りません。)を免れるものではありません。 5. 当社は、本条に基づき当社が行った行為により会員に生じた損害について、その責任を負わず、第1項に基づく措置がなされた後も、データ等を保有・利用することができるものとします。 14条 反社会的勢力の排除 1. 当社及び会員は、相手方が以下のいずれかに該当する場合、何らの催告をすることなく、相手方に対して、本サービスの提供に係る契約の解除、本サービスの一切の利用停止又は登録の取消その他自らが適当と判断する措置を講じることができるものとします。 (1) 暴力団、暴力団員、暴力団員でなくなった時から5年を経過しない者、暴力団準構成員、暴力団関係者、総会屋、社会運動等標ぼうゴロ又は特殊知能暴力集団等その他の反社会的勢力(以下「反社会的勢力」といいます。)に属すると認められるとき (2) 反社会的勢力が経営に実質的に関与していると認められるとき (3) 反社会的勢力を利用していると認められるとき (4) 反社会的勢力に対して資金等を提供し、又は便宜を供与するなどの関与をしていると認められるとき (5) 反社会的勢力と社会的に非難されるべき関係を有しているとき (6) 自ら又は第三者を利用して、相手方又は相手方の関係者に対し、詐術、暴力的行為、又は脅迫的言辞を用いたとき 2. 当社及び会員は、相手方が自ら又は第三者を利用して以下のいずれかに該当する行為をした場合には、何らの催告をすることなく、相手方に対して、本サービスの提供に係る契約の解除、本サービスの利用停止又は登録の取消その他自らが適当と判断する措置を講じることができるものとします。 (1) 暴力的な要求行為 (2) 法的な責任を超えた不当な要求行為 (3) 取引に関して、脅迫的な言動をし、又は暴力を用いる行為 (4) 風説を流し、偽計を用い又は威力を用いて相手方の信用を毀損し、又は相手方の業務を妨害する行為 (5) その他前各号に準ずる行為 3. 当社及び会員は、反社会的勢力のいずれでもなく、また、反社会的勢力が経営に実質的に関与している法人等ではないことを表明し、かつ将来にわたっても該当しないことを確約するものとします。 4. 当社及び会員は、本条の規定により、本サービスの提供に係る契約の解除、本サービスの一切の利用停止又は登録の取消その他自らが適当と判断する措置を講じた場合には、相手方に費用、損失及び損害が生じても、当該措置を講じた当事者は何らこれを賠償及び補償することはしないものとします。 5. 当社又は会員が本条に違反したことに起因又は関連して相手方に費用、損失及び損害(弁護士費用を含みますが、これに限りません。)が生じたときは、違反した当事者はその費用、損失及び損害を直ちに賠償するものとします。 15条 サービス期間・会員による解約 1. 本サービスのサービス期間は、原則として1ヶ月とします。なお、契約時に別段の定めがある場合には、その定めを優先するものとします。本サービスのサービス期間は、サービス期間満了時に同条件での自動延長とし、解約手続きを行わない限り、利用料金が発生します。 2. 会員がサービス期間内の解約を希望する場合、会員は残りのサービス期間の利用料金を支払うことで本サービスの解約ができるものとします。 3. 会員は、前項の中途解約をする場合、当社所定の方法により解約手続を行うこととし、当該解約手続の完了をもって、本契約が解約されるものとします。この場合、会員は、自己の責任において、当社からの解約に関する通知を確認するものとします。 4. 利用者が本契約を解約した場合、当社は利用者情報を消去することができます。 5. 本サービスの解約後、利用者が再度本サービスの利用を希望する際は、再度登録手続を行う必要があります。会員は再度の登録手続によって、解約前のデータが引き継がれないことを予め承諾するものとします。 本サービスの解約後、当社は、会員及びユーザーに対し、データ等を引き渡さないものとし、会員及びユーザーはこれを異議なく承諾するものとします。 16条 当社による契約解除 1. 当社は、会員又はユーザーが次の各号の一つに該当した場合には、会員に対して何らの通知催告をすることなく、本契約の一部又は全部を解除して利用者に対する本サービスの提供を停止することができます。 (1) 本規約に違反する行為を行った場合 (2) 当社に提供された登録情報の一部又は全部につき虚偽、誤記又は記載漏れがあった場合 (3) 現に制限行為能力者であるか、又は制限行為能力者になった場合において、催告後相当期間を経過しても法定代理人の記名押印のある同意書又は追認書の提出がない場合 (4) クレジットカード会社、立替代行業者等により利用者指定のクレジットカード、支払口座の利用が停止された場合 (5) 仮差押、差押、競売、破産手続開始、会社更生手続開始、民事再生手続開始等の申立があった場合、又は公租公課等の滞納処分を受けた場合 (6) 本サービスの利用提供の停止措置を受けた会員又はユーザーについて相当期間経過後もなおその原因となる事由が解消されない場合 (7) サービス停止事由に該当し、当社の業務の遂行に支障をきたすと当社が判断した場合 (8) 会員において、株式移転、株式交換、株式交付、会社分割、合併、事業の譲渡、株主構成の変動など、会員の営業に著しい影響を与え得る事由が生じた場合 (9) 過去に本サービスについてサービス提供の停止その他の処分を受けたことが判明した場合 (10) 手形又は小切手の不渡りが発生したときその他利用者の信用状態に重大な変化が生じたとき (11) 解散又は営業停止となったとき (12) 営業方法等について行政当局による注意又は勧告、もしくは行政処分を受けたとき (13) 会員又はユーザーが当社のコンピュータに保存されているデータを当社に無断で閲覧、変更もしくは破壊したとき、又はそのおそれがあると当社が判断したとき (14) 会員又はユーザーによる本サービスの利用態様が公序良俗に反し、又はそのおそれがあるなど、本サービスの利用継続が不適当であると当社が判断したとき (15) 本規約第１４条に違反したとき (16) その他上記のいずれかに準ずる行為 2. 前項の規定により本契約が解除された場合、会員は、本サービスの利用に係る一切の債務につき当然に期限の利益を喪失し、未払債務の全額を直ちに支払うものとします。なお、会員による本サービスの利用中に生じた利用者の一切の債務は、本契約の解除後も、その債務が履行されるまで消滅しないものとします。 3. 第1項により当社が本契約を解除し、会員に損害が生じた場合においても、当社は一切の責任を負わないものとします。 17条 サービスの一時停止 1. 当社は、次の各号に該当する場合には、会員に事前に通知を行うことにより、本サービスの一部又は全部の提供を一時的に停止し、又は本サービス上の機能を制限することができるものとします。但し、緊急の場合には、事前に通知することなく、直ちに本サービスの提供を停止し、又は本サービス上の機能を制限することができるものとし、事後、速やかに当該停止又は本サービス上の機能の制限につき通知するものとします。 (1) 電気通信設備の保守上若しくは工事上やむを得ない場合、又はこれらにやむを得ない障害が発生した場合 (2) 電気通信事業者が電気通信サービスの提供を中止するなど、当社以外の第三者の行為に起因して、本サービスの提供を行うことが困難になった場合 (3) 非常事態(天災、戦争、テロ、暴動、騒乱、官の処分、労働争議等)の発生により、本サービスの提供が困難になった場合、又は困難になる可能性のある場合 (4) 同期可能サービスの事情により、同期可能サービスが利用できなくなった場合 (5) 法令による規制、行政による規制等により、本サービスの提供が困難になった場合 (6) 本サービスに著しい負荷や障害が与えられることによって正常なサービスを提供することが困難である場合、又は困難であると当社が判断した場合 (7) データの改ざん、ハッキング等本サービスを提供することにより、利用者、第三者等が著しい損害を受ける可能性を当社が認知した場合 (8) 電気通信事業者又は国内外の電気通信事業体による電気通信サービス、電力会社による電力供給サービス、その他の公共サービスの提供が停止されることで、本サービスの提供が困難になった場合 (9) 本サービスに関するソフトウェアの更新作業のため、本サービス提供の中止又は機能制限が必要な場合 (10) 本サービス用のハード・ソフト・通信機器設備等に関わるメンテナンスや修理を定期的又は緊急に行う場合 (11) コンテンツサイト、情報提供元のシステム又は第三者サービスの一部又は全部の提供が一時的に停止又は中断された場合 (12) 前各号の他、当社が営業上又は技術上やむを得ないと判断した場合 (13) その他当社が本サービスの提供を停止し、又は本サービス上の機能を制限する必要があると判断した場合 2. 当社は、前項にかかわらず、提供ツールに係るコンピューター・システムの点検又はメンテナンス(以下「システムメンテナンス」といいます。)のために本サービスの利用の一部又は全部を中断することができるものとします。この場合、当社はシステムメンテナンス実施予定日の1週間前までに、当社の定める方法により会員に通知するものとします。但し、本サービスを構成する一部の提供ツールにおいては会員への通知なくシステムメンテナンスを実施する場合があります。 3. 当社は、前2項に基づいて行った措置により会員に生じた損害について一切の責任を負いません。 18条 サービスの変更 1. 当社は、当社の裁量により本サービスの一部の内容を変更、追加又は廃止(以下、合わせて「変更等」といいます。)することができます。当社は、本条に基づく本サービスの変更等により、変更等をする前の本サービスのすべての機能・性能が維持されることを保証するものではありません。 2. 当社は、本サービスに関する重要な変更等を行う場合、当社が定める方法により、事前に変更等の内容について会員に通知するものとします。但し、緊急を要する場合については、当該変更後、速やかに変更等の内容を通知するものとします。 3. 当社は、第1項に基づいて本サービスを変更等したことにより会員に生じた損害及び不利益につき一切の責任を負いません。 19条 サービスの中止・終了 1. 当社は、事前に会員に通知をした上で、当社の裁量により本サービスの一部もしくは全部の提供を中止又は終了することができます。但し、中止又は終了の内容が重大でない場合には、通知をすることなくこれらを実施することができます。 2. 当社は、前項に基づいて本サービスを中止又は終了したことにより会員に損害が発生した場合でも、一切の責任を負いません。 3. 当社は、本サービスに関する事業の一部又は全部を第三者に承継させる場合、本規約第5条に定める方法により利用者に事前に通知することをもって、本契約に基づく全ての当社の権利義務を承継させることができるものとします。但し、法令(証券取引所の諸規則を含みます。)上の制限又はその他やむを得ない事由により事前に通知することができない場合には、事後速やかに通知をするものとします。 4. 当社は、前項の措置に対して会員が第 15条に基づく本契約の解約をしない場合、前項の措置につき会員の承諾があったものとみなすとともに、当社から本サービスに関する当社の権利義務を承継する第三者に、本サービスを通じて発生する情報(会員の顧客情報、個人情報を含みますが、これに限りません。)を開示することができるものとします。 5. 会員は、当社が本サービスの提供の全てを中止又は終了する場合、当社に対して、当社が会員ごとに管理するAWSアカウントの譲渡を請求することができます。但し、アカウントは会員の当社に対するアカウント譲渡請求時点における現況での譲渡となるため、当社は、当該アカウントの現況による損害(譲渡請求時点で既に消去等の処理を行っていたために譲渡不可である場合を含みますが、これに限りません。)損害について一切の責任を負いません。 20条 知的財産権 1. 本サービスを通じて当社から会員及びユーザーに提供されるプログラムを含む一切の著作物の著作権(著作権法２７条及び２８条の権利を含みます。以下同じ。)、著作者人格権、特許権、商標権その他一切の知的財産権(各知的財産権を受ける権利及びノウハウ等も含みます。)はすべて当社に帰属し、会員及びユーザーは、本契約等により当社から事前に許諾を得た範囲内及び期間内においてのみこれらを使用できるものとします。 2. 会員及びユーザーは、当社の許諾を得ずに、当社が提供する情報等の翻訳、編集及び改変等を行い、第三者に使用させ、又は公開することはできず、いかなる理由によっても当社又は当社にライセンスを許諾している者の知的財産権を侵害し、又は侵害するおそれのある行為(逆アセンブル、逆コンパイル、リバースエンジニアリングを含みますが、これらに限りません。)をしてはなりません。 3. 会員及びユーザーが、本サービスの利用に際し創作したテキスト、画像、映像その他のコンテンツの著作権その他の知的財産権は利用者に帰属します。 4. 前項に定めるものを除き、本サービス、本ソフトウェア、本サービスに関連するソフトウェア、本サービスに関連して当社が加工、編集したコンテンツ及び統計情報並びに本サービスにより作成されたデータ(レポート、グラフ、図表を含みます。)に関する著作権その他一切の知的財産権は、当社に帰属します。 5. 当社は、当社のマーケティング等の目的で、利用者に事前に通知の上、会員の商号・商標・ロゴマークを使用することができるものとします。また、当社は、会員に事前に通知のうえ、会員が本サービスの利用者である旨の情報及び本サービスを用いて配信したコンテンツ、実施した施策等を一般的な表現で開示・公表することができるものとします。但し、会員が当社の通知後10営業日以内に異議を述べた場合は、この限りではありません。 21条 保証の否認・免責 1. 当社は、本サービスが推奨環境において機能するように合理的な最大限の努力を行いますが、特定の利用環境で動作することを含め、その品質及び機能について保証するものではありません。 2. 当社は、本サービスが全ての端末に対応していることを保証するものではなく、本サービスの利用開始時に対応していた場合でも、本サービスの利用に供する端末のOSのバージョンアップ等に伴い本サービスの動作に不具合が生じる可能性があることについて、会員は予め承諾するものとします。当社は、かかる不具合が生じた場合に当社が行うプログラムの修正等により当該不具合が解消されることを保証するものではありません。 3. 当社は、当社がガイドライン等で提示した本ソフトウェアの動作環境以外の環境で本ソフトウェアが動作することを保証するものではありません。 4. 当社は、会員及びユーザーの情報が正確性、正当性、有用性、完全性等を有することを保証するものではありません。会員及びユーザーは、会員及びユーザーの情報について、自らの判断及び責任において必要に応じ変更、修正等を行った上で利用するものとします。 5. 当社は、本サービス、本サービスを通じて提供されるコンテンツその他本サービスにより会員及びユーザーが取得し得る一切の情報が、会員及びユーザーの特定の目的に適合すること、期待する機能・商品的価値・正確性・有用性を有すること、会員及びユーザーによる本サービスの利用が会員及びユーザーに適用のある法令又は業界団体の内部規則等に適合すること、そのプログラムに欠陥がないこと、停止しないこと、プログラムのマニュアルや利用ガイドに誤り(バグを含みます)がないこと、本サービスの利用に関する問題を解決すること、本サービスを通じて提供されるコンテンツが適法に利用可能であること、当社以外が提供するサービス等の利用規約等を遵守していること及び第三者の権利を侵害しないこと等について、何ら保証するものではありません。 6. 当社は、本サービスの利用を通じた会員及びユーザーの業務上の成果等について保証するものではありません。また、当社の口頭又は書面によるいかなる情報又は助言も、新たな保証を行い、又はその他いかなる意味においても本保証の範囲を拡大するものではありません。 7. 当社の本サービスに関する義務及び責任は、本契約等及び法令に基づくものに限定され、当社は、本契約等及び法令に定めるもののほか、一切の責任を負わないものとします。 22条 損害賠償 1. 当社は、会員に対し、本契約有効期間中に本サービスが全く利用し得ない状態(全く利用し得ない状態と同程度の状態を含みます。)が発生した場合又は本サービスの利用により会員が損害を被った場合であっても、当該損害についていかなる責任も負わないものとします。但し、当社の故意又は重大な過失により会員が損害を被った場合には、直接かつ現実に発生した損害に限り、当該損害が発生した本サービスについて会員が現に支払った直近１年間の利用料金総額に相当する額を限度として損害賠償責任を負うものとし、これ以外の損害(利用者のデータの使用機会の逸失、その他の一切の間接損害、特別損害、付随損害、派生損害、逸失利益、データ喪失に係る損失等を含みますが、これらに限りません。)については一切の責任を負わないものとします。 2. 会員及びユーザーが本契約等に反した行為又は不正若しくは違法な行為によって当社に損害を与えた場合、当社は、会員に対し、損害賠償の請求を行うことができるものとします。 3. 本サービスに関して会員及びユーザーと第三者との間に紛争が生じた場合、会員は自己の責任と費用でこれを解決するものとし、当社に何ら迷惑をかけず、またこれにより当社が被った損害(弁護士費用を含みます。)を補償します。 23条 再委託 当社は、本サービスに関する業務の一部又は全部を第三者に委託することができるものとします。 24条 個人情報 1. 当社は、本サービスを利用する会員及びユーザーの個人情報について、個人情報の保護に関する法律(以下「個人情報保護法」といいます。)をはじめとする各種法令並びに当社個人情報保護方針及びプライバシーポリシー(https://anti-pattern.co.jp/legal/)に従って適切に取り扱います。 2. 当社は、会員及びユーザーが本サービスで利用する個人情報について、当社プライバシーポリシーに掲げる利用目的以外で利用しないものとします。 3. 当社は、会員及びユーザーが本サービスで利用する個人情報について、漏洩、減失又は毀損等の事故が発生した場合、その事実を速やかに会員に対して報告し、原因の調査を行い、事故の拡大防止に必要な措置を講ずるものとします。 4. 当社の提携先企業、広告主企業又は本サービスと連携可能な第三者サービスの運営事業者は、当社とは別個のプライバシーポリシーを設けています。当社は、これらの規約及び活動に対し、いかなる義務や責任も負っておりません。 5. 当社は、会員及びユーザーから収集した情報並びに会員及びユーザーの本サービスの利用状況を収集した情報を個別の法人、団体及び個人を識別することのできない形式に加工した匿名加工データ及び統計データ(以下「統計データ等」といいます。)に変換し、第三者に開示することがあります。この場合、開示されるのは特定の法人、団体及び個人を識別することのできない統計データ等のみであり、会員及びユーザーを識別できる情報を開示することはありません。 6. 当社は、個人情報保護法その他の法令及び個人情報の保護を目的として政府機関が公表している各種ガイドライン(以下「個人情報保護法等」といいます。)を遵守して、統計データ等の適正な取扱いを行います。 7. 当社が統計データ等を作成するときは、個人情報保護法等に基づく適切な加工を行った上で、安全管理措置を講じ、当該統計データ等に含まれる個人に関する情報の項目を当社ウェブサイト上に掲載いたします。 8. 当社が統計データ等を第三者に提供するときは、あらかじめ、第三者に提供される当該統計データ等に含まれる個人に関する情報の項目及びその提供の方法を当社ウェブサイト上に掲載して公表します。また、当該第三者に対して、当該提供に係る情報が匿名加工情報である旨を明示します。 9. 当社は、統計データ等について、漏えい、滅失又は毀損の防止等、その管理のために必要かつ適切な安全管理措置を講じます。また、統計データ等を取り扱う従業者や委託先(再委託先等を含みます。)に対して、必要かつ適切な監督を行います。 10. 当社は、利用状況データの取得・解析のために、Google Analytics 等を利用します。これらにおいては、cookie(クッキー)及びモバイルデバイスの識別情報(Android の広告識別子、OS の広告識別子等)等を使用し、個人を特定する情報を含むことなく、利用状況データを収集することがあります。 11. 当社は、会員及びユーザーの個人関連情報(個人情報保護法第2条第7項に定める「個人関連情報」をいいます。以下同じ。)を第三者より取得し、本人が識別される個人データ(以下「個人データ」といいます。)として利用することがあります。この場合において、会員及びユーザーは、あらかじめ当社が当該個人関連情報を個人データとして取得することについて同意するものとします。 12. 当社は、会員及びユーザーの個人関連情報を第三者に提供するに際して、当該第三者が個人関連情報を個人データとして利用することが想定される場合には、当該第三者が当該個人関連情報を個人データとして取得することにつきあらかじめ会員及びユーザーの同意を得ていることを確認します。 25条 秘密保持 1. 会員及び当社は、本規約に別段の定めがある場合を除き、本サービスに関連して口頭、資料、電磁的記録媒体その他の記録媒体等により相手方から提供された技術上、営業上又は業務上の一切の情報(但し、個人情報を除くものとし、以下、「秘密情報」といいます。)を本規約に定める利用目的のみに使用するものとし、相手方(以下情報の開示を行う当事者を「開示当事者」といい、情報開示を受ける当事者を「受領当事者」といいます。)の事前の書面による承諾なくして複製又は第三者への提供、開示若しくは漏洩をしてはなりません。但し、以下に定める情報は、秘密情報に含まれないものとします。 (1) 開示を受けた時点で既に公知となっていた、又は既に所有していた情報 (2) 正当な権利を有する第三者から秘密保持の義務を負うことなく合法的に入手した情報 (3) 開示を受けた後、自己の責によらず公知となった情報 (4) 開示当事者の秘密情報を利用することなく独自に開発した情報 2. 前項の規定に関わらず、受領当事者は、自己の責任において、以下の者に対し必要最小限の範囲内で秘密情報を開示し利用できるものとします。 (1) 販売パートナーを通じてお申し込みがあった場合の、当該販売パートナー(但し、「利用者情報」に限られます) (2) 本サービスの提供、管理、運営又は利用のために秘密情報を知る必要のある自己の子会社、親会社及び関連会社の取締役、監査役、従業員 (3) 弁護士、公認会計士、税理士、その他の法令上の守秘義務があり、かつ職業上の秘密保持義務を課せられた者 (4) 本規約又は申込書に別段の定めがある場合 (5) 受領当事者が秘密情報を開示する場合には、受領当事者が開示当事者に対して負担する秘密保持義務と同等の義務を当該開示先に課さなければなりません。 3. 会員及び当社は、法令又は裁判所若しくは政府機関の命令、要求若しくは要請に基づき、秘密情報を開示することができるものとします。但し、当該命令、要求又は要請があった場合、速やかにその旨を開示当事者に通知しなければなりません。 4. 受領当事者は、本契約の目的達成又は目的達成不能により秘密情報を保持する必要がなくなった場合には、秘密情報を削除するものとします。 5. 受領当事者は、第1項及び第2項のいずれかに反した場合、その事実を認識した時点から遅滞なく開示当事者に報告するものとします。また、この場合、受領当事者は、原因調査及び再発防止措置を講じ、その結果を開示当事者に報告するものとします。 26条 権利義務の譲渡禁止 会員は、当社の事前の書面による承諾を得ることなく、本契約に基づく権利義務を第三者に譲渡(合併、会社分割等による包括承継も含みます。)、移転、担保設定その他の処分をしてはならないものとします。 27条 準拠法、管轄裁判所 本規約及び本契約の準拠法は日本法とし、本規約及び本契約に起因し又は関連する一切の紛争については、東京地方裁判所を第一審の専属的合意管轄裁判所とします。 28条 分離可能性 本規約のいずれかの条項又はその一部が、法令等により無効又は執行不能と判断された場合であっても、他の条項の有効性には何らの影響も及ぼさないものとします。 29条 存続条項 第10条(利用者の責任)、第12条(バックアップ)、第14条(反社会的勢力の排除)、第16条(当社による契約解除)、第18条(サービスの変更等)、第20条(知的財産権)、第21条(保証の否認及び免責)、第24条(個人情報)、第25条(秘密保持)、並びに第26条(権利義務の譲渡禁止)から第30条(協議)については、当社と会員との間のサービス利用契約が終了した場合でも、その終了原因の如何を問わず、なお効力を有するものとします。 30条 協議 当社及び会員は、本規約に定めのない事項又は本規約の解釈に疑義が生じた場合には、互いに信義誠実の原則に従って協議の上速やかに解決を図るものとします。 ◆無料プランに関する特約 本契約等は、本サービスの無料利用にも適用します。但し、無料利用期間中は、本契約等の記載内容に関わらず、下記の通り取り扱うものとします。 ・当社は、「本サービスの無料版」を、本サービスの導入を検討することを目的として利用を希望するお客様（以下「無料版ユーザー」といいます。）に対して提供します。 ・無料版ユーザーは、「本サービスの無料版」の利用開始後、当社規定の利用可能期限まで「本サービスの無料版」を利用することができます。なお、利用可能期限の終期については、申込時にお知らせします。 ・「本サービスの無料版」において、無料版ユーザーは、契約内容にかかわらず最大１ライセンスの環境で利用できます。 ・「本サービスの無料版」の利用に伴って登録された無料版ユーザーのデータは、お客様が本サービスを導入された場合であっても、本サービスには引き継ぎができない場合があります。 ・当社は、「本サービスの無料版」の利用可能期限の経過後、無料版ユーザーの個別の同意を得ることなく、「本サービスの無料版」の利用に伴って登録された無料版ユーザーのデータをすべて削除できるものとします。また、当社は無料版ユーザーのデータの削除による一切の責任を負いません。 ・「本サービスの無料版」利用に関するサポートについては、当社が別途定める方法により提供するものとします。 ・当社は、事前若しくは事後の通知、又は無料版ユーザーの承諾を得ることなく、「本サービスの無料版」の提供を停止し、中断し、又は終了することができるものとします。 ・当社は、本サービスの利用に関して何らの保証もせず、無料版ユーザーが「本サービスの無料版」を利用した結果に関して一切責任を負いません。 ・無料版ユーザーの最終利用日から１４日間以上連続で利用されていないと当社が判断した場合、又は、本サービスの導入を検討することを目的としない利用であると当社が判断した場合には、当社は、無料版ユーザーのアカウントを削除できるものとします。 ・「本サービスの無料版」の利用期間中においては、当社は、無料版ユーザーに対して本サービスの仕様変更等の通知を行いません。 作成 2022年7月30日 改訂 2025年6月23日