自社でSaaSを開発する場合、作るものは「顧客の業務を助ける機能」だけではありません。複数の顧客企業が同じシステムを安全に使い分けるためのテナント分離、プランごとに使える機能を変えるプラン管理、毎月の料金を受け取る課金、顧客企業の中で利用者を増やす招待と権限、そして運営者が顧客を管理する運営管理機能が必要になります。これらはSaaSに特有の「土台」であり、通常のWebアプリ開発の感覚で見積もると抜け落ちやすい部分です。
開発の順序としては、テナント分離とデータ設計を最初に決め、次に認証・招待・権限、その上に顧客に価値を届ける中核の機能を作り、プラン管理と課金、運営管理機能を必要な段階で足していくのが基本です。中でもテナント分離と権限の基本構造は後から変えるのがきわめて難しいため、最初の版から正しく設計しておく必要があります。逆に、課金の自動化や細かなプラン設計は、最初の顧客を獲得する段階では手作業で代替できることも多く、後回しにできます。
この記事は、自社のノウハウや業務の仕組みをSaaSとして提供しようとしている事業責任者、新規事業の担当者に向けて書いています。SaaSに特有の要素、開発の順序、最初の版で省いてよいものと省いてはいけないもの、よくある失敗を、手順に沿って説明します。
自社SaaSと通常のWebアプリの違い
自社SaaSも技術的にはWebアプリの一種ですが、作るべき要素が大きく違います。主な違いを表で整理します。
| 観点 | 通常のWebアプリ（自社業務用など） | 自社SaaS |
|---|---|---|
| 利用する組織 | 自社だけ、または特定の取引先 | 不特定多数の顧客企業 |
| データの分離 | 組織をまたぐ分離は不要なことが多い | 顧客企業（テナント）ごとの厳格な分離が必須 |
| 利用者の追加 | 運営者が登録することが多い | 顧客企業の管理者が自分で招待する |
| 権限 | 自社の役割に合わせて固定的に設計 | 顧客企業ごとに役割を割り当てられる柔軟さが必要 |
| 料金 | 不要 | プランごとの料金、継続課金、請求 |
| 運営者の管理 | 自社の業務データの管理 | 顧客企業の契約状況、利用状況、問い合わせ対応 |
| 求められる信頼性 | 自社の業務に支障がない水準 | 顧客の業務を預かる水準。セキュリティ審査も受ける |
| 変更の影響 | 自社内で調整できる | すべての顧客に同時に影響する |
最後の行は特に重要です。SaaSでは、一つの変更がすべての顧客企業に同時に影響します。ある顧客の要望に合わせて機能を変えると、別の顧客の業務に支障が出ることがあります。そのため、機能の設計では「多くの顧客に共通する形」を見極める必要があり、顧客ごとの個別対応は設定で切り替えられるようにするか、そもそも受けないかを判断しなければなりません。
複数の顧客が一つのシステムを共有する仕組みをマルチテナントと呼びます。SaaSの土台は、このマルチテナントの設計から始まります。
自社SaaSの開発手順：作る順番の全体像
SaaSの開発は、次の順番で進めるのが基本です。
- 提供価値と最初の顧客像を決める：誰のどんな業務の、どんな課題を解決するのか。最初に使ってもらう顧客企業の像を具体的に描きます。
- テナント分離の方式とデータ設計を決める：顧客企業ごとのデータをどう分けるか。後から変えにくい、最も重要な設計です。
- 認証・招待・権限の基本構造を作る：ログイン、顧客企業の管理者による利用者の招待、役割に応じた権限の仕組みを作ります。
- 中核の機能を作る：顧客に価値を届ける、そのSaaSの本体となる機能を作ります。最初は課題の解決に直結するものに絞ります。
- 運営者用の最低限の管理機能を作る：顧客企業の登録、利用状況の確認、問い合わせ対応に必要な機能を作ります。
- プラン管理と課金を作る：料金プランと使える機能の対応、支払いの仕組みを作ります。最初は手作業で代替し、顧客が増えてから自動化することもできます。
- セキュリティと運用の体制を整える：操作の記録、バックアップ、監視、障害時の対応を整えます。
- 最初の顧客に使ってもらい、改善を回す：使われ方を見ながら、機能と運用を改善します。
この順番の要点は、2と3を最初に固めることです。中核の機能を先に作り込んでから、後でテナント分離や権限を組み込もうとすると、ほぼすべての画面とデータ処理を作り直すことになります。最初の版では、4の中核の機能を絞り込むほど、2と3に時間をかける余裕が生まれます。
テナント分離とデータ設計：最初に決める最重要事項
テナント分離とは、顧客企業ごとのデータを互いに見えないように分けることです。A社の利用者がB社のデータを見られてしまうことは、SaaSにとって最も重大な事故の一つです。
分離の方式には、大きく分けて次の三つがあります。
- データベースごと分ける方式：顧客企業ごとに別のデータベースを用意します。分離は最も強固ですが、顧客が増えるほど運用の手間が増えます。
- データベースの中の区画（スキーマ）で分ける方式：一つのデータベースの中で、顧客企業ごとに区画を分けます。中間的な方式です。
- 同じ表の中で顧客企業を識別する方式：すべての顧客企業のデータを同じ表に入れ、各行に「どの顧客企業のデータか」を示す情報を持たせます。運用の効率は高いですが、アクセスのたびに顧客企業を確かめる仕組みを確実に作る必要があります。
どれを選ぶかは、顧客企業の規模、求められるセキュリティの水準、想定する顧客数、運用の体制によって変わります。各方式の詳しい比較と選び方はSaaSのマルチテナント設計で解説しています。
データ設計で同時に考えておきたいのは、「顧客企業の中の構造」です。顧客企業の中に部署や拠点があり、部署ごとにデータを分けたい要望が出るか。一人の利用者が複数の顧客企業に所属することがあるか（たとえば、複数の会社の業務を受託している会計事務所の担当者など）。こうした構造は、後から対応しようとすると大きな改修になるため、最初の顧客像をもとに想定しておきます。
顧客企業ごとの設定をどこまで許すか
SaaSを提供し始めると、顧客企業から「うちでは項目の名前を変えたい」「この項目は不要なので隠したい」「承認の段階を一つ増やしたい」といった要望が必ず出てきます。これに個別の改修で応えていると、顧客ごとに少しずつ違うシステムを抱えることになり、変更のたびにすべての顧客への影響を確かめなければならなくなります。
そこで、データ設計の段階で「顧客企業ごとに変えてよいもの」を決め、それを設定として持たせる構造にしておきます。たとえば、表示する項目の名前、使う機能のオンとオフ、通知の宛先などは設定で切り替えられるようにし、業務の流れそのものを変える要望は、多くの顧客に共通するかを見てから標準機能として取り込むかを判断します。設定で吸収できる範囲を最初に決めておくことが、SaaSとして成長し続けるための条件になります。
認証・招待・権限：顧客企業が自分で使い始められる仕組み
SaaSでは、顧客企業の管理者が、自分で利用者を招待し、役割を割り当てられることが求められます。運営者が毎回手作業で利用者を登録していては、顧客が増えたときに対応できません。
最初の版で作っておきたいもの
- ログイン：メールアドレスとパスワード、またはGoogleなどのアカウントでのログイン。パスワードの再設定も含みます。
- 招待：顧客企業の管理者がメールアドレスを入力して招待し、招待された人が登録を完了できる仕組み。
- 基本的な役割：少なくとも「顧客企業の管理者」と「一般の利用者」の二つ。管理者だけが利用者の招待や設定の変更をできるようにします。
- 退職者の無効化：顧客企業の管理者が、退職した人のアカウントを無効にできる仕組み。
後から追加しやすいもの
- 細かな役割の追加（閲覧のみ、承認者など）
- 多要素認証
- 顧客企業のID管理基盤を使ったシングルサインオン
- 操作の記録を顧客企業の管理者が見られる画面
後から追加しやすくするためには、最初の版で「役割に応じて権限を判断する仕組み」を共通の部品として作っておくことが大切です。画面ごとに個別に権限を判断するような作りにしてしまうと、役割を一つ追加するたびに多くの画面を直すことになります。招待と権限の詳しい設計はSaaSの組織管理機能の設計で解説しています。
プラン管理と課金：手作業で始めて自動化する
SaaSの収益の柱は、顧客企業から毎月・毎年受け取る利用料です。そのためにはプラン管理と課金の仕組みが必要になりますが、最初の版ですべてを自動化する必要はありません。
プラン管理
プラン管理とは、料金プランごとに使える機能や上限（利用者数、データ量など）を変える仕組みです。最初の版で作っておきたいのは、「顧客企業がどのプランか」を記録し、プランによって機能の利用を切り替えられる構造です。プランの数や中身は、顧客の反応を見て変わることが多いため、プランの定義を後から変えやすい設計にしておきます。
課金
課金の方法は、主にクレジットカードによる継続課金と、請求書による支払いがあります。中小企業や個人事業主向けならカードでの継続課金、大企業向けなら請求書払いが求められることが多くなります。カードでの継続課金は、継続課金（サブスクリプション決済）に対応した決済サービスを使えば、自前で作る部分を大きく減らせます。
最初の顧客が少ないうちは、次のような手作業での代替が現実的です。
- 契約は書面やメールで結び、運営者が管理画面で顧客企業のプランを設定する
- 請求書は会計ソフトで発行し、入金の確認も手作業で行う
- プランの変更は、問い合わせを受けて運営者が対応する
顧客が増え、手作業の負担が大きくなった時点で、申し込みから支払い、プラン変更までを自動化します。課金の実装方法と、カード決済と請求書払いの作り分けはSaaSの課金システム実装で詳しく解説しています。
ただし、手作業で始める場合でも、「どの顧客企業が、どのプランで、いつからいつまで契約しているか」というデータだけは、最初からシステムに持たせておきます。このデータがないと、後で自動化するときに過去の契約の状態を再構成する手間がかかります。
運営管理機能と運用体制
運営管理機能
SaaSの運営者には、顧客企業を管理するための画面が必要です。最初の版で必要になることが多いのは次の機能です。
- 顧客企業の一覧と、契約・プランの状況の確認
- 顧客企業の利用状況（ログインの頻度、主な機能の利用量など）の確認
- 問い合わせを受けたときに、その顧客企業の状況を確かめる機能
- 顧客企業の利用の停止と再開
運営者が顧客企業のデータを見られる機能は、便利な一方でセキュリティ上の注意が必要です。誰が、いつ、どの顧客企業のデータを見たかを記録し、必要な人だけが使えるようにします。
運用体制
SaaSは顧客の業務を預かるため、公開後の運用体制が重要です。障害が起きたときの検知と連絡、データのバックアップと復旧、問い合わせへの対応、定期的なセキュリティの更新を、誰がどう担うかを決めておきます。大企業の顧客からは、セキュリティチェックシートへの回答を求められることも多いため、運用の記録を残しておくと対応が楽になります。
具体例：架空の工事現場向け日報SaaS
架空の例として、建設業の会社が、自社で使っていた現場日報の仕組みを、同業の工務店向けにSaaSとして提供する場面を考えます。
最初の顧客像は「従業員数十名規模で、複数の現場を同時に抱える工務店」としました。テナント分離は、顧客企業の数が多くなる見込みと運用の効率を考え、同じ表の中で顧客企業を識別する方式を選び、アクセスのたびに顧客企業を確かめる仕組みを共通の部品として作りました。データ設計では、顧客企業の中に「現場」という単位があり、職人が複数の現場を行き来することを想定しました。
権限は「会社の管理者」「現場の責任者」「職人」の三つの役割で始め、職人はスマートフォンから自分の日報を入力するだけ、現場の責任者は担当現場の日報を確認・承認できる形にしました。招待は会社の管理者が行い、職人にはメールでなく携帯電話番号で招待できるようにしてほしいという要望が出たため、これを最初の版に含めました。
課金は、最初の数社は請求書払いで契約し、運営者が管理画面でプランを設定する形にしました。カードでの継続課金とプラン変更の自動化は、顧客が一定数に増えてから着手する計画にしました。運営管理機能は、顧客企業の一覧、利用状況、利用の停止に絞りました。この順番で進めたことで、最初の版を短期間で公開し、実際に使ってもらいながら、職人が入力しやすい画面への改善に集中できました。
よくある失敗とその避け方
- 中核の機能から作り始め、テナント分離を後回しにする：後からテナント分離を組み込むと、ほぼすべての画面とデータ処理の作り直しになります。最初に設計します。
- 最初から課金を完全に自動化しようとする：顧客が少ないうちは手作業で十分なことが多く、自動化の開発で公開が遅れます。契約データだけは最初から持たせます。
- 最初の顧客の要望をそのまま機能にする：特定の顧客だけの要望を取り込むと、他の顧客にとって使いにくくなります。多くの顧客に共通する形かを見極め、個別対応は設定で切り替えられるようにします。
- 権限を画面ごとにばらばらに作る：役割の追加や変更のたびに多くの画面を直すことになります。共通の部品として作ります。
- 運営者の管理機能を忘れる：顧客企業の状況を確かめる手段がないと、問い合わせ対応や契約管理が回りません。
- 運用体制を考えずに公開する：障害やセキュリティの問題が起きたとき、すべての顧客に影響します。公開前に体制を決めます。
自社SaaS開発のチェックリスト
- 提供価値と最初の顧客像を具体的に描いた
- テナント分離の方式を、顧客の規模・セキュリティ要求・顧客数・運用体制から選んだ
- 顧客企業の中の構造（部署、拠点、複数所属）を想定してデータを設計した
- 顧客企業の管理者が利用者を招待し、役割を割り当てられる
- 権限の判断を共通の部品として作り、役割を追加しやすくした
- 顧客企業ごとのプランと契約期間のデータを持たせた
- 課金をどこまで手作業で始め、いつ自動化するかを決めた
- 運営者が顧客企業の状況を確認でき、その操作が記録される
- 障害対応、バックアップ、セキュリティ更新の体制を決めた
よくある質問
Q. 自社で使っているシステムを、そのままSaaSとして提供できますか？
そのままでは難しいことがほとんどです。自社用のシステムは、複数の顧客企業のデータを分ける仕組み、顧客が自分で利用者を招待する仕組み、プランと課金の仕組みを前提にしていないためです。自社の業務で得たノウハウは大きな強みになりますが、SaaSとしての土台は新たに設計する必要があります。
Q. 最初の版で、課金機能は必要ですか？
必ずしも必要ではありません。最初の顧客が少ないうちは、契約と請求を手作業で行い、運営者が管理画面でプランを設定する形でも運用できます。ただし、顧客企業ごとのプランと契約期間のデータは最初から持たせておくと、後で自動化するときにスムーズです。
Q. 開発の期間と費用はどう考えればよいですか？
中核の機能の量に加えて、テナント分離の方式、権限の細かさ、課金の自動化の範囲、運営管理機能の量で大きく変わります。見積もりが膨らむ要因と抑え方はSaaS開発の費用と期間で整理しています。新規事業として最初の版を短期間で作る場合は、Otsumuの「PoC / MVP Sprint」（300万円〜、税別・参考価格、6週間を目安に設計）のような進め方もあります。
Otsumuに相談できること
提供価値と最初の顧客像がはっきりしていて、社内にSaaSの開発経験がある技術者がいる場合は、この記事の手順とチェックリストに沿って、自社で開発を進めることも十分に可能です。特に、テナント分離と権限の基本構造を最初に固めるという原則を守れば、後の大きな作り直しは避けられます。
一方で、自社のノウハウをSaaSにしたいが、何を最初の版に入れるべきか絞り込めない場合や、テナント分離の方式や課金の自動化の時期を判断できない場合、大企業の顧客を想定していてセキュリティの要求にどこまで応えるべきか分からない場合は、SaaSの開発と事業の両方の視点を持つ外部の力を借りた方が、早く確実に進められます。
Otsumuは自らも事業を手がける立場から、SaaSの提供価値の整理から、後から変えにくい土台の設計、AIを活用した少人数・短期間の開発、公開後の改善までを一気通貫で支援しています。自社SaaSの開発はSaaS開発、新規事業として最初の版を短期間で作る場合は新規事業の爆速MVPシステム開発とPoC / MVP Sprintをご覧ください。
「自社の業務の仕組みをSaaSにできるか」という構想段階でも構いません。最初の顧客像と、最初の版に必要な範囲を一緒に整理するところから始められます。まずは30分の無料相談でお気軽にご相談ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01