HR SaaSの個社対応はどこまで？CSが作り込みすぎる構造と境界線の引き方

HR SaaSはSlackやZoomのような業種を問わないサービスと違って、企業ごとの制度に合わせた個社対応が求められがちです。瀧田さんは、その理由をまず「制度そのものが会社ごとに違うこと」に見ています。

瀧田さんによると、HRドメインでは法律が最低限のラインを決めているものの、その上には天井がないのがポイントです。

つまり、会社ごとにユニークな休暇制度や独自の働き方があると、それをシステムに落とし込めるかどうかがそのまま「やるか、やらないか」の判断になり、個社対応が発生しやすくなるという話です。

城田さんは、自身が支援してきたSMBSMB ── Small and Medium Business。中小企業を指す言葉。SaaS業界では顧客の企業規模を分ける区分としてよく使われます領域では、むしろ制度の下限をどうコントロールするかを意識していたと振り返ります。

綾部さんが手がけてきたタレマネタレマネ ── タレントマネジメント。従業員のスキルや評価、配置などの情報を一元管理し、人材活用に生かす仕組みや領域のことの領域は、さらに個別性が強いといいます。自社システムやExcelからのリプレースが多く、独自の評価係数や評価ウエイトを再現できないと、そもそも導入が決まらないのだそうです。

その結果、個社ごとに必要な機能を次々と開発することになり、綾部さんは「どんどんユーザビリティが悪くなっていってしまう」のがあるあるだと話します。

CSからPMMに移った大脇さんは、これをプロダクト戦略の問題として捉えます。どこまでをベストプラクティスとして型化し、どこから余白を残すかが戦略上必要になるという指摘です。

城田さんは、この最初の期待値調整を誤ると「フルカスタマイズします」という話になってしまうと応じます。綾部さんの実感では、自社のやり方に合わせてほしいという後者のモチベーションで導入する顧客が多かったそうです。

2つ目のテーマは、CSがなぜ青天井に作り込んでしまうのか、という構造の話です。プロダクトへの機能要望はリソース問題で断りやすい一方、CS側でリソースを捻り出せば対応できてしまう問題があると城田さんは整理します。

綾部さんは、プロダクトでできないことをCSがやってしまう場面は当時からあったと認めます。

一方で綾部さんは、やらない線引きも決めていました。評価制度の構築のような抽象度の高い領域はスコープから外し、従業員の個人データの登録はセキュリティ観点から代行しなかったといいます。

瀧田さんも基本方針は同じで、設定代行や業務代行はしないと話します。短期的には顧客に感謝される「お土産」になっても、長期では別の負担が生まれるからです。

瀧田さんが一番気にしているのは、法律に関わるサービスならではのリスクだといいます。CS側が手を加えて何か誤ってしまえば、自社の問題になってしまうという懸念です。

もう1つの理由が、顧客に自走してほしいという思想です。CSが代わりにやりすぎると、顧客が自分たちで使いこなす体験が損なわれてしまうという指摘です。

城田さんは、やりすぎると顧客側でPDCAPDCA ── Plan（計画）・Do（実行）・Check（評価）・Action（改善）を繰り返して業務を改善していく考え方。ここでは顧客が自分たちで運用を回せるかどうかを指していますを回せなくなる側面もあり、そこをどう制御するかが重要なポイントになると受けます。

大脇さんも、以前担当していた自由度の高いプロダクトで同じ線引きをしていたと話します。設定代行はしないことを、オンボーディング資料の最初に明記していたそうです。

そのうえで、もし顧客が依頼したい場合は、有償で代行できるパートナー企業へエスカレーションする形にしていたといいます。やらないことを明確にして、それをやるなら有償という線を最初から示しておくのが共通の姿勢でした。

3つ目のテーマは、境界線をどこに引くかです。設定代行のような工数の線引きはしやすい一方、支援範囲の中で顧客のやりたいことが実現できるのにリソースの問題で難しい、といったケースがあると城田さんは投げかけます。

城田さんは、CSでやるのか、営業でやるのか、開発への要望として持っていくのか、そして有償のプロフェッショナルサービスとしてどこまで提供するのか、という切り分けを論点に挙げます。

綾部さんの領域では、プロダクトで完結しないことを求められた場合を有償の線としていました。具体的には1on1のやり方を教える研修や、評価制度の構築などです。

ただし綾部さんは、最初からいきなり有償化したわけではないと補足します。特定の企業に無料で試してもらい、価値提供ができると確かめたうえで有償に移していったという流れです。

瀧田さんの領域では、労務相談や就業規則の改定相談、給与計算代行やBPOBPO ── Business Process Outsourcing。企業の業務プロセスの一部を外部の専門会社に委託すること。ここでは給与計算など人事労務の実務を外部に任せるケースを指しますといった依頼がよくあるといいます。これらを自社で抱える場合もあれば、パートナーに流す場合もあるそうです。

瀧田さんの会社の方針は、プロダクトで完結すること以外はパートナーに流すという形です。社労士や業務代行ベンダーとの提携を広げ、何かあればそこへ流して3者や両者で補完する体制にしていると話します。

城田さんは、プロフェッショナルサービスを提供する人を育成・採用するとなると、自社にも採用育成コストがかかってしまう、と背景を補います。

大脇さんの以前のプロダクトは業種を問わない自由度の高いものだったため、線引きの切り口が違いました。業界ごとではなく、技術的なスキルレベルで線を引いていたといいます。

つまり、プログラミング知識がなくても現場で使えるのがプロダクトの特性で、より高いカスタマイズ性や他システムとの連携など技術が必要な領域になったらパートナーに任せる、という切り分けです。

同じ「有償の線引き」でも、ドメインが決まっているHR SaaSは制度や研修の領域で、業界を問わないプロダクトは技術の領域で線が引かれるという対比が浮かび上がりました。