- 認知心理学の研究によれば、人間のディープワーク（deep work）の限界は1日3〜4時間であり、それ以降は集中力とコード品質が急激に低下する
- 25万人以上の開発者を分析した結果、実際のコーディング時間の中央値は1日52分にすぎず、残りは会議・管理・協業に費やされている
- 一度中断されると元の作業に戻るまで23分、プログラマーの場合は全体のコンテキスト復元に30〜45分かかる
- **フロー状態（flow state）**では生産性が500%向上するが、入るまでに15〜25分の連続した集中時間が必要
- エンジニアリングマネージャーの役割はプロセスを増やすことではなく、妨害要因の除去とディープワーク時間の保護に集中すべき
認知的限界：ディープワークの上限は1日4時間
- Cal Newportはディープワークを「妨害のない集中状態で認知能力の限界まで押し広げる専門的活動」と定義しており、多くの人にとって1日平均4時間が最大値
- K. Anders Ericssonのバイオリニスト研究でも、4時間の集中練習の後に疲労が訪れることが確認されている
- ソフトウェア開発も創造的な問題解決やシステム設計を含む高強度の認知作業であるため、3〜4時間を超えると収穫逓減が起こる
- 数学者Henri Poincaréは午前2時間・午後2時間、G.H. Hardyは午前のみ、Charles Darwin、B.F. Skinner、C.S. Lewisも3〜4時間の作業スケジュールを維持していた
- UC IrvineのGloria Markの研究によれば、現在の平均画面集中時間は47秒で、2004年の2.5分から大幅に減少している
開発者の実際の時間の使われ方
- Software.comによる25万人以上の開発者分析の結果、コーディング時間の中央値は1日52分（週あたり約4時間21分）
- 1日2時間以上コーディングする開発者はわずか10%、1時間以上でも40%
- Clockwiseの150万件の会議分析によれば、ソフトウェアエンジニアの週あたりの会議時間は平均10.9時間
- エンジニアリングマネージャーは週18時間を会議に費やしており、40時間勤務のほぼ半分
- 大規模組織の開発者は週12.2時間、小規模組織では9.7時間を会議に消費
- 会議・管理・コードレビュー・協業を除くと、週あたりの集中可能時間は19.6時間で、その大半は使いにくい短い断片時間
- 全コーディングの45%が午後2時〜5時の間に行われており、午前9時〜11時はわずか10%
- これは開発者が本来夜型だからではなく、朝がスタンドアップ・同期・セレモニーに侵食されているため
中断の高いコスト
- Gloria Markの研究によれば、中断後に元の作業へ完全に復帰するまで正確に23分15秒かかる
- Georgia Institute of Technologyの研究では、プログラマーの場合、コード編集の再開まで10〜15分、全体のメンタルコンテキスト再構築には30〜45分を要する
- Paul Grahamの「メイカーズ・スケジュール」エッセイ：会議は単なる作業切り替えではなく、作業モードそのものを変えてしまう例外（exception）
- 1つの会議が午後全体を壊しかねず、午後に会議が予定されているだけで、午前中に野心的な作業を始めるのをためらわせる
フロー状態：プログラマーの生産性を増幅するもの
- Mihaly Csikszentmihalyiの研究では、フロー状態を「活動そのものに完全に没入し、自我が消え、時間感覚を失う状態」と定義
- 10年間の研究の結果、フロー状態では通常時と比べて生産性が500%向上することが確認されている
- フローに入る鍵は挑戦とスキル水準のバランスであり、挑戦が高すぎても低すぎてもフローを妨げる
- ソフトウェアチームでは、フローを頻繁に経験するチームほど、より大きな価値をより速く、より高い満足度で届ける
- フローは自然発生するものではなく、それを消耗させる要因から守ることが不可欠
コーディング中にフローへ入る方法
- 妨害のない環境を作る: Slackを閉じる、通知をミュートする、ディープワークモードを示す視覚的ステータス表示を使う
- 通知に応答しなくても、通知を見るだけで集中力は低下する
- コーディングセッション前に明確な目標を設定する: 「バックエンド作業」ではなく、「認証エンドポイントが適切なエラーレスポンスを返すよう修正する」のように具体的に定義する
- 認知のピーク時間に難しい問題を解く: 概日リズム研究によれば、認知パフォーマンスは時間帯によって9〜40%変動する
- 多くの成人では午前10時〜午後2時が最も問題解決能力の高い時間帯
- 朝型（「ヒバリ型」）と夜型（「フクロウ型」）ではピーク時間が異なるため、個人ごとのピーク時間を守る必要がある
- メイカーズ・スケジュール向けのタイムブロッキング: カレンダーで2〜4時間のディープワークブロックを先に確保し、会議は1日の終わりか特定の曜日に集中配置する
- 各作業ブロックには1つの目標を設定し、実行可能な3つのタスクに分解する
- コンテキストスイッチをなくす: 即時応答の代わりに1日2回のコミュニケーションウィンドウを設け、現在の作業と無関係なブラウザタブを閉じる
- マラソンスプリントではなく集中セッション単位で働く: 25分のポモドーロは複雑な開発作業には不向きで、フローに入りかけたところでタイマーにより中断される
- 目標は最長時間ではなく、認知能力の範囲内での最大品質
- 内省と学習の複利効果: Ericssonの意図的練習研究では、専門性を生み出すのは作業時間ではなく、内省的な思考である
Cal Newportの4つのディープワーク戦略
- 修道院戦略（Monastic）: 浅い作業を完全に排除する
- Donald Knuthが1990年にメールを廃止したのが代表例
- 二分モード戦略（Bimodal）: 週の中でディープワークの日と浅い作業の日を分ける
- リズム戦略（Rhythmic）: 毎日同じ時間にディープワークを行い、例外を作らない
- Jerry Seinfeldの「チェーンを切らさない」アプローチ
- ジャーナリスト戦略（Journalistic）: 空き時間ができるたび即座にディープワークへ入る
- 30〜45分単位でも活用できるが、実際にはコンテキストスイッチをディープワークと勘違いする危険がある
- 多くの開発者にとってはリズム戦略が最も効果的であり、Slackの反応的な誘惑に流されず、朝の時間をコーディングに確保することが重要
エンジニアリングマネージャーが気にすべき理由
- 開発者の1日の実コーディング時間が52分しかない状況では、1回の中断で23分以上の復旧時間を消費するため、1通のメッセージが1日のコーディング割り当てのほぼ半分を使い切ってしまう
- TechSmithの実験: 会議を完全に廃止すると体感生産性が15%向上し、85%の従業員が会議を非同期コミュニケーションに置き換えたいと回答
- Microsoftの31,000人調査では、非効率な会議が職場の生産性を妨げる最大要因
- マネージャー向けの推奨事項:
- 妨害のない午前の時間を確保する
- ノーミーティングデーを導入する（例: 水曜日）
- 同期ではなく非同期コミュニケーションをデフォルトにする
- 創造的な探究の余地を認める現実的な締め切りを設定する
- 効果測定指標: サイクルタイムの短縮、チーム満足度、エンゲージメントスコア、バグ率や手戻り率などの品質メトリクス
結論
- 1日3〜4時間のディーププログラミングは習慣の問題ではなく、認知負荷の物理的限界である
- 通知を切る、午後に返信するとチームへ知らせる、週2回の朝会禁止を交渉するなど、自分で制御可能な要素の最適化が鍵
- 8時間の「半分集中」より、4時間のディープワークのほうが常に良い結果を生む
- 毎日数時間フロー状態に入ることは、高品質なコード、低いバグリスク、革新的なソリューション、そしてワークライフバランスの向上につながる
- コーダーはスプリンターではなく、マラソンランナーであり、エネルギーを温存しなければならない
AIコーディングアシスタントに関する補足
- Copilot、Cursor、Claudeのようなツールはディープワーク時間そのものを延ばすわけではなく、焦点を移すだけ
- コードをゼロから書く代わりにAIの出力をレビューすることも、同じだけのコンテキスト・判断・集中力を必要とする
- 3〜4時間の限界はタイピング速度ではなく、高品質な意思決定を持続できる脳の限界なので、コードが速く出てきても変わらない
- AIが本当に役立つ領域は浅い時間（shallow hours）: 文書ドラフト、ボイラープレート生成、ライブラリの使い方の問い合わせなど
- こうした作業をAIに委任すれば、ディープワークの予算をアーキテクチャ思考や複雑な問題解決のために温存できる
- 落とし穴は、AIを使って精神的に処理できる量を超えるコードを生み出してしまうこと
- 目標は1日により多くのコード行を書くことではなく、限られた認知資源を最も重要な意思決定に集中させること
13件のコメント
比較対象そのものが間違っている。
K. Anders Ericssonのバイオリニスト研究は、熟達者を基準にしたものではなく、練習を基準にした研究だった。楽器の場合、曲を完璧に練習したとしても完璧な演奏が常に保証されるわけではない（毎回の演奏ごとに例外がある）。それに比べて開発の場合は、ニーズが明確で、完成した後は常に同じ結果を出す。終わりのあるものを連続して行うことと、終わりのないものを連続して行うことには非常に大きな違いがある。したがって、人間の認知能力は平均して3〜4時間だと決めつけること自体にも、他人の指示によって3〜4時間開発することと、自発的に3〜4時間開発することの間にまた別の違いが生じる。この文章は、あらゆるものを一般化して、3〜4時間が人間の認知能力の限界であるともっともらしく説得しようとしている文章に感じられる。彼らの集中時間が3〜4時間だからといって、すべての人の集中時間が3〜4時間であるわけではない。むしろ限界を決めてしまって、「じゃあ私たちは3〜4時間だけ働こう」と談合するための文章のように見える。
その通り〜！ 実際に、仕事がとてもできる方は多いですよね
自分のキャリアハイの集中力による成果を基準に、「自分はこういう人間だ」と決めつけないでほしい。この記事はディープワークを理想的な作業状態として置き、そこに入るために過剰に努力しすぎている。もちろん、面白い問題解決のアイデアや試みる方向性が見えるときにはディープワークに入れて、効率も上がる。だが、それが見えないからといって「自分の脳は本当はもっと天才的なはずだ」と信じ、いつも不満を抱えて生きていると、結果的に自分が『フロー』に入れる確率をずっと下げることになる。メタ認知が足りないほど、自分の脳は自分だけのものだと思いやすいが、その脳のコンディションは決して一人で作っているわけではない。その集中力が出るまでに受けた周囲の助け（ただ放っておいてくれたり、お金をくれたりすることだけでなく、さまざまな刺激を受け、それがある瞬間に一つの方向へ精巧に結びつく出来事が起きるのが集中状態だ）を認めるべきだ。結果がどうであれ、心の中では感謝し、相手に表現する必要まではなくても、自分なりに適度な線で満足し、自分を肯定する気持ちが、長期的な集中力とコンディションを高める。
午前に3時間働いて、昼食を取ってから午後に再び3時間勤務する（合計7時間、週4日）会社に通っています。これだけでも、ずっと精神的に楽なんですよね。
良い会社ですね！
みんな、退勤してから誰もいないときに一人でコーディングすると調子がよかった理由が……;;;
だから、ほかの人が残業するときは、むしろ私が早めに退勤します。
訓練と休息、適切な環境でもう少し増やせるとは思いますが、人をすり減らして成り立つやり方なので長く耐えるのは難しいです。会社は無理をさせようと強引に押し進め、口をつぐみますが、薬を飲みながら（うつ病の薬、ADHDの薬）働いている技術者たちも時々見かけます。
そうですね、板橋で精神科が繁盛しているのは居心地の悪い真実ですよね
コーディングは1日1時間で十分だと思います。AI以前でも実際にコーディングする時間はそれほど長くありませんでしたが、今ではさらに短くなりました。
「自分がやりたい」開発やゲーム、読書をするときは、何時間でもその作業が終わるまで集中できるようです。
ここでいう4時間というのは、おそらく「やりたくはないけれど仕事だからやる」ことに対する集中力（受動的な集中力と言うべきでしょうか？）のことではないでしょうか？
単純です。ゲームをしながら徹夜でも集中力を保った経験は、男なら誰にでもあるはずです
個人的な経験では、やりたい開発をしているときは何時間続けてやっても、特に疲れるという感じはありませんでした。
マルチセッションを回すこと自体がマルチタスクになり、集中力を下げることにもなるでしょう。