ぐんちゃさん が頑張って企画取りまとめたり、動いているの見てて、面白そうだなーと思ってふわっと参加してみました。なお私はテスコンU-30に参加したことがあるただの一般開発エンジニアです。
というか最近勉強会や配信に参加しておらず本のみのインプットになっていたので、久々に人の経験や感覚の話を聞いてみたかったのと、開発チームとしてQAエンジニアの立場や参加の仕方ってどうなんだろうっていう視座を持ちたかった（前々からコミュニティの運営とかやってて、チームでどう動くかとかは結構考えるのに興味がある）ので、ちょうどよかった、というのもあります。
あとこの日は非常に頭痛が酷かったため、このイベントの後寝ていました。
イベントURL
あなたの知らないQAチーム、QAエンジニアの世界 - DevLOVE | Doorkeeper
資料
こちらの運営振り返り記事に乗っていました。感謝。
「あなたの知らないQAチーム、QAエンジニアの世界」資料まとめ＆運営日記｜ぐんちゃ｜note
感想
普段触れていない世界観なので、雑な感想になってしまいがちですが、個別に印象に残ったことを書いていきます。
オープニング、エンディング周りのメモ
QA2AQもそもそも知らなかった
- https://www.slideshare.net/hironoriwashizaki/agile-quality-qa2aq
- QA to AQ： Quality Assurance から Agile Quality へ - Qiita
エムスリーのQAチームが目指すもの
低コストで高品質の製品を創り、高速リリースが可能な開発チームを創る
という目指しているところが簡潔で分かりやすく、単にテストするだけ/システムの動作を担保するだけに留まらず、顧客価値や開発チーム自身の改善にコミットしようというのがいいなと思いました。
その目指しているところを実現するために5つ実践していることがある、とのことでしたが、これも過去の失敗を分析し、改善してきて現在のものがある、というのを発表の中で聞いてすごくわかりやすいし、いい対応だなあと思いました。
特にテストプロセスはいわゆるウォーターフォールであればV字モデルの登り側？後半のほう？であるため、そのあたりを担当範囲になってしまっていた状況から、上流への仕様策定から入ってテスト観点での意見出しや仕様上の調整を行う、というのが良さそうだなあと思いました。
テストプロセスでやっぱりこっちのほうがいい、仕様がひっくり返る、となるとリリース、顧客への価値提供が遅れることになりますし、また無駄な実装をしてしまったコストの消費、リリースが伸びることによる心理的負担、モチベーションの低下などあまりプラスに捉えられることがないので、変更や詳細を詰めていくのは関係者間で早めに決まっていく体制になっているといいよなーと思っています。
また事業フェーズによって、求められる品質が変わっている、というのも当然そうしたほうがいいよなーと思いつつ、確かにそうだなと思いました。長く続いているサービスは既存影響を、逆に新規に立ち上がったものは出してみてフィードバックを得る、と戦略が変わるので、そのバランスを取りながら顧客に提供する品質を担保するのは大変そうだなあと思いました。
まとめると、ただのテスターではなく、QAエンジニアとしてチームに求められる人物像としては、テストプロセスだけでなく要望整理や仕様策定のフェーズから開発プロセスの様々なところでレビューを行い、品質を担保するためのテストを設計・実施していける人なのかなあ、とぼんやり思いました。
実際にQAエンジニアとして働いているチームをリードする生の声が聞けて、大変勉強になりました。
QAチームを立ち上げたい！
これ実はわかってないところが多く、結構事業とチームの紹介から入って、どう行ったプロセスを担当してほしいか、という流れだったので、QA観がない自分としては良くわかっていなかったです。
なのでハッシュタグを追いながら情報を理解してみて、下記みたいなものがあったなあと思ってます（Twitter追い直したわけじゃないので、そういうのが流れてたなという印象だけ）
- 目的に対するスキルセットが提示されているだけに見える
- スキルセットの提示だけであるならば、まず第三者検証を行う手もあるし、自社で雇わなくてもよいのでは？
- このあたりも品質を担保するための方法論として取りうる選択肢なので、なるほど…と思った（うーん、開発エンジニアの話に落とせば受託やSES、オフショアみたいな発想になるのに、なぜかQAの話になると急に出てこなかったですね。シチュエーションとしては一緒のはずなのに）
- まずQAに求めるものが曖昧に思われるので、組織、プロダクトの課題整理からやれる人じゃないと難しそう
- このあたりは上の発表でもあったけど、要望フェーズから入ってやり取りできる人じゃないと厳しそうだなという印象
- もっとどういうことで困っている具体的なエピソードとかほしい
- これもわかるし、なぜ必要なのかということがスキルセットレベルでしか表されてないという印象を強めてしまうのかな…
1人目のQAを求める立場と、QAの人が1人目の人として入ったときないし、品質を改善するための思考として色々な手段を思い浮かべているんだなぁと思いました（どちらかといえば発表周りで起こっている意見周りが面白かった）。
なお、開発してるプロダクト（個人にカスタマイズされた記憶アプリ）自体は結構面白いなと思っていて使ってみたいなと思いました。
201103_DevLoveあなたの知らないQAチーム・QAエンジニアの世界余は如何にして品質技師となりし乎
紆余曲折を経てQAエンジニアになり、人生の品質が向上した、という話でした。自己肯定感グラフが結構印象的でした…。
とはいえやりたいことをやろう、と一念発起するあたりは、自分も壁に当たっているときにやっていること似ているし、あと人は大事…だなと思います。
一番最後のまとめはQAエンジニアというより、社会人として人間（？）としてキャリアをどう選択していくか、という話に近いかなと思っていますが、聞いていてとても良かったなあと思います。
僕もいろいろな人に支えられたり迷惑をかけたりしてここまで来ているし、登壇？とかで何とか恩送りしようと努力していますが、まだまだなので頑張っていきたいですねぇ…（白目）。
これまでのキャリアをQAエンジニアとして役立てる話 ~語る人枠~
これも紆余曲折を得てQAエンジニアになった話なのですが、どちらかといえばこちらは経験における構成要素がQAエンジニアとしての現在の自分を支えている、という感じで上の発表とは差別化されていました。
要はQAエンジニア、というのは比較的新しいポジションな気はしますが、品質を担保するにあたり仕様や要望などを満たしているか、また顧客へ提供される機能がより良いものになるかどうか、そういった点が重要ですが、これは開発経験だけでなく多角的に見れる人に強みがあるのかなという印象を受けました。
話の中だとこれらが上がっていました（気の緩み→覚醒→気づき、は面白かったのですが要約して書くには長くなってしまうので、スライド参照で…）
- プログラミングの経験
- カスタマーサクセスとしての経験
- 営業？ソリューション周りのビジネスロジック周りを担当する経験
- テクニカルリードとしての経験
これらが総合して生かせている場所がQAエンジニア、という感じですかね…。
とにかく開発だけでなく、様々なところに目を向けたり経験を積んでおくことが、最終的にビジネスを意識したソフトウェア開発をリードするメンバーとなる、ということなのかもな、というのを思いました（曖昧ですが）。
まとめ
4者4様で、普段知らない世界を開けたなあという気持ちです。普段、基本的に開発フェーズメインでやっていると気づかなかったり、意識が薄れているところだったりに気づかされたりと、学びの多い勉強会でした（QAエンジニア自体もそうだけど、ビジネスへの向き合い方やキャリアの考え方の参考にもなりました）。
YouTubeライブのアーカイブも残っているようなので、このブログでの感想やスライドに興味を持った方は一度見てみるとよいのではないでしょうか。というところで終わります…（思ったより長くなってしまった）
