こんにちは、SansanでCPOとしてプロダクトの責任者をやっている大津です。
実は私、今年の3月からSansan事業部の開発部長も兼務しており、大きな組織変更や仕組み作りを主導しました。その中でBacklogの1本化という取り組みもしたのですが、こちらについては開発部の尾部がすでに記事にしていますので興味がある方は是非。
buildersbox.corp-sansan.com
このときBacklogの優先度付けに向き合ったのですが、いくつかうまくいくためのポイントを学習できたので、今日はこのことについてお話したいと思います。つまり、何を開発すべきか優先度付けする際のコツをお話します。
優先度付けを行う際のポイントは以下の４つです。
- 予めリソース予算を把握しておく
- 必ず工数概算を出した状態で優先度をつける
- 起案者が優先度を決める展開を極力避ける
- 優先度はロジックではなく好みで決める
一つひとつご説明します。
予めリソース予算を把握しておく
多くの人が(特に非エンジニアが)開発の優先度をつける時、あたかも湯水のように開発リソースが存在すると錯覚してしまいがちです。優先度をつける前に、特定期間内に何人日分の開発リソース予算が存在するのかを必ず確認しましょう。
例えば、エンジニアが4人いるチームが3ヶ月(1Q)の間で開発に割くことができるリソース量はMAXで約240人日(4人*3ヶ月*20日)です。
現実的には、会社やチーム単位での会議に当てる時間や現在提供しているプロダクトの運用作業などにも時間は割くはずなので、新規開発に割けるリソースとなるともっと少ないでしょう。工数の6割を新規開発に割く、と決めたとすれば、Backlog用のリソース予算は144人日(240人日*0.6)。
これをしっかり把握しておくことが、この先で行う優先度付けには非常に重要なのです。
優先度とは基本的に相対的なものです。やるのかやらないか、それを決める行為です。
しかし多くの人は優先度を高、中、低など概念的なラベリングをするだけに留めてしまい、結局やるのかやらないのかうやむやにしてしまいます。リソース予算が把握できていれば、優先度決めにおいてはっきりと「やる」「やらない」を判断することができます。
買い物をするときも予算が決まってないとただのウィンドウショッピングで終わりがちですよね。予算を決めることが意思決定を大きく後押しします。
必ず工数概算を出した状態で優先度をつける
上記の予算の話と対になる話ですが、必ず起案されたBacklogは優先度付けに向き合う前に工数概算を行う必要があります。
つまり各商品に値札を貼るような行為ですね。
そもそも工数概算を出せないような不明確なBacklogは優先度付けの対象にすることができません。なので、起案者は工数概算できるレベルまで詰めた上で優先度付けに備える必要があります。もちろんBacklog全てがそこまで詰まってなくてもいいですが、少なくとも「特定期間の優先度付け対象にするもの」に関しては優先度を決める日までにしっかり詰めて準備する必要があります。
ここでエンジニアなら「画面が決まってないのに概算なんてできない」と言い出しそうですが、もちろん概算なのでピタリと当てる必要はありません。ただ、エンジニアとして経験を積んでいるうちに、10人日程度なのか30人日程度なのかくらいのレンジでは言い当てられるようになるものです。
とにかく優先度付けの対象とする全てを工数概算することが非常に重要です。
起案者が優先度を決める展開を極力避ける
察しの良い方は上の２ステップを理解した上で「つまりリソース予算と各工数概算を照らし合わせながら対象期間に何をやるか決めればいいんだな」と感じてくれていると思います。
まさにその通りで、その仕組みこそが私の考える開発優先度決めです。
実は弊社の開発優先度には３パターンしか存在しません。
- 高：今クオーター中にリリースする
- 中：次クオーター中にリリースする
- 低：リリース時期が決まっていない
つまり、工数概算がなされ、予算に当てはまったものが高や中になり、その他煮詰まっていないものは全て低とされます。
定期的に「優先度決めイベント」的なものが開催され、起案者はそれに向けて担当している案を煮詰めて持ち寄るといった向き合い方がなされます。
ここで大事なこととして、できれば「優先度を決める人」は起案者とは別にしてください。理由は簡単で、冷静にやるやらないを判断するためです。
当然ですが、起案者はその案に思いもありますし準備にも時間をかけてきています。その状態で本人がその案をやるかやらないか判断すれば、当然やる方向にバイアスがかかります。
できれば起案には一切関与していない立場のリーダーが、話を聞いた上で冷静に判断することが望ましいです。
優先度はロジックではなく好みで決める
最後に、結局やるやらないをどのポイントで判断すべきかについてです。
起案者とは別に「優先度を決める人」が誰か決まったなら、あとはその人が各起案者のプレゼンを聞いて「好み」で意思決定するのが一番良いと考えます。
もちろんものによっては説明的なものを語っても良いかもしれません。ただ、基本的にその人の好みで判断されているのだと思う方が場はまとまりやすいです。
多くの人は優先度付けにおいて、スコアリングやロジックなど説明できる武器を求めますが、その武器は諸刃の剣でもあります。つまり全てをそのロジックで説明しないといけませんし、そうじゃないものは「やる」と出来ないということです。臨機応変な意思決定が阻害される要因になります。
また、ロジカルなものはロジカルなものに論破されたり反論されたりします。
例えば「部長が優先度を決める」とみんなで納得したとしましょう。しかし肝心の部長がロジカルに優先度付けを始めると周りのみんなが「でもこういうロジックならこうなるのでは？」と反論や論破を試みます。「部長が優先度を決める」とみんなで決めたはずなのに、そんな展開になるのはなぜでしょう。こうなるとまとまりが出ませんしコミュニケーションコストが増します。
「部長が優先度を決める」と決めたなら、それは部長の好みで決まるんだと思う方がみんなにとって心理的に安定します。そして、それで納得できるような人を「優先度を決める人」に選任すべきです。結局リーダーシップとはそういった意思決定で求心できることを言うのだと私は思います。
誤解して欲しくないのは「好み＝何も考えていない」ではありません。
もちろん好みで決めているとはいっても、その人はいろんな背景を知り、広い視野の中で様々な話を考慮して決めるべきです。ただ、それを説明にのせるコストは必須ではないでしょう、と言う話です。そのコストはする側もされる側も本当にコストでしかありませんので。
以上が、私の考えた開発優先度の決め方です。いかがだったでしょうか？
もちろん決め方に正解は一つという訳ではないですから、こういう決め方もあるんだなと参考になれば幸いです。
今後もSansanはより良いプロダクトをお届けできるよう全力で開発を進めてまいります。
buildersbox.corp-sansan.com
buildersbox.corp-sansan.com
buildersbox.corp-sansan.com
