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

プロダクトの３つの要素

前回では、プロダクトマネジメントは「プロダクトやサービスの社会的有用性を最大化する」ことと定義しました。今回はもう少し突っ込んで、その意義や方法について。が、それよりもまず、ここでいうプロダクトとは何でしょうか？日々の業務の中で、あまり意識することはないかもしれません。でも、この定義がおろそかになっていたら、プロダクトマネジメントはできませんよね。あらためてプロダクトの定義を考えてみます。

なぜこのプロダクトやサービスは存在しているのでしょうか？
もし、あなたがプロダクトマネージャーだったとして、この質問に即座に答えられるでしょうか。即答できない人も多いのではないでしょうか。かくいう私もこの点をどうやってまとめるかをだいぶ悩みました。プロダクトの社会的有用性を最大化しなければいけない立場であれば、今の製品の現状を正確に捉え説明できる必要があるはずです。しかし、製品の性質を正確に捉えるのは容易ではありません。

特に製品に長く携わっていると、この点をおろそかにしがちです。製品には通常かなりの数のステークホルダーがおり、それぞれの人が思っている製品の価値や評価もまちまちです。こういったことは明白な事実でありながら、案外軽視されることが多いように感じます。たとえば、社長が言っているから、製品開発者が言っているから、営業が言っているから、顧客が言っているから。そういった意見を尊重するあまり、自分の中のプロダクトの定義が曖昧になってしまっているケースがよくあります。言っていることが、相対する人によって変わってしまったり（意見が変わることが必ずしも悪いわけではありませんが）口ごもってしまっているケースもあるように思います。しかし、あなたがプロダクトマネージャーであれば、自分なりのプロダクトの定義を持つ必要があります。その定義こそがあなたのプロダクトマネージャーとしての存在意義になります。

では、その製品をどのように理解すればよいでしょうか？私は、以下の3つ要素を元に製品を定義していました。

1.Concept

2.Solution

3.Value

以下、詳細を説明していきます。

Concept

通常、製品は、誰かしら考案者がおり、その考案者がある思いを持って企画をしたものだと思います。考案者は、実体験やその他周りの人の体験などを元に、ある問題に課題意識を持ち、その課題を解決させようとその製品を企画します。そして、企画をしていく中で、その思いや課題意識をよりわかりやすく説明できるように「コンセプト」という形でひとつにまとめられます。

製品とってのコンセプトとは、その製品を作って何を成し遂げたいかということです。製品には達成したい思いがあります。その思いをわかりやすく形にしたのがコンセプトです。例えば「世の中の開発者の工数を半分にする」とか「プログラムがかけない人でもシステム開発をできるようにする」など、今できていないこと、課題になっていることを解決する目標やビジョンがコンセプトです。

このコンセプトは、通常変わることはありません。というより変えてはいけません。製品企画時に設定したコンセプトは、製品のアイデンティティです。そのコンセプトが変わる時は、製品そのものの存在価値が変わる時です。安易に変えるべきではありません。コンセプトは、ほとんどの場合、製品企画時にまとまっているはずです。大抵は、なぜこの製品が開発されたのかを語ることによって、コンセプトも説明できると思います。このコンセプトは製品のベースになる価値観なので、絶対に忘れないようにします。

Solution

続いては、ソリューションです。ここでいうソリューションとは、この製品がどのような課題を解決するかという意味です。コンセプトと重なる部分が多いように感じられると思いますが、そうとも言い切れません。すべての製品がコンセプト通りのことを達成できるとは限りません。コンセプトはあくまで理想です。現時点でコンセプトが完全に達成できれば製品成長は必要ないでしょう。ただ、コンセプトを達成することは容易ではありません。コンセプトは前述のとおりゴール設定が曖昧な定義になりがちで、どうしたって製品単体で達成できたとは完全には言い切ることはできないでしょう。

そういった意味でも、今現時点でこの製品がどのような課題を解決できているかを捉えておくことは重要です。この点をはっきりと押さえておくと、現状の製品が成長のどの過程にあるのかが捉えやすくなります。ソリューションは今できていることです。製品の現状をよく知っておくのは今後の製品成長を考える上で非常に重要です。

また、ソリューションは、なるだけ具体的に定義しておきます。例えば前述の「プログラムがかけない人でもシステム開発をできるようにする」というコンセプトの製品なのであれば、具体的にどういったシステムを、どのようにプログラムをかけない人が、どのように開発できるようになったかを定義しておきます。またその結果、システム開発のどのような課題を解決したかを定義します。例をあげると「専門知識が必要で、長い経験があるベテランでもバグが発生しがちな勘定系のシステムを、専門知識のない一般的な開発者が最小限のバグで開発ができるようなった」など、できる限り具体的に定義します。数値などわかっていることもまとめておくと説得力が増すと思います。

Value

最後はValue（価値）です。このプロダクトが現時点でどのような価値を顧客に提供しているか、これを定義します。この価値も、コンセプトやソリューションと同列に考えてしまうことが多いように感じます。ただ、この価値は別々に考えるべきです。例えば前述のように、一般的な開発者が専門的な知識を要する複雑なシステムを簡単に作成できるようになるという課題解決ができたとします。それでは、この簡単に確実に開発ができるようになったことにどのような価値があるでしょうか？もしかしたら、専門的なシステム開発はそれほどの需要がなく、現在従事している専門家だけで十分に需要が満たせるかもしれません。その場合この課題解決に価値はあるでしょうか。

課題解決=価値でない場合は、往々にしてあります。課題解決は苦労も伴う大仕事です。しかし、それで満足してはいけません。価値が出て初めて意味があるのです。そのためには、課題解決では別に正しく、価値を評価する必要があります。現状で、このプロダクトを利用することで得られる価値は何か、正しく定義します。

プロダクトマネージャーの存在価値

このプロダクトの3つの要素は、以下のように捉えるとわかりやすいと思います。

• Concept = 理想とするビジョン、目標
• Solution = 現状得られる効果、できていること
• Value = 今得られている価値、効果

このプロダクトの捉え方は、ソフトウェアならではと言えるかもしれません。例えば生活必需品の場合、存在しているだけで価値がある場合もあるため、明確なコンセプトは定義できないかもしれません。IT系のソフトウェアの場合、現実世界で行われている作業や行為を、プロダクトの力でよりよくするために生まれたものがほとんどかと思います。その場合には、この捉え方は有益なのではないかと思います。

また、この3つの要素を捉える時に気をつけなければいけないことがあります。それは、正解は存在しないということです。あなたがたとえ製品の起案者であっても、あなたの3つの定義が必ず正しいとは言えません。プロダクトに関わっている方ならわかると思いますが、製品にある程度顧客がつくと、いくつかの顧客の中から製作側が想定しえなかったような思いもよらぬ使い方をする顧客が出てきます。その際正解不正解という考え方をしていると、そういった顧客の使い方を受け入れづらくなってしまいます。

このような事態を防ぐため、私がプロダクトマネジメントをしている時は「これは私なりの解釈であり、現状私がプロダクトマネジメントをしているので、その解釈でプロダクトを最大化しているにすぎない」と考えていました。つまり、現状はプロダクトマネージャーとして自分の解釈を利用しているのであって、それが自分がプロダクトマネジャーである意義だと考えていました。うまく最大化ができなければ、この解釈に問題があるということであり、その場合自分がプロダクトマネージャーである価値がなくなるということです。役割を降りるか、また別の解釈を利用してプロダクトマネジメントをしていくということになりますが、プロダクトマネジメントを担当している間は自分の解釈を信用して、遂行をしていくということです。

またまた長くなってしまったので続きは第3回で。