「納品をなくせばうまくいく」の感想part2～「納品のない受託開発」のビジネスモデル分析

「「納品」をなくせばうまくいく 」を一通り読んだ。
自分の理解のために、「納品のない受託開発」のビジネスモデルを分析してみたので、ラフなメモ書き。
自分の想像で書いているので、今度お会いした時に、実際にレビューしてもらった方がいいかもしれない。
間違っていたら後で直す。

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

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

【1】「納品のない受託開発」の戦略マップ(イメージ)

バランス・スコアカードの戦略マップを真似て、ソニックガーデンの戦略を整理してみた。
すると、4つの大きな戦略があるように読み取れた。

【1-1】財務の視点

基本は「月額定額制」であり、月額のサービス利用料として回収する。
おそらく当月末請求翌月末入金のような流れかな。

この契約は、準委任契約や派遣契約とは同じではない。
常駐しない保守契約のような「オフサイト保守」「リモート保守」ではない。
そうであれば、人月契約と全く同じ。

あくまでも、クラウド基盤上のWebシステムをSaaS形式で提供しているから、人月契約とは同じではない。
でも、普通のSaaSならば、利用料の値付けが難しい。
利用料が安くてもユーザが集まらなければ、売上を確保できない。
かと言って、利用料が高いとユーザが集まらないし、値下げすると、既存ユーザから反発を食らうだろう。

「「納品」をなくせばうまくいく 」を読むと、単なるSaaSではなく、中小企業やベンチャー企業のCTOサービス、CIOサービスとして付加価値を付けている点がミソなのだろう。
つまり、「顧問エンジニア」という呼称は、ユーザ企業のCTOないしCIOの役割として、ユーザ企業の事業システムを開発するから、単なる開発者だけではない。
技術顧問みたいな役割だから、その分、付加価値を付けているわけだ。

【1-2】顧客の視点

基本戦略は「Point of Use(システムは所有せず利用する)」。

従来は、ユーザ企業が業務システムを開発した場合、サーバー代やソフトウェアライセンスの初期費用、システムの初期構築費は、資産として計上され、5年くらいかけて減価償却されていく。
しかし、実際は、初期構築した後、ランニングコストという運用費用が発生し、さらにカスタマイズが発生すれば、追加の費用もかかる。
すなわち、業務システムを無形資産としてユーザ企業が保持するのは、多額の資金を必要とするから、高リスクだ。
しかも、ITの専門家でないユーザ企業にとって、受託SIが開発した保守性の悪い業務システムは、ブラックボックスになりやすい。
SIから、これだけの工数がかかります、と言われても、システムの詳細を知らないし、業務が改善されないのは困るので、SIの言いなりのまま支払うしか無い。

そんな背景があるから、SaaSのように、ユーザ企業がシステムを資産として持たず、使った分だけの利用料を支払う方式が増えている。

但し、全てのシステムをSaaSにできるわけではない。
ミッションクリティカルな基幹系業務システムは、オンプレミスないしプライベートクラウドにならざるを得ないのが現実だろう。

「「納品」をなくせばうまくいく 」を読むと、開発対象システムは、事業システム(≠業務システム)の開発だけに限る。
だから、エンタープライズなシステムは範囲外。
つまり、開発対象のマーケットをかなり絞り込んでいる。

すると、大手企業の業務システムよりも、ベンチャー企業や中小企業の事業システムの方が向いているのだろう。
リーンスタートアップのような最新の開発手法も適用しやすい利点もある。

【1-3】業務プロセスの視点

基本戦略は、格安航空会社(LCC)を真似た技術戦略がある。

格安航空会社(LCC)の戦略は、「使用する飛行機の機種を統一して整備費やパイロット訓練費を削減」「搭乗手続きのオンライン化などITによる自動化」「乗務員が機内の清掃・顧客サービスなどを兼務して人件費削減」だ。
この戦略を真似ると、以下の3つの観点になる。

・技術の標準化
→フレームワークはRuby on Rails、本番環境はAWSやHerokuで統一して、効率良いソフトウェア開発を実践。

・SaaS
→クラウド環境を利用して、スモールスタートやスケールアップをやりやすくし、デプロイ・リリース作業を自動化。

・マルチプレーヤ
→エンジニアは、開発者だけでなく、顧客との要件定義、クラウド環境へのリリースなど幅広い技術を使いこなし、複数の役割を兼務する。

もちろん、アジャイル開発などの開発手法も取り入れる。
そんな技術戦略を見ると、かなり対象を絞って、ニッチなマーケットで攻めている感じがする。

【1-4】学習と成長の視点

基本戦略は、ギルドによるフランチャイズ制。
ソニックガーデンと手を組む開発者はギルド集団として認知され、遠隔地でも働けるようにしている。
必要なエンジニアは、ギルド集団から随時登録され、仕事が与えられて回っていく仕掛けみたい。
この形式はフランチャイズ制に似ているように思える。

ギルド集団はエンジニアの育成集団、または、エンジニアの貯蔵庫(リソース・プール)みたいだ。
「「納品」をなくせばうまくいく 」を読むと、「レビューによる教育」や「技術者にのれん分け」するなどの話があるので、プログラマをすごく大切にしている雰囲気が読み取れる。

SIの観点では、受託開発は開発・テスト工程で開発要員の変動が大きすぎるため、社外のプログラマを短期間に大量に集めて、本番リリース前に契約を終了する開発スタイルが多い。
だから、プログラマを大切にする雰囲気は生まれにくいと思う。

一方、ギルドによるフランチャイズ制は、プログラマを顧問エンジニアになるレベルまで育成するリソースプールに置いておき、必要になれば仕事に呼ぶみたいな感じを受ける。
当然、ビジネスであるからには、仕事が渡ってこないプログラマもいたり、脱落するエンジニアもいるかもしれない。
だが、技術の向上を目指すエンジニアならば、武者修行としてやれるかもしれない。

ギルドによるフランチャイズ制には、プログラマのインセンティブを高めるような仕組みがあるように思える。

【2】「納品のない受託開発」のビジネスオーナー観点のチーム構造(イメージ)

「納品のない受託開発」のチームは、3つの構造を持つ。

【2-1】ビジネス推進チーム
・ビジネスオーナー＝ビジネスの最終責任者
・プロダクトオーナー＝仕様を決める最終責任者
・顧問エンジニア＝顧客企業のCTO or CIO

【2-2】スクラムチーム
・プロダクトオーナー＝PO
・顧問エンジニア＝開発チーム
・ファシリテーター＝スクラムマスター

【2-3】ギルド集団
・エンジニアの育成集団、貯蔵庫。

このような3つの構造があれば、顧問エンジニアはユーザ企業主体のビジネス推進チームだけでなく、開発会社主体のスクラムチームにも属しているので、開発会社のファシリテーター(スクラムマスター)の支援も受けることができる。
つまり、顧問エンジニア一人が苦労して潰れてしまうリスクを回避しているように思える。

また、開発会社のエンジニアの背後には、ギルド集団というエンジニアの育成集団がいるので、人数さえ揃っていれば、エンジニアの供給ができるだろう。
つまり、ギルド集団がうまく機能していれば、ビジネスのスケールアップにも対応しやすいはず。

【3】「納品のない受託開発」のエンジニア観点のチーム構造 (イメージ)

エンジニア観点では、3種類の役割があるように思える。

【3-1】エンジニアの担当作業
ユーザ企業(例：ビジネス推進チームA～C)ごとに、開発会社のエンジニアが顧問エンジニアで担当する。

【3-2】開発会社内部のエンジニア
・開発会社内で、エンジニア同士でサポートし合う。

【3-3】ギルド集団のエンジニア
・エンジニアの育成集団、貯蔵庫。

上記の役割を見ると、顧問エンジニアが一人で潰れないように、開発会社のエンジニアのサポートやギルド集団の支援もあるように思える。

【4】上記の戦略マップやチーム構造は僕の理解なので、多分正しくない部分があると思う。
でも、「納品のない受託開発」のビジネスモデルは、たくさんのパーツを整合性が取れるようにうまく組合せているように思う。
単純なアジャイル開発をやっているビジネスモデルではないみたい。

実際、SaaSでシステムを提供しながらも、ベンチャー企業のCTOサービスを提供して付加価値を付けているし、技術の標準化やマルチプレーヤ化でプログラマのスキルを高める配慮があるし、ギルド集団によるフランチャイズ制で、エンジニアを補給する手段も作っている。
つまり、プログラマのインセンティブを高める仕組みと売上を確保できるビジネスモデルを上手く組合せているように思える。

この辺りは本音をまた一度聞いてみたいと思う。