シミュレーションとボトルネック10 分で読める

初めてのシミュレーションプロジェクトの進め方

DBR77 Team公開日 2026年9月4日

初めてのシミュレーションプロジェクトは、一つの高額な意思決定、2〜4つの案、少人数のチームを軸に進め、成功の指標は誰かがモデルを作る前に合意しておきます。手順は、問いを選ぶ、範囲と指標を決める、データを集める、基本モデルを構築して確認する、案を動かす、そして決定してその理由を記録する、です。焦点を絞った最初のプロジェクトにかかるのは、数日から数週間です。DBR77が公開している事例では、同等の分析に数日から約1週間かかりました。

ステップ1：答える価値のある問いを一つ選ぶ

最初のプロジェクトが失敗する最も多い理由は、問いが大きすぎることです。「工場全体をモデル化する」は問いではありません。「新しい組立エリアの3つのレイアウトのうち、同じ人数でシフトあたりの生産量が最も多いのはどれか」は問いです。

良い最初の問いには、3つの特徴があります。

高額、または元に戻しにくい。たとえばレイアウト変更、ロボットセル、新しいバッファ、シフトの追加。
現実的な選択肢が少なくとも2つあり、どちらが優れているかについて意見が分かれている。
答えが時間と相互作用に左右される：共用のフォークリフト、バッファ、段取り替え、変動する受注構成。

意思決定が小さく、簡単に元に戻せるなら、代わりに現場で試してください。期限が来週なら、モデルは間に合いません。まだ決まっておらず、今後数か月以内に下される意思決定を選んでください。

ステップ2：モデリングの前に範囲と指標を決める

データを集める前に、1ページのプロジェクト憲章を書きます。そこには次のことを記します。

意思決定：一文で書きます。
比較する案：通常は現状を含めて2〜4案です。
境界：どの工程、倉庫エリア、搬送ルートを含め、何を意図的に除外するか。
指標：たとえば、シフトあたりの生産量、待ち時間（分）、工程と車両の稼働率、作業者の作業時間。
判断ルール：どのような結果なら案Bではなく案Aを選ぶか。

判断ルールは、ほとんどのチームが飛ばしてしまうステップです。これがなければ、どんな結果も言い逃れができてしまいます。これがあれば、チームは最初の試行の前に、何を探しているのかが分かります。

ステップ3：データを集め、役割を決める

データの大半はすでに存在します。CADのレイアウト、ERPの工程手順と標準時間、シフトカレンダー、受注履歴です。残りは手作業で計測します。最小限のデータセットとその集め方は、工場シミュレーションを始めるにはどんなデータが必要かにまとめています。

最初のプロジェクトに必要なのは、週に数時間ずつ関わる数人のメンバーです。専任で加わる人は必要ありません。

役割	典型的な担当者	提供するもの
スポンサー	工場長またはCOO	意思決定、期限、最終的な選択
プロジェクトオーナー	工程技術者または生産技術者	プロジェクト憲章、データ、スケジュール
現場の専門家	シフトリーダーまたは職長	実際のサイクルタイム、停止、現場で実際に守られているルール
データ担当窓口	生産計画担当者またはIT	ERPのエクスポート、受注履歴、工程手順
財務担当窓口	コントローラー	各案のコスト、取締役会が求める形式
モデラー	社内のエンジニアまたはDBR77	モデル、試行、比較

現場の専門家は、想像以上に重要です。ERPの標準時間だけで作ったモデルは、実際の生産量を左右する待ち、歩行、現場の工夫を見落とすことがよくあります。

ステップ4：基本モデルを構築して確認する

意思決定が将来のレイアウトに関するものであっても、まず現状をモデル化します。現実と比較できるのは、このバージョンだけだからです。

そのうえで、3つの簡単な確認を行います。

過去の1週間を再現します。最近の受注構成を使います。生産量と主な待ち行列が、シフトリーダーの記憶と一致するはずです。
ボトルネックを確認します。モデルでの制約は、現場が問題を感じている場所にあるはずです。
入力を一つ変えます。ある工程のサイクルを長くすると、結果はチームが説明できる方向に動くはずです。

基本モデルと現場が食い違う場合は、案を動かす前にその理由を突き止めてください。標準時間と実際の生産量の差は、たいてい本当のボトルネックを指し示しています。そこを計測し、入力を修正してください。基本モデルが間違っていると、すべての比較が同じように間違い、誰もそれに気づきません。

初めてのシミュレーションプロジェクトを計画していますか。

意思決定を数行で説明していただければ、案、境界、集めるべきデータの短い一覧を含む1ページのプロジェクト憲章にまとめるお手伝いをします。

お問い合わせ

ステップ5：同じ条件で案を動かす

すべての案に、同じ受注構成、同じ停止、同じサイクルタイムの幅を適用しなければなりません。これらが異なると、比較はレイアウトの違いの代わりに前提の違いを測ることになります。DBR77 Digital Twinの確率的シミュレーションは試行ごとにこれらの入力を変動させるため、各案は条件の悪い日でも評価されます。

これにかかる時間は範囲によります。DBR77が公開している事例では、生産ラインのレイアウトの複数案分析は約1週間で納品されました。自動化案の比較は数日でした。倉庫ピッキングのシミュレーションは、現在の製造指図から数日で準備されました。

この規模の最初のプロジェクトについて、説明のためのスケジュール例は、プロジェクト憲章とデータに1週間、基本モデルと確認に1週間、案の試行に数日、そしてレビュー会議が1回、といったものです。実際の数字は異なるでしょうが、計画が数か月に及ぶようなら、範囲が広すぎる可能性があります。

案は、それを実際に運用する人たちと一緒にレビューしてください。工程のアニメーションや3Dビューがあれば、シフトリーダーは現場と合わないルールに気づきやすくなります。たとえば、シフト交代時に塞がるフォークリフトのルートです。

ステップ6：決定し、その理由を記録する

プロジェクトが終わるのは、誰かが意思決定を下し、それを書き留めたときです。短い記録を残してプロジェクトを閉じてください。

選ばれた案と、それを勝たせた指標
採用されなかった案と、それが負けた理由（名前を変えて再び持ち出されないようにするため）
主な前提と、それぞれの担当者と出所
再試行のきっかけになるもの（新製品、製品構成の変化、新しい設備など）
今後モデルを担当する人

意思決定の記録は、2つ目のプロジェクトを速くします。選んだ案が現場で実現したら、モデルの責任者が工場に合わせて基本モデルを更新します。次の問いはそのモデルから、同じデータと確認手順で始められます。結果を発表する会議については、シミュレーション結果を経営陣に提示する方法をご覧ください。

最初のプロジェクトでよくある落とし穴

システム連携から始める。最初の意思決定の前に設備を接続すると、結果が出るのが遅れます。手元にあるデータから始めてください。設備のリアルタイムデータは、モデルを定常的に使うようになってからの後の段階です。
途中で範囲を広げる。プロジェクトの途中で新しい問いが加わるとスケジュールが振り出しに戻るため、次のプロジェクトに回してください。
モデルを担当者のいないまま放置する。工場が変わっても誰も基本モデルを更新しないため、1年後には現場と合わなくなり、誰も信頼しなくなります。
経営陣が意思決定を求めているのにモデルを発表する。経営陣に必要なのは選択とその理由であり、アニメーションはそのどちらも与えません。

これらを含む失敗の原因は、デジタルツイン導入プロジェクトの多くが失敗する理由と、その回避策で解説しています。