オープンイノベーション戦略の問題点を書いてみる。
前に書いた、
富士通の戦略は、試食でお昼代を浮かすようなもの。ＮＥＣ，ＮＴＴの戦略は世界征服！
http://blog.goo.ne.jp/xmldtp/e/01e0551c91aa0d191c15031916506fcc
は分かりにくいので、もう一度、書き直したほうがいいかな・・・と思っていたら、
自社製データベースにPostgreSQLを取り込んだ富士通の戦略とは？
http://software.fujitsu.com/jp/middleware/featurestory/2015postgre_intro/?mwn150526
なんていう記事が出ていたので、これをもとに、この前書いた上記ブログエントリーに挙げた
オープンイノベーションの問題点を書いてみよう
上記ブログでは、オープンイノベーションといっても、ただ
「他の人と協業して、その成果を取り入れ、一緒に研究開発していく」
だと、それは、
「お昼お金ない！じゃあ、スーパーに試食して、ただで食べてお昼代うかそう！」
っていうのとおなじで、戦略はやっぱ、決めないと・・・
（お昼代はちゃんと払う。スーパーには何を買いに行くか決めていく）
というお話でした。
で、戦略無きオープンイノベーションの問題点として、こんなのを挙げた
（１）他者を入れて開発するには、情報を開示する必要がある。情報を開示するということは、他社に真似られる可能性もあるということ。開発技術をオープンにして、自社は利益を上げられるのか？
（２）自社がコントロールできない。
（３）オープンイノベーションを進めると、他者のアイデアや資源が利用できるので、技術が促進できるという発想は、異業種交流会と一緒。買い手不在で、結局、売れない。
（４）そもそも、オープンイノベーションは「自分が開発できないところは、オープンにすれば他人が開発してくれるだろう」という甘い期待の上に成り立っている。その期待は、スーパーで試食を食べまくっておなかをいっぱいにしてお昼代を浮かそうと考えるようなもの。試食がそんなに都合よく出ているわけがない。
以下、今回の富士通の「Symfoware」の例で上記４つを考えてみたい。
ただ、記事の情報が、オープンでなく、肝心なところが書いていないので、わかんないところは、推測とかが入る。
なので、あくまでも雰囲気的な世間話としてみてほしい。
■オープンイノベーションの問題点（１）情報を開示して、自社は利益をあげられるか？
今回はっきり書いていないけど、まさか、「Symfoware」の中身すべてをオープンソースにする
というわけではないと思う。たぶんPostgreSQLと同じインターフェースにするだけだと思う。
この場合、上記のケースとは違い、「オープンなインターフェースに合わせ、内部はブラックボックス」
というオープンクローズ戦略なんだけど、実はこれは、オープンクローズ戦略の最悪の方法
「他社の安いシステムのインターフェースに自社のインターフェースを合わせる」
というやり方なんですよ・・・
（オープンクローズ戦略は、
・独自インターフェース、
・自社インターフェースに他社をあわさせる
・他社インターフェースに自社が合わせる
の３とおりのインターフェースのあわせ方が考えられ、さらに他社の中に
・標準に合わせる
・安い商品（＝無料含む）に合わせる
・高い商品に合わせる
の３とおりがある）
PostgreSQLにあわせたら、今までの客が、PostgreSQLにいってしまう可能性がでるでしょ。
逆にPostgreSQLは安いから使ってるんだから、その客がSymfowareが良かったとしても、
買ってくれる可能性は低くなる。この差＝顧客流出が起こりやすいってことなんだ。
なので、よくない・・・んだけど、その話はその話、オープンイノベーションの問題点は議論して
いないので、それを議論する為に、かりに「Symfoware」の中身を開示してもよいと経営者が判断
した場合、どうなるか・・・
「Symfoware」の中身を開示しないなら、PostgreSQLの人たちが何かしてくれる・・・
ということは期待できない。中身分からないんだから。ということは、自分たちの問題（バグとか）
は自分たちで・・ということになり、メリットは無い
「Symfoware」の中身を開示してしまうと、オープンソースで似たようなものを作られる可能性
がある・それどころか、「Symfoware」の機能をPostgreSQLにも、入れようよ！となるかもしれない。
そうすると、自らオープンソースを競合に持ってしまう・・・ので、自社にとって利益にならない
・・・あまり利益が上がりそうな戦略ではない
■オープンイノベーションの問題点（２）自社がコントロールできない。
PostgreSQLの開発方針に引きずられる。PostgreSQLに脆弱性があったら、アップデートしないと
いけないし、PostgreSQLが大きく変わったら・・・「Symfoware」もなんらかの対応が必要になるよね
PostgreSQLがEOLのバージョンを勝手に設定したり、変更したら・・社内体制も・・・
一方、「Symfoware」としては、自社で行った機能修正をcontributionしたい。
じゃないと、自分たちで保守しないといけないからね・・・
だけど、富士通の開発パワーでつくったものをばーんとcontributionされちゃうと、
PostgreSQLのコミッターの人はこまるはず
・・・いや、こんなに持ち込まれても（＾＾；）みたいな・・
小さい範囲で、でも、常時修正・コミットしたいんだよね（＝CI)、コミッター側は。
→回帰テストは、自動的にやってくれる体制が出来ている
でも、商用の場合は、いっぺんにばーんとバージョンアップしたい
→回帰テストの手間なんか考えると、リリースはまとめて！
で、どっちが優先されるかというと、もちろん、PostgreSQL！
■オープンイノベーションの問題点（３）異業種交流会と一緒。買い手不在で、結局、売れない
作り手から見ると、PostgreSQLとSymfowareは同じDB。共通部分は一緒にあるから、
協業するといいよね！になるけど、
買い手からみると
PostgreSQL：安さ優先。
Symfoware：価格以外を重視
で、お客さんが違う。求めているものも違う。これを２つあわせると・・・
両方の市場にリーチ！って売り手は考えるけど、
買い手からみると、中途半端な商品にみえて、結局、売れない。
■オープンイノベーションの問題点（４）他人が開発してくれる→そんなに都合よくは・・・
（３）に示したとおり、PostgreSQLとSymfowareは顧客が違うので、要望が違う。
なので、Symfowareで開発してほしいところをPostgreSQLが開発してくれるとは・・限らない。
そうすると、Symfowareの要望は自社で開発して・・・
でも、（２）で示したように、それをPostgreSQLに入れてよ！といわれても、
有る程度は入れてくれるかもしれないけど、コミュニティも迷惑！
となると、自社で管理しなきゃいけない。
一方、PostgreSQLはPostgreSQLで、勝手に発展していくだろう。
それに、自社管理分を追随させていかなきゃいけない・・手間がかかる・・・
・・・う～ん、自社開発で完結したほうが、楽かもお～
■では、どうするのがよかった？
マーケティング的に言えば、
・PostgreSQLからSymfowareへアクセスできるドライバを作り、そのソースをGithubで公開する
→ただし、サポートをつけて、商用版も用意する
というのが、一番。こうなると
・Symfowareのお客さんは、何も変更ない
・PostgreSQLのお客さんは、変換ドライバ分遅いけど、使える→遅いから、乗り換えてくれる可能性もあり
・この変換ドライバは自分たちで作る＝自分たちがコミッタ＝自分たちの都合で開発できる
ということで、メリットは大きい。ただ、これだと、開発する人には面白みが無いというか、オープンソフトに貢献している意義がないし、上の人から見ると、オープンイノベーションぽくないので、却下なんでしょうね・・
前に書いた、
富士通の戦略は、試食でお昼代を浮かすようなもの。ＮＥＣ，ＮＴＴの戦略は世界征服！
http://blog.goo.ne.jp/xmldtp/e/01e0551c91aa0d191c15031916506fcc
は分かりにくいので、もう一度、書き直したほうがいいかな・・・と思っていたら、
自社製データベースにPostgreSQLを取り込んだ富士通の戦略とは？
http://software.fujitsu.com/jp/middleware/featurestory/2015postgre_intro/?mwn150526
なんていう記事が出ていたので、これをもとに、この前書いた上記ブログエントリーに挙げた
オープンイノベーションの問題点を書いてみよう
上記ブログでは、オープンイノベーションといっても、ただ
「他の人と協業して、その成果を取り入れ、一緒に研究開発していく」
だと、それは、
「お昼お金ない！じゃあ、スーパーに試食して、ただで食べてお昼代うかそう！」
っていうのとおなじで、戦略はやっぱ、決めないと・・・
（お昼代はちゃんと払う。スーパーには何を買いに行くか決めていく）
というお話でした。
で、戦略無きオープンイノベーションの問題点として、こんなのを挙げた
（１）他者を入れて開発するには、情報を開示する必要がある。情報を開示するということは、他社に真似られる可能性もあるということ。開発技術をオープンにして、自社は利益を上げられるのか？
（２）自社がコントロールできない。
（３）オープンイノベーションを進めると、他者のアイデアや資源が利用できるので、技術が促進できるという発想は、異業種交流会と一緒。買い手不在で、結局、売れない。
（４）そもそも、オープンイノベーションは「自分が開発できないところは、オープンにすれば他人が開発してくれるだろう」という甘い期待の上に成り立っている。その期待は、スーパーで試食を食べまくっておなかをいっぱいにしてお昼代を浮かそうと考えるようなもの。試食がそんなに都合よく出ているわけがない。
以下、今回の富士通の「Symfoware」の例で上記４つを考えてみたい。
ただ、記事の情報が、オープンでなく、肝心なところが書いていないので、わかんないところは、推測とかが入る。
なので、あくまでも雰囲気的な世間話としてみてほしい。
■オープンイノベーションの問題点（１）情報を開示して、自社は利益をあげられるか？
今回はっきり書いていないけど、まさか、「Symfoware」の中身すべてをオープンソースにする
というわけではないと思う。たぶんPostgreSQLと同じインターフェースにするだけだと思う。
この場合、上記のケースとは違い、「オープンなインターフェースに合わせ、内部はブラックボックス」
というオープンクローズ戦略なんだけど、実はこれは、オープンクローズ戦略の最悪の方法
「他社の安いシステムのインターフェースに自社のインターフェースを合わせる」
というやり方なんですよ・・・
（オープンクローズ戦略は、
・独自インターフェース、
・自社インターフェースに他社をあわさせる
・他社インターフェースに自社が合わせる
の３とおりのインターフェースのあわせ方が考えられ、さらに他社の中に
・標準に合わせる
・安い商品（＝無料含む）に合わせる
・高い商品に合わせる
の３とおりがある）
PostgreSQLにあわせたら、今までの客が、PostgreSQLにいってしまう可能性がでるでしょ。
逆にPostgreSQLは安いから使ってるんだから、その客がSymfowareが良かったとしても、
買ってくれる可能性は低くなる。この差＝顧客流出が起こりやすいってことなんだ。
なので、よくない・・・んだけど、その話はその話、オープンイノベーションの問題点は議論して
いないので、それを議論する為に、かりに「Symfoware」の中身を開示してもよいと経営者が判断
した場合、どうなるか・・・
「Symfoware」の中身を開示しないなら、PostgreSQLの人たちが何かしてくれる・・・
ということは期待できない。中身分からないんだから。ということは、自分たちの問題（バグとか）
は自分たちで・・ということになり、メリットは無い
「Symfoware」の中身を開示してしまうと、オープンソースで似たようなものを作られる可能性
がある・それどころか、「Symfoware」の機能をPostgreSQLにも、入れようよ！となるかもしれない。
そうすると、自らオープンソースを競合に持ってしまう・・・ので、自社にとって利益にならない
・・・あまり利益が上がりそうな戦略ではない
■オープンイノベーションの問題点（２）自社がコントロールできない。
PostgreSQLの開発方針に引きずられる。PostgreSQLに脆弱性があったら、アップデートしないと
いけないし、PostgreSQLが大きく変わったら・・・「Symfoware」もなんらかの対応が必要になるよね
PostgreSQLがEOLのバージョンを勝手に設定したり、変更したら・・社内体制も・・・
一方、「Symfoware」としては、自社で行った機能修正をcontributionしたい。
じゃないと、自分たちで保守しないといけないからね・・・
だけど、富士通の開発パワーでつくったものをばーんとcontributionされちゃうと、
PostgreSQLのコミッターの人はこまるはず
・・・いや、こんなに持ち込まれても（＾＾；）みたいな・・
小さい範囲で、でも、常時修正・コミットしたいんだよね（＝CI)、コミッター側は。
→回帰テストは、自動的にやってくれる体制が出来ている
でも、商用の場合は、いっぺんにばーんとバージョンアップしたい
→回帰テストの手間なんか考えると、リリースはまとめて！
で、どっちが優先されるかというと、もちろん、PostgreSQL！
■オープンイノベーションの問題点（３）異業種交流会と一緒。買い手不在で、結局、売れない
作り手から見ると、PostgreSQLとSymfowareは同じDB。共通部分は一緒にあるから、
協業するといいよね！になるけど、
買い手からみると
PostgreSQL：安さ優先。
Symfoware：価格以外を重視
で、お客さんが違う。求めているものも違う。これを２つあわせると・・・
両方の市場にリーチ！って売り手は考えるけど、
買い手からみると、中途半端な商品にみえて、結局、売れない。
■オープンイノベーションの問題点（４）他人が開発してくれる→そんなに都合よくは・・・
（３）に示したとおり、PostgreSQLとSymfowareは顧客が違うので、要望が違う。
なので、Symfowareで開発してほしいところをPostgreSQLが開発してくれるとは・・限らない。
そうすると、Symfowareの要望は自社で開発して・・・
でも、（２）で示したように、それをPostgreSQLに入れてよ！といわれても、
有る程度は入れてくれるかもしれないけど、コミュニティも迷惑！
となると、自社で管理しなきゃいけない。
一方、PostgreSQLはPostgreSQLで、勝手に発展していくだろう。
それに、自社管理分を追随させていかなきゃいけない・・手間がかかる・・・
・・・う～ん、自社開発で完結したほうが、楽かもお～
■では、どうするのがよかった？
マーケティング的に言えば、
・PostgreSQLからSymfowareへアクセスできるドライバを作り、そのソースをGithubで公開する
→ただし、サポートをつけて、商用版も用意する
というのが、一番。こうなると
・Symfowareのお客さんは、何も変更ない
・PostgreSQLのお客さんは、変換ドライバ分遅いけど、使える→遅いから、乗り換えてくれる可能性もあり
・この変換ドライバは自分たちで作る＝自分たちがコミッタ＝自分たちの都合で開発できる
ということで、メリットは大きい。ただ、これだと、開発する人には面白みが無いというか、オープンソフトに貢献している意義がないし、上の人から見ると、オープンイノベーションぽくないので、却下なんでしょうね・・
結局、人事院のシステムって、どうなったの？と思ったら、
このページにきれいにまとまっていた。
つぶやき電子政府情報（2014年8月17日）：人事・給与システムと行政改革に踏み込めない電子政府
http://blog.goo.ne.jp/egovblog/e/37f52e2f2fbac28c0b954a47afa8a260
今となっては、「何でこんなことしたんだろう？」だけど、
当時は、そういう流れだったんだよね
全社的にシステムを集中させるという・・・
生物も、（ロボットみたいに）合体していくより分化して進化するけど、
集中ではなく、分化したほうが、環境には適合しやすい。
EAという、集中させることを考えたのが、間違いだったんだよね・・
そういう意味では、仕事の標準化というのも難しい。
各政府ごとにシステムを持つとコスト高っていうのは、
昔は回帰テストを今ほどやらなかったからの話で、
回帰テストは開発よりもはるかにコストが高く、
回帰テストはソースが集中しているほうが修正回数もテスト工数も大きくなるから、
ソースを集中させたほうが、コスト高になるんだよね・・・
・・・当時は、わからなかった・・・
このページにきれいにまとまっていた。
つぶやき電子政府情報（2014年8月17日）：人事・給与システムと行政改革に踏み込めない電子政府
http://blog.goo.ne.jp/egovblog/e/37f52e2f2fbac28c0b954a47afa8a260
今となっては、「何でこんなことしたんだろう？」だけど、
当時は、そういう流れだったんだよね
全社的にシステムを集中させるという・・・
生物も、（ロボットみたいに）合体していくより分化して進化するけど、
集中ではなく、分化したほうが、環境には適合しやすい。
EAという、集中させることを考えたのが、間違いだったんだよね・・
そういう意味では、仕事の標準化というのも難しい。
各政府ごとにシステムを持つとコスト高っていうのは、
昔は回帰テストを今ほどやらなかったからの話で、
回帰テストは開発よりもはるかにコストが高く、
回帰テストはソースが集中しているほうが修正回数もテスト工数も大きくなるから、
ソースを集中させたほうが、コスト高になるんだよね・・・
・・・当時は、わからなかった・・・
アクセス
トータル
ランキング
