出典 ミスミ Facebook
例年、秋になるとCADベンダーによるカンファレンスイベントが開催されてきましたが、今年はその様子も様変わりしました。このブログが掲載される前後には、名称が変更されて初めての“3DEXPERIENCE WORLD JAPAN 2020”が開催されますが、オンライン開催となりました（ライブ配信は2020年11月10日〜11月17日、オンデマンド配信は2020年11月19日〜11月30日まで）。
出典 ソリッドワークス・ジャパン
私もソリッドワークス・ジャパン・ユーザー会（SWJUG）の一人として参加しています。また、私も使用しているiCAD SXのiCAD株式会社による恒例のiCADフォーラムも、今年は“iCADフォーラム_ONLINE”として11月25日に配信が開始され、12月25日まで開催されるとのことです。
このような開催方式も新しい生活様式なのでしょうか。リアルな展示会も復活してきていますが、バーチャルな展示会や、リアルとバーチャルを併用したハイブリッドな展示会も増えています。
その場所に行かなくても、また時間を問わずに情報を得ることができることは、作業効率を考えれば良いのですが、何か寂しさも感じてしまいます。１年前には誰もこの状況を予想していなかったことでしょう。また、来年の秋にはどんな状況になっているのでしょうか。
前回では、最近トレンドになっているプラットフォームについて話してきました。「働き方」からシステムを考えてみた一つの形です。仕事をする空間が変わることや、仕事のやり方が変化することで作業効率がアップしても、“企業にとっての”企業の目的は変わりません。「企業の目的は利潤追求ではない」とか、「企業の目的は顧客創造である」などとも言われています。
確かに「利益追求は企業持続の手段」ですが、企業の中で活動する私にとっては、利益を産むことは当然のことながら重要性が高いということは言うまでもありません。言い換えるのであれば、「顧客満足度を得た上で正しい利益を得る」ということになるのでしょうか。
そうなると、システムの条件とも言える、その「基本的な考え」が重要です。製造業にとって重要な要素になる、しかも基本的な考えの一つの「部品表」について掘り下げていきましょう。
これまでも、製造業の各工程で作成されている部品表について話をしましたが、そもそも部品表には何が書かれているのでしょうか。「そんなの当たり前でしょ」とも言われそうですが、「その部品表をどう使うのか」と考えてみると掘り下げていく意味もありそうな気がします。
書籍を含む学術論文を検索してみても、多くのヒットがあるぐらいなので、普段特別意識することもなく使用しているBOMは学術的な意義も高そうですし、BOMを業として営む企業も存在しています。※BOM：部品表（Bill of Materials）
部品表には、「製品を作るのに必要な部品」が一覧表として記載されています。
部品表情報
② 部品名称
③ 型式（型番）
④ 図面番号
⑤ メーカー名
⑥ 個数（員数）
⑦ 注文に関してのデータ
a. 発注先
b. ロットサイズ
c. 日程（発注日・入荷予定日・入荷日実績）
⑧ 原価に関してのデータ
a. 見積もり金額（発注元／発注先）
⑨ 設計に関してのデータ
a. 図面情報
b. 図面改訂（変更）情報
これらの情報がデータベースに入っていたとしたら役に立ちそうでしょうか。データベースには、
- 複数種類のデータをまとめて管理することができる
- 誰でも必要な条件からデータを検出することができる
- 誰でも検出したデータをもとに用途に応じた利用ができる
といった特徴があります。
部品表情報を見ると、製品に関しての様々な情報を持っている、また持つことが可能だと言えます。私は個別受注生産型の企業に所属してきた経緯もあるのですが、当時私が作成していた部品表は、その受注装置ごとに独立した部品表でした。
受注は五月雨式になるため、受注の都度、その後の開発・設計・製造を管理する受注番号が設定されます。この番号によって、データとモノが一致するようになり、受注以降は、開発・設計・製造に関わる内容は全てこの受注番号に紐づけられていきます。
紐づけられるのは、例えば次のようなものです。
- 顧客名
- 装置名
- 図面
- 部品
- 部品ごとの必要数（員数）
- 工数（作業時間）
- ドキュメント（仕様書・検査成績表）する部品なのか
- 原価と実績
受注番号は、次の例のように設定され、紙の受注管理台帳に受注日・装置名・顧客名・受注金額が記されたもので管理されていました。まだ紙図面と2DCADが平行して使用されている頃で、2DCADもWindows OSではなくUNIX OS、部品表は手書きでした。生産管理もオフコン（オフィスコンピュータ）と言われるものが主体だった頃、この方法が社内で運用されていました。
受注番号の例
書庫の複数あるキャビネットには、多くのファイルがあって、受注製番順に部品や工数、部品原価といった製造管理上の情報が書かれたオフコンより印刷出力された膨大な紙の資料が保管されていました。
手書きの部品表も製番ごとフォルダに入れられ、ファイルキャビネットに収納されていましたが、当時の部品表は設計構成部品を示しているだけだったので、受注案件の見積もり作業を行う場合には、部品表ではなく、前述の製造管理上の情報が記載された帳票から調べるしかありませんでした。
毎日の作業時間の報告も紙形式の作業日報を提出し、これを管理担当者がオフコンへ入力するという状況でした。
当時は手書き情報が多く、これを管理できるような仕組みも普及していたとは言えませんでした。しかし、当時に比べ、デジタルデータをオンプレミスやクラウドでデータ管理できるようになった現在でも、このように何かに紐づけられた情報がそれぞれ別のシステムで管理されているということはないでしょうか。
分散する情報、製番に紐づけられていながらも、つながらない情報だった
例えば、エクセルで作られる実績集計の帳票はどうでしょうか。エクセルの機能は優れ、便利なものですが、実績集計のようにエクセルを使用して製造業の社内の状況を表そうとする場合には、そこに入力するデータは、社内のシステムにデータ元（リソース）として既に存在しているものを使用することがほとんどです。また、そのように作成された帳票は誰が管理するのでしょうか？
この状況においては、例えば以下のような課題があります。
- 計算式の整合性
- 進捗によって更新されていくものの更新管理
- メンテナンス
- 新たに作られたエクセルファイルとリソースの二重管理
また、次のようなこともないでしょうか。
- エクセル入力作業としては、どこかのデータを持ってきて→入力して→計算して→表示というように、 “ほぼ”もしくは“完全に”定型的な作業であるはずなのに、エクセル帳票作成のための工数が、毎月、属人的に費やされている
- せっかく出力したのに、その精度に問題がある
- 本来は作成された帳票の結果から議論されるべきなのに、それがない
「データを収集してその結果が見られるようになっただけでもいい」「可視化できただけでもいい」という意見もあるかもしれませんが、「見えればいいというものではない」と思いませんか。目的は、「見ることではなく、分析と次の対処を行うこと」です。
私が設計者としてBOMに関わるようになって随分な時間が経ちました。紐づけられる受注番号だけでも課題があるのですから、BOM、BOMを構築する構造、その利用方法というものが、製造部門の各工程や業務と連携すれば、会社全体をより良くできるように思えてなりません。これを考えていく上でも、俯瞰的に見た、あるべき姿からの設計図を作って、部分最適化を行っていくことが必要だと私は考えます。
次回は部品表のモデルについて話したいと思います。
（次回に続く）
