こんにちは。ユニファでプロダクトマネジメント組織のマネージャーをしているやまぐち(@hiro93n)です。この記事はUnifa Advent Calendar 2022の23日目の記事です。
今年学んで良かった技術は普通自動二輪免許でした。東名高速の渋滞で鬼の半クラを役立てています。
普通自動二輪免許。40代超えて新しい趣味ができたのと、Youtubeで学ぶのめっちゃ便利だなと言う気づきができて以前より視聴時間が増えた。#2022年に学んで良かった技術
— ymtk｜Takahiro YAMAGUCHI (@hiro93n) 2022年12月15日
今回はプロダクトマネジメントの悩みの中で頻出ワード「優先順位決め」について書いていきたいと思います。
14プロダクトを通して決める
ユニファのプロダクトは表に見えるだけで14種類。それぞれプロダクトに対しiPad版アプリ、スマホ版アプリ、Webブラウザなどの複数デバイス対応が絡んでいるので、成果物単位でのプロダクトで言うと軽く20を越えます。
各プロダクトに対し潤沢に開発メンバーがいるかというとそんなわけはなく、各々が複数プロダクトを見ているのが現状です。それはプロダクトマネージャーも同様で、ひとつのプロダクトの要求管理や機能実現推進をやればいいという話ではありません。
プロダクト単位での要求管理ももちろんしていますが、実現できるのはあくまでチームのキャパシティによるものです。これを無視した意思決定や整理をしても実際意味がないよね？と言うところで、優先度決めの中にはチームのアサイン含めた検討も含めています。
優先順位決めの目的
タイトルに2022とありますが、2021以前は実質トップダウンで優先順位が決まっていました。そうです。開発者目線で言うと「決まっていた」のです。
トップダウンが絶対ダメかというとそんなことはありません。不確実性が多い中で意思決定を早期に進める上ではそれも正解のひとつではあります。ただ、2022年になって、敢えてそのやり方を変えたのです。
2022年の7月にプロダクトオーナーの交代があり、前任者から自分が引き継ぐことになりました。その時に解決が必要だと考えたことが下記の3つです。
- スケールする意思決定
- 持続可能性のある運用体制
- 腹落ちと士気アップに繋がる情報共有
14もあるプロダクトの優先順位について特定のマネジメントだけで決めていくことは、シンプルに考えてスケールしません。営業など意志決定者に見えやすい課題感に繋がる機能は比較的優先されやすく、お問い合わせ対応や導入運用など見えにくい課題感に繋がる機能は比較的落ちやすくなるのも仕方ない部分です。
意思決定することは成功と失敗の権利を得られること同義だと思っています。言うなれば成長の機会、経験値を得られると。なぜその意思決定が正解だったか、失敗だったかの積み上げが続くことでその質は上がっていくはずです。
ただし、ある意味ブラックボックス的にそれが進んでしまった上で意思決定者が離脱してしまうことがあると、組織としての意思決定貯金はすべて喪失してしまいます。また、仮に（そんなことはないですが）プロダクト数が倍になったとき、意思決定者のキャパは限られるために意思決定スピードあるいは質を落とすだろうなと考えました。
トップダウンで決められた施策が失敗した場合、思考の引力としては自責よりも他責に向かうことも多いように思います。もちろんすべての意思決定を成功することなんて非現実的ですが、それが続くことで組織に見切りをつけていく人が増えてしまうこともあるでしょう。
そんな状態になる前にトップダウンではない別の形にできないか？と考え動かしてきたのが「2022年度版プロダクト優先順位決め」なのです。
意思決定のためのチーム作り
顧客対峙する機能組織として、営業、オペレーション(OP)、カスタマーサクセス(CS)の3つの部門があります。他社でもそうだと思いますが、これらの部門の正義、優先したいことは得てして異なります。
14のプロダクトを4領域に分割し、各領域別に部署を代表する担当者をつけることにしました。つまりは、各部門の目線での「こうしたい」をプロダクトマネージャーと話し進めていく担当者です。ユニファではこの担当者を「大臣」と呼んでいます。
各領域別の優先度素案はプロダクトマネージャーと大臣で決めることとしました。大臣制自体、自分が言い出した話ではなく現場のプロダクトマネージャーから出てきた話で、意思決定に行くぞという地盤が既にあったのだと感じています。
優先順位をタイムライン化したロードマップの更新も、それまでは年1＋不定期更新であったのを3ヶ月(Q単位)に1回に改めました。
年1となると「ここで要求を入れておかないと未来永劫ロードマップに入れられないのでは」という懸念からの駆け込み乗車が続いてしまいます。更に1年後の開発工数を期待されるという謎のプロセスが発生してしまったり、目の前の事業変化と関係のない「でも既に約束してしまった」機能追加が優先されるようなことが続いてしまうバッドシナリオが容易に想定できます。
機能リリースもそうですが、いまここで必要な範囲に絞ってリリースすることで結果シンプルかつ容易な意思決定に繋がりますし、振り返りの頻度・精度アップの機会も増やせるはずです。「ここで入らなくても3ヶ月後にまた議論します」というワードは体感的に有効に機能していて、変えられることへの信頼残高がちょっとずつ増えてきたように思います。
「3ヶ月なんて長くない？毎月やるべきでしょ」と言う声もありました。もちろんその意図も分かります。ただ、開発目線で言えば毎月14にも及ぶプロダクトの優先度が変わるような状況では中長期的な開発や仮説検証ができる状況ではなくなりますし、全体的な目線で見ても内部での優先度決めばかりしていてプロダクトは一向に外に出てこない状況にも陥りかねないため、まずはこのペースに落ち着かせることとしました。
ボトムアップとトップダウンのバランス
各チーム・各プロダクトだけの意思決定だと当然ですが個別最適が起こります。その時に立ち戻るのは事業戦略から導かれる課題の優先度です。
機能開発もまた事業を伸ばす上での施策であり、特定の施策に対してやるべき機能開発、課題解決が紐付きます。例えば「解約率を下げたい」が優先施策であれば、プロダクトによっては利用ストレスになる要素の排除であったり、他社プロダクトから明確に劣っている要素の改善であったりとりうる手段は様々ありますが、各プロダクトの取る手段はボトムアップで考えた方がむしろ良いはずです。
施策と手段の因果があまりにも遠すぎないか？コストがかかりすぎていないか？と言った部分は各部門の組織長が横断的にチェックの上、最終的なロードマップとして着地させます。その場合も各施策のhowについての指摘に落としすぎることはしません。
これら座組をまとめたものが下記の図です。
つまりは、全体の方向性はトップダウンで定めるものの、具体的な各プロダクトでの動き方は各チームで定める方式です。やり方としては特に目新しいことはないですが、各プロダクトのhowまでトップダウンで決めていた状況からの変化としては大きく「もっと細かく決めた方がいいんじゃないか」という声も聞きながらもこの方針をとっています。
決められることに慣れてしまうと自走できるチームは生まれず、自走に適したメンバーの活躍の場を奪ってしまうことは中長期的にも組織を弱くしてしまいますし、それってスタートアップな動き方ではないよねと個人的にも思い、この考えを通させてもらっているのが現状です。
この座組が本当にアウトカムに繋がってるのか？というと、体制を変えてまだ半年弱であり答えが出るのはこれからです。ただし、それぞれが仮説を持ち、それを定期的に更新し続け、振り返ることを14プロダクトでやっていくことが始まったのは明確な変化だと思っています。
まとめ
2020-2021で悩んでいた話と2022年ではプロダクト組織としての悩みも大きく変わり、ただ以前よりもプロダクトマネジメントな課題に対する悩みが増えてきたことは嬉しく思います。
自分ができないことも日々突きつけられつつ、それを自分でやるのかできる人に来て頂くのかというのもまた選択。ユニファのプロダクト開発にご興味を持って頂けましたらぜひ募集要項をご覧ください。そして意思決定の一員になって頂けたら嬉しいです。ほとんどの開発系職種で居住地問わずフルリモートOKです！
