ホーム > 記事一覧 > キーワードから事例を探す > 情報マネジメント > PDM（製品データ管理） >

人的資源マネジメント:製品開発の滞留を引き起こすファイルとは（その1）

更新日 2022-08-22

投稿日 2018-03-14

　今回は、PDM/PLMに代表される製品開発業務のIT化をどのように考え、進めるのがよいのかについて解説し...

　今回は、PDM/PLMに代表される製品開発業務のIT化をどのように考え、進めるのがよいのかについて解説します。

　前回まで続けていたテーマはいったんお休みして、今回は、PDM/PLMに代表される製品開発業務のIT化をどのように考え、進めるのがよいのかについて解説したいと思います。IoTやIndustry4.0の影響から、PDM/PLMの導入や、外部組織とのネットワーク化などを進めているという話を聞くことが多くなっているのですが、そもそも社内がつながっていない、開発関連データの管理オーバーヘッドが増える一方というような課題が放置されているからです。

1. 台帳が増え続けることによる業務効率の低下

　製品開発現場には部品や部品表、図面などに関係する様々なデータが存在しているわけですが、それらをマイクロソフトの Excel や Access で管理されている開発現場が数多くあります。「台帳」や「マスター」という単語を含むファイル名になっていることが多いので、調べてみるとその数の多さに驚くと思います。「台帳」や「マスター」というファイルが増加していく原因と、それらの増加が開発業務にどのような影響を及ぼすのかを、あるメーカーを例にとって解説したいと思います。

　このメーカーは、これまでに使った部品すべての型式や購入価格などを Excel で作成した部品台帳で、設計図面やその作成日や作成者などは図面管理台帳で、そして、作成した製品の部品構成（部品表）は部品構成台帳で、いずれも Excel ファイルにして管理していました。この他にも、製品開発業務で共通に必要となるデータは台帳にして管理しており、これらすべての管理台帳は Excel で作成していました。

　Excel で作成したこれらの台帳は、誰もが簡単に扱うことができ、検索などもできるので技術者全員が便利に使っていたのですが、開発している製品ラインナップが増えたことで、ひとつだった設計部署が３つに分かれ、さらに、新しい顧客向けの製品の開発・製造を行う事業所が新設され、並行して部品コードの見直し、部品発注方法の見直しなどの業務改善活動を行う中で、次のようなことが起きました。

　増えた設計部署がそれぞれで部品コード台帳を管理することになってしまった上に、部品コードの見直しによって旧部品コードと新部品コードが並行して使われることになったため、ひとつの Excel ファイルだった部品コード台帳から部品に関する多くの派生ファイルができました。たとえば、事業所ごとに使われている部品がわかるように作成した「事業所別部品台帳」や、旧部品コードで部品検索するための「旧部品コード台帳」、全社の部品をひとつにまとめた「品目コード台帳」などが作られたのです。さらに、このようにして作られた派生の管理台帳は、それぞれ作成した人の好みで Excel だったり Access だったり FileMaker だったりしてファイル形式もバラバラでした。

　部品コード台帳に限らず、部品構成表などの他の管理台帳も同じ状況でした。図175はこのようにして増えていった台帳を示しています。

図175. 業務拡大に対応することで増えていく管理台帳

　増えていく製品や新しい顧客への追従、業務の効率化、顧客要求やトラブルの対応など、それぞれの部署で必要に迫られて前向きに対応したことが、利用方法や管理方法が少しずつ違う同じような台帳を増やしてしまったのです。

2. 増えた台帳が滞留を引き起こす

　このような状況になっている開発現場は決して少なくないのですが、派生の台帳とはいえそれぞれの目的に沿って作ったものだから問題ないだろうというトップ・マネジメントも少なくありません。モノの流れとは違い、データの流れは見えにくいことが原因かもしれませんが、派生の台帳が増えれば増えるほど、その派生台帳の使い方は手間がかかるものになり、維持するためのメンテナンス作業も複雑化し開発業務の流れを妨げる原因となるのです。図176 は、この開発現場で設計から生産開始までに関係している主な管理台帳とデータの流れを表したものなのですが、これを見ると、派生台帳の存在が多くのデータのやり取りを生じさせ、さらに、そのやり取りの多くが手作業になるために必然的に開発業務が滞ることになります。

図176. 増加する管理台帳が業務滞留を引き越す

　たとえば、ここの技術者は部品を特定するために部品型式が必要なため、部品データが記載されているすべての管理台帳には部品型式が登録されており、さらに部品構成表（部品表）関連の台帳にも部品型式が登録されています。その結果、新規部品を採用したときや変更があったときは、これらすべての台帳に一字一句間違わないように部品型式を登録しなければなりません。部品型式だけでなく、部品名称や価格なども同じように複数の台帳に登録されていると、部品名称や価格が変わるたびにすべての台帳を漏れなく更新しなければなりません。

　このように、台帳に記載されているデータを正しい状態にするのは派生の台帳が増えれば増えるほど大変な手間となり、開発作業の効率はどんどん低下してしまいます。入力ミスや入力漏れなどによる手戻りを引き起こすことになりますし、すべての台帳を正しい状態にできない場合は、参照した台帳によって部品型式が違う、価格が違うというようなことが起き、違う部品を発注してしまったり、想定していた原価に収まらなかったりして大きな手戻りとなってしまうからです。そもそも、部品、部品表、図面に関するデータは相互に関連しているものなので、それらを管理している台帳が増えることで相互の関連がより複雑になり、データの利用や保守により手間がかかることになるのは当然の成り行きです。

　この開発現場のように、顧客要求への対応や作業の効率化、トラブル対応などに個別に対処していると、その都度、派生台帳が増えることになり、全体で見るとその度に業務効率を下げてしまうことになります。現場で個別に対応している限り、このような状況になるのを避けるのは困難です。

　次回もこのテーマを続けます。

◆関連解説『情報マネジメントとは』

　続きを読むには・・・

新規会員登録