新しい機械を買うべきか、それとも生産システムを変えるべきか？

エピソードノート:機械の能力 vs. システムのアウトプット

概要生産の待ち行列が伸び、リードタイムが遅れ、営業から回答を求められると、「もう1台機械が必要だ」という反射的な判断に傾きがちです。この反応は合理的に見えます。現場は忙しく見え、残業は増え、特定の作業区の稼働はすでに限界に達しているように見えるからです。

しかし、何年も帳簿に残る設備投資を行う前に、重要な問いを立てる必要があります。それは機械の能力の問題なのか、それとも生産システムの問題なのか?

本エピソードでは、単一の作業区で稼働率が高いことが、その機械が工場全体のボトルネックであることを証明しない理由を検討します。また、単純な能力計算(計画時間÷定格速度)がなぜ誤った安心感を生むのか、そして投資判断は材料の払い出しから最終出荷までの工場全体のシステムの論理に従うべきである理由を説明します。

私たちは、シミュレーション(特に離散事象シミュレーション)を用いた意思決定検証のアプローチを提唱します。注文が時間の中を移動する様子をモデル化し、人員、共用治具、材料の可用性といった有限の制約を反映させることで、製造業者は資本を投じる前に、シフトパターンの変更、異なる払い出しルール、修正されたバッチサイズといった代替策を検証できます。

主要テーマ1. スループットは局所的な稼働以上のもの工場は忙しく見えても能力を浪費している場合があります。真のスループットとは、単一工程で処理された部品数ではなく、顧客が受け入れる形で完成品がシステムから出ていくこと(商業的スループット)です。

• 機械は、計画担当が仕事を投入し続けるというだけで一日中稼働することがあり、その後のルート下流で出力がブロックされたり在庫を生んだりする場合もあります。
• キューで待つ材料は滞留した現金を意味し、早く投入されたのに出荷までさらに長く待つ材料はキャッシュフローを損ないます。

2. 「ボトルネック計算」の問題点単純な能力計算は、日々の生産の混乱という現実を隠す理論上の平均値を用いるため、誤った安心感を生みます。

• 誤った式:計画生産時間 / サイクルタイム = 出力部品数
• この式が見落とすもの:実際の生産は、具体的な納期、段取りの必要性、材料の欠品、品質保留、経験豊富なオペレーターの代行、保全作業を伴う実際の注文で行われます。利用可能な時間が必ずしも使用可能な時間とは限りません。
• 定格速度と実速度:定格サイクルタイムは、定義された条件下での安定した運転から得られたものです。どの作業が、どの順序で設備に届き、その後も流れ続けられるかを予測できるのは生産システムだけです。

3. 移動する制約制約とは、需要を出荷可能な製品へ変換することを制限するあらゆるものを指します。それは必ずしも機械ではありません。

• 制約条件は作業区そのものの外にあることが多いです:
  
  
  • 人員配置:特定のシフトに配置された訓練済みオペレーター、または試験サンプルや初品検査を担当する技術者。
  • 共用治具/工具:従来のフローには十分だが新しい能力には不十分な試験装置や治具。
  • 品質工程:試験技術者や検査治具が限られ、滞留を生むケース。
  • 材料不足:生産開始前にルート全体を止めてしまうもの。
• システムに手を入れると制約は移動する:作業区に物理的な能力を追加すると、ルートのリズムが変わります。ある部分のフローを増やすと、次の下流の限界が露呈し、それが追いつけなくなります(飢餓とブロック)。

4. キューを読み解く稼働率の数値は資源が働いているかどうかを示すだけですが、キューは作業が何らかの理由で待たされていることを示します。キューを時間とともに追跡することで、より多くの意思決定情報が得られます。

• 誤指標としてのWIP:大量のWIPの山があっても、それだけで機械能力の不足が証明されるわけではありません。多くの場合、それはシステムが吸収できる能力ではなく、ERPの納期に基づいて作業が払い出されるという生産管理の問題を示しています。
• リトルの法則:安定した生産システム内に留まる仕事が増えると、そこに滞留する平均時間は長くなります。出荷率を上げないまま現場の仕事量を倍にすると、仕事はより長く待たされ、探索、状況確認、例外処理が増えます。
• バッファは在庫だけではない:有用なバッファは、ルート上の既知の地点を予想される変動(通常の混乱)から守るものです。バッファは材料だけでなく時間を保持します。計画された量の仕事と偶発的な山との違いが重要です。

5. 意思決定検証としてのシミュレーション能力投資は設備購入ではなく、生産システムの変更です。シミュレーション(特に離散事象シミュレーション)は、顧客への納品を乱すことなく、これらの変更を検証できる安全で管理された環境を提供します。

• アニメーションではなくロジックを検証する:価値は動く車両や機械の映像ではなく、ルールにあります。
• 離散事象シミュレーション:注文が時間の中を移動する様子をモデル化し、事象(材料の到着、機械の状態、検査の完了)が次の判断ロジックを引き起こします。
• 意思決定の問いを立てる:モデルを使い、定義された条件下でシナリオを比較します:
  
  
  • 需要は増えるが、すべてのシフトに新しいオペレーターを配置できない場合、出荷注文はどうなるか?
  • シフト変更は、機械を購入するのと同程度の納期保護を提供するか?
  • 機械が稼働し始めた後、仕事はどこで待たされるか?

意思決定検証の枠組み:製品、工程、資源シミュレーションを理論から意思決定価値へ移すには、まず3つの基幹要素を用いて生産システムの共通の記述を構築する必要があります:

1. 製品:部品番号を超えて、需要、納期、バッチサイズ、バリエーションのルール、商業的リスクの文脈を含みます。
2. 工程:必要な作業、その順序(ルーティングロジック)、段取りファミリー、代替ルート、品質仕様、初品検査、品質保留時の手直し経路。
3. 資源:機械だけでなく、訓練された人員、治具、工具、試験装置、物理的なバッファスペースも含みます。同時に必要な2つの資源、カレンダー(停止/支援の時間帯)、品質状態によって変わる可能性のあるルールといった重要な依存関係を保持します。

この共通の記述は、ソフトウェアの選択が行われる前に改善されるべきものです。それは互いに切り離された事実(IT/OT)を、原因と結果を推論するために必要な運用上の文脈へと変えます。



このポッドキャストのサポーターになる: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.