今回は、OSSと相性の悪い「
日式的、垂直統合型事業モデルの問題」の分析と、それに某弊部会が度のように対応しているか？ついて言及したいと思います。
＜アウトライン＞
- 垂直統合型事業モデルが続く理由
- サプライ・サイドとデマンド・サイド
- 垂直統合下での市場最大化
- 事業部門と機能部門
- 責任の一本化
- 垂直統合型事業モデルの問題
- 弊部会の取組
- 参考
＜垂直統合型事業モデルが続く理由＞
「
垂直統合型事業」モデルも、Appleなど成功しているケースもありますが、差別化可能なコンテンツを持っている必要があるかと思います。通常そのような企業は限られるので、多くの場合は、「
水平分業型事業」モデルを選択することになるかと思います。しかし、なかなかそうはなりません、何故でしょうか？
＜サプライ・サイドとデマンド・サイド＞
端的に、「
サプライ・サイドのマネタイズに問題があるから垂直統合になる。」と言える気がします。これは、デマンド・サイドのイニシアティブが大き過ぎ、サプライヤーが買い叩かれるためです。
オープン・アーキテクチャの論文（経営戦略としてのオープン・アークテクチャ）でもサプライ・サイドとデマンド・サイドに「緊張関係」が発生すると指摘されており、どちらが主導権を握るか？は、プロダクト特性によって決まると言及されています。具体的には、モジュール化が要素技術単体で可能か？複合化で可能か？に依存する。ということのようです。
日本において、デマンド・サイドのイニシアティブが大きくなり過ぎるのは、日本が過当競争下に陥っているからと言えるかもしれません。
＜垂直統合環境下での市場最大化＞
「
日本の産業は、その多くが、垂直統合と汎用汎化を組み合わせたもの」であるらしいですが、これは、垂直統合下での狭い市場の中でコスト・パフォーマンスを最大化するために、専用特化できず、汎用汎化に進んだためではないか？と考えます。
＜事業部門と機能部門＞
この問題は、事業部門（≒ デマンド・サイド）と機能部門（≒ サプライ・サイド）の間でも見ることが出来ます。この問題が解決しないのはセクショナリズムを解決できず、全体最適化ができないコトとホボ「≒」かもしれません。
＜責任の一本化＞
また、これ以外にも、この根本は、「
責任の一本化」＝「
責任回避」と言う商習慣に起因しているような気もします。これにより、垂直統合型事業モデルに加え、多重請負構造という良く解らない構造が産まれます（ただし、SES・派遣は人員的には要素単体でマネタイズ可能なプロダクトを持っていないので、ココでのサプライ・サイドには含めない）。
＜垂直統合型事業モデルの問題＞
＜生産性が低い＞
垂直統合型事業モデルでは、スタックできないので、多能工化が過ぎ、専門性が低下します（ ≒ 前述の汎用汎化）。これにより、大したことできなくなり（誰でも出来るようなことしか出来なくなり）、生産性も下がり、更にヒューマンレイバーのエリミネートは難しくなるどころか、それ自体が売り物にするしかなくなります。
＜マーケティングできない＞
垂直統合下で「ルート営業」・「アカウント営業」でモノを売るということに慣れてしまっていると、「
水平分業」に移行しようとした際、マーケットのセグメントやターゲットがなんなのか解らない状態で、マーケティング・プロモーションをしてしまうことが多くなります。これにより、売れるプロダクトを作ることが難しくなりますし、昨今、言われている「
協創」なども難しくなると思います。
＜弊部会の取組＞
今回は、「
日式的、垂直統合型事業モデルの問題」＝「
サプライ・サイド、デマンド・サイドの両方の生産性が向上しない原因となっている」と、この問題の構造を以下のように分析しました。
＜サマリ＞
過当競争下にある。 → デマンドサイドが強い。 → 垂直統合型事業モデルの継続 → 汎用汎化（専用特化できない） → マーケット・インできず生産性も低い → 人員リンク・ビジネスが続く。
次回は、この問題の対応方法を具体化していこうと思います。以下の参考文献を参照すると、「
水平分業」の「
専用特化」と「
多売割費」の実現が解決になるかもしれません。昨今であれば、「
働き方改革」などが、これを後押しするかもしれません。
＜参考＞
Open COBOL Solution WG
OSSと「垂直統合型事業モデルのスタックしない問題」について。
