第145回 設計部門BOM改善コンサルの現場から～その74～設計変更（設変）のジョブフローを考える。「その2」～設変に対するジョブフローが整流されていない中小中堅製造業～
設計変更（設変）という製造業の大変重要なフィードバックサイクルが、うまくジョブフローとして流れていない場合を多く見ます。前回は設変の起承転結の「起」としてECRという視点で述べましたが、今回はその「結」となるECN（Engineering Change Notice）の全社効率を高める考え方を述べてみたいと思います。
設計部門BOM改善コンサルの現場から～その74～設計変更（設変）のジョブフローを考える。「その2」～設変に対するジョブフローが整流されていない中小中堅製造業～
突然の寒さに体がついていきません。秋という寒さへの準備期間がなくなってしまったような……
冷凍庫には買い過ぎた「シャリ金」が残されたままになっています。「君は来年まで冬眠だね」と諭しています。
本年最後のコラムになりますが、まずは本年のご愛読を感謝いたします。
中小中堅製造業に残された課題はいまだ山積みになっています。来年も「コンサル現場」から見える、感じさせられる課題を皆さんと一緒に考えていきたいと思っています。
どうぞ皆様、良いお年をお迎えください。
前回は、「設変」ワークフローの起承転結の「起」にあたるECRのあるべき姿を説明しました。
何らかの設計に起因する不具合や微修正、さらにディスコン部品の置換等々、ECRを起票する要因は多種にわたることを理解してもらったと思います。肝心なことは、そのECRをどのようにうまくワークフローに流してゆくのかという発想が大切であることも述べました。
「結」となるECN（Engineering Change Notice）の効率と実効性を高める
「起」としてのECRを受理して「承・転」となる審査処理、不具合修正、再設計などの設計責任を果たすのは設計部門です。従って、最終結果としての「結」であるECNを発行する責任部門は同様に設計部門となります。
もちろん、ECNはNoticeですから、その結果としての内容情報の全社共有は必須なのでしょう？
しかし、悩ましいのはそのECNの内容情報が全ての部門に本当に必須なのか？ という点です。
いろいろな会社のECNの実態を見ましたが、特に「紙回覧」している場合は、以下の問題が散見されます。
- あまりにもページ数が多くて、閲覧する時間が取れず「放置」される。
- 回覧をせかされ、適当に判を押して次の回覧先へ送致、結果ECN内容の精査や共有ができていない。
これらの実情は、ワークフローをICTで実現したとしても、同様な結果が生まれるでしょう。
このような実態の本質的な原因は、「このECNの束には我々の部門に重要な情報は含まれていないのでは？」という先入観が存在し、本来のECNの重要性を軽んじてしまうからだと考えています。
「必要な情報が必要な部門にしっかり届く」という効率の良いECNとはどのように考えるべきでしょうか？
そこには、「新規開発に伴う設変」というキーワードが存在すると考えています。
例を挙げますと……
1. 新規開発した部品・製品の設計不具合修正に関わるECN
保守部門には、まだ製品として市場に存在しない部品・製品に対してのECNは不要かもしれません。
2. 新規開発した部品・製品の「軽微」な修正に関わるECN
設変の内容情報としてのECNに直接影響される購買部門・生産部門ですが、本当に全ての情報が必要でしょうか？
この「軽微」な修正とは……
図面・ドキュメント（取り扱い説明書・マニュアルなど）の誤字脱字修正や「互換を失わない」変更は、購買部門として必要でしょうか？ もちろん「互換を失わないという定義」に関しては、設計部門との認識のすり合わせが必要ですが、図面中の誤字、脱字、引出線変更などによる図面の認識番号である図面番号変更は、品目コードが更新されないという条件下であれば、ICTによる最新版図面管理に任せておけば良いわけです。
これらから、「新規開発に伴う設変は設計部門内で自己還流させて、他部門をできるだけ巻き込まない」という考え方が必要だと考えています。
新規開発番号という品目コード体系の確立
ここで、何度も述べている推奨品目コード、図番コード体系を思い出してください。
これに対し「開発専用品目コード体系」という考え方を提案します。
- ＊ X：開発品目であるマーカー
- ＊ 23：2023年度を表す
という一例です。
体系としては、「X」という開発品専用コードであることと「23」という開発実行年度を付加した形です。
つまり、この一例は標準品目コード体系から分離することが目的です。開発年度を明確にして、新規開発部品（購入品）を連番で取得して行きます。
この品目コード体系で設計された部品・ユニット・製品群は新規開発品であり、「没」「不具合変更後採用」「採用」と開発完了まで、それらの行く末は分かりません。そして、そこには多くの軽微なものから大きな「設変」まで含まれるはずです。
これら「混沌（こんとん）とした状態」の設計成果物の「設変」に対し、「下流側部門をできるだけ巻き込まないようにする」という考え方です。これは標準設計変更ワークフローから離脱して、やってみなければ分からない開発、新規ノウハウ開発等々の新規設計環境で実行するという考え方です。
さらに付け加えれば、大切な資源である標準品目コードの無駄な消費（欠番）も防げますし、発番年度が分かりますから、ある年月が経過したら一括消去してデータベースを軽くすることもできます。
「下流側部門をできるだけ巻き込まないようにする」設計変更ワークフロー例
1.開発品目コード＋標準品目コード（流用部品）で出図
BOM構築できればなおさらですが、実際は難しく買い物リスト状態や五月雨出図でしょう。
2.開発の完了
この間、不具合対応は開発品目コードでECR・ECNは設計部門内で還流する＝必要最小限で良い。
3.標準品目コードへの置換とBOM構築
開発品目コードを標準品目コードに置換。同時に不具合修正を済ませてBOM構築（最も重要！）。
4.開発コードと置換した標準品目コードを購買部門に共有
購買部門には開発コードと置換した標準品目コードとのひも付け情報（基本属性情報など）を渡すことは大切。
既に気付かれている方もいると思いますが、このコラムのコンセプトでもある「設計部門を二階建てにする」につながる二階からのアウトプットされる設計成果物のカタチを目指しているのです。
新規開発製品、新規ノウハウの獲得など、明らかに設変が想定される設計成果物の設変は、設計部門内で還流させて、完成の暁には正規品目コードによってBOM構築を再実行する。そして下流側には新規品としてあらためて出図するという考え方です。
このことにより通常のECNの内容は流用品・標準品のみに対応することとなりますから、ページ数（枚数）は減り、下流側に必要な重要情報の密度は高くなります。
ECR・ECNに関わるジョブフローはISOで決めてはあるが、そのとおりに運用できていない。
ISOどおりに設変を回すとECNがとんでもないページ数になってしまい回議されない、などの問題回避策として、ぜひ一考ください。
再述しますが、ECR・ECNは製造業としての根幹であるQCDの改善を支えるジョブフロードキュメントです。このジョブフローが滞りなく回るための工夫の一案として前回・今回のコラムで提案しました。
以上
次回は1月5日（金）の更新予定です。
書籍ご案内
当コラムをまとめた書籍『中小企業だからこそできる BOMで会社の利益体質を改善しよう！』とその第二弾としての新刊『BOMで実践！設計部門改革バイブル 中小・中堅製造業の生き残る道』を日刊工業新聞社から出版しています。
BOM構築によって中小企業が強い企業に生まれ変わる具体策とコツをご提案しています。
Nikkan book Store（日刊工業新聞社）