Slackとコードのコンテキストスイッチ: Deep Workに課す隠れたコスト
SlackとコードのコンテキストスイッチはDeep Workの時間を毎週奪います。コストの測定・削減方法とフロー状態を守る実践的アプローチを解説します。
By Ellis Keane · 2026-03-13
今日、実際に何分のDeep Workができましたか? 机に座っていた時間でも、IDEを開いていた時間でもありません。一つの問題に対する、実際の持続的で途切れのない集中時間のことです。自信をもって答えられるなら、嘘をついているか、SlackとコードのコンテキストスイッチをExperienceしたことがないかのどちらかです – 後者なら、ぜひやり方を教えてください。
聞くのは、自分でも毎日の数字がわからないからです。朝9時にデータベース移行の作業を始めたのは覚えています。ふと気づいたら午後1時になっていたのも。その間に、誰かが必要としているわけでもないのに、Slackを何十回と開いていました – あの小さな赤いバッジが持つ引力は、小さな衛星も恥じ入るほど強力なのです。本来なら午前中で終わるはずだった移行作業が、水曜日までずれ込みました。
「23分の神話」と実際のところ
「コンテキストスイッチの後、再集中するのに23分かかる」という統計を聞いたことがあるでしょう。これはUCアーバイン校のグロリア・マーク氏の研究に基づいていますが、あまりにも誤用されてきたため、今では感覚的な話になっています。23分という数字は、元のタスクに戻る時間を指しており、同じ深さの集中力を取り戻す時間ではありません。また、これはエンジニアだけでなく、知識労働者全般を対象とした測定値です。
エンジニアにとっての実際のコストは、頭の中に何を保持しているかによって完全に異なります。20分間じっと見つめた末に、ようやく3つの状態機械が互いに絡み合うメンタルモデルを構築した微妙なレース条件のデバッグ中であれば、そのモデルを失うとまた20分かかります。設定ファイルのタイポ修正なら? 数秒で済みます。重要なのは正確な数字ではありません。SlackとコードのコンテキストスイッチのコストはExperienceした瞬間には完全に見えませんが、週末のスプリントベロシティには明確に現れるという点です。
Lokalise ツール疲れレポートによると、ワーカーは1日平均33回アプリを切り替えており、17%の人は100回以上切り替えています。私たちは「生産性」ソフトウェアのエコシステムを構築してきましたが、その主な測定可能な効果は生産性を中断させることです。どこかのプロダクトマネージャーが、「まだ仕事に戻れるか確認しているだけの人々」で構成されるDAU数字を祝っています。
Slackとコードのコンテキストスイッチがなぜ特別に高コストか
Slackには公平を期したいと思います。これは本当に優れたツールで、エンジニアリングチームがIRCに戻るべきだと言うつもりはありません（時々そう思う日もありますが）。しかし、SlackからIDEへのコンテキストスイッチは、2つのブラウザタブを切り替えるより本質的に高コストです。その理由を理解する価値があります。
メンタルモデルの不一致。 コードに深く入っているとき、頭の中には複雑なモデルが保持されています – 変数の状態、関数呼び出しチェーン、修正中のシステム全体の形、特定の順序で実行する必要がある変更のシーケンス。Slackはまったく異なる認知モードで動作します: 社会的コンテキスト、会話のスレッディング、誰が何について話しているか、それが自分に関係があるかどうかを把握すること。この2つのモードを切り替えることは、タブを切り替えるようなものではありません。まったく異なる2種類の思考を切り替えるようなもので、あなたの脳にはそのどちらにも「状態保存」ボタンがありません。
不確実性という税金。 集中力を実際に殺すのはこれです: 中断そのものではなく、中断の可能性です。通知バッジが表示されたとき、確認するまでそれが重要かどうかわかりません。その不確実性はワーキングメモリに未解決の問題として入り込み、切り替えに抵抗しても注意を蝕みます。私自身、コミットメッセージを書きながらバッジが視野の端に見えただけで⌘+TabでSlackに切り替えていたことがあります。コミットメッセージはデッドコードの削除についてでした。Slackの通知は誰かがgifにgifでリアクションしているものでした。生産的な午後でした。
スレッドの罠。 Slackを開き、通知を見て、スレッドをクリックし、3つのメッセージを読み、自分の入力が不要だと気づき、戻り、別のチャンネルにバッジがあるのを見て、そちらも確認する – そうすると5分が蒸発し、移行ロジックは遠い記憶となっています。皮肉なことに、ノイズを減らすために設計されたSlackのスレッドモデルは、「バッジを見た」から「自分には関係ないと確認した」までのクリック数を増やしています。スレッドの中にスレッド。亀は果てしなく続きます。
SlackとコードのコンテキストスイッチのコストはSlackで過ごした数秒ではありません。根本的に異なる2つの思考モードを切り替える認知的オーバーヘッドと、通知が中断する価値があったかどうかわからない不確実性が重なった結果です。
実際に何が役立つか（そして役立たないか）
標準的なアドバイスのほとんどを試しました – 「ブログ記事を読んでうなずいた」程度ではなく、真剣に試しました。自分自身の中断パターンを約6か月積極的に観察した結果です。
効果があること
- Slackチェック時間の設定。 Deep Workの日には、朝9時、正午、午後3時にSlackをチェックし、その間はアプリを完全に閉じる（最小化ではなく、閉じる）。切り替え回数が20代から1桁に減ります。集中する日にDockのアイコンを完全に非表示にするのは馬鹿げていますが、効果的です。
- キーワード例外付きDND。 特定のキーワードを含むメッセージや特定の人物からのメッセージを通過させるように設定したSlackのおやすみモード。ノイズからの静寂、真の緊急時のアラート。完璧ではありませんが、二択よりはましです。
- 送信メッセージのバッチ処理。 Slackメッセージをメモ帳に書き留め、まとめて送信する。チームの他のメンバーへの中断を減らし、「あ、さっきのメッセージは無視して」というフォローアップをなくします。
合理的に聞こえるが、現実には機能しないこと
- 「通知をオフにするだけ」。 フロー状態を美しく守れます。しかし、あなたが現在実装しているAPIコントラクトをチームが変更しているスレッドを見逃すことになります。治療が独自の病気を生み出します。
- 「ステータスをビジー中に設定する」。 人々はステータスを無視します。全員が常にビジー中だと主張しているため、ステータスは実質的な情報を持ちません – 「元気?」/「まあね」という職場版です。
システムレベルでのフィルタリング
スケジュール窓のアプローチは機能しますが、それは規律によるソリューションです – そして規律によるソリューションには賞味期限があります。3週間維持した後、何か緊急のことがパターンを崩し、またバッジが動くたびにSlackをチェックするようになります。このサイクルを十分に経験した後、修正策はより多くの意志力ではなく、より良いフィルターだとわかりました。
システムレベルでコンテキストスイッチの問題を実際に解決するには、あなたが何に取り組んでいるかと、Slackで何が起きているかの両方を理解し、「あなたが書いているコードに直接影響する決定がスレッドにある」と「誰かが#randomでランチオプションを議論している」の違いを伝えられる何かが必要です。
それがSugarbugで構築していることです。Slack（およびGitHub、Linear、Figmaなど）に接続し、すべてのシグナルをタイプ別に分類します – 決定、ブロッカー、質問、ステータス更新、ノイズ – そして関連するタスクと人物にリンクします。Slackを開かずに、現在のタスクに関連するSlackのアクティビティが何かがわかります。バッジなし。不確実性という税金なし。通知が自分に関係なかったことを発見するための5分間のスレッド探索なし。
先週の具体的な例: ベクター検索の移行に深く取り組んでいたとき、チームメートが今後使用する埋め込みモデルについての決定をSlackスレッドで行いました。フィルタリングなしでは、完全に見逃す（DNDモード）か、手動でスレッドをスキャンして何時間も後に偶然見つけることになっていました。Sugarbugのクラシファイアーが「決定 – 現在のタスクに関連」というシグナルとして浮上させました。一瞥して、移行作業に戻りました。
これを完璧には解決できていません – クラシファイアーはまだエッジケースを見逃しますし、また別の通知面を作ることなくフィルタリングされたシグナルをどう提示するかをイテレーションしています（それは見事に皮肉なオウンゴールになるでしょう）。しかし、不完全なフィルタリングでも、「全通知」か「通知なし」かという二択よりはましです。その移行の日、少なくとも20回のSlack訪問が不要だったと推定しています – 適切なフィルターがあれば完全に防げた、20回のコンテキスト再読み込みです。
バッジが表示されるたびにコンテキスト税を払うのをやめましょう。Sugarbugは現在の作業に実際に影響するSlackのシグナルだけを浮上させます。
Q: Slackとコードのコンテキストスイッチのコストはどのくらいですか? A: UCアーバイン校のグロリア・マーク氏の研究では、中断後に元のタスクに戻るまで約23分かかることが判明していますが、実際のコストは何をしていたかの複雑さによって大きく異なります。エンジニアがSlackとIDEを1日に何十回も切り替える場合、毎週何時間もの失われたDeep Workが積み重なります – そして苦労して構築したメンタルモデルがその往復で無傷のまま残ることはほとんどありません。
Q: SugarbugはSlackとコードのコンテキストスイッチを減らすのに役立ちますか? A: 役立ちます。Sugarbugは何か注意が必要かどうかを確認するためにSlackに切り替える代わりに、Slackメッセージをタイプ別に分類し、取り組んでいるタスクにリンクします。現在の作業に関連する決定、ブロッカー、質問が、わざわざ探しに行かなくても浮上します。目標は「念のため確認」する切り替えを排除することです – Slackを開いて何もアクションできるものがなく、3分かけて何をしていたか思い出すような切り替えです。
Q: コンテキストスイッチを減らすためにSlackの通知をオフにするべきですか? A: ミュートはフロー状態を守りますが、実際に重要なことを見逃すことになります – あなたが実装しているAPIをチームが変更を決定するスレッドなど。より良いアプローチはフィルタリングです: 今すぐ注意が必要なシグナルと待てるノイズを区別することです。スケジュールされたSlack窓はこの手動バージョンで、Sugarbugは自動バージョンです。
Q: コンテキストスイッチとマルチタスクの違いは何ですか? A: マルチタスクは2つのことを同時にやろうとすること（人間はこれが本当に苦手）。コンテキストスイッチはタスクを順番に切り替えること – コストはコードのメンタルモデルを再読み込みする時間と認知エネルギーです。複雑なシステムを頭に保持しているエンジニアにとって、その再読み込みは作業の深さによって数秒から30分まで異なります。
Q: SugarbugはどのSlackメッセージが中断する価値があるかフィルタリングできますか? A: Sugarbugはシグナルをタイプ別に分類し、取り組んでいるタスクにリンクします。そのため、Slackを開いてすべてのチャンネルをスキャンする代わりに、現在の作業に関連するアクティビティがひと目でわかります。まだ関連性スコアリングをイテレーションしています（完璧ではありません）が、DNDモードの全か無かアプローチよりは意味のある改善です。
---
SlackとIDEの往復がDeep Workの時間を枯渇させているなら – そして、通知バッジを避けるためにDockアイコンを非表示にすることが合理的な生産性戦略に聞こえるなら – それがSugarbugが削減するために構築したコストです。ウェイトリストに参加する。