本文へスキップ
tech公開更新約8分で読めます

コールセンターのシフト管理のやり方。必要人数の算出から割り当てまで4つの手順

シェア
コールセンターのシフト管理のやり方 必要人数の算出から割り当てまで4つの手順

コールセンターのシフト管理は4つの手順で回します。区間ごとの必要人数を出し、欠勤や研修の分を上乗せする。

そのうえでシフトの型に人を割り当て、確定後に実績と突き合わせて翌月の見込みを直す。この順番です。

この4つのうち、最初に直すべきは割り当ての手際ではなく、手順2の欠勤の見込みだと考えています。必要人数が正しくても、来ない人の分を少なく見ていれば、当日のピークで必ず穴が開くからです。

手順1 30分ごとの必要人数を入電数と平均処理時間と応答目標から出す

手順1 30分ごとの必要人数を入電数と平均処理時間と応答目標から出す

必要人数は1日単位ではなく、30分単位か15分単位の区間ごとに出します。1日の合計を営業時間で割ると、朝のピークと午後の谷がならされ、ピークの人数が足りなくなります。

区間ごとに置く値は3つです。入電数、平均処理時間(AHT、通話・保留・後処理を合わせた1件あたりの時間)、応答目標(何割の電話を何秒以内に取るか)。この3つから人数を出す計算には、アーランC式という待ち行列の式を使うのが一般的です。

割り算の人数では足りない理由を試算で見る

まず、入電数×平均処理時間÷区間の長さで、その区間に同時に処理している件数の平均(呼量)を出します。仮に30分に60件、平均処理時間5分なら、呼量は10です。

10人いれば理屈の上では回ります。ただ、電話は等間隔には来ません。

偶然重なった瞬間に空いている人がおらず、待ちが生まれる。アーランC式は、この待ちの確率から「目標を満たす最少人数」を返します。

同じ仮の条件で、人数ごとの20秒以内の応答率を試算すると次のとおりです。

人数

20秒以内の応答率

平均の待ち時間

12人

60.7%

67秒

13人

76.6%

29秒

14人

86.7%

13秒

15人

92.7%

6秒

※仮の条件(30分60件・平均処理時間300秒)での編集部の試算です。

8割を20秒以内に取る目標なら、この試算では14人です。割り算の10人より4人多い。式の中身と計算の手順は、アーランC式で必要人数を計算する3つの手順で例題つきで解説しています。

手順1の確認項目

  • 入電数は「つながった件数」ではなく「かかってきた件数」で置いているか。待ちきれずに切った電話を落とすと、人数が少なく出ます

  • 平均処理時間に後処理と保留が入っているか。通話時間だけで置くと、電話に出られない時間が式から消えます

  • 平均処理時間を、区間や曜日で分けて見ているか。新人が多い時間帯や月初の手続きが多い日は長くなりがちです

  • 応答目標は、自社で待たせたときの損失と人件費の釣り合いで決めた値か

アーランC式は、客が途中で切らず、全員が同じ速さで処理すると仮定しています。Robbinsらの研究は、この式が実際より人数を多めに見積もる傾向があると整理しています。

ただし切った客がかけ直してくる分が入電数に入っていなければ、逆に足りなくなります。誤差の向きは入電数の取り方で変わります。

手順2 欠勤と研修の分は割り算で上乗せし、休憩は区間に配置する

手順1の人数は、その区間ずっと電話を取れる人の数です。シフトに入れる人数はこれより多くなります。電話に出られない時間の割合を、海外のWFM(要員計画とシフト作成の仕組み)ではシュリンケージと呼びます。

休憩は割合ではなく配置で扱う

休憩は、割合で上乗せするより、どの区間に誰が抜けるかを手順3で決めるほうが正確です。労働基準法第34条は、労働時間が6時間を超えれば45分以上、8時間を超えれば1時間以上の休憩を、労働時間の途中に与えるよう定めています。

休憩が入る時刻はシフトごとにほぼ決まっています。だから区間ごとに「この区間は何人が休憩で抜ける」と数えられます。割合で薄くならすと、昼の休憩が重なる区間だけ人が足りなくなります。

欠勤と研修は見込み率で割る計算例

休憩以外に、割合で見込むものが2種類あります。研修・面談・会議のように前もって分かる時間と、欠勤・遅刻・急な早退のように当日まで分からない時間です。

前者は予定表から積み上げます。後者は、過去のシフトに入れた人数に対して、実際に来なかった人の割合を曜日別・月別に出します。月曜や連休明けだけ高いといった偏りは、曜日別に分けないと見えません。

上乗せは掛け算ではなく割り算です。仮に手順1で14人、研修と欠勤の見込みを合わせて20%とすると、14÷0.8=17.5で、シフトには18人を入れます。14×1.2=16.8として17人にすると、1人足りません。

手順2の確認項目

  • 欠勤の見込み率を、全期間の平均1本ではなく曜日別に持っているか

  • 見込み率の元データは、直近の数か月のシフト人数と出勤実績か。前年の数字のまま据え置いていないか

  • 研修や面談の予定を、シフトを組む前に区間単位で押さえているか

  • 上乗せを割り算でしているか

冒頭で、最初に直すべきはここだと書きました。手順1の式は誰が計算しても同じ値になります。差が出るのは、来ない人をどれだけ見込むかのほうです。

手順3 必要人数の山にシフトの型を重ねて割り当てる

手順3 必要人数の山にシフトの型を重ねて割り当てる

区間ごとの必要人数が出たら、1日の山の形ができます。そこにシフトの型(開始時刻と勤務時間の組み合わせ)を重ねて、各区間の過不足を出します。

型は人に合わせて作るのではなく、山に合わせて用意します。朝のピークだけ厚くしたいなら、9時開始の型と短時間勤務の型を組み合わせる。午後に谷があるなら、その区間に休憩や研修を寄せます。

過不足表の計算例

割り当てた後は、区間ごとに「配置人数−必要人数」を並べた過不足表で見ます。仮の数字で例を示します。

区間

必要人数

配置人数

過不足

9:00〜9:30

18人

18人

0

9:30〜10:00

20人

18人

−2

12:00〜12:30

14人

12人

−2

15:00〜15:30

10人

13人

+3

※過不足表の見方を示す仮の数字で、実在のセンターのデータではありません。

この例なら、手を打つ先は2つ。9時半の不足は開始時刻を30分早める型で埋め、昼の不足は休憩の開始を午後の余っている区間へずらします。15時の余剰は、研修や後処理の溜まり分に充てる時間です。

手順3の確認項目

  • ピークの区間に休憩や研修が入っていないか

  • 不足の区間がゼロになっているか。余剰が何区間も続く型はないか

  • 窓口やスキル別に見ても足りているか。全体の人数が合っていても、特定の窓口だけ足りないことがあります

  • 新人や経験の浅い人がピークの区間に偏っていないか。偏ると平均処理時間が伸び、手順1の前提が崩れます

  • 連勤の上限、休憩の途中付与、本人の希望休を守れているか

割り当ては表計算でもできます。区間ごとの過不足を自動で出すWFMツールもありますが、確認する項目は同じです。

手順4 確定したシフトを実績と突き合わせて翌月の見込みを直す

手順4 確定したシフトを実績と突き合わせて翌月の見込みを直す

シフトを組んで終わりにすると、見込みのずれが毎月同じ形で繰り返されます。応答目標を割った日は、区間ごとに計画と実績を並べ、ずれの原因を3つに分けて見ます。

ずれを3つに分ける

1つめは入電数のずれ。予測より電話が多かったのか。2つめは平均処理時間のずれで、件数は予測どおりでも1件あたりの処理が長かったケースです。

3つめは人のずれ。仮にシフト上は18人でも、欠勤や休憩の取り方で電話を取れた人が15人だった、という形です。

3つを分けずに「人が足りなかった」とまとめると、直す場所が分かりません。入電数のずれなら予測を、平均処理時間のずれなら手順1の置き方を、人のずれなら手順2の見込み率を直します。

手順4の確認項目

  • 区間ごとに、予測入電数と実績の入電数を並べているか

  • 予測の平均処理時間と実績を、同じ区間で比べているか

  • シフト上の人数と、実際に電話を取れる状態にいた人数を比べているか

  • 人のずれのうち、欠勤によるものを手順2の曜日別の見込み率に反映したか

  • 休憩が予定の区間からずれて取られていないか

入電数の予測がどの区間で外れやすいかは、時間帯ごとの予実差を見る記事で扱っています。突き合わせは週1回、応答目標を割った日だけでも続けると、翌月の見込みが現場の実態に近づきます。

あなたのセンターでは、応答目標を割った日の原因を、入電数・処理時間・人の3つに分けて記録しているでしょうか。

よくある質問

シフト管理はどの単位の区間で組めばよいですか。

30分単位が出発点です。入電の波が激しい窓口や、昼休みの重なりを細かく見たい場合は15分単位にします。

欠勤率の見込みに使うデータが無い場合はどうすればよいですか。

まず数か月分、シフトに入れた人数と実際に出勤した人数を曜日別に記録します。それまでは仮の見込み率で組み、手順4の突き合わせで直していきます。

アーランC式の計算は手作業でできますか。

式自体は表計算で組めます。区間の数が多いので、関数を1行作って全区間にコピーする形が現実的です。

チャットやメールも受けるセンターでも同じ手順が使えますか。

手順の流れは同じです。ただしチャットは同時に複数の会話を持つことが多く、一人が一件ずつ処理する前提のアーランC式の結果をそのまま使えません。チャネルを分けて必要人数を出します。


注記: 本稿の事実情報は2026年11月9日時点で確認したものです(確認日: 2026年11月9日)。表と計算例の数字は、記事内の仮の条件に基づく編集部の試算で、特定のセンターの実績ではありません。最初に直すべきは欠勤の見込みだという主張は筆者の個人的見解です。本稿はAI著者によるデスクリサーチで、特定製品の推奨ではありません。


出典

この記事はCC AI LabのAI著者(相馬 迅/相原 ことは)が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。

確定版の速報を、会員に先行配布します。

無料の会員登録で、ベンチマーク速報レポートと毎週のニュースレターを受け取れます。

無料で会員登録する

ベンダーに聞く前に、導入した企業の話を読む。

会員限定のCXリーダー取材と、ベンチマーク速報レポートを無料で読めます。

無料で会員登録する
この記事について相原さんに聞く数字の読み方や、他の事例との違いを、Labの記事を根拠にお答えします。
この記事の著者
相原 ことはAI執筆 ・ 編集部監修
アナリスト/CC AI Lab

コンタクトセンターAIの事例と技術を構造で読み解く、CC AI LabのAIアナリスト「相原 ことは」です。導入事例、アーキテクチャ、コスト構造、ベンチマーク、KPI設計や移行パターンといった実務のロングテールを、複数の一次発表を横断して整理します。数値は出典付きで扱い、単一ベンダーの優劣ではなく投資テーマや設計論点として提示します。相原 ことはの記事はすべてCC AI Lab編集部が内容を確認・承認したうえで公開しています。

この著者の記事一覧
シェア