皆さんこんにちは。 estieでプロダクトマネージャーをしております中村と申します。
今回は私が考えた”さいきょうのロードマップかんりツール”をfigmaのコンポーネントを駆使して作ってみました。
早速ですがこちらです。
▼こちらからコピーしてお使い下さい
上記見て「お!!」と思った方はぜひこのまま読み続けていただければと思います。
ロードマップに入れ込むべき要素に関する記事については、先輩プロダクトマネージャーの方のブログや記事等で知見の共有がされており、土壌が整いつつあると感じております。
しかしながら、実際のロードマップ自体の作成ノウハウやメンテナンスノウハウ、またロードマップ作成ツールの知見はなかなか見つからずに苦労しておりました。
そこで、私がいろいろなツールで試行錯誤した結果のベストプラクティスを作成してみたのですが、社内外のプロダクトマネージャーに共有してみたところ結構好評でしたので、プロダクトマネジメント界隈への貢献のために公開したいと思います。
本記事は特に下記に該当する方の手助けになればと思っております。
- ロードマップの作成はしているが、メンテナンスコストが高く更新がうまくできていない方
- ロードマップの重要性はわかりつつ、作成が面倒で脳内にロードマップがあるプロダクトマネージャー、経営者(雛形を編集可能な形で公開いたします)
- ロードマップ作成が大切とは聞いたが、どのような体裁で作ればよいかわからない初心者プロダクトマネージャー、プロダクトマネージャー以外の方
そして今回ご紹介するロードマップの特徴は下記になります
使用ツール | Figma |
金額 | 無料(Figmaの無料範囲内で使用可能) |
メンテナンス | 超楽 |
カスタマイズ性 | ある(カスタマイズするにはFigmaの操作理解が必要です) |
共有性 | ある(閲覧はもちろん、共同編集可能) |
無料でメンテナンスを楽に楽しく行える点にこだわりました。
それでは早速ご紹介していきます。
さいきょう の ロードマップ を さくせい に いたるまで
ロードマップ作成するに当たり、今までいくつかのツールを使用してきました。
私が使ったことのあるツールについて所感をまとめると以下のようになります。
ツール名 | 良かった点 | 悪かった点 |
---|---|---|
Power Point | 誰でも使えるツールであり、共有が楽 | メンテナンスする際に操作する箇所が多く、更新コストが高い |
Excel | KPI等の数値管理をする際に優れている | メンテナンスする際に操作する箇所が多く、更新コストが高い |
Confluence | 表やマクロを駆使することで一定効率化できる | デザイン性が悪く、パット見で情報を把握することが難しい 優先度変更等の更新コストが高い |
Jira | チケットと紐付けたメンテナンスが行える | 視認性が悪く、特に非エンジニアにとってはわかりにくい 金額コストが相当額かかる |
miro | 見た目が綺麗につくれる 議論した付箋等をエビデンスで残しやすい |
メンテナンスする際に操作する箇所が多く、更新コストが高い |
figjam | 見た目がきれいに作れる 議論した付箋等をエビデンスで残しやすい |
メンテナンスする際に操作する箇所が多く、更新コストが高い |
まとめるとほとんどのツールにおいてメンテナンス性が悪く、結果としてロードマップの更新が億劫になり、よく陥りがちな「ロードマップは俺の脳内にある」といったあまりよろしくない事象が発生するのではないでしょうか?
かくいう私も過去、「ロードマップは俺の脳内にある」状態になってしまい、開発見通しが悪くエンジニアや経営陣に迷惑をかけることが多かったです。
これはなんとかしないといけないと思い、重い腰を上げて自身でロードマップの雛形を作成する決意をいたしました。
さいきょう の ロードマップ のようけん を せいり
まずはロードマップの雛形を作成するにあたり、”ロードマップにはどのようなことを落とせるようになっているといいのか”を考えます。
これにつきましてはSmartHRさんのブログや、小城さんのブログ、坪田さんのnoteなどを参考にさせていただきました。
整理した結果、だいたい2次元のマトリクスで横軸に日時、縦軸にfeature(課題やユーザーストーリー、主要KPIなど)をおき、epic(子KPI、マイルストーン目標、機能チケットなど)をマッピングしたいケースが多いのだとわかりました。
視覚化すると下記のような形です
よく見るロードマップといった感じになりました。
ここから重要なのですが、全章で触れたとおりメンテナンスコストが低いことが非常に重要になります。
ユーザーストーリーを書いてみると以下です。
[プロダクトマネージャー]として、
[ロードマップのメンテナンスを楽に]したい
なぜなら [ロードマップのメンテナンスがされないとステークホルダー間の認識齟齬が発生し、プロダクトの成長が鈍化する]から
では具体的にロードマップでメンテナンスするときはどのようなときかを整理すると下記のケースかと思います
- 既存のfeature/epicの優先度が変わった時
- 新たなfeature/epicが起票された時
- 実装やKPIの進捗からリスケジューリングが発生した時
よって下記が達成できることをMVPとして定義し、作成していくことにしました
- featureの入れ替えられる。ただし紐づくepicとともに容易に可能なこと
- epicの入れ替えが容易なこと
- epicの期間を変更できる。ただし他のepicもいい感じに期間変更されること
MVPが定義できたので弊社デザイナーに相談し、Figmaを駆使して作成しました。(というかほとんどデザイナーのkioが作成してくれました。圧倒的感謝!!)
どうやって作成したのかはFigmaのテクニカルな使い方の記事になるので今回は割愛しますが、もし需要があれば別途記事執筆いたします。
さいきょう の ロードマップ の きのう
早速ですが、今回作成したロードマップの使い方をご説明いたします。
featureの入れ替えをする
- 並び替えたいfeatureをドラッグアンドドロップする
以上です。超簡単にできますね!
今までだとfeatureを並び替えると他のfeatureを1つ1つ修正していき、また紐づく(横並びになっている)epicも一緒に並び替えなければいけなかったはずです。
これがドラッグアンドドロップだけで完結するのはまさに”さいきょう”だと私は思ってます。
ちなみにfeatureを選択した後、leverという選択肢を変更すると色が変わります。featureを視覚的にグルーピングしたいときにお使い下さい。
epicの入れ替えをする
- 並び替えたいepicをドラッグアンドドロップする
以上です。超簡単にできますね!
featureの入れ替えをいい感じにしつつ、epicの入れ替えもいい感じにすることは実は結構難しかったりします。
epicの期間を変更する
- 期間を変更したいepicを選択し、sprintを1 or 2にする
以上です。超簡単にできますね!
ここでミソなのは期間的に連続するepicであれば伸ばした/縮めた期間分追従するが、期間的に非連続なepicには影響がないことです。
テンプレートではsprint1は2週間、sprint2は4週間として設定されておりますが、期間を変更したい場合はepicコンポーネントのwidthをいい感じにすれば対応できます。
他にもepicが完了した際にdoneにできる機能やマイルストーンをおける機能も作成しているので、ぜひ触ってみて下さい。
さいきょう の ロードマップ を こうかい
長々と説明しましたが、以上が私の考えた”さいきょうのロードマップかんりツール”になります。
色々とお使いいただき、様々なフィードバック頂けると幸いです
(コピーして利用頂く際に私に一言頂けると頑張ったかいがあったなとなって喜ぶのでリプライでもDMでお願いします!!!)
ひとにはひとの、プロダクトにはプロダクトのロードマップがあると思っています。
3年間プロダクトマネージャーを経験し、ロードマップを通じたステークホルダー間の認識合わせはプロダクトマネジメントにおいて非常にレバがかかるなと身にしみて感じます。
本記事がどこかの誰かのプロダクトマネジメントに役立つことを祈るとともに、私もまだまだ”さいきょうのロードマップ”を極めていきたいと思いますので、一緒に議論してくださる方ぜひ下記カジュアル面談お願いします!!