INTRODUCTION
「BOMって部品表でしょ」で終わらなかった
Windchillの開発に入ると、 BOMという言葉が 普通に出てきます。
最初は、
「BOM ＝ 部品表」
という程度の理解でも、 言葉としては間違っていません。
ただ、
実際に開発していると、
「このPartは何に使われている？」
「このデータは製品のどの階層？」
「この部品の上位には何がある？」
といったことを 意識する場面が出てきます。
BOMは「部品の一覧」ではなく、 「製品がどう構成されているか」を見るための情報だった。
01
まずはPartという単位
製品を構成する 一つ一つの部品を 考えてみます。
例えば、 自動車のような製品なら、
部品A
部品B
部品C
部品Dのように、 多くの部品があります。
Windchillでは、 こうした製品を構成する 部品の情報を管理します。
ただ、 実際の製品は 部品が横並びに存在するわけではありません。
部品Aと部品Bを 組み合わせて、 さらにそれを別の構成に組み込む。
つまり、 部品には 「上下の関係」があります。
02
AssyとSubAssyで構成が見えてくる
ここで出てくるのが、 AssyやSubAssyです。
イメージとしては、
製品
↓
Assy
↓
SubAssy
↓
Partのような 階層構造を考えると 分かりやすくなります。
例えば、
自動車
├─ 車体Assy
│ ├─ ドアSubAssy
│ │ ├─ 部品A
│ │ └─ 部品B
│ └─ 部品C
│
└─ エンジンAssy
├─ SubAssy
└─ 部品Dのように、 一つの製品は 多数の部品と いくつもの階層から構成されます。
ここで大事なのは、 「Partとは何か」 だけではなく、 「そのPartは、どこに組み込まれているのか」 ということでした。
03
BOMは「関係」を見る
BOMを理解するときに、 「部品一覧」とだけ考えると、 開発では少し足りません。
重要なのは、
「この部品と
この構成がどうつながっているのか」
です。
部品の情報を 管理する単位。
どの部品が どの製品・Assyに 属するのか。
例えば、 Javaのコードで 「子側のPartを取得する」 処理があったとします。
コードだけを見ると、
Part
↓
Part
↓
Partのように見えてしまいます。
でも業務上は、
車体Assy
↓
ドアSubAssy
↓
部品Aという意味を持っているかもしれません。
コードを理解するには、 データの「関係」を理解する必要がありました。
04
Windchill開発でBOMを意識する場面
BOMの考え方は、 単なる業務知識として 勉強しただけではありません。
実際の開発では、 データを取得したり、 画面に表示したり、 外部システムへ渡したりするときに、 その構造を意識する必要がありました。
例えば、
このデータは何？
↓
どのPart？
↓
どのAssyに属する？
↓
上位には何がある？
↓
どこで使われる？
こうしていくことで、 Javaの処理が 「データを取得している」 だけではなく、
「製品構成のどこを扱っている処理なのか」
が見えるようになっていきます。
05
なぜこの部品がここにあるのか
開発をしていると、 データそのものだけを見ることがあります。
例えば、
partNumber = "XXXX"
という値を見て、
「部品番号がXXXXなんだ」
で終わってしまう。
でも、 製造業のシステムでは、 その部品が 「なぜそこに存在するのか」 が重要になります。
どの製品に使われるのか。
どのAssyに含まれるのか。
どのSubAssyの下にあるのか。
そうした情報を理解すると、 これまで単なるIDに見えていたデータが、 製品構成の一部として見えてきます。
06
BOMを知ると、業務システムの見え方が変わる
例えば、 画面にある部品情報を 表示する処理があったとします。
Javaだけ見れば、
部品を取得
↓
画面に表示だけに見えます。
でも、 業務の意味まで考えると、
製品
↓
Assy
↓
SubAssy
↓
Part
↓
画面表示という流れかもしれません。
つまり、 システムが表示しているのは 単なるデータではなく、 製品構成の一部 だったわけです。
ここを理解できるようになると、 Javaのコードを読むときにも 少しずつ意味が見えてきました。
07
設計データから生産側へつながっていく
BOMを理解していくと、 もう一つ気になってくるのが 生産側との関係です。
設計側で作られた 製品構成の情報は、 設計だけで完結するわけではありません。
製品を作るためには、
何を作るのか。
どの部品を使うのか。
どんな構成なのか。
といった情報が
生産側でも重要になります。
そのため、
設計
↓
設計データ
↓
製品構成
↓
BOM
↓
生産というつながりを 意識するようになりました。
このあたりから、 Windchillを 単なる「設計データを管理するシステム」 として見るのではなく、 製造業全体の業務につながる システムとして見るようになりました。
FIELD NOTE
コードだけ追っていても、 BOMの意味は分からなかった。
Windchill開発に入った当初は、 Javaのコードを追えば 処理が理解できると思っていました。
でも、
Partを取得する。
構成を取得する。
上位のオブジェクトを見る。
下位の部品を見る。
こうした処理の意味を理解するには、 実際の製品が どういう構成になっているのかを 知る必要がありました。
BOM、
Assy、
SubAssy。
最初は単なる用語でした。
でも、 実際のコードと 製品構成を結びつけて考えることで、 少しずつ意味が見えてきました。
Windchill開発では、 「コード」と「製品」を 一緒に見る必要がありました。
SUMMARY
BOMを理解して、 Windchillの処理が少し見えるようになった
今回、 BOMについて学んだことは、 単に「部品表とは何か」 という知識ではありません。
重要だったのは、 それぞれを暗記することではなく、
「このデータは製品のどこにいるのか？」
という視点でした。
Javaのコードを見ているだけでは、 単なるオブジェクトやIDに見える。
でも、 BOMや製品構成を知ると、
製品
↓
Assy
↓
SubAssy
↓
Partという業務上の意味が そのコードの裏側にあることが分かります。
そして、 その先には 生産側の業務もつながっている。
Windchillを理解することは、 製造業のデータの流れを理解することでもありました。