天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

【freee/マネーフォワード/メルペイ】QA Talk〜QAの悩み"あるある" どう解決してる?〜に参加してきた

mercari.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

本イベントは、freee ✕ マネーフォワード ✕ メルペイのコラボイベントです。 今回は、QAエンジニアなら感じているであろう課題や登壇者がいま、抱えている悩みなどを取り上げます。各社の事例をまじえ、パネルディスカッション形式でお届けします。

会の様子

QAの役割

今回の話をしていくにあたって、各社のQAがどのような役割を担っているのか話を聴いていきました。

  • 「起こしちゃいけないハッピー(=不具合)が起こりにくい体制にすることで、価値を継続的に届け続ける」を実現するために必要なことは何でもやる(by freee)
  • 「信用を創造してなめらかな世界を作る」をもとに上流から下流まですべてにQAが関わるようにしている (by メルペイ)
  • 「品質を前へ、プロダクトを前へ」をもとに各部署が仕事をやっている。テスト以外もやるということは共通事項としてある。 (by マネーフォワード)

ありがちな悩み相談

役割の共有が終わった後は、会のタイトル通りありがちな悩みに対する回答を答えていく時間になりました。

以下、悩みと回答を一問一答形式かつ常体で記載していきます。

QA組織の価値をQA以外にどう説明しているか?
  • 全体会議で、QAとはなにか?を伝えるようにしている
  • QAの豆知識を毎週発信している
  • 失敗話として、「可視化」や「透明性」を実践しようとしたら、実践するのに工数がかかりすぎることがわかって頓挫したエピソードはある
  • 「すごく時間をかけないとバグが見つからない」という考え方が間違っていることを定量的に説明した
  • 「やらなくていいテスト」を徹底的に消した(2週間くらいかけていたアドホックテストとか、重大な不具合を見つけることがないテストとか、数をこなすためのテストとか)
アジャイル×QAは相性が悪い印象が多いのだが起こりがちな問題をどのように解決するのか?
  • 継続的にリリースするとなるとQAの工数を毎回調整しないといけないので大変だったりする。そこで、リストアップした案件は中長期的な見積もりを事前に行うようにした
  • スコープ変更の際にコミュニケーションを随時取っていくようにした
  • 「言われたことをやるので教えてください」というマインドセットを撤廃する
  • アジャイル×QAの相性というよりも、そもそもアジャイル開発がうまくいっていないみたいな話も多い。そういうときに、「自分はQAだから...」としているような姿勢を取らずに積極的に改善していくようにしている
  • 開発者よりもQAの方が人数が少なくなりがちで負荷が高くなるので、開発者自身がテストをできるようにサポートする
  • スクラムイベントで、ハッピーパス以外の観点を提供するようにしている
  • 開発プロセスをQAが作るようにしている
QAに関連して注目している客観性のあるメトリクスは?
  • 品質の良い/悪いを見るためのメトリクスを探すのにあまり意味がないと思っている。テストケースの粒度とかは人によってぜんぜん違うため。ただ、進捗を測るためのメトリクスはあると思う
  • C1カバレッジとか不具合を定性/定量の両面で分析するとか
  • シンプルに不具合の件数と、重篤な不具合の比率を見るようにしている
  • 静的解析を取っているが、これは取るだけになっている
QAとしての仕事ができないと、ビジネス価値に結びつくアーキテクチャをアーキテクトが作成することは難しいと思うが、どう考えるか?
  • アーキテクトに限らず、みんなQA視点を持っていた方がよいと思うが、「QA視点がないとビジネス価値に結びつくアーキテクトを作成できない」だと言いすぎな気はしている
  • 「QA視点」が何を指しているのかわかるともう少しクリアな回答ができそうな気はしている
QAがバグを見つけられないと「QAの価値ないのでは...?」と思われがちなのだが、どういう風に説明するとよいか?
  • リスクが高いところをテストしているはずで、そこでバグが出ていないなら開発したエンジニアをまず褒めると良い
  • 「リスクが高いことにバグがないこと」は証明できているので、そこに価値を感じる
  • QAが「テストをする人」としか思われていない証拠な気もするので、QAがテスト以外もしているなら、QAが継続的にサポートできているからこういうことになりましたよね、といえば良いと思う。
傍観者にならないようにメンバーを育てていく方法は?
  • 傍観者になっていることをFBする必要がある。個人を責めるのではなく、事実を確認する
QAエンジニアが入ったときにどんな能力が高いと嬉しいか?
  • コミュニケーション力。QA内部から外へ話を広げることが重要だと思っている
  • プレゼンテーション力
  • どの能力にしても、「まずは自分事にできるのか?」を重視している
  • 採用基準を読んでほしい
  • この力が欲しいというよりは、今のチームにない能力を持った人が来てくれると嬉しい

会全体を通した感想

「ありがちな悩み相談」が本当にありがちなのかは少し気になったのですが笑、色々なアプローチの仕方を学べて楽しかったです。

ゆもつよさんが激推していた採用基準はぜひ読んでみようと思います。