受注設計製品の標準化をどう進めるか

１．はじめに

受注設計製品は、商談を通して最終仕様を決めていくため、ほうっておくと個別設計の山になりがちです。この問題について、「どのように標準仕様を決めたらよいか」について考えてみたいと思います。

これには大きく３つのアプローチがあります：

１）準標準品を認定する
過去の設計実績から、モデルとなる図面と部品リストを準標準に「認定」する
新たな案件は、認定された実績から近いものを流用し「差分」設計を行う

２）標準部品を整備する
汎用性とライフを意識して、標準部品を選定する
新規設計部分において、標準部品の利用率を上げる

３）モジュール化率を向上させる
モジュールを開発して、標準製品におけるモジュールの構成割合を増やす

受注設計製品とはいっても、大半は核となる標準品の改造であることが多いのですが、問題は、その変更管理の方法です。はじめに、この問題への対応方法について考えます。
また、受注設計製品におけるモジュール化は、そもそもモジュールをどのように決めるのかが大きな課題です。３では、これに対する考え方の一例を示します。


２．受注設計製品の標準化が進まないわけ



上図にあるように、受注設計の案件では、たとえ過去に類似の事例があったとしても、担当する設計者が異なれば、実現方法も異なってしまうケースが多く見られます。
都度の設計を前提としているので、他人の蓄積から類似事例を検索・引用するよりは、自分でさっさと設計を始めてしまった方が、担当者本人としては楽だからです。
しかしこれを野放図にしておくと、設計者個人毎に「自分しか使えない蓄積」が構築されてしまい、部品や工程の標準化が進まないどころか、製品の品質まで、設計者毎にばらついてしまう、由々しき事態となります。
このような事態を避けるため、多くの企業では標準図を定めて、そこからの流用設計を促していますが、努力レベルで終わっているのが大半です。流用設計の結果はあくまでその場限りで、次からは再び標準図に立ち戻るやり方では、設計者自身にメリットが感じられないからです。


３．個別の設計結果も再活用する

そこで、これでは設計者の個人蓄積になっていた個別の設計結果を、組織として再活用することを考えてみてはどうでしょうか。
それには過去の設計結果を、①手配実績（取引先・価格・納期）とセットで蓄積し、②営業担当者にも公開することがミソです。
受注設計製品では、出図後の部材手配が、全体の納期や品質に大きく影響しますが、一度でも手配実績のあるものは、価格・納期の見積を立てやすく、取引先との交渉も楽です。QCD全てに良いことは営業担当者にもわかりますから、類似受注・リピートを意識した受注活動が進むようになります。設計担当者にしても、価格と品質が最初から読めるのはありがたく、引用元との差分に留意しておけば、取引先との打合せを含め、設計時間の短縮を期待できます。




４．関連する実績を紐づけて蓄積する

受注設計の結果は、商談情報を営業、図面や仕様明細を設計、調達価格を調達と、バラバラで蓄積されていることが多いと思います。その際、営業と設計以降との管理番号体系が異なるのはよくある話ですが、問題は、相互に直接参照する術が殆ど用意されていないということです。
相互参照を可能にするには、蓄積の際に共通のコードを振っておく必要があります。
その上で営業担当者が共通コードを意識し、今回商談との要件差異の形で設計に伝える、この商談サイクルを繰り返すことによって、本当に再利用の進む蓄積が行われます。




５．通常構造とモジュール構造との違い

通常の製品は、「型式　＝基本部分＋オプション」の標準構造を取り、①型式の決定→②オプション選択、の順で仕様が決定されます。
この場合、顧客要件の違いはオプションでしか吸収できませんから、その範囲で対応し切れない場合は、近い型式を選んで改造することになります。その場合、たとえ改造箇所が一部であったとしても、製品全体のアライメントを取る必要が生じ、これが設計者の大きな負担になります。更に改造は、設計者の独自仕様に陥りがちなため、部材の手配も、製作工程も個別対応になってしまいます。


モジュール構造を持つ製品は、「ベース部位（不変）＋モジュール部位（選択）＋都度設計部位」の構造を取ります。
すなわち、型式のみで製品の機能構成が決まるわけではなく、モジュールの組合せによって、同じ製品でありながら、機能と構成が大きく変わります。
またモジュール構造の特徴として、組合せの結果が所定の性能品質を得られるよう、プラットフォームという共通のインタフェースルールを設定します。このルールに従う限り、モジュールの独立性が保証されるので、新たに追加する場合も、他の部位とアライメントを取る必要はありません。
ベース部位とモジュールは標準化されているため、これらについて規模の経済が追求できることは、言うまでもありません。



６．受注設計製品におけるモジュールの決め方

モジュール型構造を持つ製品は、パソコンなどの見込生産品に多く、これらは開発段階で演繹的にモジュールが設計されています。
それに対し、受注設計製品では、過去の設計結果を分析して、帰納的にモジュールを決めるのがよいと思われます。
ある部位に着目して、個々の設計の起点である、顧客の要求仕様を横軸に、個別の設計により実現した機能を縦軸に取ると、左上図大小の円プロット（実際には不定形）のようになります。
また要求仕様の出現頻度を縦軸に取ると、充分なサンプル数下においては左下図のようになります。
そこで
　
１）出現頻度を元に、モジュール化の仕様範囲を決める
２）その範囲を幾つのレンジで区切るかを決める
３）区切ったレンジ毎に個別のモジュールとする

の順序で検討を行うことにより、受注設計製品においても、モジュールを決めることができます。
※なおこの方法では、最初に対象部位を決めてから、検討を始めています。すなわち、この部位と他とのインタフェースを変更しないことが前提であり、これがプラットフォーム定義になっています。




７．モジュール展開レベルを求める

特定の部位に着目すると言いますが、実際にはモジュールを展開する製品構造のレベルを、どのように求めたらよいのでしょうか。

一つの例をご紹介します：

１）対象の製品を選んで、VE（Value Engineering）手法を用いて、製品の機能体系に展開します。これと製品構造とを対比させて、左図のような「機能－構造図」を作成します。

２）通常、機能と構造とは「多対多」の関係になりますが、これを「機能が１なのに対し、構造が多または１」となる、機能がこれ以降変化しないレベルまで、機能と構造のそれぞれについて展開をしていきます。

３）もはや機能が変化しないのに、構造を変化させても意味はありません。機能の変化が無くなる箇所に対応する、製品構造のレベルを見つけ出し、これをモジュール展開を行うレベルと定めます。

４）このレベルにおいて、機能の変化に応じたバリエーションを持てば、代替モジュールとなります。




８．モジュールバリエーションの整理


モジュールのバリエーション展開は、どのように考えたらよいでしょうか。
顧客の要件は、機能に関するものであったり、方式や作動条件に関するものであったりするので、これが区別できるレベルまで、製品の機能展開を行っておきます。
その上で、製品の機能と構造を対比させた上で、過去の設計実績から「同じ機能／方式／動作条件でありながら、構造・材質・形状が異なる」ものをカウントしてみると

１）①の部品は、明らかにバラエティが多過ぎるので、この整理が考えられます。
２）同じ機能を構成する部品②③は、もともと同じユニットに付いているので、この統合が考えられます。


関連商品： 「設計・生産改革」コンサルティング
弊社HP掲載：http://www.jbc-con.co.jp/consul_service/pdf/STC06.pdf
イプロス掲載：http://www.ipros.jp/products/141048/019/

困ったときはここ！「 ビジネス解決の玉手箱」
http://www.jbc-con.co.jp/consulting/index.html

コンサルティングのお問い合わせ先：
[e-mail] にお気軽にお問い合わせください