記事のサマリー（TL;DR）
- SmartHR はARR150億円超・前年比150%成長を背景に、人事評価・スキル管理・サーベイ・配置・分析の5プロダクト群を展開中
- 法令のような「規則」が存在しないタレントマネジメント領域では、仕様をお客様の業務から「発見」するプロセスが設計品質に直結
- データモデル・権限・パフォーマンス・フロントエンド・AIの5軸で技術チャレンジを整理し、エンジニアが仕様策定から関与する開発体制を採用
国内人事SaaS・kintone／Salesforce利用企業が注目すべきデータ基盤設計の論点
SmartHR が公開したこの記事は採用向けではあるものの、その内容は「人事データを中核に複数業務SaaSをつなぐ」アーキテクチャ設計の実例として読み解くことができます。
注目すべきは「従業員データ基盤 × 複数プロダクト」という構造です。雇用契約・異動履歴といった日常業務で自然に蓄積されるデータを土台として、評価・スキル・サーベイ・配置の各プロダクトが横断的にそのデータを参照・活用します。kintone や Salesforce を人事マスタ代わりに運用している企業では、評価結果や配置履歴が別ツールに分散しがちで、「離職率30%の原因究明」のような横断分析が難しいという同じ課題を抱えているケースが多いです。
また、機微データの権限設計（所属・役職・評価フロー上の役割・確定前後の状態などの複合条件）は、専用UIやRailsアプリで業務SaaSを補完する構成においても避けられない論点です。SmartHRが「単なるアクセス制御ではなく、業務そのものを理解したうえでの権限基盤」と位置づけている点は、既存システムのAPI連携設計においても参照価値があります。
詳細
なぜ SmartHR がタレントマネジメントプロダクトを開発するのか
「組織の離職率が30%だったとして、原因はどこにあり、何から手を付けるべきか」——この問いに即答できない組織が多い理由は、大きく2つに整理されます。
- 判断材料（評価記録・異動履歴・サーベイ結果）が組織として管理・蓄積されていない
- 情報が揃ったとしても、何をもって問題と判断するかの基準が存在しない
SmartHR は1つめの課題、すなわち「データの管理・蓄積」に対し、人事労務バックオフィスシステムとしての日常利用を通じて正確な従業員データが自然と蓄積される構造を土台として持っています。雇用契約や異動の履歴はシステム利用の副産物として積み上がり、この従業員データ基盤がタレントマネジメント各プロダクトの起点になっています。
2つめの「判断基準」の難しさには、現在進行形で向き合っています。法令のような客観的基準が存在しない領域で、何を作れば人と組織の意思決定を支えられるのか——その問いがプロダクト開発の駆動力となっています。
タレントマネジメント領域で開発しているプロダクト群
現在 SmartHR のタレントマネジメント領域では、以下を含む複数プロダクトを並行開発しています。
- 人事評価：評価シート設計・多段階の評価フロー・承認・締切後集計
- スキル管理（キャリア台帳）：従業員ごとのスキル情報の記録・参照
- 従業員サーベイ：配信・進捗管理・組織単位の集計・分析
- 配置検討：異動候補者の洗い出し・経歴やスキルとの突き合わせ
- 分析：従業員データを横断した組織傾向の可視化
これらは独立した業務を支えるプロダクトでありながら、従業員データを軸に相互接続することを重視しています。たとえば、人事評価の結果はキャリア台帳やスキル情報と組み合わせて育成計画・配置検討に活用でき、サーベイ結果は組織単位の傾向としてマネジメント改善に活かされます。単体では実現しづらい意思決定支援を、プロダクト横断のデータ連携によって可能にするという設計思想です。
タレントマネジメント領域ならではの開発の難しさ
「正解が1つではない」業務ドメイン
タレントマネジメントの業務は、企業ごとに解釈・方針・制度・運用が大きく異なります。評価制度ひとつをとっても、評価項目・評価フロー・評価者の役割・結果の活用方法は企業によってさまざまです。オフィスワーカー中心の企業と、小売・飲食・製造のように全国数百〜数千店舗・数万人規模の従業員を抱える企業とでは、評価やスキルの捉え方、異動・配置の頻度や複雑さがまったく異なります。
法令のような外部基準がないため、最初から唯一の正解を定めることはできず、お客様と一緒に「正しい状態」を探し続けることが開発の基本姿勢になっています。
探索とエンタープライズ品質の両立——「矛盾の内包」
探索的な開発でありながら、タレントマネジメントプロダクトは比較的早い段階から大規模な企業に導入されます。人事労務領域の SmartHR がすでに多くの大規模企業に利用されており、タレントマネジメントプロダクトはその既存顧客にも提供されるためです。
仮説検証のスピードと、エンタープライズSaaSとしての信頼性——この一見矛盾する2つの要求を、どちらか一方を切り捨てるのではなくあえて抱えたまま乗りこなすことを、SmartHR では「矛盾の内包」と呼んでいます。段階的リリース・データ移行・後方互換性・テスト・監視を常にセットで考えながら、仮説検証を続けるという姿勢がこの開発体制の核心です。
複数プロダクトを横断した価値設計
「次の異動候補者を検討する」という1つの業務にも、従業員の経歴・スキル情報など複数プロダクトのデータを重ねる必要があります。このとき、「従業員データをどの粒度で共通化するか」「確定前の評価結果を配置検討画面でどこまで見せてよいか」といった問いには、単一プロダクトの設計だけでは答えが出ません。どこまで共通化しどこから個別業務に合わせるか——その境界設計が、この領域のアーキテクチャの要になっています。
エンジニアリング上の5つのチャレンジ
1. 柔軟なデータモデルの設計
企業ごとの差分が大きいタレントマネジメント業務では、データモデルに柔軟性が求められます。一方、何でも自由に設定できるようにすると複雑さが増し、集計・分析・他プロダクトからの参照が難しくなります。人事評価を例にとれば、評価シートの項目構成・多段階の評価フロー・期中の組織変更・確定後の評価履歴の持ち方など、企業ごとに異なる制度をどの構造で表現するかが問われます。「どこまで柔軟にするか」の見極めを業務理解にもとづいて判断し続けることが、最も難易度の高い設計判断のひとつとされています。
2. 機微な情報を扱う権限設計
評価結果・サーベイ回答・スキル情報・配置検討情報といった機微性の高いデータを扱うため、権限設計が非常に重要です。「管理者だから全部見られる」という単純な制御ではなく、所属・役職・評価フロー上の役割・本人か上長か・人事担当者か・確定前か確定後か、といった複合条件が絡みます。さらに SmartHR では従業員情報や権限（ロール）が複数プロダクトを横断しているため、権限制御をプロダクト間でどこまで揃えるかも設計の対象です。
設計の基準は企業側の使いやすさだけではなく、「データを提供する従業員本人が納得できる状態を保つこと」も前提として位置づけられています。
3. 大量データとパフォーマンス
数万人規模の従業員を抱える企業では、評価シート・コメント・評価履歴・サーベイ回答・スキル情報が積み重なり、一覧表示・検索・集計・CSV出力・分析の処理負荷が高まります。評価の締切前などアクセスが集中しやすい場面もあるため、単にクエリを速くするだけでなく、「どのタイミングで何を事前計算するか」「どの処理を非同期にするか」「ユーザーにどのような待ち時間として見せるか」まで含めて設計しています。
4. 「誰もが使える」を技術で実現するフロントエンド
SmartHR は人事担当者から現場従業員まで、職種も利用環境もさまざまなユーザーが使うプロダクトです。複数プロダクトで共通のデザインシステムを整備し、アクセシビリティ（a11y）や多言語対応に取り組んでいます。アクセシビリティは設計レビューや実装時のチェックとして日々の開発プロセスに組み込まれており、体験品質を複数プロダクトで揃えることもフロントエンドのチャレンジとして位置づけられています。
5. AIを活用したプロダクトと開発プロセス
対象者の洗い出し・設定作業・進捗確認・リマインド・集計など、タレントマネジメント業務には定型的で繰り返しの多い作業が多数含まれます。こうした作業をAIや自動化で置き換え、人事担当者が「作業する」時間を「判断する」時間に変えることが、この領域の大きなテーマです。
初期設定を楽にするAI機能のリリースはすでに始まっており、機微な人事データを扱う性質上、AIの精度・安全性・説明可能性の担保まで含めた設計が求められます。また、プロダクトへのAI組み込みにとどまらず、開発プロセス自体でもAIを積極的に活用して機能リリースのスピードを上げることも、継続的なチャレンジとして挙げられています。
開発チームの進め方
仕様はお客様の業務の中から「発見」する
法令のような規則が存在しないため、仕様は「誰かが決めて降ってくるもの」ではなく、お客様の業務の中から発見するものとして捉えられています。評価フローの設計・権限の境界・データモデルの粒度——こうした問いは、業務の解像度が低いままでは決断できません。エンジニアが業務理解の解像度を上げることが、そのまま設計品質とプロダクト価値に直結するという考え方から、エンジニアも業務理解から開発に関わる体制を採っています。
職能を越えて仕様を作る
権限設計ひとつをとっても、「この状態のとき、誰が見られるべきか」という問いをめぐって、プロダクトマネージャー（PdM）・デザイナー・QA・UXライター・カスタマーサクセスを交えて何度も議論します。AIを活用した開発が広がるなかで各自の開発が並行して進むようになり、PdM一人でプロダクトの意思決定を担う構造が難しくなってきたことも背景にあります。エンジニアがプロダクトのディスカバリー段階から担当するケースも増えており、裁量を持ってプロダクトに向き合える環境を目指しています。
SmartHR の事業規模と働き方（参考情報）
- ARR（年間経常収益）150億円超、前年比150%で成長中
- 2030年売上1,000億円を目標とする事業戦略を発表済み
- コアタイムなしフレックスタイム制、フルリモートワーク対応（プロダクトサイド）、ワーケーション制度あり