多くの組織やチームは、コンテキストスイッチを、並列化と人材リソースの最適化の両方として誤って正当化しています。 彼らの目標は効率化ですが、無意識のうちにこれらの「隠された優先順位」は、効率(物事を迅速に達成すること)の低下だけでなく、有効性(最も価値のあることを達成すること)の損失ももたらします。
戦略的および戦術的な優先順位付け
優先順位付けはアジリティの中心です。 私たちは、お客様に最も価値のあるものを提供するために、毎日厳しいビジネスの優先順位付けの決定を下しています。 『アジャイルソフトウェア開発宣言』自体が、優先形式(「YよりもXを重視する」)の4つ価値一式になっています。 優先順位付けを理解するのに特に役立つのは、宣言の最後のフレーズです:「すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく」。 優先順位付けとは、特定のものを他のものよりも評価し、それらに対処する順序を決定することです。 ビジネスに無限の帯域幅とリソースがない限り、優先順位を選択する必要があります。 すべての機能を今日、あるいは明日、実装できるわけではありません。 最も価値があるものは、一度に1つだけであり、あなたの時間、才能、リソースを割くに値するものです。
これは、ハイレベルな戦略的イニシアチブだけでなく、日々の戦術的タスクレベルにも当てはまる。 多くの場合、戦術レベルでは、戦略的な視点(つまり、木を見て森を見ず)を保つことを忘れると、より最適であろうものを犠牲にして、最適ではないことを選択することになります。 これらの決定は、私たちが「隠された」優先順位と呼ぶものに基づいています—私たちの潜在意識、習慣、または私たちの恐れのどこかに隠されているものです。 これらの隠れた優先事項を明らかにすることは、それらが望ましいかどうか、そうでない場合は、それらを克服するためにどのような行動を取ることができるかを判断するのに役立ちます。
この記事では、そのような決定の1つであるコンテキストスイッチと並列化の、隠れた優先順位について説明します。
コンテキストスイッチは、並列化ではありません
戦術やタスクのレベルでは、コンテクストスイッチングとは、すでに進行中の仕事を終える前に、別の仕事に取りかかることです。 アジャイルチームはこのプラクティスを「スラッシング」と呼び、遅延のコストが発生するため回避します。 タスク レベルでの並列化とは、複数のチームメンバーが、1つの戦略的な作業項目に取り組むことです。それぞれが異なるタスクに取り組んでいても、集合的に、プロダクトバックログから1つのエンドツーエンドのユーザー機能に(多くのアジャイルチームはこれらを「ユーザー ストーリー」と呼びます)向けて取り組んでいます。 アジャイルチームでは、これをしばしば「スウォーミング」と呼び、完成した出荷可能な機能のフローとデリバリーを最適化するために行われます。
多くの組織は、コンテキストスイッチを並列化と人材リソースの最適化の両方として誤って正当化しています。 どちらも、人と作業項目を含む「1対 多」の関係を伴いますが、結果は大きく異なります。
コンピュータ-(および人間)は、スラッシュよりスウォームのほうがうまい
コンピューターは、違いを理解するための簡単なアナロジーを提供します。 シングルコアマシン(かつて)では、PCは基本的に一度に1つのプログラム、1つのコマンドしか実行しませんでした。 したがって、長い計算を伴うプログラムを起動すると、計算が終了するとマウスが応答しなくなります。 ユーザーへの応答性を維持するために、コンピューターはマウスに反応するために既存のプログラムを頻繁に一時停止していました。 プログラムを一時停止して別のプログラムを起動するには、メモリのアンロードとロードが必要ですが、これには時間がかかり、どちらのプログラムにも直接利益をもたらしません。 これがコンテキストスイッチです。
2001年、IBMは 複数のコアを備えた最初のプロセッサをリリースしました。 これにより、それぞれに個別のコアを与えることができるため、コンピューターは一度に複数のプログラムを実行することができるようになりました。 さらに良いことに、これにより、1つのプログラムが作業を分割して複数のコアで実行でき、プログラムの作業が高速化されました。 これがタスクの並列化です。 これが、今日私たちがコンピューターで多くのことができる主な理由の1つです。
人間が作成した機械から学ぶことができるのは、1人の労働者が複数の作業項目で同時に作業すると、かなりのコストがかかるということです。 スクラム チームでは、コンテキストスイッチなしのスプリントのベロシティが、コンテキストスイッチをしたスプリントよりも、少なくとも 25%高いことがわかりました。 より広範な、科学および業界の調査によると、コンテキストスイッチの悪影響はさらに大きいことがよくあります。
- コンテキストスイッチは、 生産時間の最大40%を犠牲にする可能性がある(アメリカ心理学会)
- 一連のステップを含む複雑な作業でエラーが増加する(アメリカ国立生物工学情報センター、アメリカ国立医学図書館)
- ストレスが増加する (カリフォルニア大学アーバイン校)
ジェラルド・ワインバーグは、著書『ワインバーグのシステム思考法 ソフトウェア文化を創る』で、タスクスイッチのコストを次のように定量化しています。
No. 同時プロジェクト | プロジェクト滞在時間の割合 | コンテキストスイッチへの損失 |
1 | 100% | 0% |
2 | 40% | 20% |
3 | 20% | 40% |
4 | 10% | 60% |
5 | 5% | 75% |
サイロ化
コンテキストスイッチのもう1つの悪質な副作用は「サイロ化」で、1 人のユーザーが作業全体を自分で行うと、知識が個人にとどまります。 その個人は、多くの場合、その後もその領域にあるすべてのアイテムを抱えこみます。 将来的にその人が病気になったり休暇を取った時に(バスにぶつかる必要さえありません)、その領域がブロックされるという問題を解決できません。 さらに、チームメンバーはお互いから学ぶことが少なく、汎用性に欠け、メンバーが「自分のアイテム」に集中したり、取り繕ったりして、スプリントの目標への焦点が薄れていきます。
タスクの並列化、つまりスウォーミングは、一般に、スクラムチームの納品率を向上させるだけでなく、チーム全体の集合的で協調的なインテリジェンスを活用して、物事が計画どおりに進まない場合に適応する能力を向上させます。
隠された優先度の公開と削除
では、チームや企業がコンテキストスイッチを不適切に正当化する原因となる隠れた優先事項とは何でしょうか? 2つ見てみましょう。
応答性は錯覚になり得る
コンテキストスイッチの第一の理由は、コンピューターがかつてそれを行ったのと同じ理由です:応答性の錯覚を与えるため。 顧客に「すぐに取り組み舞う」と伝えたいと考える人がいます。 残念ながら、「すぐに取りかかる」ことは、それがいつか始まるということを意味するだけです。 終えることについては言及されていません。 言い換えれば、顧客を早期に満足させるという名目で、システムから価値を引き出すことよりも、システムに仕事を取り込むことが重視されているわけですが、顧客が本当に望んでいるのは前者です。 これはほとんどのチームが実際に望んでいることでもありますが、フル稼働という隠れた優先順位は、チームにばた違った行動を起こさせます。
チームが許容量よりも多くの作業を引き受けると、この過負荷のシステムは各スプリントの結果のばらつきを増加させ、長期的に見積もりと予測を行う能力を制限します。 これは、性急で不合理なコミットメントにつながる可能性があり、その結果、スケジュールの超過や期待が満たされないことにつながります。
コンテキストスイッチも欠陥の増加につながります。 チームメンバーは複数のバックログ項目に注意を向ける必要があるため、ニュアンスやコーナーケースが見落とされる可能性があります。 チームの完了の定義(つまり、スプリントの終了時に出荷可能であることの意味)は見落とされ、失われた時間を補うために手抜きをする可能性があります。 これらの品質の問題は、イノベーションから注意をそらし、チームとビジネス上の期待へのプレッシャーを悪化させる、より多くの顧客の要求(時には緊急の要求)に変わります。
これに対抗するには、勤勉なプロダクトオーナーが顧客と協力して、「すぐに取りかかります」という考え方に戻るのではなく、バックログで新しいアイテムの適切な場所を見つける(または古いアイテムをシャッフルする)必要があります。 優れたプロダクトオーナーは、チームが開始した作業を完了できるように、顧客の期待を管理する方法を知っています。 スクラムマスターは、コンテキストスイッチがいつ発生しているかを監視し、問題を可視化する必要もあります。
フル稼働は神話です
コンテキストスイッチが起こる2つ目の理由は、チーム メンバーのフル稼働というプレッシャーです。 フル稼働とは、チーム全体によって生み出される価値よりも、個々のチームメンバーの有効性を優先することです。 多くの不適切な決定は、 非常に誤解を招く指標である「100%フル稼働」の名の下に正当化されます。 フル稼働は、ユーザーに提供する製品を測定できないし 品質を測定することもできません。 それはあなたの顧客がお金を出しているものの何一つも測定しません。 フル稼働で分かることは、価値のある仕事であるかどうかに関係なく、誰かが週に何時間働いているかということだけです。 100%フル稼働が目標である場合、それは、人々が週に40時間(多くの場合、残念ながらそれ以上)働いている限り、あらゆる行動を正当化できることを意味します。 稼働率を示したところで、納品された製品や品質を向上させることはできません。
稼働率を追求すると、「スプリントの残りの作業はすべてテストなので、開発者は次のスプリントに取り掛かるべき」としばしば同義です。 または、「ボブはGUIの男なので、GUIが含まれている他の何かに先に取り組んでもらいます。」ということかもしれません。 スプリントバックログは、プロダクトバックログの次に優先度の高い項目である必要があります。 したがって、定義上、チームメンバーが現行のユーザーストーリー以外の何かに取り組んでいるとき、彼らはビジネスにとって次に優先度の高いものではない何かに取り組んでいます。 稼働率は、ビジネスと顧客の優先順位を下げます。 皮肉ですよね。
スウォーミングは簡単ではない
スウォーミングに不慣れなチームは、それが実際に実行できると思わないかもしれません。 一般的な反対意見は次のとおりです。
- 「どうすればいいのかわからない」 または、「それはミーガンの責任です。」 —これは、学びたくない、または誰かが誰かが自分より下だと考えることをしようとしない姿勢を反映している可能性があります。 今日の世界では、毎日新しいスキルを学ぶことが、変化するテクノロジーと市場に追いつく方法です。 優れたチームは常に学習しています。 チームの現在の目標に貢献することに焦点を当てる必要があります。
- 「これについてジョンに教える時間はありません。」 —これは、情報を差し控えることによって雇用の安定を確立しようとしている可能性があります。 チームメンバーは、雇用保障とは、個人ではなく チーム を不可欠なものにすることであることを理解する必要があります。
- 「キッチンには料理人が多すぎます」 ー それが真実であることもありますが、ユーザーストーリーに取り組むことができる人の数は、当初考えられていたよりも多いことがよくあります。
スクラム開発チーム(この例ではソフトウェア業界)が効果的にスウォーミングできる方法を調べてみましょう。
- チームは一緒に、初期の設計演習を含むユーザー ストーリーを詳しく考えます
- 1人がコードを書く
- 2つ目は単体テストの記述です(これは別のファイルなので、誰かの邪魔をすることにはなりません)
- 3つ目は、統合テストやシステムテストの作成などです。これですでに3人が 1つのユーザー ストーリーに取り組んでいることになります
- 4つ目は、自動化されたユーザー受け入れテストの作成です
- 書くクラスが2つ? コードと単体テストを記述するために、さらに2人を追加できます
- 文書の更新(ウィキ、講座、ユーザーなど)
- ペアプログラミングを検討して、品質のためにピアレビューを前倒しします
- データベース・アップグレード・スクリプトの作成
- 他にも何かあるかもしれません
開発チームは3から9人で、理想的にはその範囲の中間です。 1つのユーザー ストーリーをとっても、全員にできることがたくさんあります。
はい、つまり、これには開発期間中の毎日コラボレーションする必要があります。 だから、スクラムはラグビーのチームコラボレーションに喩えて 「スクラム」と呼ばれるのです。 これによって、開発者が、彼らが最も得意とする仕事以外のものに取り組む可能性を意味するかもしれません。 しかし、チームメンバーが一日の100%忙しく立ち働いていることを示すのではなく、最も優先度の高い仕事をより早く、より頻繁に提供することに焦点を当てることになります。 また、コラボレーションにより、サイロ化ではなく、多才な開発者のチームが実現します。
最高のチームはT型のメンバーがいます。つまり知識分野の深さ、または専門知識(専門化とは違う)を持ち、複数の分野である程度の幅を持つ個人ということです。
T型の開発者は汎用性があり、学習に熱心であり、目標はスプリントの目標であり、フル稼働ではありません。 T型メンバーは、顧客への価値提供に貢献する能力を常に高めています。
「スラッシング」からの脱出
コンテキストスイッチの背後にある、隠れた優先順位を回避するのに役立つ可能性のあるいくつかのメトリクスを検討してください。 これらもまた、稼働率と個々のサイロ化された貢献を合理化する代わりに、提供される価値に貢献する行動を奨励することができます。 以下についてはブログ記事「何を測るかに注意」で詳述しています:
- 投資収益率(ROI): 新しい機能を提供するときに、望ましい価値と意図した価値が実現されるのか? 投資収益率を生み出すために、新しい価値がどのくらい早く、どのくらいの頻度で提供されていますか?
- 本番環境での欠陥:本番環境に欠陥がある場合、あなたはその理由を言えますか? 「出荷可能」という意味での完了の定義を満たしていないのは、スラッシングのせいですか?
- スプリント目標の成功率:忙しなく仕事をこなし、多くの仕事に着手しているが、終わっていないですか? 顧客の目標に向かって取り組んでいますか、それともバラバラのタスクに取り組んでいますか?
- リードタイムとサイクルタイム:完了させるより着手することが多いですか?
- スキルの多様性?開発者はスプリントの目標に貢献する能力を継続的に高めていますか?
これらはすべて、作業の開始ではなく、仕事を終えることに集中するのに役立ちます。 コンテキストスイッチとスウォーミングのどちらかを選択する際には、コンテキストスイッチは作業を開始することであり、スウォーミングは作業を完了すること、つまり早期かつ頻繁に価値を提供することであることを覚えておいてください。
概して、顧客は完成した作業に焦点を合わせています。 彼らは使えない機能などいりません。 彼らは稼働率を気にしません。 そして、彼らはあなたがどれだけ早く着手できるかなんて気にしません。 顧客は、どれだけ早く仕上げて品質を提供できるかを気にします。 スティーブ・ジョブズが言ったとされているように、「真の芸術家は、出荷する」。
最大限に効率化するために隠れた優先事項を明らかにしたいですか?今すぐアドバイザーに連絡してください。