見出し画像

チームを動かすプロダクトロードマップの描き方(後編)

こんにちは!12月も残すところ10日弱になりましたね。
私はこの土日に大掃除を終えてもう気持ち新たになってます。やっぱり大掃除って気持ちいい。
この記事はユアマイスター Advent Calendar 2020 の21日目の記事です🎉

さて、今日は「プロダクトロードマップづくり」の振り返り後編です!前回書いた目次の⑤以降となります。作業面も含めた細いお話を書いてみました。今回はしくじりエピソードも添えてお届けします。


⑤価値のある機能にするためのランク付け

機能が洗い出せた後には、優先順位付けをしていきます。
とはいえ洗い出し機能は約300個もあり、これを一つずつ並べ替えるのは至難の技。

ということでこの機能の優先度を考えるために③で考えた軸を各機能にプロットしていきます。

ここで参考までに優先度定義を以下とします。

習熟度:a>b>c
提供価値分類:可視化>省オペ化>業務効率化

note用_-_Google_スプレッドシート

次に、習熟度の一番低い段階で絞り込みをかけて、このグループ内でも提供価値分類の優先度ごとに順番をつけます。

スクリーンショット_2020_12_20_15_14

さて、準備が整ったらここからは地味な戦いです。

Priorty1だけで絞り込んでみて「Priorty1」同士を戦わせます。
例えば、この#2項目は習熟度がbなのに1番にする必要があるのか!?
→否!!2番へ連れてけ!みたいなことをやります。逆も然り。

スクリーンショット_2020_12_20_15_18

というのを繰り替えし、繰り返し、繰り替えし.....
約300項目あったので、この順番をあげたりさげたりあげたりさげたりに合計で5~7時間はかけたと思います..!!

(しくじりその1)
この時点で前後関係のある機能要件を見極めておく必要があります。機能Aを作らないと、機能Cは作れないよね、みたいな関連があるもの。
これを一部見逃していたので、後からPriortyの優先度付けをやり直したものも(泣)

だんだんみんな目がチカチカしてくるので適度に休憩を挟みましょう。
ちなみにまだここではスケジュールに落とし込みません!もう少し我慢です

⑥価値ある機能を実現するためのアサイン

さて、優先度がつけられたら次はアサインです!
エンジニアさんの能力やチャレンジ分野などを加味しながら、アサインを考えます。
ここでポイントになるのがアサインする際に、なるべく提供価値分類ごとにメンバーのアサインを考えること。その分類ごとに責任をもったメンバーがいることでより質の高いプロダクトが組み上がっていく、という構想です。

note用_-_Google_スプレッドシート

(しくじりその2)
実は最初に作った際にこの提供価値分類を考慮せず、パラパラとアサインをしておりました。そうするとこの提供価値に対して深く考える人がおらず、各項目の機能作成時に横連携が必要な状況になってしまいました...
次Qからは各提供価値分類ごとにアサインをして、評価目標にも繋がっていくように軌道修正中です🛳

上記の⑤⑥ができたら、初めてスケジュールに落とし込みます!
各Priortyを、3ヶ月(1Q)でやりきるくらいを目安にしていました。
が、スケジュールに落とし込んだら、人が足りない・この順番だとスケジュールが成り立たない・1だけで半年くらいかかりそう(爆)、などの課題がどんどん出てきます。
というわけでスケジュールが成立するように⑤⑥をひたすら繰り返していったのでした....(ロードマップってこんなに地道な道のりを歩むのですね....)

⑦運用にむけたMTGやPDCAの設計

続いて実際に運用するために、チームで想定する動きや他チームとのコミュニケーションを設計していきました。
ロードマップがあっても、それを実現するための周辺の仕組みを整えておかないと、チームメンバーが路頭に迷ってしまいます。そのため想像力を働かせて、通常の動きからイレギュラーな動きまで洗い出しておきます。

決めたことは以下のようなものたち。新ロードマップを適用する時期を決めて、その逆算で期日を決めていきました。

・開発フロー
・開発分類の定義
・他チーム起案の案件のフロー
・ロードマップ更新の定義・履歴の管理方法
・Backlogの管理方法
・MTGの設計
・KPIの設計
・インターナルコミュニケーションの設計(社内の他チームにプロダクト部の動きを理解してもらうためのコミュニケーション)

ユアマイスターではドキュメントツールとしてコンフルエンスを利用しており、誰でもアクセスできるようにまとまっています。
プロダクト戦略の実行フロー_-_プロダクト部_-_Confluence

この辺りは新ロードマップでの開発開始前に、リーダー陣へ説明→プロダクトチーム内へ説明→全社ミーティングで説明、とインターナルコミュニケーションを大事にしていきました。
新しい取り組みで応援や協力を得るには、目指す姿や目的を宣言していくことが大事なんだと改めて痛感。これらの発信をボードメンバーも後押ししてくれたおかげでとてもスムーズにスタートがきれました。

⑧運用開始!

というわけでここまで約2ヶ月!
10月の下旬からユアマイスターの新ロードマップに沿った、新開発が始まりました!!
わーい!(みんなでユアマイスターポーズ)

スクリーンショット 2020-12-20 15.46.57

最初の頃こそ慣れないロードマップとスケジュールに追われる感がありましたが、時間が経つにつれどの習熟度のお客様にどんな価値を提供できるのか、という発言がメンバーからも出てくるようになりました。(ここを浸透させるためにはフィードバックや壁打ちでどの軸のどんな価値を考えた新機能や機能改善なのか、という議論はまだまだ欠かせません。)

目の前の使いづらさよりも、そこに秘めているお客様の将来を見据えた課題に向き合うという動きへと変わってきていることが何よりの変化かなと思います。

その後~運用開始後に躓いたこと~

気づけば12月21日。ということはロードマップを開始して約2ヶ月がたちました。上記でもしくじりは載せておりますが、何よりもの反省点となった事件を取り上げようと思います。

ことの発端は開始して2週間ほどたったころ。あちこちから、
「これが遅延します」
「これは遅延回避のためにスコープを部分的にします」
「あの遅延受けて、こっちも遅延です」
みたいな遅延祭り事件がおきました。。。

というのも要因は、各機能のスコープがロードマップ作成陣の想定と異なっており、それが各メンバーにもバラバラに解釈されてしまっていたことでした。それがアサインやスケジュールにも影響していたのです。

そこで急いで対策を講じたのは以下の通り。

・各機能の定義を再度議論・共有
・「遅延」の定義を決定
・遅延が発生するローリングタイミング等を決定
・提供価値を最大化することを念頭にスケジュールを再検討(スケジュールに合わせた要件ではなく、要件を実現するためのスケジュールへ)

自分たちの準備の甘さが如実に出て非常に反省した部分なのですが、こういった課題をすぐにフィードバックしあえるチームだからこそ軌道修正も早く取り込めたのかな、と感じています。

これ以外にも過渡期ゆえの課題は出てきますが、何よりそれを溜め込まずに課題としてキャッチして、解決策を講じていく、その改善のスピード感が大事ですね。

おわり

さて、いかがでしたでしょうか?
今回はロードマップに絞った話でしたが、そもそものプロダクト開発に対する戦略を絡めたものだったので、私のこれまでの経験では考えが及ばない面も多々あり、非常に学びの多い経験となりました。

ロードマップは完成して終わりではなく、プロダクトの価値提供を実現し、そして価値最大化できるよう磨き続けるためのもの。

というわけで今年も残り少ないですがプロダクトづくりに奔走したいと思います☺️

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