日経SYSTEMS 2012年4月号の特集１が「システムを育てるカイゼン型開発のススメ」ということで、Part4に私も寄稿させて頂きました。ソニックガーデンが今のビジネスモデルを採用した理由について書きました。
「カイゼン型開発」という言葉は、2006年に私がブログで書いたのですが、ようやく時代が追いついてきたのかと感慨深いものがあります。そして、2012年の私たちは既にそこからさらに先に進んでいて、その答えとなる「納品のない受託開発」というビジネスモデルに辿り着いています。
実際に掲載された寄稿記事の方では割とコンパクトにまとめてもらいましたが、こちらではディレクターズカットということで元々に書いた原稿の方を公開します。もし、このブログよりもさっと読みたい場合は日経SYSTEMSを読んで頂くのが良いかと思います。
SonicGardenでカイゼン型開発を行う理由
ソニックガーデンでは「納品のない受託開発」という少し変わったスタイルでの受託開発を行っています。図１の左上の領域です。
ソフトウェアの受託開発と言えば、これまでは図１左下の一括請負による納品型のビジネスモデルが主流ですが、実はそのビジネスモデルはお客様にとってもベンダーにとっても、そして開発者にとっても不幸になる問題をはらんでいると考えているからです。
「一括納品モデル」がもたらす問題
一括請負による契約の納品型のビジネスモデル（以降、一括納品モデル）では、発注者とベンダーはあらかじめ決められた金額と要件の中で納品と検収を目指して開発を行います。
そのために発注者は発注前にすべての要件を決める必要があり、発注後は当初に決めた要件を途中で変えることは基本的に不可能となります。
このビジネスモデルの中では「仕様変更」とは追加費用が発生するものであり、初期の想定違いや技術的なリスクによって発生する仕様変更にかかる費用を、プロジェクトの途中で発注者とベンダーでどちらが負担するのかで揉めることも多くあります。
「要件定義」で解決するのか？
そうした問題を解決するためにベンダーが考えたことは、いわゆる「要件定義」と呼ばれる工程でしっかりと、要件を洗い出して計画を立てることが重要だということでした。
事前にすべての要件を並べだし、問題点やリスクを洗い出すことで、計画通りに開発が進められるようにしようということです。
しかし、果たしてそれは発注者であるお客様にとって、本当にメリットのあることなのでしょうか。システム開発の初期の時点で考えた「計画通りに」システムが「完成」したとして、本当にお客様にとって役に立つのかというと、はたして疑問です。
発注者とベンダーのゴールの違いが原因
お客様にとってはシステムは稼働してからが重要ですし、当初の計画を立てた時期の外部環境とシステムが完成した頃の外部環境は変わっているはずで、そのままのシステムだけでは役に立たないことも多くあります。
ましてや、社内の社員だけが使うシステムならまだしも、ECサイトやウェブサービスなどといったエンドユーザがベンダーから見たお客様のお客様である場合には、想定通りにシステムが使われることは滅多にありません。
システムは動き始めてからが本番で、そこからどれだけ環境やユーザからのフィードバックを得て「改善」していけるかということが重要で、そういうシステムこそが本当にお客様にとって価値をもたらすものになるはずです。
発注者にしてみるとシステムが完成してからが重要で、ベンダーにはシステムが完成するまでが重要になっている、このゴールの違いが、一括納品モデルによって引き起こされる問題の原因です。
ベンダーが利益を出すためには？
あらかじめ要件と金額が決まっている一括納品モデルにおいて、ベンダーが利益を出すためには、開発途中に発生しそうなリスクを計画上の時点でなるべく潰し、見積もりの際に想定した利益分を減らさないような開発の進め方をしなければいけません。
単価の低いオフショアを使うことは価格競争を勝ち抜くためには必要ですが、人月という単位で見積もりをする限り、本来であれば売上と利益が下がってしまうので、自身の首を締めることになりかねません。
ここでベンダーのマネージャが採れる戦略は、売上をあげるために立派な提案書を作り沢山の機能をお客様に必要と思ってもらって大層なシステムを作りましょうと言うことと、利益を確保するためになるべくリスクを洗い出して想定するバッファを沢山積んでおいて実際にはそのバッファを使わないように守りに入ることだけです。
この一括納品モデルの中では採れる戦略が限られているのです。
契約だけを変えても意味がない
この一括納品のビジネスモデルがある限り、ウォーターフォールであるとかアジャイルであるとかといった開発の進め方では解決しないし、これは契約の仕方や料金回収のタイミングを変えたからといって解決する問題でもないのです。
一括納品モデルでは、発注側は金額内で要件を守らせることを重視してしまい、ベンダーはリスクをとらずに利益を守ることに集中してしまいます。結果として、そのシステムが発注者にとって価値を産むかどうか、ということよりも、決められた要件通りに作ることこそが大事になってしまうのです。
この守りに入ることでしか価値を産まない問題を私は「ディフェンシブな開発」と呼んでいます。
「ディフェンシブな開発」からみた業界構造
「ディフェンシブな開発」から気付いたことは、実は「一括納品モデル」を採用するシステムインテグレーション（SI）ビジネスの本質は保険屋と一緒なのではないか、ということです。
つまり、顧客からすれば、要件と金額を決めて発注さえすれば、途中に何があろうと最後までやり遂げてくれるというのがSIerなのであれば、扱うプロジェクト数が少ない小さなSIerに頼むよりも、多少割高になったとしても大手の会社に頼む方が安心なことは自明です。
大手のSIerであれば、いくつかのプロジェクトが赤字になろうとも、他のプロジェクトで黒字になっていれば会社としてはやっていけます。つまり最後までやり遂げるということがSIerのお客様への大きな価値になる訳です。
会社を大きくするしかなかった
システム開発において発生するであろうリスクも含めて丸投げしてきたのが、これまでの一括納品モデルだったのです。
大手SIerに発注するとなると、高いバッファが積まれて、金額が高くなったとしても、決められた金額からはみ出すことなく発生するリスクを受けてくれるのであれば、頼むだけの価値があったのです。
つまり、リスクを受けきれるだけの体力があり、大きなプロジェクトを受けても検収までやりきれる体力があるような大きな会社が強い世界になるので、多くのSIerが合併や統合をしているのは理にかなったことなのです。これはまるで保険会社と同じなのです。
違うのはSIerのプロジェクトで扱うのは保険のようなお金ではなく実際に働くエンジニアたちなので、会社から見て赤字プロジェクトでもやむなしとされるところで働くエンジニアが悲惨であることは残念なことです。
生産性を上げる意味がなかった
エンジニアから見た一括納品モデルのビジネスとしては、「人月という単位」で見積もられる中で求められるのは「成果物の完成責任」であるという捻れの構造です。
最終的には納品をするのであれば「完成責任」が求められるのは当然です。それはそういったビジネスで良いのですが、それを「人月」という作業量で見積もっていることがおかしくしています。
作業量で見積もるのであれば、作業量に応じた報酬が出るのが普通です。必ず完成することを、作業の見積もりで約束するとなれば、大きなバッファを積むしか回避する方法がなくなるのです。
また、人月の見積もりの問題は、エンジニアが生産的であればあるほど、見積額が下がってしまうということです。３人３ヶ月で作れるチームと、10人10ヶ月かけて作り上げる体制と計画では、単価が変わらなければ後者の方が売上高は高くなってしまいます。
これでは、エンジニアが生産性をあげようというモチベーションが下がってしまうのは当然です。
「Point of Sales」と「Point of Use」
ソニックガーデンでは「納品のない受託開発」に取り組む以前から、社内SNS:SKIPやプロジェクトツール:youRoomなどをクラウドを通じて提供するビジネスを行っていました。このクラウド（SaaS）の世界では、一括納品モデルの受託開発の世界とは真逆の考えかたが求められるマーケットでした（図１）。
そして、このクラウドの業界を経験したことで、品質管理に関する考えかたについて大きな発見がありました。
図２は一般的な業界による品質の考えかたの違いを表した図です。左側が製造業で、右側がサービス業です。
製造業は、モノを販売する業種なので「Point of Sales」と呼ばれる、お客様が購入する瞬間を最も品質の高い状態にもってこようという考えかたです。例えば新車を買う時は、購入の瞬間が最高の品質になっていないと嫌だと思います。モノを購入するビジネスは「Point of Sales」なんです。
一方、右側のサービス業は、モノを売るのではなく利用することに対してお金を払ってもらうビジネスの品質の考えかたです。例えばタクシーはサービス業で、乗った瞬間が最高の品質になっていなくてはいけません。この利用する瞬間を最高の品質で保つというのが「Point of Use」です。
クラウドは完全に右側の考えかたでソフトウェア開発を行っています。いつでも利用開始でき、常に安定していて、定期的にバージョンアップしていくのは「Point of Use」です。
そして、実は一括納品モデルを採用しているSIerは「Point of Sales」だったんです。そう考えると、SIerは製造業であり、工程を分割するようなエンジニアリングの考えかたは、理にかなっていたのかもしれません。
しかし、そろそろソフトウェア開発を製造業のメタファから脱却する時期にきてると考えています。
スモールスタートとスケールアウトが求められる時代
これまでのシステム開発と言えば、企業内における業務の効率化や、会計や製造のための基幹システムなどが多かったため、事前に要件を決めることも何とか可能だったかもしれません。
しかし、これからのITを活用する場面は、事業の付加価値としてのシステムや、ITそのものでビジネスをする企業にとってのシステムが求められるようになってきており、そうした場面において事前に全ての要件を決めきることなど不可能となりつつあります。
事業としてのシステムを作る際は、事業開始のタイミングでの初期投資を抑えたいものですし、一方で、事業が軌道に乗るに従って機能やインフラを拡大していきたいと考えるものです。
本気で事業を成功させる気があるのであれば、こうしたスモールスタートをしつつ仮説検証を繰り返しながら、将来的にスケールアウトすることを目指すべきです。
しかし、一括納品モデルではそれには対応することができません。お客様が「Point of Use」のサービス業をするのであれば、それを支えるシステムも「Point of Use」で作り続けなければいけないのです。
これからの時代、こうしたニーズを求められるようになり、そこに大きな市場ができると予想しています。
「一括納品モデル」に代わる新しいビジネスモデル
システムのスモールスタートをするためにはどうすれば良いか。
一つの答えは技術者を抱えて内製をすることでしょう。大手のゲームプラットフォーム企業などの資金力のある会社では、多くの技術者を雇い入れて内製を行っています。技術者が社員であれば、柔軟に開発を進めていくことも、リリースの内容やタイミングを見直すことも容易です。
しかし、すべての会社で技術者を抱え込んで内製できるかというと、それは現実的ではありません。IT以外の本業がある会社で優秀なエンジニアを採用することは非常に難しいことですし、社員として雇うのは大きなリスクになります。
内製部隊を持てないけれども、事業のためのシステムをスモールスタートで作ることができるようなアウトソーシングを望むニーズに対して、私たちソニックガーデンでは「パートナーシップモデル」というビジネスモデルを発明しました。それが「納品のない受託開発」です。
パートナーシップモデルでは、「受託で開発すること」と「納品しないこと」と「派遣しないこと」の３つを両立させることを実現しました。
まず「月額定額」ということにすることで、金額を工数の見積もりから分離しました。月額定額の中でエンジニアが出来る範囲の開発と運用をしていきます。
これは顧問弁護士などの顧問ビジネスのようなスタイルに近いと言えますが、コンサルティングではなく実際のシステムのライフサイクルをすべて受け持つ内製部隊のように働きます。
同時にクラウドを活用することでエンジニア自身は派遣されずに働くことができるようにしました。働いている時間を直接売っている訳ではないので、生産性をあげるモチベーションがとてもうまく働きます。
私たちの目指す姿はリスクを理解したお客様とプログラマが直接対話を行い、お客様のためにオーダーメイドで価値を産むソフトウェアを提供するというスタイルです。私たちが目指すのはお客様にとっての真のパートナーになることです。
これが、ソニックガーデンがカイゼン型開発を行う理由です。
0 件のコメント:
コメントを投稿