はじめに
ベンチャー企業でテックリードやってます（強くなりたい）
なんて言いつつ、10月からPO業務（というかPdM業務というか）をやっている野澤です。
最近仕事をする中で、issueについてとても悩むことが増えたなということを感じているので、そのことについて書こうと思います。
もっといい考え方やベストプラクティスなどあったら教えていただけると嬉しいです。
issueの優先順位「低」って一生取り組めなくないか！？
はい、まずこの問題です。
例えば機能Aを開発が終わって、スプリントレビューをした時に「もっとこうしたほうがいいね」という機能A2の案が出て、一旦issueに切ったとします。
この機能A2っていうのは、機能Aの改善点として出たもので、それ単体としてみたら、提供される価値は少ないです。
他にも開発すべきissueで機能Bがあったとして、そっちの方が提供される価値があるのであれば、機能A2のissueは後回しになって、機能Bのほうを優先して開発していきます。
この考え方は正しいと思うのですが、最初はモヤモヤしていました。
- そういう考え方だったら、スプリントレビューで出た改善点とかって一生取り組まれなくないか！？ それだったらあんまり改善する動きをしてもあんまり意味がないんじゃないか！？
- こういう小さな機能改善が、プロダクトの品質を良くしていくのではないか？（逆に塵積で、使いにくくなっていくのではないか？）
という点で引っかかっていました。
ただし提供できる価値の多い順で開発を進めていかなくてはいけないので、これはしょうがないんじゃないかなと今なら納得できます。
もし本当に必要であれば、本当に優先度が高いのであれば、いつかやる時がくるのです。
もしやる時が来ないのであればそれは結果的に優先度低でよかった、もしくはやる必要がなかったというだけのことなのです。
（Webアプリ、スマホアプリを使っていると、絶妙に使いづらいなと思ったりすることあると思うのですが、こういう背景があるのかもしれません。。。）
issueの優先順位つけるの難しくないか！？
悩んでいた頃（改善前）
僕自身PO業務を開始したのは2023年の10月でした。
過去のプロダクトバックログを見た時に、メンテされていないものも多く、
最初は全部を正確に提供できる価値順に並び替えるぞ！と意気込んでいました。
最初は書籍【プロダクトマネジメント】に書いてある、遅延コストの定性的評価をしようと思いました。
価値を1、2、3で、緊急性を1、２、3でつけて、合わせて6であれば最高、2であれば最低 として、その定性的評価の順番でissueを取り組むことができれば効果的に開発を進められるのではと思いました。
そして価値や緊急性を明確にするには、そのissueの課題や要求、アウトカムを明確にしないといけない！となり、必死に定性的評価をしていたのですが、issueの数が多く、物理的に無理でした。
この時に感じたことは
- 時間がかかりすぎる。。。
- 本来ぱっとみても優先度「低」なのにも関わらず、課題や要求、アウトカムを明確化し、価値や緊急性をつけて定性的評価をするのは時間がもったいない。。。
- そもそもここで明確化しても、時間が経てばユーザーの要求や、プロダクト自体のコンテキストは変化してしまうため、この価値や緊急性の値は常にメンテナンスをするコストがめちゃくちゃかかりそう。。。
ということでした。
ここでの自分の誤りは
- 全てのissueをちゃんと正確に並べ替えないといけない
と思い込んでいたことでした。
そこで考え方を見直しました。
改善中
まずは、前提として
-
- 最終的に今スプリントで何に取り組むかはチームで決める。2. どんなに正確に優先順位順に並べ替えられたとしても、それはその時点の優先順位順であり、時間が経てば要求やプロダクトのコンテキストの変化によって結局この優先順位は変わってくる。
- 1、2より全てのissueを正確に優先順位順に並べ替える必要はないと考える（正確に並べなくてもいいんだという認識を持つ）
- 思考などの時間をかけるべきは優先度「高」であるもの
- 早い段階でissueに対して、課題や要求、アウトカムを明確化してもそれは時間が経てば変化していく。だから必要なタイミングで必要なことを明確化していく。
という気持ちでいることにしました。
プロダクト開発を進める上では、優先度「高」のものだけ取り組めていればよく、issueの優先順位やissueの詳細（課題や要求、要件）に関しては時間が経てば変化していく物なので、必要なタイミングで必要なだけコミットするということを意識するようになりました。
そして優先度「高」「中」「低」の捉え方を変えました。
というのは具体的には
- 高：プロダクトとして直近考えて（対応して）いかないといけないもの。10個固定（ここの個数は一旦仮置きでおいてみてます）。基本この10個がプロダクトの重要関心事。
- 中：高の次に考えていかないといけないこと
- 低：基本考えなくてもいい（考えない）
というふうに捉えることにしました。
そうすると、おぼろげに（？）優先順位が見えてくることに気づきました。
issueが追加されてその後並べ替えるまでの流れを具体で上げると、
- issueが追加される
- issueに関して優先度「低」「中」「高」をそのissueを完了した時のことを想像しながら価値提供の度合いと今のプロダクトのコンテキストを鑑みて決める（issueそのものの理解ができていない場合は、理解できるようになるまで優先度はつけない）
- 優先度「高」のissueを10個に保っておく（ここの個数は一旦仮置きでおいてみてます。プロダクトの文脈で考えていかないといけないと思っています）
- 優先度「中」のissueを優先順位高い順に並べておく（ここも「中」のissueに対して、2. の時と同じ物差し。ただしそんなに時間はかけない。）
- 優先度「低」のissueは基本何も考えないが、かなり直感で良いので優先順位高い順に並べておく（ここも「低」のissueに対して、2. の時と同じ物差し。ただしそんなに時間や労力はかけない。）
- スプリントプランニングなどで「高」 のissueが減ってしまった場合は、優先度「中」の中から「高」を選び補填する。
- 優先度「低」の中で「中」に挙げた方がいいものがないかどうかを確認
というふうにやってみています。
Q：なぜ優先度「高」に対して、そこまで順番にこだわっていないのか
A：プロダクトとしての重大な関心ごとさえ明確にすることさえできれば、それをどういう順番で解決していくかは、チームで話し合いながら決めることができると思っているのと、めちゃくちゃ悩んで時間をかけて順番を並べ替えたとしても開発チームの状況などで必ずしもその順番で取り組めるかどうかは不確実だからです。
（実装の都合でこっちを先にやった方がいいっていう場合も多々あったりもするので。。。）
Q：なぜ優先度「高」を10個に保っておくようにしているのか
A：プロダクトの重要な関心事を明確にするためにあえて制限してみてます。
制限をしないと優先度「高」がいつの間にかたくさんになってた。。。これってどれが本当に優先度高いんだっけ？というふうになりそうだと思ったためです。
あとはプロダクトの重要な関心事のメンテナンスを定期的にしていく意味合いもあります。
常に優先度「高」は10個にしておくというルールを設けることで、優先度「高」のissueの対応が終わった後（優先度「高」のissueが10個から9個、8個、7個と減ったタイミング）に毎回優先度「高」のissueを補填するために、今のプロダクトの重要な関心事ってなんだっけ？と考えることになります。
こういう考える機会を定期的に発生させるように設計してみてます。
Q：優先度「中」で優先順位高い順に並べておくのはなぜか
A：優先度「高」のメンテナンスのためです。
Q：なぜ優先度「低」「中」のissueの優先順位順の並べ替えに時間をかけないのか
A：理由はそもそも「低」と判定した時点でそれは現時点で「高」である可能性はほぼ限りなく0で、大きく見誤っていたとしても「中」だと思うので、そんなにここに時間をかけなくてもいいだろうと考えていると、重要なのはプロダクトとしての重要な関心事である優先度「高」を明確化することだと思っていて、その過程で優先度「低」「中」が正確に並んでいなかったとしても影響は少ないかなと考えているからです。
一旦このような考え方でissueと付き合っていこうと思っています。
（他に何かissueの優先順位づけとかの方法や考え方があったら教えてください🥲）
結果的に優先度低かったからissueを消すっていう考え方があまり受け入れられなかった
自分がPO業務をやるようになってから、かなり昔に登録されていて全く手をつけられていないissueがたくさんありました。
これらが優先順位「高」とか「中」でいたりしたので、考えることがぼやけるなと思い、長い期間手をつけられていないissueは、優先度が結果的に低かった（アイゼンハワーマトリクスでいうところの第4領域）とみなし、一旦キャンセルをすることにしました。
一定期間キャンセルしてからも戻すことができるのと、issueの管理にLinearを使っているのですが、Linear自体が全く手をつけられていない（ここの期間は設定がおそらくできたはず）issueを自動でキャンセルする機能を持っていたので、思想としてそういうことなのかなと思いキャンセルを実行しました。
あとは本当に優先度が高いissueであればたとえキャンセルをしてしまったとしても、また開発を進める中でチームの中で課題が出てくるはずですし、ユーザーからのお問い合わせやご指摘がくるはずです。
そういう前提のもとキャンセルをしたのですが、キャンセル実行後に、中には重要なものが入っている可能性があるのでキャンセルしたものを確認させてください。。。というふうにご指摘をいただきました。
いくら先ほどあげたようなコンテキストがあったといえど、事後報告になってしまったのは本当に良くなかったなと思っています。。。
自分の気持ち的にはキャンセルしたものは結果的に優先度は低かったということですし、本当に重要であれば再びissueに上がってくると思うので、キャンセルしたものの確認はしていただかなくても大丈夫ですよ。。。という気持ちではあったのですが伝えることはできませんでした。。。
この事象を考えた時に、
【思考の中の重要度】と【結果的な重要度】というような二つの考え方がありそうな気がして、前者の【思考の中での重要度】が高く、【結果的に重要度が低かった】issueを削除するのはかなり心配になること、受け入れ難いことなんだろうなと感じました。
冷静に考えて、頭で考えてこれが大切だろうと追加したissueを【結果的に重要度が低かった】から削除しましたっていられて簡単には受け入れられないですよね。。。
これは同僚に指摘されて気づいたのですが、断捨離ととても似ているなぁと思いました。
断捨離をする時も、しばらくは使っていないものでも重要だと感じるものって捨てづらいですよね。。。
逆に重要、大切だと思っていた物が使われていないからって捨てられちゃったりしたら悲しくなりますよね。。。
今度からはissueをキャンセルする場合は、事前に理由や背景の説明などの共有をしっかりとしようと思いました。
最後に
PO業務を始めて、3ヶ月たとうとしていますが、いまだに何が正解なのかが全然わかっていなく（正解なんてない、もしくは組織のコンテキストによるとは思っているのですが）、本を読んで、考えて、試行錯誤をする日々です。
手を動かす機会が減ってしまったのでそのことは寂しく感じることが多々ありますが、その代わりに以前よりも視野を広くプロダクトの成長について考えることができているのでとても有意義な経験ができています。
プロダクトを通してたくさんの価値提供ができるように、引き続きプロダクトマネジメントの勉強頑張っていきます！