成熟市場に参入する難しさとおもしろさ —— 勤怠管理機能PMの三好さんにインタビュー

SmartHRは、新しく勤怠管理機能をリリースしました！

そこで今回は、勤怠管理機能の担当プロダクトマネージャー（以下、PM）の三好さん（@hiroki_m）に、開発の裏側を伺ってきました。成熟市場である勤怠管理市場に新規参入するまでに、さまざまな困難を乗り越えてきた様子をお伝えできれば幸いです。

SmartHRだからこそ勤怠管理市場に参入する意味がある

—— まずは簡単な自己紹介をお願いします。

PMの三好です。社会人歴が23年に達してしまいました。キャリアの始まりは法人営業で、そこから代理店営業や、事業企画、PMなどを経て、2018年にSmartHRに入社しました。入社してからは5年ほど年末調整機能を担当し、いまは勤怠管理機能を担当しています。

—— 勤怠管理機能は先日（2025.4.2）に正式リリースされましたね。その後の反響はいかがでしょうか？

はい、想定はしていたとおり、多くの引き合いをいただいております。すでに複数のお客様が導入済みで、多くのお客様が導入前のトライアルを実施中です。

—— いい調子ですね！ちなみに、なぜSmartHRが勤怠管理市場に参入することになったのでしょうか？すでに世の中にはたくさんの勤怠管理プロダクトがあると思うのですが……。

それには大きく2つの理由があります。

ひとつめは、お客様から強い要望をいただいていたことです。SmartHRを使いやすいと感じられているお客様からすると、従業員の入社時にアカウントが作られるSmartHRで、そのまま勤怠管理もしたい、と思われるのは自然なことでした。

ふたつめは、勤怠管理で集まるデータによって、SmartHRならではの価値を生みだせることです。残業時間や欠勤などのデータと、タレントマネジメントのプロダクトのデータをかけ合わせることで、従業員の離職リスクや生産性を可視化できます。まだそこまでたどり着けていませんが、SmartHRが掲げる”well-working”に向けて、この勤怠管理機能が重要なピースになると考えています。

—— なるほど！SmartHRだからこそ参入すべき理由があったんですね！

勤怠管理の課題は「正しい勤怠情報が集まらない」と「設定が複雑」

—— 勤怠管理のことをよく知らないのですが、どのような課題があるのでしょうか？

50社ほどにヒアリングさせていただいたところ、大きく2つの課題がありました。

ひとつは、正しい勤怠情報を集めることの大変さです。すでにご利用いただいている勤怠管理プロダクトでも、従業員による打刻漏れはよく起きますし、それによってアラートが出ていても放置されがちです。それを修正するためには、上長や労務担当者から従業員に催促する必要があります。さらに、いざ修正してもらうとなると「これでいいですか？」という従業員からの問い合わせも起きるため、とにかく工数がかかります。放置された打刻漏れや打刻エラーが積み上がり、毎月の勤怠締め作業では、大量の修正依頼と確認作業に追われることになります。

—— たしかに打刻ってよく忘れちゃいます……、すみません。

もうひとつは、設定の複雑さです。労働時間を計算するためには、膨大な数の項目を設定する必要があります。労働時間制度（フレックスや変形労働制のこと）はなにか、出退勤予定時刻は何時から何時までか、法定休日・所定休日はいつか、日付の切り替え時刻は何時に設定するか、などなど…… 細かいものを含めればキリがありません。設定の変数が多いだけでなく、従業員ひとりひとりで異なる設定を適用することもあります。こうした背景から、勤怠管理の設定は複雑化しています。ヒアリングした労務担当者から、現在のシステムが正しく設定できているのかわからない、と伺ったこともあるくらいです。

—— そ、そんなに大変なんですね。勤務形態がそんなにバリエーションがあるものだったとは知りませんでした。

—— では、それらの課題に対し、SmartHRの勤怠管理機能はどのような価値を提供するのでしょうか？

まず、正しい勤怠情報を集めることの大変さに対しては、従業員による打刻漏れなどのエラーが起きているときに、上長や労務担当者がそれを検知して、修正依頼を出し、打刻修正してもらうまでを、少ないステップ数で行なえるようにしました。

究極的には、そもそも従業員が打刻を忘れたり、ミスしたりすることがなければ、修正や修正依頼なんてしなくていいはずです。将来的にはその状態を目指しています。

次に、設定の複雑さに対しては、労務担当者のメンタルモデルに沿った設計にすることで、どこになんの項目があるか簡単にわかるようにしています。

これも究極的には、手動による設定をなくしたいのですが、まずは必要な設定をいかに迷わずにできるか、という考えで作っています。

—— なるほど、すでにお客様に評価いただいている中で、まだまだ伸びしろがあるんですね。今後が楽しみです。

絵を描いてチームを巻き込み、アイディアを磨く

—— そんな勤怠管理機能の立ち上げからここまで、どのように進められたかを伺えますか？

私自身、年末調整の経験はあったものの、勤怠管理は素人だったので、最初はキャッチアップから始めました。厚生労働省が公開している資料を読んだり、競合他社が公開している情報をじっくり分析したり、勤怠管理プロダクトの開発に携わったひとにヒアリングしたり。

インプットだけだと理解度が上がらないので、概念モデルを作って、ドメインエキスパートやプロダクトデザイナー、エンジニアと議論もしました。

やはり絵があると議論は起きるもので、これによってチーム全体の理解度は上がりましたし、作るものの目線もおおまかには揃った気がします。

そのあとはモックを作って、さらに議論したり、お客様にヒアリングしたりして、アイディアを磨いていきました。お見せしたお客様の反応が良かったので、進んでいる方向性に間違いはなさそうだ、という感触はありました。

—— ドメイン知識のキャッチアップからここまでのスムーズさ、さすがです。

間に合わせるために、なんでもやる

—— その後も順調だったのでしょうか？

いえ、もちろんそんなことはなくて、ずっとつまずきだらけでした。

最初の難しさは、売るための必要最低限のラインが高いことでした。勤怠管理プロダクトの市場は成熟していて、多数の競合がひしめいています。その中で、いくら「いい！」と言われても、買っていただくには、当初からそれなりの機能を揃えておく必要がありました。勤怠管理は、お客様の勤怠ルールを少しでもカバーできなければ採用いただけない、シビアな市場です。

一方で、事業計画から逆算して、リリース予定日は大まかに決めていたので、普通にやっていては間に合いません。そこで、作ることにした機能であってもスコープをギリギリまで削ることと、チームの開発速度を上げるためになんでもやることは意識しました。

—— なるほど、「なんでもやる」を具体的に教えていただいてもいいですか？

ほんとうになんでもですね。人が増えれば開発が早くなるというものではないものの、やはりエンジニアの数は足りなかったので、進めていくうえでここまでは増やしたほうがよいというギリギリまでエンジニアを増やしてもらえるようにあれこれ働きかけたり。生産性向上のためにスクラムイベントをなるべく同日にまとめたり、午後は打ち合わせがないように日程調整したり。また、チームをさらにサブチームに分けて、並列で作業を進められるようにしたりもしました。

もちろん勝手にひとりで決めたわけではなくて、チームと議論しながら、実行にあたってもたくさんのひとに頼らせてもらいました。ありがたいことに、分野ごとに自分より詳しい人がいるチームなので。さすがにいろいろ頼りすぎかなと思ったら、「やるべきだと思っていることならどんどん言ってほしい」と言われることもあり、ほんとうに心強かったですね。

—— それは心強いですね。それでリリース予定日には間に合ったのでしょうか？

はい、おかげで爆速で開発が進み、なんとか昨年、2024年10月に、正式リリースに先行して、一部のお客様に限定してですがリリースできました。目標にしていた日より1週間早かったくらいです。チームのみんなの頑張りのおかげですね。

—— いい話だ……。

成熟市場 x 成長企業ならではの難しさ

—— 先ほどつまずきだらけだったとおっしゃっていましたよね。このあともなにか困難があったのでしょうか？

そうですね。このあとはまた違った難しさがありました。

2024年10月の先行リリースまでは、PMである自分やドメインエキスパート、PMM、それに勤怠管理機能専門のプロダクトセールスが中心となって商談に臨んでいました。それが、10月以降はいよいよほかのセールスも巻き込んで売っていこうということになりました。

しかし、蓋を開けてみると、プロダクトがカバーできているスコープがまだ狭かったために、セールスを巻き込んで積極的に売ってもらうことは難しいことがわかりました。

もちろん、買ってもらえそうなお客様はいると思っていたのですが、勤怠管理という成熟市場では、当時の我々のプロダクトを売るにはまだターゲットにできる市場が小さかったのです。そうなると、成長企業であるSmartHRで、常に高い売上目標を追うセールスに、積極的に売ってもらうにはハードルが高かった、というわけです。

—— なんと、成熟市場 x 成長企業ならではの難しさがでてきましたね。それでどうされましたか？

あらためて戦略を練り直し、どのセグメントをどういう順番でターゲットにしていくかを整理し直しました。そして、それに合わせてプロダクトの開発計画を見直しました。

その上で、セールスには、戦略とそれに基づいた機能の開発予定を共有し、その計画に基づいて、徐々に動いていただく規模感を拡大していただくようコミュニケーションを取り直しました。ここはPMM（プロダクトマーケティングマネージャー）を中心に動いてもらいましたね。これにより、セールスは先を見据えて早く広く動けるようになり、いまは受注数という形で結果が現れ始めています。

ただ、事業計画を達成するためには、さらに爆速で開発を進める必要があるので、まだまだ大変です。

—— プロダクト戦略と、事業戦略と、販売戦略がセットだった、ってことですね。なるほどー。

勤怠管理業務の奥深さ

—— ここで少し話を変えて、そんな爆速開発を支える開発チームについてお伺いしてもいいですか？

それで言うと、一体感が強いチームだなといつも感じています。提供価値を最大化していくために、お互いに得意な領域を任せているのですが、だからと言って変に線を引くことなく、率直に職種を超えて思ったことを言い合えています。おかげで、一丸となってプロダクトを作れている感覚があります。

あと、PMMとも密に連携しています。先に話したとおり、プロダクトの成長は事業戦略とプロダクト戦略、販売戦略に一本筋が通っていることが鍵になります。そこをいっしょに考えてくれるPMMは、とにかく頼りになります。

—— それは心強いチームですね！

ただ、爆速で開発が進む一方、勤怠管理という業務は奥が深く、私自身まだまだ解像度が低いところがあります。そこの解像度を上げる時間が足りていません。

—— お、そうなんですね。その「奥深さ」についてもう少し伺ってもいいですか？

例えば、法定労働時間は8時間なので、固定労働時間制やフレックスの場合は、勤務時間が8時間を超えると割増賃金が発生します（注：変形労働時間制の場合はその限りではありません）。一方、会社が定める1日に働く必要がある所定労働時間は、通常、8時間以内で設定されます。この所定労働時間を超えた場合でも、法定労働時間を超えていない場合は、割増賃金を払う必要はありません。しかし、会社によっては所定労働時間を超えたら残業代を払う場合もあるのです。つまり、所定労働時間が7.5時間の会社があったとして、7.5時間を超えたら残業代を払う場合と、7.5時間を超えても法定の8時間を超えるまでは払わない場合の2パターンが存在します。

別の例としては、週に1度の付与が定められた法定休日（一般的に日曜日）に勤務すると、割増賃金が支払われます。一方で、多くの会社で定められている所定休日に勤務した場合、法律上は割増賃金を払う必要はありません。しかし、実際には、所定休日に割増賃金を支払う会社が多く存在します。

このように、勤怠管理では、法律上は明文化されていないところにルールが作られて運用が行なわれていることが多くあります。勤怠管理プロダクトは、これらの実際の運用をカバーする必要があるのです。そういったお客様の実務の解像度を上げつつ、中長期の戦略を練るには、まだまだキャパが足りないなと感じています。

—— ふむふむ。課題を感じつつも、三好さんがこの勤怠管理という業務におもしろさを感じているのが伝わってきます。