はじめに
ヤプリQAの日沢です。
去年の続き、今年もヤプリQAたちがJaSST '25 Tokyoに行ってきました！ ちなみに去年のブログはこちらです。
JaSST24 Tokyoに参加しました！ - Yappli Tech Blog
今回は山口、今西、私の3名で参加してきました！ チケット完売でオンライン参加となった去年の学びから、動き出しを早めて3名ともオフラインでの参加となりました！ 各々が参加したセッションの感想や学び、気づきを紹介できればと思いますので、ぜひ最後までご覧ください。
JaSSTとは
「JaSST」とは全国各地で開催されるソフトウェア業界全体のテスト技術力向上と普及を目指したカンファレンスです。
詳細はJaSSTホームページをご確認ください。
当日の様子
私は今回が初参加だったのですが、とにかく会場の熱量がすごかったです！
昨年同様、今年もDiscordによるコミュニケーションもあり、各セッションごとのテキストチャンネルが非常に盛り上がってました！ セッション終了後にもDiscord上で質疑応答が続けられたり、セッションの内容について議論が繰り広げられたりと、双方向の対話が成立していました。
また、スポンサーブースも賑わっていて、各社いろんな工夫やPR、ミニイベント等があり、セッション間も常に情報を発信できる / 得られる環境がそこにはありました。
個人的に印象的だったのは、セッション間で行える5〜10分程度のミニセッションです。 ブース前の直接話せる距離でのセッションなので、質疑応答はもちろん、ちょっとした感想を直接伝えることができ、こちらの雰囲気も個人的には好きでした。
参加メンバーから
日沢
私は今回、Agile関連のセッションを中心に見てきました。 QAとしてプロセス改善も取り組んでいきたいと思っているので、そのためのヒントや気づきが欲しかったからです。
その中で、こちらのセッションの話をさせていただきます。
Agile TPIを活用した品質改善事例
こちらは株式会社ヒューマンクレストの浅黄 友隆さんによるセッションでした。 Agile TPI というソフトウェアテストのアセスメントモデルを導入し、プロセス改善から品質向上を行なった事例の紹介でした。
Agile TPIとは
Sogeti社が提供するテスト改善フレームワーク（TPI NEXT®）の Agile版で、テストプロセスの課題を分類、分析し、計画的に対処していくフレームワークです。
詳細なガイドラインはこちらをご参照ください。
感じたこと
自分の経験がベースになるので、もしかしたら同じセッションを受けた方、上記の資料を読んだ方と感じ方が違ってくる部分もあるかと思いますが、そこは個性と思っていただけると幸いです。
セッションの中で私が汲み取ったキーワードとしては、「課題の明確化」「進捗の見える化」「チームで改善」の3つで、チーム全体で品質への意識を高める必要性を強く感じました。
まず「課題の明確化」について、下記の要素の掛け合わせで、現在地を測り、何をすべきか、を順序立てて整理ができるという点です。
キーエリア：異なるアクティビティと観点をグルーピングし、16に分けたエリア
カテゴリ：成熟度レベルを分けるもので、個人、チーム、組織またはPJの3つのレベルに分類する要素
チェックポイント：キーエリアとカテゴリを掛け合わせたもので、それぞれにチェックすべきポイントが設定されている
クラスタ：各チェックポイントの優先度
そして「進捗の見える化」は、チェックポイントが YES / NO の2択で管理されていることで、実施者が進捗をシンプルに理解、管理でき、モチベーションの維持も可能という点です。 進んでいるのかわからないと、やっていて迷いが生じたりするのはよくわかります。
最後の「チームで改善」は、明確になった課題に対して、各自のポジションに関わらずみんなで対応していくという点です。 「カテゴリ」で分けられているように、それぞれのポジションの課題をチームで共有管理することで、みんなで改善していくという意識を持つことができ、成果を共有することでチームや組織として上のレベルを目指すことができると感じました。
品質改善で大切なことは、点ではなく線で対応し、状況を明確にして共有すること、文字に起こすと当然のように見えたりもしますが、実践は難しいです。 Agile TPIは、現在の課題を浮き彫りにし、優先度をつけて、チームで対応していく、そのフローが体系的に成されているフレームワークで、非常に合理的でした。
今すぐヨーイドン！とはいかないまでも、チャンスを見てヤプリでも試してみたいと思います。
山口
私は昨年度に引き続きJaSST参加で、今年はオフラインでの参加が叶い現地に行ってきました。 Discordチャットが存在していたため、オンラインでも楽しめる形でしたがやはり現地へ行ってみると、会場ならではの熱量や登壇者の緊張感、スポンサーブースの盛り上がりなどを肌で感じより高いモチベーションを維持したまま楽しく過ごせたのが印象的です。
さて、そんな中今年も目白押しのセッションが山ほどあり、時間の許す限りたくさんのセッションを聴講してきました。 私は「品質基準」「現場でのQAが実施するテストについて」を2軸でピックアップしたいと思います。
「保証するための品質基準」がQAには必要か？
1日目の最終セッションとなったこちらについては、QAにおける「品質保証」について、そもそも「保証」をしている「品質」とは何か、そしてその「基準」を設定するためにどう整理していいかについてディスカッションをされていました。
弊社ヤプリでも普段リリース対象の機能に対して結合およびリグレッションテストを行い、クリアした後にリリースへと進行していきます。 しかし、品質を「ユーザーに提供する価値」と捉えた場合、最終的なリグレッションケースをクリアしたことでその約束事を守れているのかには、ユーザーが求めている価値と必ずしも合致するものなんかというのははっきりイエスと答えるのは難しいのかもと思いました。
価値をユーザーに提供するための約束事（最低限守るべき基準）を明確に設けるために、もっと提供したい価値が何なのか今一度考える必要があると改めて思いました。
そんな曖昧で定義するのが難しい基準についての考え方として、ソフトウェアの価値を機能単位で切り出してマッピングしていく手法をセッション内でご紹介されていました。 定義をする際にまずプロダクト単位で考えることが多いですが、弊社もyappliの提供する機能はいくつも存在する中で機能単位で「製品性↔︎アート性」「変更容易性↔︎変更困難」の四軸で考えるのは新たな発見でしたし、相性が良さそうだったのでさっそく考えてみようと思います。
現場からお届けします 〜モバイルアプリテストにおける工夫と挑戦〜
2日目はこちらのセッションに注目しました。 先ほどの品質基準といった広い概念からは視点を変え、こちらは日々QA（もしくは開発エンジニア）が現場で行なっているリリース管理、リリースのためのリグレッションテストに対してモバイルアプリを扱う3社様が現場目線でのディスカッションは、一番共感性が高く現場での熱も感じやすいセッションだったと思います。 日々進化し、多様化していくモバイルアプリの開発と短期間でのリリース速度に、QAとしてどう立ち向かっていくかを各社工夫をこらしていました。 弊社でも膨大なリグレッションテストに対して基準を決めいかに選定していくのか、非常に近しい悩みを抱えている状態だったので印象的です。
また、モバイルアプリは検証時に実機端末を何台も抱えてテストをしていくので、各端末での比重に違いが出てくるのは興味深かったです。 リグレッションにE2E自動化テストもありましたが、自動化ケースを流すタイミングに違いがあったり、ケース優先度の判定にビジネス視点を加味する点も学びになりました。
弊社でも昨年のテックカンファレンスでリグレッションケースの削減に向けた施策について発表しましたが、各社QA間で同一のテーマでの情報交換会でも実施したら面白そうだなと、一つやってみたい取り組みも見えてきた気がします。
今西
JaSST'25 Tokyoではこれまでの経験業務を踏まえて「E2Eテスト自動化」「QA領域におけるAI利用可能性」この2つを中心にセッションを公聴しました。 様々なセッションを通じて、以下2点が今後のQA業務遂行の上で求められていると実感しました。
E2Eテスト自動化の目的を常に考えて軌道修正すること
QAに求められている品質基準を十分に理解すること
"E2Eテスト自動化の目的を常に考えて軌道修正すること"について
ここ10年間でE2Eテスト自動化(ここでは便宜的に結合テストよりも先のテストフェーズと定義)の成功事例のオープン化やツール充実の背景もあり、導入ハードルが低くなってきています。しかし、いざ導入をしてみたもののうまく運用に乗らずメンテナンスコストが増えたという声をよく耳にします。
なぜ運用の段階で躓くのか？それは「E2Eテスト自動化の目的が定まっていないから」に尽きると個人的には考えています。E2Eテストを個々のテストケース粒度まで細分化して見た際に、このテストケースはこの目的でE2Eテスト自動化対象にしていると全てに対して言えるでしょうか？ここを曖昧なままにしておくと、E2Eテスト実行時間長期化や不要なメンテナンスコスト増加を招く一因になり得ます。 そういったことを未然に防ぐためにも、ツール選定や運用設計、あるいはテストスコープ策定の段階でE2Eテスト自動化の目的に都度都度立ち返り軌道修正することが重要だと感じました。
(公募セッション「なぜ人はE2E自動テストの継続に失敗するのか」参考)
"QAに求められている品質基準を十分に理解すること"について
ここ1-2年で仕事にもAIが利用できるレベルまでに浸透してきました。AIと言っても様々な分類が存在しますが、とりわけ私たちビジネスマンが使うAIは主にLLMに分類されます(Chat GPT, Claude, Geminiなど)。
LLMは端的にいうと、インターネット上の大量のテキストデータを使って学習し、人間の質問に対する最もらしい単語を繋ぎ合わせて回答を作成しています。 つまり、LLMに何かしら指示を出していくら良さそうな回答が返ってきたとしても、その回答が事実であるかどうかまでは分からないのです。
これからの時代、LLM含むAIは加速度的に人間の複雑な業務プロセスの中により深く入り込んでくることが容易に想定されます。当然ながら、その中にQA業務も含まれています。数年後にはおそらく各種必要なドキュメントを学習させてテストケースを網羅的に作ってもらう(さらに言えば実行まで)ところまでできると考えています。
仕様書を元に作らせたから見なくて大丈夫とするのではなく、これまで以上に求められている品質基準を満たす内容になっているかの確認を怠らないことが重要になってくると実感しました。
(公募セッション「AIによるソフトウェア品質保証の現在地点とこれから」参考)
最後に
今回のJaSST'25 東京 の中で中心にいたのはやはり「AI」「自動化」「アジャイル」だったように思います。 「AI」「自動化」は非常に有効なツールなのは疑いようがありません。 ただ、今西も言っている通り、「人」がしっかり関わっていかないと、大きな間違いも起こしかねないので、いかに知識をつけて、有効に利用できるかが鍵になってきます。 とはいえ臆することなく、その波に乗り遅れないようにしたいと思いました。
今回のJaSST'25 東京で受けた気づきが書き足りないので、ブログ第二弾も近々アップします！ よかったらそちらも読んでいただけると嬉しいです！
そして！早くも次回のJaSST'26 東京の話もありました！ 次回はなんと東京ビッグサイト！ 今からワクワクが止まりません！
2026/3/20 （金祝）
東京ビッグサイト
最後まで読んでいただき、ありがとうございました！
※この記事はJaSST'25 Tokyo に参加した際の個人的な感想と学びをまとめたものです。公式情報や他の参加者の意見とは異なる場合がありますので、ご了承ください。
PR
ヤプリはカンファレンス参加など、エンジニアのキャリア支援を積極的に取り組んでいる会社です。 QAチームとしても今後、外部イベントの参加レポートや、内部取り組みの発信などをしていきます。 ヤプリQAの品質改善活動や社内の様子などが知りたい！興味がある！という方は、ラウンジカフェもあるのでお気軽にお越しください。
