BtoB SaaSの最初の版に入れる機能と、後回しにしてよい機能

BtoB SaaSの最初の版に入れるべき機能は、「中核の業務を一通り終えられる機能」と「法人が導入を判断するときに必ず確認される最低限の機能」の二つです。後者には、組織単位での利用、基本的な権限の分け方、データの安全な扱いと説明、請求書払いへの対応などが含まれます。一方で、細かな権限設定、外部システムとの連携、高度な分析画面、管理画面の多くの機能は、初期は運営の手作業や個別対応で補い、後回しにできることが多くあります。

この記事は、法人向けのSaaSを新しく立ち上げようとしている事業責任者、プロダクトマネージャー、最初の版の範囲を開発会社と相談している方に向けたものです。個人向けのサービスとは違う「法人ならではの導入判断」を踏まえて、何を作り、何を後回しにするかを考えるための材料をまとめました。

読み終えると、BtoB SaaSの導入判断で法人顧客が何を確認するか、最初の版に入れる機能と後回しにしてよい機能の見分け方、手作業で代替する方法、よくある失敗と避け方が分かります。

BtoB SaaSの最初の版が個人向けサービスと違う点

個人向けのサービスでは、利用者が自分で使うかどうかを決めます。気に入れば使い、気に入らなければ離れる、という単純な構造です。一方、法人向けのSaaSでは、使う人と、導入を決める人と、お金を払う人が異なることがよくあります。

• 実際に使う人：現場の担当者。使いやすさや業務の効率化を重視する。
• 導入を決める人：部門の責任者。業務の成果や費用対効果を重視する。
• 確認する人：情報システム部門や法務、経理。セキュリティ、契約、支払い方法を確認する。

このため、現場の担当者が「便利だ」と感じても、情報システム部門の確認で止まったり、請求書払いに対応していないために導入できなかったりすることがあります。BtoB SaaSの最初の版では、中核の機能だけでなく、こうした「導入の関門」を越えるための最低限の機能を考えておく必要があります。

一方で、法人顧客の要望をすべて最初から満たそうとすると、開発期間が大きく延びます。最初の版で目指すのは、すべての法人に対応することではなく、検証の対象とする法人が導入を判断できる状態を作ることです。

法人顧客が導入判断で確認すること

最初の版の範囲を考えるために、法人顧客が導入を判断するときに確認しやすい項目を整理します。

この表のうち、現場の担当者と部門の責任者に関わる部分は、主に機能で対応します。情報システム部門、法務、経理に関わる部分は、機能だけでなく、資料や運用で対応できることが多くあります。この区別が、最初の版の範囲を絞るうえで重要になります。

情報システム部門の確認では、セキュリティに関する質問項目をまとめたセキュリティチェックシートへの回答を求められることがよくあります。最初の版の段階で、回答の準備をしておくと導入が止まりにくくなります。

最初の版に入れるべき機能

BtoB SaaSの最初の版に入れるべき機能を、四つのまとまりで整理します。

中核の業務を一通り終えられる機能

最も優先すべきは、サービスが解決しようとしている業務を、最初から最後まで一通り終えられることです。たとえば請求書の発行サービスなら、取引先の登録、請求書の作成、送付、送付履歴の確認までが一続きでできる必要があります。途中の工程が欠けていると、現場の担当者は業務で使えず、検証になりません。

中核の業務の範囲は、検証したい仮説から決めます。機能の絞り方の考え方はMVPの機能の絞り方で詳しく説明しています。

組織単位での利用と基本的な権限

法人向けのサービスでは、一人ではなくチームで使うことが前提になる場合がほとんどです。最初の版でも、次の機能は入れておくことをおすすめします。

• 企業（組織）単位でアカウントを持ち、その中に複数の利用者が所属できる
• 利用者を組織に招待できる
• 最低限の役割の区別（管理者と一般利用者など）がある
• 組織の外のデータが見えないように分離されている

特に、組織の単位をデータの構造に持たせておくことは、後から変えるのが難しいため、最初の版で必ず考えておきます。マルチテナントの考え方を、最初から設計に入れておくということです。一方で、役割の種類を細かく分けたり、部署ごとに権限を設定したりする機能は、後回しにできることが多くあります。権限と招待の設計についてはSaaSの組織管理機能の設計で詳しく扱っています。

データの安全な扱い

法人顧客は、自社のデータが安全に扱われるかを重視します。最初の版でも、次の点は押さえておきます。

• 通信の暗号化（HTTPS）
• パスワードの安全な保管、または外部の認証サービスの利用
• データのバックアップと復旧の手順
• 組織間のデータの分離
• 誰がいつログインしたかの記録

これらは機能として目立つものではありませんが、情報システム部門の確認で必ず問われます。実装に加えて、「どのように対策しているか」を説明できる資料を用意しておきます。

契約と支払いへの対応

法人では、クレジットカードではなく請求書払いを求められることがよくあります。最初の版では、請求書の発行を運営の手作業で行う形でも構いませんが、請求書払いを受け付けられる状態にしておくことは、導入の障壁を下げるうえで大切です。課金の仕組みの作り方はSaaSの課金システム実装で整理しています。

後回しにしてよい機能と、その代替の方法

次に、最初の版では後回しにできることが多い機能と、その間の代替の方法を整理します。

ここで大切なのは、「後回しにする」と「何もしない」は違うということです。後回しにする機能について、顧客から質問されたときにどう答えるか、要望が出たときにどう対応するかを決めておきます。たとえば、シングルサインオンについて聞かれたら「現在は対応していないが、今後の対応を検討している」と答え、要望の数を記録しておく、といった具合です。

また、操作履歴のように「記録は残しておき、画面は後で作る」という分け方も有効です。データさえ残っていれば、必要になったときに画面を作れますが、記録していなかったデータは後から取り戻せません。

管理画面をどこまで作るかの判断は、MVPの管理画面は最小限でよいかで詳しく説明しています。

最初の版の範囲を決める手順

ここまでの考え方を、範囲を決める手順にまとめます。

1. 検証の対象とする顧客像を決める：業種、規模、利用する部署、導入を決める人を具体的に書く。対象が広すぎると、必要な機能も増える。
2. 中核の業務の流れを描く：対象の顧客が、サービスを使って業務を最初から最後まで終える流れを、画面単位で書き出す。
3. 導入の関門を洗い出す：対象の顧客が導入を判断するときに、誰が何を確認するかを書き出す。可能であれば、見込み顧客に直接聞く。
4. 関門ごとに対応の方法を決める：機能で対応するもの、資料で対応するもの、運用（手作業）で対応するものに分ける。
5. 後回しにする機能と代替の方法を決める：後回しにする機能について、顧客に聞かれたときの答え方と、初期の代替の方法を決める。
6. 後から変えにくい部分を確認する：組織の単位、データの分離、ログの記録など、後から変えにくい設計を開発チームと確認する。
7. 範囲を関係者で合意する：作るもの、作らないもの、代替の方法を一覧にし、事業責任者と開発チームで合意する。

顧客が増えてきたら、後回しにした機能をどの順番で作るか

最初の版で後回しにした機能は、顧客が増えるにつれて少しずつ仕組み化していきます。どの順番で作るかは、次の三つの観点で判断すると迷いにくくなります。

1. 運営の手作業の負担が大きいもの：請求書の発行や初期設定の代行など、顧客の数に比例して運営の作業が増えるものは、対応が遅れると顧客の体験に直接響きます。作業時間を記録し、負担が大きくなってきたものから自動化します。
2. 導入の判断を止めているもの：商談や導入検討の場で「これがないと導入できない」と言われた回数が多い機能です。シングルサインオンや細かな権限設定などが該当しやすく、要望を記録しておくと優先度を判断できます。
3. 継続利用に影響しているもの：導入後の利用状況を見て、使われなくなった企業に共通する不足がある場合、その機能を優先します。外部システムとの連携がないために、二重入力が負担になって離れていく、といったケースです。

逆に、一社から強く要望されているが他の顧客には共通しない機能や、営業の場で見栄えがするだけの機能は、優先度を下げます。顧客の声と利用状況、運営の負担を同じ一覧に並べて、月に一度程度見直すと、場当たり的な追加を防げます。

BtoB SaaSの最初の版でよくある失敗と避け方

失敗1：大企業の要件を最初から満たそうとする

大企業は導入の効果が大きく魅力的ですが、セキュリティや権限、連携の要件が厳しく、最初の版で満たそうとすると開発期間が大きく延びます。避け方は、最初の検証対象を、要件が比較的シンプルな中小規模の企業や、特定の部門での小さな導入に絞ることです。大企業との検証が必要な場合は、大企業の新規事業でMVPを作るときの社内調整とセキュリティ審査のような観点で、確認事項を早めに洗い出します。

失敗2：一社の要望に合わせて作り込む

最初の顧客の要望をそのまま機能にすると、その一社専用のサービスになってしまいます。避け方は、要望の背景にある業務の課題を聞き、他の顧客にも共通するかを確認してから作ることです。共通しない要望は、運用での対応や個別の工夫にとどめます。

失敗3：組織の単位を考えずに作る

最初は一人で使う前提で作り、後から組織での利用に対応しようとすると、データの構造から作り直しになることがあります。避け方は、最初の版から組織の単位をデータに持たせておくことです。画面上は一人の利用でも、データは組織に所属する形にしておけば、後の拡張が楽になります。

失敗4：セキュリティの説明を準備していない

機能は十分なのに、情報システム部門の質問に答えられず、導入が止まる失敗です。避け方は、データの保管場所、暗号化、アクセス管理、バックアップ、障害時の対応などをまとめた説明資料を、最初の版の公開と同時に用意しておくことです。

失敗5：手作業の負担を見積もっていない

後回しにした機能を手作業で補う計画にしたものの、顧客が増えるにつれて運営の負担が大きくなり、対応が遅れる失敗です。避け方は、手作業の内容と頻度を書き出し、顧客が何社になったら仕組み化するかの目安を決めておくことです。

失敗6：導入後の支援を考えていない

法人向けのサービスでは、契約が決まっても、現場の担当者が使い始めるまでに初期設定やデータの登録、社内への周知など多くの作業が必要です。ここで手が止まると、契約したのに使われないまま更新の時期を迎えることになります。避け方は、最初の版の段階では機能で解決しようとせず、運営が導入の初期に伴走し、初期設定の代行や説明の場を用意することです。そこで分かったつまずきが、次に作るべき機能の候補になります。

BtoB SaaSの最初の版のチェックリスト

• 検証の対象とする顧客像（業種、規模、導入を決める人）が決まっている
• 中核の業務を最初から最後まで一通り終えられる
• 組織単位での利用と、利用者の招待ができる
• 管理者と一般利用者の最低限の役割の区別がある
• 組織間のデータが分離されている
• 通信の暗号化、認証、バックアップ、ログインの記録が整っている
• セキュリティに関する説明資料を用意している
• 請求書払いに対応できる（手作業でもよい）
• 利用規約とプライバシーポリシーが整っている
• 後回しにした機能について、顧客への答え方と代替の方法が決まっている
• 手作業の内容と、仕組み化の目安が決まっている

具体的な場面で考える：架空の採用管理SaaSの例

架空の例として、従業員数十〜数百名規模の企業向けに、採用の応募者管理を行うSaaSの最初の版を作る場面を考えます。

関係者から出た機能の候補は、求人の作成、応募者の一覧と選考状況の管理、面接日程の調整、評価の記入、求人サイトとの自動連携、詳細な権限設定、採用の分析レポート、シングルサインオン、内定者の手続き管理などでした。

まず、検証の対象を「人事担当者が数名で、複数の求人媒体から応募を受けている中小企業」に絞りました。中核の業務は「応募者を一か所に集め、選考状況を共有し、評価を記入する」流れです。

最初の版に入れたのは、応募者の登録と一覧、選考状況の管理、評価の記入、組織への担当者の招待、管理者と面接官の二つの役割でした。求人サイトとの自動連携は、媒体ごとにCSVを取り込む機能で代替しました。分析レポートは、運営が月に一度集計して送る形にしました。シングルサインオンと内定者の手続き管理は後回しにし、問い合わせがあった企業を記録することにしました。

一方で、応募者の個人情報を扱うため、データの分離、アクセスの記録、セキュリティに関する説明資料は最初から整えました。実際に、導入を検討した企業の多くから個人情報の扱いについて質問があり、資料を用意していたことで導入の判断が進みました。

よくある質問

Q. BtoB SaaSの最初の版で、無料のお試し期間は必要ですか？

必須ではありません。法人の場合、無料期間よりも、担当者が実際の業務で試せるよう導入の支援をするほうが効果的なこともあります。検証の目的が支払い意思の確認なら、最初から有料で提供し、導入初期の支援を手厚くする方法もあります。

Q. 最初の顧客から「この機能がないと導入できない」と言われたらどうすればよいですか？

その機能が導入の関門なのか、あれば便利な機能なのかを確認してください。関門であり、他の顧客にも共通するなら、優先して対応を検討します。一社だけの要件なら、運用での代替や、導入の時期をずらすことを相談します。

Q. 導入後の定着はどう確認すればよいですか？

導入した企業で、どれだけの担当者が、どの頻度で中核の業務を行っているかを見ます。オンボーディングの指標の考え方はBtoB SaaSのオンボーディング指標で詳しく説明しています。

Q. 最初の版から有料プランを複数用意すべきですか？

最初は一つか二つのプランで始め、顧客の使い方や要望を見ながら分けていくのが現実的です。プランを細かく分けると、権限や機能の出し分けの開発が必要になり、範囲が広がります。

Otsumuに相談できること

対象とする顧客像がはっきりしていて、見込み顧客に導入の関門を直接聞ける関係があり、社内に開発の判断ができる担当者がいるなら、この記事の手順で最初の版の範囲を自社で決められます。特に、中核の業務の流れと導入の関門を書き出すだけでも、作るべきものと後回しにできるものはかなり整理されます。

一方で、対象の顧客像がまだ絞り切れていない、法人顧客のセキュリティ確認にどう備えればよいか分からない、組織や権限の設計に自信がない、といった場合は、外部の力を借りることで手戻りを減らせることがあります。

Otsumuは、目的から逆算して必要な機能に絞る進め方を大切にしています。新規事業の爆速MVPシステム開発では、BtoB SaaSの最初の版の範囲の決定から、AIを活用した短期間の開発、公開後の改善まで一気通貫で支援します。SaaSとしての本格的な開発についてはSaaS開発のページでも紹介しています。範囲を決めて作り切る形としては、6週間を目安に設計するPoC / MVP Sprint（300万円〜、税別・参考価格）もあります。

最初の版に何を入れるか迷っている段階でも構いません。30分の無料相談で、想定している顧客と業務をお聞かせください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01