システム開発モデルと原価シミュレーションからわかる業務SaaSの難しさと素晴らしさについて-(1)
概要
業務SaaSシステム実現(開発)の難しさと、実現できた際のビジネス的な素晴らしさをシステム構成の考えから伝えます。 ※ここでは、マルチテナントSaaSの素晴らしさと難しさをメインに記載します。
対象者
- 業務SaaSを提供しようとしている・している経営者・BizDev
- 業務SaaSを開発しようとしているエンジニア・プロダクトマネージャー
- VCとか本とかであるSaaS推しの記事を見て、将来的に起業したいと思っている人たち
結論
話す内容
- 業務システムの様々なビジネスモデルについて
- それぞれのモデルでの原価のシミュレーション
- なぜ、マルチテナントSaaSの実現が難しく、素晴らしいのか
話さない内容
- マルチテナントSaaSの詳細な実現方法
業務システムの様々なシステム開発モデルについて
シミュレーションの前にシステム開発モデルについて説明します。 システムを構成するに当たり、大きく2つの観点を基に構成されます。
- 要件の対応方法
- 提供方法
要求の対応方法
当たり前ですが業務システムなのは業務で使われるシステムです。 企業ごとに当然業務が異なります。そのためそれぞれに応じた要求が発生します。 例えば以下のような業務差異があります。
- 例1）A社とB社では給与形態が異なる。A社は役職に応じて固定、B社は営業実績に応じてインセンティブが付与される
- 例2）C社とD社では購買形態が異なる。C社は各工場に購買部があるが、D社は購買部が本社にしかないため購入依頼を本社へ依頼する必要がある。
これらを対応するには、システムを正として、業務を変更するという考えもありますが現実的に 全て の顧客をシステムに合わせること不可能なのでその差異の要求を対応する方法を記載します。
- フルスクラッチ開発
- カスタマイザビリティパッケージ開発 + カスタマイズ開発
- コンフィギュラビリティパッケージ開発 + 設定
それぞれについて解説をします。
フルスクラッチ開発
企業ごとに 全ての開発を1から 行う方法です。 何の縛りもないので、何でもできます。(システムでできる範囲で)
- 特徴
- どんな要求も実現できる
- 開発原価は1社増えるごとに比例して増えていく
カスタマイザビリティパッケージ開発 + カスタマイズ開発
どこの会社でも使われる基本的な機能をパッケージ化する、標準機能で対応していない要求を カスタマイズ開発 で対応する。
そのため、カスタマイズができるパッケージの開発およびカスタマイズ開発が必要となる。
( カスタマイザビリティ = カスタマイズ開発をすることができる)
- 特徴
- 標準機能の開発原価は企業ごとに分割できる
- カスタマイズをすればある程度は要求を広く対応できる
- カスタマイズ開発費は1企業ごとに発生する
コンフィギュラビリティパッケージ開発 + 設定
どこの会社でも使われる基本的な機能をパッケージ化する、企業ごとの要求の違いは、全て設定だけで実現できるようにする ( コンフィギュラビリティ = 設定で対応できる) そのため、全てを設定で実現するために、あらゆる要求を網羅する開発が必要
- 特徴
- 全ての開発原価を企業ごとに分割できる
- 対応できる要求は設定できる範囲のみ
- 設定のみであらゆる要求を実現しなければならない
カスタマイザビリティパッケージ開発 + カスタマイズ開発 vs コンフィギュラビリティパッケージ開発 + 設定
上記だけみると、開発が少なく・あらゆる要求を対応しやすい「カスタマイザビリティパッケージ開発 + カスタマイズ開発」の方が良いように思えます。
しかし、これは継続的な利用の目線だと大きく異なってきます。 詳細は「コンフィギュラビリティパッケージ開発 + 設定」のシステムを提供しているWorksApplicationsの機能コンセプト に記載されています。
簡単にまとめると以下のようになります。
- カスタマイズを行なった瞬間に 以後すべての保守開発費用が企業ごとに発生する可能性がある
これは、後の開発原価のシミュレーションの差異に如実に変化が現れます。
提供方法
提供方法は大きく分けると以下の二つに分類されます。
それぞれの具体的な内容については割愛します。 ユーザーが物理サーバーを用意する必要があるかないかの違いだけです。(ユーザーから見たら)
SaaS型の提供方法について
SaaS型にも以下のような形で提供方法が分かれます。
テナント = 企業 インスタンス = サーバー と認識して頂ければ良いです。 １つのサーバーでインスタンスで動くということは必然的にアプリケーションコードも１つとなります。 そのため、自動的に マルチテナントSaaSは「コンフィギュラビリティパッケージ開発 + 設定」で実現しなければならなくなります。
参照：NTTデータ ビズインテグラル、クラウド対応型業務アプリケーションの 開発・実行基盤、「Biz∫APF」を提供開始 参照：Web アプリケーションをマルチテナント型 SaaS ソリューションに変換する
なので、ここでは以下の提供方法について議論します。
現状のシステム開発モデル
これまで、「要求に対する実現方法」とその「提供方法」について記載してきました。 それぞれの組み合わせにより以下のようなシステム構成が一般的です。
| 種類 | 要求の実現方法 | 提供方法 | 代表的な製品 |
|---|---|---|---|
| フルスクラッチ開発オンプレミス | フルスクラッチ開発 | オンプレミス | グループ内のシステム会社が作る社内向けシステム |
| パッケージ＋カスタマイズ開発オンプレミス | カスタマイザビリティパッケージ開発 + カスタマイズ開発 | オンプレミス | SAP社製ERP、国内F社ERP |
| パッケージ＋カスタマイズ開発シングルテナントSaaS | カスタマイザビリティパッケージ開発 + カスタマイズ開発 | シングルテナントSaaS | 国内F社ERP、国内T社ERP |
| コンフィギュラビリティパッケージ開発オンプレミス | コンフィギュラビリティパッケージ開発 + 設定 | オンプレミス | ワークスアプリケーションズERP |
| マルチテナントSaaS | コンフィギュラビリティパッケージ開発 + 設定 | マルチテナントSaaS | Workday、Salesforce、Kintone、RFQクラウド |
まとめ
それでは実際にそれぞれのビジネスモデルの原価シミュレーションを記載していきたいところですが、 長くなったので2回に分けて投稿します。 引き続き次回もよろしくお願いします。 https://nariyukimatsumoto.hatenablog.com/entry/2018/12/15/231037
