行ってきましたJaSST'25 Tokyo。

A1）How to Predict the Future 未来を予測する方法

保育園に送ってから現地に向かうと間に合わない・・・ということで基調講演だけはオンライン視聴しました。

以前のブログでは

基調講演は基本見る派です。わりとテストコミュニティの話題の方向性や、共通概念が基調講演から出てきたりするので。また、『探索的テストの考え方』の著者でもあるので、本の内容との関連なども気になるところ。

なんて書いていました。が、正直 あまりわからなかった・・・ というのが正直なところです。

最初はTHE AI BRIEFING、ということでAIは最近のものではなくて前からあって、とか、知識を人間の脳から離したところから・・・といった話から始まってふんふんと聞いていました。

そこから、ソフトウェアとAIとの違いは処理なのかデータから何らかを行うものなのかだ、という話やAIによって大きなインパクトがこれから考えられるジャンルのはない、テック企業BIG5のジャンル別勝敗などこれからの話にも若干触れつつ・・・だったのですが、正直講演の方向性や、どういったメッセージに最後着地するのかが迷子なまま終わってしまいました。

いちおう質疑応答の時間に出ていた質問によって、方向性がソフトウェアや品質方面の話に少し引き戻された感じはありました。こういうところで実のある質問できるひと本当にすごい。ブラボー！（CV:長友佑都）

講演概要には

今回の基調講演では、私たちがどのようにこの地点にたどり着いたのか、そしてこれからどこへ向かっていくのかを振り返りながら、未来への備え方を探ります。James Whittakerは、これから訪れる世界で何が起きるのか、そしてそれにどう対応すべきかを語るだけでなく、皆さん自身が未来を予測する方法を学べる特別なセッションをお届けします。

とあったのですが、

  • 未来への備え方
  • 未来を予測する方法

あたりまで話進んだっけ・・・？がよくわかってないです。

↑セッション終わりの本音。こういう講演聞いてちゃんと深くわかるようになりたいし、もしかしたら通訳でなく英語直で聞いたらｽｩ~と理解できるのかもしれない。

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

山口さんが喋りのプロかなと思うスムーズさですごいなと思いました。という小並感感想はさておき、20年続いているというのはすごいですし、また資格をとっている方もかなり多く、自分もいつまでも「FLしかもってませーん」ではアレだなとちょっと焦りました。

自動化シラバス訳したりした身としては自動化試験をもっとたくさんの人に受けてもらえるようになったらいいなぁと思いつつ、確かに今のgTAA->TAA->TASを含めたシラバスの中身に、実業務と絡めたイメージを持ちにくいというのも事実・・・。

そして面白かったのが、日本はJSTQBのパートナープログラムが現在92社登録しているそうで、ISTQBからも「日本てなんでそんなに多いの？」と言われてたりするそうです。日本と海外とでの構造の違いがあるそうですが、こういう違いはドヤっていいポイントな気がしますね。

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

平田さんことTarappoさんの発表でした。

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

シンプルに入社後短期間でこの辺り整えにかかってるのすごいなと思いましたし、逆にそういうことができるからこその「QAマネージャー」なんだろうなと感じました。この手腕間近で見てみたい。

今回の発表では背景として大事なのが「スケールアップ企業」であること、でした。規模拡大と急成長をしている組織において、QA組織として行うことも当然それに合わせた形や進め方が必要、と。とくに土台を整えるにあたって合議制ではなくマネージャーである平田さんが押し進めつつ、周りにわかるように言語化を欠かさなかった、というところは 自分に足りてないのここだわ・・・ と思いながら聞いていました。

私はスケールアップ企業にいるわけではないので、問題ないといえばないのですが、品質関連の色々を整備していくにあたって自分が感じているスピード感の不足は、もしかしたら細かく相談しすぎなのかも・・・と思い当たったので、ちょっと来週から動き方変えてみます。新年度になるし。

C4）なぜ人はE2E自動テストの継続に失敗するのか

大園さんの発表でした。

これがねー・・・ほんとうに良かったんですよね・・・

おもわずツイートしてました。

大園さんが自動テストを始めた10年前くらいを振り返るところからスタートしつつ、今回のSETの定義やE2Eテストの定義など。そしてここ10年でE2Eテスト導入障壁が下がったけれども、運用が続かないという話もよく聞くようになった。 といった状況から、運用面での失敗事例はある程度パターン化できるのでは、と考えたそうです。 そして一方、単体テストやマニュアルテストについては「導入したけど続けられなくてやめちゃいました」という話は聞かない。ということはE2Eテスト特有のなにかがあるはず。

このあたりの問いの立て方がまず良いですよね。

そして、継続できなかった要因・事例4パターンと、継続できた要因・事例サンプル3パターンと発表が続きます。

継続できなかった要因に関しては、おそらくここ10年で大きな変化はないんじゃないかな、と思います。し、発表中でも一部はツール等で解決されている、とおっしゃってました。 なので、継続の失敗要因という話を突き詰めていくと、目新しさはなくこれまで色々な場で語られてきたポイントだったかなと思います。これはネガティブな意味ではなく、こういったかわらない本質みたいな話はJaSSTのような場で繰り返しなされるべき話だと思っているので、今JaSSTで聞く意味のある発表だったなーと感じました。

ただ、それで終わらずに「じゃあうまくいっているところはどうなのか」という話が最後にあって、

  • １．E2Eテスト専属エンジニアポジションを用意する
  • ２．開発チームへの責務の移譲
  • ３．（番外編）役割を上手に分けていた例

を挙げられていました。ここの3ポイントに私は「今っぽさ」を感じて、これまたすごい良い発表で今聞くべきやつだと再度思った次第です。 どういうことかというと、自動テスト失敗要因、的な根本の話はこれまで語られてきた話だったのですが、このうまくいってるパターン例、とくに開発チームへの責務の移譲や、役割を分ける＝開発者がテスト設計や自動テスト実装を行い、QAがテストをレビューするという分担というのが最近のトレンドに合っているなーと感じたからです。とくに普段このブログでも「イネイブリングQAが大事になってるよね」と言っている身としては、2や3の話、そしてこのあと大園さんがおっしゃっていた

これからはEmbeddedから文化の醸成へ

というのがまさにイネイブリングQAの話だと理解しました。

なので自分にグサグサ刺さった発表でした。

A5）「保証するための品質基準」がQAには必要か？

スライド：「保証するための品質基準」がQAには必要か？ https://docs.google.com/presentation/d/13piQ3dyEUziEkQJd1CEi1xq1Flfmr9JPzqT4hTXwbZ4/edit?usp=sharing

ゆもつよメソッドTシャツを着て前列のほうで推し活してきました（）

ちょうど自分も社内で

  • QAは品質保証
  • とはいえ我々のようなWebサービスやってる会社で、とくにtoC向け部分においては「こんな品質であるべし！」を決めて、それを満たしていることを保証する、というのはなじまない
  • なので、決めたライン守れてますかじゃなくて、よりよくするにはどうすべきかを常に考えていこう

という話を入社当時からしていたので、同じような疑問をもっているなと感じてました。

3人の掛け合いが面白かったのでもう2,3時間聞いていたかったのですが、 とりあえずその場でのメモをそのまま載せときます。途中から忙しくなって敬称がなくなってますが許してください。

- 今回の問いを立てたのは末村さんが発端
	- お客様に何も約束していないのに、おれたちは何を保証しているんだろう
	- お客様に対して、ほんとうはなにがしかお約束しなければならないのでは？
	- と思った
- ゆもとさんポジショントーク
	- 品質基準、理想的には必要
	- 提供するサービスのSLAが品質基準とも呼べる
	- けどIT現場では以下問題がありそう
		- そもそもSLA決まってない
		- SLAと、QAのしごととがつながっていない
- すえむらさんからの会場質問
	- SLAあるひとー！→10%くらい
	- QAのしごととつながってるひとー！→さらにその2%くらい
- tettanさん
	- 日本無線時、ハードウェアやっていたので、ハードウェア起点で考えることが多い
	- 品質基準もあった
	- 品質基準？
		- 製品やサービスの品質を一定の基準で定めたもので、顧客のニーズや期待を満たすことを目的としている（Google検索AI要約より）
		- 品質：ユーザーにとっての価値
		- 基準：何らかの尺度とその達成要件
		- つまり
			- ユーザーにとっての価値を何らかの尺度で捉え、どの程度であれば達成できるのかを定めたもの
- ハードウェアとソフトウェアの違いってなんだろう
- 品質基準についてもう少し考える
	- 量産品の場合：鉛筆、ジュース、洋服、家電など
		- 各ユニットの品質基準の積み上げ
		- それぞれの分野で規格、法律がたぶんある
	- 一品物：家、ビル、橋、ソフトウェア？
		- 家の例）広さ、間取り、日当たり→品質基準はまちまち
		- 遮音性能、断熱性能、採光性能、・・・→品質基準決められそう
	- 品質基準いろいろありそう
		- ユーザー価値、法律、規格、認証
- Discordにて
	- SLAはパッケージにはなさそうで、サービスにはある気がする
		- すえむらさん）なるほど
	- こうのさん）これスライド用意してんすよ
		- 先にみよう！
- 特徴に応じた品質基準の捉え方
	- サブスクと所有の軸
	- アート性と製品性の軸
		- アートには基準あんまり決められない気がする
- で、ソフトウェアの場合
	- サブスクは変更容易、所有は変更困難という軸とする
	- パッケージは製品性が強くて変更困難な象限
	- 昔のゲームはアート性が高くて変更困難な象限
	- 変更容易で製品性はSaaS toB、アート性が高くて変更容易なのはSaas toCやエンタメ系アプリが該当
	- 製品性が高くて所有、に属するものは品質基準に向いてて、アート性が高くてサブスクにあたるものは品質基準に向いていない気がする
- Production Readiness Checklist
- すえむら）SLAは利用時品質だと思っていて、内部品質の基準がDefinition of Doneだと思う
	- こうの）これは品質基準ではなく、品質管理基準なのでは
		- モノを見ているかどうかの違い
		- PRCはユーザー価値ではなくもっとインフラ側をみている気がする
- ゆもと）ユーザーが見てわかるものは、品質基準としてわかりやすい。いっぽうPRCでのロードバランサやDBの話は、ユーザーが使うものじゃないから品質基準として不適なのでは？とtettanは言ってるのかな？
	- こうの）そのベースに乗っかるソフトの基準はまた別だよね？という話だった
- すえむら）下といっているのは内部品質？
	- こうの）うーん、たとえばPCの品質について考えるときに、PCの性能と乗ってるソフトの性能は別だよね？PRCはPC側を見ていて、お客さんとしたらそこはあんまり関心がなくてソフトウェアのほうの品質を気にするよね？
- こうの）品質管理基準と品質基準は関係するけどイコールではないと思う
	- 品質管理基準は、品質基準に比べると扱いやすい気がする
- ゆもと）ようはプロセスだよね
- てったん）アジャイルソフトウェア開発宣言で、品質基準いらんわみたいな話になった気がする。
	- 日立の品質保証部長に、アジャイルがきたら部門いらんくなりますよ、って言ったらめちゃめちゃ怒られた
	- ソフトウェアだとあとから変更ができる部分もあり、品質基準みたいなものがそれほどいらないのではという
- Sli.doの話
	- 業種によって品質基準変わりそうですが？
		- それはそう
		- たとえば変更容易性についても、技術が進んでできるようになった部分はある
- すえむら）まって、おおもとの質問になんらか結論だそうよ
	- SLAもない、品質基準もないという組織にきたら初手でなにするのよ？
		- こうの）ひとつのプロダクトの中の要素を分解して、品質基準（先に出てきた二軸）にマッピングするのがよいのでは
- 重篤度と品質基準は別だが、重篤度が高いところはちゃんと基準要るよね的な使い方

とにかく河野さんの整理された概念、1つのプロダクト単位ではなくその機能やコンポーネントごとに、 製品性↔アート性、変更容易性↔所有、という2軸でマッピングしていくというのは真似してやってみたい。

初日はこんな感じでした。見られなかったセッションもあるのですが、あとで動画公開されたら嬉しいですね。