見出し画像

PBLはプロダクトにつき一つであるべきなのか？

ソル | 複業クラウド CTO

Another works CTOとして複業クラウドというプロダクトを3年間開発してきました。最初の頃はエンジニアとしてもがっつり手を動かしながら、最近ではPdmも育ち、Sprint単位よりもQ単位・期単位でよりプロダクト戦略を立てていく必要がでてきました。

そんな中で今回はPBL(プロダクトバックログ)はプロダクトにつき一つであるべきかという問題に自分なりの答えを書いていきたいと思います。

結論から言うとPBLはプロダクトにつき一つである必要はない。むしろ、一つで運用するのは難しいと思います。
なぜならプロダクトは目に見えている以上に複雑であるから。

例えばこれが自分一人が使うための家計簿アプリであれば自分が使っていくなかで必要な機能を拡張していけばいいと思います。
ですがこの家計簿アプリが世の中に使われているとしたら。
利用者が一般の方だけでなく、企業だったりも使うようになったら。
アプリ内に広告を出すことで収益を得るというビジネスモデルが追加されたら。ネイティブアプリだけではなく、Webブラウザ版も出たらなど。

そのようになっていくとプロダクトは複雑になっていきます。
一番分かりやすいのがステークホルダーの種類が複数になったとき。
広告出稿してくれる企業も、家計簿アプリを使うユーザーも同じくらい重要なユーザーではあるが、求めるものはまったく異なるものであり、
それらの要望を叶えるための順位を立てるのは非常に難しいことだからです。


プロダクト課題分類

わかりやすくするためにプロダクトの課題を実際に分類してみました。

  • NSM(プロダクトの重要な指標)を向上させるための開発
    複業クラウドで言えばマッチング数(複業人材を採用したい企業と、複業したいタレントのやりとり開始)を向上させるためのグロース開発

  • 顧客タイプごとの要望(複業クラウドで言えば企業とタレント)

  • 技術的負債

  • UI・UX改善

  • 社内要望

  • 収益のための開発

ざっくり分類してもこのような分類を行うことができます。
ではこれらが一つに纏まったときどのような問題が起きるでしょうか？

課題A (顧客要望)「有料ユーザーの多くがOOという機能を欲しいと言っている」
課題B (UI・UX改善)「使えはするが、若干OOのボタンが押しづらい」　
課題C (技術的負債)「初回ローディング時間が少し長い」
課題D (収益のための開発)「LPのコンバージョン率が低いので改善したい」

このような課題があったとき、各企業によってどの課題を一番上にするかは異なりますが、課題Bや課題Dが比較的優先度は低くなるとします。

たらればの話ですが、エンジニアが1,000人くらいいて開発が早すぎて常にPBLが枯渇状態であればこの問題は上からこなしていけばいいですが、それはプロダクト開発において有り得ないと断言できます。

さてPBLの優先度を課題A -> 課題C -> 課題D -> 課題Bという順番で開発していくことになりました。果たしてDとBは本当にCが終わった後に取り掛かることはできるのでしょうか？

答えはNoです。なぜならAの開発をしている間にDやB、場合によってはCよりも優先度の高いEやFが発生するからです。
つまりDとBはいつまで経っても順番がこないわけです。

PBLを課題分類ごとに作る

そもそもPBLを空にすることはできないから、優先度順に並び替えてDとBが解消されないことは正しいことではないのか？

たしかにその通りです。ですが分類ごとに見たときはどうでしょう？
顧客要望とUI・UX改善を比較した時に本当に顧客要望が上でUI・UX改善は無視してもいいものでしょうか？収益は大事ではないのでしょうか？
収益を重要視して顧客の優先度を下げるのは良くないこと、でも逆も正しくはない。

つまり、分類においては優先度はなくすべて等しく重要である。
技術的負債をおざなりにすれば、2年後3年後には開発速度は落ち結果的に顧客に価値を生み出すことはできません。課題分類ごとにPBLを分ければその分類ごとに優先度をつけ、並列処理で開発が行われるのでより本質的な課題解決に近くことができます。

実例: 課題分類とチーム戦略

Another worksではJiraを使って管理しています。
ダッシュボード機能を使って各PBLを一覧で見れるようになっています。

PBLダッシュボード
技術課題ダッシュボード

  • テーマ開発
    Q単位で立てる開発内容。現状課題や、経営方針などを加味して選定する

  • グロース
    「マッチングブースト(β版)」「求人自動生成機能」という二つの機能をよりグロースさせるための開発。

  • Core開発
    顧客要望や、NSMに関わるような開発。

  • UX遊撃隊
    UI・UXの細かい改善のための開発

  • LPO
    新規顧客獲得のためのLP改善開発

  • 技術課題ダッシュボード
    各リポジトリーごとの技術課題

PBLを複数持つことのデメリットとその対策

Q1. PBLごとに兼任が発生すると優先度が考えづらくなる

A1. 基本的には、兼任しないようにします。弊社ではUX遊撃隊・グロース・LPOは業務委託人材。技術課題、Core開発、テーマ開発は正社員中心のチームにしています。
ただ、人数の都合上特に正社員はどうしても兼任をしなければならない場合があるのでその場合は、技術課題ダッシュボード 20%、Core開発 80%みたいな感じでSprintの工数をパーセンテージで考えてもらうようにしてます。

Q2. グロースとCore開発のPBLで進捗に差がでることで、進捗のいいPBLが全体としては優先度低いものに取り掛かっているのではないか？

A2. PBLごとに人数の配分などを変えることでバランスを保つようにする。
PBLが空になることは前述の通りほぼないのと、あくまでその場でのチームではあるので、PBLの解散と再構築は定期的に行うのはありと考えてます。

まとめ

プロダクトの戦略は多種多様でいろんな意見もあるかと思いますが、
試行錯誤しながら自分のチームに合った方法や、組織のフェーズごとに色々変化させていくのがいいかなと思いました。

この記事が気に入ったらサポートをしてみませんか？