業務プロセスのための離散事象シミュレーション

Inhaltsverzeichnis+

なぜ「離散」でなぜ「事象指向」か

シミュレーションで時間を扱う方法は二つあります。

時間ステップ指向： 時計が一定の刻みで進みます（毎分、毎秒など）、各ステップで何が起きたかを確認します。実装は簡単ですが計算資源を浪費します。承認プロセスの二つの事象の間に何時間も何も起きない時間があるのに、その間ずっと計算されるからです。

事象指向： 時計は次に予定された事象の時刻へ飛びます。事象と事象の間では状態が変わらないので、計算を行う必要もありません。

事象リスト（時刻順）：
  09:14  到着 処理#418
  09:22  処理終了#402 ステップ「検査」
  09:40  シフト交代 承認
  ...
時計は09:14に飛び、処理し、続く事象を予定し、さらに飛ぶ。

「離散」とは：状態が連続的に変化するのではなく、個々の時点で飛躍的に変わることを意味します。これは業務プロセスにぴったり合います。申請は処理済みか未処理かであり、中途半端に処理中という状態はありません。

四つの構成要素

最も重要な性質： 待ち行列はモデリングされるのではなく、発生することです。滞留時間を三日で固定するように設定する人は、結果を計算する代わりにすでに決めてしまっています。そうすると、容量やばらつきを変えたときにその時間がどう変わるかを示せません。

モデルが失敗する三つの判断

1. どの分布を使うか？

到着間隔には：指数分布。 これは、処理が独立に到着する場合（例えば複数の仕入先からの請求書や複数の利用者からのチケット）に標準的に仮定されます。受信箱で見られる振る舞い、つまり静かな時間が続いた後に三件同時に来るような挙動を生みます。

到着が一定のリズムで来る場合（例：月末の一括処理、毎朝8時の引き継ぎ）は指数分布ではなくカレンダーが必要です。

処理時間には：右裾が長い分布。 対数正規分布かガンマ分布。見積もりしかない場合は、最小値・最頻値・最大値から三角分布を使います。理由は、処理時間には厳密な下限があり右側に長い裾があるためです。正規分布は負の時間を生む可能性があり、異常値を過小評価して待ち行列を生む原因を見逃します。

実務上の経験則： 「5〜15分」しかわからない場合、モードを8にした三角分布を使ってください。対数正規とガンマの選択は、そもそもばらつきをどれだけ許すかという問題ほど結果に影響しません。

2. ウォームアップ期間

シミュレーションは空の待ち行列で開始します。これは実際のプロセスではほとんどない状態です。したがって最初の数日間は系統的に良すぎる結果になります。

対処法： 最初の数日を解析から除外する（ウォームアップ）、または現実的な初期在庫で開始します。稼働率が85％をかなり下回るプロセスなら数日で十分ですが、境界に近い場合は収束に数週間かかることがあります。

見分け方： 最初の週の平均が二週目の平均より明らかに低ければ、ウォームアップが短すぎます。

3. 何回実行するか？

単一のランはサンプル数1に相当します。単一の勤務日の情報しか持ちません。乱数を変えて繰り返し実行し、結果の幅が安定するまで行います。

実務的な基準： ランの数を二倍にしてみてください。そのときP50とP90が数パーセント以内でしか変わらなければ十分です。業務プロセスでは通常数百回になります。

件数そのものより重要なのは： 繰り返し実行することと、出力が区間として示されることです。単一の数値しか出力しないシミュレーションは、この手法の目的を果たしていません。

観点の比較

業務プロセスにはプロセス指向の見方が自然です：一つの案件に何が起きるかを書き出すことが、現場の業務フローの記述と正確に一致します。

検証：三つのチェック

1. Little's Law。 在庫 ÷ スループットはおおむねスループット時間になるはずです。モデルでも現実でも成り立ちます。この検査は分布に関する仮定を必要としないため、最も強力な検証です。

2. 稼働率と手計算の照合。 ρ = 需要 ÷ 容量は各ステップで電卓で再計算できます。モデルが大きく異なる場合は、分岐かカレンダーに誤りがあります。

3. 極値テスト。 あるステップの容量を二倍にしてください。何も変わらなければ、そのステップはボトルネックではありません。もしそうでないことを期待していたなら、モデルがあなたの理解と一致していないことになります。そこから議論が始まります。

DESが適さない場合

• 関係者が自身の判断で振る舞いを変える場合（顧客が中止する、担当が案件を選ぶ）→ エージェントベースシミュレーション。
• 在庫とフィードバックが何年もかかる規模の問題（人員増加、マーケット動態）→ システムダイナミクス。
• 待ち行列が存在しないほど容量が十分な場合 → 単純な加算で十分です。
• 実際に何が起きたかを知りたい場合 → Process Mining。DESは仮定を計算するものであり、ログの代わりにはなりません。