プロダクトロードマップの決め方：RICEフレームワークの実践と学び

はじめに

LANSCOPE エンドポイントマネージャークラウド版（以下、エンドポイントマネージャークラウド版）のプロダクトマーケティングマネージャー（PMM）の武藤です。弊社エムオーテックスが開発・販売しているエンドポイントマネージャークラウド版は、組織が利用するPCやスマホをクラウドで一元管理できるIT資産管理・MDMツールです。

エンドポイントマネージャークラウド版は、2012年9月、iOS・Androidデバイスを管理するためのMDMツールとしてリリースしました。その後、Windows・Macデバイスにも対応しましたが、PCの紛失対策を目的とした「MDM機能」の提供に留まっていました。2020年10月、LANSCOPE エンドポイントマネージャーオンプレミス版で提供してきた操作ログ取得機能をエンドポイントマネージャークラウド版に実装。以降、IT資産管理ツールとしても導入が進み、おかげさまで、累計導入実績は12,000社を超えました。

エンドポイントマネージャークラウド版は、クラウドサービス（SaaS）という特性を活かし、新機能から機能改善、またサービスの安定稼働を目指す改善も含め、毎月のようにバージョンアップを行っています。これらのリリースを行う上で、限られた開発リソースの中、何を優先して執り行っていくべきか、非常に重要な意思決定が必要です。このロードマップを決定していくためのプロセスとして「RICE」というフレームワークを2022年1月に採用しました。

本記事では、私たちがどのようにしてロードマップを決定しているのか、その経緯と現在の取り組みについてお話したいと思います。

はじめに
エンドポイントマネージャークラウド版のリリース実績
PMMの導入とロードマップの「ブラックボックス化」
フレームワークの構築
MOTEXにとってのRICEフレームワークの利点
おわりに

エンドポイントマネージャークラウド版のリリース実績

本題に入る前に、エンドポイントマネージャークラウド版のリリース実績について触れたいと思います。先述の通り、2012年9月にリリース以降、MDMツールとしての機能開発が中心、2020年10月以降は、MDMに加え、IT資産管理ツールの機能開発を実施してきました。

記はエンドポイントマネージャークラウド版の主要機能のリリース実績です。これらのほかにも、管理コンソールのUX改善や機能改良、クラウド基盤のメンテナンス・改善など、ここでは書き表すことができないほどのリリースを毎月のように行っています。これまで、MOTEXの開発リソースの中で、どのタイミングで、何をするのかをPMMとして決定してきました。では、この決定をどういったプロセスで行っているのか、本題に入っていきたいと思います。

PMMの導入とロードマップの「ブラックボックス化」

2021年4月、MOTEXとして、PM/PMM制度を創設、エンドポイントマネージャークラウド版のPMMとして私が着任しました。これまで、開発責任者をはじめ、開発メンバー、マーケティング、営業、サポートなどステークホルダーと協働し、「ロードマップの策定・実行」と「売上計画の達成のための施策」を推進してきました。

PMMとなってから数ヶ月した頃に、「ロードマップの決定プロセスが見えにくい」という声が上がるようになりました。当初は「そんなことはない」と思っていましたが、振り返ってみると確かにプロセスが「ブラックボックス化」していたことは否めません。私自身、また密接に関わるステークホルダーは明確な納得感を持ってロードマップを決定していたつもりですが、それが社内には伝わっていなかったのです。

フレームワークの構築

ロードマップのブラックボックス化という課題への解決策を模索する中、当時、開発チームの若手メンバーから「RICE」というロードマップタスクを管理するためのフレームワークがあることを教えてもらいました。PMM着任当時は、次にやるべきロードマップタスクの優先順位付けは比較的容易でした。しかし、今後は、より複雑な判断が必要になる（簡単に言えば、次にどのロードマップタスクを優先すべきか、甲乙付け難い状況に陥る）ことは容易に想像できたため、早速「RICE」をベースとしたロードマップの管理・決定のプロセスを構築することを決めました。

RICEとは「Reach」「Impact」「Confidence」「Effort」の項目の頭文字を取っています。これら4つの項目で、それぞれのロードマップタスクを評価・スコアリングし、［Reach ✕ Impact ✕ Confidence ÷ Effort］の計算式を用いてスコアを出します。

後はスコアリングしたタスクを上から順番に並べると、必然的に優先順位が高いタスクの見える化が可能となります。しかし、ただスコアリングしただけでは完全な課題の解決にはなりません。RICEをベースとしたこの仕組みを有効に活かすため、下記3つの建付けを行いました。

RICEスコアは全社員、誰でも閲覧できるようにする。そして、このタスクの優先度を引き上げて欲しいなどの要望をコメントできるようにする。
スコアが絶対ではない。あくまでスコアが高いものから最終的にはPMM・経営層で意思決定をする。
現場の意見を広く収集できるよう各部門の代表者が集う「ロードマップ検討会議」を設置する。

RICEスコアは、MOTEXでは「Backlog」というツールを利用して管理しています。ここで、そのロードマップをやる意義（＝Reach/Impact/Confidence）、その意義に対するスコアリング、社員からのコメント・要望などを集約して管理しています。

また、スコアが絶対ではないということは設計当初から意識しました。あくまでも、数百とあるタスクの中から、優先順位の高いロードマップタスクは何か？を見える化することが目的にあります。次にやるべきタスクは何かを検討する「ロードマップ検討会議」の中で、集中して検討するタスクをあぶり出しているのです。

ロードマップ検討会議は、必ずしも「会議で話し合って」決めるわけではありません。時には、「スコアで●●が、明らかに優先度が高いので、次はこれをやります。異存があれば、コメントください」とチャット上で決定することもあります。

MOTEXにとってのRICEフレームワークの利点

2022年1月の運用開始以降、以下のような効果を得られていると感じています。

客観的な比較：多数の候補の中から、定量的な基準で優先順位付けができるようになりました。
- RICEは不完全。スコアで順位は出るが絶対ではありません。しかし、少なくとも何百とある候補の中から、優先順位が高いタスクに集中して検討できるようになりました。
- ともすれば、眼の前にある大型の案件（この機能を実装すれば受注できるというような案件）に目がくらんでしまうかもしれません。しかし、そういったことを起こさない、あくまで中長期的観点で評価できます。
PMMや開発チームが日常的にロードマップについて検討できる環境が整いました。日々スコアとにらめっこです。
開発チームの主体性。

3つ目は嬉しい利点です。新機能開発をはじめとしたロードマップタスク、安定稼働のためのメンテナンスタスクなど、いっぱいいっぱいでやっている開発チームが、「隙間時間を活用して、RICEの優先順位の高いものの中で、これならすぐに取り組めそう」というものを提案してくれる機会もありました。これは本当に嬉しい効果です。