第一回「設計・開発の課題にマネジメント視点で取り組む」

2020.7.10 / Dynamic Task Manager

生産現場を支えるITの領域に長年従事した後、コンサルティングファームで経営者に近い立場で企業の業務プロセス改革やIT企画支援などの経験を経て、製造業をお客様に持つIT企業の経営に携わるようになった。再びエンジニアの方々に接する機会が増えたことを嬉しく感じるとともに、あれ?大丈夫?という感覚をもってしまうことがしばしばある。というのも、担当する仕事の情報だけが見えれば良い、他の部門のことにはあんまり興味ない。そんな風におっしゃる方々にちょくちょく出会うことがあるからだ。日々の仕事に追われて余裕がないのはわかるのだが、部門横断のマネジメントはどうなっているのだろうか?

 

 

製造業の上流工程である設計や開発、さらに個別受注型の製品や生産準備の領域では、設計図面や技術情報、工法といった作られるモノそのものに関連する情報を対象にしたマネジメントに重きが置かれてきた歴史がある。しかしながら現代のモノづくりは、製品ライフサイクルの短命化、また世界の地域別マーケットに合わせた開発件数が増えている。さらにBtoBではほとんどが個別受注生産の形態をとる。これらは複数の組織や企業、拠点を横断して行われておりプロジェクト型の業務である。業務を俯瞰する上位プロセスのマネジメント-メタ・マネジメントがより重要になってきていると考える。とかく“モノ”の管理に偏りがちでかつ属人化の課題が言われている上流工程を対象に、組織を横断したプロセスマネジメントの方法やアプローチを、事例を挙げながら考えてみようと思う。

 

設計開発のマネジメント
モノづくり、中でも設計開発のような上流工程のマネジメントに取り組み始めたのは、弊社がAras Innovatorと出会った時期と同期する。それは、ある自動車の部品会社の技術企画 -いわゆる製品の設計開発領域のITを担当している方から一通のメールをいただいたのがきっかけであった。

技術部門の開発業務の効率化、“人・カネ”を管理できるようなテーマが与えられているが、現在の技術部門のシステムは、部分最適化を狙って構築したものばかりであり、部門をつないでいるのは、ほとんど人や紙(ドキュメント)で連絡(連携)しているのが実態です。開発が主業務であるにもかかわらず、営業・製造部門・需給(物流)まで幅広く関わっており、そのため設計者は手配者となり、本来の開発で考える仕事ができていないようになっていると推測しています。』

この後、実際の業務に関わっている複数の部署の代表の方々にヒアリングをして、その実態を探ってみることになった。何を規範にどんな手順で仕事をしているのか、その中で課題と感じていることはないのか。すると、部署によって製品シリーズの違いこそあれゴールは同じはずなのだがプロセスもやり方も異なる。個別の工夫をしているために利用しているITのツールが複数あり、後工程への連携もうまくいっていない。「数年前に比べると開発件数が圧倒的に増えているのにエンジニアの数は増えていないんです。いつもすごく忙しくて残業ばかりです」 そして設計開発から試作までの間には金型設計、製造など異なる部門が関わっているが、後工程の部門では、前工程から最初に来たスケジュールが守られず、それなのに納期は変わらないのでいつも負荷が高いという。

ではこれらの部署、部門を横断して調整する役割はないのか。全体の計画は共有されていないのか?もちろん開発調整会議はやっているが、2週間に1回程度、気が付いた時には手遅れになっている。計画は個別のExcelで作成して配布しているが変更は共有されていない。エンジニア一人ひとりは優秀である。従来であれば個人が“頑張って”仕事をすれば遅れも取り戻せるし、品質問題も抑えられた。しかしながら、開発案件が増えているうえに、工程の一部のプロセスが外注に替わったり離れた拠点になったりしている。もはやエンジニアが工程間の調整や手配に時間を取られている場合ではない。

そこで、弊社が提案したのが、まずは部署横断で仕事の状態が視えてそれらが共有できるようなプラットフォームを持つことであった。元々、量産以降の工場のスケジューラや拠点間のサプライチェーンマネジメントを手掛けていたので、プロセスの連携、視える化、効率化のテーマに同様のアプローチができるのではないかと考えたのである。

 

―次回 第二回ははこちら