JaSST'25 Tokyo １日目 に行ってきました。
初JaSST現地参加嬉しい！
イベントの概要
2024年のソフトウェアテストシンポジウム（JaSST）東京は2019年ぶりの現地開催ありでの開催とさせていただきました。
運営開催にあたって大きな問題等は発生せず、現地およびオンラインにて無事開催できたことをあらためて御礼申し上げます。2025年も引き続きJaSST Tokyoを開催させていただきたいと考えております。
JaSST'24 Tokyoの経験を経て、25ではより多くの人が会場に足を運んでもらえるよう努力してまりいますので、引き続きご支援ご協力のほどを何卒よろしくお願いいたします。なお、JaSST'25 Tokyoのテーマは「No Theme」としました。
テーマに縛られることなく実行委員／登壇者／参加者が年に一度のテストのお祭りのように各自思うように楽しみ、気付きを得るシンポジウムになれば幸いです。今回のJaSST'25 Tokyoでは本会前日3月26日に初心者向けワークショップを行うこととしました。
これからも様々な立場の方にテストへの興味・理解をしていただければと思いますので、あわせてご参加検討いただけますようお願いいたします。
引用：
イベント参加の背景
- 自分の品質保証／QAに対する知見・解像度をあげたい。
- 昨年のJaSST Tokai最高でした。
- オフラインでの参加もしたかったためいざ参加…！！
セッションメモ
- オープニングセッション
来年は3/20（金）（祝）東京ビッグサイトでの開催が決定。
JSTQB カンファレンスは2025年は10月10日開催予定。
- How to Predict the Future 未来を予測する方法
James Whittakerさんによる基調講演。
AIの歴史について。
今のAIはブロックチェーン、IoT、クラウドなどの時流のものとして扱われている。
そうではなく、もともとAIがなんであったかを話したい。
AIにはいくつかの重要な要素がある。
①人間の頭から情報が離れた
人間の頭から独立しているべき。
もともとの学習は、経験的学習、ティーチングによる学習があった。
AIの第一ステップは日本の脳から知識を切り離すことであった。
②コンピュータに知識が格納され処理された
人間にとって知識は処理を通して進化させることが重要であった。
機械はそれを実現できなかった。AIの先駆者であるコンピュータはそれを実現した。
コンピュータ自身が情報を読み取り、覚えることができた。
③知識が様々なコンピュータ上に点在させた
クラウドが実現した。AmazonのAWSが加速させた。
この３つを通してAIの基盤ができた。
もともとコンピュータは計算機に過ぎなかった。
機械は人間への置き換えられることを恐れた。
同じようにAIは怖いものと思われている。
ただ、AIには明るい未来もある。
AIはこれまでのソフトウェアとは違う。AI>>TRADITIONAL SOFTWARE。
ソフトウェアは特定の領域の構造に依存している。コーディングが必要。
AIは何かの領域に依存しない。指示無く学習をしていく。
継続的に脳が機能して考えるというプロセスをシミュレーションしようとしている。
AIは情報を吸収してルールを学習していく。今後より高速化していく。
AIはデータから学習をする。データがあることが重要となる。
ヘスルケアなど価値あるデータセットがある企業が貴重となる。
コロナのワクチンはAIの大きな成功となった。
他に法律、教育、マーケティング、エンタメでAIが活躍する時代になる。
結果、人間の役割は縮小していく。
ソフトウェアは人間の仕事を取っていった。
AIはソフトウェアを作る人間の仕事も取っていく。
AIが悪用されることも想定されていく。
仕事がAIにとってかわられた人間はどうなるのか。余暇を楽しめなくなるのか。
政府が持続することができなくなることも考えられる。
結果、仕事がなくなると富がなくなる。富を何で実現するかを考える必要がある。
AIは多くの複雑なものをシンプルにしてくれる。
何かを実現するにあたる障壁を取り除いてくれる。良いことだけ残してくれる。
地球規模の問題で日本でできない問題をAIなら解決できるかも知れない。
人間の脳だけでは解決できなかった解決策も導いてくれる可能性がある。
データ、パートナーシップ、コンピュートの強い企業が勝ち残っていく。
■質疑応答
・探索的テストについて
探索にあたるデータをAIに入れることで、より効果的な探索テストが可能となる。
・生成AIは新しいテスト技法は生まれる？
生成AIはバグを見つけることが得意。
・AIをどうテストはどうする？
無限のIN/OUTに対するテストは現実的ではない。
テストが終わるころにはAIはさらに進化をする。
明確なものをテストするしかない。
最初は観察する。次は他の人がどうしているかを見てみる。
AIに対してはブラックボックスが主軸。
・AIに対する悪意ある利用はどう防げるか
ソフトウェアですら難しい。AIはさらに不透明。
なので実現が難しいと思っている。
・手動テストはAIに置き換わっていくか？
現状では人間は必要。究極的には置き換わっていくと思う。
ただ、人間の経験を通して身に着けた専門性は継続して必要になると思う。
・生成AIのもっともらしい誤りをどう解消していくか
AIに入るモデルによって見分けがつくかも知れないが、
満足のいく答えは無いかもしれない。
■感想
探索的テストに纏わるお話を期待していましたが、AIの話中心でした。
書籍自体少し時間が経ってからの翻訳なので、今の興味関心はAIなのか。
AIの悪意ある利用に対する手立ては今後課題になっていくだろうと想定しました。 -
JSTQBは今年で20周年、これからもソフトウェアテスト技術の発展に向け活動します
JSTQBは今年20周年。2022年にCBT開始。
JSTQBカンファレンスは2021年から開始。
JSTQBのメリット。テストに纏わる共通言語が作れる。
シラバスは無料でダウンロードできる。資格のためじゃなくても学習に利用できる。
JSTQBカンファレンス。
昨年はTMMiエリックさんが登壇。アジャイル、スクラムでの成熟度の判定の仕方に評判があった。
エリックさんの登壇のYoutube公開は次回の開催まで。
■感想
私のFoundationレベル取得は2014年でその時初めてJSTQBの存在を知りました。
それ以来最近まで動向を知らずにいましたが、共通言語の獲得は自分も実感しています。
昨年のカンファレンスはTMMiの活用のセッションのみ確認しましたが興味深かったです。
配信終わる前に観ねば。 - スケールアップ企業のQA組織のバリューを最大限に引き出すための取り組み
SmartHR、人事労務だけでなくタレントマネジメントもある。
各事業領域ごとにユニット（開発チーム）がいる。
プレイイングマネージャーとしてのチーフと複数人のメンバーがいる。
まず何をやるべきかを判断した。
現状把握、結果からの『何をするべきか』『いつするべきか』を判断。
成果を継続的に出し続ける土台作り。
成果が分かる土台、評価、成果が分かる仕組み作りを行った。
・土台
進む先の策定（キャリアラダー、定期確認）
進み方（すりあわせ）
壁を減らす（方針、関係性、予算）
後押し（1on1、プロジェクト化、タレマネ施策）
・評価
軸の明確化・共通認識化。
等級要件の更新タイミング・方針設定。
説明会の開催とミッションのフォードバック。
・成果を知ってもらう仕組み
QAの成果は分かりづらい。
品質保証部、QAについて知ってもらう取り組み。
すべての組織に品質保証部が関わっている訳ではないため、意識的に見える化を意識。
変化のはやいスケールアップ企業において、土台大事。
土台が改善できることも大事。
■感想
emconfの延長線上で刺激を受ける内容でした。
キャリアラダーの確立と、状況に合わせたアップデート。
そして、メンバーのフォローアップ。
自分でできる範疇でも何ができるかを考えたい。 - テストだけでは終わらない！継続的な品質向上を実現するために、事業会社、ツールベンダー、第三者検証の3社が考えるアプローチとは？
■事業会社（KINTOテクノロジーズ）
手動はリソース問題（リソース、属人）、カバレッジ不足（エッジケース）がある。
・リソース問題 ：第三者検証様による支援
・カバレッジ不足：テスト自動化ツールの導入（リグレッションテストメイン）
手動テストにメリット。
対応の柔軟性。フィードバックの速さ。
よって、手動と自動の組み合わせが重要。
自動化により、リソース最適化、テスト効率向上、品質とスピード、プロダクト全体品質向上。
□トークセッション
・QAエンジニアに期待する動き
自走力。開発との交渉。品質に対する文化醸成。
・第三者としての文化の醸成
インプロセスQA。モニタリング含む。
・何を第三者に任せているのか
運用の部分。内製したテストのメンテナンスを任せている。
内製を第三者がすると手の内化できないケースもある。
■MagicPod
自動化のメリット。テスト生産性の向上。開発生産性の向上。
リリースのたびに繰り返し実行する回帰テストを自動化する。
異常系やエッジケースは費用対効果悪い。（単体テストの方が良い）
□トークセッション
・うまく使えている企業、使えていない企業の共通点
毎日テスト回して成功率キープできているかどうかを確認しているか。
（テスト結果を見ていない企業もいる）
CI/CD上で実行することが重要。
・テストピラミッドの意識ができている企業は
網羅的に意識出来ている企業は少ない。
意識が向けやすいのはQAメンバー。ただ、単体テストには距離はある。
今後、知見ノウハウを持ったエンジニアを育てていくのが重要になっていく。
■ポールトゥウィン
もともとはゲーム領域。品質を中心にした支援サービス。
不具合の発見が遅れるほど全体コストが跳ね上がる。
人売りビジネスから、クライアントの開発生産性向上を支援するパートナーに。
自動化は重要な品質の柱。ノーコードスキルの学習している。
第三者検証の今後の価値。品質のソリューション提案。
□トークセッション
・自動化の教育
使い方だけでなくベストプラクティスに対する教育を行っている。
セグメントに分けた学習をしている。
自動化と手動化の棲み分けについても学習していく。
・第三者検証でうまくいくパターン、いかないパターン
QAエンジニアに対する解像度。テスト実行的な役割だと価値発揮はしづらい。
テスト以外にもQA活動ができることが重要。
第三者検証のQAはいろいろなプロダクト／サービスに対する知見がある。
広く見ているがことをポジティブに活かす活躍の仕方もある。
第三者検証でも内部に来てもらって内製開発を進めることは可能。
・テスト自体の品質
プロダクト、プロジェクト理解により各工程におけるテスト観点の見定めに注力している。
事業会社としてもテスト観点に対するレビューも実施している。
■感想
同じ第三者検証の企業に所属する人間として、背中を押してもらえる内容でした。
テスト自動化のメンテナンスの話をはじめ、内製チームに入っていくお話に企業間の信頼関係を感じ、第三者検証だからこその価値観が見えた気がしました。
ポールトゥウィンさんの説明にkintoさんが補足入れるような流れにも企業間の信頼関係を感じ、自分もそういった関係を築いていきたいと改めて思いました。 - ソフトウェア保守性向上のためのユニットテストカバレッジの有効性評価 ※論文事例
SNS等への発信は禁止。
■感想
本編に関係のない範囲での感想です。
研究結果を公表し、第三者の意見をくみ取ることで、新しい探索が始まっていく。
その重要さを実感しました。 - 手動 × ローコード × コードベース：3つのアプローチをつなぐ実践
バクラク事業部の話。
月２回リリース。１リリースにつき３日間テスト。
ＱＡエンジニア中心でテスト。
・ローコード
最初は手動のみでやってたがリグレッションケースの増加に伴い限界が見えてきた。
導入時：良い点→テスト拡充しやすかった。
運用時：良い点→稼働時間に制限がない。悪い点→不安定。実行時間長い。
解消法：不安定さにはピンポイントで対応。時間軸で失敗しているケースを抽出。
・コードベース
導入時：悪い点→作るのが大変。
運用時：良い点→実行時間短縮。コード流用。悪い点→テスト修正の難易度。
解消法：ペアプロ。ナレッジ共有（セルフチェックリスト、GitHub操作、有効サイト）。読書会。AI活用。
・テスト手段の使い分け
コードデザインを書いた。
テスト手段の使い分けの明瞭化。
手動テスト：基本的に探索的テストを実施。自動化できてないスクリプトテスト。
ローコード/E2Eコードベース：リグレッション。コードベースにハードルあるテスト。
APIテスト：リグレッション。API単位の網羅テスト。認証認可など画面を通しては手間のかかるテスト。
■感想
テストアプローチの明瞭化。チームが同じ目線で進めるうえで重要。
今自分の担当している案件も手動がメインになってしまっているので、
長期的にどう保証していくのが良いのかを戦略立てて計画したい。 - 「保証するための品質基準」がQAには必要か？
そもそもの品質保証とは何か？有期的な機能に対する補償ではなさそう。
理想的には品質基準は必要。SLAが品質基準とも言える。
ただ、問題がある。
・そもそもSLAが無い場合がある。
・SLAとQAの役割が繋がっていない場合がある。
ハードウェアとソフトウェアでは文化が違う。
品質基準には、ユーザー価値、法律、企画、認証など色々ありそう。
ハードウェア：製品性⇔アート性、サブスク⇔所有の４象限
ソフトウェア：製品性⇔アート性、変更容易⇔変更困難の４象限
で整理ができそう。
品質はユーザーにとっての価値。
ユーザーに届かないとわからないので、早く出せれば出せた方が吉。
スクラムには完成の定義がある。
色々なタイミングでチェックが可能な運用となっている。
（PBI、スプリント、内部リリース。製品リリースの完成の定義）
完成の定義は、プロセスを対象とするもののため、品質基準ではなく品質の管理基準な気がする。
Production Readiness Checkはモノを見ている。品質基準と言える気がする。
ただ、対象がソフトウェアではなく、ハードウェアである。
なので、それを品質基準と言ってよいかは微妙。
アジャイルソフトウェア開発宣言により品質が置き去りになった気がする。
ソフトウェアは変更容易なため、品質に基準を設ける必要があまりない。
ユーザーに価値が届いた後でフィードバックに合わせたチューニングが容易なため、品質基準という事前に定義したものが不要となる。
■感想
何のための品質か次第で基準の意味が変わると思いました。
最終的には利用ユーザーに届けたい価値のための品質であり、そのための基準であるべきとは思いつつ、事業会社や受託企業など所属する企業や、請負や準委任などプロダクトに対するかかわり方で変わりそうと思いました。
少なくとも、何も考えず品質を捉えるのではなく、目的を考えていたい。
懇親会
QA engineer at a Startup（仮）開催の懇親会に混ぜて頂きました…！
qaengineeratastartup.connpass.com
今までカンファレンスなどでの懇親会は魅力に感じつつ、反面ハードル高く感じて避けていましたが、
いつも配信でいろいろなQAの在り方・取り組みを勉強させて頂いているQaaSの方達が懇親会を開催するとお聞きして行ってきました。
結果、本当に学びの多い時間でした。ありがとうございました。
改めて、配信も登壇も書籍もそうだけど、誰かのアウトプットを受け取るだけでは、
自分自身の文脈に解像度が依存してしまうことを発見。
聞いて話してすりあわせて、初めて分かる・感じることが多いと実感しました。
そして、JaSST Tokaiの好きだったセッションをまた聞けた感じも嬉しかったです。
２次会まで参加させて頂きありがとうございました。
今後の配信も楽しみです！
ブース
自分の新卒で入った企業も協賛しており、ブースでお話しました。
10年以上経ってしまっているから不思議。
自分の頃は開発、ネットワーク、ハードウェアの舞台しかなく、QAはまだなかったため気になっていました。
まだ規模は小さいらしいですが、当時は表向きな発信をする企業とも感じていなかったため応援しています。
まとめ
１日目感想です。
はじめてのJaSST参加。多面的多角的に品質に対して考える１日となりました。
特にSmartHRさんの品質部門の立ち上げてあったり、ポールトゥインさんの第三者検証の内製化の流れに対する取り組みをお聞きできたのが嬉しかったです。
そして、やっぱり誰かと感想も含めて意見を交換することの大事さを痛感。
２日目も学びます。
蛇足
お昼に行ったラーメン屋さん、美味でした。。
