↑ トップ頁へ

2007.8.1
 
 


モノ作りが強いとは…

 日本企業は“モノ作りが強い”という言葉は結構曖昧で人によって解釈が違うので注意が必要だ。
 と言うのは、“製品企画→設計→試作・試験→製造体制構築→量産”という流れのなかで、何が強いのか曖昧になりがちだからである。

 一般には、“モノ作りが強い”というのは、このうちの設計技術が優れていることを意味する。それは、「設計⇔試作・試験」のフィードバックが円滑に進むことでもある。
 「組み合わせ」ではなく、「すり合わせ」で優位性を発揮できるとは、この段階で様々なファクターを考えながら、全体最適な設計ができるということ。これこそが、日本のモノ作りの強みだということになる。
 確かに、自動車産業では当てはまりそうである。

 ただ、この話は、「設計⇔試作・試験」に留まらない。
 「設計⇔製造体制構築」、「設計⇔量産」も成り立つ。自動車産業では、“フロントローディング”と呼ぶ発想である。工場で不具合が発生しないように、作り易さを考えたり、お金のかかる新しい治具や装置をできる限り使わずにすませるように、製品の設計段階で熟慮することが求められる。
 つまり、現場の知恵を設計段階で読み込むことで、競争力を発揮するということ。
 これをして、“モノ作りが強い”と呼ぶ訳だ。
 そして、「組み合わせ」でなく、「すり合わせ」に、日本企業が向いていると結論付けられることが多い。

 しかし、よく知られているように、これがすべての企業に当てはまる訳ではない。
 自転車メーカーのシマノのように、規格化された部品の「組み合わせ」製品を製造するメーカーであっても、圧倒的な競争力を発揮している企業があるからだ。

 それでは、これを、どう解釈するかというと、「すり合わせ」の力量があれば勝てる産業と、それでは勝てない「組み合わせ」型の産業の違いだ、となる。  例えば、自動車産業でも、「すり合わせ」が効かないトラック製造と、「すり合わせ」が効く乗用車製造があるという見方だ。  しかし、これは結果論と言えないこともない。
 パソコンは部品の寄せ集めでできるから「組み合わせ」が得意な企業が優位立つとされる。もちろん、デスクトップでは成り立つが、ラップトップやパームトップでは部品の相互干渉が生じるので、どうしても「すり合わせ」が必要となってくる。これを、トラックと乗用車の違いと見ることもできるが、ラップトップも「組み合わせ」でできるのではないか、と考える企業もある筈。又、お洒落なデザインの製品を流行らせ、デスクトップを「すり合わせ」が必要な製品にしてしまえ、と考える企業が出てもおかしくない。
 どんなタイプの製品が市場を主導するかという、いわばイノベーション競争をしていると解釈すべきではないだろうか。

 産業の特徴を固定化して眺めたり、自社の強みを色眼鏡で見たりすべきではなかろう。
 イノベーション創出には、そのようなマインドセットは大敵だと思うのだが。

 特に、日本のメーカーだから、「すり合わせ」の力量がある筈との単純な発想は危険である。
 “モノ作りが強い”といっても、上記のような強みばかりではないからだ。

 よくあるパターンは、工場の製造現場の対応力が優れている場合。
 製品設計部門からあがってきた図面あるいは指示書通りに、なかなかできそうにないものでも、作りあげてしまうような企業が該当する。どう見ても、設計段階での「すり合わせ」で力を発揮しているとは思えないのである。
 理論上可能なら、なんとか仕上げる力で、競争力を維持してきたように見える訳だ。
 このことは、新しい要素技術が社内で開発されると、強引に商用化にこぎつけることができることを意味する。素晴らしい強みである。製造工程設計や製造部門の組織運営のスキルが優れていると言えそうだ。

 このようなタイプの企業が「すり合わせ」に走るとどうなるだろう。
 普通は、製品設計に力を入れることになる。当然、設計段階で、様々な組織との調整や、知恵を借りる作業が延々と続くということ。確かに悪いことではないが、ここに注力すれば、他の業務は手薄になる。
 問題は、それで自動車産業のように、競争力が向上するのか、という点。

 自動車産業は新技術を導入すると言っても、製造の仕組みを大きく変えている訳ではない。だからこそ、“フロントローディング”方策が奏功するのである。
 しかし、上記のタイプの企業の現場が強くなった理由は、製造プロセスを変えないと製品を作れない事態に遭遇してきたからだろう。
 製品設計の段階で、現行の製造技術を前提とした考慮に時間を割くからと言って、そのスキルを使えるだろうか。

 重要なのは、自社特有の強みを見抜き、それを活かす方策を考え、どんな戦略がよいのか考えることだ。


 技術力検証の目次へ>>>     トップ頁へ>>>
 
    (C) 1999-2007 RandDManagement.com