「不具合を指摘しても後回しにされてなかなか対応してもらえない」
「品質向上のために色々提案をしているが、なかなか取り合ってもらえない」
こんな経験ありませんか？
もしかすると、「品質とスピードのバランスの認識」が
摺りあっていないせいかもしれません。
「スピードを重視したい人」と「品質を重視したい人」がいたとしたら
それぞれの思想がぶつかりあい、お互いに消耗してしまうでしょう。
今回はそのような衝突を避けるには、
こういうことをすればいいのでは？という提案を書いてみます。
なお本記事では
「短期的なスピードと品質はトレードオフだが、長期的なスピードと品質はトレードオン」
という筆者の考えに基づき、
スピード＝「数週間～1or2か月程度の短期的なスピード」と定義します
結論から言うと、「品質VSスピード」の衝突を避けるための提案とは
「意思決定者に聞く」です。
ただ、それだと何の捻りもないし意思決定者も回答に困ると思うので、
選択肢をAIに生成させてみました。
選択肢 1: 品質重視
- 概要: 品質に最大の重点を置き、バグのない、ユーザー満足度の高い製品を目指します。
-
特徴:
- 徹底的なテストとレビューを繰り返す
- ユーザーフィードバックは慎重に取り入れ、リリース間隔は長め
- 安定した運用を目指す
選択肢 2: バランス重視
- 概要: 品質とスピードを同等に重視するアプローチ。
-
特徴:
- 定期的なリリースサイクル
- テストと開発を並行で進め、迅速かつ適切なフィードバックループを確保
- スピードと品質のバランスを調整しながら進行
選択肢 3: 速度重視
- 概要: スピードに最大の重点を置き、早期のフィードバック取得を最優先します。品質は二の次とします。
-
特徴:
- 超短いリリースサイクルで頻繁なリリース
- テストは最小限で、即時のフィードバックを製品改善に反映
- 早期市場投入や運用フェーズでの迅速な対応を目指す
意思決定者にいずれかを選んでもらうことで、テスト戦略を策定する際のベースにします。
例）
「品質重視」なら、企画やエンジニアのテストケースレビューを通すこととする
「速度重視」なら、探索的テストを原則とする
このような形で方針をすり合わせることで、スピードvs品質の衝突を避け
PJに寄り添ったQA活動ができるのではないでしょうか？
また、プロダクトのフェーズによって重視すべきものは異なるので、
定期的に見直しを行うのもいいかもしれませんね。
何かの参考になれば幸いです。
※なお本記事は速度重視で書いたものにつき、
不明点・ご指摘・フィードバックなどあれば是非お願いいたします（笑）