システム本部デベロッパーエクスペリエンス室のQAエンジニア、伊藤由貴（@yoshikiito）です。
2023/5/30に行われたイベント みんなで学ぶ、QAエンジニアによる品質改善の取り組み LT大会 - connpass に参加＆登壇してきました。
登壇者リストにいらっしゃる
- 湯本さん
- 平田さん
- miisanさん
は最初から決まっていたのですが、残り3枠の抽選に応募し無事当選。登壇のチャンスをゲットできました。
皆さんの発表のレポート
各登壇者のみなさまの発表を聞いて、簡単なまとめと感想の共有です。
ツイートはみんなで学ぶ、QAエンジニアによる品質改善の取り組み LT大会 #QA_findy - Togetterにまとまっていますのでこちらもぜひ。
品質管理部の立ち上げと体制構築の1年をふりかえる / 株式会社10X 平田さん
10XにSET(Software Engineer in Test)として入社された平田さんの、品質管理部の立ち上げや体制構築を行ったお話でした。
2人目3人目とメンバーが増える中で、そのときどきの状況に応じて動き方やアプローチを変えながら対応された点がとても参考になりました。
特に、
- 特定チームに強く関わるのか全体的に関わるのか
- QAとして目指す姿と実態とのギャップ
- 他を優先して、一旦諦めると決めたところ
などは、会社や状況によって取りうる選択は違うかもしれませんが、考えるべきポイントとして取り入れていきたいと思います。
1人目QAエンジニアの奮闘記 -2023年ver- / 株式会社令和トラベル miisanさん
miisanさんの事例もかなり濃い内容でした。
品質を定量化することや、プロダクトチームとして
- デプロイ頻度とリリース数
- 初期品質
- 変更失敗率
- 平均修復時間
の改善を行ったこと。そしてその結果がデプロイ頻度やリリース回数にあらわれていること。
定量的なデータに基づいて改善活動を行えている点は見習いたいポイントでした。
もちろん数字だけを追い求めているわけではなく、QA文化浸透のための活動も行われているということで、高いレベルで両立されている印象でした。
失敗から学ぶQA組織 / 株式会社ワンキャリア 中西太郎さん
※資料はのちほど共有とのことです
Twitterのタイムラインも含めて、みんな「新卒1, 2年でそんなに・・・！？」と驚くほど、色々な経験をされていた中西さん。
QA組織においておこった失敗、たとえば
- 全部やろう！と思ったら、開発チームが４つ５つあるのでキャパオーバーになった
- 自動化もがんばったけど、開発チームに活用されなくなった
- QA組織の人貸し商売化・サイロ化
- 開発でテストするならQAチームって何するの？という指摘
などなど紹介されていました。
すごいなと思ったのは、行動する→失敗する→失敗を経て次の手を考える→行動する→・・・というループを回しながら改善されていた点です。すごく真っ当な形で活動されていて、自分も見習います。
また、アジャイル開発においてはQA組織が開発チームからテストを受注する形になるのはアンチパターンで、そうではなく開発チームにテスト活動を還していくことをしたいんだ、というお話にはとても同意でした。自分としてもそこは意識しているつもりで、一旦現状を把握したり、改善をするためにQAの責務を拡大したのち、効率化や最適化をしたうえで責務の再分配を行うような流れが、いいんじゃないかなーと思っています。
エンジニア全員がQAをできるようにするためのカルチャーづくり / 株式会社Voicy 山元亮典さん
スライド：みんなで学ぶ、QAエンジニアによる品質改善の取り組み_voicy - Google スライド
発表のパンチライン「QAエンジニア以外がQAできるようにするための考え方とアクションを紹介」というところがまずキャッチーでした。
Voicyさんではエンジニア全員がQAをできるようにするなど、QAチームはQA業務に加えてカルチャー醸成も行っているそうです。 DevOpsのサイクルにおいてあらゆる場面でテストが必要になることや、市場でのQAエンジニア不足もあって最少人数で最大の効果を出すことを目指して、このような形を目指した、ということでした。
特に気になったのは、テストスキルの点数化を行ってエンジニアのQA能力向上をはかったという点。最高レベルになると「QAチームが関わらなくともQA活動ができるエンジニア」というレベルだそうで、そんな開発者がいたら非常に強い組織になるよなと、関心しきりでした。
今後の開発規模拡大、QA人材を爆速で立ち上げる / freee株式会社 湯本剛さん
freeeさんは、今回発表した各社の中ではもっともQA組織が育った段階にあるかと思います。
このQA組織の拡大に効いているのが「QA人材を爆速で立ち上げる」という部分。
freeeさんではもちろんQA人材の募集をされているそうですが、いわゆる「スキルがある、強いQA」をどんどん採用するのは困難です。そこで、自分たちで育てようと考えたそうです。
QAやテストに関するスキルもそうですし、freeeさんのカルチャーにマッチした人材を育てるための各種施策が紹介されていました。そして、各種施策の結果、QAメンバーに対するセルフスキルアセスメントの回答で測る成長実感、つまり「QAエンジニアとして成長している」と思って仕事ができているという、かなり羨ましい状態でした。
いきなりfreeeさんのようなQA組織を目指すのはさすがに無理があるでしょうし、湯本さんの存在が非常に大きかったとは思うのですが、取り入れたいところは多々ありました。また、いつか自前でQAエンジニアが育成できるような仕組みを作りたくなりました。
自分の発表
私の行った発表についても簡単に紹介します。
今回発表されていた他社さんとは違い、まだQAチームを立ち上げよう！という段階です。そのため、将来的な立ち上げに向けて第一歩として行っている施策のうち、「部門内で認知される、知ってもらうために大事なこと」をお話しました。
- 複数ある開発部に対して横断的に関わる
- 入社直後の
- ひとりめQA
という状況において、QAエンジニアという存在を知ってもらわないことには何も進まないと考え、以下3つのポイントを知ってもらうためのトライをしました。
- QAの活用方法
- やりたいこと
- やらないこと
QAの活用方法とは、ざっくり言うと「QAエンジニアには何を頼めるのか」です。これが不明瞭なままだと、開発チームとしても一緒に仕事がしづらいですよね。 ただし、中西さんの発表にもあったように「テストの受託」のような仕事の仕方が定着するのは望んでいません。あくまでも最初のとっかかりとして、こんな依頼をお受けできますよ、を示すようにしました。
やりたいこと、はQAとして各開発チームにどんな関わり方をしたいか、です。例えば「最初はシステムテストの部分で一部入らせてもらって、だんだん手前の段階から関わりたい」などです。
やらないこと、はもしかしたら一番大事な点かもしれません。QAエンジニアが開発プロセスに関わることで「リリースまでの手間が大きく増えるんじゃないか」「ガチガチのルールを課されるのではないか」と、開発者に心配を抱かせてしまう可能性があります。特にQAエンジニアが居なかった組織では、こうした懸念は当然出てくると思います。そこで、QAがルールを押し付けたり、決まった数値基準で一律にリリースを止めたりといったことはしませんよ、を最初に宣言しました。
※ちなみに、「やらないこと」で触れたようなQAとしての考え方やスタイルを私は「QA観」と呼んでいます。音楽性みたいなものです。
・・・というような内容でお話しました。詳しくはスライドをご覧ください！
まとめ
久しぶりの登壇でかなり緊張していましたが、TwitterやZoomチャットのコメントを見ていると、何かしらヒントになることをお伝えできたようで良かったです。
また、普段ひとりでQAをしていると自分の思考で閉じがちですが、こうして他社さんの取り組みや事例を直接聞けると学びが多いですね。今後の活動に関するアイディアが湧いてきました。
他の登壇者のみなさんのようにQA組織の立ち上げができるよう、がんばっていきます。
一緒にQAチームを立ち上げてくださる方を募集しています
私の登壇スライドの最後にあるように、QAとして成果を出していきたいという気持ちはありつつ、推進力が足りていない状態です・・・。 そこで現在、私と一緒にQAチームを作っていってくれる方を募集しています。
社外向けの発信なども積極的にやりつつ、QAとして成長できるチームを作っていきたいと思っています。興味をもっていただけた方は以下画像から詳しい内容を見てみてください！
