モックアップビジネスモデル

初期費用０円受託開発

　永和システムマネジメントさんが初期費用０円の受託開発をやっていることを、人づてに聞きました。この話を同僚の何人かに話したところ「こんなの出来る訳ない！」と口を揃えて言ってました。私の会社はＩＴゼネコン大手です。従来の「受託」ヒエラルキー構造でビジネスを行っていたため、このような新しいビジネスモデルに理解を示そうとしないのでしょう。しかし、私はこのビジネスモデルが生まれたこと自体が日本のソフトウェア業界が変化の兆しと捉えています。

モックアップビジネスのメリット

このビジネスモデルは、最初の試作品（モックアップ）を０円で開発し、その試作品を気に入った会社は、その後利用料を月額で払っていくという、いわゆるクラウド型のビジネスモデルです。このビジネスモデルは、通常の受託ビジネスモデルに比べ、以下のメリットがあります。

     １．利益率の向上

私が所属している部署はパッケージ提供型の箱売りビジネスですが、たんなる「受託」に比べると利益率が２～３倍以上に上がります。受託ビジネスの場合、赤字を抱え込むリスクはなくなりますが、「人月」あたりの利益額は一定となります（極論、「無能」なプログラマをできるだけ安く集めて、マネジメントでなんとかプロジェクトを完了させることが、最も利益率を上げる手法となります）。自前で企画から開発までをサービスとして提供すれば、どこかの会社に中抜きされることなく、高い利益率のビジネスを実現できます、また、このモデルの場合、お客さんを「囲い込み」しますので、利益の継続性という観点でも魅力です。

     ２．低コスト化の実現

通常受託の場合、開発言語やＯＳ・データベース等のミドルウェアは、お客の都合で決まります。そのため、様々な技術に対して人材教育・人材配置が必要となり、そのままコストとしてビジネスに乗っかります。モックアップビジネスモデルの場合、自社が得意とする開発言語とミドルウェア構成で試作品を作ってしまえば言い訳で、リソースの選択と集中が可能となり、開発コストを大幅に下げることが可能となります。さらに、一度開発した共通部品や各種基盤系フレームワークは、次のモックアップでもそのまま流用できるため、コスト低減だけでなく、納期短縮や製品品質の向上も実現できます。

    ３．開発者のモチベーション向上

試作品開発では、ＧＵＩから大枠の仕様を自社で決められるため、開発者のモチベーションは上がります。開発者の気持ちとしては、出来上がってからの仕様変更は苦痛そのものです。最初に試作品を作り切ってしまうことは、お客さんとのイメージの共有が簡単になるため、大きな仕様変更が発生しないことになります。さらに、今回のモデルの場合、仕様変更は月額に移行した段階で発生するため、「仕様変更しないと金払わんぞ、ゴラ！」という、よくあるお客さんの脅迫タイミングを奪うことが出来ます。

　このように、モックアップ型ビジネスモデルには上記のようなメリットがあるため、初期投資が「０円」でも採算があうのではと考えています。もっと言うと「０円」じゃないとダメです。「０円」という言葉はマーケティング的には絶大な効果を発揮します。だから５０００円じゃだめなんです。（「０円」の言葉の力については、「予想どおり不合理」にも詳しく書かれています。）

モックアップビジネスを成功させるポイント

そうは言ってもこの新しいビジネスモデルは、従来型の「人月」モデルに比べると、失敗するリスク顕在化します。私が考えるに、このモデルを成功させるためには、以下のポイントが重要だと思います。

　　 １．有能なデザイナーの投入

  受注を成功させるためには、試作品のデザイン性が最重要です。「痒いところに手が届く」という機能要求については、月額の段階で対応するようにして、モックアップ段階で訴求すべきは「見た目」になるはずです。そのため、優秀なデザイナーが必要となるのです。「ハイ・コンセプト「新しいこと」を考え出す人の時代」や、「デザイン思考が世界を変える―イノベーションを導く新しい考え方」にも書かれていますが、これからは感性の時代に突入します。そのため、優秀なデザイナーを社内で育成することが重要課題であると考えます。

２．再利用の徹底によるコスト削減

モックアップでは低コストでアジャイルに作り上げることが重要です。そのためにはプログラムを徹底的に再利用させるよう、共通フレームワークを拡充することがポイントとなるでしょう。モックアップ段階では、入社２、３年目の新人プログラマーと、優秀なデザイナーの組み合わせだけで開発できるくらいの、使いやすい部品ライブラリがあれば理想的なのではないかと思います。きっと、永和システムマネジメントさんの場合、開発言語はＲｕｂｙでアジャイルに開発しているのだろうと思いますので、この点で言うと問題は無いかと思われます。

３．創造性の追求（受託意識からの脱却）

　受託開発の場合、製品の魅力が乏しいと感じられても「お客さんが言ったんだから、そのままやっておけばいい」という、一種の逃げが許されたりもします。しかし、自前でサービスを提供するということは、常に創造的であることを要求されます。本当に使いやすいユーザインタフェース、創造的な機能を創り出せる「センス」は、誰しもが持っているものではないというのが、私の持論です。魅力的なユーザインタフェースを想像すること自体、アーティストと同じ活動だと考えます。なので、そのような人材がキーマンとして社内にいるかいないかがポイントになると考えています。 

イノベーションのジレンマ

最近は、Ｎさんも赤字体質に苦しんでいる訳で、インドや中国の買収されるなんてことも現実味を帯びている状況です。今までのような受託ヒエラルキーの構造で、同じように受注できればいいのですが、クラウドの登場により市場価格が急速に押し下がっている状況を見ると、そんな大金をソフトウェアに出せるお客さんがどれだけいるか疑問です。日本のソフトウェア業界において、クラウドはまさにイノベーションのジレンマです。デジタルカメラを自社で開発しておきながら、フィルムビジネスの急速な落ち込みに対応できず、コダックはあえなく潰れました。今、日本中のＩＴ企業がクラウドを進めていますが、まず自らの仕事のやり方を見直さない限り、コダックの二の舞になってしまってしまうと私は考えます。

ニーズをシーズでウォンツに！

ビジネスモデルって何やねん？

５、６年前くらい前に、会社でビジネスモデル特許を書けという至極あいまいな業務命令が私に下りました。技術特許については、それまでにも何件か出願依頼していましたので、十分理解していましたが、「ビジネスモデル特許」については、一種の「ハイパーメディア」なにがし的な胡散臭さが感じられていたため、意識的に避けていました。が、「ハイパービジネスモデルは胡散臭いのでちょっと。。」なんて、サラリーマンとして上司に対して言えないため、教育嫌いな私ですが、「ビジネスモデル」関連の社内教育を探し出して、理解を深めようとした訳です。

さて、その「ビジネスモデルなにがし」の社内教育に出向いてみると、片手に携帯よろしくノートパソコンに向かっている「チョイワル」な壮年男性が講師の席に座っておられました。周りの受講生は、その「チョイワル」講師をまるで有名人を伺うかのように、興味津々に見つめていたので、自分がえらく場違いな場所に来てしまったと後悔していたのを覚えています。講義を進めて行くと、著作「コンサルタントの質問力」の紹介がありました。その方がコンサルタント業界では有名な野口吉昭さんであることが初めて分かりました。

ニーズとシーズでウォンツを！

講義の内容は当初期待していた「ビジネスモデル特許」とは全く関係がないものでしたが、オフィス用品販売「アスクル」や、大田区を中心にお弁当を販売している「玉子屋」等を事例に、様々な業態でのビジネスモデルを分析するという、知的欲求を満たすとても有意義な講義内容でした。特に私が感銘を受けたのは、「新たなビジネスモデルを創出する過程において、ニーズとシーズでウォンツすることが必要」という話です。

ニーズはいわゆるお客さんの声。具体的ではあるが、視野が狭く、短絡的な内容が多いです。それは決して本当に欲しいモノ、いわゆる「ウォンツ」ではない。スティーブ・ジョブスは「客は本当に欲しいものを知らない」と言っていたとか。だけど、お客の誰もが知らない「ウォンツ」を創り出すなんて、簡単には出来ない。でも、社内のどこかにあるシーズ（技術）を最大限に活用すれば、「ニーズ」を「ウォンツ」に変えることが出来るという話でした。

iPhoneが出来上がるまで

「スティーブ・ジョブス」でiPhoneが世界中で圧倒的な驚きを持ってリリースするまでの話を読んだとき、まさに「ニーズをシーズでウォンツに！」のケースに全く以て当てはまるなと感心しました。iPodが世の中を席巻していた頃、iPodを脅かすのはウォークマンではなく携帯電話であるとAppleは考えていました。デジタルカメラがカメラ付き携帯電話の登場により販売が落ち込む様を見ていたので、危機感を強く持っていたのでしょう。さて、AppleはMotorolaと共同でIPod付き携帯電話を開発し販売しました。しかし、これは大失敗に終わりました。携帯にiPodが内蔵した、「ニーズ」をそのまま具現化した「だけ」の製品だったからです。特にデザインがしょぼかったらしく、「スティーブ・ジョブス」の本の中でも糞味噌にこき下ろしていました。

ここで、Appleは既に開発を進めていたタブレット技術に目を付けます(iPhoneより先に、iPadを開発しようとしていたというのが面白い)。このマルチタッチ機能を「シーズ」として組み合わせ、徹底的にブラッシュアップを重ねた結果、まさにお客の誰もが想像もつかないようなiPhoneという「ウォンツ」が創造された訳です。

「現場」はフィールドだけじゃない

さて、私の仕事はソフトウェア開発なので、それに立ち戻って話をします。日本のソフトウェア業界に働いている人は必ずこの言葉を聴いたことがあると思います。「お客様の現場に出向いてお客の話を良く聞け！」。この言葉は半分は正しいですが、半分は間違いです。お客さんが欲しいモノを提供するためには、お客さんの現場に出向いて「ニーズ」を聞くことは重要ですが、それだけでは本当にウォンツなモノは作れない。「シーズ」は常に開発現場に落ちている訳で、開発現場にも同じように、いや、それ以上に出向かないと、本当に売れるウォンツな商品は出来上がらないと思う訳です。これから日本ではモノを作ったら当たり前のように売れるという時代じゃありません。客を感動させ、ワクワクさせる「ウォンツ」なモノを作るためには、やはり「ニーズ」と「シーズ」を繰り返し組み合わせながら、新たな「ウォンツ」を作り上げる思考パターンが必要とされるのでしょう。

この話は今週の重役向けスピーチのネタです。当初は（http://blog.livedoor.jp/kazu_fujisawa/archives/25610490.html）を元にアレンジして、「ソフトウェア業界における少子化問題を考える」を用意したのですが、「無駄に炎上させてもしょうがないだろう」という上司判断により、今回の話のネタを日曜夕方に書き下している訳です。上司の命令を従順に従う私こそサラリーマンエンジニア。