リソースと容量計画

リソースとは

プロセスシミュレーションにおけるリソースとは、アクティビティが利用を競い合う、容量に限りのあるものを指します。リソースを設定すると、シミュレーションに現実的なボトルネック、キュー、待ち時間が生まれます。無料トライアルで、実際のプロセスを使ったシミュレーションをお試しいただけます。

主なリソースの種類

カテゴリ	例
人員	カスタマーサービス担当者、融資担当者、マネージャー、専門職
設備	機械、作業端末、検査機器
システム	ソフトウェアライセンス、サーバー容量、APIの利用上限
施設	会議室、生産ライン、検査ステーション

リソースをモデル化する理由

リソースの制約がない場合、シミュレーションでは容量が無制限とみなされ、すべてのケースが待ち時間なく処理されます。多くのプロセスの実態とは異なる結果になります。

リソースをモデル化すると、次のことが可能になります。

• 現実に即したボトルネックの特定
• 待ち時間の正確な予測
• 容量計画と what-if 分析
• 最初に容量が不足する箇所の把握

リソースプール

ProcessMindでは、リソースは互換性のある単位ごとにプールとしてまとめられます。

プールのプロパティ

プロパティ	説明
名前	リソースを識別する名前（例：「承認担当者」「融資処理担当者」）
容量	プール内で利用できる単位数

容量について

容量は、そのリソースを同時に利用できるアクティビティの数を表します。

• 容量＝1：一度に1件のケースだけがこのリソースを利用できます
• 容量＝5：最大5件のケースがこのリソースを同時に利用できます

**例：**承認部門に担当者が3人おり、それぞれが一度に1件の承認を処理できる場合、容量を3に設定します。

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

プロセス内の各アクティビティで、必要なリソースを指定できます。

割り当てのプロパティ

設定	説明
リソースプール	使用するリソースプール
数量	必要なリソースの単位数

基本的な割り当て

多くのアクティビティでは、1種類のリソースを1単位使用します。

• アクティビティ：「申請を審査」
• リソース：「融資担当者」（数量：1）

複数単位の割り当て

複数単位のリソースが必要なアクティビティもあります。

• アクティビティ：「重要案件の意思決定委員会」
• リソース：「シニアマネージャー」（数量：3）

リソースの割り当て：ケースへのリソースの割り当て方法

リソースが必要なアクティビティにケースが到達すると、シミュレーションでは次の手順で処理されます。

割り当ての流れ

1. 空き状況を確認：必要なリソースを利用できるか確認します
2. 必要に応じてキューに追加：利用できない場合、ケースは待機キューに入ります
3. 待機：リソースが利用可能になるまでケースは待機します
4. 割り当て：リソースが利用可能になると、そのケースに確保されます
5. 実行：サンプリングされた所要時間にわたってアクティビティが実行されます
6. 解放：完了すると、リソースはプールに戻ります

キューの動きと戦略

ProcessMindでは複数のキュー戦略を選択でき、リソースが利用可能になったときに、待機中のケースを処理する順序を決められます。

戦略	説明
FIFO	先入れ先出し：到着した順にケースを処理します（デフォルト）
LIFO	後入れ先出し：最後に到着したケースから処理します
ランダム	待機キューからケースをランダムに選択します

要素設定で、アクティビティごとにキュー戦略を設定できます。

リソースを利用できない場合

必要なリソースが使用中の場合：

1. ケースはそのリソースの待機キューに入ります
2. ケースは待機します（シミュレーション時間が進みます）
3. リソースが空くと、設定されたキュー戦略に従って待機中のケースが選ばれます
4. その後、アクティビティが開始します

このキューの動きによって、シミュレーションに現実的な待ち時間が反映されます。

周期を設定したリソースの稼働状況

リソースを常に同じキャパシティで利用できるとは限りません。周期を設定すると、利用可能な量の変化をモデル化できます。

例：営業時間

周期	容量
平日ごと 09:00～17:00	担当者5人
平日ごと 17:00～21:00	担当者2人
週末の各日 10:00～16:00	担当者1人
デフォルト	担当者0人

例：シフトスケジュール

周期	容量
毎日 06:00～14:00（朝）	オペレーター5人
毎日 14:00～22:00（夕方）	オペレーター3人
毎日 22:00～06:00（夜）	オペレーター1人

例：季節による変動

周期	容量
毎年11月15日～12月31日（繁忙期）	スタッフ20人
デフォルト	スタッフ12人

リソースの稼働状況の見方

稼働率は、リソースが利用可能な時間のうち、作業に使われた時間の割合です。

稼働率＝（稼働時間÷利用可能な合計時間）×100％

割合ではなく、容量への負荷を確認する

シミュレーションで確認できる結果からも、同じ状況を判断できます。アクティビティの開始前の待ち時間や、繁忙時にキューがどのように増えるかを確認してください。

確認できる状況	意味
待ち時間がほとんどなく、キューも増えない	稼働率が低く、容量に余裕がある可能性があります
短い待ち時間がときどき発生する	変動に対応できる、適切なバランスです
待ち時間が定期的に発生し、キューが一定している	稼働率が高く、繁忙時の余裕が限られています
繁忙時にキューが増えるものの、その後解消する	負荷が高く、遅延の原因になっている可能性があります
キューが増え続け、解消しない	ボトルネックが発生し、需要が容量を上回っています

容量不足に陥る落とし穴

リソースの負荷が高いとキューが長くなる理由

簡単な例を見てみましょう。

• リソース容量：1
• 平均処理時間：10分
• 到着数が平均毎時5.5件の場合：キューは運用しやすい範囲に収まります
• 到着数が平均毎時5.9件の場合：キューが急増します

到着数がリソースの処理能力に近づくと、ランダムな変動（到着数が少し増える、処理時間がわずかに延びるなど）によって、キューの増加が解消の速さを上回ります。

共有リソース

1つのリソースプールを複数のアクティビティで共有できます。これは一般的で、実態にも即した設定です。

共有リソースの設定

1. リソースプールを作成します（例：「カスタマーサービスチーム」）
2. 同じプールを複数のアクティビティに割り当てます
3. アクティビティ間で共有容量を使います

例：スタッフの共有

「カスタマーサービスチーム」（容量：5人）が、次の業務を担当します。

• 「電話での問い合わせに対応」
• 「メールでの依頼を処理」
• 「チャットサポートに対応」

3つのアクティビティは、すべて同じプールを使います。電話対応中の担当者が4人の場合、メールやチャットに対応できるのは1人だけです。

共有リソースの利点

• 複数の業務に対応できる柔軟なチームをモデル化できます
• 異なる種類の業務間で生じる競合を確認できます
• リソースを多く使うアクティビティの種類を把握できます

複数のリソースを必要とするアクティビティ

複数種類のリソースを同時に必要とするアクティビティもあります。

例：設計レビュー会議

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

重要：必要なリソースがすべて同時に利用できる場合に限り、アクティビティを開始できます。デザイナーが空いていても会議室が使えなければ、ケースは待機します。

複数リソースを扱う際の注意点

• 複雑な待ち時間が発生することがあります
• 複数種類のリソースを占有するアクティビティに注意してください
• すべてのリソースが本当に同時に必要か確認してください

シミュレーションによる容量計画

リソースシミュレーションの特に有用な用途の1つが、容量計画です。

シミュレーションで確認できる主な点

必要なリソース数はどれくらいですか？

容量を変えてシミュレーションを実行します。

容量	平均待ち時間	処理量
スタッフ2人	45分	週150件
スタッフ3人	12分	週150件
スタッフ4人	3分	週150件

**インサイト：**スタッフを1人増やすと、待ち時間が大幅に短縮されます。4人目を追加しても改善幅は小さくなります。アクティビティが制約ではなくなるため、処理量は変わらず、待ち時間だけが短くなります。

ボトルネックはどこにありますか？

各アクティビティがプロセスにもたらす待ち時間を比較します。待ち時間が最も長く、増加の速いアクティビティが制約となっています。

リソース	アクティビティ開始前の平均待ち時間
受付	4分
審査担当者	2時間10分
法務審査	8分
クロージングチーム	35分

**インサイト：**審査担当者がボトルネックです。受付スタッフを増やしても解決にはならず、審査に回る案件がさらに早く積み上がるだけです。

需要が増えた場合、どうなりますか？

到着率を高めたシナリオを実行します。

需要	現在のスタッフ数	キューの増加
現状	5人	安定
＋20％	5人	緩やかに増加
＋50％	5人	維持できない

**インサイト：**現在の容量では、約20％の需要増加に対応できます。それ以上の増加には、リソースの追加が必要です。

リソースをモデル化する際のベストプラクティス

シンプルに始める

実際の制約を表す主要なリソースをいくつか設定することから始めます。

• 一人ひとりを個別のリソースとしてモデル化しないでください
• 互いに代替可能な担当者をプールにまとめます
• 必要な箇所に限って詳細を追加します

実際のデータを使う

実際の人員配置をもとに容量を設定します。

• 現在の従業員数
• 勤務時間とシフト
• 過去の稼働状況（休暇や病欠を考慮）

余裕を持たせる

実際のリソースは、常に100％稼働できるわけではありません。

• 人は休憩を取ります
• 設備にはメンテナンスが必要です
• 予期しない欠勤も発生します

理論上の最大値ではなく、現実的な稼働可能時間をモデル化してください。

実態と照らし合わせる

シミュレーションの待ち時間やキューの長さを、実際に観測した値と比較します。

• シミュレーションのキューの長さは、実際の待ち時間と一致していますか？
• シミュレーションの処理量は、実際の処理量に近いですか？
• キューの動きは実態に即していますか？

一致しない場合は、リソースモデルを調整してください。

人の要素を考慮する

人は機械とは異なることを念頭に置いてください。

• 生産性は時間帯によって変わります
• 高い稼働率が続くと、疲弊やミスにつながります
• 複数業務のトレーニングにも限界があります

次のステップ