自分の店舗、あるいは自分が働く会社の中だけで使っていた社内ツールを、外部の顧客に提供するSaaS（サービスとしてのソフトウェア）に変えたいと考えたとき、「今あるものを、そのまま使えばいいのだろう」と思ってしまうことがあります。しかし、社内ツールとSaaSの間には、見た目には分かりにくい、大きな設計上の違いがあります。この記事では、社内ツールをSaaS化するときに、作り直すべき部分の見極め方を解説します。
なお、社内で動いていたPoC（概念検証）的なシステムを本番のSaaSへ仕上げていく際の確認点については、PoCを本番システムに仕上げる際の確認点でも整理されている。
この記事で分かること
社内ツールは、多くの場合、「自分たちだけが使う」という前提で設計されています。この前提を、SaaSとして複数の顧客に提供する際にどう変えるべきかを、具体的な観点ごとに整理します。この記事では、作り直しが必要になりやすい代表的な部分と、その優先順位のつけ方を紹介します。
結論を先に示すと、押さえておきたいポイントは次の3つです。
- データを、顧客ごとに分離する仕組みが必須になる
- 権限管理を、顧客・利用者の単位で作り直す必要がある
- サポート・オンボーディングの仕組みを、新たに用意する必要がある
社内ツールとSaaSの、根本的な違い
社内ツールは、基本的に「単一の組織が、単一のデータセットを扱う」という前提で作られています。利用者は、すべて同じ会社の人間であり、扱うデータも、その会社のものだけです。これに対してSaaSは、「複数の異なる顧客が、それぞれ独立したデータを扱う」という前提が必要になります。
この違いは、単に「利用者が増える」というだけの話ではありません。ある顧客のデータが、別の顧客から見えてしまってはいけない、ある顧客の操作が、別の顧客の環境に影響を与えてはいけない、といった、独立性を保証する仕組みが、根本から必要になります。この根本的な違いを理解していないと、「機能はできているのだから、あとは営業するだけだ」と考えてしまい、実際には、まだ大きな作り直しが必要な段階であることに気づけないことがあります。
社内ツールを作った本人からすると、「動いているものがあるのに、なぜまた作り直すのか」という感覚を持つのは自然なことです。しかし、ここで見落とされがちなのは、社内ツールが「動いている」という状態は、あくまで「自分たちの使い方の範囲内で動いている」ということに過ぎない、という点です。SaaSとして不特定多数の顧客に使われるようになると、想定していなかった使い方、想定していなかったデータ量、想定していなかった同時アクセスが発生します。社内での運用では一度も問題にならなかった部分が、顧客が増えた途端に一気に露呈する、というのはよくある失敗パターンです。
作り直しが必要になりやすい部分1：データの分離（マルチテナント化）
社内ツールでは、すべてのデータが、1つの組織のものとして、まとめて管理されていることが一般的です。これをSaaSとして複数の顧客に提供する場合、顧客Aのデータと、顧客Bのデータが、システムの内部で明確に分離され、互いに干渉しない仕組み（マルチテナント化と呼ばれることもあります）が必要になります。
この分離の仕組みが不十分だと、最悪の場合、ある顧客が、別の顧客のデータを見られてしまう、という重大な問題につながる可能性があります。データの分離は、SaaS化における最も基本的で、かつ最も重要な作り直しのポイントです。
実際に、権限管理やデータ分離をどのように本番の設計へ落とし込んでいくかという手順は、権限管理やデータ分離を本番設計に落とし込む手順でも具体的に紹介されている。
データ分離の見極め方
自分の社内ツールが、この観点でどの程度作り直しが必要かを見極めるには、「今のデータベースの構造に、〇〇株式会社、△△株式会社という、顧客を区別する情報が、明確に組み込まれているか」を確認することをおすすめします。この情報が組み込まれていない、あるいは、後から無理に付け足したような構造になっている場合、根本的な作り直しが必要になる可能性が高いと考えられます。
データ分離でよくある失敗パターン
実際にSaaS化を進めた事例を見ていくと、データ分離の設計でつまずくパターンには、いくつかの典型があります。
1つ目は、「顧客IDを、後から一部の画面にだけ付け足した」というパターンです。新しく作った画面には顧客を区別する仕組みが入っているのに、社内ツール時代から使っていた古い画面や、裏側の集計処理には、顧客を区別する仕組みが入っていない、という状態です。この状態だと、表向きは複数顧客に対応しているように見えても、裏側の集計や検索機能で、顧客をまたいだ情報が混在して表示されてしまう、という不具合が後から発覚することがあります。
2つ目は、「削除機能を、顧客単位で正しく検証していない」というパターンです。社内ツールの時代は、データを消す操作をする人が限られていたため、多少雑な削除処理でも問題にならなかったかもしれません。しかし、複数の顧客が同じシステムを使うようになると、ある顧客が自分のデータを削除する操作をしたときに、条件の書き方が甘いと、他の顧客のデータまで一緒に削除されてしまう、という重大な事故につながる可能性があります。
3つ目は、「テスト環境で、顧客を1社しか想定していなかった」というパターンです。開発の途中で動作確認をする際、テストデータが1社分しかないと、複数顧客が同時に使った場合の不具合に気づけません。最低でも2社分のダミーの顧客データを用意し、それぞれの画面で「自分の会社のデータだけが表示されているか」を確認する工程を、開発の初期段階から組み込んでおくことをおすすめします。
作り直しが必要になりやすい部分2：権限管理の作り直し
社内ツールでは、「社員全員が、基本的に同じ権限を持つ」「一部の管理者だけが、特別な権限を持つ」というように、権限の設計が、比較的シンプルであることが多くあります。SaaSとして複数の顧客に提供する場合、顧客ごとに、管理者・一般利用者といった役割を、独立して設定できる権限管理の仕組みが必要になります。
さらに、ある顧客の管理者が、別の顧客の情報や設定に、アクセスできてしまわないよう、権限の範囲を、顧客の単位できっちりと区切る必要があります。この権限管理の作り直しは、データの分離と密接に関わっており、両方をセットで検討する必要があります。
権限管理の見極め方
「今のツールで、管理者権限を持つ人が、他の会社の情報にアクセスできてしまう可能性はないか」を確認してみることをおすすめします。もし、社内ツールの段階で、権限の管理が曖昧なまま運用されていた場合、SaaS化の際には、この部分を、明確なルールに基づいて、一から設計し直す必要があります。
権限設計を考えるときの具体的な視点
権限管理を作り直す際には、次のような利用者の役割を、あらかじめ想定しておくと整理しやすくなります。
- 契約者（顧客企業の代表者）：料金プランの変更や、契約の解約など、契約そのものに関わる操作ができる立場
- 顧客側の管理者：自社の利用者を追加・削除したり、自社内の設定を変更したりできる立場
- 顧客側の一般利用者：日々の業務でツールを使うだけで、設定変更などの権限は持たない立場
- 提供側の運営者：全顧客の状況を横断的に確認できるが、通常は個別の顧客データの内容そのものには介入しない立場
社内ツールの時代には、こうした役割の区別を考える必要がなかったケースがほとんどです。SaaS化にあたっては、「誰が、何を、どこまで操作できるのか」を、この4つの立場それぞれについて、表に書き出して整理しておくと、開発会社に要件を伝える際にも役立ちます。
作り直しが必要になりやすい部分3：サポート・オンボーディングの仕組み
社内ツールを使う場合、使い方が分からなければ、隣の席の同僚や、システムに詳しい人に、直接聞くことができます。しかし、SaaSとして外部の顧客に提供する場合、顧客は、身近に質問できる相手がいないまま、ツールを使い始めることになります。
この違いを埋めるために、初めて使う顧客が、迷わずに使い始められるようにするための仕組み（オンボーディング）や、使い方について質問できるサポート体制を、新たに用意する必要があります。ツール自体の機能がどれだけ優れていても、この仕組みが整っていないと、顧客が使い方に迷い、そのまま離脱してしまうことがあります。
サポート・オンボーディングの見極め方
「今の社内ツールを、全く知らない人に、いきなり渡したとしたら、迷わずに使い始められるか」を、想像してみることをおすすめします。もし、「まず誰かに説明してもらわないと使えない」という状態であれば、SaaS化に向けて、初めての利用者向けの説明や、案内の仕組みを、新たに用意する必要があります。
オンボーディングで用意しておきたい具体的な要素
最初から手厚いオンボーディングを作り込む必要はありませんが、最低限として、次のような要素を検討することをおすすめします。
- 初回登録後に表示する、簡単な使い方ガイド：画面の主要な機能を、数ステップで案内する仕組み
- よくある質問（FAQ）のページ：問い合わせが集中しそうな内容を、あらかじめ想定して用意しておく
- 問い合わせを受け付ける窓口：メールフォームやチャットなど、顧客が質問できる手段を、必ず1つ以上用意する
- 初期設定を代行、あるいは支援する仕組み：顧客が自分でデータを登録するのが難しい場合、初期設定を手伝う仕組みがあると、離脱を防ぎやすくなる
サポート体制については、最初から24時間対応のような大掛かりな仕組みを用意する必要はありません。顧客数がまだ少ない立ち上げの段階では、開発者自身が問い合わせに対応する、という体制でも十分に機能します。重要なのは、「困ったときに、連絡できる先が明確に用意されている」という状態を、最初から作っておくことです。
その他、作り直しの優先順位を検討すべき部分
デザイン・操作性の見直し
社内ツールは、機能性を重視して、デザインの見た目にはあまりこだわらずに作られていることがあります。SaaSとして外部の顧客に提供する場合、第一印象や、使いやすさの印象が、顧客の継続利用に大きく影響するため、デザイン・操作性の見直しも、検討すべき項目の一つです。
ただし、デザインの見直しは、データの分離や権限管理といった、根本的な仕組みの作り直しと比べると、後回しにしても、大きな問題にはつながりにくい部分です。優先順位としては、まず根本的な仕組みを整えることを優先し、デザインの改善は、その後の段階で進めることをおすすめします。
料金プラン・契約管理の仕組み
社内ツールには、料金という概念自体が存在しませんが、SaaSとして提供する場合、料金プランの設計や、契約状況（支払いが済んでいるか、契約が有効かなど）を管理する仕組みが必要になります。この仕組みも、決済機能と関連するため、専門家に依頼することを検討すべき部分です。決済・個人情報。専門家に頼むべき機能の見分け方については、別記事で詳しく解説しています。
作り直しの優先順位を、どう決めるか
これまで紹介した項目は、すべてを同時に、完璧に作り直す必要はありません。優先順位を決める際は、次の考え方を参考にすることをおすすめします。
- セキュリティやデータの独立性に関わる部分（データの分離、権限管理）を、最優先で対応する
- 顧客が最初に触れる部分（オンボーディング、基本的な操作性）を、次に対応する
- 見た目やデザイン、細かい利便性は、最後に、段階的に改善していく
この優先順位に沿って進めることで、限られた時間や予算の中でも、リスクの大きい部分を先に押さえながら、SaaS化を進めていくことができます。
優先順位を判断するためのチェックリスト
自分の社内ツールがSaaS化に向けてどの段階にあるかを、次のチェックリストで確認してみることをおすすめします。当てはまる項目が多いほど、根本的な作り直しの範囲が大きいと考えられます。
- [ ] データベースの構造に、顧客を区別する項目が入っていない
- [ ] 権限は「管理者か、一般社員か」の2段階程度しか存在しない
- [ ] ツールの使い方は、口頭やその場での説明を前提にしている
- [ ] 料金や契約状況を管理する仕組みが、そもそも存在しない
- [ ] バックアップは、なんとなく定期的に取っている程度で、復旧の手順が明確でない
- [ ] 誰が何を操作したかを記録する仕組みが、ほとんどない
- [ ] 利用規約やプライバシーポリシーを、まだ作っていない
このチェックリストで3つ以上当てはまる場合は、「今のツールに機能を追加する」という発想ではなく、「今のツールの経験を活かして、新しく設計し直す」という発想に切り替えたほうが、結果的にスムーズに進むことが多いです。
作り直しの規模を、事前に把握する方法
作り直しの規模がどれくらいになるかを、非エンジニアが正確に見積もることは難しいですが、開発会社に相談する前に、大まかなイメージを持っておくことは可能です。今の社内ツールの画面を1つずつ確認し、「この画面は、顧客ごとに内容が変わる必要があるか」「この画面は、全顧客共通でよいか」を、整理しておくことをおすすめします。
この整理をした資料を持って、開発会社に相談することで、より具体的で、精度の高い見積もりを受けやすくなります。専門知識ツールの一部機能について、内製と外注どちらが向いているかについては、別記事で詳しく解説していますが、SaaS化における作り直しも、多くの場合、専門家の力を借りるべき領域です。内製か外注か、契約や法務も含めた開発期の実務については、内製か外注か、そして契約と法務。開発期をやり切るための実務ガイドでも整理している。
一度に全部SaaS化するのではなく、段階的に進める
社内ツールをSaaS化する際、最初から、すべての機能を、完璧なSaaSの形に作り直そうとすると、時間も費用もかかりすぎてしまうことがあります。まずは、最低限のデータ分離と権限管理を実現した、シンプルな形でSaaS化し、実際に顧客に使ってもらいながら、必要な機能を、段階的に追加していくという進め方が、現実的です。
この進め方は、MVP（実用最小限の製品）の考え方と同じで、最初から完璧を目指すのではなく、最低限使える形で市場に出し、フィードバックを得ながら改善していくという方針です。予算300万円で何を作るかを扱った別記事でも、この機能を絞り込む考え方について、詳しく解説しています。
段階的な進め方の一例
具体的なイメージを持つために、段階を分けて進める場合の一例を紹介します。
第一段階：データ分離と、最低限の権限管理（管理者・一般利用者の2種類程度）だけを実装し、数社の顧客に試験的に使ってもらう。デザインは既存の社内ツールのものを、大きく変えずに流用する。
第二段階：試験導入の中で見えてきた不満や要望をもとに、オンボーディングの案内画面や、簡単なFAQページを追加する。同時に、バックアップとログの仕組みを整える。
第三段階：顧客数が増えてきた段階で、料金プランの多様化や、デザインの本格的な見直し、より細かい権限設定などを追加していく。
この順番で進めることで、初期の開発費用を抑えながら、実際の顧客の反応を見て、本当に必要な機能に投資を絞ることができます。逆に、最初から第三段階の内容まで詰め込もうとすると、開発期間が長引き、市場に出す前に資金が尽きてしまう、というリスクが高まります。
専門知識を活かしたツールの場合、SaaS化で特に注意したい点
専門分野の業務ロジックを含む社内ツールをSaaS化する場合、その業務ロジックが、顧客ごとにどこまで共通しているか、どこから顧客ごとの個別対応が必要になるかを、慎重に見極める必要があります。専門知識に基づく業務ロジックは、業界内でおおむね共通する部分と、事業者ごとの個性が出る部分が、混在していることが多くあります。
この見極めが不十分だと、「共通のロジックとして作ったつもりだったが、実際には、顧客ごとに個別対応が必要だった」という事態が、SaaS化した後に発覚することがあります。事前に、複数の同業者の業務フローを聞き取り、共通する部分と、個別に異なる部分を、整理しておくことをおすすめします。
例えば、業種によって独自の計算ルールや、独自の書式が存在する場合、自分の店舗だけの運用を前提に組んだロジックが、他の同業者にはそのまま当てはまらない、ということが少なくありません。「自分の店ではこうしているが、同業者は違うやり方をしているかもしれない」という視点を持ち、SaaS化の設計段階で、複数の同業者にヒアリングをしておくことが、後々の作り直しの手間を減らす近道になります。
作り直しの際に、見落とされやすい細部
バックアップとデータ復旧の仕組み
社内ツールの場合、データが消えてしまっても、社内の誰かが原因を調べ、時間をかけて復旧を試みることができました。しかし、外部の顧客にサービスを提供する場合、「データが消えました、直すまで少々お待ちください」という対応は、顧客の信頼を大きく損ないます。定期的なバックアップと、問題が起きた際に迅速に復旧できる仕組みは、社内ツールの段階では見落とされがちですが、SaaS化においては欠かせない要素です。
利用状況の可視化・ログの記録
社内ツールでは、誰がいつ何を操作したかを、厳密に記録する必要性は、それほど高くありませんでした。しかし、SaaSとして複数の顧客に提供する場合、不具合が発生した際に「いつ、どの顧客の、どの操作で問題が起きたか」を特定できるログの仕組みが、原因調査や、顧客への説明のために重要になります。この仕組みも、後から追加しようとすると手間がかかるため、SaaS化の初期段階で組み込んでおくことをおすすめします。
利用規約・プライバシーポリシーの整備
社内ツールには、利用規約という概念自体がありませんが、外部の顧客に提供するSaaSには、サービスの利用条件を定めた利用規約と、個人情報の取り扱いを定めたプライバシーポリシーが必須です。この整備を後回しにしたまま顧客への提供を始めてしまうと、トラブルが発生した際に、対応の根拠となる文書が存在しない、という状態に陥ります。法律が関わる機能を専門家に頼む理由については、別記事でも詳しく解説していますが、これらの文書の整備も、専門家に相談すべき領域です。
システムの負荷・パフォーマンスへの配慮
社内ツールは、同時にアクセスする人数が、多くても数十人程度に限られていることがほとんどです。SaaSとして展開し、顧客数が増えていくと、同時にアクセスする利用者の数が、社内ツールの時代とは比較にならない規模になる可能性があります。社内ツールの時代のままの作りだと、顧客数が増えた段階で、画面の表示が遅くなったり、処理が止まってしまったりする、というトラブルが起きることがあります。すべてを最初から完璧に対応する必要はありませんが、「顧客数が今の10倍になったら、どこが最初に問題になりそうか」を、開発会社と一緒に確認しておくと、想定外のトラブルを減らすことができます。
既存顧客（社内利用者）への影響を、どう扱うか
社内ツールをSaaS化する際、忘れられがちなのが、「今まさに、社内でそのツールを使っている人たち」への影響です。SaaS化のための作り直しを進めている間も、社内の業務は止まらずに続いています。作り直しの規模が大きい場合、社内での利用を続けながら、並行してSaaS版の開発を進める必要が出てきます。
この場合、次の2つの進め方が考えられます。
1つ目は、「今の社内ツールは、そのまま社内用として動かし続けながら、SaaS版は別のシステムとして、新しく作る」という進め方です。この方法は、社内の業務に影響を与えずに進められる一方、開発が完了するまで、2つのシステムを並行して管理する手間がかかります。
2つ目は、「社内ツールそのものを、段階的に作り直していきながら、社内の利用者にも新しい仕組みを使ってもらう」という進め方です。この方法は、開発の手間を抑えられる一方、作り直しの途中で、社内の業務に一時的な混乱が生じるリスクがあります。
どちらの進め方が向いているかは、社内ツールの利用頻度や、社内の業務にどれだけ余裕があるかによって変わります。開発会社に相談する際は、「社内の業務を止めずに進めたい」という制約があるのであれば、その点も、早い段階で伝えておくことをおすすめします。
SaaS化にあたって、開発会社に伝えるべき情報
SaaS化の相談を開発会社にする際、次のような情報を、あらかじめ整理して伝えられると、見積もりの精度や、その後の開発の進みやすさが大きく変わります。
- 今の社内ツールの画面一覧と、それぞれの役割：どの画面が、どんな業務のために使われているか
- 今の利用者数と、想定している顧客数：SaaS化後、どの規模まで顧客が増えることを想定しているか
- 業務ロジックのうち、業界内で共通する部分と、自社独自の部分：前述した専門知識の切り分け
- 予算とスケジュールの制約：段階的に進める場合、まずどこまでを、いつまでに実現したいか
- 社内での利用を止められるか、止められないか：並行稼働が必要かどうか
これらの情報が整理された状態で相談できると、開発会社側も、どこまでを最初のフェーズで作るべきかを、具体的に提案しやすくなります。逆に、「今のツールを見てもらえれば分かる」という状態のまま相談してしまうと、開発会社側が独自に仮定を置いて見積もることになり、後から「想定していた範囲と違った」という食い違いが生じやすくなります。
社内ツールのまま使っていた期間が、SaaS化の際に役立つこと
社内ツールとして、実際に一定期間運用してきた経験は、SaaS化を検討する際に、大きな資産になります。どの機能が実際によく使われ、どの機能がほとんど使われていないか、どの場面でエラーや使いにくさを感じたか、といった実運用の知見は、ゼロから顧客向けのSaaSを企画するよりも、はるかに現実的で、精度の高い設計判断につながります。
この知見を、SaaS化の要件として、開発会社にきちんと伝えることで、実際に価値のある機能に、開発のリソースを集中させることができます。社内での試行錯誤の期間は、一見遠回りに思えても、SaaS化の質を高めるための、貴重な準備期間だったと捉えることができます。
よくある疑問
Q. 社内ツールをそのまま複数店舗・複数顧客で共有して使ってもらうのは危険ですか。
A. 危険です。データの分離が行われていない状態で、複数の顧客に同じシステムを共有させると、ある顧客の操作や表示に、別の顧客のデータが混ざって表示されてしまう可能性があります。少人数の身内同士で試験的に使う場合であっても、最低限のデータ分離の仕組みを入れてから提供することをおすすめします。
Q. 作り直しにはどれくらいの期間がかかりますか。
A. 社内ツールの規模や、業務ロジックの複雑さによって大きく変わるため、一概には言えません。ただし、目安として、データ分離と権限管理だけの最低限のSaaS化であっても、社内ツールをゼロから作ったときと同程度、あるいはそれ以上の期間がかかることは珍しくありません。「少し直すだけ」という前提で予算やスケジュールを組んでしまうと、実際の作業量とのギャップに後から気づくことになりやすいため、開発会社に相談する際は、余裕を持ったスケジュールを想定しておくことをおすすめします。
Q. 今の社内ツールを一切作り直さず、SaaS化することは可能ですか。
A. 顧客が1社、あるいは身内だけの試験的な提供にとどまる間は、大きな作り直しをせずに提供できる場合もあります。しかし、複数の異なる顧客に本格的に展開していく段階になると、データの分離や権限管理は、避けて通れない作り直しになります。「今は1社だけだから大丈夫」という状態であっても、将来的に複数顧客への展開を見据えているのであれば、早い段階でデータ分離の設計だけは済ませておくと、後からの手戻りを減らすことができます。
SaaS化を検討する際の、心構え
社内ツールをSaaS化するというのは、単に「システムを直す」という作業ではなく、「これまで自分たちだけのために作っていたものを、外部の人にも安心して使ってもらえる状態に育てる」という、大きな転換です。この転換には、想定以上の時間と費用がかかることが一般的であり、「今のツールを少し直せばすぐにできる」という期待は、多くの場合、実際の作業量とはかけ離れています。
この転換の規模を、正しく認識した上で、段階的に、無理のないペースで進めていくことが、結果的に、事業としての成功につながりやすい進め方だと言えます。
この記事の次に読みたい記事
社内ツールをSaaS化する際の作り直すべき部分の見極め方を理解したら、次は自分の店のツールを他店に展開できるかを判断する視点についても、あわせて確認しておきましょう。
