この記事は freee Engineers Advent Calendarの15日目です。
こんにちは。freeeでプロダクトマネージャー兼エンジニアをしています @tetsuwada と申します。
freeeにはプロダクトマネージメントの専門チームがあり、「ユーザーの本質的な課題から正しいプロダクトビジョンを導き出し、社内外にムーブメントを生み出す核となる」というミッションを掲げています。
このチームで私はエンジニアのバックグラウンドを活かしてプロダクトマネージャー兼エンジニアをしています（チームには開発はしないメンバーの方が多いです）。
ここでは私のこれまでの学びと反省から、プロダクトマネージャー（以降PM）とエンジニアを兼務するなら気をつけたい３つのことを共有したいと思います。
1. 自身の開発速度をトラックする
PMのメインの仕事はプロダクトの方向性や解くべき課題を定義すること、つまり何をつくるかを決めることです。それらを決めたら後はひたすら開発に専念できると思われがち、というか私自身そう思っていました。しかし実際にはPMは”center of communication”と呼ばれることもあるように、常に様々なコミュニケーションと意思決定が必要になります。
これは子育てしながら仕事をする感覚に似ています。子供が寝付いたら２〜３時間は寝るのだから、その間に仕事できるでしょ？と思われることもありますが、実際にやってみるとそうはいきません。
例えば具体的に開発が始まった場合、詳細な仕様についての意思決定が常に必要になります。最初のリリースまでにどのレベルの完成度を指すべきか、やらないことはなにか、どんな技術やUXにするか、本当にそれがベストなのか？などなど様々ありますし、マーケティングやサポート、セールスなど他の組織とのコミュニケーションも多々発生します。
なので、自身のエンジニアリングに対する見積もりはエンジニアに専念していたときより余分に見積もる必要があります。そのためにも、常に自身の開発のベロシティを計測して、PMを兼務する中でどの程度の開発スピードを出せるのか把握すべきです。
とはいえ開発のまとまった時間は確保したいものです。私の場合はまずミーティングを減らすことが効果的でした。影響の少ないミーティングは出ない（議事録で後でフォローするなど）、ミーティングの時間を短くする、連続で設定し隙間時間をつくらない、というのを関係者にもお願いして、減らしていくのがシンプルながらおすすめです。後はメールやSlackは一旦閉じて、決まった時間にだけチェックする（関係者には事前に連絡しておく）というのも効果的です。
2. 実現したいユーザー価値にとことんフォーカスする
PMとしては理想を追い求めたい気持ちがどうしても大きくなります。一方で、エンジニアとしてはあれもこれもやるというわけにはいきません。ましてやPMとエンジニアを兼務する状況は開発リソースが限られていることが多いでしょうから、なおさらこのトレードオフは強くなります。
これに対しては、PMとしての視点から本当に届けたいユーザー価値をとことん突き詰めることが大切です。その上で必要のないものはけずり、どうしても必要があるが今のままではできないのであれば、一旦自身の開発の手は止めてでも、それを実現できる可能性を探るべきです。
また、実現したいユーザー価値にとことんフォーカスする上でコミュニケーションをおろそかにすべきではありません。PMである以上、自分からコミュニケーションしていかないと自分が考えている価値はメンバーに伝わりませんし、認識の相違が起きるととたんにゼロからのスタートになってしまいます。
これに関しては、小さなチームであっても何を実現するのか、やるべきことやるべきでないことは何かをドキュメント化するのがよいと思います。freeeでは神ドキュメントという簡単なドキュメントにこれらを明記し、プロジェクトが進む間常にアップデートするようにしています。
3. 一人でできることは限られていると自覚する
上記の通り、実際にPMを兼務すると思っていた以上にやるべきことが多いです。自身の生産性を10%上げれば済むのであれば努力でどうにかなるものの、明らかに200%はあげないといけないといった場合にはいち早く周囲のサポートを求めるべきです。エンジニアとしてはつい自分が頑張ってなんとかしようと考えてしまうことがありますが、PMである以上はプロダクトを成功に導くことが全てです。プロダクトが成功するためであれば、無理な場合にはそれを認めるのが正義です。１人でできることは結局限られるので、頼れるところは周りにどんどん頼っていくべきだと思います。
そのためにも、できるだけ成果物や状況を広く共有しておくことが効果的だと思います。そうすることで自分では気がつかなかった点をフォローしてもらえたりすることがあります。
また、常に計画的であるべきです。やるべきタスクと計画が見える化されていることで必要以上に不安を持たなくなりますし、どういったサポートがどの程度必要かの話もしやすくなります。
プロダクトマネージャがエンジニアを兼務すべきかどうかの指標
プロダクトマネージャーの役割は組織やその状況に応じて様々変化するため定義が難しい役職です。PMという肩書はついていなくても、実質PMとしての職務をこなしている方も多いと思います。そういった明確な定義が難しい中でも、ユーザーに価値を届ける責任者であるという点は共通しています。PMがエンジニアリングをすべきか？というのはたびたび議論にあがる話しですが、エンジニアリングはユーザーに価値を届けるための手段なので、自身がエンジニアリングすることがユーザーに価値を届けるために最適な手段かどうか、というのが唯一の判断のポイントになると思っています。
PM兼エンジニアで得られるもの
PMがエンジニアリングを兼務することによって、サービスの詳細までとことんコミットすることができます。神は細部に宿るので、開発メンバーとともに細部にまでこだわってつくりあげることでより良いプロダクトになる可能性は高くなります。また、開発メンバーと常に状況や課題を共有できるので、開発上のコミュニケーションコストが少なく、チームとしても高い一体感を持つことができます。特にサービスの立ち上げ時など、プロダクトに魂をこめていく 段階でPM兼エンジニアがいるのはとても心強いのではないでしょうか。
一方で、開発にどっぷりつかると先々のことになかなか意識が向かなくなることもあります。ですので、ユーザーに価値を届けるために最適かどうかはプロダクトの規模やフェーズに依存することが多く、それに併せて自身のエンジニアリングの役割や担当範囲を柔軟に変えていく、ということが重要になると考えています。
PM兼エンジニアということは、何をつくるかを定義するところから、それを実現するまでの責任を持つことになります。どちらが失敗しても自分の責任です。そのプレッシャーは大きいものの、逆に言えば自分の裁量で思うようにできるという大きな自由があり、最後までやり遂げたときの喜びは格別です。
元BLUE HEARTSの甲本ヒロトの言葉で、「楽と楽しいは違うよ」というものがあります。PM兼エンジニアにはまさにそれを体感する醍醐味があると思います。
最後に
freeeではスモールビジネスに携わる全ての人に価値を届けたいプロダクトマネージャーを募集しています（開発ができる必要はありません）
明日は辛い(つらい)ことは大嫌い、辛い(からい)ものが大好きなSGGH（スーパーグレート業務ハッカー）の @miry さんの登場です。お楽しみに