 コンカレントエンジニアリングとPDM
 |
 |
生産技術開発部次長 兼
FAシステム開発課長 兼
自動機開発課長
磯川 氏 |
技術情報システム部次長 兼
PDM課長 兼
モートロニクス本部
システム技術部次長 兼
ツール技術課長
斗納 氏 |
 |
 |
技術管理部
技術管理課長
江草 氏 |
技術情報システム部
PDM課
盛山 氏 |
コンカレントエンジニアリングとは、製品の開発期間を短縮するために、設計、 生産、調達といった開発工程を、同時並行的に進行させることをいう。すべての
部品の設計が完了してから、生産、調達を開始するのではなく、部品ごとに設計、生産、調達が進行すれば、製品の全体としての開発期間も短縮できる。これがコンカレントエンジニアリングの考え方だ。
しかし、大量の部品が複雑にからみあっている製品になると、個々の部品の設計 は他の部品に波及する。ある部品に設計変更が発生すると、その部品の生産、調達に波及するだけでなく、関連する他の部品の設計、生産、調達にも波及し、開発の進捗が大きく左右されることになる。
このため、コンカレントエンジニアリングを実現するためには、部品間の関連性 や開発スケジュールを正確に把握する必要がある。また、各工程間での情報伝達も迅速でなければならない。
そのようなニーズから登場したのがPDM（Product Data Management）システムで ある。それは、部品および工程に関する情報をコンピュータで管理し、情報共有と迅速な伝達を実現することで、コンカレントエンジニアリングを支援する。
dbMAGICによる自社開発を選択した理由
もともとPDMとは、CAD製品のベンダーが提唱した概念で、部
品表や構成管理など、CAD図面の管理ツールの位置づけのものが一般的だった。
富士通テンは、97年秋からPDMについての検討を開始し、98年春に提案がまとめられた。この検討過程では、同社におけるPDMの理想が徹底的に議論されたよう
だ。
同社のPDMがAPROS（Advanced PROduct data management System）と命名されたのには、大きな意味がある。APROSのAには、PDMは単なるCAD図面管理ツールでは
なく、生産管理や品質管理と連動したものでなければならない、という独自のコンセプトが込められているのだ。
「CAD図面の管理と日程管理が連動していて、日程管理の画面から図面が取り出せたり、さらには、部品ごとの品質管理を支援するといった機能は、一般のPDMには欠けています。このような機能を実現するには、社内開発するしかありません」（生産技術開発部FAシステム開発課
山口和隆氏）
 |
| サーバー群 |
PDMの構想がまとまり、その実現にむけて、開発ツールの選定が行われた結果、 同社のFA部門で７年の使用実績があるdb
MAGICが選ばれた。優れた開発効率と生産性が高く評価されたからである。
大規模PDMシステムを支えるサーバー群
システム構成図に示すように、APROSは神戸本 社工場にあるサーバー群で構成され、このサーバー群は、神戸工場だけでなく、専用回線で接続された中津川工場
と栃木工場、さらにインターネットで接続されたアメリカ、メキシコ、シンガポ ール、フィリピン、中国からも利用できる。dbMAGICのプログラムを実行するアプリケーションサーバーが5台あり、この5台のサーバーの負荷状況を、3台の
MAGICリクエストブローカが監視している。このMAGICリクエストブローカは、Webサーバーからのリクエストを受け取り、そのリクエストを５台あるアプリケーションサーバーのどれか適切なものに割り振る。
オブジェクトサーバーは、CAD図面や画像データ（TIFF、HPGL、PDFなど）の他、 Word、Excel、Visioなどで作成された仕様書や通知書などのファイル群を保持する。オブジェクトサーバーにあるファイル群のディレクトリ情報は、データベースサーバーにあるデータベースで管理されている。
APROSが提供する４つの機能
APROSは、次の４つのシステム機能で構成される：
1)技術情報共有システム部品図、開発仕様書、製品仕様書などの技術情報を、品番（部品番号）と図番
（図面番号）に関連付けることで、体系的に一元管理する。とくに図面は、品番や図番からの検索だけでなく、タスクからの検索、ECOからの検索、製品ストラ
クチャからの検索など、さまざまな切り口で検索できるように構成されている。 これによって、従来個人で管理されてきたデータも共有化され、技術情報の再利用が促進されつつある。
2)設計変更システムある部品に設計変更が発生した際、それによって影響が波及する他の部品を一括抽出し、変更目的毎にまとめられた変更計画を通知する。
3)図面発行システム
「以前から部品の設計はCADで行われていたものの、関連部門には、図面を紙にプリントして配布されていました。このため、必要な図面の配布もれ、不要な図
面が配布されるなどの問題がありました。また、海外への図面の配布にも、時間 がかかっていました」（技術情報システム部PDM課
西村一幸氏）
このシステムによって、すべての図面が必要に応じて検索・参照・利用できるよ うになる。2001年を目標に、紙による図面配布を廃止する計画だ。
4)出図日程管理システム 出図（図面のリリース）の進捗状況や担当者の作業負荷状況などを共有化して、
プロジェクト管理、タスク管理に役立てる。進捗状況は、機種毎や図面ごとに確 認でき、また担当者ごとのタスク状況も把握できる。
今後、以下のような適用業務の拡大が計画されている：
- 日程管理…企画から製品流動まで
- 技術情報共有…図面データだけでなくCAMデータも
- 図面発行…設計図面だけでなく、製造技術図面、サービス技術図面も
- 変更管理…設計変更と変更実施記録との連動
- 品質情報…開発段階での製品評価と流動初期での市場評価
ビジネスルールの改革こそ情報化の究極の目的
99年1月から実際の開発が着手されたプロジェクトは、10ヶ月後の11月に完成している。10ヶ月の開発期間の実に6割は仕様の検討にあてられている。10ヶ月というと比較的長いような印象があるが、実際は「常に変り続けるシステムが前提であるため、開発期間と運用期間の明確な区切りがなくなり、開発と運用がエンドレスで続いている」という。
6名からなる開発スタッフは、入社後3年前後の若手が中心である。それは、開発者を社内に育成するため、という大きな狙いがあってのことだ。開発にあたっ
た若いスタッフからは「従来のアプローチよりも考えるスピードが速くなった。 また、課題解決ための工数が見積もれるようになった」という意見が多く、
その成果は期待以上のものだったようだ。
 |
生産技術開発部
FAシステム開発課 技師
山口 氏 |
「dbMAGICはシステムの開発・運用の常識を変えてしまった。」と山口氏は語る。
「ABC分析でいうと、従来は開発がAに、システムの運用がBに相当していま した。この関係がdbMAGICによって逆転してしまったのです。開発生産性が高いので、システム開発よりも、仕様検討やシステム定着化に、時間がかけられるようになったのです。このことは、見方を変えれば、ビジネスルールの改革に力を注げるようになった、ともいえます。dbMAGICは、いろいろな開発のしがらみから開発者
を解放してくれるばかりではなく、ユーザーのシステム化への取組スタンスをも変える力を持っています。 それは、情報化・システム化の本来の目的であるビジネスルールの改革に力を注げることにつながるのです。」
クリックすると拡大表示されます。
|
クリックすると拡大表示されます。
|
| フロー図 |
システム構成図 |
|
