優先度の罠

複数選択が最善の選択肢か？

Photo by Filip Mroz on Unsplash

Priority セレクトボックスの罠

とあるスタートアップの物語

どの会社でも必ず、Jira管理者が解決策を提案するものだ。ほら、Priority フィールドのドロップダウンだ！（エンタープライズ開発者へのヒント：Priority2 や P-level と呼ばれることもある。）

不思議なことに、どの会社も P1, P2, P3, P4 か Low, Med, High, Critical のどちらかを選ぶ——どうやら他の選択肢はないらしい。

4つの固定オプション？よし、数週間試してみよう……

2日後

誰も驚かない展開で、組織は新しい、より高い優先度を持つチケットを発見し、マイナーなハックが必要になった：P0、または Critical Max+ を追加する！

さらに3日後

私たちの勇敢なボスは、カンファレンスでいくつかのエキサイティングな会議と発見をした！

なんと P0 よりもさらに高い優先度を発見したのだ！

それ以来、チームはこの新しい優先度をどうラベル付けするかを頭を悩ませて研究してきた。

-1 はどうだ？いや、いや。それは混乱を招く（P-1 と P1）。よし、P0.5 は？いや？

「ひらめいた」瞬間、チームはより高い優先度を発明した：ダブルゼロ！
今や P00 優先度として知られるものだ。

洪水の前

誰も気づかないうちに、あなたのチームは P00 チケットに溺れている！

優先度が複数選択でなかったら？

Priority のような常に変化する流動的な人間の概念を、どうよりよく表現できるだろうか？

• 現実の世界では、優先度は新しい情報、市場の変化、組織の目標に基づいて常にシフトし進化する。
• 緊急性、重要性、リソースの可用性、コスト/リスク分析の間の複雑な相互作用があり、単純なドロップダウンでは捉えきれない。特に時間が経つにつれて。（チケットの腐敗。）
• 異なるステークホルダーは、何が高優先度に当たるかについて相反する見解を持つ可能性があり、画一的なアプローチは不適切である。

では、次に何をする？

低 effort から高 effort まで、いくつかの代替アプローチを探る価値がある：

• より多くの余地と拡張性を持たせるために、「中立」な開始値、例えば 100 や 1,000 から始める。数値は常に増減できる。
  • またはゼロから始め、数値が大きいほど優先度が高くなるようにする。
• ビジネス価値、緊急性、必要な努力などの要素を考慮する多次元優先度システムを実装する。（ソートとフィルタリングを簡単にするために composite スコアを作成する。）
• MoSCoW手法（Must have, Should have, Could have, Won’t have）などの動的優先度付け手法を採用し、定期的な再評価を可能にする。（カーノモデルも参照。）

まとめ

優先度には多くの重きが置かれるが、その劣化速度は速い。昨日の CRITICAL チケットが来四半期にも CRITICAL である可能性は低い。

時間が経つにつれ、古い高優先度チケットはクリーンアップやメンテナンスに抵抗を持つようになる。結局、一度 必須 と宣言されたものの Priority を下げたいと思う者は誰だろうか？ましてや関連性のなくなったチケットを削除するなんて……（げっ！バックログを考えてくれ！）

複数の会社で Severity と Priority を混同しているのを見てきた。Severity は 緊急性（または時間的感度）を記述するものだ。

Priority ≠ Severity。3〜5の重大度レベル（サービスレベルアグリーメントの維持に使用されることが多い）を定義するのは理にかなっている。

緊急性のレベルは、顧客への影響ゼロ から 部分的/完全なサービス停止 までのコミュニケーションに役立つ。

注意事項

無制限の優先度フィールドを導入するには、少しの計画と規律が必要だ！

フロントエンド開発に詳しい人なら、z-index 戦争を経験したことがあるかもしれない。

基本的に、z-index を使うとデザイナーは任意の正の整数を設定して、自分のウィジェットがより低い z-index のコンテンツより「上」に表示されるようにできる。

マイナーなコンポーネントのアップデートでさえ、<Dialog /> の z-index に変更を加え、突然見えなくすることがある。サードパーティのコンポーネント、機能作業、その他のチームの貢献が互いに z-index で競い合うにつれ、これらの状況は厄介になる可能性がある。

Z-index はかつて約32,000に制限されていた。しかし、最近、10億の z-index: 1000000000 を持つスニペットを見た！

インフレは z-index にひどく影響を与えているに違いない。

議論

• これは価値のある思考実験か？
• 優先度が無限に増加していく考えは恐ろしいか？不安を誘うか？
• このアプローチが最終的に64ビット整数の制限を超えるのは避けられないか？
• Severity や Urgency 以外のフィールドはこの会話に貢献できるか？
• Jiraはどれだけの非難に値するか？それとも称賛に値するか？

インターネットに向かって「誰がすべての P00 チケットをクリーンアップするんだ？」と叫ぶこともできる。

それとも、バックログに 本気 になれる。

• 1,000チケットの90%は決して実行されないことを受け入れる。それでいいのだ。
• 数ヶ月間手がつけられていないチケットをアーカイブする。初期の優先度/緊急性はもはや適用されない。とにかく、アーカイブされた issue は多くの場合復元できる。
• issue が戻ってきた場合、それはクールだ；優先度が増しただけだ。
• 経験的に、古くて未完成のチケットを破棄しても害はないことに気づいた。
• バックログをデータベースのように無限に追加し続けることは、チームと組織を重要なことに集中させる機会を逃している。（私たちの前にあること。一方、バックログは本質的に過去を振り返る。）
• 深いバックログはビザロートロフィールームのようになり、決して出荷しないものを祝うことになる。