システム投資のパターン～SI案件以外のビジネスモデルは何があるのか

システム投資のパターンをまとめてみた。
自分が業務システムを購入する立場ならば、高価で使いにくいし、中身がブラックボックスなので、購入には躊躇するだろうと思う。
ラフなメモ書き。

システム投資のパターン from akipii Oga

【0】業務システムの投資には、3つのパターンがあるように思う。
「ユーザ企業の資産」「ユーザ企業のリース資産」「ユーザ企業の利用料支払い」の3パターンについて、以下に考えを書いてみる。

【1】ユーザ企業の資産：普通のSI開発

【1－1】発注元はSIにシステム開発を委託し、SIが受託開発していくパターン。
通常の受託開発案件であり、一番事例が多いだろう。
納品されたシステムは、運用後に数年かけて減価償却される。

発注元(ユーザ)：資産、受託先(SI)：売上として計上される。

SIから見れば、受託開発のプロジェクトさえ黒字で完了できれば、運用保守費用で毎月売上が計上されるので、安定的な収入源になる。
だから、SIの受託開発案件は、ソフトウェア開発の界隈では主流のビジネスなのだろう。

【1－2】しかし、この投資パターンは、発注元が最終的に大きなリスクを背負う。
開発を委託したシステムが実は性能が悪くて使い物にならなかったり、一番重要な仕入先や会計システムとのシステム連携ができていなかったり、想定していた要件とは違うシステムで納品されたり、など、たくさんの失敗事例がある。
発注元のプロジェクトマネージャが、システム投資の目的を常に忘れないように、その目的からシステムの機能の優先度を決めていかなければ、すぐに機能は肥大化する。
そして、システム開発で一番重要な要素であるリリース時期に間に合わなくなる。

だから、発注元も最近は経験してきて、このパターンで本当に投資対効果(ROI)があるのかどうか、計画段階から厳しく精査するようになってきたように思う。

業務システムを運用した場合、利用者は何人か、システム運用によって一人当たり何分だけ省力化されるか、どれだけ人員を減らせるか、という観点で、投資したコストをどれくらいの期間で回収できるか、計算する。
あるいは、会計帳票をペーパーレス化することで、紙として保持する倉庫代金が減らせる、などで計算するときもあるだろう。

そこで、実際に計算してみると、業務システムの投資対効果には5～10年かかるのが普通だ。
普通は数千万～数億円(あるいはもっと上)の開発案件なので、3年くらいで元が取れるわけではない。
すると、モバイル・クラウド・ビッグデータのバズワードのように次から次へと技術革新される現状では、10年前のシステムはその価値がすぐに陳腐化してしまう。
3年前に作ったシステムはもはやガラクタと同じレベルになってしまうのだ。
だから、発注元も、システムを資産として保持するリスクをよく考えてきている。

【1－3】SIの観点でも、受託開発案件の旨みが最近は少ないように思う。
受託開発案件の成功率が低すぎるのだ。
たぶん、半分以上は赤字でカットオーバーしているのではないだろうか。

その原因は色々あるだろう。
発注元の仕様スコープを制御できず、スコープクリープしてしまい、開発工数が当初の見積りよりも大幅超過してしまった。
最新のフレムワーク、モバイル・クラウド・ビッグデータなどの最新技術を使いこなせず、当初の想定通りに開発できなかった。
当初想定していなかった非機能要件、システム連携でリスクが発生し、工数がオーバーした。

普通に考えれば、前回の開発案件で使用したライブラリやフレームワークを流用するなどの対策を取れば、SI案件は成功しやすいはずだ。
以前の顧客に提供した業務パッケージ製品があれば、新規顧客にはそれを多少カスタマイズするだけで同じくらいの値段で売上が取れるはず。
フレームワークや部品の再利用ができれば、元々、運用品質が担保されているだけでなく、ソースの保守もやりやすいはずだ。

しかし、現状はそうもいかない。
SIが作ったパッケージ製品の著作権はSIにあっても、発注元企業へ納品した時に、カスタマイズした機能の著作権がSIの手から離れると、その部品を流用できなくなる。
あるいは、フィットギャップ分析してみると、パッケージ製品をカスタマイズすると一から新規のシステムを作っているのと同じくらいのコストがかかることが判明する時もあるだろう。

だから、SIは、受託開発する時にどのような手段を使って開発するか、アーキテクチャ設計が以前にも増して重要になっているように思う。

【1－4】SIの受託開発案件の旨みが最近ないのは、カットオーバー後の運用保守費が以前よりも元が取れなくなっている場合があるからだと思う。

発注元企業がうまく難癖をつけて、SIへの運用保守費に、システムの減価償却費用を上乗せして来る場合があるからだ。
発注元が要件を出したのに、SIが納品してきた業務システムは使い物にならず、作り直しの期間は運用保守費を削減されたり、運用保守費用に使いものにならない機能の費用(つまりその機能の価値)を上乗せして削減されたりするのだ。

SIが無事に納品できれば問題ないが、受託開発案件の成功率が低いため、元々赤字なのに、ユーザ企業から難癖をつけられて更に赤字になってしまうパターンがあるのだ。

【2】ユーザ企業のリース資産：SIから貸し出された最新版のパッケージ製品

【2－1】発注元：リース負債、受託先：リース資産のパターン。
SIから貸し出された最新版のパッケージ製品の例が多いだろう。
あるいは、開発用PCやサーバーのように、3年で陳腐化する場合、リース資産として契約し、契約終了後はまた新しいハードウェア機器を納入する例もあるだろう。

このパターンの利点は、発注元は常に最新版の製品を資産として使用できることだ。
つまり、システムやハードウェアの更新サイクルが短い場合、リース資産として購入した方が元が取れやすい。

【2－2】SIの観点でも、リース資産はとてもありがたい。
SIが開発した製品なので、その製品はSI企業で資産として計上されるから、減価償却が発生する。
その分、多額の費用が数年かけて発生するわけだ。

ただし、発注元にリース資産として貸し出しているので、発注元からリース料として、売上代金を毎年支払ってもらえる。
投資リスクは発注元企業が背負っているわけだ。

【2－3】しかし、業務システムにリース資産のパターンが使えるかどうかは分からない。
業務システムの運用期間が10年以上の長いスパンならば、リース資産にした場合、発注元は減価償却が発生するだけでなく、その費用をSIに支払わなければならない。
発注元の資産としての減価償却なら、費用が発生しても、その費用を他者に支払う必要はないのに。

おそらく、リース資産のパターンは、少額であり、短期間で元を取りたい場合に適用される場合が多いだろうと思う。

【2－4】AWSに業務システムを乗せるようなクラウドの場合、リース資産として扱う事例も増えるのではないか、と想像している。

クラウド上に業務システムを乗せられるならば、システムの移植性が高いため、ハードウェアの性能向上がやりやすいし、別のサーバーに載せ替えることも可能だ。
しかも、システムの移植性が高いということは業務システムの複製がやりやすいということなので、古い業務システムから新しいシステムへの入れ替えもかなり簡単になるはずだ。

例えば、「ブルーグリーン・デプロイメント」を使って、古いシステムの背後で新しいシステムへの移行作業を実施しておき、移行作業が完了すればすぐに新しいシステムへ切り替えればいいだろう。
つまり、クラウドの手法を上手く使えば、業務システムのバージョンアップを増やして、システムの寿命を長持ちさせることもできる。

今後の研究テーマになるだろう。

【3】ユーザ企業の利用料支払い：SaaS

【3－1】発注元はシステムを持たず、SIからシステムを必要な時に借りるパターン。
発注元：費用、受託先：資産のパターン。

発注元は利用した分だけ支払えば良い。「資産」として抱える必要がないので身軽。
経費扱いなので少額なら決裁権限が不要。

最近は、SaaSの事例が多い。
特に、中小企業のように、自前の業務システムを多額の費用をかけて導入することができない環境では、SaaSのように資産として保持しない方がありがたい。
また、SaaSの利点は、システムのバージョンアップが多いので、最新の機能を早く使えることもある。
自分でカスタマイズしなくても、製品元が機能改善してくれれば、その恩恵を受けられる。

【3-2】SIの観点では、SaaSの製品はSIの「資産」なので減価償却になる。
利用者が増えれば売上増だが、利用者が少なければ投資対効果が得られず赤字になるリスクが大きい。
つまり、投資リスクは受託先企業が背負っている。

一番のポイントは、SaaS利用料の決め方。
SaaS利用料が高ければ、利用者は増えない。
かと言って、SaaS利用料が低くても、投資コストが回収できない料金体系は意味がないし、低い利用料金に見合ったユーザしか集まらない。

SaaSの料金体系の決め方は難しい。
当初の計画通りに利用者が増えなければ、赤字が累積するだけだ。

おそらく、AIDMA、AISAS、AARRRのようなマーケティング手法をもとに、ABテストを実施しながら試行錯誤するしかないと思う。

AIDMA - Wikipedia

「AARRR」　今更だけど絶対抑えておくべきグロースハッカーのコンバージョンの見方 | グロースハックジャパン | growth hack japan

【3-3】今後は、SaaS形式の業務システムが増えてくると思う。
従来の業務システムは、SI案件が多く、多額の投資が必要だった。
そのために、そのマーケットは大企業に限られていた。

しかし、SaaSという技術がクラウドによって可能になり、中小企業にも業務システムを使えるという恩恵が受けられるようになり、マーケットが広がった。
中小企業の利用者も利用料も少ないかもしれないが、潜在的なマーケットであるし、未開拓なマーケットだ。
しかも、スタートアップの企業もSaaS技術さえ操ることができるなら参入しやすい。

【4】まとめ

普通のSIに勤めていると、受託開発案件のビジネスモデルしか知らない。
でも、最近はクラウドという新しい技術のおかげで、リース資産やSaaSのようなビジネスモデルも作り出せる。
この新しいビジネスモデルは、特にベンチャーのスタートアップ企業が特に盛んに試されているように思える。

ソフトウェア開発のビジネスモデルは、いったいどれくらいのパターンがあるのか。
僕は今この3種類しか知らないけれど、まだ他にもあるだろう。
色々調べてみたい。