業務全体を扱えるようなデータの保管の構造は、前に述べた品質（製品の目的や機能）から派生した構造が良い。この構造であれば、後のプロセスで必要とされるデータ項目との関連性をつけていくことが容易である。これらのデータを見る方法としてものづくり支援システムでは３つの基本画面が必要だ。

　部品の構成から仕事をする人は、部品の構成イメージ図から仕入先や品質項目あるいはその生産工程を求めれられるようにする。

　また、品質の分類から仕事をする人は品質管理イメージ図から関係する部品やそのサプライヤや生産工程が情報検索できる。

　一方、生産工程の分類から仕事をする人は生産工程の関係部品や工程での作業や使用設備、品質規格などをみることができるようにする。

　このような3つの側面からどの仕事をする人でも全体を見て仕事の意思決定ができるような全体最適意思決定を可能にするアプリケーションとなっている。

　部品の構成(BOM)から情報を検索しても、品質(性能)の分類から情報を検索しても、生産工程の分類から情報を検索しても、それぞれが他の分類の該当情報に相互に検索ができる必要がある。このことを可能にするには表の定義と関係性では変化する分類に対して固定化せざるを得ないために、業務変更には向かない。

　システムを開発するときには、個別組織や特定業務の個別システムとなる方が簡単であるがゆえに、限界を決めて構築してきた。本来ならば、企業の生産性を向上させるために、先のような3つの分類(設計、品質、生産)を絡めて情報検索ができる方式の実現を大きな課題と捉えて、解決してこなければならなかったはずである。

　物づくりにおける全体最適なシステムを作るには製品開発から生産までの全体を考えたシステム構築を基本に考えるべきである。それは、直接部門(生産)の生産性を向上させるには管理間接部門の生産性を高めることが必要である。製品企画段階の製品開発初期には全体最適を考えているはずである。それが、開発が進むと関係組織が増え、関係者も増加してくる。そのことにより、単純化した検討や考え方が失われて、部分の難しい判断をお互いに異なる価値観にて議論を繰り返す状態を発生させているのである。

　生産段階に近くなるとますます、部分最適になっていく。製品開発初期段階は製品も品質もコストも考え抜き、生産工程も考え、しっかりと検討する。このフェーズの仕事には全体最適を行うためのデータ項目が存在している。

　生産段階になると部分的であり派生的なデータ項目のみが取り扱われる。これは他のデータ項目は管理上不要になっただけであり、全体品質やコストを把握するには全体データ項目が必要である。

　工場が管理する部分的なデータ項目では生産全体の経営につながるデータの集計ができず、経営の意思決定が遅れることになる。工場の指標と経営指標が連動しないのは、このように上位から下位までのデータの関係性と粒度の変化をしっかりと定義しないことに起因しているのである。

DXデータが作られる最初のタイミングと範囲

　ものづくりにおいて、つくられるデータ項目はその仕事が開発フェーズや工場管理フェーズなどにおいて、仕事の進度によってデータ項目は追加される。
しかし、新しく出現したデータ項目であっても、そのデータ項目は他のデータ項目の細分化された一つであったり、計算された結果であり、派生的なデータ項目であるはずである。そうで無ければ、達成したい目的とは全く無関係な仕事をしていることになる。

　このように、データ項目は当初の品質目標とコスト目標から派生し、その実現のための方法を表現するデータ項目に変化していくことになる。例えば、工場における保全の仕事を考えてみる。保全の仕事の一つに設備の故障対応がある。

この故障対応を支援するシステムを考えるに、故障発生した時間から行われる業務を列記すると、故障の発見、報告、現象把握、問題の大きさ認識、報告、緊急処置、確認、報告、原因の追究、対策の決定、再発の防止、報告などに関するデータ項目を選定するはずである。では、これらの仕事にどのような基本的なデータ項目が語られることになるかについて考えてみる。

設備に関するデータの発生起源

　例えば、この設備はどのような加工を行う設備であるかやその為に守られなければならない点検項目は何であるのかを知りたいはずだ。また、その点検項目はどのような製品品質規格を守るために行わなければならないかなども知る必要が出てくる。これらのデータ項目は設備の保全者であっても、ものづくり企業では当然知っておくべきことである。　　

　更に、設備設計の仕事を支援するシステムと関係があることは容易に推察されるはずである。何故、このような設備設計仕様となったかを知りたくなり、その再発防止を前工程に働き掛けることになる。それは設備標準仕様書などに反映して、管理者のチェックポイントになる。

　設備設計の業務では、その設備が必要であることを決めた製品開発時点でその設備名称が生まれる。しかし、その設備の必要性は、製品設計における部品の形や材質などの決定により生まれるものである。その製品の機能実現のために必要な品質規格やコスト目標を達成するために生まれてきたものである。

　このようにデータの生まれるタイミングと関係性について記述したが、物づくりにおいて、データは多くの仕事のインプットであり、アウトプットである。インプットからアウトプットに転換する際に、考え方（ロジック）が必要であり、生産性の高い工場にするには、さらに自動化が必要となる。

N対Mのネットワーク

しかし、重要なことはこのインプット、アウトプットの表現に使われるデータ項目とデータ項目間の関連性である。これらは、一対一ではなく、n対mの関係にあり、個別の数値だけ見ても、別な項目まで見なければ結論に至らない。その意味で、企業の中は単純化を意識し続けなければ、生産性の低下する複雑な仕事が多くなり、コストがアップしてしまう。

ものづくりに必要な仕事は製品開発・設計、実験、試作、部品・設備調達、工程設計、生産、検査、物流などである。仕事の一つが欠けてもものは造れない。その為、これらの仕事が効率的に推進できるように組織は構成される。　
　しかし、市場の環境変化に沿って組織は改造される。ただし、情報システムは組織とは無縁に造られるものでなければならない。組織変更の都度の情報システム改造投資を避けなければならない。

　製品を開発する人、その開発した製品の図面を見る人、試作品を評価する人など、ものづくりに必要な仕事は全て人で行われている。そこでは、仕事が自動で流れることは無い。あくまでも、仕事をする人が考え、適切な組織に相談し、その結果を他の組織に伝えることが行われる。その間、生まれた情報を受け渡ししていく。

　したがって、ものづくりのシステムとは、部分だけを対象としてもうまくいかないのである。効果も出にくいのである。部分の仕事を対象にシステム化するとそのシステムを動かすためのデータを入力しなければならない。そして、その入力を最小限にしたいがために、システム化対象を狭め、個々の組織や部分の仕事にだけ活用できるシステムが造られていくことになる。

　仮にこのようなことが多く行われると当然、いわゆるスパゲッティ状態になるわけである。しっかり硬いスパゲッティなら他方を引けば他方が動くが、そうではなく、他方を動かすと余計なものが動くとか、何も動かなくなっていく。経営者が嘆きたくなるような結果に至る。このような状態にあることは、全体を見抜こうとするシステム設計者の力不足であると思う。

　整理統合しようにも、もはや個別システムを前提に仕事の進め方を標準化してしまっており、一度に同時にシステムを直さないといけないことになる。結果、手のつけようも無い状況となる。これでは人の為に役立つ情報システムではなく、全体的にみると、かえって生産性をダウンするシステムになっている。それを解決するには、物づくり全体の仕事に対して、活用できるデータを定義することが重要である。

　残念なことに、2010年ごろまでは、ものづくり全体をシステム化させようとの動きがなかった。その後も、industry4.0とかのワードが流入してきても、個別システムに動いているように見える。今後も、企業がこのような意識では、形式的なIT活用に留まってしまうのではないかと大変心配である。

industry4.0についてはこちらをご覧ください。

ものづくりシステムを3つに分けて、その目的を紹介したい

①製品（仕事）の品質が良くなるツール
　企業は人で組織化されている。その中で生み出される製品やサービスの良し悪しは、そのプロセスを推進している仕事そのものの良否に依存している。人は能力や経験が異なり、結果もばらつくものである。組織は管理者のマネージメント手法も異なり、継続的な管理が行われていないことも多い。そのような人と組織が生み出す製品はその仕事の良し悪しが反映されているものである。そこに誰でも継続的に同じレベルの仕事が行えるツールが必要になる。

②エンジニアリングや間接部門の仕事を全体最適化するツール
　生産現場の改善とはエンジニアリング（計画力）の不備を是正し、修正するための活動であるとも言える。本来、人の仕事にはミスがつきものである。また、計画時に正しかったことは生産の条件変化、市場ニーズ変化などで正しくなくなることが世の常である。そのため、現地現物となって顕在化する問題を生産現場は必死に改善している。しかしその発生原因は、計画業務の仕事の質に問題があることが多いのである。したがって、設計や生産現場、生産計画部署などの仕事をトータルで支援する全体最適意思決定ツールが必要である。製品開発段階におけるチームの能力差は、生産活動そのものに大きな差を与えるものである。

③マニュファクチャリングの標準化の大きなPDCAツール
　仕事の順番などの手続きは標準化が進んでいる。しかし、技術的な検討を行うときの判断方法などは個人の経験に大きく依存している。管理者はこれを標準化する責任があるが、技術は常に進歩し、環境変化とともに判断指標も変化する。その結果、判断は個人の能力で行われている。これらの為に結果的に標準化が遅れている。そのために製造現場には問題が発生してしまうのである。

　製品開発段階の仕事のアウトプットに対し、その結果を表す生産現場の状況を調査、分析することで企業内に大きなPDCAが回る。それによりエンジニアリングの問題が顕在化し、標準化するこができる。

　しかし、現場の仕事は分かり難い動きをしている。分かり難いから、ベテラン経験者を海外工場に派遣し、現地工場の指導をすることから脱皮することができない。現場の仕事は原価、品質、生産性、安全などに人や設備や部品・材料が関係し、それぞれが関係し合っている。企業の縮図ともいえる。現場の実体を知り、課題を共有することができれば、それぞれの計画業務が標準化する。

　分かりにくいマニュファクチャリングの標準化にはエンジニアリングの標準化が必要である。そのためにはエンジニアリング業務と工場の管理業務は計画と結果の関係である。工場の仕事に間接部門はもっと責任を持つべきであるし、工場に任せていては、欧米の科学的アプローチに遅れしまうのである。