記事のサマリー（TL;DR）
- SmartHR品質保証本部レバレッジ推進ユニットは、カスタマーサポートチーム（SP）の顧客・業務知見を開発工程に応じて整理し、QAエンジニア（QAE）と共に仕様レビューに活かす取り組みを進めています。
- 複数の開発案件で試行した結果、レビュー観点を用意するだけでは知見を活かしきれず、工程ごとにSPが提供できる情報と確認すべき内容を整理する必要があるとわかりました。
- 現在はSPが主体となって試行を継続しており、指摘内容とその後の対応を記録するデータベースの整備や、レビュー観点をまとめたNotion AIスキルの活用も進めています。
詳細
実際の開発案件で得られたフィードバック
前回の記事「開発プロセスに他職種の知見を届ける —— QAエンジニアによる仕組みづくりの現在地」では、SPが持つ顧客・業務知見をリリース前の品質づくりに活かすため、プロダクト要求仕様書（PRD）のレビューや実装前のフィードバックを試みている段階を紹介していました。当時はSPならではのレビュー観点を問いかけリストに整理している途中でした。
今回紹介されている内容では、前回の記事以降、主に人事労務領域の開発案件を対象に、SPとレバレッジ推進ユニットのQAEが仕様レビューを行いました。レビューに参加したSPメンバーは、問い合わせ対応で得た知見と仕様を照らし合わせながら、顧客が実際に行う操作や、リリース後に起こりそうな問題を確認しました。レビューでは、データ出力や一括更新、権限による表示の違いなど、仕様だけでは判断しにくい論点が挙がりました。
具体例として、承認済みの申請を取り消せる機能のレビューが紹介されています。レビュー時点の仕様には、取り消しが必要な申請の存在を管理者に事前に知らせる仕組みがなく、問題が起きた後も対象の申請を簡単に探せない状態でした。これに対しSPメンバーは、管理者が取り消しの必要な申請に気づかないまま、取り消せる期限を過ぎる可能性を指摘しました。あわせて、類似する問い合わせの実績に基づき、リリース後に問い合わせが発生する可能性を共有し、取り消しが必要な申請を管理者へ知らせるアラート通知を提案しました。
レビューに参加した開発チームからは、「ユーザーニーズが具体的に見えて助かった」「早い段階でフィードバックを得たほうが、スケジュールへの影響を抑えやすい」という声が寄せられたとのことです。ただし、こうした指摘が最終的な仕様に反映されたかどうか、リリース後の問い合わせにどの程度影響したかは、まだ追跡できていないと述べられています。指摘を出すだけで終わらせず、その後の結果まで確認することが課題として残っているとしています。
SPの知見を、仕様のフィードバックに活かすために必要だったこと
協業を始めた当初、筆者はSPの知見を主に問い合わせに関する情報だと捉えていましたが、実際には次のような幅広い知見が蓄積されていました。
- 顧客から得た一次情報をもとに整理したインサイト
- SP内に蓄積された仕様のナレッジ
- 問い合わせ件数などの定量情報
- 顧客への案内に使う文章案
実際にレビューに同席すると、SPの強みはこれらの情報を持っていることだけではなく、顧客がその機能を使う前後の操作をたどり、連携先のプロダクトや周辺機能まで確認しながら、仕様がどこで問題を生むかを考えている点にもあったとしています。顧客の業務と機能のつながりから、実際の利用時に起こる問題を予測できることも、SPの専門性だと捉えるようになったと述べられています。
一方で、各工程に合った関わり方をQAE側が見極めきれておらず、SPの専門性を具体的な指摘や提案につなげる支援が十分にできない場面もあったとしています。SPの知見を仕様の確認に活かすには、工程ごとにどの知見を活かし、何を確認するのかを整理する必要があったとしています。
SPとQAEで、工程に応じたレビューを設計する
これを受けて、実施済みのレビューを振り返り、各工程でSPが提供できる情報と、フィードバックできそうな内容を検討・整理しています。「試行予定」の工程については、現時点の仮説として記載されています。
- PRD作成（試行予定）：SPが提供できる情報は、顧客から寄せられた声、問い合わせ実績、既存機能に関する知見。確認する内容は、顧客課題の捉え方、プロダクトのスコープ。
- PRDレビュー（実施済み）：SPが提供できる情報は、類似する問い合わせ、顧客による現在の回避方法、既存機能との関係。確認する内容は、考慮漏れ、ほかの機能への影響。
- 仕様具体化・実装前（実施済み）：SPが提供できる情報は、顧客の操作や業務の流れ、周辺機能や連携先に関する知見。確認する内容は、利用時に起こる問題、リリース後に予想される問い合わせ。
- リリース後（試行予定）：SPが提供できる情報は、実際に発生した問い合わせ、顧客の反応。確認する内容は、事前に予測した問題が発生したか、指摘や仕様変更が問い合わせに与えた影響。
実施済みのレビューで挙がった指摘は、案件固有の内容で終わらせず、ほかの仕様を確認するときにも使える問いへ置き換えています。
PRDを確認するときに使う問いの例として、次が挙げられています。
- 類似する機能で、継続的に発生している問い合わせはないか
- 現在、顧客が別の操作で回避している課題はないか
- 既存機能との違いを、顧客へ説明できるか
- 開発のスコープから外した内容が、リリース後の問い合わせにつながらないか
仕様が具体化した後に確認する問いの例としては、次が挙げられています。
- 顧客が実際に行う一連の操作を完了できるか
- データ出力、一括更新、権限の違いが考慮されているか
- 連携先のプロダクトや周辺機能に影響しないか
- 期限のある操作について、対象者が期限切れに気づけるか
こうした工程ごとの整理や、指摘を問いへ置き換える作業を通じて、QAEはSPの専門性がどの工程で活かせるのかを確かめ、その知見を効果的に活用できる仕組みを検討したとしています。今後も実際の案件で得られたフィードバックをもとに、SP主体で見直していくとしています。
SP主体の運用へ移る
これまでの試行は、SPとQAEが協業しながらQAEが主体となって進めてきましたが、現在はSPが主体となって試行を続けています。
SPが仕様検討の段階から関与する目的は、顧客が困る状況や問い合わせにつながる要因をリリース前に減らすことだとしています。そのため今後は、仕様が完成した後にレビューするだけでなく、プロダクトマネージャーがPRDを作成する段階で、SPが顧客から寄せられた声を提供し、PRDの検討を支援する方法も試す予定としています。
継続的な運用に向けた課題も挙げられています。これまでSPが関与できる案件は、PRDの完成時期や開発案件の進行状況に左右されてきました。対象とする案件や参加するタイミングを決めることに加え、指摘がその後どう扱われたかを確認する仕組みも必要だとしています。そこで、SPが指摘した内容とその後の対応を記録するデータベースを作成したとしています。今後は、最終的な仕様への反映と、リリース後の問い合わせへの影響を記録し、ふりかえりに使うとしています。
レビュー観点は、SPメンバーがフィードバックを出す際の補助ツールとしてNotion AIスキルにもまとめられています。実際の案件で検証したSPメンバーからは、短時間で確認する観点を増やせることや、SP内に分散した知見を参照しやすくなることが評価されているとのことです。ただし、ツールがフィードバックの内容にどの程度寄与したかは切り分けられていないため、まずは経験のあるSPメンバーの判断と組み合わせて利用していく予定としています。
おわりに
複数案件で試したことで、SPの知見を仕様検討に活かすには、レビュー観点を渡すだけでは足りないことがわかったとしています。関与する工程に応じて、SPが提供できる情報と確認する内容を整理する必要があるとしています。
現在はSP主体で試行を続けながら、より広い範囲の開発案件への関わり方と、それを実現する体制や運用を整えているとしています。あわせて、不具合管理の手法をベースにしたフィードバック後の結果まで追跡する方法を検討しているとのことです。
また、レバレッジ推進ユニットの今後の方針として、今回の進め方をカスタマーサポート以外の職種にも適用できるかの検証も行っていく予定としています。まずは相手の専門性と課題を確認し、それが開発プロセスのどの工程でどのように活用できるかを整理し、検証していくとしています。