AIによってコードを書くスループットは数倍になり、「速く作れること」そのものは優位ではなくなった。ではプロダクトの強さは、そしてプロダクトマネージャー自身の価値は、これから何で決まるのか。統合型人事システムを展開するjinjerの最高製品責任者（CPO）に2026年4月1日付で就任した松山雄一郎氏は、「プロダクトマネージャーという役割そのものが均一化されてきている」と語る。同社が10年かけて積み上げたのは、勤怠の打刻のように業務を回せば自動的に貯まる「固いデータ」だ。その資産をプロダクトと事業に生かす立場から見た、これからの差の付きどころを聞いた。
「役割が均一化する」時代に、何で尖るのか
「AIの登場によって、プロダクトマネージャーという役割そのものが均一化されてきています。だからこそ、どうやって尖るかがすごく重要だと思うのです」
統合型人事システムを展開するjinjer（ジンジャー）で最高製品責任者（CPO）を務める松山雄一郎氏は、取材の最後にそう語った。同氏が管掌するプロダクトと開発のチームでは、生成AIの活用によってコーディングのスループットが数倍になっている。作る速さが数倍になる世界では、速いこと自体は誰の優位でもなくなる。ならば、プロダクトの強さとプロダクトマネージャーの価値は、どこに残るのか。
松山氏は、エンジニア、営業、事業開発、そして事業責任者と、職種の境界を越えながらキャリアを重ねてきた。2002年に新卒でSIerに入社し、インターネットインフラのエンジニアとして働き始めた。2012年にAWSへ移るが、ここで職種が変わる。テクニカルセールス職としてオファーを受け、面接でも細かい技術の話を聞かれたので、当然エンジニアだと思っていた。
「オファーを受諾したら、『松山さんは営業です』と」
AWSでは営業と事業開発のリードを経験し、約10年在籍する。テクノロジーを使った事業変革を自分の手でやりたいと考え、2022年にパイオニアのモビリティサービスカンパニーへ移り、カンパニーのプロダクト全体の責任者、つまりCPOに相当する役割を経てCOOを務めた。在籍は4年間だ。
そして2026年4月1日付でjinjerのCPOに就任した。その選択の背景には、パイオニアで事業を率いるなかで、人と組織の問題に自ら向き合った経験がある。
「管理職罰ゲーム」を目の前で見て、自分でサーベイを始めた
事業を率いるなかで松山氏が向き合ったのは、多くの日本企業に共通するマネジメントの難しさだった。人が採れず、マネージャーがいくつもの役割を兼務せざるを得ない。世間で「管理職罰ゲーム論」と呼ばれる構造である。
そこで同氏は、組織の状態を定点観測する取り組みを自分のカンパニーで独自に始める。ミッション・ビジョン・バリューを作り替え、そのバリューが体現できているかをサーベイで測り、結果をマネージャー一人ひとりに自ら直接フィードバックしていった。当時は知らなかったが、それは今で言うパルスサーベイに近いものだった。
jinjerから声がかかった当初、松山氏は人事に向き合うことをキャリアとして考えていなかったが、よく考えると自分がやっていることはかなり人事に関することが多いと気づく。自分の取り組みをプロダクトにして世の中に広げられるのではないか、と考えたのが参画の決め手だった。
この原体験は、そのまま同社のプロダクト戦略に接続する。松山氏の見立てでは、日本企業は人手不足によって採用が難しくなり、その採用を担う人事部門もまた、人手が足りない。だからこそ、限られた人員を勤怠や給与などの定型業務ではなく、人材の配置や育成といった経営に直結する仕事へ振り向ける必要がある。
「勤怠や給与の部分は、その企業のコアコンピタンスでは決してありません。勤怠、給与をやりたいからその会社をやっている、ということはほとんどないので」
HR SaaSがこれだけ増えても「楽になった感じがしない」のはなぜか
人手が足りないこの状況で、人事オペレーションを担うSaaSは増え続けてきた。それでも、業務が楽になったという実感は広がっていない。
「これだけ人がいない状況の中で、たくさんHR SaaSのプロダクトがあっても、あまり皆さん楽になった感じがしないとおっしゃるのです」
松山氏は、その一因を製品選定の基準に見る。製品を選ぶとき、人はつい機能で比較してしまう。だが本来目指すべきは、機能の多寡ではなく「業務がちゃんと終わること」だ。
ただし松山氏は、そこで止まらない。業務が終わることは重要だが、それはまだオペレーション削減の域を出ない、と自ら線を引く。
「本当に人事の方がやりたいことは、経営のゴールを達成したいときにどのように人員を配置するのか、ということです。外から採用するのか、内部で育成するのか、業務委託として入っていただくのか。昨今ではAIを使って人をブーストすることも選択肢になります」
「ツールを売る会社」ではなく、jinjerが目指す、「成果を届ける会社」へ。jinjerが目指すこの転換の中身は、こうした判断を支えられるかどうかにある。
判断の質は、人がどう見えているかで決まる。ある職種に応募して、5つの募集要件のうち4つは十分に満たすが1つだけ経験がない、という場合。従来であれば、募集要件を満たさないとして候補から外れがちだったが、AIがその一つを補えるなら、それも可能性の一つになる。
「チャレンジしたことがなければ適性も分からない、というのが今までだったと思うのです」
給与も評価も異動履歴も履歴書も一つのデータベースに入っていれば、適性はこれまでとは違う角度からも見えてくる。それが「「ひと」の可能性のすべてが見える世界へ」という同社のビジョンの実務的な意味だ、というのが松山氏の整理である。
では、その判断を支えるデータは、どこから来るのか。
10年かけて蓄積した「固いデータ」と、統合コストを引き受ける覚悟
外部から来た松山氏が10年の蓄積に感じたのは、データのポテンシャルだった。給与、評価、異動履歴、直近の勤怠、そこにサーベイが加わると、一人の人を見る景色は一気に多面的になる。機能ではなく、持っているデータから顧客が必要とするインサイトを出せるのではないか、と考えた。
その資産の質を、同氏は「固いデータ」と呼んだ。
「我々のこの10年の蓄積は、自動的に貯まる固いデータなのです。業務を回していたら必然的に打刻の履歴が貯まっていきますし、欠損が起きにくい。もし打刻漏れがあっても、修正したことまで含めて履歴に残ります」
対照的に、タレントマネジメント側の評価や目標は誰かが入力しなければ存在しない。長年評価者を務めてきた松山氏の実感として、非常に長く丁寧に書く人もいれば、あっさりした評価で済ませるマネージャーもいる。データの質が入力者に左右されるのだ。
「固いデータが、ある特定の瞬間の評価の根拠になるわけではありません。ですが、この2つが合わさって初めて多面的に見えるのだと思っています。定量と定性に近いですね」
「人材のライフサイクルを一気通貫で管理できる」という説明は、他のHR SaaS事業者からも出てくる。違いはデータベースが統一されているかどうかである。jinjerは、採用管理システム「Talentio」を提供するタレンティオを買収し、統合作業を内部で進めている。
買収などでDBが異なるSaaSをつなぐ場合、まずユーザーを識別するキーが何かという問題が起きる。仮にメールアドレスや社員番号だとして、名寄せに進もうとすると、あるデータでは社員番号が全角で入っている、別のシステムでは先頭の0を落として桁数を変えている、といったルールの違いが次々に出てくる。これを吸収する作業は、意外と骨が折れる。
「勤怠、給与、評価をそれぞれ買収していくとなると、とんでもない統合のコストになっていくわけです。統合はせずに別々に存在させるとしても、権限の問題やデータの鮮度の問題は果たしてどうなるのか」
jinjerの既存プロダクト群は、一つのデータベースに機能を追加していく設計思想で構築されてきた。そのため、データの鮮度や質は常に一定に保たれる。一方、買収したプロダクトについては、統合の負担を自社で引き受けながら、同じ状態を目指している。
この選択がAI時代に効く理由も同じ構造にある。システムが複数あると権限設定が微妙に食い違い、あるシステムでは住所を見せていないのに別のシステムでは権限上見えてしまう。名寄せも難しく、データにタイムラグがあって、その瞬間は一致していないこともある。
「人を多面的に、またAIを通して見るというときには、ハルシネーションにつながる可能性もありますし、見えてはいけないデータが見えてしまうことにもつながりかねない」
AIに何を渡すかという問題として見れば、単一データベースは地味な設計思想ではなく、前提条件そのものだった。
「人事システムはマネージャーを助けない」を覆す
人事システムは普段あまり触らないうえに、入力項目が多く、マネージャーを直接助けてくれるものとは感じにくい。だが、日々の業務を通じて蓄積されたデータを横断して見れば、個別には気づきにくい変化が浮かび上がる。
例えば、長期間昇給がなく、始業が9時の職場で8時半に来ていた従業員の打刻が9時1分になることが増え、異動後の評価も振るわなくなったとする。こうした変化を重ね合わせることで、退職につながる兆候が見えてくる。
だが、そこまで多面的に部下を見続けているマネージャーは多くない。しかもマネージャーはどんどん忙しくなり、メンバーと向き合う時間は減っていく。ならばデータの側から、注意すべきことの示唆と、次に取るべきアクションまで提案できるのではないか。例えば1on1や人事への相談を促す、といった具合に。狙いは個人を監視することではなく、マネージャーが声をかけるきっかけを早く届けることにある。
これを形にしたのが、2026年5月に発表し一部の顧客が使い始めている「HR Signals」である。第1弾は退職の兆候を予測する機能だ。蓄積したデータから退職に至る可能性のある人の傾向を捉え、各企業の特徴に合わせるとどうなるかを見る。学習に使用するデータについては、匿名化など個人を特定できない形に加工したうえで、利用規約の範囲内で扱っているという。
ただし、退職の兆候という情報は、扱い方によって人の不利益に直結しうる。松山氏が説明責任の設計として第一に挙げたのは、AIを使わない範囲を決めることだった。
これはHR Signalsに限らず、同社のAI活用全体に通じる原則である。
「決定論的に扱わなければいけないものにAIは使わない、というところがまず第一です。例えば給与の計算に確率が入ってくるととんでもないことになるので、こういうところには一切AIを使いません」
決定論で処理すべき領域はルールベースで処理し、生成AIを使うのは膨大なテキストデータから特徴を見つける部分に限る。そこでも根拠を示したうえで、最終的に判断するのは顧客自身だ。
使うデータもjinjerのデータベースの中にあるものに限り、外部の情報を検索して取り込むことはしない。
ではこの10年の資産を、生成AIが開発そのものを変えていく組織で、どう回すのか。
ソフトウェア開発ライフサイクルを、生成AI中心に作り替える
松山氏の見立てでは、生成AIの登場によってプロダクトマネジメントとエンジニアリングの境目は徐々になくなりつつある。エンジニアはより上流の工程へ向かい、プロダクトマネージャーは、要件やアイデアのかなりの部分を、実際に動くプロトタイプにして開発チームへ引き渡すようになる。
「今までであれば、企画を出して、デザインモックという紙芝居をお客様に見ていただいて、これで要件を満たせますかというコミュニケーションでした。今はある程度動くものまで持っていけるようになっています」
フィードバックをもらう速度が上がると、次の課題は別の場所に移る。企画からフィードバック、開発、リリースまでの流れのどこに摩擦があり、どこがボトルネックになっているのかを特定して一直線に進めることだ。
「以前とはまったく違う世界になっていて、徐々に人がボトルネックになる世界にもなっています」
そこで同社は、顧客の声を得てからリリースするまでのソフトウェア開発ライフサイクル全体を、生成AI中心のものへ作り替えている。いくつかのプロダクトはすでにそのラインに乗っているという。
変わったのは、顧客の声がプロダクトマネージャーに届く経路である。従来はフォームから入った顧客の声を集め、さらにカスタマーサクセスも持ち帰って伝える伝言ゲームだったが、現在は商談の文字起こしデータから抽出し、なるべく早くプロダクトマネージャーの目に入れる。
組織の形も動く。大きな開発組織に複数のコミュニケーションラインが走る形から、シンプルなラインで少人数・高速に開発する形へ。いわゆるスクワッド型への転換が加速すると松山氏は見る。一方でAI活用の知見を集めるセンターオブエクセレンスやセキュリティは、横串の組織として残るだろうという見立てだ。
この作り替えを支えるのが、CPO就任時に行った組織の一本化である。松山氏が管掌するプロダクトマネジメント部門には、プロダクトマネージャーとプロダクトマーケティングに加え、そのメッセージを市場に届ける「人事コンサルティングセールス」まで置かれている。就任時に、別部署だったプロダクトマネージャーとプロダクトマーケティングを一つの部門に統合し、それまでなかった人事コンサルティングセールスを新設した。企画からメッセージング、実行までが一部門で回る設計だ。
狙いはフィードバックループを速く回すことと、管掌下に入れたカスタマーサクセス本部を通じて、プロダクトアウトの戦略にマーケットインの声を混ぜることである。
SaaSの枠を越え、顧客の「業務の完了」まで担う
優先順位を大胆に変え、既存のプロセスを一から見直すこともできる。松山氏は、それが第二創業期にある同社の特徴だと語る。
「我々は挑戦者の立場です。HRテックで日本一を取るにはどうするかを逆算すると、場合によってはこれを諦めてこっちを取る、という判断が要ります。今やっているプロセスを全部作り直せる。これは結構、勇気のいることだと思います」
こうした変革を支える環境の一つとして、松山氏は同社の資本構成を挙げる。株主であるプライベートエクイティのネットワークを通じて、グローバル企業のAI活用の知見に触れられる。単独の事業資金の範囲にとらわれず事業を大きくしていける点も、面白さとして挙げた。
そして松山氏は、自社の事業の形そのものにも同じ問いを向けた。
「SaaSという業種に、とらわれてはいけないのかもしれない」
顧客のアウトカムを、単なる機能提供ではなく「業務が完了すること」と捉えるなら、SaaSという事業の形だけに閉じる必要はない、という意味である。取材の場で、BPOやFDE（フォワードデプロイドエンジニア。顧客の現場に入り込んで実装まで担う役割）のような方向かと確認したところ、松山氏はそれも選択肢の一つだと答えた。プロダクトの範囲を機能ではなく顧客の業務の終わりで定義するなら、届け方の選択肢は変わる。
求める人材像も、この延長にある。役割の境目が消えていくため、「私の仕事はここだけです」とは言わずにカバレッジを広く持てる人が欲しい、と松山氏は言う。会社がツールを売る会社から成果を追求する会社へ変わるのと同じで、仕事も完了まで責任を持ってやり切ってほしい。管理する人ではなく「なんとかする人」としてのマネージャー像である。
求められるのは職域を越える姿勢だけではない。HRという複雑なドメインそのものに好奇心を持てることも欠かせない。
「労働法規に対応するといったところは、業務としても細かいところがあるので、そこに興味がないと、最後はしんどくなってしまうのではないかと思います」
冒頭の問いに戻る。AIによって役割が均一化するなかで、どうやって尖るのか。松山氏の答えは2つの組み合わせだった。
一つは、自分の担当プロダクトの事業責任者として、顧客への価値提供とビジネスとしての成功の両方に責任を持つオーナーシップ。もう一つは、顧客の課題、場合によっては大きな社会課題に対する好奇心と、ドメイン知識を深めていく力である。
「お客様の課題に対しての好奇心や、ドメイン知識を深めていく力が、プロダクトマネージャーの差別化であり、その方々の存在意義にもつながっていくと思うのです」
自分が独自に始めたサーベイの延長線上に人事プロダクトを見つけた松山氏自身が、その答えの実例だろう。10年分の固いデータも、好奇心とドメイン知識も、速く作れることでは代替できない。AIが速さを平準化した先に残るのは、そこに何を積み上げてきたかである。
jinjerでは、プロダクトづくりを担う仲間を募集しています
jinjerでは、本記事で松山氏が語った第二創業期のプロダクトづくりを担うメンバーを募集している。プロダクトマネージャーやプロダクトマーケティングマネージャーなどの募集職種に加えて、社内制度やオフィス環境、メンバーのインタビューといったjinjerのカルチャーについても、下記の各ページで公開されている。
この記事は参考になりましたか？
提供：jinjer株式会社
【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社
この記事は参考になりましたか？
この記事をシェア
