優先度順にタスクをやらない
どんな話？
インパクトの大きい機能開発を上から順にやっていくと、ユーザー体験や、開発者体験、コードの品質がおざなりになっていき、その結果ユーザーは離れ開発効率も下がり、スピードも落ちていくのでは、というお話。
背景
こんなことが多い。
- タスクをバックログなどで管理していて、それぞれに「優先度」をつける
- 優先度順でタスクをソートする
- タスクは上から順にとっていく
僕らのチームでは2番の箇所が違っていて「優先度」ではなく「やる順番」でソートしている。
どういうことなのか。
そもそも優先度は何によって決定しているのか？
インパクト（それによって生まれる利益）ベースであることが多いのではないだろうか。
つまりそれによってどれくらいの利益が生まれるか。
機能開発をすることで月1万円しか儲からない機能より100万円儲かる機能の方がそりゃあ優先度は高くなる。
機能開発ではなくバグの場合でも影響範囲によって決まることが多い気がする。
インパクトがでかいゴールデンパスだったら早めに治すが、回避策があったり影響が小さいものは後回しになるかもしれない。
ここに関しては異論はない。
余談
バグの優先度を決めるのに戸惑っていたときに「そもそもバグがある状態は仕様を満たしていない。その程度だったらさっさと直してしまった方がいいじゃないか」という意見をいただいたことがある。
当然といえば当然なんだけど「そもそもバグがある状態は仕様を満たしていない」という言葉がとても好き。
優先度によって並べることの弊害
結論から言うと「ユーザー体験や、開発者体験、コードの品質がおざなりになっていき、その結果ユーザーは離れ開発効率も下がり、スピードも落ちていく」というのが弊害。
主に技術負債の解消系は後回しにされがちだったりする。例えば以下のようなもの。
CI/CDの改善
PlaywrightのCIの実行時間長いな〜。けどGitHub Actionsで何回もテストしてキャッシュの設定したり並列化するのを頑張るの面倒だし時間がかかるだけだから後回しにしちゃおう
- テストがどんどん膨れていってCI待ちの時間が多くなって開発スピードが遅くなる
- 開発者もストレスだし、リードタイムも遅くなる
依存ライブラリのバージョンアップ、それに伴うリファクタリング
バージョンアップデートしなきゃだけどそれに伴ってバグ出てるからめんどいな。これも後回しにしちゃおう
- 新しい技術を導入したいが依存関係の問題で導入できない
- 最新のバージョンまでメジャーバージョンが2つ以上離れてしまっていて今からじゃ簡単にバージョンをアップデートできなくなってしまった
UIの改善によるUXの向上
ここ絶対使いづらいからここをこうした方が絶対に良いと思うけど、機能開発の方が優先度高いから後回しにしちゃおう
- エンジニアが言うUX系のフィードバックはユーザーからなかなか返ってこない
- 機能がなくて不便系は言語化してもらえることが多いが、全体を通したUXはユーザーが言語化しない
- UXが悪いがそれが当たり前のプロダクトになるのでユーザーが学習して悪い意味で不満が出てこなくなるので改善しなくなる
ディレクトリ構成
開発者の人数も増えてページやコンポーネントが増えてきてディレクトリがごちゃついてきたぞ...。まぁ動いているし今はこのままでいいや
- 新しく機能を追加するときに修正箇所が多くて時間がかかったりバグが発生する
いやいや、そうは言っても機能開発が大事！なんせビジネスはスピードが命なんだ
スピードは常に求められる。
そして、品質が落ちればスピードも落ちる。
スピードを大事にしたければ「優先度が低い」タスクもやる順番は上に持ってこなくてはいけない時がある。
逆で、愚直に「優先度順」にやってしまうことで品質は落ちるので中長期的にスピードは落ちる。