はじめに：「今日、一行もコード書いてない」

ある日の私の業務ログを見てください。

09:00 - コーディング開始（機能Aの実装）
09:12 - Slackで「ちょっと質問いいですか？」→ 対応
09:35 - コーディング再開…えっと、どこまで書いたっけ
09:50 - やっとロジックを思い出す
09:55 - 「〇〇さん、MTG始まりますよ」→ 30分の定例会議
10:30 - コーディング再開…あれ、変数名なんだっけ
10:45 - ようやくエディタに集中
10:48 - 「緊急です！本番でエラーが！」→ 障害対応
12:00 - 昼休み

午前中、機能Aの実装に費やせた「本当の集中時間」は、合計で 約20分 です。
デスクに座っていた3時間のうち、たった20分。
「1日中忙しかったのに、1行もコードが進んでいない」。この絶望を味わったことのあるエンジニアは、きっと私だけではないはずです。（絶対に）
この現象には、科学的な名前がついていました。「コンテキストスイッチ・コスト」 です。

技術解説：割り込みが脳にもたらす「見えない負債」

23分ルール（カリフォルニア大学アーバイン校の研究）

「割り込みによって中断された後、元のタスクに深く集中した状態に戻るまでに平均23分15秒かかる」
（Gloria Mark, University of California, Irvine）

カリフォルニア大学アーバイン校のGloria Mark教授の研究によると、人間の脳は一度タスクを中断されると、元のタスクの「思考のコンテキスト（文脈）」を再構築するのに膨大な時間を要します。
つまり、12分間コーディングに集中していた私がSlackに対応した瞬間、「機能Aのロジック、変数の状態、次に書こうとしていた条件分岐」といった脳内のワーキングメモリが揮発（消失） し、再ロードに23分かかるのです。（人間って脆いよね、、）

ワインバーグの「同時進行プロジェクト数」とオーバーヘッド

同時進行プロジェクト数  │ 1つのプロジェクトに使える時間
─────────────────────┼──────────────────────
  1つ                 │ 100%
  2つ                 │ 各40%（20%がスイッチコスト）
  3つ                 │ 各20%（40%がスイッチコスト）
  5つ                 │ 各5%（75%がスイッチコスト！）

（G.M.ワインバーグ『Quality Software Management, Vol.1: Systems Thinking』）
ワインバーグの試算によると、5つのプロジェクトを同時進行した場合、業務時間の75%がコンテキストスイッチのオーバーヘッドに消え、実際に価値を生む作業は各プロジェクトたった5%しか残りません。
あの「1日中忙しかったのに何も進んでいない」感覚は、気のせいではなく数学的に証明された生産性の崩壊だったのです。

集中力を守る「防衛線」の引き方

では、この恐ろしいコンテキストスイッチに、私たちはどう立ち向かえばいいのでしょうか。
1. 「集中タイム」をカレンダーに予約する
毎日2〜3時間、Slackの通知を切り、MTGを入れない「聖域」をカレンダー上にブロックします。チームに「この時間帯は緊急以外レスしません」と宣言しておくのがポイントです。
2. 割り込みを「バッチ処理」する
Slackの質問にリアルタイムで反応するのをやめ、**「11時と15時にまとめて返信する」**というルールを設ける。質問する側も、急ぎでなければその時間まで待つ習慣がつきます。
3. 「割り込みログ」をつけて可視化する
1週間、割り込みが発生するたびに「時刻、内容、復帰までの大体の時間」を記録してみてください。

09:12 | Slackで質問対応 | 復帰まで23分
09:55 | 定例MTG         | 復帰まで15分
10:48 | 障害対応         | 復帰まで40分
→ 午前中の "失われた時間" 合計：78分（！）

このログを上司に見せて「集中時間の確保」を交渉する。感情論ではなく、科学的データに基づいた防衛交渉です。
「ちょっといい？」は、善意の質問です。しかし、その善意の一言が、エンジニアの脳内に構築された繊細なロジックの城を23分かけて吹き飛ばしていることを、チーム全員が知っておくべきなのです。チームのコミュニケーションも大事ですが、集中という観点から見ると無駄なMTGなどは無くすべきというのが良くわかりますね。