米国の調査会社であるGartner社が発表した”製造業における技術トレンドカーブ”（ハイプ・サイクル）の中に新しくProduct Architecture Configuration（製品アーキテクチャーコンフィグレーション）が取り上げられています。また、欧州主導で進めているサーキュラーエコノミーに対応する製品ライフサイクルという考え方においては製品や部品の再利用による対応が必要であるという事がわかってきています。このような背景の中で企業の事業戦略の根幹をなす製品アーキテクチャーについては、これの構築のための考え方とプロセスの正規化を図ることによって、事業環境の変化に迅速に対応できること、製品ポートフォリオの継続性を保証する必要性があることは明白です。さらにはモジュラー化にとって、製品アーキテクチャーを構成するモジュールバリエーションの最適化と製品ロードマップに合わせたモジュールのリリース計画はモジュラー化プロジェクトに対する大きな必要要件であると思います。このブログでは、モジュラーの根本となる製品アーキテクチャーの重要性について述べていきたいと思います。
ガートナー社のハイプ・サイクルレポートは毎年多様 な領域のエンジニアリング、テクノロジーに関する期待度を時間の経過とともにどのように進化するかを視覚的に説明することで有名です。 同レポートは、テクノロジーやアプリケーションが今後 10年スパンで、特定のビジネス目標に沿った採用判断のために最適な知見を提供します。この度リリースされたレポート“Hype Cycle for Manufacturing Digital Transformation and Innovation, 2022(ハイプ・サイクル 製造業向 けデジタルトランスフォーメーションおよびイノベーシ ョン2022（ＭＭ社訳）)”において、製品アーキテクチャーコンフィ グレーションは今後5-10年主流となるトレンドテクノ ロジーとされています。Product Architecture Configurationというアイテムは、左側の「これからホットになる」トレンドカーブの上昇部分の中央に位置しています。これは、既に先進的な一部の企業では製品アーキテクチャーの構築とコンフィグレーションに取り組んで成功していることをも示しています。
製品コンフィグレーションとは、 個別の顧客要求に合うようにかつ、生産、提供可能な ように部品を選定して組み合わせて製品とする機能 です。しかし、この適用範囲（プラットフォーム）を拡張 し、企業の中の複数のプラットフォームやシステムのシステム（複 層的なシステム構成）に活用するとなると、コンフィグ レーションルールの運用・管理は非常に複雑になって しまいます。製品や業務の複雑さを知り管理する事が、 成功への道筋です。
ガートナー社は、以下の通り指摘しています。「システム のシステム（複層的なシステム構成）に対するコンフィ グレーションには製品コンフィグレーションの定義と 運用、製造プロセス、営業とサービスのオプショ ンを一貫してまとめるためにシステムエンジニアリン グ技術を用います。ここで言うシステムエンジニアリング技 術は、統合的な製品アーキテクチャーに加え、技術的・営業 的に妥当なバリアントのコンフィグレーションを実現し、納期予測に向けた生産計画等を可能にする、統合的なルールエ ンジンを含みます。」
プロダクトマネージメントの欠如？
一般的に、自動車OEMにはチーフエンジニアと呼ばれる製品に対する責任を持った人、またはこの人をサポートするメンバーを含めた部門があります。
ここでは、市場調査、トレンド調査、競合他社調査、性能仕様の決定、さらには原価管理と販売予測まで含めた製品の総合管理を行っています。
最近ではシリーズ設計とよばれる、プラットフォームベースでの一連の車種での採算性も含めた管理が行われています。
ここで重要なのは、単純に性能を上げる設計だけではなく、いかにシリーズで採算がとれる設計を行うかです。
この製品に対する考え方、組織や責任が、量産品または受注生産を行う一般的な製造業では行われているでしょうか？筆者の知る範囲では、残念ながらコンペが性能をＸＸとしたから、次回はＸＸ＋にする、とか、見積でＹＹ円負けたからコストダウンを行うという行き当たりばったりの開発となっていることを聞くことが多くなっており、製品アーキテクチャーの管理をしっかり行っている企業は少ないのではないでしょうか。前述のGartner社が言っているように企業は次のようなマネジメントを実施することで企業としての成長プロセスのイメージが書けるはずです。
この図の左側図は、一般論として製造業においてある特定の人材が製品アーキテクチャーを検討するためのデータを保持し、独自の判断基準で分析を行って、製品ラインアップやオプションを考えているのではないかという図です。特定の方がマーケティング、営業、調達、製造などの条件や、データ分析を行っていることが表現されています。一方で右側図は、製品アーキテクチャーのデータを各部門が保持管理しこのデータを共有しながら知見とデータ分析によって製品ラインアップやオプションが構成されていることがわかります。
さて、製品アーキテクチャーはどうゆうデータを基に構築されるのでしょうか。これは、企業や製品や業界や適用される地域で異なりますが、一般的な製品アーキテクチャーを構成するデータを並べてみると次の図のようになります。この図では、製品アーキテクチャーを中心においてまず、そのすぐ外側に製品ラインアップに対するモジュール種類やインターフェース、顧客満足、製品構成ツリーなどが位置付けられており、この周りにこれらのデータを構成するためのサブデータ群が並んでいます。これを整理することによって、まず製品アーキテクチャーがどのようなデータ群で構成されているかを把握する事が可能になります。
さらにこれらのデータを扱い、管理している部門に展開すると次のような図となると思います。ここまで整理ができれば、現在持っているデータを集めて分析、整理をすれば、製品アーキテクチャーの可視化ができるようになるはずです。
この図はある建設機械の製品ラインアップとこれを構成するモジュールの説明図です。図の左側は製品を構成するモジュール群で、右側はこのモジュールを組み合わせて構成される製品ラインアップとなります。円で囲まれた製品はどのような理由で定義づけされたかを示しています。
(2) 製品リリースに基づくモジュールのリリース
製品アーキテクチャーとモジュール化には製品仕様に関する関係が深いことはすでに述べましたが、実際の製品リリースにおいては、アーキテクチャーとこれを構成するモジュール群の開発リリース計画には深い関係があります。即ち、モジュラー開発は製品ラインアップを俯瞰した形で計画されるべきですが、各モジュールの開発と生産計画は、製品のリリース計画に合わせて必要なモジュールのバリアントが開発、リリースされ、生産されるべきであると言えます。
製品アーキテクチャーの重要性とモジュラー化の間に深い関係があることは、既に説明をいたしました。それでは、製品アーキテクチャーを明示化する方法についてはどのようにすれば属人的なアーキテクチャーではなく持続可能なものにできるのでしょうか。ここではその具体策について説明したいと思います。
製品に対する要件とこれを実現するアーキテクチャーの整理と関係構築
ここに掲げる三つの図はアーキテクチャーを構成するデータ群の整理のサンプルとして、LCDテレビの開発に対してどのような要件が考えられるかについて図示したものです。
まず、最初の図においては、開発チームにおいて、それぞれのメンバーが思いの通りの言葉でLCDに求められる要件をランダムに述べています。
次にこれらの言葉を、
「製品特性」
「顧客セグメント」「顧客価値」
「製品特性の目標値」「テクニカルソリューション」
「モジュール」
「アーキテクチャーノード」という区分に分類します。
ここまで要件出しと分類が行えれば、これらの相関関係を接続図を用いて関係定義を行えれば、LCDディスプレイのアーキテクチャーをいかに構成すれば良いかが定義付けることができるはずです。Modular Management社が開発しているPALMA®ソフトウェアはこの関係をソフトウェア上で実装することで事業においてモジュールに対する要件のセグメント分類と関係構築の継続利用ができることを実現しています。
さて、製品アーキテクチャーを管理するためにはプロダクトマネージャの存在とその責任所掌範囲の明確化が必要となります。前述した製品アーキテクチャーを構成する項目の接続関係が定義できると検討すべき項目の担当所掌が明らかになります。次の図はその一例です。プロダクトマネージャは顧客のセグメントを明らかにして、顧客がどのような要目で製品に価値を感じるか、また市場における価格目標、これらから製品の目標値を設計開発者に示します。設計開発者はこの目標値をどのような技術解決策で実現して、どのようなモジュール構成で製品ラインアップが実現できるかを検討します。次のステップとして、プロダクトマネージャはこの製品ラインアップの販売計画を検討して、製品ラインアップ全体での収益性を検討します。もし、ここで収益性が悪いとなると、製品の目標値、ラインアップの再構成、設計者はテクニカルソリューションの再検討などでコストダウンを図ります。製品アーキテクチャーが事業のなかで明らかにされると、プロダクトマネージャ、設計開発者、調達、生産ライン担当者などが一度に事業収益性に対する検討が行えるわけです。
家電などの耐久消費製品は見込み生産、または在庫販売型SKU（Stock Keeping Unit）製品と呼ばれる製品では、製品アーキテクチャーがほぼ消費者がみることができる商品（製品）ラインアップ（カタログ）となります。ただし、製品アーキテクチャーで表現されているオプションや形に表現されないバリエーションなどはラインアップやカタログでは補足的に表現されています。また、在庫型であってもオプションは販売契約が成立した後、取り付けられたり、購入者が自身で取り付ける場合もあります。この場合は販売される製品タイプが年次によって何製品販売されたか、で製品アーキテクチャーの計画が正しかったかどうかが判断されます。
一方で、受注生産型製品では今回の主旨による生産形態ではETO（Engineering To Order）からCTO（Configure To Order）へ近づくことができるはずです。ここで、どれだけ組み合わせだけで受注型生産ができたか、という指標をCTO率と呼ぶと、CTO率100%が理想的な数値となります。しかしながら現実的には多種多様な顧客の要求を準備されたモジュールだけで叶えるというのは無理があるかもしれません。そこで現実的なモジュラー化を実践する企業では「CTO率を80%と置くが、残りの20%の案件の90%はCTOで実現する」という目標を立てています。これは即ち、20%の顧客の20%だけが設計されるわけですのでトータルでは96%がCTOとなったわけです。
このようにモジュラー化プロジェクトを実践する際に現実的なCTO率を目標にすることを掲げることも、モジュラー化を推し進めることの一助となると思います。
製品アーキテクチャーは本来企業の事業継続性やコンプライアンスなどを考えると、その背景や経緯の可視化は必須であることは明白です。製品アーキテクチャーへの取組はモジュラー化に限らず様々な課題への対応策として非常に重要な事項です。この取り組みにより、事業収益性、事業継続性、コンプライアンス、サーキュラーエコノミーやSDGｓへの対応、DX化への対応等、様々な企業の課題に対してキーとなるはずです。
松尾 直
プレジデント シニアコンサルタント
モジュラーマネジメントジャパン株式会社
Tadashi.matsuo@modularmanagement.com