SmartHRでプロダクトエンジニアをしている @kazukun です。これまでタレントマネジメント領域のプロダクト開発に多く携わってきました。直近ではHRアナリティクス機能やマネジメント育成計画機能の開発を担当しました。
今年の1月からは新たに組成された社内ツールユニットへ異動しました。これまでの顧客向けプロダクト開発とは異なり、CS（カスタマーサクセス）やコンサルなど社内メンバーが利用するツール群を開発するチームです。ユーザーが社内メンバーに変わったことで、「誰の何を解くのか」を改めてゼロから定義する必要がありました。
本記事では、CSメンバーと半日かけて実施したワークショップの内容を紹介します。
なぜ「社内ツール」のためにワークショップを開いたのか
社内ツールユニットのミッションのひとつは、顧客のタレントマネジメント機能の活用定着率を上げることです。
タレントマネジメント機能とは、従業員の評価・スキル・コンディションといったデータを可視化・活用するための機能群で、人事評価、従業員サーベイ、スキル管理、HRアナリティクスなど複数のプロダクトから構成されています。
これらのプロダクトは、契約しただけでは価値が出ません。顧客が自社の目的に合わせて初期設定を行い、実際に運用に乗せて初めて意味があります。その活用定着を支援しているのがCSです。CSは顧客に対して導入の進め方を提案したり、つまずきをフォローしたりしながら、機能が活用されている状態を一緒に作っていく役割を担っています。
当初、開発チームではCSの業務を支援する管理ツールの開発を想定していました。ただ、開発チームの仮説だけで進めても現場の実態とずれるリスクがあります。まずはCSの現場で何が起きているかの解像度を上げようと考えたことが、今回のきっかけでした。
目指したのは、顧客が契約してから機能を実際に使い始めるまでの間に、どこでつまずいているのかをCSの視点から明らかにすることです。
開発チームが抱いていた人事担当者像と実態とのギャップ
ワークショップの前半では、まずCSと一緒に顧客のペルソナを作るところから始めました。実際にどんな企業規模・業種の担当者が、どんな状況でSmartHRを触っているのかを具体的に描き出す作業です。ここで気づいたのが、ペルソナのずれでした。
開発チームとしては、タレントマネジメントの専任担当者がいて、ヘルプページを見ながらある程度は自走できるユーザーが多いと考えていました。しかし実態は違いました。専任の担当者はほとんどおらず、給与計算や入退社手続きといった日常業務と並行してSmartHRを触っている方が多いとのことでした。また、ヘルプページを一から読むよりも、「自社に近い他社の事例」を参考に進めたいという声が多いと聞きました。
この話を聞いて、多機能化・高機能化を追うよりも、ユーザーが迷わず使い始められる体験設計や、学習コストを下げるアプローチが重要だと気づかされました。
CSが直面している「情報の断片化」
続いて、CSメンバーへのヒアリングを行いました。普段どのように顧客へ機能を提案しているか、どんな順序で導入を進めているか、情報管理はどうしているかなど、業務の実態を掘り下げていきました。ここで浮かび上がったのが、CS側の業務における情報の断片化です。
CSが顧客の活用状況を把握するには、複数の社内システムを横断して確認する必要があります。システムが分断されているため、CSがいち早く変化に気づいてサポートに入りたくてもタイムラグが生じてしまう——開発チームとして、仕組みで解決すべき課題だと感じました。
一方で、CSの取り組みから学ぶことも多くありました。CSは開発チームが想像する以上に、特定の顧客が抱える個別の課題に踏み込み、独自の提案マニュアルとして体系化していました。CSが顧客対応のなかで磨いてきたトークや手順のノウハウに触れて、現場で積み上げられた知見の厚みに驚きました。
プロダクトごとに異なる「つまずきポイント」の整理
CS側の業務課題を踏まえたうえで、次に焦点を当てたのが、顧客の活用定着がどこで止まりやすいのかをプロダクトごとに整理することでした。これは、今回のワークショップのなかでも最も手応えのあった場面でした。
CSは顧客の活用度合いを、導入初期から活用定着までいくつかの段階に分けて捉えています。今回、その各段階をプロダクトごとの具体的なつまずきポイントとして捉え直しました。
見えてきたのは、プロダクトによって停滞するポイントがまったく違うということです。初期設定の手間がボトルネックとなり利用開始前で止まるケース、データはあるが社内の合意形成に時間がかかり活用が進まないケース、数値は出ているが次のアクションにつなげられず定着しないケースなど、原因はさまざまです。
各プロダクトがどの段階で停滞しているかが構造的にわかったことで、一律の改善ではなく、特定の段階に応じた支援や改善の方向性を考える土台ができました。
インパクト × 頻度 による課題の絞り込み
活用定着のつまずきポイントを整理する過程では、CSから多くの課題が出てきました。全部を一度に解決するのは難しいので、出てきた課題をオンラインホワイトボード上でグルーピングし、インパクトと頻度の2軸マップへ配置して優先順位をつけました。
整理の結果、優先度の高い順に以下の3つの課題が浮かび上がりました。
- 判断基準の不足
- 顧客が初期設定の優先順位を判断できず、導入が止まる
- ヒアリングの属人化
- 顧客の潜在課題を引き出す力がCSの個人スキルに依存している
- 状況把握のタイムラグ
- 活用状況がリアルタイムで見えず、適切なタイミングで介入できない
判断基準の不足とヒアリングの属人化は、顧客の導入初期に集中している課題です。現状、顧客が初期設定でつまずいた際はCSメンバー個々の対応力（ヒアリング力や提案力）によって解決できていますが、それが個人の力量に支えられている分、再現性に課題がありました。状況把握のタイムラグは、導入初期に限らず活用全体に関わる課題で、別のアプローチが必要です。
こうして課題を構造化したことで、まずはインパクトの大きい1と2を優先して検討していく方針が見えてきました。
「管理ツールの開発」から「CSのノウハウを仕組み化する」方向への転換
課題の構造化を経て、開発チームの打ち手は当初想定していた管理ツールの開発から方向が変わりました。
ワークショップを通じて見えたのは、CSが現場で培ってきたノウハウ——顧客の状況をどう捉え、どこに課題があるかを見極め、どのような順序で支援するか——といった暗黙知の価値です。この知見を個人の力量に頼ったままにするのではなく、仕組みとして再現可能な形にしていくことが、社内ツールユニットの本質的な役割だと考えるようになりました。
CSの持つ属人的なノウハウを、開発チームの力でいかに「仕組み」へ落とし込んでいけるか——これが私たちの次の挑戦です。
おわりに
今回のワークショップを通じて感じたのは、CSからの要望をそのまま形にするのではなく、一緒に課題を掘り下げながら開発チームの武器で解くことの面白さです。
なかでも一番やりがいを感じているのは、CSの頭の中にある暗黙知を聞き出して、システムに落とし込む翻訳のプロセスです。開発チームだけで仮説を立てていたら、ペルソナのずれにも、情報の断片化にも、プロダクトごとに異なる「つまずきポイント」にも気づけなかったと思います。
プロダクトの外側にある地道な運用を知ったことで、各プロダクトの課題が具体的に見えるようになり、日々のコードに対する意識も少し変わりました。
社内ツールユニットとしてはまだスタートラインに立ったばかりですが、CSとの協働で得た解像度をもとに、これからプロダクト開発を進めていきます。
We Are Hiring!
SmartHRでは、CSをはじめとする社内の多様な職種と連携しながら、プロダクトの価値を顧客に届けるためのエンジニアリングに取り組んでいます。
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
