HRテックのマルチプロダクト導入順序、なぜ「データベースが一番大事」なのか

「ゼロから始めるCSラジオ」HRテック編の第7回のテーマは、マルチプロダクト戦略と、その導入順序です。今回はMCの大脇さんに加えて、CS現場の綾部さん・瀧田さん、そして初出演の社労士・佐怒賀さんという座組で進みます。

HRテックといっても勤怠、給与、労務、タレントマネジメントタレントマネジメント ── 人事評価やスキル、目標などの従業員データを一元管理し、育成や配置に活かす人事領域。この回では「タレマネ」とも呼ばれていますなど領域は幅広く、業務も法制度も細かく違います。その中で各社がどんな順序でプロダクトを導入しているのかが、この回の出発点です。

そもそも今、ほとんどのHRテック企業がマルチプロダクトに展開しているのか。この問いに、瀧田さんは各社が同じようなラインナップを揃えてきていると話します。

綾部さんは、その背景にユーザー側のニーズがあると補足します。ツールを一本化したいという要望は昔から強く、それが各社のマルチプロダクト化を後押ししてきたといいます。

一昔前はプロダクトがバラバラなのが当たり前でしたが、佐怒賀さんが今支援している会社では、そういうバラバラのところはもう1つもないそうです。各社ともスタートは会計給与・勤怠・労務系などバラバラでも、今は同じ領域に被ってきていると整理されました。

論点の1つ目は、マルチプロダクトの導入に「順序の型」があるのか、です。まず綾部さんは、タレントマネジメントと労務のケースを挙げます。

綾部さんによれば、最初に従業員のデータベース登録さえ終われば、労務と評価は順序というより同時並行で進むことが多かったといいます。顧客規模によっては担当者が分かれるため、労務は労務、タレマネは人事企画と、並行して進めやすかったそうです。

そのぶん、CS側も労務担当とタレマネ担当が別々にいるので、1人のCSが過度に大変になることは少なかった一方、横の連携が取れていないと問題も起きたといいます。

一方、瀧田さんは労務系サービスが中心で、個別に入れる場合は勤怠を一番最初に進めると話します。理由は、勤怠の後に給与という順序が設定を立てやすいからです。

だから導入負荷は多少かかっても、勤怠から入ったほうが後から困らない、というのが瀧田さんの実感です。労務についても、単体で進めるより勤怠などと同時に始めて整合性を合わせるケースが多いそうです。

話題は、複数プロダクトをつなぐ土台になる社員マスター（従業員データベース）に移ります。瀧田さんは、この社員マスターが意外なほど複雑だと語ります。

1人の従業員の情報を複数のシステムにつなぐとき、システムが違うと表記揺れが生じ、データを加工しないと連携できないことが出てきます。ここに地味に時間がかかるといいます。

瀧田さんと佐怒賀さんがかつて在籍した会社では、勤怠（A）と労務（B）が先にあり、後から真ん中の人事データベースを作ったため、この表記揺れが大問題になったと振り返ります。

同じ人でもシステムによって情報が違う。それを真ん中のデータベースに統合するとき、どちらを正とするかを決めなければなりません。しかも一斉導入だと、お客さんは3つのデータベースを登録する状況になります。

この難所に対して佐怒賀さんが取った対策は、リリースの半年ほど前から、どの項目をどちらに寄せるかをお客さんに伝え続けることでした。準備期間を顧客側に取ってもらう動き方です。

論点の2つ目は、各社がどんな意思決定でマルチプロダクトの順序を選んできたか、です。佐怒賀さんは、人事データベースを先に作ることのジレンマを率直に語ります。

一方で、横展開を考えると真ん中のデータベースがないと必ず困る。だから多くの会社が同じジレンマにぶつかっているのではないか、と佐怒賀さんは見ています。

大脇さんは、お客様に直接価値を生むのはデータベース以外のプロダクトであり、そちらの開発を優先したくなると整理します。それでもマルチプロダクトに行くならデータベースは必須で、後回しにしがちなのに避けられない、というジレンマです。

今の瀧田さんが扱うサービスは、どこから始めてもデータベースが1つ付いてくる作りになっています。綾部さんも、従業員マスターと労務をセットで売るケースがほとんどではないかと話します。

そもそもデータベースが存在しない顧客もいて、その場合はまず土台を作るところからスタートすると瀧田さんは言います。データベースに入るのは名前や連絡先だけでなく、評価情報、所属、異動歴まで含まれ、勤怠の承認者やワークフローもこの所属情報に紐づきます。

さらに厄介なのが、旧姓と本名の扱いです。表記は旧姓でも、給与明細や社会保険の手続きは本名でなければならないことがあります。データがあればいいのではなく、一人ひとりの事情まで把握する必要があるのです。

論点の3つ目は、CSがやるべき範囲と、社労士など専門家がやる範囲の境界線です。佐怒賀さんの答えは明快で、そもそも境界線はないというものでした。

社労士の独占業務独占業務 ── 法律で社労士だけが行えると定められた業務。労働・社会保険の手続き代行などが該当し、システムの導入支援や設定はこの独占業務には含まれませんに、システムの導入支援や設定は含まれていません。だから制度に明るく設定もできるCSがいれば社労士はいらないし、逆に佐怒賀さん自身が導入支援や設定代行をすることもある、と説明します。

ないのは境界線で、あるのは役割分担だと佐怒賀さんは続けます。24時間365日しかない中で1人が全部やりきるのは難しいので、持っている情報の種類が違う者同士が持ち寄ればいい、という考え方です。

象徴的なエピソードとして、佐怒賀さんはお客様先の社労士が勤怠にあまり明るくなかったケースを挙げます。その場では相手の顔を立てて言えなかったことを、後で伝えたそうです。

瀧田さんは、お互いの強みを活かせばやりやすいと整理します。CSは自社サービスの設計に詳しく、制度に明るくない。社労士は制度に強い。だからお客さんの理想像を専門家が描き、それをどう実現するかをCSがつなぐ、という役割連携です。

佐怒賀さんは、導入を機に新しい制度を始めたいケースでは、制度変更に法的な縛りが関わるため専門家が前に出ると言います。そこで決めたルールを、システムでどう実現し、どう楽に運用させるかをCSが考える、という分担です。

SaaSの導入までくっついてくる社労士のコンサルティングは、歴史上はなかったパターンながら、最近やり始める社労士も出てきていると佐怒賀さんは言います。ただし社労士1人で全部を賄える人はまだ少ないそうです。

その理由は、必要になる知識の広さにあります。社労士としての法的観点、事業会社の人事がどう動いているか、そしてプロダクトの特性。この3つをある程度持っていないと、1人でこなすのは難しいのです。

最後の論点は、エンタープライズ特有の難所です。まず綾部さんは、タレントマネジメントの評価は一部署だけで使うことが少なく、決まれば全社導入になりがちだと話します。

そのため、綾部さんの経験では、データベースの登録や評価者の設定にとても時間がかかりました。評価者は何人もいて複雑性が高く、初回設定にかなりの時間を要したそうです。

さらにアダプションの段階では、部署のマネージャーによって運用の理解度に差が出ます。整合性を取るのが難しかったと綾部さんは振り返ります。

人事異動もエンタープライズならではの難所です。異動のたびに評価者や部署を変える必要があるため、データベースを1つにまとめておきたいニーズが強かったといいます。

綾部さんがいたタレントマネジメントのSaaSは、元々データベース機能がなく評価単体でした。異動対応で二重に情報を変える問題が起き、急いでデータベースを作り直し、その基盤をベースにプロダクトを作り直したそうです。

瀧田さんは、大企業ならではの業務の縦割りを難所に挙げます。各部署が個別最適で主張することを全体最適でまとめる推進は、難易度が高いといいます。

既存の制度ありきでシステムを入れるため、現状を疑う発想が生まれにくく、外の情報も入ってこない。SaaSベンダーからすると苦しい部分だと瀧田さんは言います。

ただ、上位レイヤーはシステムに合わせる思考の人が増えてきた一方、現場は「自分が苦しくなる」と感じて抵抗する、という構図が残ります。全体最適で会社は良くなっても、自分の業務が増える人をどう説得するかに、先方が頭を悩ませているそうです。

瀧田さんは、労務系の担当者の特性にも触れます。ミスが許されず、やって当たり前の領域だからこそ、業務が増える変更に抵抗が生まれやすいのです。

加えて大脇さんは、HRテックはアウトカムが遠いことも難しさだと指摘します。「データを増やしてほしい」に対し「何が良くなるの?」と問われても、たとえば「3年後に人が定着するから」といった説明は難易度が高いのです。

佐怒賀さんも、瀧田さんの話に重なる過去の苦い経験を語ります。かつては、お客さんが自分たちのやり方を残したがる「Excelが欲しい」のと同じ状況が多かったといいます。

当時はプロダクトの完成度も低く、強く推進した役員がいても、やりたいことがやれない。今のやり方を踏襲したい力が勝り、導入が頓挫して契約もなくなってしまったそうです。

それでも大脇さんは、個別最適に踏み切らず、SaaSとしてのスタンダードを守ってきたからこそ今があるのではないか、と受けます。佐怒賀さんも、サービスは最大公約数でしか作れないと応じます。

大きなお客さんの強い要望で機能を変えてしまうと後が大変になる。そのジレンマにHRテックも日々向き合っている、と大脇さんはまとめます。

年月を重ねてSaaSというモデルへの理解が浸透し、データベースも整ってきました。大脇さんは、タレントマネジメントのような新しい領域へのチャレンジが、システムを通してより一般的に取り組める形になるといい、と締めくくります。そしてこの回の一番の学びは「データベースが大事」の一点でした。

まとめ

HRテックのマルチプロダクトは、いろんな順序で導入されますが、共通して土台になるのが従業員データベースでした。表記揺れの統合や事情の把握といった地味な作業こそ最大の関門で、CSと社労士が役割を分担しながら、要望に流されずスタンダードを守る姿勢が語られました。

• 多くのHRテック企業がマルチプロダクト化しており、ユーザーの一本化ニーズが後押ししている
• 個別に入れるなら勤怠が先。集計を見てから給与を設定でき、手戻りが起きにくい
• 複数プロダクトをつなぐ従業員データベースは、お金にならないぶん後回しにされがちだが、横展開には必須
• 表記揺れや旧姓・本名の使い分けなど、データベース構築は地味で時間のかかる最大の関門
• CSと社労士に明確な境界線はなく、法的観点・人事の実務・プロダクト特性を持ち寄る役割分担で協業する
• エンタープライズは縦割りと「業務にシステムを合わせて」問題が難所で、要望に流されずスタンダードを守る判断が効いてくる