プロダクトロードマップ2021のしくじりと改善ふりかえり

こんにちは、ばうです。
この記事はユアマイスター Advent Calendar 2021年の12日目の記事になります。

さて、昨年のアドベントカレンダーでは「チームを動かすプロダクトロードマップの描き方」として前編・後編を書きました。
ロードマップ作りを始める際に私自身参考になる文献等が非常に少なかったのでその一助にでもなれば、と思い書いたのが背景です。

今年はこのロードマップの運用をしていくなかでのしくじりやそれに対してどんな改善をしてきたかを、私の視点から振り返ろうと思います。

1.機能単位ではなく提供価値単位にする

昨年作成したロードマップの大まかな流れとしては、以下のような形で進めていました。「機能」を軸にしてロードマップを作り始めたんですね。

1.ユーザー視点で必要そうな機能を洗い出す
2.機能をグルーピングして機能群にまとめる
3.お客様のフェーズを可視化して、どのようにお客様のフェーズが変わるかを仮説だて
4.そのお客様のフェーズごとに必要になるであろう機能群をマッピング
5.機能ごとにPdM担当者を配置、エンジニアは都度アサイン

これによって何が起きたかといいますと

・機能の要件はでてきたけど、"こんな価値を届けたい"の文脈が、機能単位で担当を任された人とプロダクト部のリードをする人とで擦りあっていなくて手戻りが発生

・機能ごとに担当者が異なっていてそれぞれが単独で動いてしまったので、目指したい方向性がバラバラで、機能群で見たときにチグハグなものになってしまった

など、一言でいうと「動くモノには近づけたけどその先のホールプロダクトやプロダクトの本質的な価値に繋がっていない」という状態になってしまいました。

小城さんも"機能を書くべからず"とおっしゃっていましたが、「この機能を作って」と渡されてしまうと目指すべきアウトカムよりもアウトプットに視点がよってしまう事態が発生しやすいのだと思います。

そこで、私たちの方針転換として、以下を再検討して、ユーザー価値ベースでのロードマップを練り直したのです。

1.3~5年後のホールプロダクトを描く
2.お客様への提供価値は何かを言語化する
3.提供価値における機能群は何かを明確にする
4.提供価値の機能群ごとの優先順位をつけて時系列にマッピングする

プロダクト部やPdMとしてはプロダクトを作った先にアウトカム(どんな時期にどんな人がどんな状態になるか)が実現できている状態にコミットしないといけません。
この方針転換により提供すべき価値での目線へと揃い始め、担当として渡された機能だけではなく、あるべきアウトカムに向かって必要な機能というものを考えるようになっていきました。

2.集中できる環境とNoを伝える場所づくりをする

プロダクトロードマップを作成した際に、プロダクトの価値を高めるための開発とは別に、会社としてのプロフィット(新たな収益の創出やコスト削減)を向上させるために他部署からの開発起案を受け取る開発分類を設置しました。

そのプロフィット関連の開発を起案する場所も作って、各部署から起案をもらい、1Qに1度優先づけをしました。しかしながら、トレンドにのって収益を上げるような施策を打つときには緊急の開発依頼が何度も出てきてしまったり、そのプロフィット関連の開発の差し込みによってエンジニアが都度アサインされプロダクト自体の開発の進捗が出なくなっていく、という課題が発生してしまいました。

そこで改善としてやったことが2つです。

1.トレンド(特に繁忙期)がくる前には、臨時ユニットを作り対応をする
2.スラックで#相談窓口を設けて、みんなが見える場で都度開発のやるやらないを伝える

やることを決めると同時に、それをやり切るためのユニットを作り集中できる環境を作りました。これで並行タスクをする人が減り、それぞれの開発に集中できる状態にしました。

また、差し込みでの依頼に関してはなぜ今その施策が必要で、ROIはどれほどになるのかを議論して「No」を伝える場所を作りました。
ここは起案する側のROIの観点や、受け取る側のプロダクトとしての軸に沿っているかの考え方や議論の深め方にまだ課題があるので、要改善だとは思っています。

このあたりはPdM カンファレンス2021でマクドナルド株式会社の公式アプリPM飯沼さんの発表に関するまとめも参考にしながら、次の3ヶ月で改善をしようと考えています。

マクドナルドのプロダクトマネジメント論、なぜ「No」と言えない開発責任者はダメか？

3.遅延の本質的な原因を見極める

実はプロダクトロードマップを始めた最初の3ヶ月で複数の遅延が発生しました。その際の振り返りでは「見積もりが甘かった」に終結してしまったのですが、ここが次の3ヶ月にも遅延が続いてしまう所以となりました...

実際には何が起きていたかというと、要件定義における定義の甘さ、設計工程における設計力、など人のレベルやプロセスの完了レベルの差が要因となっていました。

要件定義に関してはまさにPdMの守備範囲なのでこちらの改善点を今回は共有します。

1.PRDの作成を徹底
2.要件定義時点で他部署の業務フローに支障がないかを確認
3.エンジニアとも壁打ちを実施

1のPRDに関してはもう皆さんお馴染みかと思いますが、これからどんなものを作りどんな価値をどんなユーザーへ届けるのか、などアウトカムをさまざまな観点から明確に記したものです。

実はこれまで各PdMが自由に記載をしていたのですが、このタイミングからPdMも増えてきていたのでフォーマットを揃えることで抜け漏れを無くしたり、他PJのPRDを参考にしながらアップデートしていくことができました。

ちなみに、PRD導入の際にはこちらのkushidaさんのnoteにお世話になりました。

2~3に関しては、PdMだけで考えてクローズしないことが目的です。
ユーザーをわかったつもりになっていてもより詳しい部署があったり、一つの機能追加でも経理など日常の業務を変化させることになるものもあります。

また、それをエンジニア視点で見たときに遅延が生まれそうな見落としがないかを見つける場にしています。
これを機能改善含めた全ての要件定義で実行すると大変な労力がかかってしまうと思うので、機能単位というより届けたい価値提供単位でこれを実施するようになってきています。

要件定義の工程でのwhy、who、whatがより解像度高く、明確なものになれば、次工程以降での手戻りだったり想定外の開発が減っていくのだと痛感しています。

おわりに

この1年を通じての学びとしては、プロダクトロードマップというものができてようやくスタート地点であり、部署を超えてプロダクトのアウトカムベースで話ができるようになると、「プロダクトドリブン」に繋がっていくのだろうなという片鱗を掴み始めたことでした。

また、プロダクトの将来像がないとどうしてもそれた道に行ってしまう可能性が高まるので、ホールプロダクトを軸にチームやPJやプロセスを作っていく工程に関われたのはとても勉強になりました。

正直自分の力が足りないことばかりで悔しさが残る一年でしたが、逆にたくさんのしくじりから学びを得られたので、更なる改善を実行してよりよいプロダクトへと貢献できるように精進していきます！