このページの内容
> リソース > ドキュメント > simulation > リソース管理とキャパシティ・プランニング

リソース管理とキャパシティ・プランニング

リソースとは

プロセスシミュレーションにおけるリソースとは、アクティビティが確保し合う必要がある、限られたキャパシティを持つ要素全般です。リソースは、現実的なボトルネックやキュー、待ち時間をシミュレーションにもたらします。

よく使われるリソースタイプ

カテゴリ例
Peopleカスタマーサービス、ローン担当、マネージャー、スペシャリスト
Equipment機械、ワークステーション、検査機器
Systemsソフトウェアライセンス、サーバーキャパシティ、APIレート制限
Facilities会議室、生産ライン、検査場

なぜリソースをモデリングするのか

リソース制約がない場合、シミュレーションは無限キャパシティとして即時対応を想定します。多くの業務では非現実的です。

リソースをモデリングすることで以下が可能になります:

  • ボトルネックの発見
  • 現実的な待機時間の予測
  • キャパシティ計画やWhat-if分析
  • リソース利用パターンの把握

リソースプール

ProcessMind では、リソースが交換可能なユニットのプールとして管理されます。

プールのプロパティ

プロパティ説明
Nameリソースの識別名（例：「承認スタッフ」「ローン処理担当」など）
Capacityプール内で利用できるユニット数

キャパシティの理解

キャパシティは、このリソースを同時に利用できるアクティビティ数を表します:

  • キャパシティ = 1: 1件のみ同時利用可能
  • キャパシティ = 5: 5件まで同時利用可能

例: 承認部門に3人のスタッフがいて、それぞれ1件ずつ対応できる場合はキャパシティを3に設定します。

アクティビティへのリソース割り当て

各アクティビティには、必要なリソースを定義できます：

割り当てプロパティ

設定説明
Resource Pool割り当てるリソースプール
Quantity必要なリソースの数

シンプルな割り当て

多くのアクティビティは1種類1ユニットのリソースを必要とします：

  • アクティビティ：「Review Application」
  • リソース：「Loan Officers」(数量：1)

複数ユニットの割り当て例

複数ユニットが必要なアクティビティ例：

  • アクティビティ：「Major Decision Committee」
  • リソース：「Senior Managers」（数量：3）

リソース割り当て：ケースがリソースを取得する流れ

ケースがリソースを必要とするアクティビティに到達すると、シミュレーションは以下の流れで処理します：

アロケーションフロー

  1. 可用性を確認: 必要なリソースが利用可能かを確認します
  2. 必要ならキューに追加: 利用できない場合、caseは待ちキューに入ります
  3. 待機: リソースが利用可能になるまでcaseが待機します
  4. アロケート: 利用可能になったらリソースをこのcase用に確保します
  5. 実行: アクティビティがサンプリングされた期間動作します
  6. リリース: 完了後、リソースはプールに戻ります

キュー動作とストラテジー

ProcessMindは、リソースが使えるようになった時に待機中のケースの優先順位を決定する複数のキューストラテジーをサポートしています。

ストラテジー説明
FIFO先入れ先出し － 到着順にケースが処理されます（デフォルト）
LIFO後入れ先出し － 新しく追加されたケースが優先的に処理されます
Random待機キューからケースがランダムに選ばれます

キューストラテジーはアクティビティごとにエレメント設定で設定できます。

キューストラテジーの選び方

FIFOは最も一般的で公平な戦略です。LIFOは直近のケースの優先度が高い時（例：「緊急エスカレーション」）に向いています。Randomは予測できないサービスパターンをシミュレートしたい場合に役立ちます。

リソースが利用できない場合は？

必要なリソースがビジーのとき:

  1. caseは該当リソースの待機キューに入ります
  2. caseは（シミュレーション上の）時間が経過するまで待機します
  3. リソースが空いたら、設定されたキューストラテジーで待っているcaseが選ばれます
  4. アクティビティが開始します

このキューイング動作でシミュレーションに現実的な待ち時間が生まれます。

周期的なリソース可用性

リソースの可用性やキャパシティは常に一定ではありません。周期設定 を利用して、可用性の変動をモデリングしましょう。

例：営業時間

周期キャパシティ
平日 09:00-17:005名（エージェント）
平日 17:00-21:002名（エージェント）
週末 10:00-16:001名（エージェント）
デフォルト0名

例：シフトスケジュール

周期キャパシティ
毎日 06:00-14:00（朝）5名（オペレーター）
毎日 14:00-22:00（夕方）3名（オペレーター）
毎日 22:00-06:00（夜間）1名（オペレーター）

例：季節変動

周期キャパシティ
毎年11/15～12/31（繁忙期）20名（スタッフ）
デフォルト12名（スタッフ）

リソース使用率の可視化

使用率（Utilization） はリソースの稼働状況を可視化します：

使用率 = (稼働時間 ÷ 総可用時間) × 100%

使用率の目安

使用率意味
50%未満未活用気味—余剰キャパシティがある可能性
50-70%健全—変動にも対応しやすい
70-85%多忙—ピーク時の余裕が少ない
85-95%高稼働—遅延発生リスク高
95%以上ボトルネック—キュー発生

利用率トラップ

100％利用率を目標にしないでください

高い利用率は効率的に見えますが、問題を引き起こします。わずかな需要変動でも、利用率が100％に近いとキューが急激に増加します。安定したプロセス運用には70～80％を目標にしましょう。

なぜ高利用率でキューが長くなるのか

例えば:

  • リソースキャパシティ: 1
  • 平均処理時間: 10分
  • 1時間に平均5.5件到着（利用率55%）: キューは管理可能
  • 1時間に平均5.9件到着（利用率98%）: キューが急増

利用率が100％近くになると、少しの変動（到着数の増加やタスク時間の増加）でもキューが急速に積み上がります。

共有リソース

1つのリソースプールは複数のアクティビティに利用できます。これは現実の業務でもよくあるケースです：

共有リソースの設定方法

  1. リソースプール（例：「Customer Service Team」）を作成
  2. 複数アクティビティに同じプールを割り当て
  3. アクティビティ同士でキャパシティを取り合い

例：スタッフの共有

「Customer Service Team」（キャパシティ：5名）は以下を担当：

  • 「電話問い合わせ対応」
  • 「メールリクエスト処理」
  • 「チャットサポート対応」

これら全て同じリソースプールから供給されます。例えば、4件の電話中は、残り1名だけがメールやチャットに対応可能です。

共有リソースのメリット

  • クロストレーニングチームや柔軟な組織を再現
  • 異なる業務タイプ間のリソース競合を可視化
  • どのアクティビティがリソースを多く消費しているかを特定

複数リソースのアクティビティ

一部のアクティビティでは、同時に複数の異なるリソースが必要です：

例：デザインレビュー会議

リソースプール必要数
シニアデザイナー2
会議室1
デザインリード1

重要: このアクティビティは、すべての必要なリソースが同時に利用可能なときのみ開始できます。デザイナーが空いていても会議室が利用できない場合、そのケースは待機します。

複数リソース利用時の注意

  • 複雑な待ちパターンが発生しやすい
  • 複数タイプのリソース待ちが発生するアクティビティに注意
  • すべてのリソースが本当に同時必要か再検討

シミュレーションによるキャパシティプランニング

リソースシミュレーションの最も有効な用途の一つは、キャパシティプランニングです。

シミュレーションが答える主な質問

リソースは何人必要？

キャパシティ別でシミュレーションしてみましょう：

キャパシティ平均待ち時間使用率スループット
2名45分95%150/週
3名12分78%150/週
4名3分58%150/週

インサイト： 3人目を増やすと待ち時間が大幅短縮。4人目は効果が限定的。

ボトルネックはどこ？

全リソースの使用率を比較：

リソース使用率
受付65%
審査担当92%
法務レビュー48%
クロージングチーム71%

インサイト： 審査担当がボトルネック。受付を増やしても、結局審査で詰まります。

需要が増えたら？

到着数増加パターンでシナリオ検証：

需要スタッフ数キューの成長
現状5安定
+20%5ゆっくり増加
+50%5サステナブルでない

インサイト： 現状のキャパシティは約20%成長まで対応可能。それ以上は増員が必要です。

リソースモデリングのベストプラクティス

シンプルに始める

現実的な制約となる主要リソースから始めましょう：

  • 全員を別々のリソースとして細かく分けすぎない
  • 置き換え可能なスタッフはプール化
  • 詳細化は必要な部分のみ追加

実データを活用する

キャパシティ設定は実際の人員に基づいて行いましょう:

  • 現在のスタッフ数
  • 勤務時間やシフト
  • 有給・病欠などを考慮した過去の稼働実績

スラック（余裕）の設定

現実のリソースは100%常に利用可能ではありません：

  • 休憩時間がある
  • 設備のメンテナンスが必要
  • 突発的な欠勤も発生

理論上の最大値でなく、現実的な可用時間で設計しましょう。

現実と照合する

シミュレーション上の利用率と実際の運用を比較しましょう:

  • シミュレーションのキュー長は実際の待ち時間に合っていますか？
  • スループット（処理件数）は現実と近いですか？
  • リソース利用は現実的ですか？

違いがあれば、リソースモデルを見直しましょう。

ヒューマン要素を考慮

人は機械ではありません：

  • 時間帯によって生産性が変動
  • 高稼働の継続はバーンアウトやミスの原因
  • クロストレーニングにも限界があります

次のステップ

シミュレーション実行
シミュレーション設定時にリソースを設定します。
周期設定
リソースの可用性を時間帯ごとに管理します。
What-If分析
リソースパターン比較によるシナリオ分析。
仕組み
シミュレーションエンジンのリソース割り当てを解説します。

関連ドキュメント