AIで誰でも速く作れる時代、プロダクトマネージャーは何で尖るのか──jinjer松山CPOが10年分の「固いデータ」に賭ける理由

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が開発そのものを変えていく組織で、どう回すのか。