コンテキストスイッチとは、あるタスクから別のタスクへと、焦点や注意を比較的短時間で切り替えることだと定義される。これは、チームメンバとその人が取り組んでいるプロジェクトにとって、有害であると広く考えられている。コンテキストスイッチはマルチタスクに似たものだとみなされることが多く、最近のInfoQの記事でも、マルチタスクが及ぼす悪影響に関するスタンフォード大学の研究事例が紹介されている。David Starr氏は、コンテキストスイッチはムダに似たものだと考えており、次のように語っている。
コンテキストスイッチはムダそのものです。ムダとは日本語で、価値を生まない、もしくは効果のない行動のことです。コンテキストスイッチを積極的に操ることを学べば、動作にムダがなくなり、もっとテキパキとした人になれるでしょう。以上。
コンテキストスイッチの脅威に立ち向かう方法にはいろいろとある。第一のルールは、「コンテキストスイッチするな」だ。 しかし、Charles Miller氏は、コンテキストスイッチを完全になくせると思うのは甘い考えだと語る。プロジェクトにはいろいろと邪魔がつきものなので、それに対処する方法が必要だと言うのだ。彼はAtlassian社で使っていたテクニックについて話した。
- 非同期コミュニケーション - Atlassian社では、スタッフ向けにJabberサーバを動かしていて、開発者は一日中、インスタントメッセージにログオンしていました。これがよかったのは、基本的に非同期なので、無視しやすく、あとで適当なタイミングで返事ができたところです。ブログや社内Wikiもすぐれたツールで、リアルタイムに他人の邪魔をすることなく、他人の意見を得るために使われていました。
- 邪魔され役 – もう1つ使っていた面白い考え方は、1人の開発者を「邪魔され役」に任命することです。この開発者はスプリント期間中、いろいろと邪魔されることになります。彼には、チーム全体が邪魔されないよう、すべての邪魔やコンテキストスイッチに対処して、応対する責任があるのです。
開発者を1人「邪魔され役」に任命しましょう。チーム全体に広がらないよう、あらゆる質問や要求、邪魔の引き受け役として、2週間仕事をさせるのです。
Charles氏は、スプリント期間中は「邪魔され役」の人がたくさん仕事をすると期待してはいけないと警告する。これはコンテキストスイッッチの落とし穴として予想されることだ。彼はこう話している。
このやり方のよくないところは、もちろん、2週間のあいだ、邪魔され役は名目上コミットしている機能について、ほとんど仕事ができないということです。一方、「邪魔され役」の人は、邪魔されているあいだに、そうした仕事をたくさんやれるとは思っていない（または、思われていない）ので、開発者としてあまりイライラすることはなく、チーム全体のスケジュールや見積もりの観点からも、はるかに予測可能になります。
したがって、次回、アジャイルチームが複数のコンテキストスイッチや邪魔に対処する必要があるときには、スプリント中に邪魔されるチームメンバを、邪魔され役として専任でアサインすることを検討してみてもよいかもしれない。