引き続き「
サプライサイド・デマンドサイド」シリーズをお送りしますが、前に「
ラインナップを揃える＆人員を動員するダケってのは厳しい。」というタイトルで、私のちょっとした認識を書かせて頂きました。
＜オープン・ソリューションも難しくなってきた？＞
よくよく考えると、昨今のサプライサイド（ベンダ側）、コモディティ化が過ぎているので、プロダクト化どころか、ソリューション化すら、ソコにパフォーマンス的な意味合いは殆ど無い気がしてきました。
要するに、
「売れそうなモノを選択して、”担ぐ。”と組織的に宣言しているダケだと、差別化要素はあまり無い。」
と言うような話です。
また、実際に聞いた話ですが、デマンドサイドに近い組織でも、OSSなどでプロダクトのスタックを組んだダケだと、「で？（構築したこれをどう使ったらイイんだろう？）」みたいな感じになるらしいです。
もうチョット言うと、
「OSSなのでソフトウェアにフィーは無いのはイイのだケド、実際に活用してマネタイズしようとしても、どう活用してイイかが解らない。」
みたいな話です。
そう考えると、
「
昨今のソフトウェアは、単純に機能が提供されればイイという話ではなくて、それをどう活用するかというトコロが難しくなってきて来ている。」
と言う気がします。
確かに、ストレージの機能なども多様化しています。
（NoSQL : KVS / DocumentDB / GraphDB / Column、Hadoop）
そして、その機能をどうしたら使いこなせるのか？
機能カットで見ると、難しくなってきている気がします。
組織的なスタックは下図の様に３～４層あります。
- ユーザ・レイヤ
- アプリケーション・レイヤ
- インフラ・レイヤ
- プロダクトの開発者、OSSのコミッタ
各レイヤで、どういう努力をするか？
戦略的な検討が必要かもしれませんが、
※ プロジェクト構造については
コチラや、
コチラを参照。
結局のところ、
「知識を得て各レイヤに向けたトランスレーションを行うだけならば、それは所謂一つのオーバーヘッドと言うヤツかも知れないので、ユーザー・サイドのプロジェクト型組織に参画してしまうのが最も効率が良い。」
と言う話にしかならないと思います。
...ソコで以下なんでしょうか？
しかし、そう考えると、協創（ユーザー・サイドのプロジェクト型組織に参画してしまうのが最も効率が良いのに、敢えてベンダ側に所属した上でプロジェクトに参画する形を採る）ってベンダ都合なのかも知れませんね。
再三にわたり、書いていますが、「日式はサプライサイドが75%、米国は30%以下」です。
＜プロダクトの布教活動も変わってきた？＞
また、なんだか、最近、企業が油を注ぐスタイルの布教活動やコミュニティはシュリンクしてきた感がありあます。これついては、
「企業がリリースしているオンライン・サポートに加え、StackOverflowとGitHub見れば大概のことは解決するので、プロダクトも機能単品というより、エコシステムの総合力と言う感じになってきたんじゃないでしょうか？」
なんて考えています。
もっと言うと、
「基本的なプロダクトはOSSに駆逐されつつありますが、そのOSSを開発する主体は、そのプロダクトを自社の事業・サービスに使用できる企業である気がします。それをOSSにする理由は、自社の事業・サービスのQCDの向上なんじゃないか？」
と思います。
https://twitter.com/repeatedly/status/1085322589298409472 そう考えると、私の使用している、.NET Coreですが、これは、今までのWindows＋Visual Studioのライセンス販売事業の販促的な意味合いも、引き続き、含まれている気がしますが、本丸は、Azureと言う事業・サービスの販促的な意味合いが強いんでしょうか。
サービス型の事業は、ここのトコロ、弊ブログで分析してきた、「サプライサイド」より優位な「デマンドサイド」により近い位置に立つことが出来るので、これが、全体的にイイ影響を与えているンじゃないか？と思っています。
そして、Azureでは、Visual Studio Code＋各種OSSが追加されているために、少々のことではコケない、強いエコシステムが形成されているように思います。
日式も、こんな感じになりたいですね。
（と言う事で、今日も頑張って行きましょう。）
Open COBOL Solution WG
サプライサイド戦線に異常あり。
