■ 1. 記事の背景と目的
- SmartHRのHRアナリティクス開発チーム（ceris、theo、kurihara、Yuna）による事例紹介
- AIによる開発コスト低下を背景に、エンジニアに求められる「何を作るか」の判断力の重要性が増している
- グラフ分析機能における離職率の計算仕様決定を通じ、エンジニアが意思決定に主体的に関与した過程を紹介
■ 2. グラフ分析機能の背景
- 少子高齢化による労働力不足を背景に、「人的資本経営」への関心が高まっている
- 人材流出への課題意識を持つ組織が増加している
- SmartHRは労務管理の中で従業員の入退社・部署・役職等の情報を自然に蓄積できるため、追加のデータ投入なしに組織分析が可能
- グラフ分析機能の活用例:
- 離職発生率が高い部署の特定
- 平均年齢が高く定年退職による人手不足が懸念される役職の早期発見
■ 3. 「離職率」の定義と計算方式の多様性
- 離職率には統一された計算式が存在しない
- 厚生労働省の雇用動向調査における定義:
- 離職率 = 離職者数 ÷ 1月1日現在の常用労働者数 × 100
- 国全体の労働市場を俯瞰するための指標であり、個社のHR分析には適さない場合がある
- 分母の取り方による数値の変動（同一データ・同一期間での比較例）:
- 期首人数ベース（100名）: 離職率 12%
- 在籍＋入社ベース（120名）: 離職率 10%
- 中途採用が活発な組織ほど差が拡大する
- プロダクトで離職率を扱う際は「対象期間・対象従業員の定義」を自チームで決定する必要がある
■ 4. HRアナリティクスチームにおける仕様決定の過程
- PdMからの要求は「組織全体の傾向として離職率を可視化したい」というもの
- エンジニアが実装担当としてではなく「何を作るかを決める一員」として動いた
- エンジニア自身が計算方式を調査・選択肢を洗い出し、技術的観点を含むトレードオフをチームに提示
- 議論のテーブルに載った主な論点:
- 分母は「期首在籍者のみ」か「期首在籍者＋期間中入社者」か
- 休職者を在籍に含めるか否か
- 対象期間の1年を操作日起点の「相対日付」とするか、基準日月末起点の「暦月」とするか、また当月を含めるか否か
■ 5. 採用した仕様とその理由
- 分母（計算式）:
- 採用式: 離職率 = 退職人数 ÷（在籍人数 + 入社人数）× 100
- 理由: 対象期間中にその組織に属した全員を対象とするため、中途採用が活発な時期でも数値が不自然に高低しない
- 期間の区切り方:
- 採用: 暦月方式（基準日の月末を起点に1年）
- 不採用: 相対日付方式（操作日を起点に1年）
- 理由: 既存プロダクト「人事労務レポート」が暦月基準で離職率を集計しており、同一SmartHR内での数値の不一致を防ぐため
- 当月データの取り扱い:
- 採用: 当月を含める（月末までの予定データを含む）
- 理由: 関連機能との挙動の一貫性を優先し、最新データを取り込める
- 決定内容と却下案・理由はADR（Architecture Decision Record）に記録し、誰でも経緯を辿れるようにした
■ 6. チームの意思決定を支える工夫
- 「調べる」「話す」時間の確保:
- ドメインのキャッチアップを明示的なタスクとして工数を確保（実装の片手間ではなく腰を据えた調査）
- 一次情報（ヒアリング・要望）をPdMも交えてチームで対話し、「なぜ」を掘り下げる
- リリース前に社内の人事担当者を対象としたドッグフーディングを実施し、フィードバックをチーム全員で共有
- 意思決定と仕様のNotionによる一元管理:
- PRD・仕様書・ADRをNotionで管理し、ポータルページを入り口として整備
- フィーチャーごとのドキュメントを読み込ませたカスタムエージェントを設置し、仕様の問い合わせを効率化
- レビュー依頼をカンバン形式で管理し、依頼状況を可視化
- 心理的安全性の確保:
- デイリースクラムに相談時間を設ける
- リモート中心の環境で週1回・30分の雑談タイムを設ける
- Slackで良い行動にスタンプを付け、レトロスペクティブで褒め合い・感謝を伝え合う習慣を運用
- ハード（仕組み）とソフト（関係性）の両輪が整うことで、調査・意思決定がスムーズに機能する
■ 7. 結論
- 離職率の定義決定は、エンジニアが「何を作るか」に主体的に関与した事例
- AIによって「どう作るか」のコストが低下する現在、「何を作るか」を判断するプロセスの価値はむしろ高まっている
- PdMの要求をそのまま実装するのではなく、ドメイン学習・論点提示・トレードオフ明示・チーム合意という積み重ねがユーザーへの価値提供につながる