第82回設計部門BOM改善コンサルの現場から～その18～　設計部門に存在する壁、設計部門の統合の実際　その2

競合がある以上、事業部や企業でさえもが分割・統合を繰り返してサバイバルしていきます。結果、異なる企業や事業部の設計対象製品であった設計部門も統合されることになります。今回は、前回の「その1」に引き続き、そういった統合の際の、部門全体の効率向上に留まらず生産部門も含めた全体の効率向上を目指す為の考え方を述べてみたいと思います。

設計部門に存在する壁、設計部門の統合の実際　その2

酷暑＋台風＋ゲリラ豪雨です。トロピカルな荒々しい天候が続きます。
このところホッピー＋VODKA（ウォッカ）にはまっています。先般フィンランドで大量仕入れしてきたLAPLANDIAというウォッカです。白樺の炭でろ過しているため、ほのかなキシリトールの甘さが良いアクセントです。旨し。

個人所有の設計ノウハウや成果物

「その1」では、統合不全の設計部門やM＆Aに必須となるノウハウの吸収に関わる考え方や目指すべき結果・効果を述べました。そして、私がそれらを実行したときの思いとして「筆舌に尽くしがたい体験」と述べました。「その苦しい体験の主因は一体何だったのか？」と今、あらためて考えてみると「個人所有の設計ノウハウや設計成果物」との戦いであったからだと思います。その意味で、主目的が同じである設計部門統合もM＆Aも解決への基本的なアプローチはほぼ同じなのだと言えるでしょう。

「設計部門の統合もM＆Aも当社には関係ない」と感じている皆さんも決して無縁ではないと思います。
ある、コンサル先の設計部長の会話でこのような話が聞けました。「この間、設計部門OB会があって、とっくに定年退社した設計者が、『あの機械の設計資料一式、段ボールに入って我が家にあるよ』と言っていました。その機械は当社の主軸機械なのです」とのこと。

開いた口が塞がらないという表現は過剰かもしれませんが、蛸壺設計の繰り返しで設計資料も蛸壺に入れたまま退社してしまったということでしょうか。コンプラがどうのこうのというずっと手前のできごとです。しかし、これは設計者だけの問題なのでしょうか？自分の設計したものに対するノスタルジアは多少存在するにしても、普段からノウハウ・成果物を確実に2Sする習慣があればこのようなことは起きないと思います。

皆さんの会社は大丈夫でしょうか？このようなことは起こっていないでしょうか？
設計部門統合やM＆Aを始める対象の実態は設計ノウハウ・成果物がどこかに集約されているわけではなく、個人所有のまま設計担当者のみの記憶がおよぶ範囲の存在となっていたわけです。従って、設計者が50名いれば50の個人所有の設計ノウハウ・成果物が「点在」していました。そして、この点在してしまっている現実を見せつけられた私は「どうすれば良いのだ、どこから手を付けるべきか？？？」とただ呆然とするばかりでした。

一人ひとり面接しながら「所有するノウハウ・成果物を全て出して」と刑事の取り調べのごとく実行することも考えましたが、すべてを詳らかにしてくれるとは限りません。さらにその「点在」するノウハウや成果物がどのように連動・連携して「線」になっているのか？部外者の私には、おいそれとは理解できません。本当に困り、悩み、考えました。この時点が一番苦しかった様に記憶しています。

そこで、悩みぬいた私が最終的に辿り着いた方策は「設計プラットフォーム」の構築でした。
これらの点在してしまっているノウハウや成果物を「集約する受け皿」がまずは絶対必要と考えたのです。受け皿としての設計プラットフォームです。
受け皿たる設計プラットフォームにすべてのノウハウ・成果物を「いったん、全て吐き出させる」。
それが可能となれば、何とか始められると手探り状態ではありましたが確信したのです。

どうやって統合するのか？どうやってノウハウ・成果物を吸収・蓄積・共有するのか？

設計プラットフォームのイメージは過去のコラムを参考としてください。

＊参考
第75回設計部門BOM改善コンサルの現場から～その12～　中小製造業・設計部門の「働き方改革」とは？ Part2（ERPナビ）

後は、どのように「吐き出してもらえるか」にあるわけです。
統合される、もしくはM＆Aされた側の設計者の立場で考えてみましょう。

まずは、自身の所持しているノウハウ・成果物こそが自身の存在価値と考えるでしょう。つまり、特にM＆Aの場合、この存在価値がリストラ対象から外れる「抑止力」と考えるでしょう。であれば、簡単に吐き出してはくれないということになるわけです。M＆Aばかりでなく普段の設計部門においても自己ノウハウの開示を嫌う設計者が存在することは確かです。これほど意味のない、勘違い保身は無いのですが、このような場合も同様な対処が必要です。

そこで、私は以下のような「業務命令」を発令しました。

設計に関わった機種・製品に対するE-BOMを構築すること
BOMの構成部品は2Sを行って、可能な限り属性情報を付与すること
1、2項を設計プラットフォーム上で実行すること

本コラムを愛読されている方を混乱させてはいけないので、少し説明を付け加えたいと思います。
通常状態の設計部門における流用化・標準化設計プラットフォームの構築には、設計者のモチベーションを抑圧してしまう「業務命令方式」は馴染まないというのが持論で、今までも何度か述べてきました。しかし、今回の事例はそのような尋常な状況ではないことは理解してもらえると思います。「敵対的」とまでは言いませんが、それに近い関係が存在していることも否定できないわけです。

これらを、期限を定めて、進捗レビューを行いながらジワジワと吐き出してもらいました。
何よりBOMの効果を感じたのは、点在するノウハウ・成果物をBOMが「線」として私に理解をさせてくれたことです。
各ユニットの機能と各ユニットの相関関係そしてそれらユニットを構成する部品群の担当機能を白日の下に晒してくれました。

故意にノウハウを隠ぺいしようとしてもBOM上で必ず矛盾が生じ、いわゆるブラックボックス化は不可能でした。属性情報も当初は個人ごとの野放図状態でしたが、蓄積が進むにつれて統一していく機運も生まれてきました。BOMにしても2Sにしても「可視化」が進むとバラバラのままでは放置できなくなるのが設計者魂？でしょう。

進捗レビューは毎回、毎回まさにデザインレビューを繰り返していく感じでした。私自身も製品に対する知見が広がっていきました。
予期せぬ効果（？）として、設計者担当者本人も気づかなかった設計不具合を見つけることもありました。
品目コードさえなかった環境で「モノ」を個人管理していくことの危うさと、その限界を設計者は心底知ることになったと思います。

このように設計プラットフォームにノウハウ・成果物が確実に蓄積されることによって、再利用可能な設計成果物のDBとして他の設計者が利用可能な環境が生まれてくるわけです。設計成果物の共有の始まりです。
さらにBOM化によって製品ごとの相関関係が逆展開という形で明確になり、似て非なる部品群や購入部品の同等品重複化もあぶり出すこともできました。

下流側に起こる変化に目を向けると、以下のようになります。

E-BOMが設計成果物として生産部門にアウトプットされることにより、汎用化された生産管理システムを上手く稼働させることができる様になります。さらに生産部門としてのM-BOM構築を習得して、マスター情報に磨きを掛けていくことによって属人化された、「勘と経験の生産部門」から脱却することができます。多種多様の設計成果物に頭を悩ませることなく一元管理していくことが可能となり、結果生産効率を上げて儲かる製造業を目指すことができます。最終的に上流から下流への一気通貫システムの完成を目指すことが可能になるわけです。

設計部門は普段からBOM構築を行うことが何より大切です。これが設計者同士のノウハウ・成果物の共有を促進して設計部門の人材流動化を可能とします。そして設計者自身が多くの部門体験を積むことを可能にするのです。結果、多能スタッフとして成長させることにより「一生一設計者」などという偏狭な人生を歩ませずに済むのです。つまり、統合が上手くいった設計部門の設計者をそのまま設計部門に塩漬け状態にするのではなく、設計者に対する二次育成として、この流動性の獲得は大変有用かつ重要な手段であると思います。

紆余曲折の結果として技術系統が異なる混成設計部門が発生してしまうことや、M＆Aの結果「他人のノウハウ・成果物」を吸収する必要が出てきてしまうことなど、それらを拒絶し続けることは難しい時代になってきたと考えています。

混成設計部門をそのまま放置することや、大金を叩いたM＆Aの結果としてノウハウが吸収できないというような事態を招かないためにも、設計プラットフォームという考え方や実際の仕組みの準備を行い、そしてBOM構築への見識を早急に整えるべきだと考えています。そして、その延長線上に流用化・標準化設計を見据えて欲しいと思います。

以上

次回は10月5日（金）の更新予定です。