ソフトウェアベンダーにおけるプロダクトマネジメントについて #3

# プロダクトマネジメントは製品戦略を考えることである

さて、プロダクトの定義ができたところで、次はようやくプロダクトマネジメントに関する話をしていきたいと思います。プロダクトマネジメントとは前述したとおり「プロダクトの社会的有用性を最大化する」ということと定義しました。では、「最大化」とは何でしょうか？どうなったら「最大化」されたと言えるのでしょうか？どのように「最大化」したら良いでしょうか？こうやって考えていくと最大化を考えるためには、以下の3つの視点が必要そうです。

* 何を最大化させるか(選定)
* どこまで最大化させるか(目標)
* どのように最大化させるか(手段・運用)

もうお判りだと思いますが、この3つの視点は「戦略立案」そのものです。つまり、プロダクトを最大化するためにどのような手段をつかうかプランをたてることは、いわゆる「製品戦略」をたてることであり、逆にいうと極端に言ってしまえば、プロダクトマネジメントの最大のキモはその「製品戦略」の立案にあるということです。

「製品戦略」というと、なんとなく曖昧なものをイメージされることもあると思いますし、逆に具体的な数値ばかりがまとまったものというものを思いつく人もいるかもしれません。そのような「製品戦略」であっても問題はないのですが、この文脈でいう「製品戦略」で必要になってくるものは、プロダクトのどの要素を、どこまで、どのように最大化させるかという「最大化」のプランであり、方法論です。言い換えるならば「最大化」の道筋をたてること、この点が極めて重要になってきます。

# 製品戦略とは

それでは、製品戦略はどのように作るべきでしょう。この点についても、正直言って正解はないのではないかと私自身考えています。戦略とは、あくまで目的を達成させるためのプランであり、目的やそのものの対象によって大きく変わってきます。短期的なビジョンか長期的なビジョンかという点でも、プランの方向性は大きく異なってくると思います。一概に言えないというところではないでしょうか。

マーケティング論では、いわゆる「3C」や「4P」、「コトラーのプロダクト3層モデル」など様々なフレームワークがあるかと思います。これらのフレームワークはマーケティング戦略を立案する時には非常に有益だと思いますが、プロダクトマーネジャーが考えるべき「製品戦略」はマーケティング戦略だけではありません。もちろん、マーケティング戦略も考慮しますが、重要なのはプロダクトをどのように最大化させるかです。そのためには、製品機能や、製品の提供方法、サポート方法まで多岐にわたる視点が必要です。そういった意味では、マーケティングのフレームワークにだけ頼ることのないようにしないといけません。

私はプロダクトマネジメントの「製品戦略」を考える際は、以下のようなポイントをベースにプランをまとめるようにしていました。

1. コンセプト
2. コアコンピタンス
3. テーマ
4. ロードマップ

「1」のコンセプトは、リマインドです。そのプロダクトの存在価値を忘れないように必ず記載するようにします。「2」のコアコンピタンスは、製品戦略の何を最大化させるか（選定）にあたります。ここで、最大化させる対象を定義します。「3」はテーマで、ここでどこまで最大化させるか（目標）を設定します。最後はロードマップです。このロードマップで最大化させるための（手段・運用）を提示します。

コアコンピタンスでは、今現在、製品として一番売りとなる部分、また今後、製品として一番伸ばしたいポイントをまとめます。強みを最大化させることがすなわち製品の価値を最大化させることになるからです。この点は、過去の顧客からの評価をベースに、プロダクトマネージャーが自分自身の思いを元に定義します。

テーマでは、今回の戦略でとして達成したいことをまとめます。例えば「製品のパフォーマンスを2倍にする」や「製品の使い勝手を3倍よくする」など、なるだけ達成度合いが後から評価しやすいように具体的に定義します。

# ロードマップの作り方

上記の製品戦略の中で一番手間と時間がかかるのがロードマップの作成かと思います。ロードマップこそが製品戦略の軸であり、製品戦略そのものと言っても過言ではありません。ロードマップはつまるところ、製品をどう成長（最大化）させるかの道筋です。稀に単純に今後対応予定の機能だけを羅列しているだけのロードマップをみることがありますが、それでは戦略の道筋として広くステークホルダーに認識してもらうのは難しいでしょう。製品がどのような思想を持ち、どのように発展していくのかがわかること。これがロードマップの役割です。

ロードマップを作成するには、以下の手順を踏むのが一般的でしょう。

1. エンハンス要望のまとめ
2. 積み上げ項目の洗い出し
3. 優先順位の決定
4. 対応スケジュールの調整
5. ロードマップの決定

順番はどちらでも構わないのですが、まずはエンハンス要望のまとめと積み上げ項目の洗い出しをします。スクラムで言うとところのプロダクトバックログですね。エンハンス要望に関しては、役割、役職に関わらず全ステークホルダーの要望をまとめるように意識します。特にありがちなのが、すでに利用しているユーザからの強い要望を優先的に対応してしまうことです。すでに利用しているユーザには、その要望を出さざるを得ない背景があるはずで、その背景は時には利己的な場合もあります。その背景をよく理解せずにその対応を優先してしまい、結果使われないような機能ばかりが実装されてしまうということがあります。そのような事態にならないように、広い視野をもって具体的にどのような人に価値が出るのかを考慮し、要望をまとめるようにします。

次は優先順位の決定です。この優先順位の決定が一番かかる事項です。ですが、曖昧に実施してしまうと、後々の工程に大きな影響が出ます。この優先順位の決定には、やはりトレードオフスライダーが役に立ちます。やり方はスクラムと同様で問題ありませんが、スクラムチーム内のインセプションデッキで作成するトレードオフスライダーと同一である必要はありません。ここでの優先順位には、ある基準によって判断されるだけではなく、プロダクトマネージャーとしての思いをのせるべきです。それがプロダクトマネージャーを行なっている意義になりますし、その思いが製品をより個性的に最大化させることができるからです。ただし、間違っていけない点は、自分自身がやりたいことを優先するという意味ではありません。広くステークホルダーから集まった妥当性の高いバックログの中から、自分がこれが今一番必要だと思う項目の順位を入れ替えるというだけです。

ここまでできれば、後は別段難しいことはありません。プロダクトオーナーがいれば、そのプロダクトオーナーと実の対応スケジュールの調整を行い、後はロードマップとして図におこすだけです。

# プロダクトマネジメントの本質

プロダクトマネージャーとしてはまだまだやるべきことは多数あるかと思いますが、ひとまず戦略をたてることができればひと段落というところではないでしょうか。しかし、プロダクトマネージャーの本質は、戦略を作成することではなく、作成した戦略に責任を持つことです。この戦略が正しく遂行できるように、進捗確認を行い、うまくいってなければ軌道修正をしながら、運用、管理を行う必要があります。プロダクトマネージャーの戦略が、今後の製品成長の柱になるわけですから、全力で達成できるように最大限の努力をする必要があります。

# さいごに

今回は、自戒の念をこめて記載したつもりですが、それでもこうやってまとめてみると自分の不完全さを思い知らされます。次回プロダクトマネジメントをやらせてもらう機会があれば、今回のまとめをもとにもうちょっとうまくやりたいものです。

冒頭で、スクラム開発でのプロダクトオーナーとプロダクトマネージャーの違いについて記載しましたが、スクラム開発におけるプロダクトオーナーの定義などは非常に網羅的にまとまって参考になります。例えば、今回ボリュームが多くなってしまうので書かなかった、継続的な対応項目の運用や、仕様策定の支援などに関しても細かく定義があります。すべてが日本の慣習に合うわけではないと思いますが、非常に参考になると思います。

今回は、自分なりのまとめとしてこの記事を書きました。他にも様々なところでプロダクトマネジメントの定義がされていると思いますが、この記事はあくまで私の解釈でまとめたものです。偏りが多く、思い違いも多数あるかと思います。その点は何卒ご留意ください。もし、間違いや指摘事項などありましたらコメントもらえると大変ありがたいです。

最後に、私のような人間にこのような職掌を経験させてくれた株式会社アプレッソには大変感謝をしています。ありがとうございました。