Sansan Tech Blog

Sansanのものづくりを支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信

元開発者の、プロダクトマネージャーへの第一歩

Sansan 事業部でプロダクトマネージャーをしております、熊崎と申します。
プロダクトマネージャーといってもまだまだひよっ子です。

開発者 -> プロダクトマネージャー -> 開発者 -> プロダクトマネージャー

と経歴の変遷を経ているのでプロダクトマネージャーという肩書を得たのは2度目。

1度目の時は十分に稼働できていなかった経験があり、それに対して2度目の今は割とうまくいっている自負が得られており、「その違いって何だろう」と考え始めたのが本記事を書くきっかけとなりました。
これからプロダクトマネージャーを目指す開発者にとっての一助となれば幸いです。

はじめに

私がプロダクトマネージャーという肩書を初めて得たのは2014年。
当時は組織の規模も製品の規模も今と比べて左程大きくなく、創業時からずっと役員がプロダクトマネージャーの責務を持っている状況でした。
私は開発者として籍を置いていたわけですが、会社として「今後の組織や製品のスケールを見据えて、専任のプロダクトマネージャーを立てていこう」という方針となり、それが転身するきっかけとなったのです。

開発者からプロダクトマネージャーに転身した際、以下の疑問が脳裏をよぎりました。

「プロダクトマネージャーって何をする仕事だ ?」

なる前に考えておけよって話ですが、発令がわりと急だったのを言い訳とさせていただきます。
社内でプロダクトマネージャーという職種が立ち上がって間もなかったので周囲にも知見がなく、文献を漁って巡り合ったのが「Inspired: 顧客の心を捉える製品の創り方」。長年愛されている良書です。
私も本書をバイブルとしており、本記事でも何度か引用させていただきます。

プロダクトマネージャーの主な任務としては2つある。製品の市場性を評価することと、開発すべき製品を定義することである。
by Inspired


「なる程凄そう」

開発にしか携わってこなかった私は初めて読んだとき、とても遠い未来の話のように思いました。結局この時は目の前の仕事に追われるまま闇雲に手を動かしてしまい、プロダクトマネージャーという仕事の輪郭を掴めなかったのです。

その時から5年。3年ほどで一度開発者に戻ったので、プロダクトマネージャーとしては実質2年ほどの経験を得ました。
現在でも「Inspired」に書かれていることの20%くらいしか実践できていませんが、未熟であるものの「自分がプロダクトマネージャー足り得ている」と実感できるくらいにプロダクトマネージャーの正体が見えてきました。
本記事では私が考える「元開発者の、プロダクトマネージャーへの第一歩」として、「プロダクトマネージャーの4つの仕事」を述べたいと思います。

尚、本記事ではプロダクトマネージャーの仕事について述べさせていただきますが、以下コンテキストが多分に含まれていること、ご留意ください。

  • 携わっている製品は企業向けソフトウェア (B to B クラウドサービス) である。
  • 製品の新規立ち上げではなく、既存製品の改善が担当範囲である。

プロダクトマネージャーの4つの仕事

  1. 製品が解決すべき課題を積む
  2. 課題の解決策を見つけ出す
  3. 開発リソースの責任者に説明して解決策を開発計画に載せる
  4. 世に出す前に課題解決足りうるか判断し、出す出さないの意思決定を下す

1. 製品が解決すべき課題を積む

プロダクトマネージャーになって真っ先に行うべきは製品が解決すべき課題を積むことです。
先ずはユーザーを知りに行くことから始めるのが良いでしょう。

ユーザーを深く理解することなく、ユーザーに愛される製品を作る方法があるとは思えない
by Inspired

開発畑の人間としてはここで一気に腰が重くなりますね。私はなりました。
しかし、プロダクトマネージャーになるには乗り越えなければならない壁だと思います。ユーザーを知らなければ、良い製品を作るために必要な情報を得られません。

ユーザーとは接触するな、と言い渡されるような会社で働いているならば (中略)
方針を変えるようにがんばって (中略)
うまくいかないなら、履歴書を引っ張り出して (中略)
職場を探そう
by Inspired

Inspired にはプロダクトマネージャーとして必須な行動の一つとして挙げられてます。私もそう感じてます。(寧ろ経験を得るにつれ、ユーザーが気付きの宝庫に見えてくることでしょう。)
ユーザーと直に接している営業やカスタマーサクセスの方々から声を集めるのも良いですが、既存製品であれば先ずユーザーに目の前で触ってもらうことをお勧めします。

一例ですが、「このプロダクトを使って普段のように○○してください」と言って使ってもらいます。
そうすると、「ここで表計算ソフトに頼ってしまうのか」「ここで Google 検索に逸れてしまうのか」「諸々製品で解決すべきではないだろうか」と様々な気付きが得られるわけです。

ただし、たとえ多くのユーザーが求めていたとしても、○○機能が欲しいと言われたそのままに実装すべきでないことは言うまでもありません。

自分が本当にほしいものは何かをユーザーが知っているのであれば、ソフトウェアを作ることはずっと簡単だろう
by Inspired

仕様を受け取って開発することに慣れていると、解決策から先に考える思考にも陥りがちです。
真っ先に向き合うのべきは課題であって、解決策ではありません。

「どういう課題を解決したいんだっけ ?」
と問い続けることが大切です。

冒頭でプロダクトマネージャーの任務として製品の市場性評価を引用しましたが、既存製品のユーザーインタビューは小さな市場性評価だと考えております。

2. 課題の解決策を見つけ出す

課題が明確になったら、デザイナーや時には開発者の力を借りて、その課題がどのように解決されるべきか、つまり製品仕様がどうあるべきかを見つけ出します。
この工程は、場合によっては非常に時間が掛かることを覚悟する必要があります。

製品を見つけ出すプロセスは、私たちが望むほどには予測可能ではない
by Inspired

私の経験だと解決策を見つけ出すのに数ヶ月や1年近く掛かったケースが存在します。
解決策が見つからない期間はとてつもないプレッシャーが掛かるので、目先の中途半端な解決策のようなものに飛びつきたい衝動にかられます。
しかし、中途半端な解決策を以て開発工程に進んだ場合に、より多くの開発コストを犠牲にしてしまうことを考えると、ここでまっとうな解決策を見つけ出せるまで向き合うべきなのです。

3. 開発リソースの責任者に説明して解決策を開発計画に載せる

当然積まれた課題の解決策は開発者の力を借りて製品化していく必要があります。
しかし、開発リソースは無限にあるわけではありません。多くの課題が積まれた場合、取捨選択が行われるわけですが、そこで「何故その課題を解決しなければならないのか」を説明する責任が生じます。

ここでは開発リソースの責任者と判断基準を予めすり合わせておくとスムーズに事が運びます。市場性評価や既存製品の KPI を使って課題の重要性を説明することを求められるかもしれません。
開発リソースの責任者が OK と言えば開発工程に進めるし、NG といえば開発工程に載らない事実は変わらないため、彼ら彼女らがどういった説明を求めるのかを把握し、すり合わせておく必要があるのです。

尚、弊組織では有用性 (NPS への貢献度)/経済性 (売り上げへの貢献度)/技術評価 (製品開発運用への貢献度) の3軸で評価したのち、最後は責任者の好みで判断することになってます。完全ロジカルに課題を取捨選択できる判断基準を設けることは不可能という結論になっているためです。

得てして「この課題は優先度高く解決すべきか」という問いは難しく、明確な結論が出ないことも多いため、プロダクトマネージャーを始めたときに乗り越えるべき壁になるかもしれません。
私は今でもこの問いに関してはとにかく課題を積んで、後は当たって砕けるしかない、と考えております。

補足

実は「2. 課題の解決策を見つけ出す」と「3. 開発リソースの責任者に説明して解決策を開発計画に載せる」の工程は完全に直列になるものではありません。
折角苦労して課題の解決策を見つけて積んだとしても、開発計画に載らなければ水泡に帰すだけですし、かといって解決策が見えていなければ開発の目戸も立てられず、計画に載せられないためです。
弊組織では課題と、ある程度現実味のある解決策を持って計画に載せることになってます。
なので、徹底的に解決策に向き合うのは計画に載った後に行います。ここでいう計画とは向こう3ヵ月のうちに解決したい課題として積まれるだけで、明確なリソース確保等はさらにその後になります。
何故なら「2. 課題の解決策を見つけ出す」で記述した通り、解決策を見つけ出す工程は予測可能ではないためです。

4. 世に出す前に課題解決足りうるか判断し、出す出さないの意思決定を下す

アジャイルでいうところのスプリントレビュー、ウォーターフォールでいうところの受け入れにあたります。

これならユーザーにリリースしても大丈夫、というレベルの機能性を確保するのがプロダクトマネージャーの仕事である
by Inspired

課題の解決策が製品に組み込まれ世に出ることにより、自分が積んだ課題が本当に解決されるに足りうる状態か、世に出していいものか最終判断して責任を持つのもプロダクトマネージャーの責務です。

この工程もプロダクトマネージャーを始めた頃は「本当に世に出して大丈夫か ?」という戸惑いが頭をもたげ、ユーザーへの影響を考えると恐怖で足がすくむ思いをしたものです。
可能であれば、初めのうちは先輩のプロダクトマネージャーに同席してもらい、意思決定に付き合ってもらうのがベストです。世に出る前の成果物を見る目線も、積み重ねで養っていくしかありませんので。

私の場合、創業からプロダクトマネージャーの責務を持っていた役員が最終意思決定者だったため、そこで多くの学びを得ることができました。

おわりに

プロダクトマネージャーの4つの仕事を紹介させていただきました。大掛かりなことを考えなくても、小さな課題から着実に解決していけば自ずと仕事に慣れていき、より大きな課題に取り組めるようになっていくはずです。
そこではよりコストを掛けた市場性評価やユーザーテスト等、専門的な技能を要するようになるかもしれませんが、4つの仕事をこなすという意味で大枠は変わらないと考えております。

開発者として既存製品に携わったことがあるのであれば、その時点で少なからず製品の課題に心当たりがあるのではないでしょうか ?
もしプロダクトマネージャーになったなら、そこから取り組んでいくのも良いでしょう。

プロダクトマネージャーへの第一歩として先ずは焦らず小さく仕事を回すこと。それが肝心です。



buildersbox.corp-sansan.com
buildersbox.corp-sansan.com

© Sansan, Inc.