エンジニアからプロダクトマネージャーになるときにやること
今日は自分がエンジニアからプロダクトマネージャーと言う役割を担うことになったときの話をします。FiNC Developer Advent Calendar 2016 11日目の記事です。
最近日本のソフトウェア界隈でもよく聞くようになったPM=Product Managerという職種ですが、エンジニアから実際どうやってジョブチェンジしていくの？って話はあまり聞いたことがないので書いてみます。
- 「プロダクトマネージャー(PM)とは」を知る
- 事前準備
- プロダクトマネージャーとしてやること
- やってみてわかったこと
1.「プロダクトマネージャーとは」を知る
まずは王道に、その職種の役割を理解しましょう。
最初に言っておくと、この定義は実際の現場によってある程度かわることが多いようです。ですがまずはメジャーなPMの役割を知っておきましょう。
結論自分の解釈では、プロダクトマネージャーは「ユーザーに製品の価値を届ける責任を持つ人」であり、そのために「何を創るべきか・作らないべきかを決める人」であると同時に「誰よりもその製品・ユーザーについて考え、誰よりも情熱・信念を持っている人」だと思います。
とわいえ、プロダクトマネージャーとは論は、自分より経験豊富な方々の書籍や記事が沢山ありますので、それらから学ぶのが一番です。
必読
推奨
世界で闘うプロダクトマネジャーになるための本 トップIT企業のPMとして就職する方法
プロダクトマネジャーの教科書 | Linda Gorchels, 新井 宏征 |本 | 通販 | Amazon
「Inspired」は、「プロダクトマネージャー」でググれば必ずどこかででてくる本です。プロダクトマネージャーの定義から、実際にPMとしてやるべきこと、具体的な製品づくりまで広く必要なことが書かれています。
印象的な最初の一節は
私はソフトウェアエンジニアを経てプロダクトマネジメントの道に進んだが、それはみんなに愛される製品、つまり、みんなをワクワクさせる、本当に価値のある製品のために働きたいと思ったからである。
で、まさにこれが自分がPMに足を突っ込もうと思った理由であり、これをよんでいるソフトウェアエンジニアの方、PMの方はみな共感する部分かと思います。
そんなにボリュームのある本でもないので、まずは数冊読んで、世間がいうPMとはなにかを知り、プロジェクトマネージャーとは違うプロダクトマネージャーの役割をちゃんと言語化できるようになりましょう。
その他、ネット上の記事にも今年に入って多く情報が出てきたので読んでおきましょう。エンジニア出身の方も多いので参考になります。
参考記事
公開資料まとめ | プロダクトマネージャ―カンファレンス 2016
伊藤直也氏がプロダクトマネジャーの役割を学んだ良書5選と、適材を見極めるポイント — エンジニアtype | 転職＠type
「Inspired: 顧客の心を捉える製品の創り方」を読んだ — 29%の純情な感情
エンジニアからみた良いプロダクトマネージャとは？ — サンフランシスコではたらくソフトウェアエンジニア — Higepon’s blog
プロダクトマネージャーはビジョナリーであれ！土屋尚史×田川啓介×坂本登史文×犬飼敏貴×及川卓也 | CAREER HACK
他にもググればでてきます｜プロダクトマネージャー — Google 検索
2.事前準備
事前知識を得たとして、さてPMを始めようとなりますが、いきなり「プロダクトステートメントを決めよう」とか「製品ロードマップをひこう」と思ってもできません。あまり本には（当たり前すぎるのか）書いてませんが、その前にかならずやるべきことがあります。
「お客様」を知る
エンジニアからPMをするなら、まずはここを重点的にやっておく必要があるでしょう。
エンジニアという枠をでて、よりお客様の近くに身をおき、直接話したり、データを見たり、調査をして、実際に自分たちのターゲットのことを今まで以上に知る必要があります。
あたりまえのことですが、ここの深さやベクトルの正しさが、結局はPMとしてのアウトプットの質に大きく影響するので、初心に帰って、ユーザーのことを徹底的に知ることから始めるのがいいでしょう。
自分の場合は、ToB向け製品を扱っているので、法人のお客様との商談に参加し話すのはもちろん、営業チームやCSチームの人とも話し、今自分たちが相手にしているユーザーを知るところからはじめました。思った以上にエンジニアとして知っていたユーザー像と実際のユーザーの間にギャップがあることに気づいたり、まだチーム全体として顧客理解がたりないことに気づいたりします。
いわゆるリーンな製品開発でいう「顧客学習」に近いですが、最初もその後も継続的にお客様を知ることが大事になります。
「チーム」を知る
PMの責務がユーザーに価値を届けることだとすると、なにかを決めることを同じくらい、それをいかに早く正確に実行することが重要ですが、そのベースには自分たちのチームを知る必要があります。
いわゆるマネジメントですが、PMはエンジニアチームだけでなく、実行に係る関係者すべてをなるべく知っておく必要があります。この関係性の質は、実行のスピードやクオリティ、つまりお客様に実際に提供される価値に間接的にですが大きく影響してくる部分だと思います。
とはいってもやることはとてもシンプルで、まずはメンバーみんなとちゃんと対話して、プロダクトについてどう思っているか、なにをモチベーションに、使命として働いているかを知ることからやればいいと思います。
エンジニアをマネジメントする場合も同様だと思いますが、この信頼関係の太さがExecutionに大きく影響します。誰だって信頼できない人に指示されても心から頑張れませんよね、PMの場合はより広範囲にメンバーが広がる分、さらに重要になっていきます。
3. PMとしてやること
事細かにいくといろいろなことがあると思いますが、ざっくり最初に知っておくとよいPMの役割を整理します。
指針を決める
いわゆる、vision, mission, 製品ステートメントの類のものです。これを指針にプロダクトに関する意思決定をしていくのが理想であり、その軸を決めるのがまずPMの仕事と言われます。
プロダクトのフェーズによっては、引き継いだので最初からあるケースもあるかもしれませんが、ない場合やワークしていない場合は、しっかりここを決めることにフォーカスしたいところです。
ステートメントのイメージは深津さんのこの記事が参考になります。
アプリ製作のための定義ステートメント共有シート | fladdict
自分の場合は、部門のVision/Missionから始め、それに紐付いたかたちで製品のステートメントを定めました。最終的に、フレームワークは↑のものにこだわる必要はなく、最終意思決定者とチームとPMで、共通の認識を明文化することが大事です。
作ってみるとわかるかと思いますが、ゼロから指針を決めるには、事前準備に書いたようにお客様・チーム、さらには会社のゴールやミッションなども深く理解して、合意形成をとる必要があり、リーダーシップ、ファシリテーション能力、ロジカルシンキングにプレゼン能力まで、エンジニアとは少し違った頭の使い方が求められます。
ロードマップを引く
指針が決まれば次は「なにをするべきか・しないべきか」を決め、製品ロードマップをつくることになるでしょう。これも重要かつ大きな仕事です。
エンジニア出身ならわかると思いますが、企画はもちろんデザインナーエンジニアも、「なぜつくるのか」「今後どうするのか」ということはとても関心のあることで、そこの納得感はチームのパフォーマンスに直結するといっても過言でないです。
startupや新規事業はでは不確実性が多く、難易度が高いですが、それを言い訳につくらないのはよくないので、精度をなるべく上げた仮説で組み立てたり、こまめにアップデートするなどして形骸化せずに作成・浸透させるのがPMの仕事になります。
やる・やらないを決める
指針にそって大小さまざまな判断をすることも役割の一つです。
指針がしっかりあれば、自分ですべてやらなくなることもあると思いますが、なるべく全てを把握しているべきでしょう。
日々の開発サイクルにおける実装項目の決定から、CSから来た想定外ケースへの恒久的な対応まで、日々さまざまな論点が開発チームにはでてきますが、それらを迅速に的確に判断できる人＝PMがいると、製品開発はとてもスムーズに進みます。開発だけでなく、関係者各位にどう共有して認識を合わせるかも、製品価値を最終的にユーザーに届けるためにPMには求められます。
4. やってみてわかったこと
基本的に体験学
エンジニアは多数の書籍からある程度ベースの知識を得ることができ、その積み重ねも重要な要素です。しかしPMはインプットは大事なものの、人や組織を扱う仕事でもあるので、実際にやってみるのが一番だ感じます。なのである程度学んだらまずはプロダクトの方針を自分で考えたり、お客様にあったり、チームで話し合ったりしてみるのがよいです。
自分のタスクは自分できめる
プロダクトマネージャーは、miniCEOとも言われますが、エンジニア時代と違って明確にあなたの仕事をだれかが定義してくれることはありません。より上位の意思決定者がいれば多少オーダーは振ってくるかもしれませんが、製品開発チーム全体で今なにをするべきか、をゼロから考える事自体が仕事ともいえます。
ある程度指針が決まって、実行フェーズに入ればルーチンワークが増えるかもしれませんが、基本的に常に主体的に、ゼロから指針を組み立て、製品チームの仕組みを作っていく必要があります。
師を見つけておく
自分のタスクは自分で決める、といいつつそう簡単にすぐにエンジニアからPMになっていい仕事をするなんてことは実際難しいですし、失敗することのほうが多いです。そのために、アドバイスもらえる身近な師を見つけておくのがいいと思います。FiNCは幸い、経験豊富なProduct Managerが他チームにいたり、技術顧問の方がいたりと、よい師から学ぶ環境があり、初歩的な失敗を事前に防ぐことができたように思います。知らないことを素直に聞くことがやはり大事ですね。
全部を自分でやらない
これもやってみて学んだことであり、腹落ちしたことですが、PMだからといって、全てなんでもできるわけではないことをいい意味で認識してしまうことが大事です。特にエンジニア上がりのPMはすぐに今までずっと仕様を書いているDirectorやPlannerよりアウトプットは遅いでしょうし、すべてをマネージしようとしても限界がきます。
また役割の話だと、エンジニアからだと開発マネージャーとの兼任というケースもありそうですが（自分がまさにそうでした）、これはなるべく早く別の人に役割を移譲したほうがよいと言われます。製品の理想を語り、推進するをミッションとするプロダクトマネージャーと、開発のスケジュールどおりの実行やエンジニア組織の成長をミッションにもつエンジニアマネージャーは、本質的に相反する役割であり、むしろこの2つの役割がコンフリクトすることが、よいプロダクトチームをつくる、と自分の師たちから言われ、まさにそうだなと思っています。
(とは言え）いざとなったらなんでもやる、気持ちも必要
スマートな職種のイメージがありますが、いざとなったら営業にもいくし、CS対応も考えるし、チームの関係性を考えたり、それこそ急ぎのbugfixをしたりと、実際はわりと泥臭いことが多いなと思います。在るべき論とは反しますが、過渡期においては、サービスをよくするためならなんでもやる、その気持ちが必要です。
おわりに
ざっくりですが、自分がPMの役割を果たすためにやってきたことを振り返ってみました。同じような経緯でエンジニアからプロダクトマネージャーをやろうと思った人の役に立てば幸いです。
実際大変ですが、いいものを創ることが一番チームにとっては幸せなので、そこに貢献できることは確実にやりがいのある仕事だと感じます。自分も引き続きいろいろと勉強しながらやっていこうと思います。
