いくつものプロジェクトでQAとして働いてきましたが、ほとんどのプロジェクトで共通した問題点がありました。
それは、「QAと企画・開発の相互理解が足りてない」ということです。
QA側は「なんで企画はQAに資料を共有しないんだろう」、「なんで開発はスモークテストをしないんだろう」、「なんでいつもスケジュール遅れるんだろう」、「なんでいつも同じ不具合を出すんだろう」、「そもそもQAをバグを見つける部署だと思ってないか…？（「問題のないことを確認する部署」です。この差はでかい)」、といったような不満を抱えてます。
一方、企画や開発側も「なんでこんな簡単な不具合を本番流出させてしまうんだろう」、「なんでこんなに金と時間がかかるんだろう」といったような疑問(不満？)を持ってることでしょう。
それらの相互理解不足が原因で起きるトラブルは数知れませんし、時には深刻な問題にも発展します。
私が見てきた限りですが、QAとしてこの問題を解決できた現場は、ほとんどありませんでした。その問題を受け入れた上で、大なり小なりの不満をためつつ業務をしている現場が多かった。
理由としては、「忙しくてそんな暇がない」「他部署との関係性が弱い」「他部署と対等にコミュニケーションができる人材がいない」といったところでしょうか（現在私が所属している会社も例外ではありません）。
しかし、改めて考えてみたところ、この問題はほぼコミュニケーションのみで解決できる問題であり、そして解決できたときのメリットが大きいと感じました。つまり、費用対効果がデカい。
提案
ということで、QA側に専任でこの問題をを解決するポジションがあってもいいんじゃないかな、と考えてます。
イメージとしては、カプコンさんの「テクニカルディレクター」が近いかもしれません(参考：https://www.famitsu.com/news/201709/02141012.html)。
QAの現場から企画や開発に対する問題点を吸い上げ、それを企画・開発の担当者に伝え、解決する。
それと同時に、企画・開発側が感じているQAに対する問題点を吸い上げ、解決する。
文章にすると短いですが、何をすべきかは、都度都度考える必要が出てくるでしょうし、ときにはタフなコミュニケーションも発生するかもしれません。求められる知識やスキルや素養も広範囲に及ぶと思いますが、そのようなポジションの人材がQA内に一人でもいれば、QAの社内的なプレゼンスはだいぶ変わってくるのではないかな、と思ってます。
まとめ
現在所属しているQA組織に、このポジションを提案してみようと検討しています。
自分がやるかもしれませんし、他の人がやるかもしれません。
うまく成果がでて、2020年あたりのCEDECで成果を発表できるといいなと思ってます（笑）