開発要望タスクの優先度が「高」ばかりで悩んでませんか？

CTO室相談室でCARTAの各部署の技術メンター・コーチをしている前田@brtriver です。

自分の仕事内容を説明するのが難しいですが、スタッフエンジニアでいう右腕です！

いろんな部署のサポートをしていると開発要望タスクのリストを確認する場面がよくあります。そして、その中の「優先度」という項目で正しく優先度をつけることができていない現場が多いと感じます。

そこで、今回はどのように「優先度」を考えればよいかについて私自身が意識していることをまとめてみるので、ぜひ一緒に考えてみましょう。

優先度が「高」だらけになってしまう

チケット管理において優先度が「高」だらけになってしまう現象を目にしたことはありませんか？

チケットは困ってる本人が書くため、基本とその優先度は「高」が多くなります。

チケットに残すために書いたとしても、優先度低いタスクはそもそもやらないという判断されることが多く、そのチケットが永遠と残るというのはよくある話だと思います。

結果として優先度「高」が溢れかえり、「真の高」を考える会が開催されることになります。 中には「高」の中でも、どっちのほうがより「高」なのかをランク付けし始める様子を見かけたことも...

そうなってしまうのは、 主観的な意見の往来になることが原因の1つ です。そのような状況を避けるためにはどうすればよいでしょうか？

本当に必要な開発要望タスクのリストを管理する方法は以下の3点だと考えます。

客観的情報の共有: 定量的な指標

理由: なぜそのタスクをやるべきなのか

タスクの鮮度: いつそのタスクが生まれたのか

では、細かく見ていきましょう。

優先度決定において大事なのは、それを 「複数人が見たときに同軸で判断できる情報」 です。多くの場合は「タスクが生まれた理由」のみが残されており、個々人が思いをぶつけ合うと空中戦を生む理由になります。

書いた人以外の誰かが見たときに「このタスクのほうが先にやったほうがいいよね」というのがわかるような情報を共有しましょう。

例えば以下3つがおすすめです。

ビジネス上の売上インパクトを端的に表現します。

「この機能があればXXの契約ができて売上がXXあがる」

「この機能があればクライアントからさらにXXぐらい予算を寄せてもらえる」

機能ができることで、 売上が伸びるのであればやった方がいいと判断しやすい です。クライアントとの折衝している場合は、「今月末までにできていたら契約できる」などの制約もあるはずです。

他社との差別化から優先順位を考えます。

「他社でこういうことができなくて困ってるという声が多いのがわかった」

「自社はこういうデータを見せれる。だから、XXXの通知ができればクライアントに訴求できるんじゃないか」

ここで大事なのは、以下の軸で 判断しないこと です。

やはり、 きちんとした仮説立てと検証は必要 です。

「毎日x時間スプレに貼り付けしている作業が自動化されてると別の仕事ができる」

「手動でテストしているのはテストを自動化することで、リリースサイクルを早くし多くの機能をリリースできる」

具体的に削減される数字が目に見えれば、合意形成と意思決定をしやすいです。既にかかっているコストを下げ、費用対効果が上がるならば優先度は自然に上がります。

「なぜその課題を解くべきなのか(Why)」を共有する ことも大切です。

Whyを深ぼる利点は2つあります。

Whyを深ぼった結果、すでにある方法や別の解決方法が見つかり、「そもそも対応しなくてよい」こともあります。

また、エンジニアがビジネスサイドに丁寧に理由を説明する必要がある場面もあります。たとえば、利用しているフレームワークのアップデートやEOL対応です。

ビジネスサイドは「対応したほうがいい」は分かってもそれがどれぐらいの影響があるのかはわかりません。もし数週間で集中すれば対応できるのであれば、すべての新規開発を一旦とめてアップデートに集中するほうが結果として近い将来に新規開発に集中できる可能性もあるかもしれません。

これも何故アップデートをしなくてはならないのか？の理由を具体的に共有できれば多角的な視点をもってチームで判断できます。

環境は常に変化し続けるものです。タスクを置いている間に、もっと優先度高いものが出現し対応すべき順番が変わる可能性は多々あります。

チーム全体で「最新情報を更新し続ける」共通の意識持てるとより強いですね。

これらの内容はエンジニアに限定した話ではありません。

ビジネスサイドの方にも同時に意識してもらえるだけで、解像度は大きく変わります。そして、優先順位も「全員」で客観的に判断できるようになるはずです。