受託PjM→自社サービスPdMになって「変わった」4つのこと
この記事は"プロダクトマネージャー Advent Calendar 2021"の13日目の記事です。
これまでの経歴では、ディレクター/PjM/スクラムマスターとして、クライアント向けのWebサービスやモバイルアプリを作ることが多かったのですが、
2020年11月にnoteに入社し、今年の6月からはPdMに転身し、新たな挑戦をはじめています。
よく聞く「受託→事業会社」への転職。そして「PjM→PdM」へのジョブチェンジを経て、「変わった」ことについて振り返ってみます。
※受託と事業会社、PjMとPdMどっちが良くてどっちが悪い！という趣旨の記事ではないです。念の為！
まずは自己紹介
まずは前提となるバックグラウンドの説明…ということで簡単に自己紹介。
note株式会社プロダクトマネージャー
新卒から9年間ずっとディレクター/PjM/スクラムマスター
新卒から8年くらい海外エンジニアとオフショア開発
noteにPjMとして入社、今年6月からPdMに挑戦中
以前からPdMに興味はあったし、やってみたかった
「自分ごと化のレベル」が変わった
noteに入る以前は受託開発で、プロジェクトベースでクライアントのためのWeb・アプリを開発する仕事がキャリアの大半を占めていました。
クライアントのプロダクトなので、「いや、自分たちは期日内に求められたものを納品できればいいんで」と線を引くのはよくあること。
「クライアントとタッグを組んで、世のためになるようなプロダクトがつくりたい」と思うことは多いものの、現実は納期・予算・契約などの都合で、自分たちの利益や責任分界点を気にしなければならないという、よくある受発注の関係・上下関係のある構造で仕事せざるを得ないことが多くありました。
そんな中でもかなり意識して「クライアントのことを自分ごとして考える」ようにしていたし、なんならそれが自身の強みだとさえ思っていたのですが、構造上どこまでいってもクライアントとの利害関係は一致しないし、どれだけ自分ごと化しても他人の組織・プロダクトでした。
noteに入ってからは、これまでの「自分ごと」を上回る次元で自分ごと化してプロダクトのこと、会社のことが考えられるようになりました。
事業会社に入ったんだから、自社の事業を自分ごととして考えるのは当たり前かもしれませんが、我が子のように思ってnoteに接し、仕事以外の時間でもnoteに触れたり、noteに活かせそうな種を探すようになったのは、「心から良くしたい」と思えるプロダクトと、プロダクトを支える会社に出会えたからだと思っています。
「重視すべき基準」が変わった
僕が経験してきた受託開発では、定めたQCD = Quality（品質）・Cost（費用）・Delivery（納期）内でプロダクトを開発し、納品することが最重要事項とされることがほとんどでした。
また、「決めていないことはやらない」とか、「バグ修正はひとしきり機能を開発した後でしかやらない」とか、「事前に合意したことから逸脱せず、ガバナンスが効いた状態でQCDを満たすこと」を重視しているプロジェクトも多くありました。
noteに入ってからは、「合意したことをやりきる」よりも「クリエイターにとって価値があること」を素早く・小さく進めることが重視されており、多くの意思決定を「クリエイターのためになるか」を軸に決めることができるようになりました。
事前に合意したことが本当にユーザーのためになるか、思っていたとおりに使ってもらえるかが全くわからないけど、「決めたからやる」から、ある程度根拠を持って「まずやってみる」に基準が変わり、より本質的な価値に素早く辿り着くことを重視して開発を進められています。
「世界の見え方」が変わった
PjMをやっていたころからPdMへの興味があって、書籍や記事を読んだり、カンファレンスに参加したりしていたのですが、実際にPdMをやりはじめてみて、PjMの頃とは圧倒的に世界の見え方が変わった実感があります。
受託開発をやっていたころも、関わっているサービスに活かせる情報を集めたり、アンテナを張って生きているつもりではあったのですが、PdMになって、プロダクトについて考える時間が物理的に増加したことで、よりアンテナが広く、高くなりました。
他社サービスを触っていても、街中のキャッチコピーを見ても、出先のオペレーションを見ても、「何かnoteに活かせることはないか？」という視点でモノゴトを捉えるようになりました。
経験のあるPdMや経営者、視座を高く持っている人からすると当たり前のことなのかもしれませんが、僕にとっては大きな変化の1つでした。
なぜ世界の見え方が変わったのか？は、まだ確信が持てるレベルで言語化できていないので、ぜひ同じような経験をされた方がいたらお話を聞いてみたいところです。
「チーム開発において重視すること」が変わった
受託開発の頃は、クライアントの担当者のために頑張ろうとか、僕のために頑張ってくれるメンバーがいたりということはあったのですが、「そのサービスや会社を前にすすめること」を指向して集まった人でチームが構成されているわけではありませんでした。
なので、プロジェクトが始まってまずすることは、クライアントや開発するプロダクト・その先にいるユーザーについての解像度を上げることでした。
自社開発をやっていても同じことはしているのですが、ベースとなる考え方や目的意識が大きく異る人々が同じベクトルに向かえるようにするのと、共通の考え方がベースにある人々が同じベクトルに向かえるようにするのとでは労力が違います。
どっちが良い・悪いという話ではないのですが、同じ労力を掛けるならば、「プロダクトをよくしてユーザーに喜んでもらえる総量を増やす」経験をしたい、それがうまくできるようになりたいと思い転職に至っています。
noteでは、ミッション・ビジョン・バリュー（MVV）が社内に浸透しており、採用においてもMVVへの理解が重視されていることもあってか、チームビルドはもちろんですが、より課題に向き合うことを重視できている実感があります。
とはいえ、まだまだ道半ば
色々を書いてきましたが、まだ至らない点やうまくできていない点も多く、いろんな方に支えてもらいながら、何とかかんとか前に進められている。というのが正直なところです。
具体的な業務だと、KPIをトラッキングすること、SQLを書くこと、期初の目標を立てること…などなどはじめて挑戦することも多く、うまくいってないな。まだまだだな。と感じる日々を過ごしています。
成果を出してはじめてうまくできている実感が持てると思っているので、来年は「やったこと」についてアドベントカレンダーが書けるようにがんばりたいところです。
この記事が気に入ったらサポートをしてみませんか？