システム開発モデルと原価シミュレーションからわかる業務SaaSの難しさと素晴らしさについて-(2)
はじめに
こちら の記事の続きです。 業務システムは大まかに分けて以下のような開発モデルがあることを記載しました。
| 種類 | 要求の実現方法 | 提供方法 | 代表的な製品 |
|---|---|---|---|
| フルスクラッチ開発オンプレミス | フルスクラッチ開発 | オンプレミス | グループ内のシステム会社が作る社内向けシステム |
| パッケージ＋カスタマイズ開発オンプレミス | カスタマイザビリティパッケージ開発 + カスタマイズ開発 | オンプレミス | SAP社製ERP、国内F社ERP |
| パッケージ＋カスタマイズ開発シングルテナントSaaS | カスタマイザビリティパッケージ開発 + カスタマイズ開発 | シングルテナントSaaS | 国内F社ERP、国内T社ERP |
| コンフィギュラビリティパッケージ開発オンプレミス | コンフィギュラビリティパッケージ開発 + 設定 | オンプレミス | ワークスアプリケーションズERP |
| マルチテナントSaaS | コンフィギュラビリティパッケージ開発 + 設定 | マルチテナントSaaS | Workday、Salesforce、Kintone、RFQクラウド |
それぞれの特徴は要求の対応しやすさ、使い始めまでから解約までの手軽さ等々ありますが、 もっともわかりやすい原価のシミュレーションで比較をしてみます。
シミュレーション
ここで、それぞれのモデルに応じたシミュレーションを行います。 前提は以下となります。
- あくまでも参考なので、必ずしも現実と一致しているわけではない
- 大企業向けERPを運用する(統一できる指標がそこしかないため)
- 要求の大きさは固定、それをそれぞれの方法で対応した際のシミュレーション(ある程度大規模システムを想定)
- それぞれの要求を実現する際に発生するコストは変動(対応方法によっては難易度が代わり、かかるコストも変動するため)
- 10年運用することを仮定
- 定期的に追加開発が発生している
- 計算式で用いるベースはこちら(それぞれの詳細の原価は後ほど解説します。)
シミュレーションで用いる各種マスタ
導入企業が1社の場合
当然ですが、フルスクラッチ開発オンプレミスが最も安くなります。 これは、他に共通的に利用することを前提としていないためです。 逆にもっとも共通化を考えているマルチテナントSaaSが最も原価が高くなります。
導入企業が10社の場合
マルチテナントSaaSとコンフィギュラビリティパッケージ開発オンプレミスとそれ以外の開発モデルとで原価が逆転現象を起きました。 これは 初期開発費・保守費用・追加開発費用が企業間で按分できるか という点が結果に大きく影響しているからです。
※ マルチテナントSaaSの方が高くでますが、実際は10社程度ではこのような高級インフラを用意しないのでマルチテナントSaaSの方が安くはなります。
導入企業が100社の場合
マルチテナントSaaSとコンフィギュラビリティパッケージ開発オンプレミスとで差が出始めてきました。 これは サーバー費用を企業間で按分できるか という点が結果に大きく影響しているからです。
導入企業が1000社の場合
この辺だとマルチテナントSaaSとパッケージ＋カスタマイズ開発と比べて原価が100倍くらいの差が出ています。 この100倍がどこに影響でるかというと、その分の 人員の確保が必要・システム料金に反映 となっていきます。
原価計算式
実際にシミュレーションを行い、マルチテナントSaaSが圧倒的に原価が低いモデルであることを確認しました。 なぜそのようなことが起きるかという原価の計算式をそれぞれのシステム開発モデルで示します。
- それぞれの項目の意味は以下のようになります。
- 1.1人月費用：1人1ヶ月分の作業が発生する場合にかかる金額 ≒ 人件費 参考
- 2.初期導入時の要件を満たすにかかる人月(導入企業固有の機能以外)： 他の企業でも使えるように機能開発した部分における初期要件を満たす際にかかる人月
- 3.初期導入時の要件を満たすにかかる人月(導入企業固有の機能)： 他の企業では使えるない機能開発した部分における初期要件を満たす際にかかる人月
- 4.初期導入時の要件を満たすにかかる人月(導入企業固有の機能以外)： 他の企業でも使えるように機能開発した部分における初期要件を満たす際にかかる人月
- 5.初期導入時にかかる人月：3+4
- 6.企業固有ではない初期開発費：1 × 3
- 7.1社増えるにあたり必要な初期開発費用：1 × 4
- 8.初期サーバー費用 (オンプレシステムの費用は こちらの大規模会社向け を参考にしました)
- 9.1社増えるにあたり必要な初期費用：7+ 8
- 10.インフラ保守費用(ベース) ：他の企業と共通したインフラを構築した場合の年間インフラ費用
- 11.1社ふえるにあたり必要なインフラ保守費用 ：他の企業と共通していない、または負荷軽減のためのインフラを構築・増築した場合の年間インフラ費用(オンプレはこちらを参考にしました(本番機・テスト機を用意した場合) , SaaSはAWSで構築するとしてシングルテナントの構成はこちら、 マルチテナントの構成はこちらを参考にしました)
- 12.保守に必要な人数(人月/年間)：保守を行う年間で必要な人月(今回は毎月2人が保守体制をとるとしました。)
- 13.ベースとなる保守費用(年間)：他の企業と一律で行える保守をした際の保守費用
- 14.1社増えるにあたり必要となる保守費用(年間)：他の企業と一律で行えない保守(企業独自) をした際の保守費用
- 15.追加機能開発人月(係数)：追加要求を対応するための開発における必要工数の係数。（フルスクラッチの追加開発を係数1とし、それと同じ要求を実現するために必要となる工数との係数）
- 16.追加開発費用(ベース)：他の企業と一律で行える追加開発 を行なった際の開発費用
- 17.1社増えるにあたり必要な追加開発費用：他の企業と一律で行えない独自の追加開発 を行なった際の開発費用
※保守費用はバグ修正・問い合わせ対応などをここでは指します。
フルスクラッチ開発オンプレミス
初期サーバー費用に関しては こちらの大規模会社向け を参考にしました サーバー維持費用はこちらを参考にしました(本番機・テスト機を用意した場合)
他と比べた特徴として、以下となります。
- 実現するのが比較的容易なので、超優秀人材でなくて良いので人件費は少なめ
- その企業に合わせた開発なので、1社のみであれば開発人月がもっとも低い
- 他の企業で使える前提ではないため、1社ごとに比例して開発原価が増える
パッケージ＋カスタマイズ開発オンプレミス
他と比べた特徴として、以下となります。
- 初期開発費はベース開発と独自開発(カスタマイズ)のどちらもある
- 保守費用は 1社増えるにあたり必要な保守費用(年間) に割合が増える。理由は（かなり多くの）カスタマイズをした場合に独自の保守契約が必要となるため、他の企業と一律で行える保守ができなくなる
- 追加開発費用も同様
パッケージ＋カスタマイズ開発シングルテナントSaaS
他と比べた特徴として、以下となります。
- 基本的には「パッケージ＋カスタマイズ開発オンプレミス」と同様
- 初期サーバー費用が0になり、インフラ保守費用に割り当てられる。
- シングルテナントSaaSなので、インフラ保守費用は企業ごとに按分することができない 。
コンフィギュラビリティパッケージ開発オンプレミス
他と比べた特徴として、以下となります。
- 初期の開発・保守・追加機能開発は全て企業独自にするものではないので、企業数がふえるごとに費用が発生しない。こちらを参考にしました
- インフラは企業ごとなので、その分費用が発生する。
マルチテナントSaaS
他と比べた特徴として、以下となります。
- 「コンフィギュラビリティパッケージ開発オンプレミス」に比べて、インフラ費用を共有 することができる。こちら を参考
- サーバーの負荷軽減対応や通信量・容量の増加などに伴い、企業ごとに必要な保守費用も若干かかる。(EC2のデータ転送量・RDSのストレージ・I/O・S3容量増加がありますが、大した金額差にはならないためこの程度の金額にしています。)
- 技術的・要件決めの難易度がかなり高度になるので、機能開発における工数およびそれを実現できる 優秀な人材の人件費 も高くなる。
シミュレーションにおける原価のまとめ
導入社数に応じた原価のシミュレーションを行いました。当然按分して費用を顧客から徴収します。 そのため、マルチテナントSaaSは多くの企業を導入することが前提であれば、他モデルと比べてかなり安価に提供することが可能となります。
実際にはすべての企業が同様にカスタマイズを行うわけでもないし、開発・リリースのプロセスも違うので単純にこのように同じ指標で測るのは難しいと思います。
まとめ
マルチテナントSaaSの最大の強みは 安価 であること。 それにより以下の副次的なメリットが発生する。
- 企業が試運用しやすい
- 追加機能開発費用を支払わなくても、追加機能が利用できる可能性がある
- セキュリティ担保・可用性向上のために大量の投資ができ、結果的に他モデルと比べてこれらのレベルが高くなる
ただし、その制約として あらゆる要求を網羅的に対応する必要がある シミュレーションの例だと1000社の要求に耐えれる機能開発が必要 そのため以下のようなことが発生する。
- 初期の開発スピードは遅い
- 優秀な人材の確保が必要
最後に
マルチテナントSaaSの良さと難しさについて記載しました。 今回のシミュレーションはこちら で行いました。マルチテナントSaaSの営業の際に少しでも参考になれば幸いです。
しかし、マルチテナントSaaSは実現が難しく、すぐに実現できるものではありません。 弊社ではRFQクラウドというマルチテナントSaaSの開発・保守を行なっています。 世界的に有名なマルチテナントSaaSであるSalesforce、Workday、Tradeshiftもですし、Kintone・SmartHRなどの国内SaaSも含めてあらゆる知見を生かしたマルチテナントSaaSシステムの開発を行なっています。
将来的にマルチテナントSaaSを実現したい、または、そんな難しいシステム一緒に開発し成長していきたい人材を募集しています。 少しでも気になった方はまずはお話でもできたら幸いです。 https://www.wantedly.com/projects/260140
システム開発モデルと原価シミュレーションからわかる業務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
