JaSST’25 TOKYO 参加レポート

こんにちは。hacomono QA部です。
今年も JaSST’25 TOKYO に参加しました。
JaSST（ジャスト）は、NPO法人ASTER （ソフトウェアテスト技術振興協会）が運営する
ソフトウェア業界全体のテスト技術力の向上と普及を目指すソフトウェアテストシンポジウムです。※JaSST：Japan Symposium on Software Testing

開催は2日間にわたり、現地とオンラインのハイブリッド形式で実施されました。現地会場ではワークショップが開催されました。専用のDiscordサーバーも用意され、参加者同士がセッションの理解に役立つURLの共有や意見交換を活発に行っていました。

今回は、現地またはオンラインで参加したhacomonoQA部の各メンバーから、参加レポートを共有いたします。

スケールアップ企業のQA組織のバリューを最大限に引き出すための取り組み

▼ tackey（滝田）
hacomono QA部は社員数が7名いるものの組織体制としては、成長過程にあると考えています。まさにスケールアップ企業がどのような取り組みをしているのか知りたかったため、ぴったりのセッションでした。
仕組みとして、「メンバーが成果を出す」「メンバーの成果を評価する」「メンバーの成果を周囲に知ってもらう」といったことを実現していると理解しました。
QA業務が多岐に渡るため評価自体がそれを制限するような内容になっていない点は、多くのQAエンジニアにとって納得のいく仕組みです。
等級要件については、Goodな具体例をあげつつNGの例も明記することで認識齟齬を生み出さない状態を作れていると感じました。
全体を通して、私自身の現状に合うような取り組みをなされているとも感じ、非常にイメージしやすく参考になるセッションでした。

Agile TPIを活用した品質改善事例

▼ tackey（滝田）
Agile TPI自体について私が知識を持っておらず、単純な興味からセッションを拝聴しました。
AIを活用してテストを行なっている点が印象的でした。
仕様書やテストドキュメントなど、テストをする上で必要なデータをAIに読み取らせることで、プロダクトバックログアイテムからどの機能に影響があるかをAIが判断してくれる。それを元にテストパターンを組む。という内容になっており、非常に興味を惹かれました。
リグレッションテストの改善を行い、落ちないスモークテストが完成した話などは自身も課題としている内容となっており、参考になりました。
セッションの中でAI活用の苦労など細かな情報も含めて発表していただいており、hacomonoでも実践しようと思える内容となっていました。

リーダブルテストコード〜メンテナンスしやすいテストコードを作成する方法を考える〜

▼ tackey（滝田）
「リーダブルテストコード」とはどういうものだろうという興味からセッションを拝聴しました。
テスト対象の仕組みなどが起因する課題内在性負荷が高いことは仕方ない。しかし、課題外在性負荷は下げる必要がある。という話がありました。認知負荷の低減を図るに当たってとても理解しやすい説明でした。
E2Eテストは手続き的になりやすいため、コンテキストを明示するとコメントの必要性が下がる。
これについて私は意識できていなかったと思います。コードが自己説明的になればコメントをせずに理解しやすくなるということは非常に効果的だと感じました。
テストの意図を考えた上でそれを明記しておくことで、理解しやすく説明も容易になる。これによりテストコードの修正性もあがる。
テストの意図については、考え込まれていなかったり曖昧にしてしまうことが私自身にあります。これを解消するための書き方について学べたと感じました。
読みやすいテストコードの書き方、それを書くための考え方や具体例について非常に参考になるセッションでした。実際に私が実装するときやPRレビュー時に気になっていた点ではありつつも、言語化できていなかった部分について聞くことができ、すぐに活かせる情報だと感じました。

ソフトウェアがJISマーク認証される時代に～標準化がもたらすソフトウェア品質の確保や市場への信頼性向上〜

▼ Piro-chan（廣田）
JISという品質規格の存在は知っていましたが、ソフトウェアでJIS規格に認定されているのは2つしかなく、新たな取り組みであるということは初めて知りました。
品質という、常に形を変え続ける曖昧な概念に対し、どのような基準を設けるべきかは難しい問いだと思います。JIS規格を実際に取得したウイングアーク1st社の事例についてセッションで触れられていましたが、テストレベルに対しテストタイプをマッピングし、品質特性ごとにゴールを定義していると話されており、抜け目なくよく考えられていると感銘を受けました。
hacomonoでは明確な品質基準をまだ設けていませんが、今後どうしていくべきか、考えるきっかけになる良いセッションでした。

幅広いシステムが絡む品質保証における難しさと、マトリクス組織を用いた専門性の確立と課題解決

▼ Piro-chan（廣田）
個人的にQA組織論は正解のない難しい問いだと感じていて、最近興味のあるトピックだったので、他社の具体事例が聞ける貴重な機会でした。
組織論でよく話題に上がるマネージャーとエキスパートの分類について、
bitkeyさんでは、前者は将来を思い描き、QAのみならず組織全体の最適化を図る人で、
後者は今と向き合ってたくさんのGoalを達成していく人と定義しているそうで、
時間軸で分けて考えるのは分かりやすいと感じました。
また、カッツモデルという管理職向けのスキルフレームワークをグレード全体に適用している話も興味深かったです。どのグレードでどんな種類のスキルが求められるのか、きっちり言語化できている点が素晴らしいと思いました。
会社によって千差万別な考え方と組織論があると思うので、こういった話をまた社外のQAの方々と意見交換できたら嬉しいです。

テストだけがQAの仕事なの？　～名もなきQAの仕事に名前をつけて、未来をつくれるQAになろう～

▼ Piro-chan（廣田）
オフラインならではの、ワイワイガヤガヤ系ワークショップに参加しました。
内容は読んで字の如く、QAがやっている名もなき仕事を洗い出してみて、そこに共通する軸を考えてみよう、というワークでした。
具体を洗い出してみると、自分のテーブルでは、飲み会の感じやメンバーのケア、JIRAやツールの使い方についてアドバイスするなど、実に様々な種類の仕事が挙がりました。
自分は特に意識したわけではありませんが、出してみるとコミュニケーション周りのタスクばかりを挙げていて、そこには「チームのパフォーマンスを良くする」という一貫したテーマがあることに気付くことができました。
ワークはこんな感じ
※全体はスプレッドシートで進めていましたが、自テーブルは諸事情で付箋で行いました
名前の付いていない仕事にも目的や信念がそこにはあって、どれも大切な仕事なんだと気付けました。色んな会社の方々とおしゃべりしながら、90分あっという間の楽しい時間を過ごせました。

▼ matchan（松田）
テスト設計や実施、スクラムイベントなど、スケジュールに組み込むような仕事の他に自分が行っていることに名前をつけ、それを行う理由やそこから得られる結果がどういったものなのかを掘り下げるワークを行いました。
コミュニケーションの円滑化、自己研鑽、他メンバーの育成など参加者ごとに重視しているものが異なっていて新鮮でした。僕自身はスクラムチームのプロセスまわりに仕事が閉じていたのでもう少し仕事の範囲を広げたいと思いました。
これまで目的が曖昧なまま行っていた仕事に名前とがついたことで、今後はより効果的にそれらの仕事に取り組めるようになったと感じます。

SaaSプロダクト開発におけるバグの早期検出のためのAcceptance testの取り組み

▼ ebi-chan（蛯子）
開発手法や、開発体制がhacomonoと共通している点が多いため共感できる点も多く、すぐに活用できそうなアイデアが紹介されていて参考にありました。
開発者テストレイヤーでのバグ検出にフォーカスされていて、そこで見逃されるバグ（QAのテストで検出されるバグ）にはどのようなものが考えられるのかを具体的な事例をいくつか紹介されていました。
特に印象に残ったのは「開発者が意図的に開発者テストを怠っていない」という言葉で、仕組みで解決すべきであるという点に共感しました。
当初はAcceptance Criteria（受け入れ基準）を設定して開発者テストを実施していたようですが、より具体的なテストケースに落とし込まないと十分な効果が得られなかったようでした。
このあたりは実施者の仕様理解度等によって変わるところかなという所感でした。
結果的にQAがよりスクリプトテスト以外に時間を費やすことができるようになったという点はとても魅力的に関しました。

チーム内連携強化のためのGQMフレームワークに基づいた不具合情報可視化の取り組み

▼ ebi-chan（蛯子）
不具合情報の活用に関して課題感を感じている中で、興味を持ったセッションでした。
GQMフレームワークとは何？？？の状態でしたが、結果的に不具合分析のアプローチの一つとして大変参考になる事例紹介でした。
まず、GQM（Goal/Question/Metric）とは何なのか？というのを身近な例（Goalを「健康を維持するための生活の維持」を設定）を挙げて説明されていたため、理解しやすかったです。
特に参考になったのが、Metricの取得に対する考え方でした。
Goalを設定してから取り組むべきであるというのは意識しているものではあったが、Goalに対するQuestionというレイヤーが入っていることによってよりMetricとして何を取得するべきか？ということがより明確になっていました。
また、取得した情報のダッシュボードによる可視化だけでなく、アンケートなどによる有効性の測定までされていたのが印象的でした。しっかりと振り返ることの重要性も再認識しました。

タイミーQAのリアルな挑戦：DevOps時代の開発生産性と品質文化を創造する

▼ hama（塩濱）
少数精鋭で内製化しているQAチーム（QAコーチとSET）が、開発者と密接に連携し、自律的な品質保証体制を構築することで、開発生産性と品質を両立させる先進的な取り組みについて伺えました。
開発者がテスターの役割を担っていたり、E2Eも実装する文化が根付いていたりと、各開発チームが自律的に品質保証を行っている様子も講演内容から感じることができ、組織全体としてタイトルにもある、品質文化を創造するを体現されているのだろうと思いました。
今後の展望として、品質基準と完成の定義の整備を、SREやPOを含めた関係者との連携によって進めており、特に、CUJ（クリティカルユーザージャーニー）を基盤とした品質基準の策定に力を入れいているとのことだったので、こちらについてもどこかで是非お聞きしたいなと思いました。
hacomono QAチームは現状内製化しているわけではないのですが、自社の状況と照らし合わせながら、どのような状態を目指していくべきなのかを考えるきっかけにもなりました。

大規模プロジェクトにおける品質管理の要点と実践

▼ matchan（松田）
自身の経験してきた案件からは想像がつかない事例のため興味から聴講しました。
第三者検証会社が期間は数年、月の稼働人数が数百から千人規模に及ぶ大規模プロジェクトの品質管理を行う際の要点についての話を聞くことができました。
話の中では、自動テストの早期実装による継続的な品質保証のために開発初期に全インターフェース実装を行うチームを立ち上げる取り組みがプロセス改善として印象に残りました。
開発と並行したE2E自動テストの実装は取り組みたいテーマとして持っていたため、開発プロセス段階のチーム構成からそれに沿ったアプローチを行うことは実践してみたいと思いました。

テストだけでは終わらない！継続的な品質向上を実現するために、事業会社、ツールベンダー、第三者検証の3社が考えるアプローチとは？

▼ matchan（松田）
事業者と第三者検証の両視点からのお話が聞けることに興味を持ち参加しました。
登壇されていた事業会社ではQAには品質活動についての自走、品質文化の醸成を期待している一方で現状任せているタスクは自動テストの実行やメンテナンスといったテストフェーズに留まっていました。
一方で参画している第三者検証の方からは品質保証活動にも取り組みたい旨が語られ、そのギャップが印象的でした。品質保証の役割を求められれば動きやすいとも語っていたため、互いの求める役割は共有し合うこと意識したいと思いました。

ソフトウェア保守性向上のためのユニットテストカバレッジの有効性評価

▼ matchan（松田）
論文事例ということでQAの活動に関する研究に触れたことがなかったためその考え方やアプローチを知りたくて参加しました。
研究の目的はプロダクトの保守性を評価するメトリクスとして妥当なデータを得ること。コードカバレッジがそのメトリクスになりうると仮説を立て、保守性の指標であるサービス復元時間との相関を求める研究でした。
仮定を証明する結果は得られていませんでしたが、データの分析からサービス復元時間のデータが障害発生タイミングや復旧手法によりグループ分けできることが判明しているなど副産物的な学びを得られていました。
品質のメトリクスを得るために仮説・検証のサイクルを回すという発想がなかったため今後のための新しい気づきとなったセッションでした。

ソフトウェアテスト最初の一歩〜テスト設計技法をワークで体験しながら学ぶ〜

▼ matchan（松田）
オフラインで参加したため現地での交流と、テスト設計技法の基礎をおさらいする意図で参加しました。
同値分割、境界値分析、デシジョンテーブルについて5名の組で実際に技法を使ってテスト分析を行うワークを行いました。
テスト対象に意図的に曖昧さを持たせることで各自の分析結果に幅が出るようになっており、思い付けなかったような同値分割の分け方があったりと発見がありました。また、デシジョンテーブルは作成後に他の人へ共有することが必要（レビュー、テスト方針の説明など）とあり、自身で完結して使うことがあったため反省しました。
また、一緒にワークを行った方に2名開発エンジニアの方がおり、QA以外の方の参加から品質保証への関心の高まりを感じることができました。

オフライン参加の感想

▼ Piro-chan（廣田）
今年は会場が去年よりも広く、設備も整っていて驚きました。
オフラインの良いところはやはり他の参加者やブースの方々とお話できるところです。
ワークショップも楽しめましたし、ブースも巡ってノベルティをゲットできました。
それから、テスコンの成果物の展示も面白く見させていただきました。
まだまだ自分の知らないことが多く、身が引き締まりました。

▼ hama（塩濱）
会場広い！というのが第一印象でした。
スポンサーブースもずらっと並んでおり、お祭り感があり、入り口からとてもワクワクしました。
各ブースの方々と実際にお話しができる点が、オフラインの魅力でもありますね。
沢山ノベルティもいただきました。
運営の方々、今年もありがとうございました。来年も今から楽しみです。

▼ matchan（松田）
初めてのオフライン参加でしたが人の多さに驚きました。ソフトウェアテストに関わる、関心がある方々が一堂に会する場の熱気を感じいっそうセッションに身が入りました。
出展しているブースもミニセッションやアンケートなど参加者の学びとなるような取り組みをされているところも多く楽しく見て回ることができました。
それぞれのセッション会場間の移動はスムーズで、休憩時間にブースを見て回る余裕もあり2日間通して快適に参加できました。
次回もオフラインで参加したいです！

▼ モーリー（森島）
昨年に引き続き現地へ行きました！ビルの外観から今回の会場のすごさが伝わるでしょうか！？
昨今はQAエンジニアの採用激化や単価高騰などがありましたが、ソフトウェアテストに対する関心の高さが年々高まっていそうです。

前回よりもスケールアップした会場が広いのはもちろん、セッションごとの移動がスムーズでとても参加しやすかったです。（写真で伝わりづらいですが）スポンサーブース会場も横に広く、開放感にあふれていて、セッションの合間は人で賑わっていました！とても綺麗な会場でした。

いくつかのブースでお話しさせていただきました、お話しいただきありがとうございます🙏
素敵なブースのお写真を撮らせていただいたので、いくつか掲載しておきます。
Findyさんのブースでは、質問に答えてガチャガチャをしてお守りのノベルティをゲットしました！ブースでのAIに関する質問や興味・関心にAIがあることが多い、セッションでもAIを絡めているお話しがいくつかあったのが印象的でした、世はまさにAIブーム！

Cybozuさんでスキルアップに関する質問に答えてメガネ拭きをいただきました！自分はAIと回答しましたが、他の方の回答にもAIがあり関心の高さが伺えました。（勉強になる）

スポンサーブースでお話ししていただいた方々にはお礼を申し上げます！
別のイベントでお会いした方とお話しできたりして、改めてイベント規模の大きさとオンサイトで開催される意義を感じました。
来年もぜひ参加したいので、東京ビックサイト開催を楽しみにしております。