生産計画におけるWhat-Ifシナリオ分析：進め方

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-12

生産計画のWhat-Ifシナリオ分析とは、計画を複製し、前提を一つ変えて結果を比較することです。手順、必要なデータ、ツール、確認のポイントを解説します。

Automatically translated with AI from the original post. Read the English original

生産計画におけるWhat-Ifシナリオ分析とは、基準計画を保持し、前提を一つ変え、実際に何かが起こる前に結果を比較することです。前提としては、2シフト分停止する機械、緊急受注、欠品した材料、新しいシフトモデルなどが考えられます。比較により、各選択肢が納期、負荷、残業にどのような影響を与えるかが分かります。本記事は、一度きりのスプレッドシートではなく、再現性のある方法を求める生産計画担当者を対象としています。また、どのようなデータ、ツール、確認を行えば答えの信頼性が担保されるのかを解説します。

重要なポイント

• What-Ifシナリオは、基準計画を取り上げ、機械停止や緊急受注といった前提を一つ変更し、実際に何かが起こる前に結果を基準計画と比較するものです。
• まず意思決定を明確にし、そのうえで二〜三個のレバーと二〜三個のKPIを選んでください。背景にある意思決定がないシナリオは、単なる演習にすぎないからです。
• まずは一度に一つのレバーだけを変更してください。複数のレバーを組み合わせるのは、それぞれ単独の効果を理解した後にします。
• 将来の期間に使う前に、過去の期間でモデルを検証してください。モデルの価値は、その出力が用途に対して十分正確かどうかにかかっているためです。
• Microsoftのツールでも作業の一部はカバーできます。Dynamics 365のマスター計画では代替の計画戦略を保持でき、Power BIのWhat-ifパラメーターは単純な計算には適していますが、スケジュールの順序決定には向いていません。

What-Ifシナリオとは何か、そして何ではないのか？

シナリオとは、将来に関する一貫した前提の集合であり、基準計画と同じモデルで実行するものです。基準計画は、現時点で最善と考える計画です。それ以外はすべて、その基準計画のバリエーションです。

混同されやすい三つの概念は、区別しておく価値があります。

• 予測は、起こると予想されることを示します。シナリオは、特定の事象が起きた場合に何が起こるかを示します。
• What-If の問いとは、立てる問いそのものです。工場シミュレーションは、選んだ入力で工場のモデルを動かして、その問いに答える方法の一つです。スプレッドシートやERPシステムでの計画実行も、別の方法となります。
• 感度分析は、一つの入力を一定の範囲で変化させ、結果がどれだけ動くかを確認するものです。どの前提に注意を払うべきかが分かります。

三つの目的は同じです。判断を変えることがまだ低コストなうちに、意思決定の結果を把握することです。

どの意思決定にシナリオを作成する価値がありますか？

意思決定が覆しにくいとき、複数の制約が絡み合うとき、あるいは経験だけでは答えが明らかでないときに、シナリオを実行してください。生産計画における典型的なきっかけは次のとおりです。

• ボトルネックの機械がメンテナンスで停止し、どの受注を遅らせるかを選ばなければならない。
• 顧客が納期の前倒しを求めている。その影響はどこに及び、誰がコストを負担するのか。
• 欠勤や休暇により、一週間の人員が減る。
• サプライヤーが重要な材料の遅延を発表した。
• 製品構成が変わろうとしており、現在の生産能力がそのまま機能するかを知りたい。
• 二交代制の導入、新たなバッファー、追加の治具の導入を検討している。

変更が容易で簡単に元に戻せる意思決定や、計画に十分な余裕があり実行可能であることが明らかな問いについては、シナリオは不要です。シナリオは計画担当者の時間を使うため、より良い意思決定につながるものでなければなりません。

生産におけるWhat-Ifシナリオ分析はどのように実行しますか？

スプレッドシートや専用ソフトウェアでも使える手順は次のとおりです。

1. 決定事項を書き出します。「X は金曜日までに決める必要がある」という一文にしてください。これが書けないなら、まだシナリオは必要ありません。
2. ベースラインを固定します。現在の計画を、前提条件とともに保存します。カレンダー、サイクルタイム、受注リスト、資材の手配状況などです。すべてのシナリオはこのバージョンと比較するため、途中で変わってはいけません。
3. レバーを選びます。レバーとは、変更できる、あるいは変わる可能性のある要素です。キャパシティ、人員配置、受注の優先順位、納期、資材の入荷などが該当します。この決定に影響する要素を 2～3 つ選んでください。
4. 現実的な範囲を設定します。実情を知っている担当者に確認します。典型的な修理にはどれくらいかかるか。サプライヤーはどのくらいの頻度で、どの程度遅れて納品するか。数字を推測で決めてはいけません。自社の実績を使い、見積もりには必ず見積もりであると明記してください。
5. 測定指標を決めます。KPI は 2～3 個あれば十分です。例としては、納期遵守率、リードタイム、ボトルネックの稼働率、残業時間、仕掛品などがあります。何かを実行する前に定義しておき、後から都合のよい指標を選ぶことがないようにします。
6. レバーは一度に 1 つだけ変更します。各シナリオをベースラインと比較して実行します。個々の効果を理解してから、レバーを組み合わせてください。
7. 比較して決定します。ベースラインと各シナリオを並べて比較します。それぞれのケースでどう対応するかを話し合い、決定事項とその理由を記録します。
8. 記録を残します。前提条件と結果を、決定事項とともに保存します。実際に何が起きたかを振り返る際に必要になります。

以下は、ロジックを示すためだけに作った架空の例です。ある工程には、1 シフトあたり 300 個を生産するボトルネックのプレスが 1 台あります。工場は週に 10 シフト稼働するため、キャパシティは 3,000 個です。今週の受注は合計 2,700 個で、キャパシティの 90% に当たります。ベースラインは実行可能で、1 シフト分の余裕があります。

• シナリオ A:プレスが 2 シフト停止します。キャパシティは 8 シフト、つまり 2,400 個に低下します。300 個が手当てできず、一部の受注は納期に間に合いません。
• シナリオ B:同じ停止に加えて、土曜日のシフトを追加します。キャパシティは 2,700 個に戻りますが、負荷は 100% になります。さらに何か問題が起きれば、納期遅延は避けられません。
• シナリオ C:同じ停止が発生し、計画担当者が優先度の低い受注 300 個を来週に移します。重要な受注は納期どおりに出荷でき、ある顧客には金曜日に驚かせるのではなく、今日のうちに連絡が入ります。

このために高度なツールは必要ありません。必要なのは、ベースライン、レバー 1 つ、そして率直な比較です。B が解決策に見えても余力がない、と分かることに価値があります。

どのようなデータとツールが必要でしょうか。

まずは手元にあるものから始めます。シナリオには、計画そのものと同じ入力が必要です。受注と納期、工程順序とサイクルタイム、リソースとカレンダー、資材の手配状況などです。これらが信頼できない場合、すべてのシナリオが同じ誤りを引き継ぎます。先にマスターデータを修正してください。そうしないと、意思決定ではなくモデルについて議論することになります。

次に、問いの複雑さに応じてツールを選びます。

• スプレッドシートは、上の例のように 1～2 個のリソースと少数の受注で結果が決まる場合に十分です。
• ERP の計画実行機能では、資材が主導する問いに対応できます。Dynamics 365 Supply Chain Management では、マスター計画で異なる計画戦略をシミュレーションできます。Microsoft のドキュメントによると、必要な数だけ計画を設定でき、異なる需要予測やシミュレーションのために一部を保持しておくことができます。ただし、そのページではシナリオの扱いが詳しく説明されていないため、ご利用のバージョンと計画エンジンにどう適合するかは、導入パートナーに確認してください。マスター計画は資材とキャパシティを粗いレベルで扱うものであり、詳細な順序計画ツールではありません。
• 有限キャパシティのスケジューラーまたはシミュレーションモデルは、共有設備、段取りが順序に依存する場合、シフト、スキルが相互に影響し合う場合に適した選択肢です。このような場合、単純な計算では問題がないように見えても、日々のスケジュールが実行不可能になっていることがあります。
• Power BI は、シナリオの結果をマネージャーに示すのに適した場所です。what-if パラメーターを使うと、ユーザーはスライダーを動かして指標の変化を確認できます。Microsoftによると、これはビジュアル内の指標で使うように設計されており、パラメーターに設定できる一意の値は最大1,000個です。そのため、「スクラップが5%増えると出力はどうなるか」のような単純な問いには役立ちます。ただし、スケジュールを順序立てて組むことはできません。これは結果を見せるためのフロントエンドとして扱い、計算エンジンとは見なさないでください。

どのツールを選ぶにしても、次の2つはツールの外に置いてください。書面にした前提条件と意思決定ログです。ツールは変わりますが、文書は残ります。

その答えは信頼できるのでしょうか？

シナリオは、その背後にあるモデルと同じ程度の品質しかありません。以下の3つのチェックが役立ちます。

バックテストを行ってください。 結果が分かっている過去の期間に対してモデルを実行し、その出力を実際の結果と比較します。シミュレーションの文献では、これは運用妥当性（operational validity）と呼ばれています。つまり、モデルの出力の振る舞いが、想定される用途と利用される条件の範囲において十分に正確であるかどうかです。Winter Simulation Conferenceで発表されたSargentらの論文はこの考え方を示し、誤ったモデルを受け入れてしまうモデル利用者のリスクを小さく抑える必要があると指摘しています。平たく言えば、モデルが先月の結果を再現できないなら、来月の判断に使ってはいけません。

ドライバーを把握してください。 各前提条件をその範囲内で変化させ、どれが結果を大きく動かすかを確認します。多くの場合、2つの前提が支配的です。それらにはより良いデータを用意する価値があります。残りは大まかなままでかまいません。

1つの数値ではなく、範囲を示してください。 「木曜日に出荷します」という表現は、実際には持っていない精度があるように見せてしまいます。「修理時間によって、水曜日から金曜日の間」の方が誠実で、より役立ちます。意思決定者は、不確実性が見えていれば適切に扱えます。

どうすれば、プロジェクトではなく習慣として定着させられるでしょうか？

シナリオ分析は、1人のスプレッドシートに依存していると失敗します。以下のいくつかの取り組みが、継続を支えます。

• ベースラインとモデルデータの責任者を決めてください。 責任者がいないと、モデルは工場の実態から徐々に乖離していきます。
• 毎週短い時間枠を設け、計画担当者、製造責任者、必要に応じて購買と営業も加えて、未解決の問いを確認してください。シナリオは20個ではなく、2つか3つに絞って持ち込みます。
• 事後に振り返ってください。 週が終わったら、実際に起きたこととシナリオが示していたことを比較します。どこがずれていたのか、そしてなぜかを確認し、モデルや範囲を更新してください。
• 出力だけでなく、ロジックも共有してください。 製造責任者が前提条件を理解していれば、早い段階で異論を出してくれます。それこそがこの取り組みの狙いです。
• 財務部門を巻き込んでください。 納期遅延を避けるための残業のようなコストに関する問いには、同じシナリオにコストの数値を加えたものが必要です。コストの入力値は一度合意しておき、会議のたびに数字が変わらないようにしてください。

基本が機能すれば、ライブデータが役立ちます。実際の進捗が計画に戻ってくるようになれば、シナリオは前日の計画ではなく、工場の実際の状態から始まります。まずはロジックとマスターデータを正しくしてください。弱いモデルの上にライブフィードを載せても、誤った答えが速く出るだけです。

よくある間違い

• 判断の裏付けがないままシナリオを実行すること。
• 複数のレバーを同時に動かし、何が効果を生んだのか誰にもわからなくなること。
• 途中でベースラインが変わったものと、シナリオを比較すること。
• サイクルタイムや修理時間に最良の数値を使うこと。
• モデルが「正しそうに見える」という理由で、バックテストを省くこと。
• 範囲ではなく、1つの数値だけを報告すること。
• あらゆることにシナリオを作りながら、どれにも基づいて行動しないこと。
• 判断の記録を忘れ、振り返りで比較できるものがなくなること。

Polarisの位置付け

共有機械、シフト、製品構成の変化に関するwhat-if の問いがある場合、表計算よりも生産システムのシミュレーションのほうが速く答えを出せます。iFAKT は、Polaris を ERP データと連携して動作する、生産向けの AI とデジタルツインとして説明しています。Polaris Simulator モジュールは、実際の判断を下す前に生産システムを仮想的に検証し、キャパシティ、人員配置、バッファのシナリオを含めて評価します。ボトルネックや稼働率の不均衡も可視化します。Polaris Optimizer モジュールは、制約条件のもとで最適化された計画を作成し、障害が及ぼす影響も分析します。まずは実際の一件の判断で試し、結果を信頼できる表計算による計算と照合してください。

関連して検討したいトピック

• 障害時の計画: 機械の停止、部材の遅延、欠勤に備えて、標準的な対応をあらかじめ準備する方法。
• キャパシティと有限スケジューリングの比較: 週単位の負荷表では問題がなさそうに見えても、日次のスケジュールが破綻する理由。
• 製品構成の変化: 複雑なバリエーションへの移行がボトルネックをどのように移動させるかを検証する方法。
• 実務におけるモデルの検証: 過去の期間について、シミュレーションによるリードタイムと実際のリードタイムを比較する方法。
• シナリオのレポート: マネージャーがロジックを追えるよう、ベースラインと各シナリオを Power BI で並べて表示する方法。

次のステップ

手元にある次の判断を一文で書き出してください。そのうえで、現在の計画をベースラインとして保存し、一度に一つの条件だけを変えて三つのシナリオを実行します。生産計画におけるこの小さな what-if シナリオ分析を一巡させれば、この方法が毎週の会議に定着する価値があるかどうかが見えてくるはずです。