コンテキストスイッチの真のコスト：500万件のGitHub PRが示すもの
500万件以上のPRデータを分析し、開発者のコンテキストスイッチコストを計測。本当のボトルネックは意外な場所にあります。
By Ellis Keane · 2026-03-29
多くの記事で引用されるコンテキストスイッチコスト – 割り込みから再集中するまでに23分かかるというGloria MarkのUCアーバイン研究 – は、実際の研究から得られた実際の知見です。しかし、その研究が対象としたのは2008年の一般的なナレッジワーカーであり、ソフトウェアエンジニアではありませんでした。そして、23分という数字を推定された1日の割り込み回数（著者の気分によってたいていは6〜15回）と掛け合わせ、憂慮すべき年間コストを導き出すブログ記事の産業（いつも頭を抱えるストック写真付き）は、元の研究が意図しなかったことをしています。
私はこの問いに個人的な関わりがあります。以前の会社で – これは誇張ではありませんが – ある日の業務時間の80〜100%を、ただの人間ルーターとして過ごしたことがあります。コードを書いているわけでも、レビューしているわけでもなく。どのシステムも互いをつないでいなかったため、人とツールの間で情報を転送していたのです。その経験がSugarbugを作った理由の一部ですが、同時に、標準的なコンテキストスイッチコスト計算機に懐疑的な理由でもあります。それらは割り込みを測定します。しかし、本来着手するはずだったことに一度もたどり着けない日々は測定しません。
そこで私たちは、エンジニアリング業務においてコンテキストスイッチが実際に何をコストとしているのかを知りたいと思いました。抽象的な開発者生産性の観点からではなく、チームが毎日生み出す成果物であるプルリクエストで測定することにしました。数千のオープンソースプロジェクトにまたがる500万件以上のPRを対象とした3つの大規模調査の知見を統合し、PRレビュー時間を実際に左右するものを調べました。
主な発見：最もコストの高いコンテキストスイッチは、フローを破るSlack通知ではありません。レビューキューに1日放置されたプルリクエストであり、質問がようやく届いた際に著者がメンタルモデル全体を再構築することを余儀なくされるものです。
参照したデータセット
独自のスクレイパーを構築して1万件のPRを個別に分析したわけではありません。2本の査読済み研究と1つの大規模業界データセットから知見を統合し、その結論を相互に検証しました。
stat: "3.35M" headline: "Zhang らが分析したプルリクエスト数" source: "Pull Request Latency Explained: An Empirical Overview (Empirical Software Engineering, 2022)"
3つの主要データセット：
これらを2024年 DORA State of DevOps レポートおよびAtlassianの2024年 Developer Experience レポート（2,100人以上の開発者を対象に、コンテキストスイッチ、開発者生産性、人間的側面を調査）と相互参照しました。
キューこそが本当の問題
Zhang らは、PRが最初の応答（最初のコメント、最初のレビュー、何であれ最初のアクション）を受け取るまでの時間が、PRの総寿命の分散の58.7%を説明することを発見しました。これはデータセットで観測された最も強い予測因子です – PRサイズ、コードの複雑さ、変更ファイル数を上回っています！比較になりません。
コードレビューにおけるコンテキストスイッチの最大コストは、スイッチング自体ではありません。それは、誰もが他のことに追われてスイッチングを繰り返している間に形成されるキューです。
実際にどういうことかを考えてみましょう。エンジニアが午前10時にPRを開きます。担当レビュアーは自分のフィーチャーブランチに集中しているか、会議中か、Slackメッセージをトリアージしているか（正直、おそらく3つとも順番に）。PRは放置されます。午後3時に誰かがそれを拾うころには、著者はすでに別の作業に移っています。そこでレビュアーが質問を送ると、著者は5時間前に書いたコードへコンテキストスイッチして戻り、メンタルモデルを再構築し、返答します。その返答が届くのは午後4時半ですが、レビュアーはすでに帰宅しています。
PRはさらに1日老います。
データが示すのは、これは規律の問題というよりキューイングの問題だということです。そして、そのキューのコンテキストスイッチコストは、割り込み計算機が完全に見逃す形で複利的に積み重なります。
小さなPRでは解決しない
これは聞いたことがある話でしょう：小さなPRほど早くレビューされるから、PRを小さく保て。それは完全に間違いではないのですが、効果の大きさは（本当に）期待より小さいのです。
Adadotによる30万件以上のPRの分析では、PRサイズとリードタイムの間のケンドールのタウ相関係数はわずか0.06という弱い関連性でした。ただし、この研究では集計値の信頼区間は報告されていません。100行未満のPRが1週間以内に完了する確率はおよそ80%と聞くと素晴らしいように思えますが、それは誰かのレビューキューに6日間放置されたPRの完了率と同じだということに気づくまでは！
stat: "0.06" headline: "PRサイズとリードタイムの相関係数" source: "Adadotによる約3万人の開発者からの30万件以上のPR分析（2023年）"
より興味深い発見：この相関は組織によって大きく異なり、0.1から0.7近くまで幅がありました。これは、PRサイズそのものがボトルネックではなく、PRを取り巻くレビュー文化とプロセスが問題だということを示唆しています。強固なレビューリズムを持つチームは大きなPRも効率的に処理できます。レビューを後回しにするチームはどんなサイズのPRでも苦労します。
SmartBear/Ciscoのコードレビュー研究が示す400行の閾値は有用なヒューリスティクスとして成立しており、Adadotのデータもその範囲を超えるとレビューへの関与が低下することを示しています。しかし、根本的なレビューリズムを修正せずにPRサイズだけを最適化するのは（試みたすべてのエンジニアリングマネージャーへの真摯な敬意を込めて言いますが）、デッキチェアを並べ替えているようなものです。
全員が同時にすべてをレビューしている
マルチレビュー研究では、プルリクエストの62%に、複数のPRを同時にレビューしている開発者が関与していることがわかりました。さらに重要なのは、統計的に有意な相関が見つかったことです：レビュアーあたりの同時レビュー数が多いほど、PRの解決レイテンシが長くなっていました。
プルリクエストの62%に複数のPRを同時にレビューしている開発者が関与しており、マルチレビューはより長い解決時間と直接相関しています。 attribution: マルチレビュープルリクエスト研究、760プロジェクトにわたる180万件のPR
そのメカニズムは直感的です（この研究が観察研究であるため因果関係の方向性は証明されていませんが）。レビュアーがPR #1に取り組み、差分を読み、コードが何をしようとしているかのメンタルモデルを形成し始めます。そこへ通知が届きます – PR #2がデプロイをブロックしているためレビューが必要です。レビュアーはスイッチします。PR #1に戻ってきたとき、メンタルモデルが失われているため差分の半分を読み直さなければなりません。
これを8人のエンジニアチームに拡大して想像してください。それぞれが2〜3件のPRをオープンにし、2〜3人の同僚のためにレビューしています。調整のオーバーヘッドが自ずと説明されます。また、2024年DORAレポートでは「ハイパフォーマー」クラスターが31%から22%に縮小し、ローパフォーマークラスターが17%から25%に増加しています。DORAはPRレビューの並行数を要因として特定していませんが、増加する調整オーバーヘッドはこのシフトの一因として考えられます。
コンテキストスイッチコスト推定の誤り
広く流通している「開発者一人当たり年間5万ドル」という数字について率直に言いましょう。こうした推定のほとんどの方法論は次のとおりです：23分の再集中時間を取り、1日の推定割り込み回数（著者の気分によってたいていは6〜15回）を掛け、開発者の時給を掛け、年換算します。
問題は数学が間違っているのではありません。問題は、すべてのコンテキストスイッチを同等に扱っていることです。深いコーディングからチームランチの場所を尋ねるSlackメッセージへのスイッチ – これはコンテキストスイッチです。あるPRのレビューから、まったく異なるコードベースの別のPRのレビューへのスイッチ – これもコンテキストスイッチです。しかし、認知コストは比べものにならないほど異なります。それを単一の時給に平準化することで、本当のダメージがどこで起きているかが見えなくなります。
具体的に言うと：前職の典型的な1日は、Notion、Linear、Mattermost、Proton Mail、Proton Calendar、Discord、Twitter、Farcaster、無数のTelegramとSignalチャンネルを行き来することでした – 半ダース忘れているでしょう。今は少数のツール（Signal、Obsidian、Figma、GitHub、メール、カレンダー）を使っています。スイッチあたりのコストは変わりませんでした。変わったのは、注意を奪い合うコンテキストの数と、実際に重要なコンテキストはどれかということです。
PRデータが示すのは、コストの高いスイッチはキューを生み出すものであり、フローを中断するものではないということです。PRをすぐに（数分以内に）レビューするよう通知を受けて50行の素早いレビューをする開発者 – これは高いリターンを持つ短い中断です。そのレビューリクエストを他の4つとともに並べて明日取り組む開発者 – これはレビュアーにとっては長い中断ですが、著者とチームにとってははるかに大きなコストを生み出します。
コスト計算機が測定するもの
- 個々の割り込み – 誰かのフローが途切れる頻度
- 再集中時間 – 以前のタスクに戻るまでの時間
- 時給の掛け算 – 大きく怖い年間数字
PRデータが実際に示すもの
- キューの形成 – 最初の応答を待つPR
- レビューの並行性 – 複数のPRを抱えるレビュアー
- カスケード遅延 – 著者のコンテキストスイッチがレビュアーの遅延を複利的に増大させること
チームへの示唆
チームの開発者のコンテキストスイッチコストを下げようとしているなら、実践的な答えは地味です – だから多く書かれないのでしょう。ツールでも、認定プログラム付きのプロセスフレームワークでもありません。レビューリズムです。（わかっています、わかっています。レビューリズムを改善して昇進した人は誰もいませんよね。）
LinearBの2025年エンジニアリングベンチマークは、3,000組織の610万件のPRから得られたもので、エリートなサイクルタイム（2.5日未満）を達成したチームには1つの共通点があることを発見しました：PRを素早くレビューしていたのです。PRの数が少ないからでも、PRのサイズが小さいからでも（ただし多くの場合そうでもありましたが）なく、レビューリクエストに数時間以内に応答することがチームの規範であり、後回しにされるものではなかったからです。
参考までに、BenとI – 2人チーム – の最初のPR応答は数時間ではなく、数分が平均です。これは規律自慢ではありません（私たちはそんなに規律正しくありません）。これはチームの合意です：レビューリクエストは、キューに入れない唯一の通知です。CIアクションと自動テストがメカニカルなチェックを処理するため、実際のコンテキストを必要とする人間のレビューは短く、即座に行われます。合意が先でした。ツールはそれを持続可能にしただけです。
実践的には次のことを意味します：
- サイクルタイムだけでなく、最初の応答までの時間を測定する。 DORAメトリクスを追跡しているなら、これを追加してください。PRのスループットの最も強い予測因子です（Zhang らによれば寿命の分散の58.7%を説明します）。
- レビューの並行性を制限する。 レビュアーが3件の保留中のレビューリクエストを抱えている場合、4件目は良いレビューを得られません。マルチレビューデータは並行性とレイテンシの明確な関連性を示しました。まず2件の同時レビューのWIP制限から始め、影響を監視してください。
- PRサイズだけを最適化するのをやめる。 小さなPRは良いですが、実際にレビューをするチームの代わりにはなりません。48時間のレビューバックログを抱えたまま1日に50行のPRを20件生み出すチームは、当日レビューで1日に200行のPRを5件生み出すチームより状況が悪いです。
- レビューが本物の仕事であることを認める。 Atlassianの2024年の調査では、開発者の69%が週に8時間以上を非効率さによって失っていることがわかりました。レビューはその非効率な時間の一つである必要はありません – ただし、「本物の」仕事への割り込みではなく、ファーストクラスのエンジニアリング活動として扱われる場合に限ります。
そして、生産性ツールの世界にいる誰もが（私たちを含め、正直に言えば）大声では言いたくない部分があります：エンジニアリングチームのコンテキストスイッチコストに対する最も効果的な介入はツールではありません。PRがいつレビューされるかについてのチームの合意です。チームの暗黙の規範が「時間ができたときにレビューに取り組む」であれば、いくらツールを使っても、PRデータが明らかにするキューイングカスケードを防ぐことはできません。
ツールは役に立ちます – 4つのブラウザタブを開かずにPRの全文脈を確認できることはスイッチあたりの認知負荷を下げますし、どのレビューが他の人の作業をブロックしているかを浮き上がらせることは優先順位付けに役立ちます。しかし、核心となるレバーは合意であり、合意はタダです。23分の計算機は不要です。
最もコストの高いコンテキストスイッチは、フローを破る通知ではありません。1日キューに放置されたレビューリクエストであり、質問がようやく届いた際に著者がメンタルコンテキストを再構築することを余儀なくされるものです。
シグナルインテリジェンスをあなたの受信箱にお届けします。
よくある質問
Q: 開発者一人当たりのコンテキストスイッチコストは年間いくらですか？ A: 推定値はさまざまですが、根拠となる研究は多くの記事が示唆するよりも薄いものです。カリフォルニア大学アーバイン校のGloria Markの研究では、割り込みごとに23分の再集中時間が必要とわかりました。Atlassianの2024年の調査では、2,100人以上の開発者の69%が週に8時間以上を非効率さによって失っていることがわかりました。ドル換算の数字は給与の前提、割り込みの頻度、「スイッチング」の定義に大きく依存するため、私たちはPRデータに注目しました。
Q: Sugarbugはエンジニアリングチームのコンテキストスイッチ削減に役立ちますか？ A: はい。SugarbugはLinear、GitHub、Slack、Figmaなどのツールをナレッジグラフとしてひとつにつなぎます。エンジニアは4つのタブを開くことなく、関連するPR、Slackのやり取り、Figmaのコメントなど、タスクのすべての文脈を確認できます。目標はスイッチを減らすことであり、ツールを減らすことではありません。
Q: レビュー遅延を最小化するための理想的なプルリクエストのサイズは？ A: Adadotによる30万件以上のPR分析では、コード100行未満のPRは1週間以内に完了する確率がおよそ80%であることがわかりました。400行を超えると、レビューの質と完了速度がともに低下します。小さなPRはレビュアーのコンテキストスイッチの負担も軽減します。
Q: SugarbugはGitHubのプルリクエストと連携しますか？ A: はい。SugarbugはGitHubのアクティビティ（PR、コメント、レビュー、ステータス変更）を取得し、他のツールにまたがる関連シグナルとリンクします。LinearのイシューからPRが生まれ、Slackのスレッドでアプローチが議論された場合、Sugarbugは3つを自動的に結びつけます。
Q: 「再集中に23分」という統計の出典はどこですか？ A: カリフォルニア大学アーバイン校のGloria Markの研究に由来します。「The Cost of Interrupted Work: More Speed and Stress」（CHI 2008）として発表されており、割り込み後に元のタスクへ戻るまでに平均23分15秒かかることが明らかになりました。この研究が対象としたのは一般的なナレッジワーカーであり、ソフトウェアエンジニアに特化したものではない点に注意が必要です。