#概要
QA業務に従事していると、どうしてもQAだけでは解決できない開発側の課題に直面し、改善を依頼することがあります。そういった時に伝え方次第で、依頼を受けてもらえる可能性や改善スピードが大きく変わることを実感したので、今までの経験から学んだことを投稿しようと思います。基本的な内容が多いので主に新人QAの方の参考になれば幸いです。
#自己紹介
2017年からQAチームにてモバイルゲームのテスト管理や障害削減、テスト効率化の推進などをしています。
#開発向けの改善依頼で気を付けたいこと
##サマリ
- 開発との良好な関係性を築き、感謝を忘れない
- 改善を依頼する課題は厳選し、適切なタイミングで提示する
- 課題は具体的なエビデンスと合わせて伝える
##1.開発との良好な関係性を築き、感謝を忘れない
改善依頼単体の注意点で言うと2,3だけですが、開発との間に信頼関係がなければどんなに準備して改善を依頼したとしても結果にはつながらない、あるいは一時的に結果が出せても継続は難しいと思います。
そこで、前提となる良好なコミュニケーションにつなげるポイントをまとめてみます。
###開発のことを知る
開発が何を課題視しているのか、またその温度感を知っておく
- QAにとって温度感の高い課題でも、開発側ではそうではないことがあることを認識しておく
- 温度感が揃ってない状態でどんなに課題を伝えても響かないため、まずは開発との温度差を把握することが重要
開発側の負荷状況を知っておく
- 負荷が高い状況で優先度の低い要求をしない
- 「今それ言われてもさすがに無理」、「そもそも状況を把握してる？」とNextActionに繋がらないだけでなく信頼を失う可能性も
###開発と目線を合わせる
課題に対する温度感を合わせる
- QAはなぜその課題を重要視しているのか、それによるリスクや懸念を明確化して伝えて理解してもらう
共通の目標を持つ
- 期初など仕切り直しのタイミングで、共通の品質目標を立て一緒に取り組むことを合意しておく
- 例えばQAへの検証依頼漏れによる障害を○%減らすなど
###開発の立場を尊重し感謝を忘れない
求めるだけでなく、まず感謝もしっかり伝える
- 感謝と依頼のバランスが大事
- 感謝せず依頼ばかりしていると、関係性が悪化したり相談しづらくなるため要注意
開発側の課題にもできる範囲で貢献する
- 開発側で困っていることにもアンテナを張り、改善案を提示したり、他タイトルの改善事例を共有するなどできる限り貢献していく
##2.改善を依頼する課題は厳選し、適切なタイミングで提示する
現場の要望や課題はそのまま伝えず、取捨選択し優先度をつける
- 現場の要望や課題に対して、何が根本原因か、またどの職種で改善すべきかを考える
- 精査した結果QA内で解決すべき話であればQA内で対策する
- 課題に優先度をつける
- 優先度は課題の発生頻度や重大度などを基準に考えるとぶれない
ベストなタイミングを見計らう
- 開発の温度感と課題の優先度をもとに、今改善依頼をあげるべきか、来月に回すべきかなどタイミングを精査する
精査した上ですぐに改善してほしいことがたくさんあったとしても、一度にまとめて投げない
- もちろん課題の優先度にもよるが、できるだけ今一番改善してほしいこと1つに絞って相談する
- まとめて依頼してしまうと優先度がよくわからなくなるため、NextActionが定まらなかったり初動が遅くなり、結果遠回りになる
##3.課題は具体的なエビデンスと合わせて伝える
課題を裏付けるエビデンスはKPIだけでなく具体的な情報も合わせて提示する
- 必ずKPIの中身は事前に分析しておいて、具体例と合わせて提示する、もしくは聞かれた際に答えられるようにしておく
- 具体的な内容や事例がないと対策も曖昧になり、効果を発揮できずに終わってしまう
#さいごに
自分なりに開発への依頼で気を付けるべきと思ったことを列挙してみました。チーム開発の現場において信頼関係はとても重要です。一見課題が出次第すぐ開発へ改善を依頼する方が改善は早く進みそうですが、実際はそうではないことの方が多いと感じます。1つ1つの課題に丁寧に向き合い、開発と一緒に解決して行きましょう。