「納品をなくせばうまくいく」の感想part3～「納品のない受託開発」のビジネスモデルの不明点とあるべき姿

「納品のない受託開発」のビジネスモデルの不明点とあ今後の方向性について考えたことをメモ。
倉貫さんに直接質問しないと、理解できた気にならないと思っている。
間違っていたら後で直す。

【元ネタ】
書評：システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか？ | Social Change!

「納品をなくせばうまくいく」の感想part2～「納品のない受託開発」のビジネスモデル分析: プログラマの思索

「納品をなくせばうまくいく」の感想part1～ソフトウェア業界のビジネスモデルが抱える問題: プログラマの思索

【公開】第30回IT勉強宴会「最近感じる日本企業のITの問題と展望～「ソフトを他人に作らせる日本、自分で作る米国」を読んで」: プログラマの思索

【1】「初期費用なしで開発したソフトウェア」は誰の資産なのか？

「「納品」をなくせばうまくいく」を読んでみて、このビジネスモデルはSaaSであり、開発したソフトウェア(システム)はSI側の資産であり、顧客は利用費を支払うものだと思っていたが、違うらしい。

(引用開始)
違うというのは、お客さまはすべて経費にする訳ではないんです。「納品のない受託開発」というキャッチフレーズではありますが、実質は、私たちの持ち物ではなく、お客さまの持ち物なので、お客さまに資産計上はして頂きます。新規開発にかかった分が計上対象になります。納品というのはその区切りに過ぎないので、納品という様式がないからといって計上しないわけではないのです。
(引用修了)

【1-1】「ソフトウェアは誰の資産なのか？」が根本的な問題だ。

従来のSIモデルでは、開発したソフトウェアはユーザ企業の資産だ。

普通、受託側のSIは、発注側のユーザ企業にシステム提案して、システムを導入すると業務がこのように抜本的に改革できますよ、とアピールする。
すると、発注側の立場では、では、そのシステムの回収計画とROIを示してくれ、とSI側に要求する。

発注側としては、システムの初期構築費とランニング費用が知りたい。
その理由は、単に安く開発を済ませたいからだけではない。
導入したシステムで本当に元が取れるのか、ROIと損益分岐点が知りたいのだ。

普通は、システムの初期構築費は数千万円、数億円のような巨大な金額になる。
はい、契約します、とすぐに発注側企業も契約できるわけではない。
情報システム部門が、色んな利用部門にヒヤリングして根回しし、経営者に向けて、システムのメリットをきちんと説明できて初めて契約できる。
多額の初期費用を支払ったのに、「誰も使わない、使い勝手の悪いシステム」になるのは困る。

初期構築費用は、SIの開発工数だけではない。
サーバー代金もあるし、Oracleなどミドルウェアのソフトウェアライセンス、パッケージ製品のソフトウェアライセンス費用、開発者のライセンス費用、ユーザ企業への教育・研修費用も含まれる。
それなりに費用はかかるものだ。

また、苦労して開発したシステムが無事に稼働しても、実際の利用人数が少なく、ランニング費用が高ければ、「使うだけ損」という気持ちにもなりやすい。
発注側企業にすれば、毎月の保守費用に数十万円、数百万円も支払うのに、SIベンダーはちゃんとその価値を提供してくれているのか、と疑いがちだ。

普通の会社では20万円以上の費用の支払は、部課長の決裁はできず、会社の稟議で承認を得ないといけないから、高額になるほど、社内の根回しが大変になる。
実際、本番障害がほとんどなく安定稼働しているなら、ランニング費用はせいぜいサーバーの電気代や通信費くらいでそんなに高くないでしょ、と思っているからだ。

だから、発注側企業はSIに対し、システムの初期構築費用と毎月のランニング費用はどれくらいになるのか、その回収計画を提示してくれ、そしてROIがどのように変化するのか回収計画に盛り込んでくれ、とよく言う。

一方、SIにとって、回収計画は非常に重要な提案だ。
オンプレミスの業務システムならば、業務システムは顧客の資産になる。
すると、初期構築費用は顧客側の資産に計上され、3～5年かけて減価償却される計算になる。
そして、本番稼動後1年間は無償の瑕疵担保責任をSIが持ち、1年後からランニング費用が発生するのが普通。

すると、発注側企業は、最初の1年間に初期構築費用という高額な大金を支払い、1年後から毎月、それなりの金額のランニング費用を支払い続けることになる。
業務システムを使い続ける限り、ランニング費用の支払いを止める訳にはいかないから、最終的には発注企業はSIの言いなりになって支払い続けるしか無い。

すると、業務システムを開発して運用し続けた場合、業務システムのライフサイクルを考えると、業務システムが生存している間にユーザ企業が支払い続けるコストは、「初期構築費用＋ランニング費用 * (稼働期間 -1年)」となり、かなりの金額になる。
たとえ小規模な業務システムであったとしても、5年も使うならば、おそらく数億円以上はかかっているのではないだろうか。

逆に言えば、SIとしては、一度導入したシステムがユーザ企業で使い続けられるなら、毎月定額のランニング費用が入ってくるので、安定した収入源になる。
ユーザ企業がいくら現状の業務システムに不満があったとしても、その業務システム無しでは業務が止まってしまうならば、SIも、その仕様変更はすごく工数がかかります、と突っぱねることもできる。
「システムの安定稼働が最優先です」を大義名分にすれば、SIは無理して、開発する必要もないのだ。

だから、業務システムのライフサイクルの観点から見た回収計画は、発注側企業と受託側SIの駆け引きになりやすい。

【1-2】従来のSIモデルにはそんな背景があるから、「納品のない受託開発」のビジネスモデルは画期的と思っていたけれど、SaaSモデルと同じという僕の理解は間違っているみたい。

「初期費用なしで構築したソフトウェアは顧客の資産であり、毎月のランニング費用(月額定額料)を支払う」というモデルはそもそも実現し得るのか？
構築したソフトウェアに関する費用は誰が持つのか？
初期構築費用は資産ではないのか？

そもそも、最初に何か新しいモノを生み出すには、初期投資という費用が発生する。
その費用はどこから湧いてくるのか？

単純に考えると、「納品のない受託開発」のビジネスモデルは、ユーザ企業の資産(ソフトウェア)の減価償却を毎月のランニング費用という月額定額料に混ぜ込んでいるのではないか？

つまり、普通は3～5年かけて分割払いにする減価償却費を、もっと長いスパンの薄い費用にしてしまい、月額のランニング費用に上乗せしているのではないか？

すると、実は、月額定額料の金額はかなりの高額になるのではないだろうか？
なぜなら、普通のランニング費用の上に、少しとは言え薄く積み上がった減価償却費を積んでいるからだ。

この辺りのビジネスモデルは直接聞いてみたい所だ。

【2】「納品のない受託開発」のビジネスモデルのあるべき姿は、「優秀なエンジニア」と「CTOやCIOを求める企業」のプラットフォームではないか

「納品のない受託開発」のビジネスモデルで最も興味が惹かれる部分は、月額定額料のビジネスモデルよりも、優秀なエンジニアのリソース・プールである「ギルド」というプラットフォームだ。

「納品のない受託開発」のビジネスモデル分析 from akipii Oga

日本のIT業界が抱える問題は、受託SIの多重下請構造のために、優秀で意欲ある技術者がインセンティブを持ちにくい点に尽きると思う。
その理由は、「納品をなくせばうまくいく」の感想part1～ソフトウェア業界のビジネスモデルが抱える問題: プログラマの思索に書いた。

そんな問題を抱えたままなので、日本のユーザ企業が自社内で優秀なエンジニアを抱えて、自社開発を進めることも実際は難しい。

その背景は、【公開】第30回IT勉強宴会「最近感じる日本企業のITの問題と展望～「ソフトを他人に作らせる日本、自分で作る米国」を読んで」: プログラマの思索にも書いた。
「日本のユーザ企業がシステム開発を内製化するにはどうすればよいのか？」とユーザ企業自身も考えているけれど、実際の開発現場では、なぜか、ユーザ企業の若手はプログラミングしなくなるのだ。

おそらく、日本のユーザ企業では、プログラマよりもプロジェクトマネージャのような管理職になるのがスキルアップのモデルとして普及されているから、自分の給料や社会的地位を上げるには、プログラマで居続けるインセンティブがないのだ。

一方、「納品のない受託開発」のビジネスモデルでは、優秀なエンジニアは「ギルド」という集団で技術を切磋琢磨する空間が保証されている。
そして、ソニックガーデンが技術レベルを認めれば、「ギルド」にいる技術者が、ユーザ企業のCTOないしCIOとして、ユーザ企業のビジネスをITインフラ面から支援する仕事を請け負う。

つまり、「ギルド」は「CTOやCIOを求める企業」のためのIT技術者を提供するプラットフォームでもある。
このプラットフォームにいる優秀なエンジニアが多いほど、CTOやCIOになれるエンジニアをユーザ企業に提供でき、毎月の売上も定額料のおかげで安定した収入として増やすこともできる。

だから、このビジネスモデルの本質は、「ギルド」というプラットフォームをいかに育成するか、という点にあるように思う。

僕が単純に考える「ギルド」のイメージは、最近活発に開催されているITコミュニティの一部と同一視できるのでは、と思う。
活発なITコミュニティには、意識の高いIT技術者がたくさん集まり、能力を切磋琢磨している。
また、若い技術者も定期的に流入しているから、幅広い年齢層のITコミュニティも多い。
そんなITコミュニティをギルド化すれば、「納品のない受託開発」のビジネスモデルの基盤にもできるだろう。

この辺りは完全に僕の考えにすぎないので、実際に聞いてみたいと思う。