構築中。

名古屋のITインフラお守り係です。ITイベントへの参加記録などを残していきます。

JaSST'25 Tokyo 初日のみ現地参加(3/27+オンライン 3/28)

昨年は完全にオンライン参加だったのですが、今年は初日のみ現地参加してきました。

jasst.jp

なぜ JaSST へ?

「QA は担当していないのになぜ JaSST へ?」ということですが、

  • かつて、自社のテスト手法は完全我流で、テスト仕様書に「◯◯が正しいこと」が列挙されるような状態だった
    • いまも基本的な状況は変わっていないけど
  • 「少なくともユニットテストぐらいはコード化して書こうよ」という活動を数年前に始め、最初にサンプルコードを書きつつあれこれと言い出したのが私だった
  • そして現在、少しずつプロダクトにテストコードが実装されるようになってきた
  • そうすると「テスト(コードも一般的な手法も)に対する知見のなさ」を段々と知覚するようになってきた
    • けれど、JaSST に誘っても誰も現地に来ない
    • かろうじて QA を兼務しているチームのトップが(今年初めて)社内でリモート参加を決めた

というわけで、一人寂しく(?)完全アウェイの中、東京までやってきました。

(場所的には、いつも参加している PostgreSQL Conference Japan の会場の近所だったので迷うことはなかったのですが)

普段参加しているコミュニティとはほぼ参加者層が被らないので、

  • 登壇者の中で知っている名前は t_wada さんとブロッコリー(風間)さんと Autify の松浦さん、そして一部のサイボウズ勢ぐらい
  • ついでに初日の現地参加者の中に知っている顔がほとんどなし
    • 一部対面したことがない X の FF さんが参加されている気配だけはある(?)

という状況。

昨年の 11 月に迷惑メール対策カンファレンス(JPAAWG)に参加したとき以来の完全アウェイでした。

(たまにコンフォートゾーンを抜け出して完全アウェイの世界に踏み出すのも良いかと?)

現地に向かう前に

通院日だったのですが診察が少し早めに終わったので。

病院のそばの某公園(名古屋の桜の名所)で花見をしてきました。

(当日のソメイヨシノは咲き始めぐらいでしたが、これを書いている時点ではもう満開らしいです)

東京へ~会場着

基調講演を聞きながら新幹線で東京にやってきました。

前述のとおり、よく来ている場所の近くだったので迷いませんでしたが、見慣れないビルでの開催でした。

(後でクロージングのときに「ビルが建つ前に会場を予約した」という話をされていましたが、建ったばかりの新築ビルでした)

初日セッション参加

C2-1)JSTQB は今年で 20 周年、これからもソフトウェアテスト技術の発展に向け活動します

シラバスの翻訳(日本語訳)の話が出ていましたが、これからは機械翻訳が AI 化によって以前より自然な文章になってくることが予想されるので、キーワードのブレなどの調整以外は機械(AI)の力を借りることになるんだろうな…と思いながら聞いていました。

なお、最初から最後まで認定テストの略称を聞いてもチンプンカンプンでしたが、とりあえず帰ってきてから JSTQB Foundation Level の参考書籍を買ったので読むことにしました。

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

www.docswell.com

登壇者の熱量がすごくて、

参加者の反応も活発だったのが印象的でした。

個人的には組織にこれだけ変化を加えると(たとえ会社や組織の歴史が浅く社員の平均在籍年数が短くても)抵抗する人たちが出てきそうな気がするのですが、そういう話はなさそうでしたね。

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

他の参加者の方から「会場が重々しい」というポストがありましたが、わたし自身も何をつぶやいて良いかわからず(迷って)、この時間帯のポストはゼロでした(そして睡眠不足ゆえ、セッション後半から頭痛が…)。

(なお、情報交換会では KINTO テクノロジーズのみなさんがいらっしゃるテーブルにお邪魔しましたが、後ろで参加者のお子様がトヨタのミニカーで遊ぶ光景を見つつ(?)温かい雰囲気でおしゃべりができたことを念のためお知らせしておきます)

D4-1)ソフトウェア保守性向上のためのユニットテストカバレッジの有効性評価 ※論文事例

内容的に外部公開 NG でした。

タイトルに「論文事例」とありますが、JaSST の CfP には IT カンファレンスで一般的な通常の発表以外にも論文の募集があるところが面白いですね。

jasst.jp

D4-2)手動 × ローコード × コードベース:3 つのアプローチをつなぐ実践

speakerdeck.com

自社の事業と近いドメインの事業が中心になりましたね。

なお、タイトルに「手動」とありますが手動テストについては「出発点が手動テストだった」という言及程度で、手動テストのやり方を工夫したとかローコードテストなどとどのように組み合わせたか?などの話は特段なかったように記憶しています(手動オンリー→ローコードとの組み合わせ→さらに一部をコードベースに移行)。

ローコードテストは実装が楽な反面、うまく使える状態にメンテナンスしていくのが大変で実行にもコストが掛かるので、(全てのテストが対象ではないけれど)実行の確実性とコスト抑制を求めてコードベースに移行していく、という流れは参考になりました。

D5-1)開発者主導の自動テスト導入によるバグ早期発見

www.slideshare.net

ユニットテストは対象のスコープが小さく、仕様を勘違いして実装した場合にそれに気づくのが遅れる…ということで、Acceptance Criteria と Acceptance Test を「シフトレフト」で早めに実施してその部分を「解決」する、というお話でした。

それぞれを直訳すると「受け入れ基準」「受け入れテスト」であり、これは受託のウォーターフォール開発では納品を受けるユーザー側主体で行うもののはずですが、一方で自社サービス向けのアジャイル開発の文脈ではプロダクトオーナーやプロダクト開発チームが主体になって行うはずなので、

という戸惑いが。

speakerdeck.com

こちらのセッションでもそれぞれについての言及がありますが、本来は Acceptance Criteria と Acceptance Test は直接的に「対」になるものではない(前者はアジャイル文脈、後者はテスト文脈?)ので、ちょっと混乱しました。

取り組み自体は同意しつつ、一方でユニットテストより前に実施するテストを「Acceptance Test」と呼ぶのはどうなんだろう?(別の名前のほうが良いのでは?)という気もしました。

D5-2)銀行におけるスマートフォン実機でのテスト自動化について

「物理」が絡む(そして対象がたくさん)と気が重くなりますね。

(すっかりクラウドに慣れきってしまった私)

一体、何台の端末を用意してテストするのでしょうか?

(予備機も必要そうですし)

そういえば、JR 東日本グループの JRE BANK が話題になりましたね。

あちらは楽天銀行OEM でしたね。

それぞれのブランドに合わせてカスタマイズする部分が、プロダクトの実装もテストの実装・実行ともに大変そうな印象です。

(使用端末のバリエーションと「掛け算」すると実装・テストのパターンが爆発しそう)

ブースめぐり

セッション間の休憩時間がそれぞれ 30 分ずつあったので、いくつかブースを回ることができました。

情報交換会

最初は(先に触れたとおり)一番端の KINTO テクノロジーズの皆さんのところに混ぜてもらい、その後 Findy ブース→ Autify ブースでお喋りしていました。

なお、催しとして書籍の抽選をやっていることに途中まで気づいていなかったので、もしかしたら「番号を呼ばれたけどスルーしてしまっていた」かもしれません。

帰路

そのまま新幹線に乗って帰りました。

新幹線の中で PostgreSQL アンカンファレンスを聞く予定だったのが、JaSST の余韻に浸っているうちに半分時間が過ぎてしまっていました。

2 日目セッション参加(オンライン)

というわけで、X へのポストは少なめです。

集中して話を聞けたわけではないので、後日アーカイブで復習することになりそうです。

B6)AI によるソフトウェア品質保証の現在地点とこれから

テストケースの自動生成に合わせて「テスト DB のデータもよしなに作ってくれるようになると良いな」という話などをしました。

将来なくなりそうな(別の手法で解決できそうな)課題だからといって「いま」の時点で直面しているのであれば「いま」に合った手法で解決するサービスを提供する、という判断は大事ですよね。

AI の進歩によって人間が向き合う「具体」と「抽象」のラインが変化してきそうだな、と思ったり。

以下は仕事をしながら「ながら聞き」だったので X へのポストなし

  • C8-1)タイミー QA のリアルな挑戦:DevOps 時代の開発生産性と品質文化を創造する
  • C8-2)コドモンの QA の今までとこれから - XP による成長と見えてきた課題 -

speakerdeck.com

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

A10)「真の学び」が未来を拓く~成長するエンジニアのマインドセット

この時間帯は参加するかどうか迷ったのですが、参加して正解でした。

なお、Discord でわいわいしていたので X へのポストは少なめです。

ちなみに長野・松代の「象山記念館」ほかの訪問記(?)はこちら↓です。

hmatsu47.hatenablog.com

クロージング

ASTER(ソフトウェアテスト技術振興会)による「善吾賞」の表彰がありました。

www.aster.or.jp

これを書いている時点では 2025 年の記載はありませんが、REST API の仕様を AI で読み込むことで API のバグの自動修正を行う研究の論文が表彰されていました。

表彰に続いて、次回(来年)の JaSST Tokyo の開催日程と場所の話に。

来年は 2026/3/20(金・祝)の 1 Day 開催、場所は東京ビッグサイト(の会議室)、とのことでした。

(何年か前には東京ビッグサイトで開催できなかったときのリベンジ回(?)らしいです。なお人気の会場ゆえ 1 日しか会期が取れなかったとのことです)

参加してみての感想

初日、現地に行ってみて早い段階で感じたのが

  • 予備知識ほぼゼロで参加するのはもったいないな

でした。

昨年は仕事をしながらリモートで聞いていただけだったのでそこまで感じなかったのですが、真剣に聞こうとすると「いま何の話をしているのか?」キーワードから文脈がすぐに想起できないことがしばしば。

会場でも Discord を見ながら参加していましたが、ほぼ常に Discord の流れから半分取り残されていました。

このあたり、来年東京ビッグサイトで参加するときには「改善」した状態で参加したいです。