この記事は、ナウキャスト Advent Calendar 2025 の11日目の記事です。
こんにちは、ナウキャストの大森です。普段は、オルタナティブデータを用いた経済統計の開発や、それらを活用したプロダクトのマネジメントを行っています。
最近、データサイエンティスト（DS）のキャリアパスとして「PdM（プロダクトマネージャー）」という選択肢が語られることが増えてきました。 一般的には、コードを書く専門職からビジネス側のジェネラリストへの転身、あるいは「現場を離れる」という寂しいイメージがあるかもしれません。
私自身、2021年に新卒のデータサイエンティストとして入社し、データエンジニアリング（DE）の領域へ足を踏み入れ、気づけば複数のプロダクトを見るPdMになり、2025年からは事業ユニットのリーダーを務めることになりました。
ただ、この変遷は決して「戦略的なキャリアチェンジ」ではありませんでした。
目の前のデータをもっと便利に使ってもらうには？ チームがもっと動きやすくするには？ ——そうやって 「自分の守備範囲」を少しずつ染み出させていった結果、気づいたら肩書きが変わっていた というのが正直なところです。
今回は、アドベントカレンダーという機会を借りて、エンジニアリング出身の私がどのようにしてPdMという役割に行き着いたのか。そして、そこでどんな 「壁」 にぶつかり、どう乗り越えてきたのか（あるいは現在進行形で格闘しているのか）。
成功談だけでなく失敗談も含めて、ありのままのプロセスを書いてみたいと思います。
キャリアに悩むデータサイエンティストやエンジニアの方にとって、一つのサンプルとして参考になれば嬉しいです。
キャリアの変遷（Generated by Gemini）
Phase 1：データを作る楽しさと、「届かない」もどかしさ
モデルを作るだけがDSじゃない
入社当初、私は「JCB消費NOW」という民間統計の開発チームに入りました。（「JCB消費NOW」のプロダクトページは こちら）
当時の私は、まさに「ザ・データサイエンティスト」。Jupyter Notebookを開き、Pythonでデータを加工し、どうすればより実態を表す指数（モデル）が作れるかに没頭していました。
転機は2年目、開発チームのリーダーを引き継いだことでした。当時のデータ基盤は、データ量の爆発的増加に伴い、運用保守コストや拡張性に限界が見え始めていました。
「どんなに精度の高い統計モデルを作っても、データが安定して更新されなければ、顧客にとっての価値はゼロに等しい」
全体を見たとき、そう痛感しました。そこで私はモデル開発の手を少し休め、データエンジニアリング領域へ拡張。Snowflake × dbt × Airflow への移行など、モダンデータスタックへの載せ替えを推進しました。
DS から DE になった時の苦労話や楽しさは長くなってしまうので別の機会でお話しできればと思います。
「How」の解像度を高める
この時期に、DSとしての「データの中身（統計的性質）への理解」に加え、DEとしての「データパイプラインへの理解」が深まったことは、後のPdMキャリアにおいて決定的な財産になりました。
「この機能を追加したい」と言われたとき、「データ構造的に難しいから工数がかかる」「ここを直せば一瞬で終わる」という実装レベルの勘所が瞬時に働く。これは、エンジニアリングのバックグラウンドを持つPdMならではの強みだと、今でも感じています。
Phase 2：PdMへの拡張と、ぶつかった「3つの壁」
基盤移行やスクラム開発の導入など、「開発組織」を整えることに奔走していた2023年。
「HRog賃金Now」という新規プロダクトのリリースを経て、私はマクロ経済統計に関わる3つのプロダクトのPdMを任されることになりました。（「HRog賃金Now」のプロダクトページは こちら）
「作る責任者（Tech Lead）」から「プロダクトの責任者（PdM）」へ。
役割が変わったことで、私はこれまで経験したことのない3つの壁に直面することになります。
壁①：顧客の解像度がない —— 「良いデータ」って誰が決めるの？
最初の壁は、「ドメイン知識」の圧倒的な不足でした。
私が担当するプロダクトのユーザーは、官公庁の担当者や、証券会社のエコノミストなど、いわゆる経済の「プロ」の方々です。彼らは日々、公的統計やニュースを詳細に分析し、世界の経済動向を追っています。
一方、当時の私はどうだったか。統計学的な正しさは語れても、「この指数が前月比で上がったことが、経済にとってどういう意味を持つのか」が全く分かっていませんでした。開発者として「信頼性の高いデータ」は作れても、ユーザーとして「使いたいデータ」が分からなかったのです。
「これでは、対等な議論なんてできない」
そう危機感を覚えた私が2024年の1月から始めたのが、「月曜朝の経済勉強会」 でした。経済ニュースを毎日チェックし、分からない用語を調べ、「なぜこの指標が注目されているのか？」を自分なりに解説する時間をチームで設けたのです。
これを続けていくうちに、少しずつ「点」だったデータが「線」として繋がる感覚がつかめてきました。
「物価上昇の局面においては賃金上昇との好循環は起こっているのか、消費は冷え込んでいないのか」
そんな視点で自分たちのプロダクトを見れるようになってきました。
壁②：エンジニアのエゴ vs ビジネスのROI
2つ目の壁は、「リソース配分」のシビアさです。
新卒の頃は「技術的に正しいこと」が正義でした。「挙動が不安定だから直したい」「レガシーだからリファクタリングしたい」。しかし、PdMは時にそれを「やらない」と決断しなければなりません。
私が担当する領域は、市場規模や予算が限られています。無尽蔵にリソースがない中で価値を出し続けるにはどうすべきか。ここで私は、「サービスをまるっとBIツールに載せて提供する」 という決断を下しました。
画面開発の自由度は落ちますが、お客様が重視する「データの質」は落とさず、リリース速度を優先する。「自分の作りたいものを作る」から、「限られたリソースで最大の価値を狙う」へ。この 「守りの意思決定」 は、裏側のコスト構造を知っているエンジニア出身だからこそ、自信を持って踏み切れた判断でした。
壁③：「戦略ごっこ」への逃避と、現場への回帰
そして3つ目、これが個人的に最も苦しく、かつ大きな学びだった壁です。
それは、「どこまで自分でやるか」の線引きの失敗です。
PdMになった当初、私は「開発実務は他のメンバーにできるだけ委譲して、自分は戦略を練ることにもっと集中すべきだ」と意気込んでいました。
開発はエンジニアメンバーに大幅に委譲し、顧客とのコミュニケーションはビジネスサイドに任せ、データ分析はアナリストに依頼する。自分はそれらの報告を聞き、方向性を示す——。
一見、理想的なマネジメントに見えます。しかし、実際は何が起きたか。
「で、大森さんって今、何してる人だっけ？」
チームから直接そう言われたわけではありませんが、空気感としてそれを感じました。
それもそのはずです。二次情報だけを集めて会議をしている人間の言葉には、重みがありません。「戦略」という名のふわっとした絵を描くだけで、現場の解像度が日に日に落ちていく。自分自身も「プロダクトの手触り感」を失い、意思決定に自信が持てなくなっていました。
「これではダメだ」
私はやり方をガラリと変えました。
「エンジニア出身なら、一番の武器は『作れること』だ。迷ったら手を動かそう」
特に、新しい機能のプロトタイプ作成や、技術的な難易度が高い検証フェーズでは、意識的に自分がコードを書くようにしました。初期のMVP（Minimum Viable Product、実用最小限の製品）を自分で実装することで、データの癖や開発のハマりどころを肌で理解できます。そうして一次情報を自分の中に持っておくと、その後メンバーに任せる際にも解像度の高いコミュニケーションができるようになります。
「全部自分でやる」のでも、「全部丸投げする」のでもない。
「最初の泥臭い0→1や、勘所となるコア部分は自分で耕し、整った畑をチームに広げていく」。
これが、失敗を経てたどり着いた、今の私のPdMとしてのスタイルです。
Phase 3：そして、事業責任者へ —— 「0→1」への挑戦
こうしてPdMとして試行錯誤している最中、2025年からは金融リサーチ事業全体のリーダーを務めることになりました。
これまでは「すでにあるプロダクト」を磨くことがミッションでしたが、これからはエンジニア・アナリスト・ビジネスサイドと協力し、「全く新しい事業」を創り出すことが求められています。
直近では生成AIを活用した分析プロダクトの開発をリードしていますが、手探りの連続です。「技術的に何ができるか」は分かっても、「顧客が本当に欲しい形」はコードを書いても分かりません。エンジニア出身ゆえの「内向き思考」の殻を破り、広い視点で世の中を捉えることが今の私の最大のチャレンジです。
おわりに：データサイエンティストのキャリアはもっと自由でいい
DSからキャリアをスタートし、DEを学び、PdM・事業責任者へ。
振り返ってみると、私のキャリアは 「データ」という軸足は変えずに、そのデータを「どう活かすか」という変数が増えていったプロセスだったように思います。
- Data Science: データから価値ある情報を抽出する（What）
- Data Engineering: それを安定して届ける仕組みを作る（How）
- Product Management: それを誰に、なぜ、どう届けて対価を得るか（Who & Why）
これらは別々の職種として語られがちですが、本来は一連のつながったプロセスです。
DSとしての「データの勘所」と、DEとしての「システムの実装力」を持っていることは、PdMとして意思決定をする上で、これ以上ない強力な武器になります。
もし今、「データサイエンティストとしての将来」に迷っている方がいたら、ぜひ一度、隣の領域——エンジニアリングやプロダクトマネジメント——を覗いてみてほしいです。
そこには、あなたが作ったモデルやデータを、より多くの人に、より大きな価値として届けるためのヒントがたくさん転がっています。
現在のナウキャストではエンジニアもアナリストもビジネスも、職種の垣根を越えてごちゃ混ぜになりながら、新しいプロダクト開発に挑んでいきます。
泥臭く、でも最高に面白いこの「総合格闘技」を、これからも楽しんでいきたいと思います。
Discussion