先日、経団連会館にて情報サービス産業協会が主催された「第４回構造改革シンポジウム 情報サービス産業における新ビジネスモデルへのチャレンジ」に参加して登壇してきました。
その際の様子を収めた会報が発行されて、私の話した内容も掲載して頂けたので、私の部分だけを抜粋して、こちらの記事で紹介します。
目次
「納品のない受託開発」にみるソフトウェア受託開発の未来
受託開発の新しいビジネスモデル「納品のない受託開発」をご紹介いたします。
当社はエンジニアが5名と社長、副社長の7名(*1)の会社ですが、小さい会社であっても大きなことをしようというのがポリシーです。当社の技術的な特徴は、「アジャイル×Ruby×クラウド」をベースにリーン・スタートアップ方法論を実践しているところにあります。
我々のビジネスは、オー ダーメイドで納品するシステムインテグレーションビジネスではなく、自分たちで企画したパッケージを販売するビジネスでもありません。
最近マーケットを拡げている、グーグルやセールス フォースのような自分たちで企画してリスクを取って納品しないビジネスもやっていますが、本日ご紹介するのは、オーダーメイドなのに納品しないビジネスです。
*1：これが開催された2013年2月時点の話です。
(1)「ソフトウェアを売る」のではなく「ソフトウェアが使えることを売る」
このビジネスは「完成」よりも「持続」の考え方が重要です。
顧客がクラウドを利用し使い続けるためには、ベンダはソフトウェアを修正し、メンテナンスし続けないといけない。「ソフトウェア」を売るのではなく、「ソフトウェアが使えること」を売る、言い換えれば、ソフトウェア機能を売るのが、IT企業のサービス化だと思います。
こういう考え方に至ったのは、前職のシステムインテグレータ(以下SIerと表す)時代に、顧客の要望に応じてシステムを修正し、顧客の望むシステムに近づけていくアジャイル手法に取り組んだのですが、全然うまくいかなかった経験があったからです。
アジャイル手法の何が悪いのだろう、どうすればアジャイルができるだろうかと考えたところ、ビジネスモデルに問題があるのではないか、と気づいたのです。
顧客はシステムを使って収益を上げたり、コスト削減したいのに、ベンダはシステムを作ること自体がゴールになっている。システムで価値を生むのではなく、要求通りに作ることがベンダの利益になる。
このモデルを変えない限り、私のやりたいことはできない。
顧客がSIerに期待するのは、SIerが最終的な責任を負ってくれるからのようです。だから安心感のある大手SIerと契約するのでしょう。
こういうビジネスモデルは保険ビジネスに似ています。しかし大きく異なるのは、お金で解決できない場面が多いこと。こういうプロジェクトに放り込まれたエンジニアは悲惨です。
(2) ビジネスモデル「納品のない受託開発」
技術者視点で見たSIビジネスの問題は、人月で見積もりすることです。人月で見積もりするのに完成責任を負わされる。こんな商売は世の中にありません。
完成責任で商売するなら完成品に値札をつけて売る。誰が何カ月働いたかという労賃では売らない。弁護士は人月で商売しますが、人月で商売するときは完成責任を負いません。時間分のお金をもらいます。
納期があって、見積もりがあって、完成責任を負うビジネスモデルでは、リスク分を上乗せした納期や見積りになるのは仕方がないと思います。上乗せ分をなくし顧客本位を指向したのが、当社のビジネスモデル「納品のない受託開発」です。
「オーダーメイドの受託開発」だけれども、「納品しない」、エンジニアの生産性を上げるために「派遣しない」、この三つを両立させるために、月額定額にするというのが当社の答えです。
月額定額の中でできる範囲の開発と運用をセットにして分けることはしません。クラウドを利用して開発しエンジニアを派遣しません。
具体的には、クラウド上でのソフトウェア開発に限定する、社内で運用するとなれば納期や納品が発生するからです。
開発と運用を分けない、要求定義に時間をかけてもシステムは常に動いているので、仕様変更は必ず発生します。2、3週間分だけ決めて作り、作った分を確認した方が顧客も仕様変更を要求しやすい。
顧客先にプログラマは行かない、ただしコミュニケーションツールで、プログラマと顧客は直接対話しています、移動時間や会議のための準備時間は無駄です。
最後はドキュメントを書かない、ドキュメントは引き継ぎのためにある、我々は一人の人間がずっと見るのでドキュメント不要です、その分コストカットができます。
(3) 顧客の「顧客」に向けて
昨今のビジネス環境はスピード重視、フィードバック重視で、スモールスタートして販売の拡大が見込めたら、スケールアウトしたいと言っているお客さんがたくさん出てきています。
このような要求に対してSIで一括開発というのは非効率です。一括請負だと非効率なので、当社のビジネスモデルが有利になる。
これからはシステムを発注くださる顧客の「顧客」に向けて、システム開発する仕事がどんどん増えてくると思います。
所有から利用へ、完成から持続へと変わるビジネスによって、産業自体も変わるでしょう。売り切りの時代からずっと使い続ける時代になります。
このような時代に産業革命を起こそうというのが「ソニックガーデン」の会社のあり方です。
質疑応答＜属人性を重視した納品のないビジネス＞
司会
次は倉貫さんにおうかがいします。倉貫さんにも質問がたくさん集まっています。一言で言うと、本当にそんなにうまく行くものなのかという疑問の声です。
例えば、弱点はないのか、属人的になるのではないか、それらはどのように解消するのか。また、この方法では社員の給料も定額になってしまわないのかという質問も来ています。
倉貫
うまく行っていますよ。（笑）
ただ、普通の社員構成でされているような会社が我々のビジネスモデルでやろうとしても、すぐには成果がでないと思います。言い換えると、「納品のないマーケット（ソリューション型＆サービス型）」には入って来れないでしょう。
これがイノベーションのジレンマというものだと思います。
当社はエンジニアがほとんどです。間接部門の人間はいないので、余計な管理コストがかからないです。
当社がやっている納品のないマーケットは、例えば弁護士や、少数の優秀な人で成立するようなマーケットにしたいです。大勢の人はいなくてもいいし、雇用が増えないというのは望むところです。人数を増やして会社を大きくすることはできない会社です。
属人的かどうかということでは、属人的でいいと思っています。優秀な人間がレベルの高い仕事をするには属人的にならざるを得ないのではないでしょうか。どんな仕事でも、どんな職業でもそうで、サービスビジネスはそういう人たちで手掛けるビジネスなのです。
そのためには、属人的なまま採用を上手にやるとか、辞めないでもらうというところが大切になります。
質疑応答＜生産性を高める工夫＞
司会
顧客との打ち合わせにより、エンジニアが仕様を詰める、そうした意味の属人性ということではどうでしょうか。
倉貫
そういう意味だと、当社は顧客ごとに一人のエンジニアが付き、要件定義からクラウドでの運用まで全部一人で担当しますから、その仕事に関して言うと属人的な仕事のやり方です。これでいいと思っています。
技術の部分ではRubyというフレームワークを使っています。Rubyを社内で徹底的に共通化しています。ですから、ソニックガーデンではPHPやJavaを手掛ける人は採用しません。Rubyで社員全員を統一しているので、そこでは問題なく共通化はできています。
その共通化の仕組みを社内で整備するか、外部のものを活用するかという観点では、僕は社内で持つのはナンセンスだと思っています。グローバルにオープンソースの世界で標準化されたものがあれば、当社はそこに乗っかるほうがいいと思っています。
社員の給与については、エンジニアの生産性を上げるモチベーションとしてすごく関わりがあります。これまでのビジネスモデルでは生産性が上がれば上がるほど仕事はたくさん来るのに給料は上がらないということが起きていました。
当社のやり方をすると、生産性が上がれば、給料も上がります。
というのは、顧客と働いている時間で契約していない。エンジニアは顧客と月々のパフォーマンスで契約をします。本当は1カ月フルフルかかっていたのが、成長して1年後にはそのエンジニアが同じ仕事をするのに半分の時間でできるようになります。そうなると残りの半分の時間でまた別の仕事ができるわけです。
優秀なエンジニアは当然給料が上がり、エンジニアとしては頑張り甲斐がある。エンジニア道を突き進めば、給料が上げられるという仕組みになります。
質疑応答＜Point of SalesとPoint of Use＞
司会
一つ聞きたいことがあるのですが、ここには大会社の方もおられます。既存の会社の中で社内ベンチャーをつくる場合と、大きな会社から独立して会社をつくる場合では何が違うのか。そのへんについてコメントがあればお願いします。
倉貫
社内ベンチャーのときは、実は今日お話しした「納品のない受託開発」はやっていませんでした。社内ベンチャーは会社の本業と違うことをやるということで始めました。
受託開発では本業の事業部の人と食い合うことになってしまうので、やってはいけないと思っていたし、やらなかった。 もし、やっていたとしても、多分できていなかったでしょう。これは我々が独立したきっかけの一つでもあるのです。
品質管理の考え方は、いわゆる「納品のないビジネス」と「納品のあるビジネス」ではまったく違います。「Point of Sales」、「Point of Use」という考え方になります。これは別にソフトウェアビジネスに限ったことではありません。他のビジネスでもあります。
「Point of Sales」とは、製造業における品質管理の考え方です。顧客がその商品を買う時点、提供側からするとその商品を売る時点を最高の品質にしようということです。それはそうです。品質をつくり込んで売り、お金をもらう。
例えばパソコンを買ったとします。買ったときは最高の品質でした。そこから1年たつと古くなりますから、償却していきます。そして新しいものに買い替えるというのが、いわゆる製造業、販売するというビジネスの品質の考え方です。
だから「Point of Sales」と言います。セールスする瞬間を最高の品質にするということです。
一方、サービス業では、タクシーにもレストランにも映画館にも当てはまりますが、利用するサービスの品質曲線が製造業と違って一定です。むしろ、もうちょっと線を上げないと競合に勝てません。つまり、利用する瞬間を最高品質にしましょうというのがサービス業の考え方です。
システム開発で考えると、一括請負の受託開発というのは「Point of Sales」にあたります。QA部門があり品質をつくり込んでいます。しかし、僕らの「納品のない受託開発」は「Point of Use」です。一定までつくって終わりではなくて、ずっと直し続けなければいけない。
この品質対する考え方の違いによって、お金の回収、与信管理の仕方等が全部変わってきます。我々は「納品のあるビジネス」を営む会社の中で、社内ベンチャーをやっていたので、「納品のないビジネス」のことをやろうとしてもあらゆることが社内手続き上で例外の扱いになってしまいます。
何をしようとしても、経理部門、総務部門、本部の部門等とぶつかってしまいます。だから、別会社にしないとできなかったということです。
荒野
アイデアがあっても、それを支える仕組みが合っていないとどうにもならないということですね。
質疑応答＜新規事業への取り組み方＞
会場
示唆に富んだお話しありがとうございます。我々のこの10年とか20年は、例えば大企業だからとか、何か阻害要因があるため、わかっていながら変えられない、うちには適用できないという状況が続いています。もともと二進法で育っているから0か1に分けてしまうというところがありがちです。
今日お集まりの方はそういう方は少ないかもしれませんが、往々にしてありがちなので、改めて皆さんが適用できないものではないというメッセージを、何か思いつくことがあれば言っていただけたらと思います。
司会
実は、それは最後の質問に取っておこうかと思っていたのですが、まさに聞きたい質問です。会場の皆様の会社でもできる、あるいは皆さんのヒントになるようなことをそれぞれお話しいただけますか。
倉貫さん、どうでしょう。
倉貫
お話ししたモデルは、いまの事業をされているところでそのまま適用するのは難しいし、できないと思いますが、新しく会社をつくってチャレンジしてみるのであれば、まずできると思います。
あとは、我々自身がやってきたことを振り返って考えると、会社の仕組みをしっかりしすぎると、たぶん私みたいな人間は出てこないのだろうと思います。私はTIS（株）の中ですごく自由にさせてもらって、怒られはするのですが、それくらいで済む。
だからこそいろいろなことにチャレンジさせてもらい、社内ベンチャーや自分で会社を持つことに繋がったのかなと思います。
ここにいる皆さんで新しい事業をやろうというのは、結構ご年配なので無理じゃないかな（笑）・・・というのは続きがあって、皆さん自身で別にやらなくてもいいと思っていて、会社の中の若い人たちがやればいい。
そのときに社員がやることをすぐ諌めたり、怒ったりすると、社員も子どもと一緒で萎縮してしまい、次のチャレンジがしにくくなる。私はそのへんも割と伸び伸びさせてもらったのが良かったと思います。
あと新規事業は、小さく始めて失敗するのがポイントだとネスレの高岡社長もおっしゃっていましたが、私もそうだと思います。
本業ではないことを始めるのだから、小さくていいと思わないと、新しいことは始められないでしょう。そのへんを怒らないとか、小さくても始めさせてみる。若い人たちがやることを邪魔しない、阻害しないで応援すれば、新しいことができるのではないかと思います。
