こんにちは！ SmartHR プロダクトエンジニアの @kiita です。
プロダクト開発に携わる方ならおそらく誰もが大事にしている「顧客理解」という言葉。
大事だということはわかっていても「ユーザーを理解するってどういうこと？」「理解するためにはどうすればいいの？」と聞かれたら、答えに詰まる方も多いのではないでしょうか。
正直なところ、以前の私にはまったく分かりませんでした。
しかし今では、そのような問いに（少しですが）自信を持って答えられるようになったと感じています。
これは、私が所属する「配置シミュレーション機能」開発チームでの素敵な取り組みを通じて起こった変化です。
すべては「チームのなりたい姿」を話し合うことから始まった
まずは、その取り組みを行うに至ったきっかけをお話します。
そもそも今回ご紹介する一連の取り組みは、チームで「どんなチームになりたい？」を考えたことから始まりました。
チームが議論した末出した答えはズバリ、「プロダクトの方向性を見極められるようになる」です。
（誰かに言われた通りに開発するのではなく、自ら最適解を模索・判断できるようになりたいよね、というニュアンスが込められています。）
チームのなりたい姿が決まると、自然と「Q. ではプロダクトの方向性を見極められるようになるには？」→「A. ユーザー・顧客理解が必要だよね」→「Q. では顧客をより理解するには？」と問いが立てられていきます。これが、今回ご紹介する具体的な取り組みに繋がりました。
ここから、顧客を理解し、プロダクトの方向性を見極めるために行なった 3 つの取り組みをご紹介していきます！
取り組み 1.「SmartHR を使った人員配置検討業務のロールプレイング会」
1 つ目にご紹介するのは「SmartHR を使った人員配置のロールプレイング会」です。
こちらは、SmartHR の配置シミュレーション機能を利用した人員配置検討業務を、ロールプレイング形式で体験してみる取り組みです。
（ここで言う人員配置とは、様々な情報を考慮しながら、従業員をどの組織・ポジションに配置するかを決める業務のこと）
事前準備として仮想のユーザー環境を用意し、配置検討業務に関わる役割（組織人事や部門付人事、部門長など）にメンバーがなりきって業務を体験しました。
開発者が顧客目線でプロダクトを触るのはよくある取り組みですが、「チームの担当領域にとらわれず、顧客が配置検討業務の中でやることをなるべく全部体験してみた」点がこの会のポイントです。
この取り組みを通して得られたことは、
- 配置検討業務において SmartHR がどのように使われるのか、チームの解像度を上げることができた
- 会の準備過程で、今まで触ったことのなかった SmartHR の様々な機能に触れ、プロダクト全体の課題を把握することができた
の 2 つです。特に 2 つ目については、普段の開発業務では気付けない「配置シミュレーション機能を使えるようになるまでの課題」を身をもって体感でき、他チームとの連携の重要性を改めて認識することができました。
取り組み 2.「2024 年下期の開発が終わった時の未来予想」
続いてご紹介するのは「2024 年下期の開発が終わった時の未来予想」です。
こちらは、2024 年下半期で開発予定の機能に対し「誰の、どのようなペインを解消するのか？」を言語化することで「下期が終わった時、ユーザーの業務はどのように変わるのか？」の認識合わせを行った取り組みです。
事前準備として、開発予定の機能ごとに「関係する業務スコープは？」「その業務の目的は？」「どんなペインを抱えている？」といった質問項目を書いた下画像のようなカード（「機能カード」と呼ぶことにします）を作りました。
会の冒頭に個人ワーク時間を設け、メンバーは好きな機能を一つ選び、カードに書かれた質問に対する回答を記入します。
各機能に対する解像度はメンバーごとにまちまちなので、その後各機能カードをメンバー全員で確認し、ブラッシュアップしていきました。
この取り組みで良かったことは、
- 何を開発すればいいか（What）にとどまらず、その結果顧客の何を変えたいのか（Why）の解像度を上げることができた
- 一人一人が質問に答える形式をとったことで「わかったつもり」に気づきやすくなり、ズレ埋めができた
の 2 つです。
期初にロードマップを共有されても、その場ではいまいち理解が深まらないことも多かったのですが、今期はこの取り組みのおかげで解像度が上がったことを実感できています。ぜひ来期以降もやっていきたい、素晴らしい取り組みでした。
取り組み 3.「実際の業務フローに近いシナリオに基づいたスプリントレビュー」
最後にご紹介するのは、「実際の業務フローに近いシナリオに基づいたスプリントレビュー」です。
SmartHR の多くの開発チームではスクラム開発を取り入れており、必要に応じてスプリントレビューを実施しています。
今回の取り組みでは、普段のスプリントレビューと以下の 2 点を変えて実施しました。
- レビュー対象領域を変える
- 普段のスプリントレビューでは、スプリントごとの成果物（インクリメント）に対してレビューをもらう。今回は特定スプリントのインクリメントやチームの担当領域（「配置シミュレーション機能」）にとらわれずに、一連の業務フローを再現することを重視してプロダクトを触ってもらい、レビューをもらった
- 招待者を変える
- 普段は実際の顧客との接点が多いカスタマーサポートチームやカスタマーサクセスチームにレビューをもらう。今回は実際に SmartHR の組織変更に携わった人事を招待してレビューをもらった。また、レビュー対象範囲が広いため、関係する他開発チームのメンバーも合わせて招待した（SmartHR で行なった組織体制変更については、事業を支える、SmartHR のあたらしい組織体制についてをご覧ください）
この取り組みで良かったのは、
- SmartHR 社の配置検討時のエピソードを、見知った具体的な社員名なども交えながら話してもらえたことで、より配置検討業務の解像度を上げることができた
- 関係する他チームも一緒に招待したことで、プロダクトが抱えている課題に関してチーム間で認識を揃えることができた
の 2 つです。チームの担当領域に縛られずにレビューしてもらったり、普段と違うメンバーを招待することで、普段とまったく異なる角度のレビューを得ることができました。
最後に
ここまで、私が所属するチームが顧客理解を深め、プロダクトの方向性を見極めるために行なった 3 つの取り組みをご紹介しました。いかがでしたでしょうか。
2024 年の上半期を通してこれらの取り組みを行った結果、
- 仕様検討時にメンバーから出てくる言葉がより具体的になった
- 顧客が抱えているペインを理解したことで、各リリース段階のスコープを検討しやすくなった
- チームの担当領域だけでなく、その前後も含めた顧客の体験全体に目を向けるようになった
といった点でチームが成長できた実感があります。
今回紹介した取り組みが、開発チームにおける顧客理解のための参考になれば幸いです！
We Are Hiring!
SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！