こんにちは。ドリーム・アーツのShopらんでQAエンジニアをしている坂井です。
今回はJaSST’25 Tokyoというソフトウェアテストのシンポジウムに参加してきたので、その中で印象に残ったセッションを紹介し、現在テストに関わっているやマネジメントを行なっているなど品質に関わっている、関心ある人の参考になればと思います。
また、JaSST’25 Kansaiにも参加したのでこちらもぜひ見ていただけると嬉しいです！
JaSSTとは
NPO法人ASTERが運営するソフトウェア業界全体のテスト技術力の向上と普及を目指すソフトウェアテストシンポジウムです。
今回参加したJaSST’25 Tokyoでは2日間にわたって、現地参加/オンライン参加で複数並行して行われるセッションに参加するという形でした。
私は初めて参加し、現地(TODAホール)で参加しましたが、現地で600人、オンラインで600人参加していたそうで大盛況でした。また、Discordでもコミュニケーションが取れ、講演後に質問や感想など共有できる場が用意され、発表中にも感想がどのセッションでも流れていました。
その中で特に印象に残ったセッションを中心にレポートしたいと思います！
スケールアップ企業のQA組織のバリューを最大限に引き出すための取り組み
発表者：株式会社SmartHR 平田さん
発表資料：https://speakerdeck.com/tarappo/sukeruatupuqi-ye-noqazu-zhi-nobariyuwozui-da-xian-niyin-kichu-sutamenoqu-rizu-mi
品質保証部のQAマネージャーが、QAの「バリュー最大化」に向けた土台づくりに取り組んだ話でした。現状把握からスタートし、トップダウンで素早く行動しながら、現場と対話しつつ試行錯誤を重ねている様子が印象的でした。
特に印象に残ったのは「成果を出せる環境の構築」と「成果を伝える仕組みづくり」です。開発チームへのオンボーディングや社内外への発信など、3ヶ月という短期間で成果を見える化したスピードとリーダーシップに驚きました。
ここで重要なのは、成果を出すことと、成果を伝えることは別物だという点です。成果を出しても見えなければ無いものとされてしまいます。だからこそ、社内外へ向けた発信で活動を見える化することが、評価につながるのだと感じました。
自分の現場を振り返ると、テストや改善の活動は成果が見えづらい場面も多く、どう伝えるかが今後の課題だと感じます。今後は個別最適にとどまらず、チーム全体の最適を測る目標を設定し、成果を発信することを意識して取り組んでいきたいです。
なぜ人はE2E自動テストの継続に失敗するのか
発表者：LINEヤフー株式会社 大園さん
発表資料：https://speakerdeck.com/o3/jasst-tokyo-25-ozono
10年前と比べるとE2E自動化テストの導入障壁が下がったけど、継続できなかったと聞く数は変わらないのはなぜだろうという疑問から、継続できない要因や継続が成功した要因を自身の経験から共有してもらいました。
特に印象的だったのは、「なぜE2Eをやっているのか？」「なぜそのタイミングで実行しているのか？」という問いです。
この「なぜ？」が曖昧なまま積み重なると、テストの結果に対する信頼が揺らぎ、やがて結果を見るのが怖くなっていきます。自分自身も同じ経験をしており、耳が痛い話でした。
ここで改めて感じたのは、E2Eテストは技術よりも、目的と位置づけをチームで明確にすることが肝心だということです。
「何を保証したいのか」「どの意思決定を支えるのか」が不明確なままでは、形骸化してしまいます。
なので単に「動作確認用にE2Eを回す」のではなく、どのリスクをカバーするためのテストなのかをチーム全員で合意形成し続けることが重要だと思います。さらに、運用コストに見合った価値を発揮しているかを定期的に見直すことで、形だけの運用に陥らずに済むのではと思いました。
チーム内連携強化のためのGQMフレームワークに基づいた不具合情報可視化の取り組み
発表者：株式会社ZENKIGEN 横田さん
発表資料：https://www.docswell.com/s/masataka-yokota/ZMXR1J-jasst-gqm
不具合の情報がチーム内で共有されず、意思決定や優先度判断が属人的になっていたという課題に対し、「GQM（Goal/Question/Metrics）」というフレームワークを導入した事例を紹介してもらいました。
具体的には、まずチームで何を達成したいか（Goal）を決め、それに対する質問（Question）を設け、その答えを導くための指標（Metrics）を定義します。その上で、起票者・入力タイミング・収集方法を明確にし、Notionでダッシュボード化して日々のMTGや振り返りで活用しているとのことでした。
GQMの良い点は、データを集めること自体が目的ではなく、「何を知りたいからそのデータを集めるのか」を明確に決められることだと思います。
Goalが明確にあることで、役に立たないデータの収集に不毛な工数を費やすことを避けられ、納得感を持って開発を進めることができます。
自分の現場でも、不具合起票の粒度や記載内容にばらつきがあり、後から分析しにくいと感じることがあります。
今回の話を聞いて、起票ルールと指標を「何を知りたいのか」というGoalから逆算して決めることが、チームの共通理解を作り、情報を形式知化する大切な一歩になると学びました。
全体を通して
継続的なコミュニケーションや連携をするためには、「指標を定義することの重要性」「見える化する努力」「定期的な振り返りと発信」など、当たり前のようですが、やり抜く忍耐と勇気が求められることだなと感じました。
また、QAエンジニア、テストエンジニアが求められる範囲が広くなっているなと感じ、普段行っているテストだけでなく、開発全体のプロセスに対して、課題意識を持つ・言語化する・仕組みにすることは、どれもスキルアップしていく必要があると再認識できました。
JaSST Tokyo への参加は初めてでしたが、似たような課題に立ち向かっているなと感じ、とても励まされました。特に「現状を把握し、課題を全員で解決する」姿勢が印象的で、自身もその姿勢でチームに還元していきたいと思いました。
来年はなんと東京ビッグサイトで行われるそうなので、来年がすでに楽しみです！
Views: 0
