フルスペックな競合の中で後発SaaSが選ばれる理由。ドメイン知識を土台に課題を聞ききる、SmartHRのヒアリング術

成熟市場に後発プロダクトとして参入する際、「競合に見劣りするのではないか」という焦りから、終わりの見えない網羅的な機能開発に陥ってしまいがちです。

フルスペックな機能を揃えた競合がひしめく「勤怠管理」の市場にもこうした難しさがありました。この市場に挑んでいるのが、クラウド人事労務ソフト「SmartHR」を開発する株式会社SmartHRです。2025年4月に勤怠管理機能をリリース後、順調に受注を広げていると聞きます。同社はなぜ、リリース当初から「選ばれるプロダクト」をつくることができたのでしょうか。

リリースを主導したプロダクトマネージャーの三好博輝さんによると、そのカギは、顧客の「バーニングニーズ」の解決につながる機能に開発のスコープを絞ることでした。ヒアリングで得た多くの課題の声から、リリース時に対応すべきニーズをどう見抜くのか、その手法を三好さんに取材しました。

• keyboard_arrow_down 競合プロダクトの機能は「つくって当たり前」
• keyboard_arrow_down 複数の候補から見つかった「締め作業」におけるバーニングニーズ
• keyboard_arrow_down コツは「大変」という言葉の重みを測ること
• keyboard_arrow_down 機能要望はスコアリングを行い、優先順位を決める
• keyboard_arrow_down 過去の失敗で痛感したドメイン知識の重み

――今年4月、労務管理プロダクトの新機能として「勤怠管理」をリリースしましたね。後発でプロダクトを開発する際、どのような流れで機能のスコープを定めているのですか。

三好：最初に「必要最低限」といえる機能の定義、次に「バーニングニーズ」の絞り込み、そして最後にターゲット戦略に合わせた開発優先度の見極め、という流れで機能のスコープを決めていきました。

まず1つ目についてですが、ここでは顧客がプロダクトの導入により「価値」を感じられる最低限の機能とは何かを明確にします。勤怠管理の場合、全従業員による勤務実績を集計して給与計算用データを出力するまでの一連の業務フローを完遂するための機能がなければいけません。

具体的には、従業員の出退勤打刻を受け付ける。そのデータをシステム上に自動で集計し、管理者が確認できる状態にする。従業員から休暇の申請があれば、上長に通知し、確認・承認を促す。月の締め日には、確定した勤怠データを、給与計算システムへ連携できる形式で出力する、といった機能です。

ただ、競合はすでにフルスペックなプロダクトをリリースしています。そのため、必要最低限の機能を満たしただけでは、競争に勝てません。

そこで次に、差別化を図るための「バーニングニーズ」、つまりユーザーに共通する、最も大きなペインにつながる課題をつかみ、それを解決する機能を考えます。業務を完遂するための機能の「骨組み」に、肉付けしていくイメージです。

最後に、必要最低限の機能を開発した後のプロダクトロードマップを明確にするために、注力するターゲットを絞り込みました。ヒアリングで得た情報や既存のデータを改めて分析し、ユーザーをセグメント分けし、どのようにターゲットを広げていくかを明確にしました。

――そこまでして、ようやく選ばれるプロダクトにはなるのですね。

三好：そうですね。勤怠は業務の根幹を支えるプロダクトなので、導入までには時間がかかるし、入れ替えのハードルが非常に高い。プロダクトを変えることで、これまでできていたことができなくなるのは受け入れられづらいのです。「勤怠管理も含め、労務やタレントマネジメントの業務をSmartHRに一元化できる」というだけでは、乗り換えの理由としては弱い状態です。ただ、できないことをできるようにする開発だけをしていくと、永遠に機能の○×を埋めるだけの開発になってしまいます。

——機能を磨き込むなかで、今回認識した「バーニングニーズ」はどのようなものでしたか？

三好：勤怠管理のなかでも月1回の「締め作業」というワークフローに着目しました。

これは、労務担当者やマネージャーが従業員の打刻に基づき労働時間を確定する作業です。ヒアリングを重ねるうち、ここで大きなペインが発生していることがわかりました。実際には、従業員による休暇申請の出し忘れや打刻漏れが生じるため、担当者は月末から給与計算まで長くて5営業日ほどで、従業員一人一人に催促し、正しいデータを入力してもらわなければならないのです。

勤怠管理の締めの時点で、確認・修正する必要がない綺麗な勤怠データがほしい、というのが多くのユーザーに共通する「バーニングニーズ」と捉えました。従業員が忘れずに打刻・申請をする仕組み、マネージャーが忘れずに承認できる仕組み、漏れがあればアラートを出す仕組みが大事であると捉えたのです。

――そこにバーニングニーズがあることはどのように見極めたのでしょうか？

三好：地道に、SmartHRの顧客企業を中心に数十社ほど課題ヒアリングを行いました。限られたヒアリング時間中に、各社の労務担当者から普段の業務の流れを聞きながら、共通する大きな課題をいくつか見つけ、業務フローと照らし合わせながら絞るのです。

今回、「締め作業」以外で挙がった候補は主に3つです。

まず法令違反の検出。三六協定や年次有給休暇の法令違反リスクがある従業員を判別するのに苦労している担当者が数多くいました。出力したExcelファイル上でフィルタリングをかけ、対象者に通知する作業を毎月繰り返しているというような状況で、これはかなり苦痛だとわかりました。2つ目が給与計算との連携。CSVファイルの勤怠データを手で加工して連携させる既存のやり方では人的ミスのリスクが高いのが課題でした。3つ目は勤怠と人事労務のデータベースを別々に更新する作業の手間。ただ、これはSmartHRの勤怠管理であれば、人事データベースを共通化することで解決できるため、このペインを深掘りすることは考えませんでした。

これらの課題が見えた各業務フローを定量化していくと、1人あたりの作業工数が最も大きかったのが締め作業でした。管理画面を開く、勤怠データのファイルを開く、従業員の打刻漏れを催促する、といった一連の作業にかかる時間やマウスをクリックする回数など、負担の大きさは明らかでした。

――ヒアリングの限られた時間で課題をしっかり聞き取るコツはありますか？

三好：全業務の内容について聞く余裕はないため、事前に業務フローをひと通り理解し、自分のなかで「この業務に痛みがあるのではないか」という仮説を立てたうえでヒアリングに臨みました。

仮説の立て方としてはまず、労務関連の書籍などを参考にしつつ、一般的な業務フローのイメージを可視化しました。そのうえで、社内にいる勤怠管理の実務経験者、勤怠管理プロダクトの開発経験者に、実態とのズレがないかチェックしてもらいました。さらに、自分で他社プロダクトも触ってみて「この業務は大変そうだな」「この機能は使いにくそうだな」とペインの当たりをつけていました。

このように仮説を持ってヒアリングに臨むと、短時間で核心となる情報を引き出すことができたし、相手からの回答に対して「まったく知らない、深掘りできない」という状況にもならなかったです。限りある時間の中で、比較的早い段階から答え合わせのような形になっていました。

――ペインを深掘りする際のポイントを教えてください。

三好：初めに本当に深掘りすべきペインを見極め、その次に、ペインの大きさを測る指標となる事実情報を聞くことです。

最初のポイントとして、対象者の表情と声のトーンの変化に注目し、深掘りすべきペインを見極めています。これまでのヒアリングの録画を見返すと、私が「具体的にこういうことですか？」と聞いたとき、相手の実務での悩みに直結すると「そうなんですよ！」と強めに返されたり、身振り手振りに感情が現れたりします。そういう反応をその場で見逃さずに、深掘りすると、本当に価値がある話が引き出せる印象があります。

次のポイントとして、1つのペインを深掘りします。コツは、時間や手数がどれくらいかかっているか、具体的な事実情報を聞くことです。「何が大変ですか？」と聞いても、一定の閾値を超えたものは全部「大変」という表現になってしまいます。

たとえば「1日8時間かかる業務です」と言われたら、本人がそう言わなくても明らかに大変だとわかるし、効率化の余地があると判断できる。逆に「大変」と言いながら、具体的な業務内容を聞くと、実はそれほど大した作業じゃないこともあります。もちろん、大変さには定量的な観点と精神的な観点があるので、その両面から把握することが重要です。

――ニーズを見つけたら、どのように機能に落とし込んでいますか？

三好：課題ヒアリングでニーズにアタリがついたら、今度はソリューションヒアリングを行います。仮説として立てた課題に対するソリューションとして画面のモックや動くプロトタイプをつくり、フィードバックをもらいます。これを、初期ターゲットとして仮説を立てている企業群に対して実施しました。

実際に顧客に使ってもらうと、改善すべき部分や磨くべき部分がよくわかります。勤怠管理の場合、締め作業に特化した機能自体は他社プロダクトにもありますが、同じ機能でも使用感や操作のしやすさに差があります。磨けば強みになるので、私たちはUI/UXで差別化を図りたいと考えました。特にバーニングニーズである「締め作業」の使い勝手については、すでに打刻忘れや承認忘れのアラートを出すなどの工夫も行っていますが、リリース後の現在も改善を続けていきます。

――顧客から寄せられる機能要望の中には、市場全体に共通するものから「n=1」の意見まで、色々なものがあると思います。こうした要望をどのような基準で実装計画に落とし込んでいますか？

三好：セールスやカスタマーサクセスを通じて寄せられる顧客の要望は全て、私とプロダクトマーケティングマネージャーで、課題に変換したうえで、スコアリングをします。おもなスコアリング項目としては、（１）解決しないと勤怠管理にどれだけ支障をきたすかという「業務への影響度」、（２）他のユーザーでも起こりえるかという「汎用性」、（３）ロードマップで定める「プロダクトの方向性」と合致しているか、があります。複数の軸でスコアリングして重要度を定め、ロードマップと照らし合わせながら実装時期を決めています。

ロードマップ上では、半年先までは開発する機能を具体的に決めているため、半年以内に実装予定がある機能で、かつスコアリングも高い場合、前倒しして実装するという意思決定をします。

半年より先は狙うターゲットと到達していたいプロダクトの状態、必要な機能要件を定めています。現在は、まだ他社でできていることを自社でもできるようにしていくことが多いフェーズであるため、課題に優先順位はつけつつも、まだそれらの多くが重要度が高い状態です。そのため、優先順位を低く設定した課題であっても、営業活動や利用しているお客様から得たフィードバックによって、狙っているターゲット像と合致している、事業目標の達成に寄与できそうなど、将来的に解決する必要のある課題であれば、「先取り」して実装することがあります。

――ターゲットとして想定していなくても、売上への貢献が見込める大企業からの要望が上がってきた場合、取り込みたくならないのでしょうか。

三好：個別のニーズには応えないのが基本的な考え方です。ただ、開発工数やカバーできる規模、運用に与える影響等を勘案して、場合によっては検討することもありえます。ただ、そうした判断は、現時点で決め切るのが難しいのが正直なところです。

そもそも勤怠管理で「汎用的」と言える機能は、全業種の6割くらいの顧客のニーズを満たすものです。残りの4割は、業種や企業によって全然ニーズが違うので、「いつつくるか」ではなく「本当につくるべきか」という判断が都度求められます。

たとえば、医療・介護・福祉・運送といった業界にはそれぞれ特有の大きな課題があります。基本的にどのニーズも深く、すぐに対応できるかわからないものがほとんどです。それから企業の規模が大きくなると、独自のルールで運用している企業が一定数出てきます。数万人規模の企業から「このルールに対応する機能要件さえ満たせれば導入する」という話をもらった場合、まず判断するのは、その機能がある程度「汎用的」かどうかです。もし将来的に他のお客様にも展開できるような機能であれば、ロードマップに組み込んで実装することもあります。

ですが、その企業だけの個別ニーズなら、運用の工夫でカバーできないか、受注時期をずらせないか、という交渉になります。

――最後に、「バーニングニーズを捉え、機能開発に落とし込む力」を養う方法を教えてください。

三好：先輩のやり方を学んだり、事例や書籍を読んだりして身につけてきました。最近出た書籍では、具体的な業務や顧客のイメージをつかむうえで馬田隆明さんの『解像度を上げる』が参考になりました。また、ターゲット設定の考え方では、三枝匡さんの『戦略プロフェッショナル』がとても参考になります。「戦略を決めるとき、ターゲットをいかにシンプルに定めるかが全てだ」と書かれていて、まさにその通りだと感じます。

ただ、大前提として、重要なのはドメインへの理解です。

▲『解像度を上げる――曖昧な思考を明晰にする「深さ・広さ・構造・時間」の４視点と行動法』馬田隆明 著、英治出版、『決定版　戦略プロフェッショナル 戦略独創経営を拓く』三枝匡 著、ＫＡＤＯＫＡＷＡ

――ドメイン知識はどのように身につけているのですか。

三好：基本的なルールや制度については、本を読む、一次情報を取りに行く、知見を持っている社内の人に聞く、といったことをしています。加えて、顧客がどういうロジックで勤怠のプロダクトを決めるのか、その判断軸を知るために、商談に同席するなどしています。

正直なところ、自分もまだまだ勉強中で、今も全ての意思決定が必ずうまくいくとは思っていません。「この機能はリリース段階では必要なかった」「この機能を先に実装するべきだった」と後になって反省した過去の経験を振り返ると、多くの場合、お客様の業務理解が甘いなど、ドメイン知識の不足が原因だったと感じます。

ドメイン理解があるからこそ、顧客の感覚的な言葉の裏にある本当のニーズをつかみ、それを解決できるプロダクトを開発できると思っています。近道はありませんが、これからも「事実」に真摯に向き合い、地道に学び続けたいです。

取材：古屋 江美子、池田 恵実
執筆：古屋 江美子
編集：池田 恵実、王 雨舟
撮影：赤松 洋太