# チャプター1 みなさんこんにちは。スタートアップCSベースプレゼンツゼロから始めるCSラジオです。 この番組ではカスタマーサクセスの知見をドメインごとに解き明かしていきます。 今日から新シリーズHRテック編がスタートします。 全10回目までHRサース×カスタマーサクセスの知見を4人で言語化していきたいと思うのでよろしくお願いします。 前回の0回目ではシリーズの全体像をお話ししました。 今回は本編第1回でHRドメインのCSが難しい理由をお話ししていければと思いますので皆さんよろしくお願いいたします。 じゃあ早速ですが自己紹介から始めていければと思います。 まずは私からというところで改めて私が新規事業開発をやっているカスタマーサクセスの組織支援をしているエティの代表 そしてカスタマーサクセス向けのコミュニティスタートアップCSで主催しているしろたです。改めてよろしくお願いします。 今回はゲストMCに大垣さんそしてパーソナリティという形であやるさんと瀧澤さんをお呼びしているので改めてよろしくお願いします。 それでは大垣さんから簡単に自己紹介よろしくお願いします。 大垣です。サブMCを担当させてもらいます。 普段はアプリケーションプラットフォームアザサービスAPaaSと呼ばれる自分で現場主体でアプリを作れますというようなプラットフォームサービスで 去年までCSの立ち上げからマネジメントを6年ほどやって今年からPMMに移動して今新機能とかオプションの立ち上げというところを担当しています。よろしくお願いします。 よろしくお願いします。 じゃあ続いてあやるさんお願いします。 はい、あやると申します。私はこれまでですね、HRテックのCSですね、あと組織のマネジメントであったりとか、あと事業開発というところをやってきました。 現在は独立してCS組織の立ち上げの支援であったりとか、あとはCSの方向けのですねキャリア支援というところをやっています。本日はよろしくお願いします。 よろしくお願いします。 じゃあそれでは次、瀧澤くんお願いします。 はい、瀧澤と申します。私は新卒からですね、現在8年目になるんですけれども、最初からHRテックの業界で一本でやってきました。 そこでですね、組織の立ち上げから拡大というところまで研究させていただいてまして、現在ではエンタープライズ領域のオンボーディング部門ですね、マネージャーやらせていただいてます。よろしくお願いします。 はい、よろしくお願いします。 実はね、これテイク2というところでね。 またお茶のくらいでやりますか。 どちらかというと僕が録音ボタンを押し忘れたっていうね、これはみなさんのアイスブレイクのためにわざとやったってことにしましたけどね。 ダメなんですけどよろしくお願いしますというところです。 今回ですね、放送に関しては大きく3つのポイントを用意していますと、1個目がHRドメインは他のSaaS何が違うのかみたいなポイントと、 もう1つが業務、制度、組織の三重構造みたいなところをベースにお話ししていく。 最後に3つ目に関してはお客様の知識レベルによって動力がどう変わってくるのかみたいなお話をしていきたいなと思いますので、よろしくお願いします。 じゃあ早速ですね、HRドメインは何が違うのかみたいなところからいきたいなと思うんですけど、 大木さんだけHRテックのSaaS経験がないっていうところだと思うんですけど、 外から見てHRテック独特だなとか、こういう傾向ありそうだなみたいなのから聞いていきたいなと思うんですけど、どうしたの? そうですね、やっぱりプロダクトの導入がすぐアウトカムにつながらないようなイメージがあって、 採用成功とか人の定着、エンゲージメント向上とかってすごく中小度が高いアウトカムだなと思っていて、 それとプロダクト活用をどう紐づけていくのか、距離が結構遠いイメージがあるんですよね。 なのでそれをCSの皆さんが普段どうやってやってるのかっていうのは結構未知な領域です。 ですよね、HRテックって言っても結構領域広いと思ってて、採用、育成定着みたいな領域、 言い換えになれば採用系、あとはローム系、あとは垂れ真似系みたいな形に分けられると思うんですけど、 それぞれによって多分違いがあるなと思ってて、多分守備範囲がお二人とも違うなと思っていて、 タキタくんから聞いていきたいなと思うんですけど、 タキタくんが担当しているプロダクトって人事ロームって呼ばれるような守備範囲であってます? そうですね、僕はローム系やらせていただいているので、 ロームって言っても入社から始まって退職から終わりだったらあると思うんですけども、 その中で発生するイベントっていうのは入社の書類をどうやって集めていこうと、 その入社した後に勤怠とかですと思うんですけども、 ロームの担当の方はその後社会保険の手続きをやったりとか、 勤怠が終わったら給与計算をやったりとか、振込もそうですし、 それこそ給与に関わる情報でいくと、例えば結婚しましたとか、住所変更しましたとか、 その変更の届出をロームに出して、その情報をロームが管理して、 その情報が何がつながるかというと、給与もちろんそうなんですけど、年末調整につながる。 本当にいろんなものがロームにギュッと詰まっている。 ロームっていう言葉だけで少ないなって思うんですけど、実は幅広いみたいな、奥深いみたいなところが、 すごく面白いポイントでもあり、難しいところでもあるのかなと思います。 でもあれですよね、今の話を聞いていてもちょっと難しい漢字が並んでいると。 でもこれって多分、法律とか制度、そもそも国に出さなければならないみたいなところはあると思うので、 やっぱり各業務に法律みたいなのが絡んでくるっていうのは、 一体その人事ローム、領域だと独特な部分なんですかね。 そうですね、そのあたりは本当にその通りだなと思っていて、 法律だけではなくて、そこに関連してやっぱり会社の制度も変えないといけないっていうところもありますし、 制度が変わるとやっぱり求められる人材も変わってくれば、 会社のカルチャー自体も変わってくるみたいなところがあって、 単純に一システム変えるだけでどこまで入るのか、 システム変えるだけでそもそもそれっていいのみたいなところもやっぱり難しさとしてもあるかなと思います。 じゃあある意味完全自由というよりも、踏み越えてはいけないガードレールがありつつ、 企業ごとの汎用性をどうチューニングしていくかみたいなところがある意味、 人事論文の領域だと難しくなってくるみたいなイメージですかね。 そうですね。 ありがとうございます。めちゃくちゃ面白いですね。 一方で綾部さんはタレマネとか入社後の部分だと思うんですけど、 タレマネはまじで領域広いなと思うんですよね。 タレマネってどうですか? タレマネはいっぱいあるんですけど、 大きく、すごく、抽象度を上げて言うなら2つあって、難しさみたいなところとか他との違い。 1個は何かっていうと、やっぱりもともとお客さん側でやっていた目標設定とか評価みたいな業務ですよね。 ここがあんまり機能してなかったりすると、そもそもプロダクト導入したとて、 データ入れてもらえないみたいなことになって、 データ入れてもらえないから別に人事の業務が効率化されるってわけでもなく、 かつデータ活用にもつながらなかったりするので、 お客さんのアウトカムにも出てこないみたいなことで、結構なりがちかなと思うので、 そもそもやっぱり目標設定とか評価、実際の業務をちゃんとワークさせることが結構求められるので、 ここが1つ難しさになってくるのかなっていうのはすごい思ってますね。 難しそう。 そうそう。そこが難しいところと、2つ目は結構沸さんがおっしゃっていただいた通り、 プロダクトを導入したアウトカムを消滅するのがちょっと難しいというところです。 使われているっていうことと、あとやっぱり定着率が上がるとか、 やっぱりそういうところに期待されて導入される企業様とかは多いので、 このデータを使って、例えば退職する理由とかを炙り出して、 それを改善させていきたいみたいな期待があったときに、 果たしてそれが本当にプロダクトでできているのか、できたから退職率が下がったのかみたいな、 証明が難しいというところが結構現れるかなと思います。 確かにな。だから結局システムだけ入れたからといってうまくいくというよりも、 そもそもそれに何を乗せるのっていう前提のスタートラインが、制度とか理念とか、 しっかりしていないと機能を入れてもうまくいかないということですね。 そうなんですよね。巻き込む人が多いので、やっぱり随分そうになってくるので。 確かに。 各レイヤーによって考えていることが違うので、難しいかったりしますね。 人事の人だけ巻き込んでりゃよくいいわけじゃなくて、 やっぱり評価の必要な情報を入力してもらうためには、 マネージャーの人たちの協力とかも必要で、 その人たちの行動変容とかも必要なケースもあるので、 そういう意味ではすごく奥深い領域である難しさではある。 難しさがある領域かなと思います。 確かにな。これちょっと後で聞ければなと思うんですけど、 ぶっちゃけやろうと思ったらもう人事コンサルみたいな領域まで入ってきますね。 めちゃめちゃその通り。 事業者として外から関わるのは本当に難しそうですよね。 難しいですね。 結構、どうなんだろう。今のHRテックの企業のシリアスの方は違うかもしれないですけど、 結構、やっぱり人によって支援が俗人化してしまってるっていうのはある。 ある人は評価制度の構築までやっちゃってました。 アドバイスまでやってたけど、 とある人はプロダクトのオンボーティングまでやったりするので、 すごくそこら辺は俗人化してたなっていう印象はありますね。 確かにそうですよね。僕は採用系のCSみたいなのもやったんですけど、 採用も比較的近くて、 そもそも前提、どういう理念に基づいてどういう人を取るのか、 それは新卒であるべきか、中途であるべきか、 それはどういうレベル感でどこから何人取るのかみたいな、 ちゃんと前提の戦略がうまくいってないと。 走り出したとしても進捗通りにちゃんと募集が来てるのか、 エントルが来てるのかっていう、 アウトカムを、最終入社のアウトカムを出すための支援をしていかなきゃいけないので、 これも伴奏型というかコンサル型になっていきやすいよなっていうのもありますよね。 ありがとうございます。 今のお話聞いてても、僕結構SaaSのCSの時は業務改善型と成果創出型みたいな2パターンに分けて話すことがあるんですけど、 業務改善型はERPみたいなところの、ある意味導入するのめっちゃ難しいですけど、 全社導入だし、ただ導入し終わったら行って価値提供ができるようなプロダクト。 一方で成果創出型っていうのはCRMとかSFAみたいな形で、 キッティングした後にどう使うかによってちゃんとお客さんにROIが合うようなことを提供していく。 この2つを分けて話すんですけど、 HRっていう領域一括にしても多分採用とか垂れ真似は成果創出型に近いし、 人事労務の領域はどちらかというと業務改善型に近いしっていう、 一括にしても全然性質が違う領域が混ざっているところはある意味難しいポイントなのかなと思うし、 あとやっぱり僕もいっぺんと経験してみて、 これを横串で全体像を見ながら設計できるのって結構難易度高いよな、 経営者の視点を持って人っていう軸でどうやって経営をしていくかみたいなところも持たなきゃいけないんで、 そこまでいくとさらにHRのマルチプロダクトって、 マジ難易度高い。 それだけで難しいのにプロダクトにも就職していかないといけない。 メーカーとしてのスキルも必要になりますもんね。 そうっすよね。 これだけでいけたいですね。 じゃあ次に行きますか。 2つ目は業務制度組織の三重構造みたいなところで、 これは僕が最後にお伝えした業務改善型も含めてだと思うんですけど、 そもそも業務フローみたいなところを、 通常のサーチだったら棚下ろしして、それをどうやってDXするか乗せ替えるかだと思うんですけど、 そもそも制度設計とか、場合によっては社内政治まで動かさなきゃいけないみたいなところとかもあるなと思っていて、 この点をちょっと深掘っていきたいなと思ってますというところです。 あやまさんから聞いていきたいなと思うんですけど、 前回お話あったかというところだと思うんですけど、 評価みたいなところって割とブラックボックスになったりとか、 そういう部分が性質としてあったりして、それを紐解いていくところが領域的にあったみたいなところだと思うんですけど、 そういう点で具体的にどんなことが起きていくと思いますか。 そうですね。 やっぱりブラックボックスになった、目標設定とか評価をしていく中でですね、 基柱の細かいワンワンとか進捗確認とか、成果を出すための支援みたいなことをやれている会社とはそうではない。 別にそれがマネージャーによってはやってたりとか、マネージャーによってはやってないみたいな会社だったりすると、 やっぱりタレマネシステムを導入してもですね、評価のネガティブギャップが起きる。 いわゆる期末に対して、そもそもこの目標ってもうそもそも取り組んでないものですよね。 その評価業務自体が形外化してしまって、評価がすごく従業員にとってネガティブなことになってしまうってことは結構あるかなって。 なのでここをちゃんとオペレーションとしてワンワンを定期的にやりましょうと言って、 それワンワンを進捗の場とかではなくて、ちゃんと成果を出すために必要な会話ですとか、 あとはそこの問題点を解消していく場にしましょうよと、ちゃんとオペレーションに落とし込んで、 マネージャーの人たちに動いていただく必要があるかなと思います。 切り分けるといろいろありそうですね。そもそもちゃんとした運用が回ってるか回ってないかとか。 あとなんか組織規模とか企業の成熟度によっても変わってきそうですね。 スタートアップとかだったら一旦立てたものがもはや企業の救世主みたいな。 そうですね。1ヶ月くらいで変わるとかあるもんね。 2、3社前とかだとOKRだったんですけど、もはや3ヶ月ごとにOKR変わるから追って走ってるなんて果たして意味あるんだっけ。 逆にメンバーの皆さんがそもそもこれどうせ次のクローターで変わるから追う意味あるんだっけ。 若干モチベーション下がってきたとかスタートアップとかあるんですよね。 OKRの文脈とかでいくと、やっぱりOKRが評価とどうひも付いてるのかっていうところが結構重要だったりして。 これがひも付いてると難しくなるところはOKRの目標がめちゃくちゃ低い水準に立てられてしまう。 達成でOKRってそもそも外編としてはストレッチした目標立てようみたいな概念なんですけど、評価と密接にひも付いちゃったりするとそれが密接がすごい下がるみたいなところがあるので、 ここの水準を合わせにいくのが結構大事だったりする。 それをやっぱり教えてあげれるかどうかみたいなことも結構導入心に置いた重要だったりします。 っていうのが結構企業ごとにあったりするので課題が。 あそこに切り込めるかみたいなところもシリーズの重要なアクションですね。 特にアウトカムを意識したら。 MBOってなんだっけ? OKRってなんだっけ? スタートアップぐらいですけどね、OKRやってるとか。 新規事業とか。 いや面白いっすね。 一番コトロ臭いというか一番難しいところに突っ込んでいかないと。 突っ込んでいかないとやっぱりタイマネシステム導入しても 人事の人だけの業務が効率化されただけで止まるので。 そうするとやっぱりリプレイスされる可能性っていうのが結構出てくるんですよね。 現場からの反発とかもあいてですね。 なので常に意識をアウトカムに向けた方が事業としてもいいのは私個人の所感ですね。 なるほどな。 ロームも似たような現象はあるんですけども、 多分タレマネに比べて正解に近いようなものってロームの方がある。 やっぱり近代だったらこの集計にならないっていう。 休憩室だったらこの集計にならない。 ワークルだったら普通にこういう会社のルールに沿ってあげてねっていう。 なので実際に使うエンドユーザーの教育ってそんなにかからない。 もちろんかかる部分もあるんですけども、 今のタレマネの話だとワンオンワンがちゃんとできないといけないっていう。 確かに。 それを教えるのめっちゃむずくね。 近代だったらこのボタン押してね、ここから申請出してねって終わるものが、 ワンオンワンってそもそもこういうもので、 会社の文化と合わせてこういうことを見ていかなきゃいけなくてみたいな。 そうなんですよ。 そこがめっちゃむずくて。 ただその管理職の方のバックグラウンドとかで、 ワンオンワンに対する考え方全然違う。 詰める場でしょ、人もいれば。 ちゃんと成長支援するような。 成長支援というか問題払拭の場とか、 相手のキャリアについて考える場にする方もいたりはして。 そこはね、すごいおっしゃる通り、 その価値観にぶつかるのでめっちゃむずかったことですね。 確かに。 逆にもうある程度はマネジメント経験とかがあったりとか、 CHRとか経験がある人じゃないと、 この規模のこのパターンはこういう制度で、 こういう感じで組織作っていった方がいいねっていう肌感がない。 完全にCSするの難しそう。 そうなんですよね。 なので今直近で結構多いのは、 CSとそういうコンサルエアルチームを分けてるケースですね。 やっぱり専門性が明らかに求められるので。 なのでそういう人たちはおっしゃる通りCHRをやってたとか、 HRテックをやってたとか、 研修会社でやってたとか、 そういう方々がプロフェッショナルサービスとしてサービス提供してるのが、 最近ではすごいHRテックの垂れ間ない領域で多い印象ですね。 傾向とかってあるんですよ。 ワンオンワンって会社としての文化として、 制度としてワンオンワンやって、 こういう会社は成功するとかってあると思うんですけど、 さらに思っていると、 例えば営業だったらCSだったら、 バックオフィスだったら、 サイエンスだったら、いろいろあるじゃないですか。 ここのこういう職種のところは成功しやすい、 ここはちょっと形外化しやすいみたいな特徴とかあったりするんですか。 職種ごとでちょっと分析したことはないんですけど、 比較的、 エンジニア組織とかは、 やっぱりアジャイル開発っていう考え方があるのか、 比較的ワンオンワンとかも、 やるよねっていう文化があるので、 とか細かい目標の変更とかもあるよねっていう文化の中では、 結構育っているでしょう。 育てるというか業務をされている印象があるので、 比較的ワンオンワンをやること自体に対する抵抗感はなく、 やってくれる印象はありますし、 あとすごくピープルマネジメントにも興味関心を持っている方も、 中にはいらっしゃったりするので、 得意不得意が結構分かれるんですけど、 なので、比較的うまく進みやすいな、 ワンオン定着やってくれるなっていう印象ではありますね。 ただやっぱり、やってくれないわけではないですけど、 ちょっと営業っていう触手とかになってくると、 すごくやり方に対する価値観が違うなっていう印象はありますね。 本当さっき言った通り、 進捗確認だけの場にする人もいれば、 ちゃんとキャリアに対して、 この業務は、みたいな動機づけをちゃんとやる人もいれば、 そこがめちゃくちゃパッキリ分かれてるなっていう印象はありますね。 ワンオンっていうキーワードだけ聞くと、 ワンオンをやるっていう手段が目的かしらから、 そもそも何のためにやるかっていうのをインストールすることは重要そうですね。 これがいいかどうか分からないですけど、 僕いつも喫煙者なんで、 僕はタバコ吸うと普通に喫煙所行って、 家族雑談チックに話したほうが相互理解が深まってる。 もちろん業務の話とかはしないですけど、 どちらかというと、 最近どう?みたいな。 いやー、とかは逆にそういう場でやったほうがよかったりとか、 それが一つじゃないと思うんですけど、 目的は何なのかとかを意識して手段を変えていくっていうのはある意味必要なのかもしれないですね。 やっぱり過去のマネージャーの方の成功体験に引っ張られるところが結構多い領域なので、 ここは非常に難しい、本当に専門性が必要な領域だと思いますね。 自分がこう育ってきたから相手にもこうする、 みたいな持論ができやすい領域なので、 なのでこっちのやり方に対する抵抗感とかも提案したとき、 提案とか研修したときにやっぱりあったりするので、 非常に専門性が深い、組織開発の領域は専門性が深いかなと思いますね。 確かにね。やばいこれ、みんなマネジメントの興味がありすぎて、 やりすぎちゃう。 そうですね。 ありがとうございます。 ちなみにさっき若干触れたと思うんですけど、 この論の領域みたいなところだと、 制度との兼ね合いとか、 いわば一定勤怠の方法とかも集計の方法とかもある意味フレックスとか、 いろいろ決まってたらそのルールの中に合わせて設定していけばっていう話だと思うんですけど、 そもそも働き方、生産性が高い働き方ってなったときに、 もはやフレックスがいいのかとか、 いろいろ固定時間性がいいのかって前提の抽象から入ると、 またそれはそれで若干コーサルチェックになっていくとかもあると思うんですけど、 抽象度が高いところから具体の既にある勤怠のルールとかに合わせていくみたいな、 この抽象と具体のバランスってどんな感じで進めていくんですか? そうですね。 大体は初手でいくと既にある今のルールをどうシステム落とし込むとか、 システムリプレイスが多いぐらいではあるので、 今までのシステムをやってきたことをまずどう進むっていうところがまず第一歩にはなりますと。 その中で結構システムのリプレイスあるあると思うんですけど、 そもそも精度を変えるってなったときに、なかなか何かじゃないと変えにくい。 その理由付けに結構されやすいんですよ。 なので今までフレックスしたいなとなったときに、 そもそも今のシステムができたとしても何か理由がないとやりづらいとか、 ゆっくりできなくなることも同じ。 そういったときにシステムをリプレイしてやったりはするんですけども、 抽象と具体の域みたいなところだとあんまりベンダーとしては深くは突っ込まないことは多いです。 やっぱり結構その働き方って会社の文化にすごい影響があるので、 こうやった方がいいじゃんっていうような目先のミスとかっていうのもあったりして、 こうやった方が楽になるようはあるんですけども、 なかなか文化をガラッと変えるのは難しいのであんまり踏み込まない。 だからこういう方法がありますよっていうのを選択肢として与えてあげた上で、 何かタイミングで変えてもらったりしたらそのときに うちはすぐできますっていう選択肢を与えてあげるぐらいが一番距離感的にもちょうどいいっていう形になりますね。 他社にリプレイされないようにするみたいなところの戦略は何か持っているんですか? そうですね。やっぱり一番機能的なところではあるんですけども、 それこそ勤怠って労務管理っていう形において、 じゃあこの集計が取れたらいいかっていうだけで、 その後の給与計算がつながったりすると思うんですけども、 給与計算もそうですし、そもそもサブロ協定で違反をしてしまったらお金を払わないという。 こうしたのは単純な勤怠自体の機能ではあるんですけど、 給与計算までつなぐって考えると、 じゃあどのように給与計算と一緒にデータつないでやっていくかとかっていう。 単体で見るとその使っているシステムデータをどれだけ幅として広げていって、 インフラ化させて抜けさせないようにするかっていうところが結構戦略して考えるところでありますね。 やっぱり今のHRのロームサースの界隈だったら、 自社でマルチプロダクトしてやっていて、 単体でやられているところなんてほとんどないっていうような世界になっているので、 本当に自社で扱っているシステムの経済圏というか、 どこまで広げられるかみたいな、単体で勝負するんじゃなくて複合で勝負しにいくっていう。 これでチャーンをできるだけするっていう。 それを5個6つ入っている状態でプレイするってなると、 かなりのリプレイスコストがかかってしまうので、 いかに早く広げていくかっていうので定着まで持っていかせるっていうのが戦略の一つです。 なるほど。 だからさっきのお話じゃないですけど、ある意味具体から入った方が最初はオンボーディングしやすいけど、 逆に具体から入りすぎると今度広がらないってことは、 僕も人事ロームのマルチプロダクトやっているときに、 いかに最初に経営目線で長い時間軸でマルチプロダクトの概念を真と理解してもらって、 そこから約算をして、じゃあ3年後はタレマネまで行きましょう。 3年後に行くために、初年度でまず近代とかロームとかの情報を蓄積しましょう。 そうするとローム担当の人のコースが開くんで、その人たちを次は制度設計に回しましょうみたいな感じで。 最初は抽象の絵を描いた上で、オンボーディングがここらへんみたいなところがある程度きったりするコントロールをしないと、 した方が楽なのかなっていうのは思ったんですけど、その点とかってどう思います? 楽はめちゃくちゃ楽だと思っています。 難しいところが法律は絡んでいけるというのがすごく大事で、 むやみやたりに法律を取ってしまうと、もし万が一間違ってしまったときのリスク。 ここが一番気をつけないといけないポイントなんですよね。 なので抽象的な話でそういうのを最初にデザインしてあげるっていうのは大事なんですけど、 やっぱりその抽象を達成するには具体の話が必要で、 具体の中にそういうことが絡んでくるのがあるとリスクになってしまうので、 話したときにはやっぱり自分たちのベンダーで、もしベンダーの中に抱えているものがあるのであれば、 そういったサポートを使ってあげるのも一つですし、 それがないのであれば外部のベンダーさんと協業して、 BPOの先でそういった専門知識とか資格を持っている人たちをアサインして一緒に進めていくっていうのが結構手だらしがあります。 結構風呂敷広げるときにドキドキするっていう。 みんな分かってるんですよね。広げたほうがいいのは分かると思うんですけど、 本当にこれでいいの?みたいな。 この制度設計して本当に大丈夫?みたいな。 給与とかでも1円、2円の差、何か制度変えて1円、2円の差が出るとなったとしても、 従業員数が多ければ多いほど単月かけるとインパクトがすごい出る。 本当にこれバチと変えていいの?みたいな。 確かに。 すごいありますね。 そうですもんね。制度変えて給与が1円でも下がったら、 ちゃんとそういう順番に乗っ取った対応しなきゃいけないとかいろいろある。 なるほどな。 マルチプロダクトで一気に給与計算からローミの機能まで全部導入されたときとかって、 すごいオンボーディングが時間かかりそう、大変そうだなって印象があったりするんですけど、 それも一人のCSの人が全部プロダクトのオンボーディングとかやられてるんですか? そうですね。うちの会社でいくとそうです。 会社さんによっては領域ごとに分けられているところではあるんですけども、 うちの会社でいくとあえてそれをやっていて、 分かれれば、例えば入社、CSのメンバーとして入社したときに知識のキャッチアップとかっていうのは、 その領域だけでいいので早いっていうのはあるんですけども、 会社としてはマルチプロダクトでの価値っていうのを考えるときに、 やっぱり息つかんでやったほうがいいのねっていうところですし、 お客さんからしてもこの人に聞いてもらえれば、ここの範囲全部分かるのほうがストレスはかかりづらい。 だけでもいいってなったときに、難しいんですけどこっちのほうがいいっていうのは結構こだわってやってますね。 確かに。 そうするとやっぱり育成が結構重要になってくると思うんですけど、 一気通貫でやるために育成の中で工夫されてることってあるんですか? そうですね。基本的には業務の知識と法律的な知識と、 やっぱりうちのプロダクトの知識ってこの3つをどう抑えていくかをベースにするのが全体的にやっていることで、 その後に発生するのってお客さん個別でどういう違いがあるのか、 その得たものってどういう実感値を得るためにお客さんと接触していかないといけないので、 その後はOJTと組み合わせてやるっていうのをやってます。 いろいろ立ち上げイネーブルメントどうするかっていうのはずっとくるくる変わってくるものがあるんですけど、 最近のうちの傾向でいくと、もう3ヶ月でどれだけ戦略化させるかっていうのはもうプラン引いてガツでやってる。 3ヶ月でやってるんですね。すごい。なるほど。 確かに。 なるほど。確かに若干今の話にも出てこのまま3番目のテーマにいっちゃいますけど、 エンタープライズとかSMBとか、規模感によってもそうですし、 お客さんの知識レベル、それもロームの知識量であったりとか、 あとはITに対してどれだけ明るいかみたいなところによっても結構変わってくる。 そこの影響が受けやすい領域なのかなってこのHRテックには思っていて、 ちょっとその話をしていければなと思うんですけど、 HRのフロントの人事担当の方のバックグラウンドによってのバラツキみたいなところを感じるところってあったりとかします? これじゃあ滝田君に。 はい。すごく言いにくいんですけど。 そうですね。やっぱりシステムを扱うっていう形になるので、 ベースそのパソコンとかこういったSaaSのシステムを入れ替えた経験があるかないかとかっていうものと、 業務をどれだけ付加しているかによっては本当に変わってくるものになります。 サービスシステムでいくと本当にいろんな会社さんがいるので、 それぞれのシステムの癖みたいなのはもちろんあるんですけれども、 そもそもこの自社の制度を知っていないというものもそうですし、 法律現金帯の制度っていうものを知っておかないとシステムを落としたときに一番難しいところですと、 お客さんによっては法律違反みたいな感じの制度をやってしまっているという時があるんですよね。 それをそのままシステムに落としてやるのか、 いやちょっとねみたいな感じで言って変えていくのかっていうところによって変わってくるので、 そもそもその間違ったことちょっと私やってるんだよねって理解があった上でやるのかっていうところ、 この辺りも変わってくる。 もちろんシステムの不慣れな人たちだったらそもそもここをこうやってボタンを押すんですよとかっていうのときからスタートしますし、 場合によってはお客さんの隣についてパソコン一緒に触れながらこうやってやるんですよみたいな、 自社システムのオンボーディングしてるのにパソコン教室してるみたいなときも場合によってはあるんですよね。 しかもちょっと話してるかもしれないですけど、僕はもともとSMBの領域がメインだったので、 そうなってくると機能として実現されてるのってそもそも法令遵守の構造だから、 そもそもこれ通りに使ってたらいいけれども、 じゃあ中小企業SMBの現場って100%きれいにルールが遵守されてるかでいくとそうではないから、 許容性をシステムでどう担保して、その許容できない範囲をどうやってCS側でちゃんとコントロールして載せてあげるかっていうのは、 結構支援入ってて絶妙なバランス感覚が必要で、 でもこちらとしては社老子ではないから突っ込みきれないっていうので、 この辺ちょっと本社老子の先生に聞いてくださいみたいな、バランスはちょっと難しいところがあったよなっていうのは。 そうですね、この法令の最低ラインみたいなところもそうなんですけれども、 近海からローム管理になると厄介なところで、それを下回らなければ後は何でもいいんですよ。 ホワイトであればあるほど何でもいい。 大企業さんであればあるほど、そういうところは従業員の働きさと満足を高めてよくしてるんですけれども、 逆にシステムが追いつかないみたいなこともあったりするみたいな。 ミッドエンタープライズだとそっち側の… 違いますね。 それは面白いですね。 だから個別開発する企業とか出てくるんだろうなっていうのはあるんだろうな。 自社オリジナルの休暇制度とか。 ユニークな休暇制度ってなんだろうこれ。 なるほど、ありがとうございます。 この点でタレントマネジメントの観点とかだと、 お客様の知識レベルとかによっての変化みたいなのってあります? やっぱりそこはすごく影響度が大きい部分であり、 ベンダー側でコントロールもできしづらい部分はあるかなと思っていて。 例えばプロジェクトマネジメントをやってきた方とかが、 フロントですね、カウンターパートでいらっしゃったときはプロジェクトが進みやすい、 プロダクトの導入が進みやすかったりとか、 直接にマネージャーの人とかを巻き込んで、 ちゃんと期日通りに動かしてくれることが比較的しやすかったりするんですけど、 兼務してたりとか、バックグラウンドとしてそういう、 総務やってましたとか、さまざまな方が兼務されてた場合がいらっしゃるので、 そうではない場合はなかなか進捗が進まなかったりとか、 そこによって目標設定とか、1-on-1とか評価みたいなところの決められた通り、 期日通りやってくれるかがバンバラになってしまうというケースは結構あった印象ではあります。 そもそもHR担当、人事担当の方以外にも評価をしてもらう現場サイズのレベル感とか、 そうですね。 しかも雇用形態によっても変わりそうですよね。 例えば正社員の方の評価であれば割とグッと進むかもしれないですけど、 例えばアルバイトの方までとかまで行くと、 割となかなかそこまで時間がかけられないとか。 確かにそうですね。ただそこは評価対象外にされているケースが多かったですね。 評価対象は正社員だけとかになっているケースが結構多かった印象ですね。 ちょっと会社によっては違うと思うんですけど。 業態業種とかによっては。 実質的なタレマネシステムの導入を推進する方と担当する方ってイコールなことが多いんですか。 それとも例えば上層部の方が実質的推進して、後は任せたって感じで降りてくるみたいな担当者の方だと、 モチベーションというか結構熱意がないと進められない領域かなと思ったんですけど。 でもそうですね。おっしゃる通りで。 結構鍵になっているのは推進する方と運用担当で分かれているケースが多いんですけど、 分かれている上で推進力を保つためのポイントは、 例えば運用別でしてもらう方がいたときでも、その人のメインのミッションに、 例えばワークエンゲージメントの向上とか、そういった何か組織を良くするための目標が入っているかどうか。 やっぱり組織って戦略に従うので、それで入っていなかったりすると、 注力業務じゃないよねみたいな形になって優先度が下がってしまったりするので、 これは結構僕が過去、進む企業とそうじゃない企業をすごい分析したときに、 やっぱりそこが目標として入っているかどうかが結構大きく変わってくるなと思っていて、 結構SaaS企業のベンダーの方って運用担当者は誰ですかとか、 推進者は誰ですかみたいなのが聞いてくるんですけど、 結構実は重要だったのはその運用担当の人の目標とかだったりするんですね。 そこに返ってくるんですね。 そうそう。だから結構分析して分かったときに経営層の人とかに言ってましたね。 運用担当者を置く人には注力業務はワークエビジョン向上とか、 そういう人を置いた方が上手く回りますみたいな話はして、 そうするとやっぱり進みやすく、ぐっと進むので。 そこ大事なポイントかもしれないですね。 そこ結構重要ですね。 見落としがちというか、お互いに多分、センダル側もお客さん側も。 言いづらい部分では難しいですけど、結構形式的に担当者になるみたいなことではなくて、 その人の意欲を持ってくれる人をアサインするっていうのが結構重要ですね。 そうですよね。 でも確かにそうかもしれないです。 いろんなCSやってても、今思うとお客さんに聞いてるな、 何々さんって何で評価されますって。 どうしたら何々さんを昇格させてあげられますかね。 ありますよね。 特にバックオフィスアースであればあるほど、 営業とかだと表彰があったりしますけど、 バックオフィスの方、業務性質上ミスったら怒られる。 確かにそうっすね。 ちゃんと業務やってても普通みたいな感じなんで、 ある意味、どうやってこの人を引き上げるというか、 評価対象にしてあげるかみたいなところは、 結構意図的にやってたところはあるかなとは思いますね。 OKです。 ちなみにこれは想定の倍以上の尺があって。 まあ、想定の範囲内ですね。 想定の範囲内ですね。 いやでも、もう一周やっても全然まだ話したくない。 でもね、このテーマとかぜひ聞きたいというところは、 コメントとかいただければ回答しますし、 実はラップアップイベントみたいなのも企画してるんで、 そういうものを最終的に気になることはぜひ回答していければなと思いますので。 はい。なんで一旦今日はこの辺でというところで、 ちょっとお話を閉じていければなと思います。 改めてありがとうございましたというところで、 今回ですね、大きく三つのお話をさせていただきましたというところです。 一個はまとめると、 ドメインの知識であったりだとか、 法律の理解というかどの範囲までやるのかみたいなところの重要性。 あとは、制度が未整備なお客様ってどうやって対応してくればいいんだっけ。 あとはお客様のレベル感とか、 システムに対しての明るさによっても結構変わってくる。 こんな要素が絡み合ってくるのが、 HR SaaSの難しさみたいなところを、 今日お話しさせていただいたのかなと思いますというところですね。 次回はですね、HR SaaS、 個社対応はどこまでやるべきかみたいなところのテーマで、 お送りできればなと思いますので、 引き続きよろしくお願いしますというところで、 改めて、スタートアップCSベースプレゼント、 ゼロから始めるCSラジオというところのHRテック編、 以上となりますので、皆さんフォローの上で引き続きお楽しみください。 ありがとうございました。 ありがとうございました。