この記事は、CYBOZU SUMMER BLOG FES '24 (QA Engineer Stage) DAY 6 の記事です。
こんにちは、kintone AndroidチームでQAエンジニアをしている田中です。
今回は、所属しているチームのQAとエンジニアがコミュニケーション量を増やしたことと感じた変化をお話しようと思います。
はじめに
kintone Androidチームと私
kintone Androidチームはその名のとおり、kintoneのAndroid版モバイルアプリの開発をしているチームです。 現在はエンジニアは3人、QAは1人（私です）所属しています。
私がこのチームに入ったのは昨年6月中旬頃、別チームと兼任での配属でした。
しばらくはチームの掛け持ちの状態が続き、今年3月上旬に専任となりました。
＜チームに入ったばかりの頃＞
- 今までモバイルアプリのエンジニアと交流がほぼ無かったので不安とドキドキ
チームでは「話す」機会を増やしてきた
約1年前のQAとエンジニアの距離
当時、チームのQAは自分も含めて2人。どちらも他チームとの兼任メンバーでした。
この頃は兼任しているチームの作業との兼ね合いを考慮しつつテスト設計・実施をしていました。
仕様書などテキストベースで開発内容を理解することが多く、やりとりも最小限。
テスト設計の着手は最優先で行なわれるわけではないため、QAがテスト設計を始める頃にはエンジニアは次のPBIに着手していますし、スプリントゴールにもテスト完了までは含まれていませんでした。
さらに、チームには私と同じ所属オフィスのメンバーがおらず、出社したときに雑談できるというタイミングも滅多に訪れません。
そんな事情もあり、心理的に、難しい内容ならともかくちょっとした質問のほうが逆に質問しづらい…と感じていました。
＜この時点での課題＞
- エンジニアに直接聞けばすぐに解決するような内容も、まずはQAメンバーに相談していた
- QAが参加するスプリントイベントは最低限
- QAとエンジニアはテキストベースのコミュニケーションが多かった
- スプリントゴールにテストフェーズは含まれていない
- 人となりがまだ把握できていないので声をかけるのに少し勇気がいる
- 兼任メンバーがいるためスケジュール調整がハードモード
少しずつ一緒に作業をするように
まずはデイリースクラムやプランニング、ふりかえりなど、これまでPM＋エンジニアだけで実施していたスクラムイベントにQAも参加を始めました。
QAはそれぞれ兼任しているチームがあるため予定を入れるときは複数チームのスケジュールの中で調整する必要があり、どうしても都合が合わないということもありましたが、最低限QAのどちらかは参加できるようにしていました。
＜この頃の変化＞
- 話す機会が増え、エンジニアメンバーの人となりを徐々に理解
- “ ついで “ で口頭相談ができるタイミングができた
- 一緒に作業をしているという意識が出てきた
朝会やふりかえりで徐々にファシリテーターの持ち回りに参加
QA参加前の名残で、参加者が持ち回りで担当していたファシリテーターのローテーションにQAメンバーは含まれていませんでした。
せっかく参加しているのでQAもローテーションに加わり、ファシリテーターを担当するようにしました。
初めてファシリテーターを担当したときは緊張で頭がパニックになったのを覚えています。
ファシリテータは結構スキルも必要だなと感じていて今でも苦手ですが、緊張はあまりしなくなりました。
＜この頃の変化＞
- 参加するだけよりも当事者意識を持てるようになった
「リアルでは初めまして」
所属拠点が違うためずっとオンライン上のみでやりとりしていましたが、11月にkintone iOS/Androidチームでチームビルディングを実施しました。
この時の様子はAndroidエンジニアのトニオさんが記事にしてくれています。 blog.cybozu.io
チームに入ってから5ヵ月、実際にで会うのはこれが初めてでした。
普段オンラインで話しているし…とは思っていましたが、直接会って話したりチームビルディングのコンテンツを一緒にやったりするとまた別の力が働くように感じました。
＜この頃の変化＞
- 普段の業務でより話しやすく感じるようになった
- エンジニア⇔QAの距離がより近づいた感覚があった
iOSとAndroidのチームが徐々にそれぞれの活動へとシフト
これまで合同で動くことも多かったkintone iOSチームとkintone Androidチームでしたが、人数が多く発言しづらいことや特定チームの話題のときにもう片方のチームに待ち時間が発生することなどを考慮し、分かれていても問題なさそうなものから徐々にチームだけで動くようになりました。
＜この頃の変化＞
- チームのことだけを考えられるようになった
- 時間いっぱい自チームの話ができるようになった
テスト設計のエンジニアレビューを導入
テストの設計はこれまでQA2人の間でやりとりして完結させていましたが、エンジニア視点を取り入れるためにエンジニアにテスト設計レビューをしてもらうことにしました。
エンジニアに見てもらうことで、過剰な確認や影響範囲外にあたる箇所の項目を間引けるので、より効率よく確認ができるようになったと思います。
＜この頃の変化＞
- テストについてより深くチームで話せるようになった
- 手動確認の内容をエンジニアが把握できるようになった
専任&QA1人体制へ
3月上旬、私は兼任していた別のチームから離れてkintone Androidチーム専任のQAになりました。
同時にQAメンバー1人がkintone Androidチームから離れ、QAが1人の現在の体制へ。
QAが1人になったことにより、第一段階の相談先が自ずとチームのエンジニアになりました。
ひとりの判断で決めてよいのか迷ったり、他の人の意見を聞きたかったり、背中を押してほしいだけの場合だったり、いろんなケースがありますが、悩むよりもまず相談することを心がけています。
＜この頃の変化＞
- QAが1人なので、一番の相談相手がエンジニアに変わった
- 内容を問わず、何かあれば相談することを意識した
- 兼任ではなくなったのでQAを含めたときの予定の調整がしやすくなった
品質とは？「LEADING QUALITY」の読書会
プランニングやテスト設計レビューなどで、QAとエンジニアの間で「このテストはなぜ必要なのか」というような会話がよく起こるようになりました。
そこで、認識を揃えるためにチームで勉強会（読書会）を開催しました。
この勉強会を通して、チームの現状を振り返ったり、チームの目指す品質について考えたり、テストや価値などの言葉が表しているものについて話をしたりすることができました。
＜この頃の変化＞
- 同じ本を読んで擦り合わせしたため、共通言語を使用した会話ができるようになった
- お互いの品質の認識について理解できた
QA、エンジニアのモブに参加してみる
気負わずに質問できるようになったとはいえ、SlackやZoomを利用して話しながら実装作業をすすめているエンジニアに声をかけるタイミングを計りづらい感覚がありました。
Slackのテキストでタイミングを伺っていたのですが、結局エンジニアがモブをしているところに私も参加をすることにしました。
参加するといっても同じ作業をするというわけではなく、エンジニアがモブで話しているのを聞きながら自分の作業をする、いわゆる同じ空間にいるような状態です。
たったこれだけでしたが、話題の切れ目や一息入れているタイミングなどが把握できるため、声をかけるタイミングがわかりやすくなりました。
＜この頃の変化＞
- 話を中断させることなく声をかけるタイミングがわかりやすくなった
- 作業中にエンジニア→QAの質問もできるようになった
- ラジオのように耳に人の声が入るので、1人で作業していた時よりも集中できる（私は、ですが）
QAとエンジニアがコミュニケーションを増やしてよかったこと
1. 気軽に声をかけやすくなった
話す機会が多くなったことで、何気ない質問も気軽にできるようになりました。
「こういう動きしてるけど想定内？」とか「ここ体験的にあまりよくないかも」とか、ちょっと口に出すだけで済むような質問や感想を心理的負担を感じることなくエンジニアに投げかけることは、1年前の私には考えられないことでした。
当初抱えていた「難しい内容の質問ならまだしも、ちょっとした質問は気が引けてしづらい」という問題は、今では影も形もありません。
2. チームで動いているという自覚ができた
以前よりも当事者意識があるため、チームで動いているという意識づけ、一体感が生まれました。
QAとエンジニアがほとんど別々に動いている状態だった頃は、同じチームで動いているという意識は薄かったです。
今はチームの活動ほとんどに参加していることで、全員で動いていると感じています。
3. 作業中の会話から即対応することができる
私はコードが読めるQAではないため「こういう場合はどうなるの？」「この機能には影響ある？」という質問を結構してしまいます。
逆に、自分が考えが及んでいなかった部分を教えてもらうこともあります。
以前は作業後にまとめて質問することが多かったですが、今はその場で質問してその場で対応することができるようになりました。
4. QAとエンジニアの作業の境界をゆるめられた
エンジニアがQA担当の作業を進められるようになったこともよかったことのひとつです。
以前は担当作業が分かれていたので、今のようにQAが1人しかいない状態だとテストフェーズに回ってきたときにQAが不在の場合作業が止まってしまいます。
そういう時にエンジニアがテストを進められるようにしておくことで、作業が滞らないようになりました。
また、進行状況や手の空き具合、テストの内容などによっては、実装が終わった段階でQAとエンジニアで手分けしてテストを行い実施時間を短縮することもあります。
職能にとらわれず誰が実施しても問題ない作業はお互いにできるようにするなど、コミュニケーションが容易になったからこそ出来るようになったことも多いです。
5. PBI着手～完了までのスピードが上がっている
情報共有が容易になったこと、実施できる人が実施するという行動がとれるようになったことなどの要因から、全体的な作業スピードが上がっていると感じています。
現在はスプリントゴールにテストフェーズも含まれています。
QAが専任になって実装と同時進行で作業を進められるようになったことも大きいですが、テストが終わるタイミングが以前よりもずっと予想しやすくなりました。
さいごに
この約1年を振り返り、改めてチームの形が大きく変わっていることを実感しました。
改めて、メンバーに感謝を伝えたいです。
チームで足並みを揃えて動いているので、今後も状況にあわせて話し合いをしながら貢献していきたいと思います。
本記事がQA Engineer Stageの最後の記事になります。
ここまで読んでくださりありがとうございました！
