あなたを無力にする隠れた優先順位を明らかにする

多くの組織やチームは、コンテキストの切り替えを並列化と人材リソースの最適化の両方として誤って正当化しています。 彼らの目標は効率ですが、無意識のうちにこれらの「隠された優先順位」は、効率の低下(物事を迅速に達成する)だけでなく、有効性の損失(最も価値のあることを達成する)ももたらします。

戦略的および戦術的な優先順位付け

優先順位付けはアジリティの中心です。 私たちは、お客様に最も価値のあるものを提供するために、毎日厳しいビジネスの優先順位付けの決定を下しています。 アジャイルソフトウェア開発のマニフェスト自体は、優先度形式の4つの値のセットです(「YよりもXを重視します」)。 マニフェストの最後のフレーズは、優先順位付けを理解するのに特に役立ちます:「つまり、右側の項目には価値がありますが、左側の項目をより重視します」。 優先順位付けとは、特定のものを他のものよりも評価し、それらに対処する順序を決定することです。 ビジネスに無限の帯域幅とリソースがない限り、優先順位を選択する必要があります。 すべての機能を今日、あるいは明日実装できるわけではありません。 一度に1つだけが、次に価値があり、時間、才能、リソースに値するものになる可能性があります。

これは、 高レベルの戦略的 イニシアチブだけでなく、日常の戦術タスクレベルにも当てはまります。 多くの場合、戦術レベルでは、戦略的な視点(つまり、木のための森)を維持することを忘れると、より最適であったであろうものを犠牲にして、最適ではないことを選択することになります。 これらの決定は、私たちが「隠された」優先順位と呼ぶかもしれないものに基づいています—私たちの潜在意識、習慣、または私たちの恐れのどこかに隠されています。 これらの隠れた優先事項を明らかにすることは、それらが望ましいかどうか、そうでない場合は、それらを克服するためにどのような行動を取ることができるかを判断するのに役立ちます。

この記事では、そのような決定の1つであるコンテキスト切り替えと並列化の隠れた優先順位について説明します。

コンテキスト切り替えは並列化ではありません

戦術レベルまたはタスク レベルでは、コンテキスト切り替えとは、既に処理中の別の作業項目を完了する前に、作業項目を開始することです。 アジャイルチームはこのプラクティスを「スラッシング」と呼び、遅延のコストが発生するため回避します。 タスク レベルでの並列化とは、複数のチーム メンバーが 1 つの戦略的な作業項目に取り組んでいることで、それぞれが異なるタスクに取り組んでいても、製品バックログから 1 つのエンドツーエンドのユーザー機能に向けて作業しています (多くのアジャイル チームはこれらを “ユーザー ストーリー” と呼んでいます)。 アジャイルチームの場合、これはしばしば「スウォーミング」と呼ばれ、完成した出荷可能な機能のフローと配信を最適化するために行われます。

多くの組織は、コンテキスト切り替えを並列化と人材リソースの最適化の両方として誤って正当化しています。 どちらも、人と作業項目を含む 1 対多の関係を伴いますが、結果は大きく異なります。

コンピュータ(および人間)は、スラッシュするよりもうまく群がる

コンピュータは、違いを理解するための簡単なアナロジーを提供します。 シングルコアマシン(当時)では、PCは基本的に一度に1つのプログラム、1つのコマンドしか実行しませんでした。 したがって、長い計算でプログラムを起動すると、計算が終了するとマウスが応答しなくなります。 ユーザーへの応答性を維持するために、コンピューターはマウスに応答するために既存のプログラムを頻繁に一時停止しました。 プログラムを一時停止して別のプログラムを起動するには、メモリのアンロードとロードが必要ですが、これには時間がかかり、どちらのプログラムにも直接利益をもたらしません。 これはコンテキストの切り替えです。

2001年、IBMは 複数のコアを備えた最初のプロセッサをリリースしました。 これにより、それぞれに異なるコアを与えることができるため、コンピューターは一度に複数のプログラムを真に実行することができました。 さらに良いことに、これにより、1つのプログラムが作業を分割して複数のコアで実行でき、プログラムの作業が高速化されました。 これがタスクの並列化です。 これが、今日私たちがコンピューターで多くのことができる主な理由の1つです。

人間が作成した機械から学ぶことができるのは、1人の労働者が複数の作業項目で同時に作業すると、かなりのコストがかかるということです。 スクラム チームでは、コンテキスト切り替えなしのスプリントの速度が、コンテキスト切り替えを使用したスプリントよりも少なくとも 25% 高いことがわかりました。 より広範な科学的および業界の調査によると、コンテキスト切り替えの悪影響はさらに大きいことがよくあります。

• コンテキストの切り替えは、 誰かの生産時間の最大40%を犠牲に する可能性があります(アメリカ心理学会)
• 一連のステップを含む複雑な作業でエラーが増加する(米国国立バイオテクノロジー情報センター、米国国立医学図書館)
• ストレスが増加する (カリフォルニア大学アーバイン校)

Gerald Weinbergは、彼の著書「Quality Software Management: System Thinking」で、タスク切り替えのコストを次のように定量化しています。

サイロ化

コンテキスト切り替えのもう 1 つの悪質な副作用は「サイロ化」で、1 人のユーザーが作業全体を自分で行うと、知識が独立して保持されます。 その同じ人は、多くの場合、そのドメインにある他のすべてのアイテムを前進させることになります。 将来的には、その人が病気や休暇中の日になり(いいえ、バスにぶつかる必要さえありません)、その地域のブロッキングの問題を解決できません。 さらに、チームメンバーはお互いから学ぶことが少なく、用途が広くなく、人々が「自分のアイテム」や金メッキに集中するにつれて、スプリントの目標への焦点が薄れます。

タスクの並列化、つまりスウォーミングは、一般に、スクラムチームの配信率を向上させるだけでなく、チーム全体の集合的で協調的なインテリジェンスを活用して、物事が計画どおりに進まない場合に適応する能力を向上させます。

非表示の優先度の公開と削除

では、チームや企業がコンテキストの切り替えを不適切に正当化する原因となる隠れた優先事項は何ですか? 2つ見てみましょう。

応答性は錯覚になる可能性があります

コンテキスト切り替えの最初の理由は、コンピューターがそれを行ったのと同じ理由です:応答性の錯覚を与えるため。 誰かが顧客に「私たちはそれを正しく理解します」と伝えることができるようにしたいと考えています。 残念ながら、何かを「正しく理解する」ことは、それが始まることを意味するだけです。 それはそれを終えることについては何も言いません。 言い換えれば、顧客を早期に満足させるという名目で、システムから価値を引き出すことよりも、システムに仕事を取り入れることが評価され、後者は顧客が実際に望んでいるものです。 これはほとんどのチームが実際に望んでいることですが、完全な活用は、異なる動作を引き起こす隠れた優先順位です。

チームが持続可能よりも多くの作業を引き受けると、この過負荷のシステムは各スプリントの結果のばらつきを増加させ、長期的に見積もりと予測を行う能力を制限します。 これは、性急で不合理なコミットメントにつながる可能性があり、その結果、スケジュールの超過や期待が満たされないことにつながります。

コンテキストの切り替えも欠陥の増加につながります。 チームメンバーは複数のバックログ項目に注意を向ける必要があるため、ニュアンスやコーナーケースが見落とされる可能性があります。 チームの完了の定義 (つまり、スプリントの終了時に出荷可能であることの意味) は見落とされ、失われた時間を補うために手抜きをする可能性があります。 これらの品質の問題は、イノベーションから注意をそらし、チームとビジネスの期待へのプレッシャーを悪化させる、より多くの顧客の要求(時には緊急の要求)に変わります。

これに対抗するには、勤勉な製品所有者が顧客と協力して、「私たちはそれを正しく行う」という考え方に戻るのではなく、バックログで新しいアイテムの適切な場所を見つける(または古いアイテムをシャッフルする)必要があります。 優れたプロダクトオーナーは、チームが開始した作業を完了できるように、顧客の期待を管理する方法を知っています。 スクラムマスターは、コンテキストの切り替えがいつ発生しているかを監視し、問題を可視化する必要もあります。

完全な活用は神話です

コンテキスト切り替えが使用される 2 つ目の理由は、チーム メンバーの完全な使用率を示すというプレッシャーです。 使用率とは、チーム全体によって生み出される価値よりも、個々のチームメンバーの有効性を優先することです。 多くの不適切な決定は 、非常に誤解を招く指標である「100%使用率」の名の下に正当化されます。 ユーザーに配信された製品は測定されません。 品質を測定するものではありません。 それはあなたの顧客があなたに支払っているものを何も測定しません。 使用率の尺度は、それが彼らが行うことができる最も価値のある仕事であるかどうかに関係なく、誰かが週に何時間働いているかです。 100%の使用率が目標である場合、それは、人々が週に40時間(多くの場合、残念ながらそれ以上)働いている限り、あらゆる行動を正当化できることを意味します。 使用率を測定して、納品された製品や品質を向上させることはできません。

利用を追求すると、「スプリントの残りの作業はすべてテストなので、この開発者は次のスプリントに取り掛かるべきです」のように聞こえることがよくあります。 または、「ボブはGUIの男なので、GUIが含まれている他の何かに先に取り組んでもらいます。」 スプリント バックログは、製品バックログの次に優先度の高い項目である必要があります。 したがって、定義上、チームメンバーが現在のユーザーストーリー以外の何かに取り組んでいるとき、彼らはビジネスにとって次に優先度の高いものではない何かに取り組んでいます。 使用率は、ビジネスと顧客の優先順位を下げます。 皮肉ですね。

群れは簡単ではありません

スウォーミングに不慣れなチームは、それが実際に実行できるとは思わないかもしれません。 一般的な反対意見は次のとおりです。

• 「どうすればいいのかわからない」 または、「それはミーガンの責任です。」 —これは、学びたくない、または誰かが自分の下にあると考える何かをしたくないことを反映している可能性があります。 今日の世界では、毎日新しいスキルを学ぶことが、変化するテクノロジーと市場に追いつく方法です。 優れたチームは常に学習しています。 チームの現在の目標に貢献することに焦点を当てる必要があります。
• 「これについてジョンに教える時間はありません。」 —これは、情報を差し控えることによって雇用の安定を確立しようとしている可能性があります。 チームメンバーは、雇用保障とは、個人ではなく チーム を不可欠なものにすることであることを理解する必要があります。
• 「キッチンには料理人が多すぎます」 — 時には真実ですが、ユーザーストーリーに取り組むことができる人の数は、当初考えられていたよりも多いことがよくあります。

スクラム開発チーム(この例ではソフトウェア業界)が効果的に群がる方法を調べてみましょう。

• チームは、最初の設計演習を含むユーザー ストーリーをまとめて詳しく説明します
• 1 人がコードを書く
• 2 つ目は単体テストの記述です (これは別のファイルなので、足を踏む必要はありません)
• 3 つ目は、統合テストやシステム テストの作成など、すでに 3 人が 1 つのユーザー ストーリーに取り組んでいることになります
• 4つ目は、自動化されたユーザー受け入れテストを作成することです
• 書くべき2つのクラス? コードと単体テストを記述するために、さらに 2 人を追加できます
• ドキュメントの更新 (wiki、トレーニング、ユーザーなど)
• ペアプログラミングを検討して、品質のためにピアレビューを前倒しします
• データベース・アップグレード・スクリプトの作成
• 多分あなたは他の人を考えることができます…

開発チームは3人から9人で、理想的にはその範囲の中間のどこかです。 1 つのユーザー ストーリーで誰もができることはたくさんあります。

はい、これには開発中の毎日のコラボレーションが必要です。 そのため、スクラム はスクラムと呼ばれ、チームコラボレーションのラグビーの比喩です。 はい、これは、開発者が彼らの最も得意な分野ではない何かに取り組んでいることがあることを意味するかもしれません。 しかし、得られるのは、労働者が一日の100%忙しいことをしていることを示すのではなく、最も優先度の高い仕事をより早く、より頻繁に提供することに焦点を当てることです。 また、コラボレーションにより、サイロ化ではなく、多才な開発者のチームが実現します。

最高のチームには、少なくとも1つのスキルまたは知識分野の深さまたは専門知識(専門分野と同じではない )を持ち、複数の分野である程度の幅を持つ個人であるT字型のメンバーがあります。

T字型の開発者は汎用性があり、学習に熱心であり、目標はスプリントの目標であり、活用ではありません。 T字型メンバーは、顧客への価値提供に貢献する能力を常に高めています。

「スラッシュ」からの脱出

コンテキストの切り替えの背後にある隠れた優先順位を回避するのに役立つ可能性のあるいくつかのメトリックを検討してください。 これらおよび他のものは、利用と個々のサイロ化された貢献を合理化する代わりに、提供される価値に貢献する行動を奨励することができます。 以下のそれぞれは、「 測定対象に注意してください…」で詳しく説明されています。ブログ:

• 投資収益率 (ROI): 新しい機能を提供するときに、望ましい価値と意図された価値が実際に実現されますか? 投資収益率を生み出すために、新しい価値がどのくらい早く、どのくらいの頻度で提供されますか?
• 生産の欠陥:欠陥が生産に上陸している場合、その理由を知っていますか? あなたが実際に「出荷可能」を意味するためにあなたの完了の定義を満たしていない理由をスラッシングしていますか?
• スプリント目標の成功率: 忙しい仕事を提供し、多くの仕事を始めていますが、終わっていませんか? 顧客の目標に向かって取り組んでいますか、それとも異なるタスクに取り組んでいますか?
• リードタイムとサイクルタイム:終了するよりも始める必要がありますか?
• スキルの多様性: 開発者はスプリントの目標に貢献する能力を継続的に高めていますか?

これらはすべて、作業を開始するのではなく、提供することに集中するのに役立ちます。 コンテキストの切り替えとスウォーミングのどちらかを選択する際には、コンテキストの切り替えは作業を開始することであり、スウォーミングは作業を完了すること、つまり早期かつ頻繁に価値を提供することであることを覚えておくことが重要です。

概して、顧客は完成した作業に焦点を合わせています。 彼らは使用できない機能を気にしません。 彼らは利用を気にしません。 そして、彼らはあなたがどれだけ早く始めることができるかを気にしません。 顧客は、どれだけ早く仕上げて品質を提供できるかを気にかけています。 スティーブ・ジョブズが言ったとされているように、「本物のアーティストは出荷されます」。

隠れた優先事項を明らかにするための支援を可能な限り効果的にしたい場合は、今すぐアドバイザーに連絡してください。