NTTグループのソリューションガイド
月刊ビジネスコミュニケーションによるエキスパートブログ
HOME | ABOUT |
atom rss2.0

« previous next »

モジュラーか、インテグラルか?

2006.07.03|オープンソースソフトウェア このエントリーをはてなブックマークに追加Yahoo!ブックマークに登録この記事をクリップ!BuzzurlにブックマークBuzzurlにブックマーク

ふとしたきっかけで、昨夏に読んだMIT教授Charles H. Fineの記事を思い出した。「Are You Modular or Integral? -- Be Sure Your Supply Chain Knows」がそれである。ここからはこの記事を引用し、解説を加えながら紹介していこう。

製品アーキテクチャには大きく分けて『すり合わせ(インテグラル)型』すなわち部品設計を相互調整することにより製品毎に最適設計して製品全体の性能を出す方式と、『組み合わせ(モジュラー)型』すなわち部品間のインタフェースを標準化して、各部品を寄せ集めて多様な製品を作る方式がある。さて、記事を見ていこう。

「思い返せば90年代、DaimlerBenzとChryslerはそれぞれ元気だった。Chryslerはモジュラー型のアーキテクチャだ。サプライヤが技術革新に対して裁量の余地を与えられ、自律的に動けるようにしたモジュラー化である。その特長は、短期間設計、多数のサプライヤによるアウトソーシン グ、サプライヤ間でのインターオペラビリティ、それに、サプライヤを用いた良い意味でのコスト削減である。サプライチェーンの強化により自社はデザインにフォーカスし、魅力的なピックアップトラックやSUVで増収増益を得た。」

「一方、DaimlerBenzはインテグラル型のアーキテクチャだ。サプライヤのエンジニアと自社のエンジニアが顔をつき合わせて、完璧さとハンドメイ ドなこだわりを追及した。また、日本製の低価格高級車に対抗するために、ジャストインタイムやカイゼンを取り入れ、高級車をスピーディに生産することによ り増収増益を得た。」

解説を加えると、DaimlerBenzとChryslerはグローバル時代の生き残りをかけ1998年に対等合併したが、その途端に地獄を見ることになった。官僚主義的で格式高いDaimlerBenzと、奔放で冒険好きなChrysler。独・米を代表する二つの自動車メーカーが互いに足りないとこ ろを補い合うならば両社の相性は最高だと思われていたのだが。。。

「そもそも両社のビジネスモデルはまったく正反対であり、まさに水と油であった。Chryslerが骨の髄までコストを削減すれば、 DaimlerBenzは金に糸目をつけずに最高のラグジュアリーを追求する。Chryslerが重要な開発を世界に分散するサプライヤの自由裁量に任せてアウトソースすれば、DaimlerBenzはシュツットガルトの閉鎖地域でサプライヤと一体となって細部にこだわって最高の品質を追求するといった具合だ。つまり、Clayton Christensenの言葉で言えば、価値基準とプロセスがまったく違っているのだ。Claytonに言わせれば、優れた価値基準とプロセスをもつ Chryslerの独立性を残し、そこにDaimlerBenzの優れたリソースを注入すればよかったのにということになる。」

結果的には組織としての機能不全に陥ってしまった。まず、Chrysler部門が失速し58億ドルの損失と十数万人のレイオフ、期待されたジョイントプロジェクトのクロスファイアはまったく売れなかった。その後、クライスラーが何とかもち直すと、今度はメルセデス部門が不振に陥り、2005年12月期決算 でついに赤字に転落してしまった。まさに十字砲火(クロスファイア)を自ら浴びてしまった感がある。

「このことから得られた教訓は、コストや品質や顧客サービスが極限まで求められる競争環境においては、製品アーキテクチャとサプライチェーンアーキテクチャの整合性が成功を左右する大きな要因の一つとなるということだ。Chryslerはモジュラーなサプライチェーンでモジュラーな製品開発をやっていた ので成功していたのだ。DaimlerBenzはインテグラルなサプライチェーンでインテグラルな製品開発をやっていたので成功していたのだ。なのに、こ れらを融合させようとして自己崩壊してしまった。」

「では他の企業はどうだろう。Dellはモジュラーの代表格。Toyotaはインテグラルだ。Nokiaは、ハードウェア・コアとソフトウェアはモジュ ラーにしてアウトソースし、顧客満足度のキーエレメントとなるファッションデザインと、サイズや電力消費に関するコンポーネントはインテグラルなサプライ チェーンを使ってインテグラルに開発している。」

「整合性のとれたアーキテクチャをもって成功している企業が、そのアーキテクチャを変革しようという誘惑に駆られるときが時々ある。1990年代、 Ciscoの低価格攻勢にさらされたLucentとNortelがこの誘惑の犠牲となった。モジュラーアーキテクチャによって低価格を実現したCisco を見習い、LucentとNortelは社内の工場と整備を売却し、サプライチェーンをアウトソースに変えた。しかし、製品開発も一緒にモジュラーに変え ることをしなかったために失敗し、2000年からの長期的なテレコム市場の不況の中で喘いでいる。」

「一方、Ciscoは不況の中でも元気である。サプライチェーンと製品アーキテクチャの整合性に対する周到な戦略をもっているのが一つの理由かもしれない。Ciscoは3つのビジネスラインをもっており、コンシューマ向けにはDellのようなモジュラー、売上の65%を稼ぐ法人向けルーターはNokia のようなハイブリッド、電話会社向けのカスタムデザインはハンドメイドなFerrarisのようなインテグラルなのである。」

さて、引用と解説はここまでにして、振り返って日本の状況を見てみよう。昔は電電公社においてDIPSというシステム基盤を日立・NEC・富士通と共同開発しながら、同時並行的にその上で業務アプリを開発していた。しかも欧米に比べて要求条件の極めて厳しい日本の大規模な業務システムをインテグラルで築き上げてきたのである。

ところが1990年代以降はパラダイムシフトに呑み込まれて、Sun、Oracle、SAP、Microsoftなどのモジュラーなサプライチェーンを使 わざるを得なくなった。それにもかかわらず、顧客の要求条件の厳しさは同じで、かつ、システム開発も今までどおりのインテグラルであったため、散々苦労してきたと言える。

一般的に日本の企業全般に言えることだが、Ciscoのようにサプライチェーンとシステム開発のアーキテクチャの整合性に関して周到な戦略が必要ではなかろうか。オープンソースはインテグラルか、モジュラーか。少なくとも我々にとっては、中身まで読みこなしたPostgreSQLはインテグラルであり、同 じOSSとはいえMySQLはモジュラーである。つまり、オープンソースは両方の性質をもっているので、アーキテクチャの整合性に関して多様な戦略を可能 にしていると言えるのである。

Latest