前書き
以前、キリスト教の牧師(見習い)からWebエンジニアに転職した話 でエンジニアになった経歴を記事に書きました。その後、自分がどのような歩みをして 資格スクエア の PdM（プロダクトマネージャー）になったか、そして何をしているのか明らかにしていなかったので記事にまとめることにしました。
記事の目的
この記事では以下のことを目的として書いています。
- PdM になりたい方に向けた情報共有（経緯と役割）
- PdM を始めたばかりの方に向けた情報共有（役立った本と実践して良かったこと）
- エンジニアのキャリアをどうするか考えている方への指針（PdM のメリット・デメリットや適正の考察）
エンジニア時代
2016年10月〜2019年6月まで約2年9ヶ月、資格スクエアのWebエンジニアとして、主にサーバサイド（Ruby on Rails）を担当しながらフロントからインフラまでサービス全体に携わる開発をやっていました。その中で大きめの開発としてやったことは以下になります。
- YouTube から API で動画を取得する定期バッチの実装
- 学習進捗メールを SendGrid 経由で送信する実装
- アンケート機能の実装
- 検定機能の実装
- 問題演習アプリの API を実装
他にも事業側依頼の開発やエラー対応、管理画面の整備と資格スクエアのほぼすべての機能に触れながら開発していました。
PdM になる背景
弊社では、2019年3月に新規サービスとして NINJA SIGN の開発が始まりました。@yokozawa0701 さん（尊敬するマネージャーです）が資格スクエアの PdM をやりながら、NINJA SIGN の PO（プロダクトオーナー）を兼務することになったのですが、さすがに2つのプロダクトを見ているので業務量が半端なく NINJA SIGN の開発進捗がなかなか加速しませんでした。
そこで社長の判断により、@yokozawa0701 さんは資格スクエアの PdM から外れ、NINJA SIGN に専念することになったのです。
その空いた PdM の候補として自分の名前が上がり、話がありました。
社長から「資格スクエアの PdM をやってもらえないか？」と話があった時、自分では PdM になる強い希望はありませんでしたが、29歳で未経験に関わらずエンジニアとして採用してくれた感謝と、牧師時代に経験したマネージメントが PdM として活かせるかもしれないと思い、その場で快諾しました。
そして、2019年7月から資格スクエアの PdM としての役割を担うことになったのです。
PdM の役割
これは資格スクエアの場合ですが、基本的には以下のように事業チーム（営業・マーケティング・CS）とエンジニアチーム（開発）の間に入って、プロダクトの開発・運用・保守が円滑に進むようにマネージメントしています。その中でも EM（エンジニアリングマネージャー）の役割が割合としては大きいです。
具体的な役割は以下です。
事業チームに対して
- 営業から受ける開発依頼の要件を質問しながら最適にまとめる
- マーケティングから分析方法などの相談を受けて解決する
- CSから受けるお客様の不具合やエラー調査、ご要望を解決する
エンジニアチームに対して
- プロダクトの方向性を伝達する
- プロダクト仕様の質問に答える
- 開発・実装の相談を受けた際、判断して決定する
- 心理的安全性を高い状態にする
- 開発がスムーズにできるようサポートする（レビューなど）
PdM をやる上で必要な要素
上記の役割を全うするために、PdM を実際にやって以下の3つが重要だと感じました。
- プロダクトに精通している
- エンジニアリングを理解している
- コミュニケーション能力がある
詳細は以下です。
1. プロダクトに精通している
プロダクトに精通していないと事業チームとエンジニアチームから来る質問に迅速かつ正確に答えることができません。ですが、仕様を把握していれば質問を受けてもその場で返答することができるので、スピーディーに業務を遂行することができます。
2. エンジニアリングを理解している
エンジニアリングを理解していないとエンジニアチームと一緒にプロダクトを改善していくことが難しいです。PdM はエンジニアチームと実装・アーキテクチャの質問や相談から始まって、プルリクエストのレビューまでやるので、プロダクトを改善していくにはエンジニアリングの理解が重要です。
3. コミュニケーション能力がある
コミュニケーション能力がないとチーム間でのやり取りに時間が掛かったり、要望に応えられません。ですが、コミュニケーション能力がしっかりしていれば、事業チームの本質的な要求が何であるか質問しながら正確に捉えつつ実装コストが最適になる点で合意したり、エンジニアチームがストレスを感じにくい状態で開発できるようになります。
PdM になってチャレンジしたこと
PdM になって @yokozawa0701 さんが担っていた役割を引き継ぎつつ、さらに良いものへと昇華させるために本を読んで勉強しつつ、新しいことにもチャレンジしました。
自分自身が取り組んだことは以下の3つになります。
- 定期的な 1 on 1 を行う
- エンジニア文化を制定する
- 積極的に技術トピックを共有する
詳細は以下です。
1. 定期的な 1 on 1 を行う
PdM になった時に、自分がどのような役割を担ったら良いのか明確に言語化できていない状態でした。そこで役立ちそうな本を探したところ、エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイドが見つかりました。
読んだところ、最も重要なことが「1 on 1」であることが書かれてありました。そして、自分がかつて牧師時代に 1 on 1 によるカウンセリングを数多く行っており、その重要性を体験していたため、とても共感できたのです。特に資格スクエアのエンジニアはフルリモートでの開発が OK であるため、信頼関係を築く上で 1 on 1 によるコミュニケーションはとても重要であると判断し、さっそく実行しました。
1 on 1 をやると普段業務で話せないことも含めて本音でコミュニケーションが取れます。その結果、チャットでは伝えにくいことも話せるため、やはり信頼関係を構築する上で非常に重要であると実感しています。
やる頻度はそれぞれの状況を加味しながら判断しており、最頻度の方で約2週間に1回、あとは1-数ヶ月に1回のペースで行っています。1 on 1 を実行してみて、大切なのは画一的に同じ頻度でやるよりも、一人一人の気持ちを尊重しながらお互いが良い関係を築ける頻度でやることだと感じています。
2. エンジニア文化を制定する
次に取り組んだのは「エンジニア文化を制定する」ことです。
これは上記の 1 on 1 からの流れで取り組んだもので、最初の 1 on 1 の時に全員に「資格スクエアのエンジニアチームはどのような良さがありますか？」と聞きました。なぜかと言いますと私自身は資格スクエアのエンジニアチームしか経験してこなかったため、他のチームと比較する軸がなかったからです。
その結果、「お互いを尊重している」「コミュニケーションが取りやすい」「チームの雰囲気が良い。お互いに仲良くやっている」と意見を頂き、チームのお互いが尊重し合い、雰囲気の良い文化があることを見えてきました。
ちょうどその頃に Team Geek ―Googleのギークたちはいかにしてチームを作るのか という本を読んだのです。
この本の中では「素晴らしいチーム文化を作る」という内容が書いてあり、今のチームにある文化を言語化し、それが守られることが重要だと感じました。
そして、本内容とチームの状況を含めて「尊敬」というエンジニア文化を制定しました。その後、時間が掛けながら「感謝」や「称賛」といった複数の文化を付け加えて、今のエンジニア文化を作り上げてきました。
具体的には、以下のようなものです。
エンジニア文化
※ 文章として長いので別リンクとさせて頂きます
エンジニア文化を制定した経験からわかったことは文化をゼロから生み出すのは難しいです。それよりも、チームの誰か1人が持っている良い特徴を模範とし、全員がそれを身に付ける方が素早く浸透して文化としてしっかり根付きます。
そして、文化として根付くと後からチームに加わった方でも自然とそれに倣って良い雰囲気を保つことができます。
3. 積極的に技術トピックを共有する
さらに取り組んだことは「積極的に技術トピックを共有する」ことです。
資格スクエアでは開発手法にアジャイルを採用しており、営業日は朝会（スタンドアップMTG）を行っています。大体15分以内で情報共有を行ってから、1日の業務を始めます。
自分が技術記事が好きなこともあり、PdM として朝会の司会をしながら最後に3分以内で気になった技術トピックを共有することにしました。狙いとしては以下です。
- チームが新しい技術や知識に触れて新鮮な気持ちになる
- 雑談が生まれるキカッケを作り、メンバーの交流を促す
実際にやってみると、ただ業務報告をするよりも技術トピックを共有した方が朝会の雰囲気も良く、意見交換をしながら新たな知見を得ることができました。
さらに slack 上に技術トピックを共有できるチャンネルを作り、投稿するようにしました。そうすると自然とチームのみんなも投稿を始めて、良質な情報収集ができると共に新たなコミュニケーションが生まれる場となりました。
ちょっとした工夫ですが、効果があってとても良かったです。
PdM のメリット・デメリット
ここまで PdM になった背景や役割、PdM でやったことなどを書きましたが、経験してみてメリットとデメリットを挙げてみます。
メリット
- PdM のパフォーマンスがエンジニアチーム全体に影響を与え、プロダクトの進化を加速させられること
- インフラからフロント、またセキュリティなどサービス運用の全領域で知識が付くこと
- プロダクトに強い責任が生まれ、未来を描く力が付くこと
- マネージメント力が飛躍すること
デメリット
- コードを書く時間が減ること
- 業務量が増えること
個人的に PdM を担っていることは、非常に良い経験だと感じています。自分の場合、技術は好きでもギークではないので、開発だけでチームやプロダクト、さらにユーザーに貢献するのは難しいです。ですが、PdM としてマネージメント力を発揮することでチームをサポートし、プロダクトに貢献することができます。
時にやるべきことが多くて大変な時もありますが、限界を打ち破り、パフォーマンスが引き上げられるので良い経験となっています。
PdM が向いている特徴
最後に自分の経験から PdM に向いている方の特徴を挙げます。
- 技術は好きだけどギークではない
- チームをサポートすることに喜びを感じる
- チームの心理的安全性に関心がある
- プロダクトの未来像を思い描くとワクワクする
- メンタルと責任感が強い
これに当てはまらなくても PdM をすることはもちろん可能です。ですが、上記の特徴がある方は手を動かすエンジニアよりも PdM として役割を担った方がさらに活躍できるのではないかと思っています。
後書き
エンジニアになった頃の自分はスーパーエンジニアのようなギークに憧れていました。ですが、実際に本物のギークと出会うと凄過ぎて「自分はエンジニアなんて名乗れない」と思うほど、心が砕かれましたw（でも諦めていません）
その後 PdM を経験して、エンジニアのキャリアは手を動かすだけでなく、マネージメントでも活躍できることを知り、自分の適性を見出せたように感じます。（でも開発は好きです）
自分の経験から PdM について記事を書いてみました。必ずしも一般的な PdM の内容ではないと思っています。ですが、PdM をやっている方・興味がある方に少しでも役立つ情報があったら幸いです。