ハクソク

世界を動かす技術を、日本語で。

中断された作業のコスト (2023)

2025年8月24日原文(blog.oberien.de)

概要

  • 23分15秒 の中断回復時間は広く引用されているが、 一次資料が不明確 な点
  • 主要論文 ではこの具体的な時間は明記されていない事実
  • 多くの ブログや記事 が誤った参照や伝聞を元にしている現状
  • Gloria Mark のインタビューでのみこの数字が言及されている
  • 確かな根拠 を求める場合は注意が必要な情報であること

「23分15秒で集中力が戻る」説の出典検証

  • 「23分15秒」 という数字は多くのブログや記事で 中断後の回復時間 として引用
  • 簡単な参照 を試みたが、 一次資料の特定が困難 という問題
  • The Cost of Interrupted Work: More Speed and Stress （Gloria Markら著）の論文が最もよく引用される
    • この論文では 中断がある方がタスク自体の所要時間が短い （20.31分・20.60分 vs. 22.77分）と報告
    • 23分や回復時間についての記述は一切なし
  • 関連論文 も調査
    • A Diary Study of Task Switching and Interruptions ： 回復時間の記載なし、週平均50回のタスク切替のみ
    • Disruption and Recovery of Computing Tasks ： 11～16分 の中断解決時間を報告、ただし回復時間の詳細分析はなし
    • If Not Now, When? ： Resumption Lag （再開遅延）の値を収集と記載あるが、 具体値は未提示
    • No Task Left Behind? ： 回復時間の記載なし、同日中にタスクが再開される確率に注目

ブログ・記事の引用状況

  • 23本のブログ・記事 を調査
    • 9本 が誤って論文を参照
      • うち1本は 論文に存在しない引用文 を掲載
    • 2本 は論文の 本来の結果 を正確に引用
    • 9本 が Gloria Markのインタビュー （3件）を直接・間接的に引用
    • 2本 が Wall Street Journal の Gloria Mark発言 を引用

結論：数字の出典と注意点

  • 23分15秒 という数字は Gloria Markのインタビューや記事 で繰り返し言及
  • 一次資料（論文や正式な研究報告）でこの数字を裏付けるものは発見できず
  • Gloria Mark の他の論文にもこの数字は見当たらず
  • 根拠を求める場合は、インタビュー発言が唯一の出典 となるため、 利用時は注意が必要

参考リンク集

  • Dev Interrupted: https://devinterrupted.substack.com/p/3-proven-ways-to-improve-dev-focus
  • Loom: https://www.loom.com/blog/cost-of-context-switching
  • Paladinic: https://www.paladininc.com/blog/detail/6299/dealing-with-work-interruptions
  • Lifehacker: https://lifehacker.com/how-long-it-takes-to-get-back-on-track-after-a-distract-1720708353
  • The Muse: https://www.themuse.com/advice/this-is-nuts-it-takes-nearly-30-minutes-to-refocus-after-you-get-distracted
  • Fast Company: https://www.fastcompany.com/944128/worker-interrupted-cost-task-switching
  • idonethis: https://blog.idonethis.com/distractions-at-work/
  • idea to value: https://www.ideatovalue.com/curi/nickskillicorn/2023/07/it-takes-23-minutes-to-regain-focus-after-a-distraction-task-switching/
  • LeadDev: https://leaddev.com/process/managing-chaos-context-switching
  • getabstract: https://journal.getabstract.com/en/2022/03/17/twenty-three-minutes/
  • gallup: https://news.gallup.com/businessjournal/23146/too-many-interruptions-work.aspx
  • JournalStar: https://eu.pjstar.com/story/news/2013/01/25/frequent-emails-phone-call-interruptions/42450766007/
  • togglblog: https://toggl.com/blog/how-to-get-back-on-track-when-you-get-distracted-at-work
  • Presentation by Gloria Mark: https://slideplayer.com/slide/1409624/
  • Productivityjunkie: https://www.linkedin.com/pulse/productivityjunkie-23-minutes-15-seconds-mystery-sugar-inga-bieli%C5%84ska
  • Bright Developers: https://www.brightdevelopers.com/the-cost-of-interruption-for-software-developers/
  • Wall Street Journal: https://www.wsj.com/articles/SB10001424127887324339204578173252223022388
  • Ironistic: https://www.linkedin.com/pulse/cost-distractions-developers-ironistic-com
  • Jazz Hanley: https://www.linkedin.com/pulse/reclaim-23-minutes-you-lose-every-time-youre-work-jazz-hanley
  • devmio: https://devm.io/careers/aaaand-gone-true-cost-interruptions-128741
  • Stephanie C. Mitchell: https://www.stephaniecmitchell.com/articles/whats-distracting-you-from-writing
  • devbizops: https://devbizops.medium.com/getting-into-the-developer-flow-state-7b0e5c98eb8a
  • Hardvard Business Review: https://hbr.org/2014/04/help-your-employees-find-flow

Hackerたちの意見

ある日は、ちょっとした中断で考えが途切れちゃって、残りの6時間は捨てられた瓶やレールの枕木を集めることに費やしちゃう。どこかで、何かの役に立つかもしれないと思って。別の日は、中断があってもほとんど影響がないこともあるんだよね。どの日になるかを見極めるのが難しくて、Slackにログインしない方がいいのかなって考えたりもする。

└

同じ気持ちだよ :)

└

平均は23分15秒ってことだよね？

└

まさにその通り。そんな日があると、デスクから離れた方が逆に仕事が進むことに気づいたよ。森を散歩したり、家事をしたりすると、すごくリフレッシュできる。もちろん、時には「今日は仕事する日じゃないな」って認めて、リラックスするのが一番いい時もある。そうすると、次の日はすごく生産的な日になることが多いし、みんなハッピー。

└

中断コストを最小限に抑える方法を見つけたんだ。それはペアプログラミング。あるスタートアップでは、毎日一日中ペアプログラミングをしてた。中断からの再開がほとんどシームレスだったよ。説明できないけど、体験しただけなんだ。

└

年を取るにつれて、元の軌道に戻るのに時間がかかる気がする。頭が悪くなったわけじゃないと思うけど、経験がそれを補ってるのかも。多分、間違った方向に進むことは少なくなったけど、中断を防ぐためにもっと厳格にならないといけない。

└

私にとっての違いは、タスクを事前に計画していたかどうかだ。午前10時から11時までに何に集中して達成したいかを知っていると、元の軌道に戻るのがずっと楽になる。逆に、何かを始めるだけだと、外部からの中断がなくても簡単に別のところに行ってしまう。

└

私にとっては、中断の性質が重要だと思う。記憶から何かを引っ張り出すだけの簡単な質問は、あまりコストがかからない。でも、考える必要がある質問は大きなコストがかかるし、コードやドキュメントを確認しなきゃいけないときはさらに大変。時には、メールやTeamsの通知を読むだけでも気が散ることがある。インタラクション（誰かがデスクに来るとか、電話とか）ではなく、トピックが問題なんだ。ただ、どちらの場合でも、コーディング中に中断が起こると、バグのリスクはほぼ同じだと思う。

└

前の晩にどれだけ寝たかと、先週飲んだコーヒーの量には、正の相関があることに気づいたよ。逆に、コーヒーの量は負の相関があるね。

└

いくつかのタスクは、頭の中にたくさんのコンテキストを保持する必要があるかもしれない。中断されると、そのコンテキストがクリアされて、また再構築しなきゃいけないんだ。もしくは、単に疲れてるのかもね。少しの睡眠不足で、どれだけ非効率になるかって、本当に驚きだよ。

個人的には、思考プロセスの新しさが回復に大きく影響するって結論に至ったよ。要するに、ちょっと変わった道を通って結論に至ると、中断後に戻るのがすごく難しくなるんだ。

これは科学報道全般にありがちな問題だよね。ニュースが論文に書いてないことを言ったり、論文のデータとは真逆のことを言ったりすることが多い。引用された研究を記事から見つけられないこともよくあるし、たまには著者の責任でデータに裏付けられてないことを言っちゃうこともあるけど、科学報道の人たちがこういうことをよくやるんだ。私の基本的なルールは、少なくとも論文の要約や方法、グラフやデータを見てみること。5分もあれば、ポップサイエンスの記事よりもずっと情報が得られるし、読むほどに楽になるよ。中断は復帰に影響するけど、結構バラつきがあると思う。厳密なTDDをやっているときは、中断からの回復がうまくいくんだ。でも、デザインについて考えたり、複雑なアルゴリズムのパフォーマンス分析をしていると、頭の中で進んでいるから、戻るのに時間がかかる。これって測定可能だと思うし、プログラミングタスクにかかる時間を実験で見てみるのも面白いかも。

Hacker Newsで議論の続きを見る