イノベーションへの解 第5章
イノベーションへの解:第5章 事業範囲を適切に定める (10)
製品の機能性と信頼性が顧客のニーズを十分満たしていない状況で圧倒的に優位に立つ企業は、独自の製品アーキテクチャを持ち、バリューチェーンの中で性能を制約するインターフェースをまたいで統合されている。
一方、機能性と信頼性が「十分以上」になり、代わってスピードとレスポンスが「不十分」な状況では、相互作用の方式がモジュール型アーキテクチャと業界標準によって定義されている特化型の専門企業が優位に立つ。
新市場型破壊の波が始まって間もない頃は、まだ製品が十分でないため、独自アーキテクチャを持つ統合型企業が最も成功する。その後、破壊者たちが数年かけて性能向上を遂げても、やがては間接費が低い特化型企業によるローエンド破壊によって攻撃される。
複数の市場階層に顧客を持つ企業は、こうした競争市場の変化を乗り切るのは難しい。市場の上位層と低位層を獲得する際には、まったく異なる戦略とビジネスモデルが求められるからである。この2つの顧客層を同時に、かつ適切な方法で追求するためには、複数の事業部門が必要になることが多い。
<参考文献>
クレイトン・クリステンセン (著), マイケル・ライナー (著) (2003)『イノベーションへの解:利益ある成長に向けて』翔泳社
イノベーションへの解:第5章 事業範囲を適切に定める (9)
「純粋な相互依存型アーキテクチャ」と「純粋なモジュール型アーキテクチャ」は連続体の両極をなしており、企業はこの両極間の任意の戦略を任意の時点で選択する可能性がある。
競争基盤が機能性と信頼性にある状況でモジュール型アーキテクチャによって事業を立ち上げると、モジュール式が支配的なアーキテクチャになるまで競争上大きな不利を被るが、必ずしも失敗するわけではない。
リーダー企業が独自アーキテクチャからくる信頼性、機能性での優位を基に競合企業を引き離したときは、アーキテクチャをモジュール化して公開し、低コストの組立能力によって市場拡大に寄与できる企業向けに、サブシステムをモジュールとして積極的に販売し始める必要がある。
破壊的イノベーションにおいても、独自アーキテクチャから事業を始め、競争基盤が変化したときにアーキテクチャを公開して、低コストの組立業者向けに主要なサブシステムを供給することは可能である。このような戦略をとる企業は、ニッチ・プレーヤーになったり、差別化できないコモディティの供給業者になったりすることを回避できる。
<参考文献>
クレイトン・クリステンセン (著), マイケル・ライナー (著) (2003)『イノベーションへの解:利益ある成長に向けて』翔泳社
イノベーションへの解:第5章 事業範囲を適切に定める (8)
費用もそれほどかからず得意な分野に集中できることから、モジュール型製品の価値を構成するサプライヤーとして、新成長事業を立ち上げるのは魅力的だ。しかし、破壊の初期段階ではモジュール化が技術上または競争上、可能でないことが多い。
企業が何かを外部調達するか、逆に何かを顧客に販売するためには、次の3つの条件が満たされていなければならない。
- 指定可能性:供給業者と顧客の両者が「構成要素のどの属性が製品システムの動作にとって重要で、どれがそうでないか」を識別できなければならない。
- 検証可能性:調達部品が条件を満たしているかどうかを検証するために、それらの属性を評価できなければならない。
- 予測可能性:サブシステムによって狙い通りの成果をあげるために、顧客はシステム全体の中でサブシステムがどのように相互作用するかを理解していなければならない。
この3つの条件が揃ってはじめて、効果的なモジュール型インターフェースとなる。製品の性能が十分でないとき、つまり企業が製品の性能を可能な限り高めるために非標準的な製品アーキテクチャにて新技術を用いて競争力を高めているときは、この条件は満たされないことが多い。もし複雑で補完的で予測不能な相互依存関係がシステム内にあるときには、単一組織の中にインターフェースを設けなければならない。
指定可能性、検証可能性、予測可能性が揃ったとき、複数の組織が距離を置きながら連携できるようになる。モジュール型インターフェースが確立すると、そのインターフェースに沿って産業の非統合化が起こる。
指定可能性、検証可能性、予測可能性が存在しない場合は、経営者による監督と調整が、調整メカニズムとして優れた機能を果たす。またモジュール化の条件が満たされない場合は、組織統合が重要となる。
<参考文献>
クレイトン・クリステンセン (著), マイケル・ライナー (著) (2003)『イノベーションへの解:利益ある成長に向けて』翔泳社
イノベーションへの解:第5章 事業範囲を適切に定める (7)
一般に技術改良の軌跡は、どの市場階層においても顧客の利用能力が向上するぺースを上回るため、「相互依存型アーキテクチャ&統合型企業」から「モジュール型アーキテクチャ&特化型企業」へと向かう。
顧客のニーズの変化は、図5-2で示すように比較的緩やかなペースで起こるが、ときには顧客が要求する機能性に非連続的な変化が生じ、顧客ニーズの変化を上方に押し上げることがある。この現象が発生すると、統合が競争優位の源である状況に逆戻りする。
図5-2. 顧客ニーズと競争基盤の変化
競争において、統合が優位となる地点と非統合が優位となる地点は、時とともに移動する。したがって、バリューチェーンの各段階をつなぐインターフェースをまたいで統合している企業は繁栄する。
<参考文献>
クレイトン・クリステンセン (著), マイケル・ライナー (著) (2003)『イノベーションへの解:利益ある成長に向けて』翔泳社
イノベーションへの解:第5章 事業範囲を適切に定める (6)
統合化からモジュール化への前進は、製品の改良が進んで顧客の要求を追い抜く度に繰り返される。そして「性能が十分ではない状況」に業界を支配していた独自システムや垂直統合企業は、「性能が十分である状況」では特化型企業に取って代わられていく。
統合は、ある時点では競争上不可欠だが、後には競争上の障害となる。モジュール化と特化を駆り立てるのは、以下の予測可能な因果的連鎖である。
- 技術改良のペースは顧客の利用能力を上回るため、ある時点では機能性や信頼性が十分でない製品も、やがては顧客の利用できるものを上回るようになる。
↓ - その結果、競争基盤が変化し、企業はそれまでとは異なる方法で競争することを強いられる。
↓ - 顧客が機能性や信頼性の向上に対して割増価格を支払う意志を失うにつれ、今度は顧客が求めるものを必要なときに与える能力を持つ供給業者が、利益を得るようになる。
↓ - 企業は競争圧力により「スピードと顧客ニーズへの対応性をできる限り高めること」を強いられると、相互依存型の独自仕様の製品アーキテクチャを、モジュール型に進化させることによって、この問題を解決する。
↓ - モジュール型を通じて産業の解体が実現し、一部の特化型企業が、かつて業界を支配していた統合型企業を打倒する。
性能向上の軌跡が各市場の各階層を通過するにつれて支配を弱め、それと同時にモジュール型のモデルが次第に支配的になっていく。アーキテクチャ戦略や統合戦略の有効性は「性能ギャップ」や「性能過剰」の状況に依存する。状況が再び変化すれば、戦略的アプローチもそれに合わせて変える必要がある。
<参考文献>
クレイトン・クリステンセン (著), マイケル・ライナー (著) (2003)『イノベーションへの解:利益ある成長に向けて』翔泳社
イノベーションへの解:第5章 事業範囲を適切に定める (5)
図5-1. 製品アーキテクチャと統合
図5-1の「性能が十分である状況(赤領域)」は、製品の機能性と信頼性があまりにも良くなり過ぎた「オーバーシューティング」という状態である。その状況では顧客は改良製品を喜んで受け入れるものの、割増価格を払ってまで購入する意志はない。
オーバーシューティングでは、機能性と信頼性に関するニーズを満たされてしまうと、顧客は「次に何が十分でないか」を定義し直すようになる。顧客はカスタマイゼーション、速度、利便性に関する新たなイノベーションの改良軌跡に沿った性能向上に対して、喜んで割増価格を支払うようになる。これが起こるとき、ある市場階層における競争の基盤が変わる。
図5-1に示すように、新たなイノベーションの改良軌跡上における競争圧力が、製品アーキテクチャの漸進的進化を押し進める。「性能が十分ではない状況(青領域)」ときには有利だった相互依存型の独自アーキテクチャが、「性能が十分である状況(赤領域)」ではモジュール型設計へと進化する。
モジュール型アーキテクチャは、個々のサブシステムの性能を高める上で全体を設計し直す必要がなく、新製品を早く市場に出すことができるため、「性能が十分である状況(赤領域)」において有利である。標準インターフェースはシステム性能に妥協を強いるが、「性能が十分である状況(赤領域)」では多少の機能性をあきらめる余裕がある。
モジュール型は独立した特化型の組織にも、部品やサブシステムの販売、購入、組立を可能とすることから、産業構造にも大きな影響を及ぼす。相互依存的型では、システムの主要要素のどれか一つを製造するために全ての要素を製造する必要があったのに対し、モジュール型では外部委託が可能になり、また一種類の構成要素を供給して利益を得ることもできる。
モジュール型のインターフェースは、最終的には融合して業界標準となる。これが起こると、企業はそれぞれの分野で選り抜きのサプライヤーから調達した部品をうまく組み合わせて、顧客の特定のニーズに巧みに応えられるようになる。そのような特化型企業が、統合型リーダーを破壊する。特化型企業は、それぞれの顧客が必要とする通りのものを迅速に提供することで競い合う。特化型の構造を持つために間接費が低く、割安価格でも利益をあげながら、ローエンドの顧客を摘み取ることができる。
<参考文献>
クレイトン・クリステンセン (著), マイケル・ライナー (著) (2003)『イノベーションへの解:利益ある成長に向けて』翔泳社
イノベーションへの解:第5章 事業範囲を適切に定める (4)
図5-1. 製品アーキテクチャと統合
製品の機能性と信頼性が、ある市場階層に属する顧客のニーズを満たすにはまだ十分でない「性能が十分ではない状況(青領域)」では、企業はできる限り優れた製品をつくることで競争しなければならない。競争では、独自仕様の相互依存型アーキテクチャを基に性能を最適化する企業に、大きな競争優位が約束される。
インターフェースの標準化が進むと、技術的に実現し得る最高のものから遠ざかってしまう。競争で遅れを取らないために、エンジニアは新製品を生み出すたびに性能ギャップを縮めようとする。利用可能な技術から最高の性能を引き出すために、システムの構成要素をますます効果的な方法で組み合わせようとする。
相互依存型の独自アーキテクチャで競争する企業は、統合型企業でなければならない。システムのどの構成部品を製造するにも、システム内の重要な部品の設計と製造をコントロールする必要があるからだ。
「性能が十分でない状況(青領域)」では、未熟な新技術が持続的向上のために採り入れられることが多い。新規参入企業がブレークスルー技術(画期的技術)の商品化に成功することがほとんどないのは、システムの他の構成要素にも変更を強いる相互依存関係が多すぎて、まったく新しい技術を組み込んだ有望な製品の商品化になかなかこぎ着けないからである。
参考:ブレークスルー技術と破壊的技術
- ブレークスルー技術とは「技術進歩の軌跡に持続的な影響を及ぼすもの」であり、破壊的技術とは「技術面での飛限的前進を伴わず、既存技術を破壊的ビジネスモデルという形にまとめたもの」である。
- ブレークスルー技術のほとんどが持続的な特性を持っており、製品内の他のサブシステムとの間には予測不能な相互依存関係がある。
- 持続的イノベーションの中には、年々行われる単純な漸進的改良(漸進的技術)と一足跳びに持続的軌跡を上っていくような劇的で画期的なもの(ブレークスルー技術)があるが、どちらも持続的な影響を及ぼすため、優良企業がほぼ必ず勝利を収める。
<参考文献>
クレイトン・クリステンセン (著), マイケル・ライナー (著) (2003)『イノベーションへの解:利益ある成長に向けて』翔泳社
イノベーションへの解:第5章 事業範囲を適切に定める (3)
製品の「アーキテクチャ(基本設計概念)」は、製品の構成要素とサブシステムを決定し、目標機能を実現するためにそれらがどのように相互作用する必要があるかを定義する。また、任意の2つの構成要素が組み合わさる境界面は「インターフェース」と呼ばれる。
一方の設計・製造方法が、もう一方の設計・製造方法に依存する状態のことを「相互依存型アーキテクチャ」という。あるインターフェイスを挟んで予測不能な相互依存性が存在する場合、組織はどちらか一方の構成要素を開発するために、同じ組織内で同時に両方の構成要素を開発しなければならない。
「相互依存型アーキテクチャ」は、それぞれの構成要素を最適な方法で設計・開発するため、機能面と信頼面での性能を最適化する。これに対して「モジュール型アーキテクチャ」は、あらゆる構成要素の絡み合いや機能が完壁に指定されている。モジュール型インターフェースでは、バリューチェーンの全構成要素または全段階にわたって、予測不能能な相互依存性が全く存在しない。「モジュール型アーキテクチャ」は誰が部品やサブシステムをつくるかを問わない代わりに、厳しい規格によってエンジニアに設計の自由を与えない。
純粋なモジュール型と相互依存型のアーキテクチャは、連続体の両極に位置し、ほとんどの製品がその両極間に位置している。そして製品アーキテクチャを競争状況に適合させる企業が、成功する可能性が最も高い。
<参考文献>
クレイトン・クリステンセン (著), マイケル・ライナー (著) (2003)『イノベーションへの解:利益ある成長に向けて』翔泳社
イノベーションへの解:第5章 事業範囲を適切に定める (2)
将来顧客が重要だと判断するであろうイノベーション領域において優位に立つためには、「今日何を習得し、将来何を習得する必要があるか」について「片づけるべき用事」をべースに検討する必要がある。
顧客の問題にとって何が「解決策」となるかは、図5-1に示した2つの状況、「性能が十分ではない状況(青領域)」と「性能が十分な状況(赤領域)」で異なる。「性能が十分な状況(赤領域)」では、外部委託による専門化や特化が有利である。
図5-1. 製品アーキテクチャと統合
<参考文献>
クレイトン・クリステンセン (著), マイケル・ライナー (著) (2003)『イノベーションへの解:利益ある成長に向けて』翔泳社