同じチームの中で、いつも特定の1人だけに仕事が集中していないでしょうか。その人は忙しく、隣の人は手が空いている。そんな状態が続くと、忙しい人はいずれ疲弊し、チーム全体の速度が落ちます。このページでは、仕事の量そのものを、複数人にどう配るかを考えます。
コンピュータの世界での負荷分散
利用者からのアクセスが増えたウェブサービスを考えます。1台のサーバーだけで全部のアクセスを受けると、そのサーバーの処理が追いつかなくなります。そこで、複数台のサーバーを用意し、アクセスをあらかじめ振り分けます。この振り分け役を、負荷分散装置と呼びます。
負荷分散とは、複数の処理者に仕事の量を均等に配り、特定の1台だけが過負荷にならないようにする技術です。振り分け方には、順番に均等に回す方式や、今どれだけ手が空いているかを見て配る方式など、いくつかの種類があります。
前者は、来た順に1台目、2台目、3台目、1台目、と機械的に割り当てる方式です。仕組みが単純で分かりやすい一方、1件ごとの重さが違うと偏りが生じます。たとえば3台に順番で回していても、1台目に重い処理ばかりが偶然続けば、その1台だけが結果的に過負荷になり、他の2台は余力を残したままになります。後者は、その時点でいちばん手が空いている処理者に回す方式です。重さがバラバラな仕事を扱うときほど、この方式が効いてきます。どちらの方式にも一長一短があり、扱う仕事の性質によって、どちらを使うかを選びます。
ここで大事なのは、負荷分散が「順番」の話ではなく「配分」の話だという点です。どの順番で処理するかを決めるのは、2章で見たスケジューリングの役割です。誰にその仕事を担当させるかを決めるのが、負荷分散の役割です。両者は似ていますが、扱う軸が違います。
仕事の言葉に翻訳する
負荷分散を仕事に翻訳すると、「問い合わせや依頼を、特定の1人に集中させず、チーム内に均等に配る仕組み」になります。
均等に配るためには、まず今どれだけの仕事を各人が抱えているかが、チーム内から見える必要があります。見えなければ、配る判断そのものができません。負荷分散の前提は、負荷が見える状態を作ることです。これは、単一障害点を見つけるときに業務フローを書き出したのと、同じ発想です。見えていない負荷は、配りようがありません。
見える化の具体的なやり方は、難しいものである必要はありません。各自が今抱えている案件数を、共有のボードや表に週の初めに書き出すだけでも十分です。大事なのは精密さではなく、偏りに気づける頻度です。
毎日更新する必要はなく、週に1回でも、見えていない状態よりはるかに前進します。逆に、精密な集計システムを整えようとして導入自体が止まってしまうよりは、簡単な方法でまず始め、必要に応じて改善していく方が現実的です。
具体的な場面
1つめの場面は、問い合わせ対応です。すべての問い合わせが、経験の長い1人に自動的に割り振られる運用だとします。その人が忙しくなるほど、対応は遅れます。問い合わせの種類ごとに担当を分けたり、受付順に手の空いている人へ回したりする仕組みにすれば、特定の1人への集中を避けられます。
具体的な会話にすると、次のようになります。新しい問い合わせが来たとき、これまでは無条件で「じゃあAさんお願い」でした。これを、「今日の対応件数がいちばん少ない人にお願いします」というルールに変えます。ルール1つを変えるだけで、割り振りの判断に迷わなくなります。
2つめの場面は、複数の案件を抱えるチームです。声の大きい依頼者や、頼みやすい相手の案件が、特定のメンバーに偏って集まることがあります。案件の数と負担を、定期的に一覧にして見える化すれば、偏りに早く気づき、配り直せます。
たとえば週次のミーティングで、案件の一覧をホワイトボードに書き出したところ、Dさんだけが他のメンバーの倍近い件数を抱えていたことに気づいたとします。その場で1、2件を別のメンバーに動かすだけで、翌週の負荷は均されます。見える化しなければ、この偏りは気づかれないまま蓄積し続けます。
3つめの場面は、新しい業務の割り当てです。新しい仕事が発生したとき、「とりあえずできそうな人に頼む」を繰り返すと、できる人にだけ仕事が集まり続けます。誰に頼むかを決める前に、今の抱え方を確認する一手間が、負荷の偏りを防ぎます。
会話にすると、こうなります。上司が新しい業務を思いついたとき、真っ先にEさんの顔が浮かんだとします。そこで一呼吸置き、「今Eさんは何件抱えているか」をチームの一覧で確認します。Eさんがすでに手一杯だと分かれば、次に手が空いているFさんに声をかけます。この一呼吸が、特定の人への集中を防ぐ習慣になります。
依頼を振り分け役が受け取り、3人の担当者に均等に配っている様子です。
「頼みやすい人に頼んで何が悪い」という反論
負荷分散の話をすると、「早く確実に終わらせたいから、得意な人に頼むのは当然ではないか」という反論が出ることがあります。
この感覚は自然なものです。1件だけを見れば、得意な人に頼む方が速く、質も高いことが多いからです。急ぎの案件であればなおさら、実績のある人に頼みたくなるのは無理もありません。問題は、この判断を積み重ねた結果として何が起きるかです。1件ごとの最適が、チーム全体では特定の1人への集中を生みます。個々の依頼者にとっての最適と、チーム全体にとっての最適は、必ずしも一致しません。1件ずつ見れば正しい判断の積み重ねが、全体では歪みを生むという構図です。
対応としては、「得意な人に頼む」こと自体を禁止する必要はありません。その代わり、その人の抱えている量を定期的に見えるようにし、限界に近づいたら意識的に他のメンバーへ回す判断を挟むことが現実的です。完全に均等にすることが目的ではなく、限度を超える手前で止める仕組みがあれば十分です。
落とし穴
負荷分散には、2つのよくある落とし穴があります。
1つめは、均等に配ることと、公平に配ることを混同することです。案件の数を均等にしても、難易度や重さが揃っていなければ、負担は均等になりません。数だけでなく、重さを考慮した配り方が必要になる場面があります。たとえば、件数は同じでも、1件あたりの対応時間が大きく違う依頼が混ざっていれば、件数だけを見た配分は実態とずれます。3件抱えていても軽い依頼ばかりの人と、2件でも重い依頼を抱える人とでは、実際の負担は後者の方が大きいこともあります。「件数」ではなく「かかる時間の見積もり」で配ることが、実態に近い配分になります。
2つめは、負荷分散を導入したことで安心し、そもそもの仕事の総量を減らす努力をやめてしまうことです。配り方を変えることは、チーム全体の仕事量そのものを減らすわけではありません。配分の工夫と、業務量そのものの見直しは、別の課題として扱う必要があります。配り方の工夫は対症療法であり、業務量そのものが多すぎる問題は別に扱います。
たとえば、チーム全体の案件数が毎月増え続けているのに、配り方だけを工夫して均等にならしても、いずれ全員が同時に手一杯になります。その状態になって初めて、「そもそも人を増やすべきか」「引き受ける案件の量そのものを見直すべきか」という、一段上の問いに向き合う必要が出てきます。負荷分散は、その問いを先送りにするための道具ではありません。
ここまでの3つの視点、単一障害点・冗長化とフェイルオーバー・負荷分散は、どれも「人と仕事の配置」を扱ってきました。次のページでは、視点を少し変え、「情報の共有のタイミング」を扱います。全員が今すぐ同じ情報を持っていなくてもよい、という結果整合性の考え方です。
持ち帰り
- 負荷分散とは、複数の担当者に仕事の量を均等に配る技術のこと
- スケジューリングが「順番」を決めるのに対し、負荷分散は「誰が」を決める
- 均等に配ることと、負担を公平にすることは、同じではない
やってみる
チームの案件一覧を見て、今週いちばん多くの案件を抱えている人を1人、確認してみてください。