こんにちは！プロダクト開発部PdMの天川です。
5月で入社から丸4年を迎え、現在のPdMメンバーでは社歴が長い方になりました。
この記事では、私が4年間で経験してきたPdMの役割の変化と、これからコドモンのPdMが求められるだろう役割についてお話しします。
なぜ、私はコドモンを選んだのか
コドモンに入社する前、私はヘルステック企業でエンジニアとして働いていました。
転職したきっかけは、コドモンのエンジニアリングマネージャーからの声掛けです。 保育業界にはまったく詳しくありませんでしたが、前職で循環器系疾患（糖尿病など）の再発防止に関わっていたため「人々の暮らしや社会を変えられるサービス」であることは非常に魅力的でした。
前職のメインユーザーは50〜60代でしたが、コドモンのメインユーザー（保護者）は20〜40代で私と年齢が近く、コドモンで働くことが同世代や将来の自分の幸せに直結する予感で転職を決めました。
いま、私が向き合っていること
私はプロダクト開発部で、連絡帳・お知らせ一斉配信・保護者連絡など施設と保護者のコミュニケーションに関わる機能を担当しています。
これらは保育や子どもの育ちに関わる、PdMとしてもやりがいの強い機能です。 一方で連絡帳や保護者連絡は日々個人情報がやり取りされる機能のため、負荷対策やセキュリティなどシステムの土台に関する課題も多くあります。
子どもが保育園で過ごす様子を毎日連絡帳で見られること。電車の中で保育園からのお便りを確認できること。その「当たり前」を守り、子どもと周囲の大人の生活を支え続ける重要さと責任を感じています。
4年で変わったPdMの役割
この4年間でPdMチームは3人から11人に増え、組織の変化とともに求められる役割も変わってきました。私が感じた変化をいくつかのフェーズに分けてお話しします。
1年目：目の前の課題に取り組みつつ、チームとの距離感に悩んだ時期
入社直後、さっそくチームにPdMとして配属されバックログの整理やバグ修正の仕様検討から始めました。
当時はまだシステム内に課題が多く、チームで取り組む課題もバグ修正やユーザーの問い合わせ対応が中心でした。そのため私も長期的なロードマップ作成より既存のissueから重要なものを取り上げ、急激に伸びるサービスを支えることに集中していた時期でした。
この頃はエンジニアからキャリアチェンジしたばかりで「決めることが自分の仕事だ」と決断を抱えがちになっていたと思います。PdMが素早く決めてチームの流れを止めないことが重要だと思っていましたが、エンジニアから「社内で受発注のような関係になっている」と指摘を受けたこともありました。
今までPdMのいなかったチームに続々とPdMが配属され、お互いの役割や距離感を掴むことに苦戦していました。PdMとして意思決定することと、チームで納得感をつくることのバランスに悩んだ時期でした。
2〜3年目：チームで決める、を加速させた時期
開発メンバーが増え、部署全体で「自己組織化」という言葉を聞くようになった頃です。エンジニアはペアプロがメインとなり、チームとして強くなることを部署全体が意識した時期でした。
このような変化と共に難易度が高めの開発も増え始め、この頃から仕様もチームで決めるようになりました。Miroを使ったユーザーストーリーマッピングや実例マッピングを積極的に行い、時にはCS（カスタマーサポート）のメンバーも招いてチームで早く良い判断をするための工夫を重ねていました。
多様なメンバーの知識や意見が取り入れられる一方で、不安もありました。
ワークの準備やファシリテーションに割く時間が増え「議論をどう収束させるか？」「どうしたら必要なタイミングで必要な人の意見を取り入れられるか？」といった悩みが出てくると、PdMの役割がファシリテーターや「意見をまとめる人」に近づいていると不安になることもありました。チームメンバーからすごく良い仕様が提案されて、PdMがいなくても仕様は決められるのではと悔しく思ったこともあります。
それでも、リリースした機能を見ると一人で決めるよりいい判断ができている自信があったこと、あるメンバーから「最後の決めができるのはPdMだと思ってる」と言ってもらえたことが、悩んだ時期の支えでした。
4年目〜現在：事業とプロダクトがつながり始める
2024年9月、事業戦略の決定を担うICT事業戦略部（以下IBS）が発足しました。 発足当初はIBSとPdMの業務分担が曖昧だったこともあり「企画業務がIBS側に集約されてしまうのでは？」という不安もありました。その心配は杞憂に終わり、PdMも非常に働きやすくなっています。
今まではプロダクト側から見える課題やユーザーの声を手掛かりにロードマップを決めるのが中心で、機能ごとに分かれたチームが各々の課題に取り組んでいる印象がありました。事業戦略の整理が進み、戦略に合わせた課題の優先付けや体制作りがされることで「事業とプロダクトが初めてつながった」と感じる場面が増えています。
今では企画を考える際に、「この課題は事業的にどんな意味があるのか？」「この戦略ならもっと別の方針や手段もあるのでは？」といった視点を自然と持つようになりました。2025年4月からはある大きな課題に向けて、2チーム合同での開発準備も始まっています。事業という一段上の視点をPdMが持てるようになりチームを超えた改善が一気にやりやすくなった実感があります。
IBSが生まれたことでPdMの役割が自然と広がり、チームとしても個人としてもできることを広げるチャンスが生まれています。
コドモンのPdMに求められること
これからのPdMにはより広く・長い視野でサービスを考える力が求められそうです。一機能のあるべき姿を見るだけでなく、その課題が事業の中でどんな役割を担うのか、数年後にどんな姿を作るかを考えながら意思決定することがより大切になっていくはずです。
私たちは「機能ごと」のチームから「テーマごと」のチームにシフトしていきます。PdMに限らず、役割をはみ出していける柔軟さと、変化の中でいま重要な課題を追い続ける適応力が問われると思います。
ちなみに：エンジニア経験はPdM業務で活きるのか？
インタビューで時々聞かれる質問ですが、「コドモンでは必須ではないが強みの一つにはなる」と思っています。まず、コドモンのPdMはコードを書きません。技術的な検証や判断はエンジニアが主導することがほとんどで、判断の理由を聞いてチームで最終的に決定をします。
入社直後は「PdMになったんだからエンジニアリングに口を出すのはやめよう」と距離を置き過ぎて、調査結果に疑問が残っても突っ込みを入れられず手戻りする失敗もありました。 今はメンバーへのリスペクトは大切にしつつ「ちょっとだけ技術もわかるPdM」として必要なことは何でも言わせてもらっていますし、それが最終的にチームやユーザーのためになると信じています。
エンジニアと共通言語があれば確実に仕事はしやすくなりますし、セキュリティ対応や負荷対策など技術色が強い課題ほどメリットは大きくなります。エンジニアとして培った知識や経験をPdMとして今のチームでどう活かすかが見えてきたら、必ず強みになるはずです。
最後に
入社から4年間、プロダクトや組織の成長とともにPdMの役割も変化してきました。 戸惑うこともありましたが、振り返るといつも「この変化があってよかった」と思える発見があります。もちろん過去を振り返ったときに悔しい思いもありますが、それもPdMとしての視点や経験が広がったからこその感情だと受け止めています。
これからもコドモンは子どもを取り巻く環境と共に変化していきます。 変化の波を楽しみつつ、一緒に超えていきたい！と思ってくださる方とぜひお話ししたいです。
