多事想論articles

標準化の落とし穴

 製品開発に関わっている方であれば、少なからず「標準(化)」という言葉を耳にしたことがあるでしょう。「標準部品を組み合わせて製品を開発する」、「標準開発プロセス」、「○○標準化活動」等、製品開発部門でも接することが多い言葉です。そのことが象徴するように、現在の製品開発において「標準化」は重要な取り組みの一つとして認識されています(本稿では「標準」を作り、それを活用していく取り組み全体を「標準化」とします)。

 改めて標準化の効果を考えてみると、開発プロセスや設計手順を対象とした標準化では、プロジェクトマネジメントの質や製品品質の確保等を挙げることができます。さらに標準部品を定義し使う場合には、製品開発フェーズでの効果に加え、生産、調達、管理等、バリューチェーンの広い領域の業務効率化に貢献することができます。 そのため、グローバル化にともなう市場の多様化、製品の複雑化・高度化等に対応しつつ、QCDを維持・向上する、という多くの製造業が抱えている課題への対応策として、標準化はますます重要になってきています。

 その一方、標準化には2つの落とし穴があると考えています(ここでは社内的な取り組みとして、標準を定義し使う部品・開発プロセス・設計手順・評価等を対象として述べます)。

(1) 隠れた前提に気付かないで不具合に至ってしまう
 一般的に標準には、前提があります。例えば「新しい技術は採用せず、従来技術の改良を行う製品を対象とした開発プロセス」、「**方式の製品に使用できる標準部品」等です。これらの前提には、例えば「使用可能な温度領域」のように明示されているものもありますが、明示されてないものも多数あります。 標準部品を例に挙げると、部品の使用条件には、温度、湿度、紫外線、荷重が作用する周期等、様々なものがありますが、すべてのものが書かれているわけではありません。それは、前提を厳密に書こうとすると、ありとあらゆる条件を挙げる必要が出てきて、際限がないためです。すべてを記述することができないため、「常識的な範囲」で条件が変化した場合に問題となるものを中心に記述し、それ以外は記述を避けているのです。 これらの明示されていない前提を把握せず、そこから外れた使い方をした際に、不具合を起こしてしまう可能性があります。デザインレビューの場で「標準部品を使っているから問題がない」と言う発言を耳にすることがよくあります。これは前提が合っている状態での判断としては適切かもしれませんが、必ずしも前提が合っているとは限らないのではないでしょうか?

(2) 枠にはまった製品を開発してしまう(標準部品の場合)
 標準化の活動を進め標準部品が増えてくると、それらを積極的に活用することを求められることがあります。同じ部品を使って開発を進めるわけですから、ともすれば出来上がるものも同じようなものになってしまう、標準部品が制約となって目標を達成できないという事態に遭遇する可能性があります。

 では、これらの問題に対して、どのようにすべきなのでしょうか?

 (1) の問題に対しては、「標準を疑うことを標準化する」ことが必要です。
すなわち、開発中の製品を取り巻く環境が、標準の前提から外れていないか疑う、もしくは標準が適用できる理由を明確にすることで、隠れた前提を明らかにします。これを設計者の心得とすることはもちろん、エキスパートを交えたデザインレビューの場で確認項目とすることなどが具体的な対策となるでしょう。

 (2) の問題に対しては、「標準部品を使うところを見極める」ことが必要です。
開発等の業務効率を追求するために標準部品を使うべきところ、製品の価値を高めるために力を掛けるところを見極め、後者については標準を超えられるよう、努力をする必要があります。

 さて、(1)と(2)の問題は異なった現象ですが、「標準との向き合い方」という観点で本質は同じです。いずれも、標準を絶対的なものとして捉えているため、過信したり、必ず守る必要があると諦めてしまっているのです。 同様に、上記に挙げた対策も本質は同じです。隠れた前提を明らかにする、標準を超えられるようにする、いずれも実際に進めていく際には標準が決まった経緯を紐解き、中身を理解することが必要となります。 例えば、標準部品の場合、経緯を紐解く際に活用できる一つの手法として、技術ばらし(※)があります。 技術ばらしを用いた場合、定性的な検討にはなりますが、部品設計において考慮すべきことを広い視野で明らかにできるため、隠れた前提を明らかにする、標準を超える際の問題の発見や対応策の着想に至ることができます。

 標準は効率化のための手段なので、製品開発の狙いや制約に対して「標準を上手く活用する」、という柔軟な姿勢で臨むことが重要なのでしょう。

※技術ばらし手法
 製品の開発要件(設計で達成すべきこと)と、開発要件を達成するための手段である、設計要素の関係を明らかにする手法。

/articles/column/images/20130313_zu.png

執筆:春田和宏
※コラムは執筆者の個人的見解であり、iTiDコンサルティングの公式見解を示すものではありません。

資料ダウンロードはこちら