こんにちは。freee会計の口座連携システムでQAエンジニアをやっているtoyopiです。
freee Developers Advent Calendar2023 20日目です。
自己紹介
私は2022年10月にfreeeにQAエンジニアとして入社しました。 freee入社前は組み込み開発/技術営業/Webアプリケーション開発などを経験しており、QAエンジニアはfreeeで初めて経験する職種でした。 社会人経験の中では開発として過ごしてくる期間の方が長かったのですが、 モノやプロダクトの開発をしていると「自分が今作っているものは実際に使う人にちゃんと意味のあるものになっているのだろうか」と思うことが多くなり ユーザー目線に立ちつつ開発もサポートできるQAエンジニアにジョブチェンジすることにしました。 freee入社直後はfreee会計の税理士向け機能のQAとして、そして現在はfreee会計口座連携システムのQAを担当しています。
QAエンジニアになってみて
QAエンジニアを実際に経験し、経験前とのギャップやこの職種の深さなど学んだこと感じたことは多々ありますが その中でも「コミュニケーション」というところに焦点をあてたお話を書いていきたいと思います。
というのも実際にQAになってみて思うのが、チームとの関わり方やコミュニケーションの取り方がかなり重要だなと思うようになったからです。 チームといかに認識を合わせて行動できるかがテスト工程やチームの品質につながるのではないかとここ最近思うようになりました。
この記事で書くこと
ということで今回は、私がチームとのコミュニケーションで気をつけていること・意識していることを記事にしてみました。 どれも完璧には出来てないかもしれませんが、なるべく意識していることです。
特に「スクラム開発をしている かつ QAがいないチームに専任QAとして参画しようとしている人 もしくは 参画して日が浅い人」は、ここ1年の私の状況と似ているので参考になるかもしれません。 チームメンバーと関係性を構築しつつ、QA業務(主にテスト工程)を円滑に進めるヒントになれば嬉しいなと思います!!
文字だけになってしまったことが悔やまれますが、よかったら読んでみてください。
コミュニケーションで気をつけていること
(1)同期的に話す場を持つようにする(=仲良くなる)
チームに入った直後くらいにやるようにしており、 所属するチームが今何を目指していて、何を作ろうとしていて、具体的にどういう作業をやろうとしているのか...を出来るだけ知る機会を作るようにしています。 チームが目指している先をちゃんと理解できると、テスト設計や実行の際に注力するポイントの参考になったりするなと思います。
色々方法はあるかと思いますが具体的に私が実践したのは、「チームのデイリースクラム(朝会)に参加させてもらう」です。 開発エンジニアの進捗確認の場になってる場合、中にはQAが参加して何するの？と思うかもですが私がデイリースクラムに参加して考えていることは以下です。
- もともとQAでテストする予定のない改修(ちょっとした修正やバグ修正)の中でテストした方がよいものはありそうか？
- 次回案件のだいたいのテスト開始目安の予想
微修正といえどソースコードを修正するので場合によっては障害につながるケースもありました。そのため、ちょっとした修正でも「影響がありそうな機能はないか？」を考えながら聞いたりしています。 必要であれば開発エンジニアが作ったGitHubのプルリクエストを眺めたり、理解がすぐに出来ない時は具体的な修正内容を朝会の場で同期的に聞いたりします。
そしてテスト開始目安の予想をするのは、できるだけ開発からテストフェーズへの切り替えを素早くするために前もって準備するためです。 slackで追うよりも同期的に開発の進捗を毎日聞いているほうが、予想の精度も上がっているような気がしています。(個人の感想です)
ちなみにfreeeではどのチームも雑談(社内では、ゆるふわ とも呼ばれる)を意識的に取り入れているなと感じていて デイリースクラムでは雑談の場があることもあり、仲良くなれる後押しにもなっています。
雑談の重要性については、QA 兼 スクラムマスターとして活躍されているbarusさんの記事でも触れられているので良かったら見てみてください。
(2)丁寧すぎる言葉は使わないようにする
こちらもチーム入った初期ぐらいに意識していることです。個人の主観になってしまうので具体的な言い方は伏せて、なぜ気をつけているか理由を書くに留めておきます。 意図としてはいい意味でラフな関係性を構築したいなと思っており、壁を作りたくないなという思いもあります。 QAからチームに、チームからQAに、どちらの方向のコミュニケーションにとっても遠慮なく自然に言葉を交わせるようなそんな関係性を築きたいなという思いもあります。 そういった小さな積み重ねが確認不足や認識齟齬防止につながるんじゃないかと考えています。 意識するだけでも振る舞いが変わると思うので参考になれば嬉しいです。
(3)多分、そうだろう...で業務を進めない
特に仕様に関しては不確実なことは必ず確認するようにしています。ちょっとでも迷うようであれば必ず聞くようにしています。 特にテスト工程で仕様をしっかり確認しないまま進めていて、認識が合わないままテストを実行していたとなると 品質問題にも直結するし、何より無駄なテストになっているかもしれないからです。 テストはどうしても後工程ということもあり、テストで遅れがあるとリリースにも影響があります。 ちょっとしたことかもしれない、こんなこと聞いて大丈夫かな、こんなこと聞くのも気がひけるなと思うこともあるかもしれませんが、そこで聞かなかったことで結局工数が膨らむ・問題が発生するということにもなりかねないので 迷ったら絶対に確認はしましょう。
ちなみに...聞くことを迷う頻度も前段で書いた(1)や(2)が後押ししてくれて、少なくなるかなとは思ったりもします。 そしていざ質問する時も、意識できるポイントがあると思うので↓に書きました。参考になればと思います。
(4)質問をする時は、質問を受け取る立場のことを考える
QAエンジニアは仕様の質問をする機会が多く、ここは特に意識しているポイントです。 質問をすることばかり考えるのではなく、この質問を受け取った人が理解できる内容か、知らない用語はないか、答えづらい質問形式になっていないか考えるようにしています。
具体的には...
YES or Noで答えられる形式で質問する、回答に出来るだけ自由度をもたせない(AはBですか など)
質問が複数ある場合は冒頭に質問の数を記載する(〜点質問があります など)
質問を見たときに見やすいかたちにする(質問が複数ある場合は文章で繋げるのではなく質問ごとに番号を振る など)
以下はQA特有ですが...
- テストいる・いらないを聞く時は、自分の意見+理由をセットで言う(〜だと思うのでテストは必要だと思いますがいかがですか？ など)
最後のテストいる・いらない質問は、私がQAなりたての頃の「テストいりますか？」と聞いてばかりでチームメンバーが回答しづらく困らせてしまった失敗からこの形式で質問するようになりました。
すべての質問に適用することは難しいかもしれませんが、なるべく気をつけています。
(5)聞いた内容は自分の言葉で言い直す
同期的に質問したときによくやります。 聞いて理解した内容が本当に合っているのかの確認のために自分の言葉で言い直して聞くようにしています。 抽象度高くなってしまいますが、例えば、「〜っていうことですか？」や「〜っていう理解でOKですか？」といったかんじです。
さいごに
以上が私がチームとのコミュニケーションで気をつけていることです。
これまで複数のチームのQAを担当して、チームによってQAエンジニアの動き方は全然違うなと思いました。 そこがQAエンジニアの難しいところでもありますが、深くて面白みがあるところなのかなと思うこともあります。 結局大事なのは、線引きせずチームのために出来ることは何でもやっていくというマインドが大事なのかなと今は考えています。 「チームにとってコミュニケーションがとりやすい形って何だろう」を考えることもその一つかと思います。 今回の記事がそのヒントになれば嬉しい限りです。
明日は基盤QAのyukkyさんが基盤QAについて記事を書いてくれるみたいです!!一味違ったQAエンジニアの動き方を書いてくれると思います。お楽しみに!!
