コンテキストスイッチの生産性への影響とその対策、改善例

この記事は株式会社Gincoのテックブログ兼開発生産性 Advent Calendar 2022の4日目の記事です。

作業に中断が発生し、元の作業状態へ戻るのに時間を要したことは多くの人は経験があるでしょう。

このような事象をコンピュータサイエンスの用語からコンテキストスイッチと呼びます。

生産性を上げるにはコンテキストスイッチを取り除き、やりたいことに注力できる状態を作ることが必要です。

本記事ではコンテキストスイッチの作業への影響やその発生条件、対策、業務改善例について書きます。個人やチームに対し、作業を効率化するために避けるべきこどのように作業を進めればいいかという情報を提供することを目的としています。

要約

良いコンテキストスイッチ、悪いコンテキストスイッチがある
- 悪いコンテキストスイッチ
  - 2 倍の時間がかかり、2 倍のエラーを含む
  - 元の作業状態に戻るまでに少なくとも15分必要
  - ストレス、疲労感の増加
- 良いコンテキストスイッチ
  - 自身が取り組んでいるタスクについて他の人から質問されることで、タスクをより深い理解でき、生産性向上に繋がる
悪いコンテキストスイッチの条件
- 思考や記憶が必要な作業はコンテキストスイッチによる影響が大きい。例えばソフトウェア開発だと設計、プログラミング、UI設計、リリースが該当する
- 割り込み前後のタスクのコンテキストの差が大きいほど影響も大きくなる
  - 最も影響が大きいのはプロジェクトの変更
  - 次点で、優先度の変更(緊急の割り込み)、午後に発生した割り込み、作業フェーズの変更
  - 組み合わせによって影響はより大きくなる
- 自身で発生させるコンテキストスイッチはより影響が大きい
  - ビルドやツールなどの技術的な問題、優先度の誤り、タスクや技術に関する事前情報不足、作業に飽きたなど
悪いコンテキストスイッチへの対策例
- Google CalendarやSlack Statusを利用し、思考や記憶が必要な作業中に割り込みタスクを入れない
- タスクをプロジェクトや種類でグループ化し、まとめて取り組む
- タスクへ取り掛かる前に、必要な情報が揃っているかを確認する
- 自動化/半自動化し、そもそものタスク数を減らすか、省力化する
ぜひ日々の生活や業務の作業効率化に活かしてください

コンテキストスイッチとはなにか

コンテキストスイッチは複数のタスクを進めている作業者が、タスクを切り替える際に、元のタスクを記憶しておき、次のタスク完了後に再度元のタスクを思い出すプロセスを指します。コンピュータサイエンスの用語が語源です。

コンテキストスイッチの悪影響

コンテキストスイッチの影響については多くの研究がされており、生産性と品質に悪影響を与えることが分かっています。

2 倍の時間がかかり、2 倍のエラーを含む

Microsoft Research は Microsoftのソフトウェアエンジニアの業務分析を行いました。分析の結果から、コンテキストスイッチが発生したタスクは、発生していないタスクの 2 倍の時間がかかり、2 倍の確率でミスを含むことが推定されています。[1][2]

元の作業状態に戻るまでに少なくとも15分必要

デルフト工科大学は2つの開発組織の業務分析を行いました。分析の結果から、プログラミングなどの集中力を必要とする作業では、コンテキストスイッチの発生後元の作業状態へ戻るまでに必要な時間は少なくとも15分であることが分かりました。[1][3]

ストレス、疲労感の増加

カリフォルニア大学は100人弱の大学生を対象として事務作業中にコンテキストスイッチを発生させる実験を行いました。調査の結果、コンテキストスイッチにより元の作業にかかる時間が短縮される一方、特に中断時間が20分を越えるとストレスや疲労感はより高くなることが分かりました。[4]

以上から、集中力を必要する作業ではコンテキストスイッチにより15分以上が無駄になり、成果物に誤りがある確率は倍になります。また、集中力をそれほど要しない作業であっても、コンテキストスイッチにより作業のストレスや疲労感は増加します。

そのため特に集中力を必要とする作業では、生産性や成果物のアウトプットの質の向上にはコンテキストスイッチを減らす必要があります。

悪いコンテキストスイッチの条件

コンテキストスイッチを減らす必要があることは分かりましたが、どのようなコンテキストスイッチを減らせば良いのでしょうか。

カルガリー大学は約150人のソフトウェア開発者の作業記録を分析し、どのようなコンテキストスイッチが生産性に影響するのか調査を行いました。[5]

調査の結果、下記が分かりました。

思考や記憶が必要な作業はコンテキストスイッチによる悪影響を受けます。例えばソフトウェア開発だと、設計、プログラミング、UI設計、リリースが該当します
影響の大きさはコンテキストスイッチごとに5~20分程度です。カリフォルニア大学の結果[4]と一致した結果でした
さらに影響の大きさはコンテキストスイッチの種類によって異なります
- 自発的中断
  - ビルドやツールなどの技術的な問題、優先度の誤り、タスクや技術に関する事前情報不足、作業に飽きたなど
  - 作業者は外部中断が有害と主張しがちだが、自発的中断はその中断時間の長さ、中断が中断を呼ぶことから最も影響が大きい
- 外部中断
  - 最も影響が大きいのはプロジェクトの変更です
  - 次点で、優先度の変更(緊急の割り込み)、午後に発生した割り込み、作業フェーズ(設計、プログラミング、テスト、UI設計、リリース)の変更で影響があります
  - 組み合わせによって影響はより大きくなります

良いコンテキストスイッチもある

良いコンテキストスイッチも存在することが分かっています。[5]

例えば自身が取り組んでいるタスクについて他の人から質問されることで、タスクのより深い理解に繋がります。

このように、自身と同じプロジェクトに取り組んでいる人とのコミュニケーションは生産的なコンテキストスイッチになりえます。

悪いコンテキストスイッチを避ける方法

以上より悪いコンテキストスイッチを避けるためにチームや作業者が意識すべきことをまとめます。

正しいタスクを正しい事前情報とともに用意する

上述したように自発的中断が最も有害です。

自発的中断が起きないよう、タスクの完遂に必要な情報や知識が揃っているか、優先度は適切かなど、依頼者と作業者で確認することが重要です。

この確認には経験を要する上コストがかかる。経験のある人がタスクに必要な情報をドキュメントへまとめておくと良いでしょう。

思考や記憶が必要な作業中に割り込みタスクを入れない

例えばソフトウェアエンジニアであれば、設計、プログラミング、UI設計、リリースが思考や記憶が必要な作業になります。これらの作業中に割り込みを入れないようにします。

作業は余裕を持って依頼してもらう、集中したい時間にはGoogle CalendarやSlack Statusを利用するなどにより集中して作業を終えられる時間を作ると良いでしょう。

再開可能な状態にした上で作業を切り替える

カルガリー大学の研究[5]で、悪いコンテキストスイッチへの対処法が述べられています。

一般的に、タスク後半でのコンテキストスイッチは序盤のそれに比べて有害です。これは中断前の状況を再考する必要があるためです。

一方で、一部の経験のある作業者はタスクをキリのいい状態で保存することが可能であり、タスク後半でのコンテキストスイッチの影響を避ける事ができていました。

このことから、もしコンテキストスイッチが入った場合は、作業者は再開可能な状態を作った上で作業を切り替えると良いでしょう。

タスクをプロジェクトや種類でグループ化し、まとめて取り組む

プロジェクトをまたいだコンテキストスイッチは悪影響があるとはいえ、役割が大きくなるほど多くのプロジェクトへ関わることになるでしょう。

複数のタスクが与えられたときにプロジェクトやタスクの種類ごとにグループ化し、まとめて取り組むことで悪いコンテキストスイッチを減らし、影響を避けることができます。

業務改善例

悪いコンテキストスイッチの条件を踏まえて、過去に私が行った業務改善例を紹介します。

アラート通知を最小限に保つ

アラート対応は緊急度最大の割り込みタスクです
アラート数 x 15分以上 x 通知を受ける人数の工数が消費されるため、アラート数の低減は非常に重要です
しきい値の調整やアラート原因の恒久対応により月間 2.5人日(20 x 15min x 4) の工数を削減しました

ミドルウェアのバージョンアップ自動化

今まで述べてきたコンテキストスイッチとは少し異なりますが、頻繁に発生するタスクは自動化するのが早いです
現職では100程度のミドルウェアを運用しており、それぞれでAction Requiredなアップグレードが頻繁に発生します
発生頻度が高く、1回あたりの作業回数が多く、時間(ビルドとデプロイに時間を要します)も長いため自動化しました
1ヶ月ほどかかりましたが、コンテキストスイッチと業務自体の時間合わせて四半期ごとに1人月の工数削減に繋がりました

工数削減のみ言及していますが成果物の品質の向上も期待できます。

以上はソフトウェア開発における業務改善例ですが、他の業界においても同様です。

業務プロセスをイメージし、起きているコンテキストスイッチの頻度と1回あたりの影響、改善に必要な時間を考えれば改善が必要か判断できると思います。

他には

社内Wikiの継続的メンテナンス

自己中断の有害性から、タスクに必要な情報が整理されており中断なく情報を取り出せることは重要
Wikiなどの組織の情報基盤は全ての作業者があらゆるタスクで使用する
そのため優先度を上げ、明示的に工数を確保してでも整備すべき

なども有益でしょう。

まとめ

本記事では様々な研究を元にコンテキストスイッチによる影響とその条件を述べました。また、それらへの対処方法と業務改善例を紹介しました。

現場は効率化の必要性を感じているものの組織では蔑ろにされたり評価が難しかったりするということがありがちですが、今回コンテキストスイッチの影響を定量化して紹介しました。これにより改善の効果や必要性の説明がつけやすくなったのではと思います。非効率な作業はいくらでもあると思うので、ぜひ日々の生活や仕事に活かしてみてください。

Gincoでは悪いコンテキストスイッチを撲滅し、エンジニアリングにより生産性と開発者体験を向上させたいエンジニアを募集しています。

https://herp.careers/v1/ginco/requisition-groups/16eb3cb7-3407-4441-9230-ae8da92389ad

参考

[1] Programmer Interrupted. https://blog.ninlabs.com/2013/01/programmer-interrupted/

[2] A diary study of task switching and interruptions. CHI ‘04, April 2004, Pages 175–182, https://dl.acm.org/doi/10.1145/985692.985715

[3] Interrupts: just a minute never is. IEEE Software (Volume: 15, Issue: 5, Sept.-Oct. 1998), https://ieeexplore.ieee.org/document/714843

[4] The Cost of Interrupted Work: More Speed and Stress. CHI ‘08, April 2008 Pages 107–110, https://dl.acm.org/doi/10.1145/1357054.1357072

[5] Task Interruption in Software Development Projects: What Makes some Interruptions More Disruptive than Others?, EASE'18, June 2018 Pages 122–132, https://dl.acm.org/doi/abs/10.1145/3210459.3210471