この記事は、SmartHRのタレントマネジメント領域にご興味をお持ちの方向けに、私たちがどのようなプロダクトを作り、その開発にどのような難しさや面白さがあるのかを紹介するものです。
お気軽にカジュアル面談のお申し込みをお待ちしております！
募集中の職種
SmartHR エンジニア採用ページにて、タレントマネジメント領域の求人を掲載しています。ぜひご覧ください！
なぜSmartHRがタレントマネジメントプロダクトを開発するのか
突然ですが、質問です。
あなたの組織の離職率が30%だったとします。原因はどこにあり、何から手を付けるべきでしょうか。評価制度でしょうか、配置でしょうか、それともマネジメントでしょうか。そもそも離職率30%は問題なのでしょうか。
この問いに即答できる人は、ほとんどいないのではないでしょうか。難しさは大きく2つあります。
- 判断材料になる評価の記録や異動の履歴、サーベイの結果が、組織として管理・蓄積されていない
- 仮に情報が揃ったとしても、何をもって問題と判断するかの基準が存在しない
1つめの「データの管理・蓄積」の難しさに、従業員データの基盤からアプローチしているのがSmartHRです。人事労務領域を中心としたバックオフィスシステムとして日々使われる中で、雇用契約や異動の履歴といった正確な従業員データが自然と蓄積される構造になっており、この従業員データ基盤がSmartHRの土台です。現在はこの基盤の上に、評価、スキル管理、サーベイ、配置、分析といったタレントマネジメント領域のプロダクトを展開し、人材活用の意思決定を支えようとしています。
2つめの「判断基準」の難しさには、いまも向き合っている最中です。法令のような基準がない、いわば「ルールや規則」がないタレントマネジメントの領域で、何を作れば人と組織の意思決定を支えられるのか。その開発の難しさと面白さを、ここから具体的に紹介していきます。
タレントマネジメント領域で作っているプロダクト
現在、SmartHRのタレントマネジメント領域では、複数のプロダクトを開発しています。
その全体像をまとめたのが、以下の図です。
図にあるとおり、これらはそれぞれ独立した業務を支えるプロダクトですが、単に個別のツールを増やすのではなく、従業員データを軸にプロダクト同士がつながることを重視しています。たとえば、人事評価の評価結果はキャリア台帳やスキル情報と組み合わせて育成計画や配置検討に活用でき、従業員サーベイの結果は組織単位の傾向として、マネジメントや組織づくりの改善に活用できます。プロダクトをまたいでデータや体験をつなげ、単体では実現しづらい意思決定支援を可能にしていくことが、この領域の開発で目指していることです。
タレントマネジメント領域ならではのプロダクト開発
正解が1つではない
タレントマネジメントの業務は、企業ごとに解釈や方針、制度や運用が大きく異なります。
評価制度1つをとっても、評価項目、評価フロー、評価者の役割、結果の活用方法は企業によってさまざまです。スキル管理やサーベイ、配置検討も同様に、組織の規模や文化、事業フェーズによって求められる形が変わります。
しかも、入力フォームや一覧画面を作れば終わりではなく、サーベイの配信、進捗管理、承認や差し戻し、締切後の集計といった業務運用まで含めて、ユーザーが迷わず使える形に設計する必要があります。
たとえば、オフィスワーカー中心の企業と、小売・飲食・製造のように多店舗・多拠点で現場業務を担う従業員が多い企業とでは、評価やスキルの捉え方、異動・配置の頻度や複雑さがまったく異なります。
企業ごとに形が異なるうえ、法令のような「ルールや規則」もないため、最初から唯一の正解を決めきることはできず、お客様と一緒に「正しい状態」を探していくことになります。
私たちは、お客様の課題を理解し、仮説を立て、実際に使ってもらいながら学び、プロダクトを改善していきます。
探索とエンタープライズ品質を両立する
こうした探索的な開発でありながら、この領域のプロダクトは比較的早い段階から大規模な企業にも導入されます。人事労務領域の「SmartHR」がすでに大規模な企業を含む多くの企業に利用されており、タレントマネジメント領域のプロダクトはその従業員データ基盤の上で既存のお客様にも提供されるためです。そのため、仮説検証のスピードと同時に、エンタープライズSaaSとしての信頼性も求められます。
一見矛盾するこの2つの要求を、どちらか一方に切り捨てるのではなく、あえて抱えたまま乗りこなす。SmartHRではこれを「矛盾の内包」と呼んでいます。どこまで探索に振り、どこで品質を担保するかを両立するための創意工夫にこそ、タレントマネジメント領域ならではの難しさと面白さがあります。
複数プロダクトを横断して価値を作る
タレントマネジメント領域では、単一プロダクトだけで完結しない価値が多くあります。
たとえば「次の異動候補者を検討する」という1つの業務でも、従業員の経歴やスキル情報など、複数プロダクトのデータを重ねて初めて判断できます。このとき、従業員データをどの粒度で共通化するか、確定前の評価結果を配置検討の画面でどこまで見せてよいか、といった問いには、単一プロダクトの設計だけでは答えが出ません。
どこまで共通化し、どこから個別の業務に合わせるのか。その境界を考えながら設計しています。ここに、プロダクトを横断してデータをつなぎ、意思決定に活かす難しさと面白さがあります。
エンジニアリング上のチャレンジ
前述のとおり、この領域のプロダクトは早い段階から大規模な企業に導入されることがあります。新しい業務フローを試しながらも既存のお客様の運用を壊さないよう、段階的なリリース、データ移行、後方互換性、テスト、監視を常にセットで考えつつ、仮説検証とエンタープライズSaaSとしての品質を両立させています。
加えて、SmartHRならではの前提がもう1つあります。これらのプロダクトが、人事労務で蓄積された従業員データ基盤の上で、複数プロダクトとしてつながって動いていることです。ここで紹介するチャレンジはどれも、この「従業員データ基盤 × 複数プロダクト」という構造の上で向き合うことになる難しさと面白さです。以下では、データモデル、権限、パフォーマンス、フロントエンド、AIという5つの観点からチャレンジを紹介します。
柔軟なデータモデルを設計する
タレントマネジメントの業務は企業ごとの差分が大きいため、データモデルには柔軟性が求められます。一方で、何でも自由に設定できるようにすると複雑さが増し、ユーザーにとっても開発者にとっても扱いづらくなります。この「どこまで柔軟にするか」の見極めが、実はいちばん悩ましいところだったりします。
たとえば人事評価であれば、評価シートの項目構成、多段階の評価フロー、期中の組織変更や評価者の交代、確定後の評価履歴の持ち方など、企業ごとに異なる制度をどのような構造で表現するかが問われます。評価項目を自由に設定できるようにするほど、集計や分析、他プロダクトからの参照は難しくなります。この柔軟性と扱いやすさのトレードオフをどこに置くかを、業務理解にもとづいて判断していきます。
機微な情報を扱う権限設計
タレントマネジメント領域では、評価結果、サーベイ回答、スキル情報、配置検討に関する情報など、機微性の高いデータを扱うため、権限設計が非常に重要です。「管理者だから全部見られる」といった単純なものではなく、所属、役職、評価フロー上の役割、本人か上長か、人事担当者か、確定前か確定後か、といったさまざまな条件が絡みます。さらにSmartHRでは、従業員情報や権限（ロール）が複数プロダクトを横断してつながっているため、権限制御をプロダクト間でどこまで揃えるかも設計の対象になります。単一プロダクトに閉じない権限基盤づくりは骨の折れる開発ですが、その分なかなか経験できない、エンジニアのキャリアとしても価値のあるチャレンジです。
誰が、どのデータに対して、どの状態で、どこまで閲覧・編集できるのか。単なるアクセス制御ではなく、業務そのものを理解したうえでプロダクトの仕様として安全に表現し、監査性を保ちながら誤操作や意図しない閲覧を防ぐ設計が求められます。
私たちがこの設計で基準にしているのは、企業側の使いやすさだけではありません。自分の評価やサーベイの回答がどう扱われるかは、従業員本人にとっても大きな関心事です。データを提供する本人が納得できる状態を保つことは、機微な情報を扱うプロダクトの前提だと考えています。
大量データとパフォーマンス
従業員数が多い企業では、扱うデータ量も大きくなります。特に、全国に数百〜数千の店舗や拠点を展開し、アルバイト・パートを含む数万人規模の従業員を抱える企業もあります。
評価シートやコメント、評価履歴、サーベイ回答、スキル情報などが積み重なると、一覧表示、検索、集計、CSV出力、分析の処理負荷は高まり、評価の締切前などアクセスが集中しやすい場面もあります。そのため、単にクエリを速くするだけではなく、どのタイミングで何を事前計算するか、どの処理を非同期にするか、ユーザーにどのような待ち時間として見せるかまで含めて設計します。
「誰もが使える」を技術で実現するプロダクト体験
エンジニアリングのチャレンジは、バックエンドだけではありません。SmartHRは、人事担当者から日々現場で働く従業員まで、職種も利用環境もさまざまな、すべての働く人が使うプロダクトです。業務でパソコンを使う頻度も、利用する端末も、人によって大きく異なります。だからこそ、「誰もが使える」を技術で実現することに投資しています。
具体的には、複数プロダクトで共通のデザインシステムを整備し、アクセシビリティ（a11y）や多言語対応に取り組んでいます。とくにアクセシビリティは、設計レビューや実装時のチェックとして日々の開発プロセスに組み込んでいます。こうした体験品質を、フロントエンドの技術と仕組みによって複数プロダクトで揃えていくことも、この領域ならではのチャレンジです。
AIを活用したプロダクトと開発プロセス
タレントマネジメントの業務には、対象者の洗い出し、設定作業、進捗確認、リマインド、集計など、定型的で繰り返しの多い作業が数多く含まれます。こうした作業をAIや自動化で置き換え、人事担当者が「作業する」時間を「判断する」時間に変えていくことは、この領域の大きなテーマです。
実際に初期設定を楽にするAI機能などのリリースも始まっており、機微な人事データを扱う領域だからこそ、AIの精度や安全性、説明可能性の担保まで含めて設計しています。
また、プロダクトにAIを組み込むだけでなく、開発プロセス自体でもAIを積極的に活用し、機能リリースのスピードを上げていくこともチャレンジの1つです。
どれも、単に機能を実装するだけでは解けません。業務を理解し、ユーザーにとっての価値を考え、将来の拡張性や安全性も踏まえながら設計していく課題です。
開発チームの進め方
私たちは仕様そのものをチームで発見し、形にしていくプロセスを大切にしています。ここでは、その進め方を紹介します。
仕様は、お客様の業務の中から発見する
ここまで述べてきたとおり、タレントマネジメントには法令のような「ルールや規則」がありません。ルールや規則がないということは、仕様は「誰かが決めて降ってくるもの」ではなく、お客様の業務の中から発見するものになります。評価フローをどう設計するか、権限の境界をどこに引くか、データモデルをどの粒度にするか。こうした問いは、業務の解像度が低いままでは、どれも決められません。
だからこそ、エンジニアがお客様や業務の解像度を上げることが、そのまま設計の質とプロダクトの価値に直結します。だからこの領域では、エンジニアも業務理解から開発に関わります。
職能を越えて仕様を作る
タレントマネジメント領域の開発では、エンジニアも「仕様書どおりに実装するだけ」ではなく、お客様の業務理解、ドメインモデリング、権限や状態遷移の整理、リリース後の利用状況の確認まで、職能をまたいで議論しながら開発を進めています。
実際、権限設計1つをとっても、「この状態のとき、誰が見られるべきか」という問いをめぐって、プロダクトマネージャー（PdM）、デザイナー、QA、UXライター、カスタマーサクセスを交えて何度も議論します。それぞれの視点から意見がぶつかり、最終的に安全で使いやすい仕様に落とし込めたときは、チームとして手応えを感じる瞬間です。
こうした動きは、AIを活用した開発が広がるなかで、さらに加速しています。各自の開発が並行して進むようになり、PdMが一人でプロダクトの意思決定を担うのは構造的に難しくなってきました。そのため、エンジニアがプロダクトのディスカバリーから担当するケースも生まれており、裁量を持ってプロダクトに向き合うことができます。
こんな人に来てほしい
ここまでの内容を踏まえ、こんな方にぜひ来ていただきたいです。
- 人事評価など、複雑な業務ドメインを技術で本質的に解決したい人
- 正解が1つではない領域で、お客様と一緒に仮説検証しながらプロダクトを育てたい人
- 従業員データ基盤の上で、複数プロダクトを横断するデータ連携や権限の設計に興味がある人
- 職能を越えて、業務理解や仕様づくりから開発に関わりたい人
まとめ
冒頭の問いに戻ります。あの問いに即答するのが難しいのは、判断材料が散らばっており、法令のような基準もないからでした。だからこそ私たちは、お客様と一緒に「正しい状態」を探しながら、SmartHRの従業員データ基盤の上に体験を積み上げ、企業の人材活用や組織づくりを支えていきます。
正直、まだ道半ばの領域です。だからこそ、一緒に悩みながら形にしていく面白さがあります。
そんなプロダクト開発に興味を持っていただけたら、ぜひ一度カジュアルにお話しできると嬉しいです！
SmartHRについて
最後に、SmartHRについてもう少し知りたい方向けに、この記事のテーマに関連する情報を絞って紹介します。
会社紹介資料
👇 SmartHRってもう大企業でしょ？入社してやることあるの？と思われた方へ
👇 まだまだ急成長中です
働き方
- SmartHRの働き方制度（2025年以降）
- コアタイムなしフレックスタイム制
- フルリモートワークOK（プロダクトサイドのみ）
- ワーケーション制度あり
