第59回　増え続ける Excel ファイルが製品開発の滞留を引き起こす

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

こんにちは、RDPi 石橋です。

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

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

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

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

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

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

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

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

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

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

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

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

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

様々な要因へ個別に対応していることで管理台帳が増えていくわけですが、管理対象である部品や部品表、図面に関するデータは相互に関連しているので、図177 に示すように様々な問題を引き起こします

図177 増加する管理台帳が引き起こすトラブル

登録してある部品型式などの不一致や記載ミスがあった、製品コードなどの必要なデータがどこの台帳にあるのかわからない、登録してある図面番号が古いままだった、マクロで自動化してある台帳更新をマクロ作成者が異動したので修正できない、というようなトラブルが発生し、その対応に時間をとられることで全体の業務効率を下げてしまうのです。現場で個別に対応していて管理台帳を変更したり増やしたりしている限り、このような状況になるのを避けるのは困難です。

Excel などの慣れ親しんだツールを使ってデータを管理するというのは開発業務の IT 化の第一歩です。しかし、製品開発の上流から下流までを視野に入れた全体最適となる業務やデータの設計を行わなければ、IT 化による効果は非常に限定的なものになるばかりか、かえって非効率なことになってしまいます。十分な注意が必要です。

また、ISO などの影響かもしれませんが、業務フローばかりに注意を向けて規定化することが全体最適と考えている開発現場も少なくないようです。PDM/PLM 導入など IT 化を成功させるために大切なのは、業務に注目して効率化をするというよりも、個々の業務で必要となるデータに注目して全体最適となるデータとその流れを設計するということです。第49回 で解説している設計・製造リンクのような考え方が必要不可欠なのです。

図178で示すように、設計・製造リンクは、受注からはじまって、設計や手配、製造といった一連の業務（開発工程）に必要なデータを適宜提供し、データによってそれぞれの業務をスムーズにつなげる開発のプラットフォームです。データ視点で開発全体の最適化を行うことで、進化する技術や部品への追従、新規顧客や新規領域の開拓、厳しい顧客要求への対応、技術者のさらなるレベルアップなどの外部や内部の環境の変化にすばやく柔軟に対応することができるのです。

図178 設計・製造リンクは開発全体最適のプラットフォーム

PDM/PLM は設計・製造リンクの中核となるシステムですが、設計・製造リンクの構想がない状態での PDM/PLM の導入は、その後の運用において大きな混乱や滞留を生じさせることになります。実際、PDM/PLM にかかる費用や投入した工数に見合う投資効果を得ていないというマネジャーの不満や、システムに縛られてかえって効率が落ちているという開発現場からの不満をよく聞きます。

このような PDM/PLM を導入しても十分な効率化ができていない、もしくは成果が出ていない組織のほとんどは、IT 化を技術者の片手間でやったり、タスクフォースや委員会を設置して兼任で進めたり、構想や設計からシステムベンダーに丸投げしたりしています。実は、設計・製造リンクのような全体最適となる設計・製造の IT 化ができない最大の原因は、自社で開発業務全体を視野に入れた IT 化要員を置いていないことなのです。

PDM/PLM の導入などによる IT 化を行った後、顧客や製品、部署などの変化に対応する必要が生じたとき、PDM/PLM のどの部分に変更が必要なのか、その変更がどこに影響するのかなどを自分たちで判断できずシステムベンダーに頼るしかないとしたら、どういうことが起きるでしょうか？

システムベンダーがすぐに対応してくれるとは限らず、対応してくれたとしても短期間での対応には通常よりも多額の費用が必要となるでしょう。その上、現状業務の調査からはじめることになって短期間の対応とはいえなくなり、さらに、思いもよらないところに影響があって手戻りを繰り返すようなことになり、結局稼働できるまでに長い時間がかかってしまうことにもなりかねません。そして忘れてはいけないのが、システムベンダーに頼んでいるにもかかわらず、現状調査や設計、テストなどに、社員が多くの時間をとられてしまうということです。

PDM/PLM の導入などの IT 基盤構築は自分たちの主業務ではないからと、システムベンダーに頼ってしまっては、必要最小限の工数で迅速かつ的確に開発業務の変化に対応することはできません。自分たちで製品開発業務を考え、自分たちで PDM/PLM などのシステムやツールをどのように拡張したり変更したりすればいいのかを設計することが大切なのです。その上で、拡張や変更の実作業をシステムベンダーなどの外部にやってもらえばいいのです。

PDM/PLM からなる設計・製造リンクは、自社の開発に合った固有の業務基盤であると同時に、ビジネス拡大のために継続的に成長させるべきものなのです。この認識があれば、片手間にシステム導入を行ったり、システムベンダーに丸投げすることはないはずです。自社内に設計・製造リンクを構築するための IT 要員を置き、自社内に自社の開発におけるノウハウを IT 化するための知見・スキルを蓄積することが必要不可欠です。

自社内で IT 化要員を置き、全体最適となるような設計・製造リンクを構想し設計した上で PDM/PLM の導入・構築に取り組むことができれば、その実装方法の選択肢も広がります。

たとえば、自社の設計・製造リンクに合うパッケージを購入して自分たちで設定やカスタマイズをすることもできますし、要求仕様を具体化した上で実装はシステムベンダーに任せることもできます。もちろん、市販のデータベースを使って自分たちで最初から開発することもできます。いずれの実装方法であっても、自社の IT 化要員が全体を構想・設計しているので、顧客要求の変化や効率化のための業務変更などに迅速に対応することが可能です。

図179 は、あるメーカーで設計・製造リンク構築を進めるために関係している部署からメンバーを出してもらい作ったチームです。メンバーには、PDM/PLM の導入などの設計・製造リンク構築の実務を担当してもらうととともに、今後の IT 化を進める中心的役割を担う人材となるためのトレーニングを実施しています。そのため、各メンバーには設計などの自分に関係する業務領域を担当してもらい、実務を通じて、業務分析・設計やシステム設計、業務やデータフロー設計などのスキルを身につけてもらいました。

図179 設計・製造リンク構築チーム

このメンバーで、各種 CAD や PLM、製造における自動機などの導入など、設計・製造リンクのシステム構築を行い、開発期間の半減などの大きな効果を上げています。実際の育成方法は別の機会に紹介したいと思いますが、トップが決断すれば、社内のメンバーで IT 化を進めることが可能なのです。

設計・製造リンクを構築することは、Industry4.0 や IoT に対応するための大前提にもなっています。ビッグデータを活用し外部との密なネットワーク化を進めるには、まずは自社内のデータ化、ネットワーク化ができている必要があるからです。Industry4.0 などの新しい時代で製品開発を継続するためには、製品の設計・製造のための技術者を育成と同様に、製品開発のための IT 基盤構築のための技術者の育成にも力を入れることが必要不可欠です。その重要性は大企業はもちろんのこと、中小企業であっても同じなのです。

今回も最後まで読んでいただきありがとうございました。