元QAエンジニアが、PMの立場でQAエンジニアのイベントに参加してみた

こんにちは、弥生のシダです。 私は弥生でsubPM*1として活動しています。 また、私は2023年9月まではQAエンジニアとして働いていました。

先日、弥生で開催されたQuesというイベントに参加しました。 そこで新たな気づきを得ましたので、この場にてお伝えしたいと思います。

Quesについては以下の記事を参照ください。 (なお、現地で初めて知ったのですが、こちらは”キューズ”と読むのが正解のようです。直前まで"クエス"と口語していたため、開始2秒で恥ずかしくなりました。)

tech-blog.yayoi-kk.co.jp

YOUは何しにQuesへ?

前述の記事にもあるとおり、弥生内でQuesが開催されることとなりました。 開催が決まったときには私はQA業務から距離を置いていたため、参加の予定は無かったのですが、当日の会場設営や写真撮影などの手伝いを行うこととなり、その流れで話を聞くこととしました。

QAエンジニアとPMの作業内容には少なからず親和性があることは知っていたため、今のPM業務をより良くするヒントがあるのでは、と思ったことも一因です。

予想以上に賑わっていてワクワク

今回ピックアップする話

今回第22回のQuesではいくつかのセクションがあり、いずれも興味を惹かれる内容でした。 特に、私は前職で第三者検証会社に所属していたため、「事業会社のQAに求められるものと、第三者検証会社から安定的に供給できるQAエンジニアのGAPを埋めるにはどうすればいいか」という話題については、とてつもない"わかりみ"を感じました。

その話をしだすといくらでも語れる気がしますが、今回の目的はそこではありません。(というよりも、ただの昔話になってしまう)
そこで今回は「チームで求められるQAの役割」という話題にフォーカスして話したいと思います。

「チームで求められるQAの役割」の内容

※一部、私の意訳も含まれます

テストについて

QAの業務には、勿論テストは含まれる。 ただ、目の前の物だけ見てもいいテストは出来ない。具体的にいうと、完成した設計書やシステムを見るだけでは、表面的なテストにしかならない。それを解消し、QAとしての価値を高めるためには2つ案がある

開発プロセスを観察する

開発の様子を観察することは、効果的なテストをするうえで非常に大切である。観察を通じて以下のような問題点が明らかになる。

  • 仕様決定に四苦八苦した点
  • レビューで何度も差し戻しがあった点
  • コミュニケーションが不十分なまま進んだ点

これらの問題点を見つけ出すことで、QAはプロセスの改善に切り込むことができる。また、これらの観察結果をテスト観点に取り入れることで、より良い品質を実現することが可能となる。

利用者側の目線を持つ

QA本人が仕様やプロセスに明るくない場合、あるいは開発内部に親しみが無い場合は、ユーザー側の立場なるという点が効果的である。多くの開発メンバーは、実際に利用される背景を十分に理解していないことが多いため、ユーザー目線での意見は開発メンバーにとっても貴重なものとなる。このユーザー目線のフィードバックを開発側に還元することで、品質の向上が期待できる。ユーザーの視点を取り入れることで、より使いやすく、実際のニーズに合った製品やサービスを提供できるようになる。


いずれも、とても共感できる内容でした。私自身、QAエンジニアとして出来ていたことも出来ていなかったこともあると思います。
ただ、これだけだと単なるレポートになってしまうので、もう一歩踏み込んで考えたいと思います。

PMとして何ができるか

QAエンジニアの理想の動き方は分かりました。
では、PMとしてはこの内容を踏まえ、どういったことが出来るでしょうか?

1. QAエンジニアが開発プロセスを観察できる環境の構築

開発プロセス全体を透明化し、QAエンジニアが開発の進捗や変更点を常に把握できるような環境構築が必要だと考えます。 日次のMTGで生の声を聴いてもらうことも必要ですし、タスク管理ツールなどを最新化してQAエンジニアが開発の進捗状況をリアルタイムで確認できるようにする、というのも効果的だと考えます。

2. 要求元とのMTGへのQAエンジニアの参加

要求定義や仕様策定の初期段階からQAエンジニアにも参加してもらうことで、品質要件を早期に把握し、後のプロセスでの問題を未然に防ぐことが期待できると考えます。 また、QAエンジニアが要求を正確に理解するための質問や確認ができる場としても活用できます。 QAエンジニアが要求元とのMTGに参加することで、ビジネスニーズや実際の利用背景を深く理解し、それに基づいたテストケースの設計や品質保証が可能になると考えます。

3. 開発エンジニアとQAエンジニアの対等な関係構築

上記1、2のような施策も、QAエンジニアの声が開発エンジニアに届かないと意味がありません。そのため、開発エンジニアとQAエンジニアのパワーバランスを適切に保つのが大事だと考えます。(前職でのQAエンジニアとしての経験論ですが、開発エンジニアと距離を感じることが度々ありました。)
それぞれの役割と責任を明確にし、お互いに尊重する環境を作り出すことで積極的な意見交換に繋がり、結果的に品質の向上が期待できると考えます。


貴重な学びをありがとう

まとめ

改めて考えると、QAエンジニアが最大限に力を発揮できるよう、PMとしても出来ることはあると思います。 現在の私のチームには上記のような課題は無いものの、今後チームや環境が変わることはあるはずなので、後学のために覚えておきたいと思います。

今回の参加を通して、QAエンジニアとしての視点も持ち続けるべきだなと改めて感じました。 また、機会があれば次は開発エンジニア向けのイベントにも参加してみたいとも感じました。私自身もまだまだ成長が必要だなと思える、大変良い機会でした。
開催のために動いてくれた皆様に、この場を借りてお礼申し上げます。


弥生では、一緒に働いてくれる仲間を募集しています。 herp.careers

*1:subPM…サブプロジェクトマネージャーの略