歴史上、多くの機器、設備、サービスなどがモジュール化されてきたことは皆様も認識のことだと思います。今回は、何故このような製品、企業がモジュラー化に至ったかについて考えていき、これからのモジュラー化への参考となればと考えました。

さて、モジュラー化の前に多くの製品、設備などが標準化という道を歩んできました。標準化とモジュラー化の違いについては、いろいろな場所で議論されています。それらについて、ここではあえて言及いたしませんが、歴史的には標準化からモジュラー化へと歩んだ例が多いかと思います。

標準化とは

時代は遡りますが、書物によればフォード社がT型フォード車を大量生産するために多くの事柄に対して工業的な標準化を図った、と言われています。この時の標準化のドライバーは大量生産のための「ライン生産」でした。そののち第二次世界大戦のころには、ライン生産のための標準化はもちろん行われましたが、それに加えて、大量に兵器を生産するために、各地に展開された工場で、未熟な工員が一定の品質で生産ができること、メンテナンスが容易であることも標準化のための要求項目となったようです。下記は当時のソビエト連邦におけるエンジンの標準化（モジュラー化）の例です。やはり大量生産、転用、メンテナンス管理などが標準化のドライバーになっています。

以下ソ連のT-34戦車のエンジンを説明した資料をWebモータマガジン記事から抜粋転載いたします

T-34は現代戦車の祖とも言われ、ドイツの誇る機甲師団をも恐れさせた第二次世界大戦の「神」戦車だ。ただ、残念なことにT-34の1両では火力と装甲とも、ドイツの名戦車タイガーやパンサーに遠く及ばず、変速機は単純劣悪だった。しかし合理的設計は低コストと大量生産に特化し、低品質を数で補い、高性能・高品質にこだわった少数精鋭のドイツ戦車を圧倒してしまう。ちなみに、第二次世界大戦当時のタイガーは全系列で約2000両、T-34系列で約5万7000両と、その差は30倍近い。同エンジンはT-34以外にも同期のあらゆる戦車や自走砲・大型軍用車両に転用された。約4万9000両製造されたM4 シャーマンが、実にさまざまなエンジン形式があったのとは対照的に、生産性と前線での整備性の向上に大きく寄与した。ただし、西側工業国ほど高い品質管理をしない旧ソ連製のアルミエンジンだけに、信頼性や耐久性は低く、やはり粗悪品を大量生産で補う理論であった。

Ｔ-34に搭載されたV-2-34エンジン

この徹底した標準化はのちのモジュール設計につながるわけですが、戦時とは異なる要件から標準化とモジュラー化が生まれてきたと思います。第二次世界大戦後、製品が各国から輸出されるようになり、部品の調達、サービスの国際化から各国が工業標準を設定します（ISO,JIS,DIN,ウィットなど）。この標準化により多くの企業が利益を得ることを覚え、デファクトスタンダードと呼ばれる、先行した、または、強い製品・部品を持つ企業は彼らの標準がグローバルスタンダードと呼ばれる強い標準となります。例としては、コンパクトディスク（ＣＤ）、ブルーレイ、ＵＳＢコネクターなどがあげられます。

このような強い要求、はっきりとした目的意識をもった標準化がモジュラー化への道になっていると思います。ここからはモジュラー化の必然性について考えていきたいと思います。

モジュラー化とは

標準化とモジュラー化の違いについて、筆者の個人的な考え方ではありますが、一つの考え方として、標準化は単純化された要求に対して応えるために使われていることが多いことに対してモジュラー化は複数の要求、複数のプロセス・部門の要求にこたえるための最適解を得るために用いられているといっても過言ではないと思います。下記は設計部門を中心としたモジュラー化が必然となった背景について書きだしてみました。

1. 製品のあるべき姿の見える化
   1. 製品（部品）がどうゆう仕様要求で作られているか
   2. それは企業の戦略に合っているのか？設計者の趣味か？
2. 設計暗黙知の見える化
   1. 如何に設計者が考えた形状（数値）材質、振る舞いを「見える化」、「見せる化」するか？
   2. KKD（勘と経験と度胸）ではなく、検討に裏打ちされたもの
3. 標準化の標準化
   1. 標準化で終わらず、「標準化を標準化」するような継続的な管理

上記に述べた（１）製品のあるべき姿の見える化と（２）設計暗黙知の見える化のようなテーマを解決するために、筆者は2000年代初頭に製品に対する要求項目を早い時期に集めて集約する「テンプレート設計開発手法」の実践を行いました。このインテリジェントパーツと呼ばれる設計テンプレートには製品性能のための要求だけではなく生産、サービスの要求をも織り込み、これを仮想製品または仮想部品と称して事前に開発し、製品開発の際には、これらを実製品に適用するという手法を取りました。

この際に、現在使われている部品の図面を分析するとキャリーオーバー的に持ってこられた部品・製品形状の謂れは図面には書かれていないことが多く「キャリーオーバーなので」ということで多くの事柄が信用されて使われていることが見受けられました。ソフトウェア産業界では要求仕様に基づく開発は一般的ですが機械設計では製品に対する仕様に基づいて設計はされていますが、個々の部品、部品形状がどうゆう要求を満たすために設計されているかについては細かく設計表現されていながことが多いかと思います。残念ながら多くの企業の設計現場ではKKDと呼ばれる「勘」と「経験」と「度胸」と呼ばれる手法で「最善策」がとられています。これは企業の長い経験に基づいて決められていますので決して間違いではありません。しかしながら、これを正しいという説明ができていないのです。このような設計要件の見える化の課題を解決する手法の一つとしてモジュラー設計では、要求項目、即ち顧客ニーズに基づいて設計されていることを表現し何度も使えるようにQFDのような手法を用いて、考えに至るプロセスを「見える化」しようとしています。

モジュラー設計が企業競争力に及ぼす影響力

この手法を使うことで2000年代に多くの産業、特に開発競争が激しい自動車産業では開発期間の短縮と類似車両の同時開発を行い、大きな成果をあげています。一方、ETOと呼ばれる受注型産業でも設計手法もしくは標準部品をコピーすることで開発期間の短縮化を図っています。ただ、この時には部品組合せをどのレベルでおこなえば最適な共通部品とできるか、またはどの製品を企業の標準製品として準備しておけばよいかについては設計者もしくは企業の製品マネージャのセンス（幅広い視野）に任されていました。この標準設計の課題をモジュラー設計では部品の組合せをどのように行えば企業として最適な組み合わせであるかを論理的に解こうとしています。

標準化のドライバーの一つとして筆者は少しユニークなケースも経験しました。それはETOのケースですが、モジュラー化のドライバーは見積もり設計の早さでした。この企業では一般的には引き合いが来てから要求仕様に基づいて営業技術と呼ばれる計画設計と見積もりを行う専門家が営業と一緒に活動をしていました。しかしながら同業他社が製品のモジュラー化とセールスコンフィグレータを組み合わせて、タブレットのようなインターフェースで顧客の要望を選択、入力をすると、90％以上の精度で簡単に見積もりができるようにしました。その結果、この企業が見積もり仕様書を一番最初に提出する企業となり、同業コンペティターはこの企業が提出した仕様書に基づいて見積もり設計を行うことになってしまいました。これでは、二番目以降の企業は一番目の企業の仕様に合わせることとなり、ほとんどが新規設計となり、時間でも金額でも負けてしまうという結果となっていました。フォロワー企業は急いで、見積もりを早くするために自社の製品をコンフィグレーション（組合せ）ができる標準化活動を行い、製造現場には常設図面を設置し、受注から直接製造BOMへ出力できるようにしようとしました。

このように、多くの企業では設計の標準化によって多くの成果を上げていると思います。しかしながら、標準化プロジェクトは一時的な活動となっていることが多くないでしょうか。筆者の経験でも非常に多くのリソースを使って標準化されたプロジェクトも実践で使うようになると、それぞれのビジネス事情とユーザの思いで変化していくことがあると思います。これは避けられないことと思います。結果的に「部品の系図管理」などという本末転倒な言葉が出るようになり、当初の標準化への思いが薄くなってしまっています。これを避けるためには、当初の標準化作業に立ち戻って、標準化したものに対して修正を加えて再度リリースするという「標準のメンテナンス作業」が必要です。これが「標準化の標準化です」。これらの事象から、従来型の標準化プロジェクトから脱却し、より一層の成果を上げるためには前述したモジュラーの必然性が問いかけている課題に対して取り組むべきかと考えます。

1. 製品のあるべき姿の見える化
2. 設計暗黙知の見える化
3. 標準化の標準化

企業がモジュラー製品、モジュラー設計に取り組む際にはこのようなテーマに対して真摯に取り組むべきです。私はこの動きが設計標準化ではなく、企業全体で取り組むモジュラー化活動だと考えています。

もはやモジュラー化は設計部門だけの課題ではないことは皆様周知のことと思います。今回述べた課題を解決するためには企業横断組織、クロスファンクション組織での取り組みが必要となります。クロスファンクションチームという企業全体の組織で、市場の調査、企業内の調査から、プロセスなどの課題と製品に対する要求項目を洗い出し、これを整理することでモジュラーが見えてくると思います。また、このモジュラー化活動で得られる利益についても組織横断で得られることも理解すべきです。設計時間の短縮だけではなく、原価、ことにプロダクトライフサイクルプロセスに存在する多くの間接費用にも着目するべきです。モジュラー化のための要件も製品の性能用件だけではなく、販売、製造、調達、サービスメンテナンスの多くの部門の要求が並べられて判断されるべきです。

上図は、弊社が提唱しているプロジェクトフロー図で、企業がモジュラー化に取り組む際のフロー図です。ここでは、モジュラー化の活動の各ステップが定義づけされており、これらの活動が企業全体で取り組まれるべきと提唱しています。
今回はモジュラー化プロジェクトが必要とされる「必然性」について着目して述べてみました。皆様の企業、組織においても必然性について語られてモジュラー化プロジェクトが進められることを望みます。

以下のプレミアムコンテンツでは、モジュラー化の成功のポイントを欧州の事例をもとにまとめています。ぜひご確認ください。