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

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

概要

  • 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 Tasks11~16分 の中断解決時間を報告、ただし回復時間の詳細分析はなし
    • If Not Now, When?Resumption Lag (再開遅延)の値を収集と記載あるが、 具体値は未提示
    • No Task Left Behind?回復時間の記載なし、同日中にタスクが再開される確率に注目

ブログ・記事の引用状況

  • 23本のブログ・記事 を調査
    • 9本 が誤って論文を参照
      • うち1本は 論文に存在しない引用文 を掲載
    • 2本 は論文の 本来の結果 を正確に引用
    • 9本Gloria Markのインタビュー (3件)を直接・間接的に引用
    • 2本Wall Street JournalGloria 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をやっているときは、中断からの回復がうまくいくんだ。でも、デザインについて考えたり、複雑なアルゴリズムのパフォーマンス分析をしていると、頭の中で進んでいるから、戻るのに時間がかかる。これって測定可能だと思うし、プログラミングタスクにかかる時間を実験で見てみるのも面白いかも。

中断が予想される職場で働くときは、仕事のやり方を変えるよ。観察者から見たら、時間をあまり失ってないように見えるかもしれないけど、それは中断に慣れていく結果として、他の仕事に分散されてるだけなんだ。まだそこにあるけど、もっと広がってる感じ。

これは科学報道全般にありがちな問題だよね。ニュースが論文に書いてないことを言ったり、論文のデータとは真逆のことを言ったりすることが多い。もしかしたら、LLMの幻覚の一部は、こういう報道を受けて(誤って)高品質なトレーニングデータとしてタグ付けされることで説明できるかもしれないね。

これは科学報道全般において本当に一般的な問題だね。これには実際にかなり悪い面がある。ニュース記事を書いてる人たちは、ちょっとした白い嘘や「まあまあ近い」って感じで流してるんだろうね。ある意味、そういうのには真実があるけど、問題はこれらの「小さな誤り」から生じるもっと大きな問題にある。1) 確かに、これが科学への不信感を大きく助長してる。人々はニュースから科学を得ていて、直接の情報源からではない。もし「科学者が言ってる」って言いながらおかしなことを報道したら、人々は科学者を責めることが多い。結局、科学者はわかりやすい英語で書いてるわけじゃないからね。チョコレートが健康に良いとか、赤肉が癌を引き起こすとか、機械学習の量子ブラックホールとか。これらには常に真実の要素があるけど、真実はセンセーショナルではない。真実と複雑さは表裏一体だよ。複雑さが減ると、正確さを犠牲にしなきゃいけなくなる。このバランスを取るのは難しい。2) 一般の人はあまり科学的リテラシーがなく、意味を誤解しやすい。実際、科学者ですらこの手のことに苦労することが多い。赤肉の問題を例に取ると、確かにそうだけど、そういう研究の多くは50gや100gの毎日の摂取量を見ていて、「直腸癌のリスクが25%高い」という結果が出てる。参考までに、コストコのホットドッグは110g、ネイサンズのホットドッグは48g。つまり、1日1〜2本のホットドッグの話をしてるんだ。リスクの増加率についての話で、リスクのパーセンテージではない。CDCのサイトによると、男性と女性の約3.9%が大腸癌と診断される。これが基準なら、25%の増加は4.9%のリスクになる。4%の癌リスクから5%に移行するには、かなりの量のホットドッグが必要だよ。国全体で見ると気になるけど、個人レベルではそうでもない。これが#1に戻るけど、人々はニュースを「ホットドッグを食べると癌になりやすい」と解釈してしまう。一方で、周りのホットドッグをたくさん食べてる人が癌になっていないのを見ている。彼らの観察は研究の結果に反するわけではないけど、ニュースのストーリーには反する。観察と理解の不一致が不信感を正当化する。でも、何かを誤解する方法は、正しく解釈する方法よりも多いんだ([2]に関連)。この失敗のパターンは自己強化的になる。インターネットを使う人なら誰でも気づくと思う。(コミュニケーションは本当に難しいし、正確にコミュニケーションするのはさらに難しい)3) (おそらく最悪の部分)科学者は主に引用数(カウントや「h-index」)で評価される。画期的なことをしない限り(これは稀)これがパフォーマンスを「測る」主な方法になる。引用数を増やすための良い方法はメディアの注目を集めること。残念ながら、たくさんの論文が発表されていて、引用数の主な要因は論文の存在を知っていること。小さな数字の話をしているときに、アビ・ローブのようなタイプである必要はない(でも、そういうのは役に立つ)。カリフォルニア州立大学の大学院生とMITの大学院生が同じ論文を発表した場合、後者の方がより多くの引用を得ることが期待される。MITにはメディア部門があって、これらの論文は大きなニュース組織に取り上げられやすい。だから、多くの科学者がTwitterのようなプラットフォームを使うんだ。引用が十分に得られないと、自分の仕事が何の意味も持たなくなるから。ここには明らかなスリッパリースロープがある... これは誤報のフィードバックループを生む可能性がある。競争が激しくなるほど、この状況はリスクが高くなる。自分の仕事を少し誇張するのはすごく簡単だ。出版時には誰もチェックしていない。再現は後で行われ、システムは再現を軽視する。さらに、再現する際には、論文に間違いがあったのではなく、自分が間違えたと仮定する方がずっと簡単だ。これを言いたいのは、状況は複雑だってこと。誰か一人のせいではないと思う。むしろ、複合的な影響によって生じた現象だ。ちょっとしたことが積み重なって、何百万の出来事と何年も経つと大きくなる。みんなシンプルなものを求めているのはわかるし、シンプルさには多くの利点があるけど、それは大きな罠にもなる。「できるだけシンプルに、でもそれ以上はダメ」というのは、何かが非常に複雑でないことを意味するわけではない。これは、人々がウィキペディアの数行を読んで理解できると思わせる罠なんだ(全記事を読むべきだけど、それでも足りない)。複雑さが増す世界に対して、影響が大きくなる罠だね。[0] そして、彼らがそうすべきだとは思わない。論文はピア・ツー・ピアのコミュニケーションネットワークだ。オープンで可視的だけど、それがピア・ツー・ピアのコミュニケーションの仕方なんだ。専門家から一般の人へのコミュニケーションは、伝統的にニュースや他の科学コミュニケーターを通じて行われてきた。科学者に一般の人向けに論文を書くように頼むのは、同僚にコードについて何も知らないかのように説明するように頼むようなもので、全く仕事が進まないよ... [1] ニュース組織や科学コミュニケーター(特にポップサイコミュニケーター... うんざり...)がここで害を及ぼしているけど、誰でも取れる防御策もある。自分の理解は常に何らかの程度で間違っていることを認識すること。情報を二元的な真偽の声明として受け取らず、確率として捉えること:例えば、たぶん真実、たぶん真実かも、たぶん偽、たぶん偽かも。根本的に、これが良い防御になる理由は、常により正確な解釈だから。科学者は確認を通じて真実を見つけるのではなく、否定を通じて見つける。つまり、彼らは物事を排除していく。科学者は真実に近づくんだ。[2] [2] これも、科学者と詐欺師を見分けるのに役立つ。科学者は常に何らかの疑念を持っている。最初は自信満々に見えるかもしれないけど、詳細を詰めていくうちに言葉が弱くなっていく。これは完全ではないし、すべての質問に通用するわけではないけど、よくあることだ。科学者はメディアリテラシーについてより多くの訓練を受けている。これは、同僚に話すには正しい方法だけど、一般の人には専門知識がないように感じさせるから。最良のサインは、彼らに自分の専門分野について話させることだ。彼らは止まらず、非常に詳細に話し始める。 [3] N回以上引用された論文の数。h-indexが10というのは、10回以上引用された論文が10本あることを意味する。h-indexが100というのは、100回以上引用された論文が100本あることを意味する。 [4] 画期的なことをすれば、引用数なんて誰も気にしない。でも、画期的なことをすれば、引用数は確実に急増する(多くの場合、h-indexも上がる。なぜなら、注目を集めて、他の人があなたの他の作品を読むから。あなたの作品自体は変わらないけど、可視性が変わる)。この事実は、引用メトリクスの使用を正当化するためにしばしば使われる。引用メトリクスは良いけど、簡単にハックできて、文脈に依存する。アビ・ローブのことを挙げるけど、論争はこのメトリクスにとって有益だ。彼を間違っていると言う論文は、彼にとってのポイントになる。論争は、まったく新しいソースからポイントを集める方法なんだ!あなたの仕事を基にしている人たちではなく、あなたの仕事に対抗する人たちから。 [5] 「もしシンプルに説明できないなら、あなたはそれを十分に理解していない」というのは笑えるフレーズだ。なぜ「バーテンダー」に量子色力学を教えられないのかというと、理解していないからではない。シンプルに説明できないのは、理解していないからだ。色という言葉を使うことすらできないのに、レベルで「赤」が存在することは不可能だと考えられる(そのスケールで「赤」が存在することが不可能だということにすら触

会議による中断の予測があると、逆に悪化する気がする。結局、両端で30分くらい失っちゃうんだよね。

これが俺の一日を台無しにするんだよね。他の同僚からの中断は大体話の内容に関係してるし、手助けするのはいつも楽しい。

最後の最後に会議の予定を変更されるのが本当に嫌だ。30分しかない感じで、深いことに手をつけられなかった。ほんと無駄だよね。

そうだね。私にとって、会議は半日を失うようなもんだ。

元の情報源は2006年のギャラップのインタビューで、研究者のグロリア・マークが話してるやつだよ。ここで読めるよ: https://news.gallup.com/businessjournal/23146/too-many-inter... > GMJ: 中断の後、仕事に戻るのにどれくらい時間がかかるの? > マーク: 良いニュースと悪いニュースがあります。同じ日に中断されて再開された全ての仕事を比較した結果、良いニュースは大半の中断された仕事が同じ日に再開されたことです。81.9%で、平均して23分15秒で再開されました。まあ、そんなに長くはないと思います。

悪いニュースは何だったの?

私はこの記事を、23分は元のタスクに戻るために使われるのではなく、中断自体や元のタスクに戻る前に取り組む他のタスクに使われるということだと解釈してる。この解釈が正しければ、その23分は混乱で無駄にされるのではなく、単に他のことに使われているってことだよね。私の読み方は合ってる?

残念ながら、それは元のソースじゃないよ。この作品の著者、Jaro Fietz(別名oberien)は、その記事にすでに詳しくて、図の中で言及して、ページの下の方にリンクも貼ってるんだ。彼らは、引用ではなく、その基礎研究を探しているみたいだね。 > 結局、23分15秒はどこから来たの? グロリア・マークがインタビューで何度も言及してるけど、元の印刷されたソースは見つけられなかったよ。グロリア・マークの出版物は他にもたくさんあるけど、23分15秒の数字を探しても見つからなかった。もしその数字が最初に出てくる論文や研究を知ってる人がいたら、教えてほしいな。

もし実際に23分で、しかも変更できないなら、重要な職業の多くが完全に成り立たなくなるだろう(例えば、医療とか)。つまり、中断の影響を一つの数字で意味のある形でまとめるのは難しいと思う。

それとも、そのタスクはどんどん優先度が下がっていったのかもね。

俺はずっと、それが平均だと思ってたんだよね。つまり、ある人には5秒、別の人には2時間かかるってこと。まあ、実際の引用は具体的じゃないけど、そんなのはすごく無茶で簡単に無視される主張だよね。

逆に、私は中断可能でいることで、同僚を助けることが自分がどれだけ価値を加えているかをよく考える。自分が失う時間以上に、彼が得られる時間を考えると、会社にとってもいいことだよね。

これは確かに重要なポイントだね。でも、中断がストレスの経験を増加させて、結果的に有害な職場環境に寄与するっていう側面もあるよね。

会社には良いことだね。Cレベルじゃない限り、その考えは頭に浮かぶべきじゃないよ。自分のことを大事にしてね。

マネージャーとして、面倒な中断の多くは「ハッスルが足りない」と言うことに起因してると思う。ああ、私の仕事は主に開発者に戦略的な方向性や優先順位を与えることだと思ってるけど、彼らが仕事を進めるための障害を取り除くことでもある。後者に関しては、私が受ける中断は、自分で考えてやろうとしない人たちから来ることが多い。データベースにアクセスが必要なら、インフラサポートに聞いてみて。誰がこのAPIクライアントを書いたか分からないなら、gitで探してみて。こういうことを自分で調べようとしない人が多いんだよね。

イラストはこちら: https://www.reddit.com/r/ProgrammerHumor/comments/2rmir6/why... (これがxkcdにあると思って、しばらく探してたんだけど、やっと見つけたよ)

それってxkcdにあるの?