コンテキストスイッチで開発者1人あたり年間5万ドルのコスト
エンジニアリングチームにおけるコンテキストスイッチのコストを計算。ツール間の切り替えが開発者1人あたり年間5万ドル以上を消耗させることを実証します。
By Ellis Keane · 2026-03-28
開発者がエディターからSlackに切り替えてスレッドを読み、関連チケットを確認するためにLinearを開き、コメント内のFigmaリンクをクリックし、そして20分前に何をしていたか思い出そうとするとき、実際にどれだけのコストがかかるのでしょうか？
これは修辞的な質問ではありません。私は実際に数字を知りたかったのです。「コンテキストスイッチは悪い」というのは、誰もが計算することなく頷いてしまうような話です。そして、実際に計算してみると、その数字はもっと多くの人が怒るべきほど大きいものです。
そこで、計算を示します。入力値が出力よりも重要であるため、ステップごとに説明します。自分のチームに固有の数字を入力して、チームに合った数値を算出できるはずです。
入力値
チームの開発者が支払うコンテキストスイッチのコストを決定する変数が3つあります。それぞれ単独では議論の余地がないものです。掛け合わせたときに居心地が悪くなるのです。
変数1：発生頻度
職場での中断に関する研究は、ほぼ20年間にわたり同じ数値圏内を示し続けています。UC Irvineのグロリア・マーク氏の研究（生産性に関する文章で非常に頻繁に引用されているためほぼミーム化していますが、基礎的な方法論は堅固です）では、知識労働者は平均して約3分ごとにタスクを切り替えることがわかりました。そのすべてがツールの切り替えではありませんが、かなりの割合がそうです。
エンジニアリングチームに限定すると、私たちが観察したこと（および他のチームからの情報）に基づいて、1日あたり30〜50回の意味あるコンテキストスイッチという数字が実態に近いと感じます。ここでの「意味ある」切り替えとは、1つの認知的文脈を離れて別の文脈に入ることを指します。エディターからSlack、SlackからLinear、LinearからPRレビュー、PRレビューからいつの間にか話が進んでいるSlackスレッドへ戻る、といった具合です。通知をちらっと確認する程度はカウントしません（それ自体にもコストはありますが、別途計算が必要なため、ここでは扱いません）。
保守的な作業数として35を使用しましょう。Slackの利用が多いチームであれば、おそらくもっと高くなります。中断を減らすことに取り組んできたチームであれば、低くなるかもしれません。しかし35は合理的な中間値です。
変数2：回復にかかる時間
これが人々を困らせる数字です。マーク氏の研究では、中断後に元のタスクに完全に戻るまでの平均時間は23分であることがわかりました。「完全に戻る」というのはこの文の中で多くの意味を担っており、公平を期すと、すべてのコンテキストスイッチが23分の完全な回復を必要とするわけではありません。エディターからSlackのメッセージをさっと確認して戻る場合は、2〜3分で済むかもしれません。深いデバッグ作業からFigmaでのデザインレビューに切り替えて戻る場合は、簡単に23分かかります。
典型的な開発者が経験する浅い切り替えと深い切り替えの組み合わせを考慮した、より正直な1回あたりの平均は、おそらく8〜12分の範囲です。作業数として10分を使用しましょう。これは「コンテキストスイッチはそれほど悪くない」派に有利な数字ですが、それでも最終的な数字は驚くべきものになります。
変数3：支払っている給与
米国のソフトウェアエンジニアの中央値給与は年間約150,000ドルです（情報源や市場によって異なります）。福利厚生・機器・オフィス・税金を含む総コストは180,000〜200,000ドルになります。この計算では年間2,000労働時間を想定し、1時間あたり約90ドルに相当する180,000ドルを使用します。
計算
それでは始めましょう。
- 1日35回の切り替え × 1回あたり10分 = 1日350分の回復時間
- コンテキストスイッチからの回復に1日5.8時間を費やすことになります
- 8時間労働の場合、2.2時間の集中した生産的な作業しか残りません
もちろん、回復時間のすべてが無駄になるわけではありません（コンテキストを切り替えて戻る間も、ある程度有益な思考は行われています）。そのため、余裕を持って50%の効率係数を適用しましょう。回復中も天井を眺めているわけではありません。コードを再読し、メンタルモデルを再構築し、再度方向を確認しているのです。そのため、回復時間の半分は本当に生産的で、半分は純粋なオーバーヘッドとしましょう。
- 350分 × 50% = 1日175分の純粋なオーバーヘッド
- これは1日2.9時間、すなわち労働時間の約36%
- 時給90ドルとして：2.9時間 × $90 = 1日$261
- 250労働日で：$261 × 250 = 年間$65,250
余裕を持った50%の効率割引を適用しても、コンテキストスイッチのオーバーヘッドは開発者1人あたり年間$65Kになります。
効率係数をより厳しく設定すると（例えば回復中の生産性30%、オーバーヘッド70%）、数字は$91Kまで上昇します。10分ではなく生の23分の回復時間を使用すると、本当に非現実的な数字になります。
stat: "$50K+" headline: "開発者1人あたり、年間" source: "試算に基づく"
保守的な想定と余裕ある割引を適用しても、コンテキストスイッチのコストは開発者1人あたり年間約$50,000〜$65,000です。10人のチームであれば、誰も予算に組み込んでいない生産性オーバーヘッドが50万ドルに達します。
数字が間違いに見えるが、そうではない理由
即座に出てくる反論は「でも1日3時間もコンテキストスイッチで失っていない、そうなら気づくはずだ」というものです。そうですね、一まとまりで来れば気づくでしょう。問題は、そうではないことです。1回10分の35回に分散して、1日中散らばっているのです。それぞれが、取るに足らないと感じるほど小さく、集中を途切れさせるには十分大きいのです。
これは、スクリーンタイムを計測したときに驚く理由と同じです。誰もスマートフォンに1日4時間費やしているとは思いません。しかし、5分ごとの確認が積み重なり、計測するまでは見えない形で蓄積されます。コンテキストスイッチも同じように機能します。スクロールする代わりに、デザインレビューについて誰かからpingが来る前に作業していたコードベースのメンタルモデルを再構築しているのです。
もう一つの反論は「それらの切り替えの一部は必要だ」というものです。まったくその通りです。Slackを見ず、PRをレビューせず、プロジェクトボードを確認しない開発者は、孤立して間違ったものを構築している開発者です。問題は、コンテキストスイッチを全くしないかどうかではありません。各切り替えがそのコストに見合っているかどうかです。
深い作業から引き離して5分のコードレビューに向かわせるPRレビュー通知は（議論の余地はありますが）価値があります。「APIドキュメントがどこにあるか知っている人はいますか？」というSlack通知は、読んだ人に10分のコンテキスト税を課すことを考えると、まったく価値がありません。悲劇は、ツールがこれらを同じ緊急度で扱うことです。つまり、すべてを緊急として扱うため、何も緊急ではなくなるということです。
悲劇は、ツールがこれらを同じ緊急度で扱うことです。つまり、すべてを緊急として扱うため、何も緊急ではなくなるということです。 attribution: Chris Calo
お金が実際にどこへ行くのか
コストは均等に分散されているわけではありません。ほとんどコストのかからない切り替え（時刻確認、カレンダー通知をちらっと見る）もあれば、壊滅的なもの（深いデバッグセッションが無関係な会議で中断される）もあります。分布はだいたい次のようになります：
| 切り替えタイプ | 頻度 | 回復コスト | 1日のオーバーヘッド | |------------|-----------|---------------|----------------| | 浅い（通知をちら見、短い返信） | 約15回/日 | 2〜3分 | 30〜45分 | | 中程度（ツールの切り替え、短い会話） | 約12回/日 | 8〜12分 | 96〜144分 | | 深い（会議、PRレビュー、デザインの議論） | 約8回/日 | 15〜23分 | 120〜184分 |
深い切り替えがコストの大部分を占めていますが、最も正当化されやすいため、排除が最も困難でもあります。コードレビューが不要だと主張する人はいません。問題は移行コスト、つまりレビューに入り、そして以前にやっていたことに戻るために支払う税金です。
実際にコストを削減するもの
通常の「通知をまとめる」「カレンダーに集中時間をブロックする」というアドバイスは省きます。間違っているからではなく（間違っていません）、個人の規律で体系的な問題を管理する負担を開発者個人に押しつけるからです。これは、道路がポットホールだらけなのに、もっと注意深く運転するよう人々に求めるようなものです。
体系的な解決策の方が興味深いです：
ツールの境界数を減らす。 コンテキストがツールの境界を越えるたびに（SlackからLinear、LinearからGitHub、GitHubからFigmaへ）、切り替えコストが発生します。コンテキストが1か所に存在するか、少なくともすでに作業している場所に表示されれば、境界コストは下がります。これが接続されたツールの基本的な論拠であり、Sugarbugがツール全体にわたってナレッジグラフを維持するよう構築した理由です。自分でコンテキストを探しに行く必要がなくなります。
移行コストを安くする。 切り替えが必要な場合は、中断した場所から簡単に再開できるようにしてください。ブラウザのセッションマネージャー、ターミナルマルチプレクサー、IDEのワークスペース機能はすべて役立ちます。しかし最も効果的なのは、コンテキストを事前に読み込んでおくことです。SlackスレッドからLinearの関連チケットに切り替えたとき、チケットがすでに関連するSlackの会話・リンクされたPR・Figmaのコメントを表示している状態です。これがナレッジグラフの機能です。接続を事前に計算することで、頭の中で再構築する必要がなくなります。
不要な切り替えを完全になくす。 多くのコンテキストスイッチは、情報が間違った場所にあるために発生します。Linearを簡単に確認できないため、チケットのステータスをSlackで質問する人がいます。コミットメッセージにPRリンクがないため、LinearをPRリンクを探して開く人がいます。これらは情報取得のための切り替えであり、情報はすでにどこかに存在しているため、最も排除しやすいものです。ただ、必要な場所に表示されていないだけです。
開発者が決して見ない本当のコンテキストスイッチコスト
私が話したすべてのエンジニアリング組織（すでにこれについて考えているところばかりなので、偏ったサンプルですが）は、コンテキストスイッチが問題であることを認めています。ほとんどがプロセスで対処しようとしてきました（水曜日はミーティングなし、Slackフリーの時間、通知のバッチ処理）。情報アーキテクチャを変更することで、コンテキストがツールの境界を越える頻度を減らすという構造的なアプローチを試みたところはほとんどありません。
これは、構造的なアプローチが知られていないからではありません。それを実現するためのツールが最近まで存在しなかったからです。ツール同士が連携しなければ、ツールの境界越えを減らすことはできません。そしてナレッジグラフ層が存在するまで、開発者は1回10分の中断ごとに、年間$50Kのコンテキストスイッチ税を払い続けることになります。
シグナルインテリジェンスをあなたの受信トレイにお届けします。
Q: コンテキストスイッチの開発者1人あたりのコストはいくらですか？ A: 平均的なエンジニアリング給与と計測された回復時間を用いた計算に基づくと、コンテキストスイッチのコストは開発者1人あたり年間約48,000〜62,000ドルです。正確な数値は給与・切り替え頻度・回復時間によって異なりますが、桁の大きさは一貫しています。
Q: Sugarbugは開発者のコンテキストスイッチを削減しますか？ A: はい。Sugarbugはツールを単一のナレッジグラフに接続するため、Linear・GitHub・Slack・Figmaのコンテキストがすでに作業している場所に表示されます。何が起きたかを把握するために6つのタブを切り替える代わりに、関連するコンテキストがあなたのもとへ届きます。
Q: 開発者は1日に何回コンテキストスイッチをしますか？ A: 調査の推定値はさまざまですが、ほとんどのエンジニアリングチームでは1人1日あたり30〜50回の意味あるコンテキストスイッチが発生します。すべてがツールの切り替えではなく、会話の中断や会議の移行も含まれます。ツール間の切り替えが最も削減しやすいものです。
Q: Sugarbugはチームのコンテキストスイッチコストの定量化を支援できますか？ A: Sugarbugは接続されたツール全体のシグナルフローを追跡するため、コンテキストがツールの境界を越える頻度や情報がどこで失われるかといったパターンを浮き彫りにできます。分析ダッシュボードはまだ構築中ですが、基礎となるデータはすでに存在します。