【QA Success Panel 2 アフタートーク】QA組織や評価の考え方、「なんでもやる」QAに至るまでをお伺いしました
こんにちは。MagicPodエバンジェリストのYoshiki Ito / 伊藤由貴です。
先日QA Success Panel #2 というオンラインイベントを開催しまして、多くの方にご視聴いただきました。
イベントレポート記事はこちらです。
お昼休み1時間のイベントで、実際のディスカッションの時間は正味45分程度だったので、アンケートでも「もっと聞きたかった」という反応をたくさんいただきました。 実はパネリスト・モデレーター側も同じ気持ちでして、開催後に「もっと話そうぜ！」ということになり、先日3人でアフタートークを開催しました。
今回はそのアフタートークの際に話した内容を、いくつかのトピックに分けて共有します。当日「もっと聞きたかった！」と感じた方はもちろん、この記事をご覧になっているけれどもQA Success Panel #2 には参加していなかったという方はぜひ配信動画のほうも見ていただけると、より普段のQA業務に役立つヒントが得られるのではないかと思います。
目次
QA組織構成の話
QA Success Panel #2 当日は時間の制約もあり、テーマ1, 2は簡単に触れるにとどめ、テーマ3を中心にディスカッションを行いました。 アフタートークではせっかくだからテーマ1の、双方の組織の構成や背景から共有していこう、という話になり、組織構成の話からスタート。
まずはmurashiさんが書いてくださっていた、インプロセスと組織横断とのハイブリッド、という点について話をしました。
ハイブリッド、にもいくつかの考え方があります。
- 組織構造のハイブリッド
- インプロセス専業のQAと、組織横断専業のQAとが存在する形
- マインドセット・工数配分としてのハイブリッド
- 個々のQAが、業務内容や工数配分について、＊割はインプロセスで残りの＊割は横断的なもの、といった動き方をする形
また組織構造に関しても、
- QAがQA部等の組織に所属し、そこから各開発チームに入り込む形
- QAは各開発チームに所属し、バーチャルな横断組織としてのQA組織がある形
などのパターンがあります。
これらのパターンについて、現状や今後どうしていきたいのか等の議論になりました。もちろんこれらの形・パターンには正解が無いのですが、その時点における組織の最適解だけでなく、組織のフェーズも踏まえた移り変わりなども含めて理想を設計する必要があります。
当日も少し話題に上がっていましたが、「BizとDevの距離が近いっていいよね、そういう組織にしていきたいよね」という話で盛り上がりました。（ここはこの後の「QAの役割、「なんでもやる」に至るまで」にも繋がります。）
QAの評価制度の話
組織構造と切り離せない、評価制度についても話題に挙がりました。
各開発チームにQAが入り込んでいて、QAマネージャーが横断的に全体を見ているような場合、個々のQAエンジニアの半期ごとの評価などは難しいこともあります。このあたりは会社全体の評価制度との兼ね合いもありますし、QA組織の都合だけでは動かせない部分なので、QAマネージャーの方が苦労しやすいポイントでもありそうです。
estieさんの評価制度では主に2つの軸、QA組織と入り込んでいる開発チーム側両者で評価を行う仕組みになっているとのことで、QA組織構造とうまく対応付いているように感じました。このあたりは、QA組織をつくっていく過程でその時点での会社の評価制度とすり合わせができるとスムーズなのかもしれませんね。
QAの役割、「なんでもやる」に至るまで
当日のお話の中でも印象的だったのが、hacomonoさんもestieさんもどちらもQAの役割として「できること、品質向上につながることをなんでもやろう」という方向性、という点でした。
estieさんでは、murashiさんがQAとしてJoinした時点で頻繁なリリースができているなど、「あれ、わりとうまく回っているのでは？」という印象を受けたそうです。先にも書いた「BizとDevの距離が近い」という面も含めて、（課題はいろいろありますよ、とのことでしたが）開発がうまく回る土台がすでにあった、ということだと思います。
品質が悪い・バグがたくさん見つかるといった状況であれば、QAとしてもやるべきことがあり、かつ明確にしやすいので、ある意味動きやすいという面もあります。しかし、土台ができていて開発が回っている状態においては、「QAとして何をしようか」という（贅沢な）悩みも発生します。このような状況の中で、開発全体の動きがスムーズになって、それが品質を高める・顧客に価値を早く届けられるようになることはなんでもやろう！という発想につながっていたそうです。
hacomonoさんではQAがテストを担っている部分もあり、その理由としてPiro-chanさんは「QAが信頼されている」とおっしゃっていたのが印象的でした。QA組織として信頼されている点は素晴らしい一方で、今後よりテストを開発チームに移譲しつつQAの役割を拡張していく中で、信頼されている・頼られているがゆえの難しさもあるかもしれない、と感じました。
関連して、当日も（主に私が）気になっていたトピックであるhacomonoさんの「SET解体」についても伺うことができました。
もともとQAEとSETが分かれており、SETが自動テストを担っていたところ、QAの動き方を組織として変えていくなかで「QAもみんな自動化できないといけないよね」ということで、SETからQAEへとコードベースの自動テストをスキルトランスファしていったそうです。こういった決定ができる、というのは組織としての強さを感じますね。
AIの使い方の話
生成AIの使い方について、当日はhacomonoさんのLLM Dayなどについて触れましたが、アフタートークでも追加でお話を伺いました。 具体的なAI活用の話というよりは、業務におけるAIの依存度の上昇についての話題に。
最近は「とにかく生成AIを使わなければならない」といった空気感がありますが、いずれ落ち着くフェーズもくるのでは無いか、という話もでて、個人的にも共感しました。 またmurashiさんがおっしゃっていて印象的だったのは「わからないことをAIで調べて、回答が期待通りでないときにやりとりを続けて、1時間くらい経っちゃっていた、ということがある」「誰かに聞けばもっと早く解決できたのに」というエピソードです。あわせて「生成AIによって自分の能力が拡張されたというある種錯覚があって、結果として自己解決にこだわって生産性が落ちている懸念がある」「AIに聞けばいいじゃん、なんで人に聞くんだ？という文化があると特に助長されやすいかもしれない」といったお話も出て、重要な視点のように思います。
私からは「Claudeのリミットに達して復活まで残り1時間＊分です、と言われると、仕事が完全にストップしたような気持ちになります。自分でやればいいだけなのに」という、すっかりAIに使われている状況を告白しました。（皆様お気をつけください）
「いつもどおり」の話
当日のメインテーマでもあった「いつもどおり」を変える話にも触れました。
Piro-chanさんからあったのは「いつもどおり、をどのレイヤーの話と捉えるかによって変わってくる」という提起でした。 QA個人なのか、QAチーム・組織単位で何かを変えることなのか、はたまた開発組織も含めた全体での話なのか。
私が当日のメインテーマの案を出したときには、暗に「開発組織も含めた全体」のつもりで考えてしまっていましたが、確かに業務の仕組み化などで「いつもどおり」を変える場合には、このようなレイヤーごとに考える視点も必要だなとヒントをいただきました。
最初に触れたような、QA組織の構造を変えてインプロセスの動きを中心に組織横断の動きも入れて・・・といった形を検討・模索するのはまさに組織全体の「いつもどおり」を変えていくところにつながりますね。
一方で「個人レベルでいつもどおりを変えているところはある？」という話にもなり、murashiさん・Piro-chanさんお二人とも、たとえば日々の行動テーマを設定したり、生成AIと連携して日報をつけるなどして改善に繋げているとおっしゃっていました。
個人的にはこうした自己管理なども含めた「QAの仕事術」的なトピックについても、今後のイベントテーマなどに設定していろんな方に伺ってみたいですね。
まとめ
今回は、QA Success Panel #2 のパネリストであるPiro-chanさんとmurashiさん、そしてモデレーターをしていた私との3名で行ったアフタートークの内容をもとに、どういったポイントについて会話をしたのかを中心に共有しました。
3人で2時間みっちりと本音トークをしたのでここに書ききれなかった部分もありますが、当日の情報と合わせてよりhacomonoさん・estieさんでの取り組みの雰囲気を感じていただいたり、なにかヒントを得ていただいたりできていればうれしいです。
hacomonoさん・estieさんともにテックブログにてQA関連の情報を発信されていますので、こちらもぜひご覧ください。
