第33回関西IT勉強会の感想～製造業の基幹システムのパターンが知りたい

第33回関西IT勉強会のメモ。
感想をラフなメモ書き。

【元ネタ】
第３３回　ＩＴ勉強宴会in大阪 : ATND

関西ＩＴ勉強宴会のブログです: 第33回IT勉強宴会in大阪　【「受注生産」のためのシステム開発ライブ】

Twitter / akipii: 渡辺さんの話。受注生産にはロットごとの在庫管理もいらない。下手に経験し過ぎて過去の開発の経験の奴隷になっていた。すごく意味深

Twitter / akipii: 渡辺さんの受注生産の話は単品生産かつ受注後に仕様に基づいて生産する方式。作出属性や評価をデータベースで実現する場合、evalを使うと言う事例。最終的にはDSLに繋がるだろう.

Twitter / akipii: 生産管理システムの設計パターンが知りたい。佐野さんの話では四種類あり、それぞれ特徴と課題がある。トヨタのJIT生産方式もその一つに過ぎない。在庫の変動と工場の操業率に課題がある。その辺りをモデルで整理できないか

「受注生産に徹すれば利益はついてくる」の感想～ERP普及が上流工程の軽視を助長している: プログラマの思索

【1】佐野さんの話。
製造業の受注生産のプロセスは幾つかのパターンがある。

単品生産と混流生産。
個別生産と反復生産。
大量生産と少量生産。
部品集約生産と展開集約生産。

見込生産と受注生産。
見込生産は組立型とプロセス型がある。

組立型の例は、家電製品。
ロットごとに個別に製造する。

プロセス型の例は、化学、化粧品、製薬、食品など。
バルク生産。
石油や化学薬品という原材料から副産物ができたり、製造後の半製品をリサイクルできたりする。

生産管理には幾つかのパターンがある。
ETO、MTO、BTO、MTSなど。

製番管理は受注生産の基本形。
受注番号＝製造番号で、一つの製造番号に関係する部品を紐付ける。

追番管理は、渡辺さんが提唱する在庫推移監視方式に似ている。
但し、計画の変更が発生すると、生産計画に大きな影響がある。

セル生産。
JIT生産、つまり、トヨタのかんばん方式。
TOC。

【2】渡辺さんの話。
ある中小企業の受注生産は、受注したら、技術者の長年の経験で、設計から部品仕入れ、部品組み立て、加工、出荷までやる。
ロットごとの在庫管理もいらない。生産計画もいらない。進捗管理もする気がない。
すごく単純。

だが、受注して生産する製品は、多品種少量生産だが、仕様はある程度決まっている。
長さ、幅、重さ、面積はこれくらい、とか。
これらが受注生産する製品の仕様を構成する。

製品の仕様構成からなる項目の計算式、例えば、面積や重さが仕様を意味する。
それらは作出属性でもあるが、意味がある。
また、長さの範囲という評価式もある。
つまり、単純ではあるが、計算式という関数をテーブルのカラムにセットする必要がある。

では、どのようなテーブル設計にすべきか？

答えは、仕様構成というテーブルに、受注製品Noと仕様変数Noを持たせ、長さ、幅、重さ、面積のような各種の項目を属性としてそれぞれ独立させて持たせる。
評価式をテーブルの属性として文字列として持たせる。
その評価式を計算したい時、evalで評価する。
つまり、画面上で、例えば、長さAと長さBから面積を求めたい時、JavaScriptで評価式をevalで実行して計算させて、結果を表示させる。

つまり、evalのような評価機能のある言語が必要。
ただし、変な値がテーブルにセットされていたら、セキュリティ上危険。

また、コンテキストのスコープはどうなるのか？という質問もあった。

【3】「受注生産に徹すれば利益はついてくる」を読んできたから、製造業の受注生産システムのパターンを整理するような話が聞きたかったが、もっと細かい話で、ちょっと残念だった。
多分、講演の面白さはごく一部の人達だけではなかったか、と想像する。

【4】今まで、業務システムの設計や開発をしてきたが、上流工程の設計技術がどんどん軽視されている気がする。
むしろ、クラウドやモバイル、データマイニングなど、下流工程の技術革新の方が激しくて、そちらを追いかけるのに精一杯。
また、そんな最新技術を追いかけるのは楽しい。

実際、上流工程の設計技法は必要性は分かるが、実際の現場ではさほど必要とされていない。
理由は「受注生産に徹すれば利益はついてくる」の感想～ERP普及が上流工程の軽視を助長している: プログラマの思索にも書いたけれど、ERPというパッケージ製品が普及しているために、生産管理や会計、販売などの業務を一からスクラッチで開発する必要がないからだ。
たとえば、弥生会計や奉行シリーズのような安い会計パッケージ製品のおかげで、中小企業なら会計システムを一から作る必要もない。

同様に、大企業ならSAPやOracleEBSのようなパッケージ製品を導入するのが普通だから、自社の業務とパッケージ製品のフィットギャップ分析だけやれば十分。
細かい機能設計まで考えなくても、導入して運用することはできる。

すると、上流工程の設計技法はさほど必要ではない。
むしろ、パッケージ製品にある機能を知り尽くすだけで十分。
上流工程の業務知識や設計の技法をあまり知らなくても、パッケージ製品を知り尽くしていれば、導入できるし、コンサルみたいに振る舞える。

でも、そんな流れは本当に正しいのか？
上流工程の知識の重要性は落ちているのか？

DOAは日本が編み出した設計技法であり、その技法はとても優れていると思うが、そのノウハウを公開しなかったこと、また、そのノウハウをパターンや知識体系として綺麗に整理できず世の中に広めようとしなかったことが、上流工程の知識の軽視の一つに遠因になっているような気がしている。

【5】僕自身は、「受注生産に徹すれば利益はついてくる」を読んで、製造業の生産管理の方式、その生産プロセスの特徴と長所、弱点が綺麗に整理されていて、非常に面白かった。
一口に受注生産と言っても、下記の4種類があり、それぞれ利点と長所がある。

ETO：設計前に受注して、顧客の要望に合わせて材料を購入して生産する(例：製鉄、造船など)
MTO：設計書がある前提で受注を受けて部品を発注して組み立てる(機械部品、半導体機械など)
BTO：見込生産で部品は自社工場で倉庫に作り置きしておいて受注が来たら即座に組み立てて出荷できる(例：自動車、パソコンなど)
MTS：見込生産で製品を作っておき、受注が来たらすぐに出荷する(例：家電製品など)

上記の4種類の生産方式は、リードタイムの長さ、在庫の有無、工場の操業度の変動有無、見込生産と受注生産など色々違いがある。
その違いが、業務システムにも大きく影響している。

この辺りを整理してみたい。
できれば、アナパタみたいに、モデルのパターンまで抽象化してみたい。