設計品質そのものはいったん置き、設計、出図、材料購買、生産、組立という一連の流れだけを見る。どの工程が最も時間を消費するか。これは工程とツールの設計方法で変わる。ツールや体系が異なっても、本質は「どの動作が冗長か」にある。
シナリオ1:低頻度操作が教育コストと待ち時間を生む
100人規模の研究開発では、設計者がPDMサーバから部品番号を取得し、一意キーを得る必要がある。OAによる番号取得の導入には1週間、毎日2時間の教育が必要。操作自体は理解できるが、番号取得は毎日行う作業ではない。一度覚えた後、2週間の設計作業に入る。2週間後に不足部品の番号を追加しようとした時点で、操作を忘れている。結果として助手の対応待ちになる。
シナリオ2:情報サイロと「もう一度転記する」作業
PLMには情報サイロという問題がある。部品は図面が生まれた時点で名前を持ち、製品ライフサイクルを通じて同じ成果物であり続ける。しかし倉庫、図面、PDMなど、ほぼすべてのシステムが個別に動く。設計者が「フランジ1」と名付けても、倉庫システムはその名前を知らず、もう一度転記する。この転記は誤りやすく、最大級の時間浪費となる。
データをインポートできる場合、または
取得元が1つの一意なファイルである場合、
この問題は完全になくなる。
一意なデータ源:部品ファイルからサーバDBへ
以前、同僚から「部品図の溶接カットリストに何の意味があるのか」と問われた。これはこのシナリオに合致する。溶接カットリストを図面から作る場合、依存元は図面ファイルとなる。図面寸法も元は部品から来る。部品を一意なデータ源にできれば、一意性の問題は解決する。そうでなければ、1つの部品を扱うために2つ、3つ、場合によっては4つのファイルを管理する。
SolidWorks図面のリンク値は属性の取得元を解決する。寸法の取得元も部品。カットリストの取得元も部品である。
クラウドサーバ環境では、これらをすべて1つの一意なデータテーブルから直接取得できる。
ここで、数量を部品に書き込む図面がある場合を考える。
その場合、数量の取得元は部品なのか。
アセンブリに同一部品を追加した場合、数量を部品へ転記するのか。
その部品を別のアセンブリでも使用する場合、数量を変更するのか。
SolidWorksでは図面は部品を表示する「顔」であり、参照用であってデータ本源ではない。本質は、転記と、その後の確認・照合をなくすことにある。SolidWorksでは部品ファイルがデータ源であり、サーバを利用する場合は一意なデータベースやデータテーブルもデータ源となる。
シナリオ3:図面とBOMの配布
1つのプロジェクトに350種類の独立部品、締結部品5,000点を含む全1,400部品、合計150枚の図面があるとする。購入部品、加工部品、在庫部品、標準締結部品はそれぞれ何点か。具体的なデータと図面を、必要な担当者へどのように配布するか。
加工側に必要なのは平面図であり、設計側が作成するのは部品図である。
部品が変化した時、すべての情報を自動更新できるか。独立したExcelでは不可能で、また転記が発生する。書き出したExcelなら可能だが、何を書き出すかを規則で定める必要がある。すべてを書き出すだけでは何も解決しない。
設計思考が最も活発なのはモデリング中である。自分が何を描いているか、45#鋼が必要か、溶接工場へ送るか機械加工へ送るかを把握している。データ源を確立する最適な時点はここにある。150枚の図面を後から整理する時点では、思考は既に鈍っている。個人の見解として、文脈が最も鮮明なうちに問題を解決し、判断を固定する方が信頼できる。この時点では注目点が1つだけだからである。後から文脈を再構築する方法は、150個の点を同時に扱うため信頼性が低い。
SWTDOの方法:属性タグと1対1のファイル関係
SWTDOは属性タグと1対1のファイル関係を使用する。
図面配布
各部品へ属性タグを一括付与する。WeChatではタグで連絡先群を抽出できる。当社のプラグインでもタグで部品群を抽出できる。部品と図面は1対1で対応し、PDFやDXFとも1対1で対応できる。ここでは多体部品をどう扱うかが検討点となる。
BOM配布
タグで部品を一括抽出し、BOMを作成する。
さらにタグ付与自体が問題となる。1ファイルずつ開き、1つずつタグを入力する場合、材料、取得元、加工方法、購入、溶接など十数種類のタグで漏れが発生しやすい。どの部品にタグがないかを一目で確認できる必要がある。
一括タグとデータセンター
当社のプラグインは、選択した部品への一括タグ付与に対応する。タグには固定文字列、関数式、複数要素の組合せ、部品から抽出した情報を使用できる。
大型BOM表は参照ツールであり、一括書込みツールでもある。データセンターは小規模BOMのデータ源にもなる。ファイル属性タグは、設計、出図、検索、BOM作成、配布まで、製品ライフサイクル全体を貫く一意なデータ源となる。
