おそらくは既知の話題。
古きよきIssue管理システムの各チケットにはたいてい「優先度」という属性があった、ある時代があったようにおもう。
これはやめましょうねという話。
だいたいこの手のシステムだとIssueをあげた本人、あるいは連絡を受け取った人がその場の雰囲気で「優先度: 高」とかをつけて、そこから開発チームがスクラムイベントとかそういう場でそのチケットの「優先度を判断」することになる。
チケットにはすでに優先度が付与されてるのに優先度を判断ってどういうことだよあーっ！？ 優先度: 高 のラベルがついてるんだから最優先でやれッッ！！ あの……優先度が高いチケットはすでに100枚くらいあるんスけど、最優先ってことは他のは優先度低いってことっスか？
どうしてこういう問題が生じるのか？
それは優先度、というそのIssue単体で機能しない概念を、しかも全体観を把握していない個人が主観で付与しているのが原因である。
Issueが主観で書かれているのは正しい（もちろん発生している事象が客観的に記述されている必要はある）。
しかし優先度は現場が相対的に評価するもので、なおかつ流動的に変動するものだ。
「低、中、高」みたいな粒度で管理できるものではない。
さらに現在一番人気のプロジェクト進行フレームワーク（の割にあまりにも無知やいい加減な運用が目立つことで有名な）スクラムでは、基本的にチーム一丸となってチケットを最優先のものから一つづつ片付けていくことになる。そしてその優先度を毎スプリントごとに流動させることをよしとするフレームワークだ。
優先度: 高 みたいなチケットが100個くらいあると話にならない。それに開発者以外の人間があげるチケットは、実際に本人が困っていてどうしようもないから報告するので本人にとっては全て 優先度: 高 なのだ。
「ビジネス側の人間は全部優先度最高でチケット作るから云々」
みたいな定番のネタがあるが、現場がプロジェクト進行の権限を握れていないのが問題の本質だ。
優先度にかわる属性
じゃあどうすればいいのか。
優先度という意味不明、測定不明な概念を報告者に使わせなければ良い。
ここでは仮に、「緊急度」と「重要度」という概念を推奨しておく。
緊急度
「緊急度」は文字通り、どのくらい差し迫っているか。絶対的な納期が近い、あるいはハイリスクの真っ只中にいるかどうかだ。
例えばユーザーの操作が途中で中断されてしまうようなバグ。これはアプリの価値の根本を損なっており、明らかに緊急だ。こういったメインフローのクラッシュなどは「超ヤバイ」的な特製のラベルで管理することをおすすめする。
あるいは脆弱性があったモジュールのセキュリティアップデートなど、これも万が一のリスクを考えれば緊急度は高い部類にはいるだろう。
逆に、利用しているフレームワークのEnd of Lifeが近い……などは緊急度が低いタスクの典型になる。
なお緊急度の管理も、優先度ほどではないが時間と共に変化する可能性が高い。納期に余裕があるタスクは最初「低」で切っていたが、納期が迫るまで放置されれば「高」となる。
一定期間ごとにチケットの振り返りは必要だろう。
当然、手持ちのリソースを大きく超える量の緊急タスクが発生する可能性はある。
その場合は何かを削る判断が必要だ。これをトリアージと呼ぶ。
削るのは他の要望かもしれないし、社員を徹夜させることですり減っていく何かかもしれない。
偉業とは犠牲なしに達成できないが、血が流れすぎると本体が死んでしまう。このヒリつくリソース配分の感覚が戦略ゲームの醍醐味ってわけ。
重要度
「重要度」はこれも文字通り、事業における重要性だ。
この重要度は先の「優先度」に似て、報告者の先入観によるabuse、そこから生じる部門間の不信感などの原因になる可能性もあるので各組織ごと、慎重にルールを定めよう。
重要度は金額で数値化（フェルミ推定的な計算になるが）するのがシンプルでよい。
例えば、非常にわかりやすい例で言えば圧倒的な競合優位性を生む新機能開発だ。貴方の会社がスタートアップなのであれば、ここの重要度は常に「最高」となる。ユニコーンを目指すのであればここの評価値は常に無限大だ。
同様に、チャーンレートが高いサービスで重要顧客の不満を解消してあげる重要度は非常に高い。
逆に……例えば「デザインがちょっと使いにくい」「ちょっとしたバグがある」こういった事象の重要度は「低」（おおブッダ！寝ておいでですか？）となる。
みんなが普段使ってるサービスでいつまで経っても放置されてるバグ、ありますよね。「簡単に直せるやつだろ！！いつまで放置してんだよマジで」っておもうやつ。理由はこれ。
人はプログラミングやデザインに詳しくなければ詳しくないほど、しょうもない重要性の低いバグやUIの大きさにこだわる習性がある。自転車置き場の法則。
全部重要だろ症候群を避けるためにもここのルール付けは各々厳格に頑張りましょう。
ただし、ちょっとした瑕疵のようにみえていたものがチャーンの最後のひと押しになっていたり、サポートコストを増大させていたり、セキュリティリスクの遠因になっていたりする。デザインのダサさがブランドを毀損している可能性だってなくもない。
この辺に絶対の解答はなく、それぞれを正しく評価し運用するのがPMの能力なのだ。頑張りましょう。
最初にも述べた通り、納期という絶対基準がある緊急度と比べてこちらは濫用されやすいことに留意する。
あらためて優先度を考える
考える前に……
実装コストという第三勢力
そのチケットの解決に必要なコストを見積もろう。
実装コストはチケットの相対的な優先度を考えるうえで非常に重要なファクターとなる。
当たり前だがこの3要素をかけあわせて自動的に優先度を出す仕組み……なんてものはない。変数が多すぎるからだ（事業のタイプ、会社の資金状態、開発リソース、プロダクトの健康状態……）。
こういう物事にいい加減な結論を出す文書が欲しいならビジネス系の啓蒙書を読もう。
ただ、たとえば緊急度は低いが重要度は高いタスクがあったとしよう。
この実装コストが13とかであれば優先度は下がる。コスパが悪いからだ。
じゃあ実装コストが3だったら……？おそらく優先度は中くらいだろう。そのスプリントでやるかどうかは怪しいレベルだ。
ではもし、実装コストが3だが、手持ちの他のタスクで緊急度が高いタスクがない場合を考えてみよう。この場合、重要度が高いうえに簡単に片付くタスクをあらかじめ処理しておくのは大変コスパが良い行動となるだろう。
もうひとつ考えてみよう。
緊急度も重要度も最高のタスクだ。ただしコストは非常に重たく13だ。
事象としてはアプリの操作中にクラッシュ。どんなに重たくても最優先だろう。
ただし……残念なことにもうひとつ喫緊のタスクがあった。
こちらは主要顧客からの機能追加要望。この顧客は貴方のアプリの使いにくさに対してフラストレーションが溜まっており、ここらで挽回しないとチャーンしてしまうリスクがある。困ったことに駆け出しの貴方の会社にとって一番の大口顧客であり、解約は痛手を超えて倒産のリスクすら呼び込む。
さて、どちらを優先すべきだろうか*1？
これは極端な例で、経営判断に委ねる形になるだろうが開発部というのはIT企業のコストセンターでありボトルネックなので大なり小なり近いトリアージを積み重ねてタスクをマネジメントしているのだ。いやしくもエンジニアを名乗るのであれば、仮に末端の人間であってもこの手の思考訓練は日々積み重ねる必要がある。見積もりとリソース配分の計画は問題解決の本質だ。
さらにもうひとつ、ややこしい問題を投下してみよう。
緊急度も重要度も低く、コストもそこそこなタスクだ。
そんなものやる必要があるのか……？
ただし、現場の人間のモチベーションが非常に高いとしたら？
これは難しい。が、貴方が管理しているのは規格化された歯車ではなく人間だ。
貴方は人間の熱意、そして納得も考慮してマネジメントしなければならない。
完全に信頼して放任する？20%ルール、定期的なハッカソンの開催などで管理する？社会人として飼い慣らすよう教育するべきか？
ここに正解はなく、その判断は各組織にゆだねられる。
つまり優先度付けは難しい……？
これがチケットの属性に「優先度」を設定することの難しさとなる。
開発者が実際に見積もりをする（そして見積もりというのはベテランでも失敗しやすい芸術的技能だ）まで優先度を考えることはできないし、見積もりが済んでいてもプロジェクトの抱える他のタスクによって簡単に変動する。
ここまで書いたが「タスクの優先度付けをする」という行為は限りなくプロダクトマネジメントのエッセンスに近い。
まず事業戦略を頭に入れ、顧客や社内の要望を整理し、対処に必要なコストとそこから得られるリスクやリターンを判断することができて、はじめて正しい優先度付けの足場が作られる。
そして優先度というのは単体でひとりよがりに決めたところで絵に描いた餅のようなものだ。社員の能力やリソースを把握して、実際にそれがどう消化されていくかまで考えなければならない。優先度とはイコール計画だ。
ラプラスの悪魔めいた未来予測やめろ、そんな完璧にできるわけないやんけ。
つまりそういうことで、世の中のマネジメントはだいたいクソだが、管理がクソでも現場が機能不全に陥らない程度のクソさならタスクは消化されていく。
「AとB、どちらが優先度が高い？」
この設問に正しく回答するのは非常に難しいが、間違えたところで事業にダメージがはいるようなことはまずありえない。事業戦略レベルのミスに比べれば屁みたいなものだろう。
繊細な優先度つけに数十回程度間違えたところで会社が潰れることはないだろう……いずれにせよ緊急度のタスクは現場が拾うのだ。
ただし、マネジメントに失敗しつづけている間に少しづつ組織の歪みは進行する。
事業と現場の感覚は乖離する。無力感、閉塞感が支配し仕事がうまくいかない理由を他部門に求めるようになる。
人が仕事に絶望し、辞めたり病んだりするのは忙しいことが本質的な理由ではない（異常な残業とか、限度はありますよ普通にね）。
自己効力感が得られなくなったとき、人は飽きたり病んだり辞めたりサボったりするようになる。
過剰なタスクを与え続けてオーバーフローさせると、その人の頭には失敗が残り続ける。そのストレスから能力が下がり、根本的な処理能力が下がる。そうして自己効力感を失うと人はやる気を失うのだ。
経営者がハードワークに耐えられるのは自己効力感のブーストが凄まじいからだ。まさに一国の主人として権力を振るう感覚が常人を超えた働き方を支え、その人の限界を迎えて強制バーンアウトするまで動かすことができる。
マネジメントは事業にもたらす金銭と、組織の構成員にタスクのオーナーとして持たせる自己効力感のバランスのマネジメントなんだろうなとこの記事を書いていて気がついた。
即効性に欠けるだけで、いわゆるブルシットジョブではない。なのに現場どころかマネージャー本人からすら軽んじられている傾向にあるのがマネジメントだとおもいますまる。プレイングマネージャーとかいうプレイもマネジメントも中途半端なんだけどリソースが足りなすぎるが故の必要悪存在が消えて組織は成熟したと呼べるのかもしれない（そうかな？）。
そしてこの気付きは資本家と労働者の利害は一致しない（対立するとは限らないが）という考え方に根ざしており、世の中のむそ…理想家たちには受け入れられない洞察やんけとおもいました。
おしまい
*1:そんな状況に追い込まれていることそのものが問題だって？そりゃそうだ
