こんにちは、SmartHR 品質保証本部 レバレッジ推進ユニットのark265とgo-sanです。
過去の記事（「組織」と「AI」の品質課題に挑む ──レバレッジ推進ユニットの現在地、未来へレバレッジをかけるためのレバレッジ推進ユニットの役割と今）では、レバレッジ推進ユニットがビジネスサイドや周辺職種へのヒアリングを進めてきた話、そして、仕組みとして確立する手前の領域を支援するという軸についてお伝えしました。
今回はその続きです。ヒアリングや仮説検証を経て、現在取り組んでいるカスタマーサポートチームとの協業についてお伝えします。まだ取り組みの真っ只中で、結果が出ている話ではありませんが、試行の中で見えてきたことを整理しながらご紹介できればと思います。
取り組みの背景と仮説
SmartHRのカスタマーサポートチーム（以下、SP）は、リリースされた機能に対するお客様の問い合わせに日々対応する中で、多くの知見を蓄積しています。「この機能は実際にはこう使われている」「ここでつまずきやすいお客様が多い」といった、開発プロセスの中だけでは拾いきれない、リアルなユーザー体験の情報です。
一方、QAエンジニア（以下、QAE）は品質視点でプロセスや仕様を評価する専門性を持っています。
SPの顧客知見とQAEの品質視点を掛け合わせることで、リリース前からより効果的にSPの知見を開発プロセスへ活かせるのではないか。そんな仮説から、この取り組みはスタートしました。
開発チームがSPメンバーに仕様の確認やフィードバックを求めることは、すでに各チームで行われています。また、SmartHRは現在全社で約1,500人を超える規模の組織で、開発チームも多数あります。チームごとのSPメンバーの距離感もさまざまです。
今回の取り組みのポイントは、その構図を逆にしていることです。開発チームがSPメンバーを巻き込むのではなく、SPメンバー自らが主導して開発プロセスに顧客視点を届けにいき、そこに、開発プロセスを知っているQAEがサポート役として入り、SPの知見がもっとも効くポイントを一緒に探しています。
そして、その関与のタイミングを「リリース前」に置いています。狙いは、リリース後の問い合わせ対応だけでなく、リリース前からSPの知見を活かすことで、問い合わせが起きにくい状態を一緒に作っていくことです。SPにとっては自分たちのKPIである問い合わせ削減に直結し、開発チームにとってはリリース前に顧客視点が入ることでプロダクト品質が作り込まれます。「SP主導」で、かつ「リリース前」から。この2つの軸で取り組みを進めています。
試行した2つのアプローチ
仮説を立てた後、パイロット対象とする領域を決めて、SPメンバーと一緒に実際に動き始めました。試みたのは主に、PRDレビューへの関与と実装前のフィードバックの2つのアプローチです。それぞれ何を試し、何がわかったかを中心にお伝えします。
1. PRDレビューへの関与
まずは実際のプロダクト要求仕様書（以下、PRD）をSPメンバーと一緒に読んでみることから始めました。機能の設計段階にSPが関与できれば、リリース前のもっとも早いタイミングで顧客視点を届けられるのではないかと考えたからです。
実際に出てきた指摘は、PRDの記述と問い合わせの実態を照合する観点が中心でした。「類似機能で課題になっている問い合わせがあるので、同じ作りで実装すると顧客体験が下がりそう」「『やること・やらないこと』の線引きから、問い合わせにつながりそうな観点で優先順位の提案ができそう」。SPメンバーからは「この領域の問い合わせは実際にかなりきている」といった、記載内容を裏付ける具体的な情報も出てきました。
一方で、「PRDの記述だけでは、実際の機能の動きがイメージしにくい。もう少し詳細を聞ければ判断できるかも…」という声もありました。SPは知見を持っています。ただ、PRDは設計意図や背景が凝縮されたドキュメントのため、非同期で読むだけでは実際のお客様体験との接点が見えにくく、SPの知見と結びつけるには情報が足りないことがありました。
また、指摘は出せるものの、観点が個人の経験に閉じたままでは、組織としてスケールしません。誰がアサインされても同じ品質で関与できる状態にするために、SPの知見を「型」として言語化する必要がありました。
レビュー観点の型化
再現性の課題を受けて、次に取り組んだのはSPならではのレビュー観点を「問いかけリスト」として整理することでした。「気になるところを指摘してください」ではなく、「どのPRDでも使える問いかけ」として型にする試みです。
整理してみると、SPが貢献できる観点はいくつかの軸に分かれることがわかりました。
- 既存機能との差別化（既存機能と何が違うのか、お客様視点で説明できるか？）
- 問い合わせ増加・副作用の予測（この機能のリリースで、別の問い合わせが増える可能性はないか？）
- リリース後のリスク予測（機能名や用語でお客様が誤解しないか？「急にできるようになる」ことで混乱が起きないか？）
- 「やらないこと」の明確さ（ファーストリリースでやらないのか、将来的にもやらないのかが明記されているか？）
- 運用回避パターンの共有（お客様が現在どう回避しているかを共有し、スコープに反映できないか？）
それぞれに「なぜSPだから見つけられるのか」の理由も添えました。
例えば、既存機能との差別化に対しては「SPメンバーは日々お客様に機能を説明しているので、『説明できない差』はお客様も理解できない」。問い合わせ増加・副作用の予測に対しては「改善したら別の問い合わせが増えた、というパターンを経験的に知っているのはSPである」、といった具合です。
こうした理由付けがあることで、指摘が「個人の気づき」ではなく「SPの専門性に基づく観点」として位置づけられます。これが型の骨格になりました。
別のPRDでの試行
問いかけリストの型ができた後、別のPRDで実際に使ってみることにしました。
まずはSPメンバーとQAEで、PRDを非同期的に読みながらコメントを入れていきました。結果、いくつかの有用な指摘が出てきました。たとえば、データの出力形式や、リリース後の既存データの扱いに関する考慮漏れといった点です。いずれも、SPメンバーが日常的なお客様対応の中で把握している情報がベースになった指摘でした。
一方で、プロダクトを横断するFeatureの場合、PRDの記述だけでは他プロダクトとの接続部分が読み取りにくく、非同期のコメントだけでは踏み込んだフィードバックが難しいこともわかりました。そこでPMを交えた同期的なレビューの場を設けたところ、非同期では出なかった論点まで議論が広がりました。PM側からは「漏れている観点のチェックとして助かった」という反応があり、他のプロダクトでも試したいという声もいただいています。
ただし、型が機能しているかどうかの分析はまだこれからです。今回は最初の1例にすぎません。問いかけリストのどの観点が効いたのか、どこが足りなかったのかを振り返り、他のPRDでも試行を重ねながら精度を高めていく段階です。
2. 実装前FBへの関与
PRDレビューと並行して、もうひとつ検討していたのが機能テスト、受け入れテスト段階での関与です。これまでに探索的テストのタイミングでSPメンバーが実際の機能を触りながらフィードバックする機会もあったので、それよりももう少し前の段階で考慮漏れを防げるのではないかと考えていました。
そんな中、PMとの相談の中で、あるチームが「実装前フィードバック会」という取り組みをすでに試験的に行っていることを知りました。プロダクトバックログリファインメント（以下、PBR）後の仕様について、プロダクトエンジニアやPM、SP、セールスなど多職種のメンバーが集まり、それぞれの立場からフィードバックする場です。
実際にその会を見学してみると、いくつかの発見がありました。スプリントレビューの段階ではすでに実装済みのため踏み込んだ議論がしにくいのに対し、この実装前のタイミングでは実装方針そのものについて議論できる余地がありました。また、SPメンバーが得意とする「この仕様だとこういう問い合わせが来そう」「お客様は実際にはこう使っている」といった情報が、まさにこの場で求められていることもわかりました。
一方で課題も見えました。対象Featureの領域とSPメンバーの普段の担当領域との重なり具合によって、引き出せる知見の深さが変わるため、適切なマッチングの仕組みや、領域を問わず使える観点の型化が必要そうでした。また、PBR済みのチケットをSPメンバーと一緒に読んでみるアプローチも試しましたが、チケット単体では前後のコンテキストが見えにくく、SPメンバーだけでは読み解くのが難しいという壁がありました。口頭でコンテキストを補いながらの同期的な場の方が、質問のやりとりを通じてSPの知見は届けやすいことがわかりました。
現在は、PRDレビューと同様に、このタイミングでSPメンバーがフィードバックできる観点の型化も目指しながら、開発チームを巻き込んだパイロットのタイミングを調整しているところです。
試行を通じた気づき
ここからは、SPメンバーと一緒に動いたからこそ見えてきた気づきを共有します。
相手の困りごとに目を向けると、引き出せる知見が広がる
開発チームの一員として、QAEを担当していたとき、普段の開発業務では接点が少ない職種のメンバーへヒアリングをする機会は多々ありました。しかし、自分たちが持っている知識が質問の上限になってしまい、相手が本来持っている専門的な知見をうまく引き出しきれなかったり、互いの強みを活かす接点を見つけにくかったことに、この取り組みを通じて気づきました。
こうした方にヒアリングに行く際に、大事だったのは、自分たちが欲しい情報をもらいにいくだけの「Taker」で終わらないことです。「日々の業務でどんな情報に触れていて、何に困っているのか」まで踏み込んで聞くことで、互いの専門性を交換し合う「Give and Take」の関係になったとき、引き出せる知見の幅が大きく広がることを実感しています。
SPメンバーが持つ、プロダクトを横断する視点
SPメンバーと一緒に動いてみて実感したのは、一人ひとりが開発チームが担当する個別の機能だけでなく、プロダクト全体を横断的に見ているということです。「この機能を変えると、別の機能で問い合わせが増える」「お客様が実際にはこう使っている」といった、個々の開発チームの担当範囲を超えた、横断的な情報を持っています。その俯瞰的な知見を、どうすれば開発プロセスの中で活かせる形にできるのか。そこに難しさがあり、同時にやりがいも感じています。
現在の状況と今後の展開
PRDレビューについては、最初の試行を終え、他のプロダクト領域のPRDでも試していく段階に入っています。回数を重ねながら、問いかけリストの精度を高めていくフェーズです。実装前フィードバックについては、型を整理しつつ、開発チームを巻き込んだパイロット運用の準備を進めています。小さく試しながら型を作るフェーズはまだ続いています。
今はまだ試行錯誤の真っ只中ですが、この取り組みを通じて「SPが開発プロセスに知見を届ける」ことが特別なことではなく、当たり前になる状態を作っていきたいと考えています。特定のチームとの関係性に依存するのではなく、どのプロダクト領域でも、SPの知見が組織として開発プロセスに届くような仕組みを一緒に作っていけたらと思っています。
We are Hiring!
この記事を通して、SmartHRのレバレッジ推進ユニットが目指す方向性や価値、取り組みについて、少しでも興味を持っていただけたでしょうか。
もし「こういった取り組みの推進に興味がある」「もう少し詳しく話を聞いてみたい」と思っていただけたなら、ぜひカジュアル面談をご検討ください！私たちと一緒に、全社的な視点と横断的な活動を通じて、SmartHRの品質レベルの成長を支えていきましょう！
