モジュラーシステムは、さまざまな方法で構成可能なビルディングブロックの集合体であり、さまざまな顧客ニーズに対応するものです。新しい目的を果たすために、あるいは何らかの面でパフォーマンスを向上させるために、いくつかのモジュールは時間が経つと開発が行われます。
モジュラー化では製品全体に典型的な影響を与えることなく、モジュール内で最適化とコスト削減を行うことができ、うまくいけば、顧客価値を下げることなく行うことができます。多くの企業では、製品の複雑さを軽減したり、ETO(受注開発)ではなくCTO（受注組合せ生産）で顧客の注文プロセスを効率化したりするための手段としてモジュラー化を利用しています。
上手くいけば、このようなシステムから大きなベネフィットを得ることが可能です。さらに、製品に関連する作業を行うすべての人が恩恵を受けることができます。最も明白なメリットは開発の中にあります。エンジニアが設計やメンテナンスを行う部品数は今よりも少なくなるでしょう。さらにこのようなメリットは、販売からサプライチェーンを経て、アフターマーケットに至るまでのバリューチェーン全体で感じることが出来るでしょう。
モジュラーシステムには素晴らしい例がある一方で、効率性の一側面に焦点を当て、他の側面を無視したモジュラーシステムなど、悪い例もあります。例えば、ブランド間でプラットフォームを標準化してサプライチェーンの複雑さを減らす一方で、ブランドが異なるラベルの同じ製品になってしまうことによる顧客価値への影響を無視している場合です。別の例としては、既存の製品の品揃えの複雑さを軽減するために柔軟なシステムを構築する一方で、顧客主導の将来構想を考慮に入れていないことが挙げられます。これらのアプローチは、柔軟性のあるシステムを作ることができますが、実際は間違ったことをしてしまっていると言えます。
これは以下のような疑問につながるでしょう。
「優れたモジュラーシステムとそうでないモジュラーシステムを見分ける方法とは？」
次に、この両者の違いを生む3つの要因についてご説明します。
多くの企業は、製品提供の複雑化に対処するためのソリューションとして、製品プラットフォームにモジュラー設計を取り入れています。柔軟性の向上と相まって複雑さの軽減、数量の統合、そしてサプライチェーンの効率化が約束されることは非常に魅力的ですが、多くの企業が共通の問題に直面しています。
モジュラー製品を使用する際の基本的な推進力は、必要な複雑さを減らしつつ、高い柔軟性を可能にすることです。Do more with less. (最小で最大を成す)、これは理論的には簡単に聞こえますが、実際には難しいことです。
適用スコープが広くなる（つまり、より柔軟性の高いモジュラーシステムになる）ということは、より多くの顧客とボリュームをモジュラーシステムに集約することを意味します。しかし、同じモジュラーシステムでもスコープが広すぎると、全く異なるニーズを持つ製品で性能やコストを犠牲にしてしまうリスクがあります。
モジュラーシステムの開発にはコストがかかることを認識することは大切です。システムを開発することは、単一の製品を開発するよりも本質的にコストがかかります。さらに、システムに含まれる可能性のあるすべての製品を検討するのにも時間がかかります。この時間を前もって費やしておくことで、その後の起動にかかるリソースと時間を削減することができ、時間の経過とともに利益を得ることが可能になります。
一度開発して導入したモジュラーシステムを最大限に活用することで、最大の効果を得ることができます。開発費を捻出するために、より多くの調達ボリュームとより多くの効率的な生産が必要です。
簡単に言うと、プラットフォーム上のボリュームを増やすには、スコープの柔軟性と変更の堅牢性の2つが重要です。この2つがあれば、多くの製品を長く作り続けることが可能になります。
上記では、モジュラーシステムの利点を説明しましたが、モジュラーシステムの作成と維持に必要なワークロードも理解しなければなりません。収益性を高めるためには、複雑さとワークロードが大きければ大きいほど、より多くのボリュームが必要となります。多くの企業では、部品番号とも呼ばれるユニークなコンポーネントの数を複雑さの指標として使用しています。モジュラーシステムの作成と保守にかかるワークロードを理解するために、モジュラーシステムのライフサイクルにわたる平均的な部品数を使用します。このワークロードの尺度を用いて、モジュラーシステムの収益性を説明する式を作成することができます。
収益性とは、何かの正味の結果をそれを行うためのワークロードと比較する概念です。すでに議論した要因を考えると、モジュラーシステムの収益性を定義することができます。
モジュラーシステムの収益性
＝スコープ、ライフサイクル÷ワークロード
このシンプルなモデルを頭に入れておけば、以下に示す3つの決断を行う前に、再度考えるべきだということがお分かりになるかと思います。
市場投入（Time to Market（TTM）)までの時間を短縮する目的で、プロジェクトのスコープを縮小したという話をよく耳にします。Time to Market（TTM）は重要な要素ですが、多くの場合、スコープの縮小は最善の判断ではないと考えています。それは短期的には成功かもしれませんが、中期的には損をする可能性が高いのです。
ある例では、プラットフォームの開発スコープを拡大したことで最初の6ヶ月間のプロジェクトに約3ヶ月が追加され、このプラットフォームをベースにしたその後のプロジェクトでは、それぞれ2ヶ月間期間を短縮することができたというプロジェクトの例があります。
ここでは一体何が起こっているのでしょうか。
最初の2つのプロジェクトは、より広いスコープの代替案の中で確実に後から開始されることに注目してください。最初のプロジェクトのフロントローディングに余分な3ヶ月を費やすことで、プロジェクト3、4、そして将来に向けて時間とリソースを節約することができました。プラットフォームのライフサイクルが長ければ長いほど、より多くの利益をTime to Market（TTM）から得ることが可能になるのです。
また、1つのシステムで広いスコープをカバーすることを目的としているため、高性能な製品との標準化には十分に注意が必要です。一見単純な共通化の解決策ではありますが、需要の少ない製品の利益率を妨げてしまいます。この場合、標準化したものをより幅広い顧客に販売しようとしても、プラットフォームのスコープを狭めてしまうことになりかねません。
この項目は前の項目と関連していますが、別の角度から来ています。以前から稼働しているプラットフォームで、技術Aから技術Bへのアップグレードが必要なものを考えてみましょう。
このプロジェクトの市場投入までの時間を短縮するために、スコープを縮小して売れ筋製品（ハイランナー）だけをアップグレードするようにします。何が起こるのでしょうか？なんと1つのプラットフォームが2つになってしまいます。古いプラットフォームは、ポートフォリオを完成させる上で重要な製品を含んでいるため、フェーズアウトすることはできません。そのため、1つだけではなく、2つのプラットフォームを維持し、制作するためのワークロードを費やす必要があります。この2つのプラットフォームを完全な新世代のプラットフォームに置き換えるまで、行き詰ってしまうでしょう。そうしないと、プラットフォームがどんどん増えていくスパイラルに巻き込まれ、開発リソースがどんどん減っていき、リソースの制約から開発プロジェクトのスコープを狭めることにさらに注力する必要になるのです。
現在存在する要求を見極めることは、それほど難しいことではありません。既存のポートフォリオや競合他社のポートフォリオを見たり主要な顧客に聞いてみると、95%の要求は把握できる可能性もあります。将来を予測するのは難しいことですが、予測はプラットフォームのライフサイクルを延ばすための鍵となります。それでは、どのように変化に備えたらいいのでしょうか。
ランダムな変化が起こる場合は問題ではありますが、多くの場合はそうではありません。顧客の真のニーズを理解し、手に入れたい顧客のための確固とした戦略を持ち、優れた技術的なロードマップを持つことで、変化を予見し、あるいは少なくとも多くの部分での変化が可能になります。製品の特定の部分への変更を切り分けることができればできるほど、プラットフォームのライフサイクルは長くなり、得られる利益も増えるでしょう。
モジュラーシステムの最良の例の一つは、フォルクスワーゲングループの車です。信じられないほどのシステムの柔軟性を持ち、長期に渡る明確な学習と改善への道筋を示しています。フォルクスワーゲンは強いコミットメントを示し、時間をかけて学習することで改善してきました。そしてこの努力は、3代目のモジュラーシステムで報われました。
The Volkswagen Group MQB Modular System has a very wide scope
今日ではフォルクスワーゲンのモジュラーシステムは、乗用車の全スコープにまたがっています。
それらは、電動式（MEB、PPEプラットフォーム）と内燃式（MQB、MLBプラットフォーム）のドライブラインを含む基本的な構造設計原理の違いによってのみ定義されています。イノベーションにより、年間30億ドル以上の削減が可能です。2020年には、MQBプラットフォームがフォルクスワーゲングループの総生産台数の80％以上である1100万台近くを集約しています。このMQBプラットフォームは2012年に発売されたので、すでに8年が経過しています。このプラットフォームがどれだけ長生きするかは、時が経たなければ分かりません。MQBプラットフォームとその兄弟が、複数のモジュラーシステムがサブシステムで構成され、モジュラーシステム間で共有できるような、さらに大きなものになっていると考えると面白いです。
この偉大なプラットフォームを達成するために、フォルクスワーゲンは1993年にモジュラーシステムで作業を開始しました。この時はプラットフォームと呼ばれていました。同社はスケール効果とサプライチェーンの効率化を目指し、持っていた20の車種を車のサイズに基づいて5つの共通のプラットフォームに標準化しました。例えば、Aプラットフォームは、アウディA3、アウディTT、Volkswagen Golf、Seat León、そしてSkoda Octaviaなどの同じサイズの車のために作成されたものです。
このAプラットフォームは、貧弱なモジュラーシステムの明確な例です。なぜでしょうか？
柔軟性を目指したモジュラー化ではなく、複雑さを減らすために標準化が使われていたからです。車の実用性能の多くが標準化されたプラットフォームに縛られていたため、顧客にとってはモデルの違いを見分けることが非常に難しくなっていました。
これは、ブランドの特徴の多くが失われたことを意味します。非常に似たような車がSeatで半額で手に入ることを、アウディの顧客が知ればどうなるでしょうか？彼女はより安いブランドを購入するか、あるいはプレミアムブランドが購入の動機である場合、代わりに競合するプレミアムブランドに注目するでしょう。
これまで、モジュラーシステムの収益性に関するモデルとしてフォルクスワーゲンを紹介してきました。同社はプラットフォームを削減し、ワイドスコープの市場ニーズを満たすために、この狭いスコープを使用し続けていましたが、それは真の顧客ニーズを満たすことには繋がっていませんでした。しかしながら、フォルクスワーゲンのモジュラーシステムを用いた約30年に及ぶ進化は、戦略に対して集中的に長期的な取り組みを行ってきたことを示しており、素晴らしい例だと考えています。改善を重ね、素晴らしい結果を導き出しました。
この内容に関するご質問、ご興味のある方は以下のフォーマットからご連絡お願いいたします。