設計や開発は独創的な発想が必要で標準化は向かない。と言われる方もいます。
確かに、そういった側面は有りますが、すべてに新たな発想が必要な訳ではありません。
過去の事例、図面などの成果物、仕事の進め方/システムなど、標準化出来る所は標準化すべきです。
具体的な設計にしても、流用設計を極力多くして、多くの製品で、極力共通する部品、あるいは技術を使う事を考え、新たな発想が必要な部分は極力少なくすることが大切になってくると思っています。
設計開発の標準化・流用設計の必要性について
効率化
圧倒的に業務の効率化です。物を検索している時間、無駄な設計、および設計検証を省ける効果等を考えればやらない手はありません。
ムダを省くのはコストダウンの常とう手段でもあります。
標準化を進めると、設計者の自由な発想を妨げる、技術的な発展につながらない。と主張される方も多いですが、考え方を逆にした方が良いと思っています。
クリエイティブな業務に極力集中し、効率化を図り、設計/開発の質を向上するため。
業務の属人化を防ぐ
業務が属人化する要因、メリット、デメリットは？
その業務で特定の人がいないと勧められない状態を属人化と言うようです。仕事が組織ではなく人についている状態です。
私自身、梱包容器の仕事を開始した当初は、担当一人で社内でも誰も経験したことのない開発項目でしたのでまさしく業務が属人化してしまった経験が有ります。
業務が属人化するのは、短期的には効率的な面もありますが、長期的にはデメリットの方が大きいです。
一番のデメリットは、業務内容を周りは担当者と同じレベルで理解していないので、適切なコメントやアドバイスが出来なくなり、誰もフォロー出来なくなる。
担当者は性格の問題もあるでしょうが、説明、共有化するのも無駄、あるいは時間が取れないと考えてしまい、ますます、自分がやらねば。と自分を追い込んでしまうといった、負のスパイラルに陥っていまう。という事が起こります。（私の場合はそうでした）
自分の地位を守るために業務を抱え込むような場合も一般には有るかもしれません。
後、得られた知識が個人の物になりますので、会社の知識/知見として蓄積されません。後任が来ればまたゼロから始まることになります。
業務の属人化を防ぐには？
色々な事が考えられますが、基本はマネージングの問題だと思います。誰もフォロー出来ない状態になるとそもそも、開発の進め方、システムが機能しません。
その為には、やはり、システムがしっかり確立されておりそのシステムに沿って進める事が大切です。システムが確立されて、しっかり運用することで属人化の問題点が明確に見えてきます。
デザインレビューや本格検証が機能しないと思うのであれば、人員の補強を図るなど何らかの対応を取る必要が有ります。
ただし、単純に人員を増加すれば上手く行くとも限りません。本当に必要な対策は何か？良く考える事が大切になります。
知識を会社の知識としていくにはやはり標準化が必要となってきます。
設計開発の標準化の秘訣
- メンバーの意識合わせ、
- 使える状態にするための情報の整備
- 標準化する物、しない物を決める。
- 一度ルール化したら、使う、使わせて改善して行く。
メンバーの意識合わせ
まずは、メンバーに標準化が必要だという事を良く説明し、意識を合わせる必要が有ります。
気が乗らない人がいるのは仕方がないとして、実施する事を承諾してもらう事は必要です。実際にやって効果が実感できれば、反対意見は自然と消滅します。
情報の標準化
情報は、エンジニアにとって非常に大切な仕事道具です。
設計開発に使うすべての情報、例えば、過去のクレーム事例、部品表（ＢＯＭ）、競合他社情報、過去の開発情報などです。
5S活動同様、必要な物が、必要な時に、必要な分だけ、誰でも使えるように維持管理する必要が有ります。
従って、設計/開発の標準化を進めるにあたっては、情報の整理整頓を行う事が初めの一歩になります。
注意点は以下のようになります。
- 共通認識、用語の統一を図る。
- 分類は最低限に、「その他」を作ると破綻する。
- コード化できるものはコード化する。
- 標準化しない物、標準化する物を決める。（整理整頓）
具体的にどう進めるのが良いのかについては別に記事にしていますのでそちらを参照願います。
標準化する物、しない物を決める
活動のすべてを標準化しようとすると破綻をきたしますし、すべてを標準化する必要もありません。標準化するものと必要のないものをまずはっきりさせることが大切です。
- 標準化するには繰り返し使われるか？。
- 関係者で共有する価値があるか？
の観点で決めて行く事が大切だと思います。繰り返しの頻度だけで見れば1年に1度実施するかどうか、といった作業でも必ず実施されるものであれば標準化する必要が有るでしょう。たまに実施する物程、標準化した方が良いとも言えます。
特に初めは範囲を狭くして、まずは運用させて、問題点を洗い出してから広げて行くのが良いと思います。
例えば、実際に試作品に関しては標準化するが、アイデアを遂行している間は一切管理しないと決めるなどです。QMS（品質管理システム）は構築する必要が有るでしょう。
小さく初めて大きく育てる。の考えが大切だと思います。
一度ルール化したら使う、使わせて改善して行く
標準化は実際に進めると、非常に難しく、時間もかかります。準備期間の間は逆に効率が落ちますし、導入後も、皆が使えるようになるには時間がかかります。
途中何度か心が折れかけることも多いですが、標準化については時間がかかっても必ず完成できます。一旦上手く行くと、それまで、否定的な事を言っていた人も便利さに気が付き協力者に代わります。
その為には、遂行担当は自分だとリーダーが自覚するのが出発点になると思います。
これを実施しないと何も変わりません。「成功の秘訣は成功するまで続ける事」といった言葉があったかと思いますが、標準化においてはその考えが非常に大切だと思っています。
流用設計（機械設計）
（設計の流用化を進める上で）最も重要なのは現在までの設計成果物の２Sを用い、専用の部品・ユニット・製品「カタログ」を完成させ、この「標準カタログ」を設計者同士で共有し、ネタ帳であるこのカタログから仕様を満足する部品、ユニットを検索して流用化を図る事です。
BOMで実践、設計部門改革バイブル（株）大塚商会 谷口 潤氏（著）P111より
谷口氏は、標準カタログから、各部品、ユニットまで、たどり着ける情報の整理（階層化）が大切と言われています。
BOMで実践、設計部門改革バイブル（株）大塚商会 谷口 潤氏（著）は機械設計の標準化に関して、色々なノウハウが記載されています。一読をお勧めいたします。
確かに、社内で何か新しいものを検討する場合、過去の社内情報をまずあたりに行くので、情報が整理されている事は大切だと思います。
流用設計の注意点
しかし、十分に実績がある部品、部材でも、別の製品に使う場合には、まったく同じ条件で使用できるとは限りません。出来ないと考えた方が良いでしょう。
従って、流用する場合には、実績が十分だから大丈夫ではなくて、今回の設計は何が違うか？を確認し、それに対して検証（シミュレーションや計算でも良い）することは必要になります。
結局、デザインレビューで流用設計と新規設計を明確にすることが大切だと思います。
プロセス開発の標準化について
ISOのQMS（品質マネージメントシステム）を構築する事を言っています。
標準化というには、これは共通の方法で使える設計、開発方法だというのが無いと共通化とはいえません。そういった目的で発達してきたのがISOなどの規格だと思っています。ただ、この規格は具体的な方法は一切記載されていません。各職場での使いこなしが必要です。私のブログのメインテーマになっています。
「実験計画法」や「品質工学」と呼ばれる方法がありそのような考え方を社内に取り入れて適用できないか考えてみるのは大切だと思います。
ただ、具体的な対策や方策を捻る出すのは、「目の付け所」を共有化することが大切と考えています。
例えば、加工の場合は均一性や異物混入、経時変化による劣化、寿命、個々の技術であれば更にノウハウはあるでしょう。いずれにしても具合に社内でノウハウを蓄積して行くことが大切と思います。
過去の膨大な開発設計情報を見える化して見たい物がすぐに出てくるようなシステム作りです。
対象人数が少なく、資料も少ない場合はまだ対応可能ですが、対象範囲が広がると極端に難しくなります。AI技術のさらなる発展に期待したいです。
まとめ
- 設計開発の標準化の秘訣
- メンバーの意識合わせが前提条件
- 情報の整理整頓が最初の一歩
- 標準化する物、しない物を決める。
- ルール化したら使わせる。使いながら改善。
- 機械設計の流量設計
- 実績（前例）と今回（新規設計）の相違点、その影響の検証、同じものは二つ無い
- プロセス開発の標準化
- 業務の進め方（開発計画書 等）（QMSの構築）
- 専門知識の教育、目の付け所の共有
- 過去の技術の見える化（IT技術駆使）
コメント