🏃‍♀️

エンジニアが「PMも兼任して」と言われたときの心構え

2020/12/17に公開

この記事はプロダクトマネージャー Advent Calendar 2020 17日目の記事です🎄

カンタンに自己紹介

名古屋の企業でフロントエンドエンジニア兼PMをやってます、amakawaです。2年ほど前に事務員からエンジニアに転職して、総勢50名ほどのベンチャーで2年近くバックエンド〜フロントエンドを書きつつ、プロダクトマネジメント・プロジェクトマネジメント業務も担当してきました。
東京へ転居して、2月からディレクターとしてプロダクトマネジメント・プロジェクトマネジメントをメインにやっていく予定です。

どうしてこの記事を書いたか

弊社は少人数のベンチャーということもあり、1人のエンジニアが複数プロダクトの開発を兼任します。さらに専任のPMはいないので、エンジニア・デザイナーは自然とプロダクトマネジメント・プロジェクトマネジメントをやることになります。私も社内ツールを2、3つほど保守しつつPMをやってました。

しかし、世間に出ているプロダクトマネジメント・プロジェクトマネジメントに関する情報はPMを兼任するパターンをあまり想定してません。正式にアサインされ1プロダクトにじっくり向き合えるPMと、複数プロダクトを保守しつつエンジニアも兼任するPMでは使えるリソースや権限が違います。
そのため、兼任PMだからこその悩みがあったり、世間に出ている情報では前提条件が違いすぎて参考にならないこともあります。

この記事ではテーマをあえて「エンジニア兼任PM」に絞って、兼任だからこそ気をつけていたこと、兼任でも開発や運用を回すためにやっていたことをまとめました。

(PMの業務範囲は企業によって違いますが、弊社はプロジェクトマネジメントとプロダクトマネジメント両方をやっていたので、この記事での「PM」「PM業務」は両方を指しています)

こんな人に読んでもらいたい

「PMもやって」と言われたエンジニア
PMではないけどプロジェクトマネジメントやプロダクトマネジメントもやっている「実質PM」なエンジニア

心構え

エンジニア業務よりもPM業務を優先する

最優先はプロダクトとチーム

「今日は自分がアサインされてるissueをやるぞ！」と決めた日に「仕様について相談する時間が欲しいです」と言われた場合、どちらを優先しますか？
私の場合、後者を優先します。

自分が担当しているissueが進まないのはエンジニアにとってストレスですが、PMの役割を少しでも担うならば優先すべきは個人の成果よりもチームの成果です。というより、自分も含めたチームの成果が、自分の成果になると考えています。

PM業務を優先して自分のissueが解消できなければ他のメンバーにお願いすることも可能です。しかし打ち合わせやスケジュール管理を他のエンジニアやデザイナーに頼むのは、持っている情報の差や言語化できないコツがあることからやや難しいと感じます。

PM業務>エンジニア業務を念頭に、自分がボトルネックにならないことを最優先に柔軟に動くのが大切です。
ちなみに、リソース的にコードを書けない場合のことを考えると、自分より優秀なエンジニアがチームにいることが望ましいです。単純に、一番できるエンジニアにPMもやってもらおうと考えると結果的にその人がボトルネックになる気がします。

達成度のわかりやすさに惹かれない

仕様の詰めやスケジュールの見直しが必要なのに、目の前のissueをやりたい...。その気持ちは「やった感」の分かりやすさも関連していると感じます。

エンジニア業務は潰したissueの数や作った機能など成果がわかりやすい上に、同じエンジニアであればその価値がわかります。しかし、PMは業務内容が曖昧な上にチームに1人しかいないので大変さを共有できるメンバーがいません。仕様書とDB構成を見て半日溶けると、自分でも本当に何やってたんだ？となります。

しかし、ここで「〇〇やりました！」と言いたい気持ちを優先すると上記に書いた「最優先はプロダクトとチーム」ができなくなります。
達成感を得るために目の前のissueを片付けるのではなく、プロダクトとチーム全体を見た上で優先すべきことをやらなければいけません。そして、理解してもらいにくいからこそ「仕様書とDB構成の確認をしてました」だけではなくて、「現在のDB構成だと新機能のリリース後に他ツールとデータ連携ができなくなるリスクがあったので、仕様書と照らし合わせて確認していた」というように自分の作業の内容と意味を説明出来る必要があります。

エンジニアの自分とPMの自分を分ける

二重人格を作る

昨年の記事にも少し書いたのですが、実装のしやすさを優先して機能を削るなど過度な守りに入るのは絶対いけません。エンジニア兼PMがやりがちな失敗かと思いますが、これではエンジニアがPMを兼任することがマイナスに働きます。

もちろん作業工数の見積もりや実現可能性を考える上で実装のしやすさを見ることは必要ですが、「エンジニアの自分」にそれらの情報を提供されたら、決定するのは「PMの自分」です。そして、技術が分かるからこそ、エンジニア兼PMが難しい実装を要求する際はメンバーからはしっかりとした説明が求められるかと思います。このときも「エンジニアの自分」「PMの自分」がどう考えて、最終的にどちらがどのような根拠で決定したかを分けて説明すると分かりやすいかもしれません。

エンジニアとしての評価とPMとしての評価を分ける

これは私も悩んでいるのですが、PM業務に時間を使う以上エンジニアスキルの伸びが遅くなるのは避けられません。個人開発をしたり通勤時間に本を読んできましたが、それでも経験年数に見合った技術が身についているかは常に不安です。

しかし、使う時間が他のエンジニアより少ないのだから仕方ありません。必要以上に不安になったり、特に他のエンジニアと自分を比べるのは危険かと思います。エンジニアのスキルとPMとしてのスキルを分けて、自分がそれぞれ何が出来るようになりたいかをイメージし、そこに向かっていれば良いと考えています。社内での評価も、エンジニア・PMで分けてもらえると業務の割り振りや評価基準がしやすくなって良いかもしれません。

私も当初は、PMになってもスキル面で後輩に絶対負けない！くらいの対抗心を燃やしてましたが、チームでの成果を意識し始めてからは、スキル面で抜かされたら後輩に教えてもらおうくらいの気持ちです。そう考え方を変えると、自分がやりたい作業でも後輩のスキルアップに繋がりそうならチャレンジしてもらう、という判断がためらいなくできるようになります。

もしスキルの伸びが少しでも遅くなることが受け入れられない場合、自分が追い込まれるか、エンジニア業務を優先した結果チーム崩壊の２択な気がするので早めにチームで話し合いましょう。

巻き込み力だけでなく「巻き込まれ力」が大切

エンジニアに与えられない情報を取りに行く

「エンジニア兼PM」「実質PM」がたくさんいる企業の場合、社内でそもそもプロダクトマネジメント・プロジェクトマネジメントの大切さが認知されていないケースもあります。

その場合、エンジニア兼PMもチーム外ではただの「エンジニア」として認識され、プロダクトの今後にとって重要な情報も「運用フローが固まってからエンジニアに伝えればいいや」というようになかなか回ってこないことがあります。必要な情報は取りに行くと同時に、プロダクトに影響がありそうな情報や決定が確実に開発チーム内に回ってくるように交渉するのが大切です。ここを怠ると、社内ですでに決まった仕様をチームに流すだけのPMになってしまい、開発チームがつらい思いをします。

私の場合、自分が担当しているツール名がslack内で使われるとメンションが飛んでくるように設定しています。こうすることで、新しい運用ルールが作られたり、別チーム内で起きている問題がすぐに分かります。おせっかいの一歩手前を狙って、積極的に巻き込まれていくことが重要です。

おわりに: エンジニア兼PMっていいことあるの？

2年やってみて思いますが、エンジニア兼PMは独特の難しさがあると感じます。同様の話をLTでした際にも実況ツイートで「つらそう」とだけ言われたことがあり、ハズレくじのイメージもあるのかもしれません😭

確かにどちらも片手間にはできない仕事なので、常にやることを選択して限られた時間の中で実行しなければいけません。それでもなお、スキルの伸びやキャリアに関する悩みがあります。

それでも、エンジニアがPMを経験できるのは非常に良い機会です。考えることの量・視点・時間感覚・深度すべてがPM経験を通して広がり、エンジニア以前にサービス作りに関わる人としてのスキルが上がると思っています。最終的にエンジニアとPMどちらの道を選んでも、自分が担当するサービスをよりユーザーにとって価値のあるものに成長させ、サービス作りをもっと楽しめるようになると考えています。

また、PMを専任で置くほどマネジメントの仕事がない企業で働く場合、キャリアを広げる良い機会になります。私はディレクターとしてもっとプロジェクトマネジメント・プロダクトマネジメントを極める道を選びましたが、エンジニアとして入社した際はPMの存在さえ知りませんでしたし、もし専任でPMを置く企業に入っていたら1年目からPMを担当できることはなかったはずです。

今回の記事が、エンジニア兼PMとして働く人の参考になると共に、「PMやってみない？」と言われた時にポジティブに挑戦できる人がもっと増えたらと思います！