スクラムマスターの渡部です。
以前、とあるイベントに参加した際、「スクラムをやり始めたチーム向けの、ネタ帳的な情報ってあまり見かけないよね」という話をしていたのですが、それならばと思い、私たちのチームで実際にやったことの一部を紹介していこうと思います。
今回のテーマは、コンテキストスイッチのコスト削減です。
※今になって思えば、「スクラム現場ガイド」がまさにネタ帳的な内容でしたので、興味がある方はぜひお手に取っていただければと思います。
本記事で解説する内容
- コンテキストスイッチとは？
- コンテキストスイッチを体感してみよう！
- コンテキストスイッチを減らすためにやったこと3つ
想定読者
- （スクラムを導入しているか否かに関わらず）個人・チームのパフォーマンスを上げたいと考えている方
コンテキストスイッチとは？
コンテキストスイッチとは一言でいうと、作業Aから、異なる文脈の作業Bに思考を切り替えることです。
ただ作業を切り替えているだけのようにも思えますが、作業Bを終えて作業Aに戻ったとき、「作業Aがどこまで進んでいたのか？」、「この後何をするべきだったのか？」を思い出して復帰する工程が必要になり、ムダが発生してしまっているのです。
思い出すことができればまだ良いのですが、酷い場合は全く思い出すことができず、「昔話したアレ…結局何をすれば良かったんだっけ…？」と確認するハメに…
皆さんの中にも、「たくさんミーティングが入っている日は、他の作業が全然進まないなぁ…」というシチュエーションに身に覚えがある方はいませんか？
恐らくその時、「ミーティング」と「作業」の間でコンテキストスイッチが発生することにより、「元々の作業を思い出して復帰する」ことに思考のリソースを割いてしまっている可能性があります。
コンテキストスイッチを体感してみよう！
そうは言ったものの、「簡単な作業なら、少しくらい平気でしょ！」という気持ちも分かるので、簡単なワークでコストを体感してみたいと思います。
私がチームで実施しているのは下記の方法です。5分あれば体験できるので、良ければ是非試してみてください。
準備するもの
- 紙
- ペン
- ストップウォッチ（スマホでOK）
概要
アルファベット10文字「a〜j」、ひらがな10文字「あ〜こ」、数字10文字「0〜9」を2通りの順番で書いていただき、書き終えるまでの時間を計測・比較します。
「アルファベットを書く作業」、「ひらがなを書く作業」、「数字を書く作業」の、3種類の作業が存在するイメージですね。
手順
- まずは、3種類の文字を1文字ずつ順番に書きます。（a → あ → 1 → b → い → 2…）
- 次に、1つの文字種をまとめて書いて、次の文字種に移ります。（a〜j → あ〜こ → 0 → 9）
- 1,2で書き終えるまでの時間を比較します。
いかがでしたでしょうか。
「文字を書く」という作業は日常で慣れているはずですし、特に難しい文字を書いている訳でも無いはずですが、書きにくさを感じませんでしたか？
簡単に思える作業ですらそうなのですから、当然、コードを書いたり、テストをしたり、その他開発以外のあらゆる作業も影響を受けます。
ですので、個人やチームのパフォーマンスを向上させるためには、できる限りコンテキストスイッチを減らし、同じコンテキストの作業を継続できる状況を作ることが大切になります。
次のセクションでは、私たちのチームがコンテキストスイッチ減らすために実際にやってみたことを、エンジニアからのラフな感想付きでいくつか紹介していきます。
やったこと①：運用系作業（差し込み作業）のコントロール
困っていたこと
- 運用系作業（差し込み作業）と、それに関連する確認相談が頻繁に発生していた
- スプリント内の全工数の内、3〜6割ほどが運用系作業で占められていた
何をしたのか
- 運用系作業を専門で行うスタッフをアサインして、他スタッフが確認・対応する時間を減らした
- 複数の作業依頼が発生することもあったので、運用系作業のためだけのカンバンを作成し、着手すべき優先順位順に1列で並べるルールにした
どうだったか
エンジニア曰く「これは本当に良かった、助かった」とのこと。
差し込み（コンテキストスイッチ）を減らしたことと、単純に運用系作業に対応できる量にも制限が出来たことで、もともとは3〜6割程度を占めていた運用系作業の割合が、多くて1割程度に落ち着きました。
この施策は、チームで実施してきたカイゼンの中でも特にインパクトが大きいものでした。が、その分、チームに適したフローを整えるのに頭を悩ませましたし、影響範囲も大きいので、沢山の方にご理解ご協力をいただきました。
プロジェクトとチームの状況をご理解いただき、ご協力いただいた関係者の皆様、本当にありがとうございます。 特に、フロー検討時に相談に乗っていただいたY岸さん、K林さん、グループ全体にスムーズに展開していただいたT中さん、そして何より、一手に引き受けてくださったSさん、本当にありがとうございます。
実施に際してチームごとに課題はあるかと思いますが、同じような問題に悩まれているチームは多いかと思いますので、是非試してみていただければと思います。
因みに、スクラム現場ガイド 14章では「専任チーム」として同様の事例が紹介されています。
やったこと②：プロダクトオーナーの席移動
困っていたこと
- （詳しい事情は皆様のご想像にお任せしますが）不明なことが非常に多い中で探りながら開発を進める必要があり、都度の確認・相談のために作業の手が止まっていた
何をしたのか
- プロダクトオーナーにコンテキストスイッチによるコストを説明・理解いただき、チームの近くに移動してもらい、気軽に確認相談できる環境を整えた
どうだったか
本当にややこしいものは、口頭のみで済ませてしまうと後で困るので、結局テキストに残すことになるのですが、「簡単な相談や、作ってその場で方向性のジャッジができることは良かった」と、エンジニアからはまずまずの評価でした。
因みに、プロダクトオーナーが近くにいることで過干渉のリスクがあると言われていましたが、私たちのチームではそのような問題はありませんでした。
やったこと③：MTGの調整
困っていたこと
- MTGがたくさんある
- MTGの開催時間が点在していて、長時間集中できる時間が無い
何をしたのか
- 参加マストなMTG以外は、欠席 or 任意参加にしてもらえるよう、関係者へ交渉した
- 参加マストなMTGで、時間調整可能なものは、朝に移動して午後はできる限り空けた
どうだったか
エンジニア曰く「MTGまであと30分くらいだから簡単な作業をしよう…とムダに考えなくて良くなったので進めやすくなった」とのこと。
ちなみに
コンテキストスイッチによる作業効率の低下は、作業単位のみならず、プロジェクト単位でも発生することがわかっています。
ざっくりとした例えですが、次のようなプロダクトA,B,Cのための3つのプロジェクトがあったとします。（必要な作業 A1,A2,A3が達成できれば、プロダクトAが出来上がるイメージです）
まずは、全てを優先、つまり、チームが複数のプロジェクトを掛け持つ場合のスケジュールを見てみましょう。
作業間でコンテキストスイッチが発生するため、作業間に余白を入れて、下記のようなスケジュールになります。
次に、1つずつ順番に対応する場合のスケジュールを見てみましょう。
コンテキストスイッチが発生するのは、A→Bの切り替え時、B→Cの切り替え時のみとなるので、そこに余白を入れて、下記のスケジュールとなります。
可能な限りコンテキストスイッチを抑え、1つずつ順番に対応した場合の方がムダ（余白）が無いため、トータルで早く完了しそうだということがわかります。
（コンテキストスイッチの話とは少し脱線しますが、各プロダクトA,B,Cが早くリリースでき、多くの価値を提供できる利点もあります）
プロジェクトの同時並行に関してはやむを得ない場合もあると思われますので、可能な場合には考慮いただくとよろしいかと思います。
補足
下記ページにある表では、同時並行のプロジェクトが増えるごとに、コンテキストスイッチによってロスが生じ、1つ1つのプロジェクトに使える時間の割合が減っていくことを説明していますので、良ければ見てみてください。
掛け持ちが3つ以上になると、1つ1つのプロジェクトに費やせる割合よりも、コンテキストスイッチによるコスト（ムダ）の割合の方が多くなるのは感慨深いです。
さいごに
いかがでしたでしょうか？
チームのパフォーマンスをできるだけ高めたいと考えている方にとってのヒントとなれば幸いです。
既に何らかの施策を実施されている方は「うちのチームはこんなことをやってみたよ！」とコメントいただけると涙を流して喜びます。
今回は、「コンテキストスイッチのコスト削減」にフォーカスしてお話しましたが、いずれ別のテーマでもネタ帳的な内容で記事を書ければと思います。
このように、私たちのチーム・会社では、効率的に目的を達成するために全員が一丸となって日々カイゼンと繰り返しています。
そんな働き方に少しでも興味を持っていただけるようでしたら、是非下記も覗いてみていただけると嬉しいです。
