
- はじめに
- PdMを引き受けるまで
- 数字を見ても、答えは簡単に出ない
- アイデアは湧くが、別にやりたいわけではない
- Whyは、案を落とすためのフィルターだった
- プロダクトの見え方が変わった
- 次に同じ立場になる人へ
- おわりに
はじめに
OLTAでエンジニアをしている小林です。
PdMが育休に入ることになり、2ヶ月間、エンジニアの私がPdMを兼務することになりました。
外から見ていたPdMの仕事と、実際に自分でやる仕事とでは、ずいぶん見え方が違いました。特に印象に残ったのは「Why」の使い方です。
Whyは、案を通すための理由ではなく、案を落とすためのフィルターでもある。
この記事では、エンジニアが突然PdMを兼務して気づいたことを、率直に書いてみます。
PdMを引き受けるまで
PdMが育休に入ることは事前に分かっていたため、引き継ぎにはあらかじめ時間を取ってもらいました。
PdMを代わりに担当してほしいという依頼を受けて、引き受けることになりました。
普段、エンジニアとしてチケットに書かれた仕様を実装していると、「何を作るか」は見えても、「なぜこれを今作るのか」「ほかの案ではなく、なぜこれが残ったのか」までは見えないことがあります。
それがどのように決まっているのか一度は決める側から見てみたいと思ったのが引き受けた理由でした。
数字を見ても、答えは簡単に出ない
PdMには、「データを見て合理的に意思決定する」というスマートなイメージがありました。
現実はそんなにきれいではありませんでした。
施策を実施しても、ダッシュボードの数字が劇的に跳ねることは滅多にありません。数字にはノイズもあり、「この変化は、本当に施策によるものなのか」と悩むこともあります。
一方で、数字を追っているからこそ分かることもあります。
大きな変化ではなくても、利用状況を継続的に見ていると、少しずつ変化していることに気づけます。「この機能は、ちゃんと使われている」と確認できることもあります。
劇的ではありません。かなり地味です。
でも、派手な成功体験よりも「自分たちが作ったものを使っている人がいる」という痕跡が見えるくらいが、ちょうどよいのかもしれません。
アイデアは湧くが、別にやりたいわけではない
PdMをやっていると、「こういう機能があったほうがよいかもしれない」「ここは直したほうがよいかもしれない」というアイデアが、なんとなく頭に浮かんできます。
湧いてくるというほど立派なものでもありませんが、エンジニアとして実装を担当していたときより、改善案を考える時間は増えました。
ただ、正直に言うと、そこに「これを是が非でも実現したい」という熱があることは、ほとんどありませんでした。
思いつくことと、自分がやりたいことは別物でした。
最初は、自分の当事者意識が足りないのかもしれないとも思いました。しかし、今は少し違う捉え方をしています。
PdMの仕事は、思いついたことをすべて実現することではありません。むしろ、思いついた案の大半を落とし本当に今取り組むべきものを残す仕事なのだと思います。
Whyは、案を落とすためのフィルターだった
自分の中に「どうしてもやりたい」という強い動機がないなら、何を根拠に「今、これをやる」と決めるのか。
そこで必要になったのがWhyでした。OLTAでは「with Why」をValueの一つとして大切にしています。
以前は、Whyは案を通すために説明するものだと思っていました。しかし実際にPdMをやってみると、案を落とすためにWhyを考える場面も多くありました。
一見すると魅力的な案でも、ユーザーへ届けたい価値や今取り組む理由を言葉にできるとは限りません。「よさそう」と「今やるべき」は別です。
Whyを考えることで思いついた案をそのままチケットにせず一度立ち止まれるようになりました。
フィルターがなければ頭に浮かんだことがすべてチケットになります。それはそれで地獄です。
優先順位を付ける前に、そもそも検討の列へ並べるべき案なのかを考える。そのためにもWhyが必要でした。
逆に、Whyを言葉にできた案は、ほかの人へ説明するときにも詰まりませんでした。うまく説明できないものはだいたい自分でもまだ理解しきれていません。
プロダクトの見え方が変わった
以前は、プロダクトを「チケットに書かれた仕様を実装する対象」として見ることが多かったと思います。
PdMを兼務している間は、「ユーザーが実際に触っているもの」として見る時間が増えました。
もちろん、エンジニアとしてもユーザーを意識していなかったわけではありません。ただ、自分で数字を追い、施策を選び、やらないことを決めると、同じプロダクトでも見える範囲が変わります。
チケットの見え方も変わりました。
チケットに書かれているのは、単なる実装内容ではありません。いくつもの案を検討し、落としたあとに残ったものです。その背景には、誰かが行った意思決定があります。
以前よりは、そのことを想像しながら実装できるようになったと思います。
次に同じ立場になる人へ
2ヶ月という短い期間ではありますが、同じようにエンジニアからPdMを兼務する人へ伝えるなら、次の3つです。
- 最初に「やること」だけでなく「やらないこと」も決める
- 数字が劇的に変わることを期待しすぎず、まずは使われている痕跡を見る
- 迷ったときは「なぜやるか」だけでなく「なぜ今はやらないか」を書いてみる
特に、やらない理由を言葉にすると、自分の考えが足りていない部分が見えてきます。
案を出すことより、案を落とすことのほうが難しい。
おわりに
2ヶ月間PdMを兼務して分かったのは、意思決定のしんどさと、Whyを言葉にする面倒くささです。どちらも、外から見ていたときに想像していた以上に重いものでした。
一方で、この2ヶ月は、単に育休中の業務を引き継いだだけの期間ではなかったとも思います。
育休によって担当者が不在になることは、突然起きることではなく、あらかじめ分かっている予定です。今回は事前に引き継ぎの時間が設けられていたため、安心してPdMの仕事を引き受けることができました。
これまでも、エンジニアとして仕様の検討に関わる機会はありました。ただ、今回の経験を通じて、仕様そのものだけでなく、その背景にある優先順位や「何をやらないか」という判断にも、以前より目が向くようになりました。そのうえで、コードを書いているほうが性に合っている、という結論は変わっていません。それでも、エンジニアとPdMの両方の視点を知れたことは、これからエンジニアとして働くうえでもプラスになると思います。これからはエンジニアに軸足を置きながら、PdMとエンジニアの間を行き来し、プロダクトの意思決定にも関わっていければと思います。
OLTAでは、職種の枠を越えてプロダクトに向き合い、一緒にものづくりをしてくださる方を募集しています。興味を持っていただけた方は、ぜひ採用ページからご連絡ください。