定期的にSI業界が終わったという話が出ますが、本当にそうでしょうか。終わるべきは一括発注・請負のディフェンシブなビジネスモデルです。受託はなくなることはありません。ソフトウェアの開発を、他の業界のアナロジーで考えるのではなく、正面から取り組んだビジネスモデルについて語っています。
(c) hinel｜写真素材 PIXTA
目次
ディフェンシブな開発
今から5年前に、SI業界における多くの問題の原因がそのビジネスモデルにあるという「ディフェンシブな開発〜SIビジネスの致命的欠陥」という記事を書きました。SIにおけるビジネスモデルは、発注者とベンダーはあらかじめ決めた金額と要件の中で納品と検収を目指すため、利益を出すためには双方がリスクを取らずに「守り」に入る必要があります。その結果、顧客にとって価値を産むかどうかよりも決められた要件通りに作られることを重視することになってしまいます。人月という単位であらかじめ決めるとなれば、単価の安い下請け会社を使うことにならざるを得ず、技術力の向上を目指すプログラマにとって生き辛い業界になっています。ここに潜む問題は現場の改善で解決できるものではなく、ビジネスモデルを変えるという経営者の判断が必要になるという話を書きました。
「ディフェンシブな開発」の記事は多くの方に読んで頂き共感を得ました。あれから5年が経ち、世界は変わったのでしょうか。ソーシャルゲーム業界が台頭したことやクラウドビジネスの盛り上がりから、ITをコアコンピタンスとする企業が優秀なエンジニアを直接採用するケースが増えたことで転職ブームが起きています。また、スタートアップという言葉が流行りつつあり、優れたプログラマが自ら起業するケースも増えてきたように感じます。こうした流れは必然ですし、良い傾向だと私は思います。やはり、ビジネスモデルを変えるのは現場のエンジニアの仕事ではなく、経営者の為すべきことです。では、この5年でSI業界のビジネスモデルに変化はあったのでしょうか。残念ながら大きな変化があったようには思えませんが、それを取り巻く環境は変わりつつあります。
5年で変わったもの
2007年からの世界金融危機の影響で日本経済全体に打撃が与えられる中、SI業界を支える企業のIT投資額にも当然のように影響が出てきました。それまでは、最初に予算を積みさえすれば、大手のSIベンダーが黒字になろうが赤字になろうが、最後まで作りきってくれるというビジネスモデルでした。そのビジネスモデルでは、ユーザ企業は完成リスクを丸投げする代わりに高い費用を払っていました。リスクを丸受けするために、SIベンダーには企業体力が求められます。数件のプロジェクトを抱える企業と、数百件のプロジェクトを抱える企業があるとしたら、後者の方が丸投げをする方からすると安心です。SIベンダーはある意味、保険屋のようなものだったのです。不景気になると、そのビジネスモデルの延長上では、経営者の採るべき方針は合併をして体力を増やすことしかないのも頷けます。
しかし、不景気になったことでコストを抑えるためにも、ある程度のリスクは自分たちで持とうとするユーザ企業も出てきます。そうなれば、体力があって安心できるだけのSIベンダーは選ばれなくなります。そうしてユーザ企業からのキャッシュアウトが減ってきたことが、SI市場がシュリンクしている一因だと考えられます。それでは、このままSI業界は終わってしまうのでしょうか。否、すべての企業でソフトウェアの開発と運用のすべてを内製化することはありえません。ITそのものでビジネスをしているのでなければ、お金を稼いでいる本業があるはずで、本業以外をアウトソーシングするということは当然です。つまり、受託はなくならない。では、何が問題の本質なのかと言えば、やはり「一括で発注・請負」をする「ディフェンシブなビジネスモデル」です。
本当に「SI業界が駄目」なのか
「ソフトウェアの品質はいつ決まるのか？〜「Point of Sales」から「Point of Use」へ」という記事で書いた通り「一括での発注・請負」は製造業の発想です。ソフトウェアでこのビジネスモデルを採用したことは多くの弊害を産みました。最も大きな問題が人月という単位です。目に見えないソフトウェアを測るために「どれだけ工数がかかるか」で見積もりをするのですが、同時にその見積もりで契約では「完成責任」を負います。このねじれがある限り、エンジニアが技術力を高め生産性をあげれば上げるほど売上高が下がるという構造から抜け出せません。それ以外にも、要件定義したのに、出来たものが要件と違ってしまって揉めるなんてことはざらにあります。また、プロジェクトの途中で誰もが不要だとわかった機能であっても、要件が決まっているからと作らないといけない無駄もあります。
そもそも「SI業界が駄目」というのは何を指して言っているのか、はっきりさせておく必要があります。「一括で発注・請負」をするビジネスモデルのことを、システムインテグレーション（SI）と呼ぶのであれば、それは駄目だと私も強く思います。以前は私もそこを混同させていました。しかし「一括で発注・請負」をするというのは取引の仕方だけで、お客様が必要とするシステムやソフトウェアをプロフェッショナルとして提供するという市場は存在し続けます。目指したい姿は、リスクを理解したお客様と直接プログラマが対話をし、お客様のためにオーダーメイドで価値を産み続けるソフトウェアを作るスタイルです。それはお互いに守りに入るのではなく、ソフトウェアの生み出す価値を最大化するために、対等に切磋琢磨しあえる関係です。それは「一括で発注・請負」では出来ません。
「納品しない」という仮説
「ディフェンシブな開発」の記事を書いてから、ずっと「一括で発注・請負」ではない新しいビジネスモデルを模索してきました。その一つの答えとして「改善型開発 ～ システムを作るのではなく育てるという発想」という記事を書きました。そこで、プロジェクトの一番初めにリリースを行い、それから受発注契約を結び保守と改修を繰り返すことで、システムの改善を推進するという改善型開発という開発モデルについて提案しました。この記事を書いた時はまだ事例も作れてなく、私の仮説に過ぎず、なによりビジネスモデルまでは考えられていませんでした。その後、何度も失敗の経験と、クラウドのビジネスをする経験を積むことで、「一括で発注・請負」の問題はすべて「納品」してることに起因しており、そこで「納品しない」ことによって解決するのではないか、という仮説に辿り着きました。
「キャプション直すだけで数万円？システム開発の値段が高くなる３つの理由とは」という記事で書いたのは、IT投資のコストパフォーマンスの悪さについてです。原因は、１）ベンダの見積りにおける過重なバッファ、２）開発と運用で別の業者を利用していること、３）最大時を想定したハードウェアを購入していること、と分析をしました。実は、これらもすべて「納品」していることに起因します。納品するためには要件の確定と見積もりが必要になり過重なバッファが発生し、納品があるから開発と運用が分かれますし、納品するためにハードウェアを購入するのです。人月以外の単価ということで、ストーリーポイントやファンクションポイントなども試しましたが、結局は「金額のための見積もり」につながってしまえばうまくいきません。金額のための見積もりをしてはいけないのです。
「ソフトウェアパートナーシップモデル」
「オーダーメイドの受託」と「納品しないこと」の両立が新しいビジネスモデルの肝です。作業のための見積もりは良いですが、それを金額に換算してしまえば人月になってしまう。金額を見積もりから分離するには「定額モデル」を採用すれば良いのです。月額定額のキャップを決めて、その中で出来る範囲の開発と運用をしていくという、信頼をベースにおいたビジネスモデルです。月額定額の中で出来るだけのことをするというのは、顧問弁護士や顧問税理士のようなビジネスに近いです。私の考える「一括で発注・請負」ではない新しいビジネスモデルは、ソフトウェアのライフサイクルすべてを受け持つ顧問のようなスタイルです。顧問といっても開発と運用のために手を動かすため、内製部隊のように使うことができます。それを「ソフトウェアパートナーシップモデル」と名付けました。
この「ソフトウェアパートナーシップモデル」という仮説を立証するために、SonicGardenで試行錯誤を繰り返してきました。ここからは、今のSonicGardenで行っている「ソフトウェアパートナーシップモデル」の内容を紹介します。SonicGardenでは「カスタムクラウド」というサービス名で呼んでいました（今、サービス名の変更を検討してます）。私たちが考える「ソフトウェアパートナーシップモデル」のポイントは４つあります。「クラウドのアプリケーション」「開発と運用を分けない」「月額定額」「チーム固定」です。
「クラウドで動くアプリケーション」
まず提供するのは「クラウドで動くアプリケーション」だけに限定しています。オンプレミスで動かすということは、どこかで「納品」をしないといけなくなるからです。私たちは納品しないことを目指すので、作るものはクラウド上で動くウェブアプリケーションに限定しています。実際には、エンドユーザが利用する本番環境の他に、顧客側の仕様責任者（プロダクトオーナーと呼んでいます）が動作を確認するためのステージング環境も、クラウド上に用意します。プロダクトオーナーは、ドキュメントで仕様の確認をするのではなく、実際に動くアプリケーションで確認をしてもらいます。そして、確認が出来れば、あとはいつのタイミングでも本番環境へ反映させます。どちらもクラウドなので、リリースはあっというまに終わります。プロダクトオーナーにとっては、机上の空論で進捗や製品の確認をしなくても、実際に動くアプリケーションでいつでも確認ができるというメリットがあります。
「開発と運用を分けない」
次に「開発と運用」は分けない体制を採用しています。もし開発と運用を分ける、ということになれば、それもどこかで「納品する」ということになるからです。開発と運用を分けずに、クラウド上のアプリケーションの裏側の全てを任せて頂くというアウトソーシングになります。SonicGardenが開発と運用の両方を受け持つということは、プロジェクトに終わりがないということでしょうか。いいえ、そうではなく、そのソフトウェアが稼働し続ける限り、ずっと面倒を見続けるということです。終わりがあるとすれば、そのソフトウェアを稼働させなくなった時です。開発と運用を分けないことで、引継のためだけの無駄なドキュメントは不要になり、圧倒的なコストダウンを実現することが出来ました。
「月額定額」
そして、このビジネスモデルの最大の特徴が「月額定額」です。「納品」するということは見積りが必要ということで、逆に、納品しないことに対しては「見積りしない」ビジネスモデルにする必要があります。そこで、私たちは月額に支払われる金額の上限額を決めて、その範囲内で出来るだけの作業を実施するということにしました。月額定額にすることで、最初の大きな要件定義は要らなくなります。最初の１ヶ月分くらいの機能を決めて、順に開発を進めていき、すぐに運用に入っていきます。プログラマが作業に入っている間に、プロダクトオーナーは次の機能を決めていけば良いのです。しかも、本番で運用が始まれば、ユーザのニーズを汲み取りながら変えていけます。月額定額なので、要件はいつでも、どれだけ変えても良いのです。要件はいつでも変えても良いし、どれだけ変えてもかまいません。優先順位も変えることができます。これも大きなメリットです。
しかも、月額定額という金額を決めてしまうことで、新しい機能や要件が出た際に、ベンダの営業担当が持ち帰って見積りを・・・というようなことをしなくて済みます。プログラマに直接依頼すれば良いだけです。こうすることで、見積りをするだけの営業は要らなくなりますし、バッファを積むだけのマネージャも不要になります。プロダクトオーナーとプログラマの間には誰も入らないので、話がスピーディになります。そして、またしても大幅にコストを削減できました。プロダクトオーナーは、実際に手を動かすプログラマと直接に対話ができることで、余計な伝言ゲームがなくなることもメリットです。
月額定額にするという選択は、私たちにとって一時的な売上を捨てることを意味します。しかし、私たちはお客様と長くおつきあい出来ることを選びました。また月額定額なので、プログラマは時には、プロダクトオーナーの思いつきの機能を否定することもあります。限られたリソースを有効に使うため、本当に価値のあるものだけを作ろうと考えるのです。プログラマがお客様の立場に立って話ができることも特徴です。私たちは、お客様のパートナーとして長くおつきあいさせて頂くビジネスモデルにしたことで、お客様とともにそのソフトウェアの価値を追求します。
「チーム固定」
そして最後の特徴が「チーム固定」という点です。これまでのシステム開発では属人性を排除しようとするので、最初の提案時にエース級のプログラマが出てきたけど、実際に作業するのは別の担当者がアサインされることがあるかもしれません。しかし、SonicGardenでは「属人性」を重視するビジネスモデルにしました。契約して頂くプロダクトオーナーごとに、メインプログラマとサポートプログラマの２名をアサインします。そして、彼らはそのプロダクトオーナーの担当として、ずっと開発と運用の両方を行っていきますし、窓口自身もそのプログラマが行います。当社のプログラマは、プロダクトオーナーと対話をし要件の引き出しから、画面設計データ設計から、ソースコードでの表現まですべて行える担当者を用意しています。
「お客様にとっての内製部隊として使って頂く」
「月額定額」で「人を固定」して提供するビジネスモデルと言えば、派遣を想像するかもしれませんが、SonicGardenでは派遣は一切行いません。プログラマがお客様のところへ伺うことはしないというのが、私たちのスタイルです。ではどうするのか。ここで出てくるのが第３のクラウドです。youRoomやSkype、Pivotal Trackerといったクラウド上のツールを使ってコミュニケーションしていきます。実際のところ、移動するコストは馬鹿になりません。生産性を阻害し、移動にかかる時間もコストになり、そうしてまで移動する価値は、クラウドを活用すればなくなります。移動にかかるコストは、結果的に顧客が支払う金額の中に入っていることを気付くべきです。私たちは、そうした無駄を省くことで、圧倒的な低価格を実現しています。オプションで移動することも可能ですが、高価格になるのでオススメできません。
また「月額定額」で「人を固定」するというのは、顧客自身でプログラマを雇用して内製することに近いです。私たちは、顧客自身で内製をすることが本当は最も効率よくソフトウェアを作っていけると考えています。しかし、プログラマを雇用するのはリスクが大きいのも事実です。簡単に解雇できない雇用リスクもありますし、良いプログラマかどうか判別することは一般の人にとっては相当難しいことでもあります。私たちは「お客様にとっての内製部隊として使って頂く」ことをコンセプトに提供しています。つまり、ひとりのプログラマを雇用するよりも安い価格で、かつ、既に実績のある私たちのプログラマがチームで対応させて頂くという形です。私たちはお客様にとっての顧問プログラマになりたいのです。企業法務を担当する弁護士は、１社専属ということは殆どの会社ではありえなくて、弁護士を複数の企業でシェアする形をとると思います。私たちのプログラマも、複数の企業でシェアして頂くことで、最大のコストパフォーマンスを発揮することができます。
プログラマの努力がビジネスに反映される仕組み
このビジネスモデルでは、プログラマは技術力を高めて生産性を上げることによって、効率を高めることができ、シェアできる企業を増やしたり、自社作品のサービスを作る時間を増やすことができるようになります。そうして、自身のギャランティーを増やしたり、新しい挑戦のための時間を作ることができます。また、プログラマは移動しなくて良いので、どこからでも仕事をすることが出来ます。「『国境なきプログラマ』を目指す～ノマドワークの究極のかたち」という記事で紹介した通り、アイルランドにいながらにしてプログラマとして仕事をすることが出来るのです。
「ソフトウェアビジネスの新分類」という記事で書いた通り「ソフトウェアパートナーシップモデル」は、あの図の左上の領域（ソリューション型＆サービス型）です。この領域はまだこれからの市場です。そして私の考えでは、左下に比べて売上高では低く、その代わりに利益率の高い市場になるはずです。丸投げするのではなく、自らリスクをコントロールして価値を産むソフトウェアを作りたい顧客にとって、左下の領域で提供される品質は過剰です。左下の領域の企業にとってイノベーションのジレンマに陥っており、容易に左上の領域には移ることは難しいでしょう。
運用中心プロセスとARC（Agile/Ruby/Cloud）
このビジネスモデルを実現するのに必要なポイントをあげるとするならば、１）スモールスタート出来るように小さい状態でも動くものを素早く作り上げること、２）徐々に肉付けを行い改修していくために保守性を高めること、３）利用者が増えた場合でも容易にスケールアウトすることができること、になります。それらについて、SonicGardenでは、アジャイル開発、Ruby、クラウドによって実現しています。それを実現したプロセスが「「運用中心プロセス」という考えかた～モノ作り中心から動くサービスを中心に据えることへのパラダイムシフト」という記事に書いた「運用中心プロセス」です。
ソフトウェアパートナーシップモデルで目指すビジョン
私は、このソフトウェアパートナーシップモデルのビジネスモデルが広まることで、受託開発の業界は新しい市場が開けるのではないか、と考えています。そのビジョンでは、ソフトウェアを提供するベンダーはただ仕様通りに作るのではなく、顧客企業にずっと寄り添う形でサービスを提供し続ける関係になり、プログラマという仕事を希少価値の高い職業にすることで、プログラマで高みを目指し続けることで高い報酬を得られ、プログラマを一生の仕事にできるような業界が作られるのではないか、と考えています。そして、このビジネスモデルは、もはや只の理想ではなく、現実に契約は始まっています。
