ITANDI TECH BLOG

イタンジのスタッフブログです。イベントや技術情報などを発信しています。

プロダクトロードマップとは巨大なフレームワークの表層部分

この記事はProduct Manager Advent Calendar 2016の23日目のエントリーです

横澤です、本年はお世話になりました。来年もよろしくお願い致します。

プロダクトマネジメントの勃興】 本日はプロダクトマネジメントにおけるプロダクトロードマップの位置付けについて思うところがあったので書いてみました。ここ二、三年くらいでしょうか、プロダクトマネジメントという単語、というか概念が流行ってきている感があります。プロダクトマネジメントとは何か?プロダクトマネージャーは何をする人か?まだプロダクトマネジメントで消耗してるの? 的な事が各所で語られているのを見かけます。

プロダクトマネジメントにおけるプロダクトロードマップという業務】 私の理解ではプロダクトマネージャーの重要な役割の一つにプロダクトロードマップ(PRD:ProductRequirementDocと呼ばれる事もあるようですが以下PRMと略します)をアウトプットしてメンバーの指標とする役割があると認識しております。ですが、プロダクトロードマップのお手本というのはあまり見た記憶がありません。冷静に考えてみればその会社のPRMが見られるという事は、サービスの方向性やセグメントとかフェーズ認識とか会社や事業として重要な思念が色々と見えてしまうのでカジュアルに公開する訳にはいかない様な気がします。

とは言え作ろうと思ったら試しに見てみたいので色々とググったのですがこんな資料を発見しました。シンプルisベストという事でしょうか。他にもガントチャート型の例なども見かけましたが、個人的には「マイルストーンを大きめな粒度で描いたスケジュール表」という受け取り方をしています。分かりやすさという意味ではこのシンプルさは良いのでしょうけど、これだけ見せられて納得感があるのか?というのがどうも腑に落ちないところでした。

【プロダクトロードマップの背後に潜むコンテキストの重要性】 丁度昨年度の始め辺りに上に書いたようなモヤモヤした気持ちを持ちつつもググって調べたフォーマットや独自の考えを用いてPRMを作成したのですが、モノの見事に失敗しました。結構な時間と気合を入れてそれっぽいアウトプットをしたのですが、結果としては現在のプロダクトと乖離しているので仕事としては失敗したと考えています。失敗した理由を改めて考えてみると大きく分けて3つの理由があったと振り返っています。

  • 提供する機能は明確に記載されているが、それがもたらす価値についての記載が希薄だった

  • 最終的には文章と画でアウトプットされたが、そこに至るまでの分解されたKPIや数字の関係性が抜け落ちていた

  • 細かく書きすぎ且つ、一つ上のレイヤーで抽象的にまとめられておらずスッと記憶されない

おおざっぱに言うとメンバーに公開する際の圧縮率が足りてないのと、最終アウトプットに至る途中資料の作り込みが足りないという結論を得ました。良いPRMというのは高度に抽象化されたMVCフレームワークみたいなイメージで、普通にWEBアプリを作る上では必要最低限の規約を理解すれば充分で、より深掘りしたくなった際には、複雑ながらも全体を通して一貫性のあるクラス構造によって支えられていて、読み進めるウチに入口であった規約の背後に潜む思想がより強靭に理解されるようなモノだと考えました。つまりRuby on RailsみたいなPRMは良いPRMだろうという事です。

【事業計画とPRMは表裏一体】 そんな事を考えている中、今年もPRMを作る機会がありました。反省を活かして凝縮されたシンプルな作りを目指すのですが、どうも納得する水準に達さない出来のままに、途中で会社全体の事業計画を作る業務に移りました。事業計画にはマイルストーンとして「この事業(≒プロダクト)はこのタイミングでこんな事が実現されている」みたいな事を書きこんでいたのですが、それを見て「PRMの一枚裏にあるコンテキスト資料とは事業計画なのではないか?」という考えが頭をよぎりました。その考えを辿った結果、会社のミッション>事業を通して実現したいビジョン>サービスやプロダクト個別の事業計画(ビジネスモデルやKPIツリーが含まれる)>PRMというレイヤー構造として理解でき、それぞれの資料の繫がりを自分の中で整理する事ができるようになりました。

【何が言いたいのか】 開発メンバー等に共有するPRMのフォーマットはやはりシンプルに凝縮されたフォーマットが望ましいと思います。ただ、PRMが産み出されたコンテキストについては、メンバーが知りたいと考えた時にどこまでも深掘り出来て、最終的にはそれが会社のミッションやビジョンという最上位レイヤーから繋がった概念である、と理解できる設計になっている事も重要だと考えています。プロダクトマネジメントをする上ではUXデザインであったりビジネスデザインであったりと考慮すべき領域が多岐に渡るのですが、それぞれがどういうレイヤー構造で企業思念に結びついているのかをもやもやしながらも少しは理解を進歩出来たと思う一年でした。

ちなみにイタンジでは共にプロダクトの成長を楽しんでいけるメンバーを絶賛募集しております。

来年もどうぞよろしくお願い申し上げます。