こんにちは。ドリーム・アーツのShopらんでQAエンジニアをしている坂井です。
ソフトウェアテストのカンファレンス JaSST’25 Kansai に参加してきました。
大阪に行く機会が少ないため目的地までの電車にかなり苦労しましたが、会場には約60名ほどの参加者が集まり、JaSST Tokyoとは規模が小さい分、和気あいあいとした雰囲気が印象的でした。
特に印象に残ったセッションを中心にレポートしたいと思います！
雰囲気が伝わりづらいですが、会場の様子です。(もっと遠目で撮っておけばよかった…)
また、JaSST’25 Tokyoにも参加したのでこちらもぜひ見ていただけると嬉しいです！
DevOpsを加速させるテスト、DevOpsで加速するテスト
IoTを支えるSREの方によるセッションでした。
- 大企業になるほどDevOpsの導入は難しく、サイロ化の壁にぶつかる
- 「DevOpsはスピードではなく、品質を高め続けるための仕組み」
- AIがコードを書くスピードに合わせるには、テストもAIや自動化で追従する必要がある
多くの現場では「開発スピードと品質はトレードオフ」と語られがちで、速く作ると品質が下がるという前提で話が進むことが多いと思います。
しかし講演者は、AIを活用すれば「スピードを上げても品質を保つ、むしろ高めていける」という視点を提示していました。
普段よく耳にするのは「AIでテスト設計やテスト実装を効率化する」という話ですが、今回は「DevOps全体に品質を乗せる」という広いスコープで語られていたのが新鮮でした。
自分の現場に置き換えると、テストやプロセス改善にAIを取り入れるだけでなく、開発と品質を同じレベルで加速させる仕組み作りが今後必要になるのだろうと感じました。
技術だけでは要求品質を満たせない～論理的思考によるメンバー育成から導く品質向上～
メンバー育成や品質改善をテーマにしたセッションでした。
- 「何ができていないか」を可視化する
- 実施手順を確実に変化できるレベルまで落とし込む
- 言い方を工夫して、チーム全体を動かす
2年前から新人へのオンボーディングを担当しているのですが、
特に仮配属の新人に対して「配属期間中に何を達成してもらうか」はざっくり決めているものの、日々の変化に合わせて一定の経験をしてもらうことに難しさを感じていました。
このセッションを聞いて、何ができていないかを列挙する前に、望ましいスキルセットやゴールを明確にする必要があるなと気づきました。
配属期間中に会得して欲しいスキルは何なのか、普段自分たちが行っている業務を再認識することで、評価が独りよがりにならず、育成の方向性もブレにくくなるのではないかと思います。
実践！実例マッピング！うまく実施するためのチーム作り
PO(プロダクトオーナー)からの要求がざっくりしていて、スプリントが進んでも完成に近づかない、そんな課題に対して実例マッピングを導入したというお話でした。
実例マッピングとは、あるユーザーストーリーに対して具体的な質問からルールを定めていくワークのことです。
参考記事/スライドはこちら↓
私自身、実例マッピングは聞いたことはあるものの、具体的にどんなメンバーで、どの内容について話すと良いのか、以下をポイントに説明されていたのが印象的でした。
- QAさえ呼べば良いわけではない
- 多様なメンバーに参加してもらい参加者に偏りを持たせない。
- なるべく早い段階から始める
- PoCの段階で実施すると良かった。
- 参加者の質問力が問われる
- 過去の事例や不具合の経験を活かした質問などが大事。
特に「QAさえ呼べば良いわけではない」という指摘は強く印象に残りました。
自身の経験では、どうしても「QAと開発者」で議論を閉じてしまい、結果としてビジネス側やデザイナーの観点が後追いで入ってきて、追加仕様や優先度の再調整に繋がることがありました。
つまり課題の本質は、役割ごとの「暗黙の前提」が早い段階で可視化されていないことだと思います。
実例マッピングは、設計やPoCの段階でユーザーの要求やユースケースを共通の言葉で可視化するための仕組みとして有効です。
また、開発チームに閉じず、多様な視点を持つメンバーを交えることで、技術論に偏らず「ユーザーが本当に求めていること」を中心に据えられるのが大きな価値だと感じました。
脱”今まで通り”。考えるQAエンジニアのワークショップ。【2歩目】~課題解決編~
仮説からテスト戦略を立て、さらに追加情報で再構築するというワークに参加しました。
それぞれ与えられたアプリケーション仕様や課題、リクエストに対して議論し、最後に選択した各自のテスト戦略を話し合うものでした。
普段の現場では以前決まったテスト方針や計画をベースに進めることが多いですが、このワークでは
- プロジェクトや機能の性質ごとに最適な方針を選ぶ
- 開発中の変更に合わせて戦略を柔軟に切り替える
といった臨機応変な対応を体験できました。
これまで「テスト方針はプロジェクトの初期に決めたものを守るもの」と思いがちでしたが、実際には状況に応じて動的に戦略を更新していく力が必要なのだと実感しました。
現場に置き換えると、例えば「UIの色や文言を変えるフロントエンドの改修」と「決済処理などお金に関わる基幹機能の改修」では当然リスクの質がまったく違います。
それを同じテスト戦略でカバーしようとするのは無理があり、リスクに応じて戦略を切り替える必要があると思います。
このワークを通じて、戦略は固定したものではなく、変化に対応するためのフレームワークだと捉え直すことができました。
(ワーク後に使ったカードをもらいました！)
AI時代の高速な開発を支えるガードレールとしての自動テスト
AIコーディングの台頭によって、テストやQAの役割は「門番」ではなく「ガードレール」になるべきだ、という話が印象に残りました。
- 門番：最後に立ちはだかり、通す/通さないを決める存在
- ガードレール：安心して実装するためのここから出ちゃいけないライン、機能性やユーザージャーニーを保護するもの
バイブコーディングのように開発スピードが急激に上がっていく未来を考えると、従来の「門番型のQA」では対応しきれないというのは、まさにその通りだと感じました。
従来のようにテストを「リリース前の最後の門番」として構えているだけでは、加速する開発フローに追いつけず、むしろ足かせになってしまう恐れがあります。
そのため、QAの役割は、安全に加速するための仕組みやプロセスを整える役割がより重要になるのだと解釈しました。
自動テストについても、単なる効率化の手段ではなく「開発全体を支える基盤」として考える必要があると思います。
全体を通して
これからのQAの役割や個人の役割がどのような変化、対応していくかを考えさせられる良い機会になりました。
また、ワークショップへの参加が今回初でしたが、和気あいあいとした雰囲気で発言がしやすかったです。普段の業務で行っていることを俯瞰してみれたり、再確認することができました。
来年も開催となった際は是非参加したいです！
Views: 0
