2026.10.11 / VOL. 41 / 全 685 記事

トリウィア

高解像度な本音。

ぼんやりした世論を、Webディレクターの解像度で鮮明に、かつ辛口に切り出す記録。

Sponsored

「忙しい」が口癖のアンタ。作業量じゃなく、切り替えの回数で潰れてるんだよ

忙しさの実感は作業量よりも中断と切り替えの回数に左右されます。切り替えコストの正体、チャットと会議が集中を削る仕組み、記録して測るところから始める手順を解説します

仕事と組織

忙しいと言っている人のカレンダーを見ると、案外空いている。なのに本人の疲労は本物だ。矛盾はしていない。消えている時間は予定表に乗らないところ、つまり切り替えの回数に消えている。

切り替えには、毎回コストがかかる

作業Aから作業Bに移るとき、頭の中は瞬時に入れ替わらない。直前まで何をしていたかを保持したまま、新しい文脈を読み込み直す。この読み込み直しに時間がかかる。

プロセスの切り替えでキャッシュが無効になるのと同じだ。処理そのものは軽くても、切り替えが頻繁なら実効スループットは落ちる。

  • 30分の作業を3回に分けると、単純な3分割よりも合計時間が伸びる
  • 中断のあと、元の作業に戻るまでに何をしていたか思い出す時間が入る
  • 「あとでやる」が増えると、抱えている未完了の数自体が負荷になる

チャットは、切り替えを量産する装置だ

通知が1回来るたびに、切り替えが1回発生する。内容が5秒で済むものでも、コストは5秒では終わらない。1日に50回通知が来る環境では、まとまった思考ができる時間帯が消える。

厄介なのは、この消耗が予定表のどこにも記録されないことだ。だから「今日は何もできなかったのに疲れた」という感覚だけが残り、原因が特定できない。

スポンサーリンク

会議の入れ方で、1日の性質が変わる

同じ3本の会議でも、置き方で残る時間が全く違う。

  • 10時・13時・16時 — 空いているのは合計5時間ほどだが、1時間から2時間のブロックに分断される。重い作業に着手しにくい
  • 10時・11時・12時 — 午後がまるごと残る。同じ会議数でも、まとまった時間が確保できる

つまり会議は詰めたほうが、残りの時間の質が上がる。「間を空けたほうが余裕がある」は直感としては正しいが、まとまった時間を必要とする仕事には逆に働く。

自分で入れる予定が、いちばん削られる

他人からの会議は守られるのに、自分が作業のために確保した時間は簡単に譲られる。結果、分断される側が常に自分の作業になる。カレンダーに作業時間を他人から見える形で置くだけで、この非対称は少し改善する。

まず測る。減らすのは、その後

いきなり「通知を切る」「会議を減らす」に飛ぶと、必要な連絡が止まって別の問題が出る。順番としては、記録が先だ。

  1. 3日だけ、中断を記録する

    中断されたら時刻と内容を1行書く。分析はしない。回数と発生源が見えるだけで十分

  2. 発生源の上位2つを特定する

    たいてい特定の人か、特定のチャンネルに集中している。全体を平準化する必要はない

  3. その2つだけ、扱いを変える

    即時に応じる範囲を決める、まとめて確認する時間帯を決める、一次受けを別の人に回す。範囲を限定するから実行できる

「忙しい」を他人に伝えるときの問題

切り替えの多さは他人から見えない。だから「忙しい」と言っても、カレンダーが空いている人には伝わらない。伝わらないから、また依頼が来る。

ここで効くのは、感覚ではなく抱えている数を出すことだ。「今5件動いていて、うち2件が今週締切です」と言えば、相手は判断できる。「忙しいです」だけでは、相手は優先順位を決められないので、結局そのまま渡される。

そして、断るときは代案を添える。「今週は無理ですが、来週前半なら取れます」「これを後ろに倒せるなら受けられます」。受けるか断るかの二択で答えないほうが、仕事は通しやすい。

抱えている数が見える状態になると、依頼する側も自然に調整を始める。見えないから、無限に入ってくるだけだ。

まとめ

  • 忙しさは作業量ではなく、切り替えの回数で決まる部分が大きい
  • 切り替えのコストは予定表に記録されないので、原因として認識されにくい
  • 会議は分散させるより詰めたほうが、まとまった時間が残る
  • 自分のための時間は削られやすい。他人から見える形で置く
  • 減らす前に3日記録する。発生源の上位2つだけ扱いを変える

スループットを上げたいなら、処理速度より先に割り込みを見ろ。

参考・出典

※制度・統計・ガイドラインは改定されることがあります。実際の手続きや判断にあたっては、各機関の公式サイトで最新の内容をご確認ください。(リンク最終確認: 2026年9月30日)

書いた人

トリウィア編集部

ぼんやりした世論を、仕様書を読む解像度で切り出しています。Webディレクター兼エンジニア。