モジュラーコンセプトが全く取り入れられていない、又は、これに興味のない企業はごくわずかです。複数の製品で再利用され、横断的に共有されるビルディングブロックを求めることは、製品開発、サプライチェーン、アフターマーケット業務におけるスケールと効率性を獲得し、バリューチェーンを通じて複雑性のコストを削減するために、ほとんどの企業で共通して行われていることです。
しかし、体系的かつ意識的に取り組んでいる企業は意外と少ないと言われています。通常は、場当たり的なアプローチにもかかわらず、自分たちはあるべきところにいるのだと思い込んでしまっているのです。
このブログでは、モジュラー化を成功に導くための指標のひとつである「製品アーキテクチャ成熟度モデル」と呼ばれるものをご紹介します。これは、あなたが現在どこにいて、どこを目指すべきかを、部門横断的かつ現実に即して理解するものです。製品アーキテクチャ成熟度モデルは、スコープ（範囲）と時間の次元に基づいて、市場、製品開発、サプライチェーンという機能横断的な次元をカバーしています。
Scope and Time（市場と時間）
スコープとは、1つの製品、またはプラットフォームがカバーする市場のことです。標準的な製品では、たとえ汎用性があっても、その市場範囲は狭く、専用的になっています。部品の交換やオプションの追加・削除などの可能性が高ければ高いほど、スコープは広くなります。パフォーマンスや機能、特性をより多く選択できるようになれば、より大きな市場に対応できるようになるでしょう。
時間とは、製品またはプラットフォームの収益性のある寿命のことです。製品やプラットフォームが段階的に廃止されるべき時に廃止されないという状況はこれにカウントされません。過小評価されたボリュームで生き続けることは、収益性のあるビジネスではなく、コスト高な製品寿命維持活動に過ぎないのです。
スコープと時間の次元との関わり方については、こちらの記事「優れたモジュラーシステムは何をもたらすのか？」をご覧ください。
モジュラーマネジメント社では、「スコープ」と「時間」の2つの次元に基づき、6段階の成熟度を設定しています。これらは理想化されたものであり、現実にはこのように白黒はっきりしないことが多いことを私たちは理解しています。
例えば、ある製品はレベルIIとVを兼ね備えている可能性があります。このような課題はありますが、このモデルは、現在の位置と望ましい目標状態の両方を特定するために最適です。
実際に開発された既成の製品は存在しない、または、お客様からのオーダーは、一品一品、同じものが二度とないデザインやパーツで、独自にカスタマイズされた製品を納品することなります。過去の納品物をコピーすることで、多少の再利用は可能であるかもしれません。しかし、この再利用は過去の遺産を使うようなものであるため、技術者以外が再利用情報を活用することは難しいかもしれません。
各製品は、専用の設計を施した縦割り製品の集まりです。どの時点でも、各製品はあらかじめ決められた仕様を持ち、部品表も交換可能な部品がなく固定されています。異なる製品間の共通性、再利用性は低くなっています。製品の寿命は短く、大量生産が可能であり、小改良にとどまり、大きな改良は行われません。新製品は頻繁に開発されますが、旧製品は平行して製造販売されています。
各プラットフォームは、専用の設計を施した縦割り型となっています。各プラットフォームの内部では、顧客が仕様をニーズに合わせるための選択肢が限られており、部品表においても、交換可能な部品はごくわずかです。異なるプラットフォーム間の共通性、再利用性は低くなっています。プラットフォームは大量生産で寿命が短く、小さなフェイスリフトが行われるだけで、大きな改良は行われません。新しいプラットフォームは頻繁に開発されますが、古いプラットフォームは平行して活用されています。
各プラットフォームは、顧客にとってより多くの選択肢を持ち、部品表でより多くの交換可能な部品を持ち、より広い市場（スコープ）をターゲットにしています。また、各プラットフォームは長寿命で、継続的に更新・改良されるかもしれません。しかし、プラットフォームの寿命が尽きる頃には、開発によってプラットフォームがバラバラになり、本来の互換性や共通性を欠いた複数のサブプラットフォームに分岐してしまう傾向があります。異なるプラットフォーム間の共通性・再利用性は時間とともに減少しています。
レベルIVと似ていますが、今度はいくつかの重要なシステムやコンポーネントがプラットフォームを越えて横断的に共有されます。多くの場合、これは純粋に「技術的な必要性」に由来するもので、開発および製造するには単に高価すぎる、またはリソースが必要なシステムまたはコンポーネントを横断的に共有する必要があるためです。
製品アーキテクチャにおける最高の成熟度では、幅広い製品群に互換性と共通性を持たせ、非常に広い市場（スコープ）に対応することが意図されています。同時に、研究開発とサプライチェーンにおける内部シナジーと規模の経済を最大化します。より大規模な開発や化粧直しのようなマイナーチェンジに直面した場合、モジュールシステム全体が更新され、すべての製品で同じレベルの互換性と共通性を維持することができます。個別の「サブプラットフォーム」への分岐は避けられます。この成熟度では、製品アーキテクチャだけでなく、組織や仕事の進め方にも非常に高い要件が課されます。アーキテクチャのガバナンスは、すべての製品で厳密に管理されなければなりません。
オンライン製品アーキテクチャ成熟度モデル診断で、あなたの企業がどのレベルであるかをテストすることができます。
製品は、物理的なサイズが同じである、顧客の用途が似ている、組立構造が共通であるなどの理由で、プラットフォームにまとめられることが多と思われます。また、ハイエンド、ミッドエンド、ローエンドの製品や、異なる地域の市場のニーズに対応する製品についても、プラットフォームが作成されることがあります。これらの考え方がプラットフォームのカバレージ範囲を狭めているようです。グローバルな家電メーカーであれば、洗濯機だけでも10以上のプラットフォームを持っているかもしれません。
各プラットフォームはそれぞれ独自の部品を持ち、研究開発やサプライチェーンにおけるシナジーが全プラットフォームに及ぶことはありません。あるプラットフォームに改良を加えても、他のプラットフォームに適合するように設計し直さなければなりません。また、総量が多くても、製品によってばらつきがあるため、特定の部品の数量は少ないものになります。サプライチェーンでは、通常、各組み立てラインは1つのプラットフォームに特化しています。時間とともに数量が変動すると、一部のラインでは需要過多、品質不良（サードシフト症候群）、製品の入手不可能による失注が発生します。また他のラインは、需要不足のため稼働率が悪くなってるかもしれません。
プラットフォームアプローチとモジュラーアプローチの違いは、狭い範囲で活用されていたプラットフォームから今日のモジュラーアプローチに至るフォルクスワーゲン社「Volkswagen group journey」報告から理解することができます。
プラットフォームとモジュラリティについてのトピックに興味がある場合は、「広範な製品をまとめてモジュラー化する方法」をチェックすることをお勧めします。
現在の製品アーキテクチャの成熟度を正しく把握するためには、エンジニアリングだけを調べても十分ではありません。営業、マーケティング、研究開発、エンジニアリング、サプライチェーンを含む部門横断的な評価を確保する必要があります。製品またはプラットフォームごとに調べるべき主なパラメータは次のとおりです。
この評価は、インタビューや起こっている現象情報を集めるなど、証拠の収集によって定性的に行うことも可能ですが、上記のパラメータを実際に測定することで、現状と理想的な状態を定量的に把握することが可能になります。
あるべき姿を定義するためには、3つの次元で評価する必要があります。
顧客固有性 - 各顧客固有のニーズと要件の組み合わせに対応する能力。
Time-to-Market – すべての製品ラインアップに対し製品アーキテクチャを適用展開するまでの時間。大規模で互換性の必要がないような製品の場合は最初のリリースに時間はかからないかもしれません。
内部複雑性と間接コストは互いに強く関連しています。設計や部品番号の数が多く、それらを頻繁に変更すればするほど、内部複雑度と間接コストは高くなります。
組織横断的な作業、継続的な開発、安定した製品、スケールメリットなども強く関連しています。適切なクロスファンクショナルチームを立ち上げ、継続的な改善を効率的に進めるためには、部品やサブアセンブリの時間的なスケール（集合量）が十分である必要があるのです。モジュールは、より広い範囲の品揃えに使用され、変更が必要なモジュールにのみ変更が加えられるため、モジュール化は必要なスケールと安定性を可能にし、インターフェースは、変更が設計全体に波及することから他のモジュールを保護します。
内容に関する質問や議論を深めたい場合、またオンライン調査で自分のモジュラリティがどの程度かを知りたい場合は、お気軽にご連絡ください。