JaSST Kansai '25 参加レポート

最近急にあつくなってきました。
私が住んでいる部屋の近くに 市営のプール があるのですが、近くの高校生が毎日泳いでいるようです。
監督の怒鳴り声を聞きながら仕事をしています。ああ恐ろしや
当日は 4:30 起きです。早すぎ

この記事について

JaSST というテスト専門のシンポジウムに参加してきました！
https://jasst.jp/kansai/25-about/

そちらのイベントの内容について報告します。これをきっかけに

• 次の開催に行ってみたいな
• テストについて興味が出た

といったような影響を与えられれば幸いです

JaSST とは

JaSST（ジャスト）は、NPO法人ASTER （ソフトウェアテスト技術振興協会）が運営する
ソフトウェア業界全体のテスト技術力の向上と普及を目指すソフトウェアテストシンポジウムです。
※JaSST：Japan Symposium on Software Testing

今回のシンポジウムは重複しているセッションがあまりないので、私のような優柔不断にはありがたいタイムテーブルでした(笑)
会場内で迷子にならなくて済むし

言語やフレームワークといった領域での MeetUp や Summit はよくありますが、テストという「開発プロセス」だけでのシンポジウムって少し珍しいんじゃないでしょうか？

テストは製品開発のいろんなステージでいろんな手法がありますが、今回のカンファレンスは 「TODO」に関するテストが多かった印象です。

セッション内容のアーカイブ配信などは不明です。

会場の雰囲気

このまえ AWS Summit に参加してきまして、それと比べると流石に規模は全然違いますが、イスも机もあってプレゼンも見やすく快適でした笑
研究時代のシンポジウムの雰囲気と似てて懐かしさを感じました。

今回の学び

今回のシンポジウムを通して学んだこと・新しい知見を記します。
気になった内容があったらこの後のセクションもお読みください。

新しく知った言葉

• 4 keys
• 事例マッピング
  • ユーザーストーリーマッピング
  • SMART な受け入れ基準
  • BDD
  • ATDD
• ハイレベルテストケース
• テスト
  • セキュリティてすと
  • 性能テスト
  • 信頼性テスト
  • 互換性テスト
• 経験ベーステスト
  • 探索的テスト
  • エラー推測
  • チェックリストベースドテスト
  • Context Driven
• 継続的テスティング
  • SRE
  • (DevOps)
  • Holistic testing
• スモークテスト
  • サニティチェック
  • 受け入れテスト
  • intake テスト
• シフトライト
  • カオスエンジニアリング
  • AB テスト
  • カナリアリリース
  • シフトライトテスティング
• 品質モデル
  • ISO25010
  • 製品品質モデル
• マスターテスト計画
• テストレベル
• バグ分析
  • ODC 分析
  • SFMEA
  • なぜなぜ分析
  • 不具合モード分析
• テストプロセス改善モデル
  • アセスメント
  • ISO/IEC 33063
• ペアワーク
  • QA2AQ
  • 障壁の解体
• モブテスティング
  • バグハッシュ
  • アジャイルテスティング
• ヒューリスティック評価
  • ドッグフーディング
  • エキスパートレビュー
  • ニールセンのヒューリスティック
• ユーザビリティテスト
  • HCD
  • 認知的ウォークスルー
  • ユーザ行動観察調査

当日はワークショップがあり、そこで開発プロセスで困った際に切るカードを手に入れました(物理)

新しく知った考え方

• ガードレール型テスト
  • AI が誤った方向性の開発を行わないように、テストケースを適切な方向へ誘導するガードレールとみなす考え方
• DevOps を組織に取り入れる際、テストの観点から提案すると導入がしやすい
  • 詳細はセッション内容参照

JSTQB

こちらテスト設計の資格です

https://jstqb.jp/

なんと国際資格
しかも有効期限なし

私はテスト初心者なので、何か勘違いをしていましたが、

• テスト設計の能力を測る試験
  であって
• テストコードの知識を問われる試験
  ではありません。

元から IT アーキテクトを目指していた私ですが、テストに強い IT アーキテクトを考えるようになりました。

セッション内容

備忘録です。まともな文の体裁をしていません。

↓↓↓ タイムテーブル ↓↓↓
https://jasst.jp/kansai/25-timetable/

私の主観で、各セッションで得た新しい知見や再認識した知見を記します。
主観に依存した内容なのにご注意

また、途中でワークショップがあったのもあり、全てのセッションに対する内容をメモしてるわけではないのはご了承ください

セッション内容備忘録

(基調講演) DevOpsを加速させるテスト、DevOpsで加速するテスト - 前川 博志（ダイキン工業）

• 概要

  • ソフトウェア技術者からみたテストの話

• 課題：DevOps を組織、特に大企業で広めるのは難しい

  • 原因：組織のサイロ化
    • 社員だけで 24/365 の体制を作るのが困難
    • 運用がコア業務と認識されない
  • 原因：DevOps の利点を大きく主張しづらい
    • 4keys^[1] といった DevOps 指標の改善の何が嬉しいのか.
    • リリース回数の向上 ≒ 業務の増加 と捉えられる

• 実例：多くの組織は「開発主導」の DevOps になる

  • 運用側は通常業務に忙殺
  • 最新の開発スキルも獲得しづらい

• 主張：DevOps とは、開発の段階から運用のこと（＝開発してからの面倒ごと）を織り込んで開発を行うことだ

  • 面倒ごと
    • リリースの高度化・自動化
    • 可観測性の強化
    • 自動テストの強化
    • セキュリティの早期確認

• 実例：当初のダイキンでの取り組み

  • AWS の設計指針の共有, リファレンスアーキテクチャ

• 課題：作成したが、なかなか広がらない

  • 教訓：仕組みは作るだけは広まらない。リアルな運用シーンを想定し、イネイブリングしていく必要がある
  • 教訓：本当に必要な人には届いていない

• 教訓：「テストや品質」といったキーワード、取り組みは、企業の中で DevOps を取り入れるいいきっかけとなる

• Q&A

  • 品質評価方法は
    • 非機能要件に関して、AWS セキュリティダッシュボードが１つ
      • -> QAチームへのフィードバックとなる
    • まだ取り組み中だが、4keys による評価を考えている

仕事なのに楽しいって、ズルいですか？ - 岩田雅弘（bubo）

• 仕事が楽しいと思えるとき
  • 学び・成長
  • 人の役にたてる
  • 対話による発見や気づき
  • 仲間との刺激

技術だけでは要求品質を満たせない ～論理的思考によるメンバー育成から導く品質向上～ - 上垣 颯太（ベリサーブ）

• 課題：メンバー育成
  • 何度指摘しても同じミス
  • 応用が効かない
  • 生産性が低い
    • -> 結果的に誤ったテスト評価を行う
• 対策：
  1. 言い方を変える
  2. 何ができていないか可視化する
  3. 確実に変化できるレベルまで落とし込む

オフショアで挑む新規プロダクト開発 - 須﨑 慎一郎（チームスピリット）

• 課題：新機能開発でテストをオフショアに委託した際の課題
  • コミュニケーションコスト
    • 原因：仕様に関する質疑応答が各ツールに散乱
    • 原因：コミュニケーションツールを定めていなかった
    • 原因：複雑な設計内容の伝達ミス
    • 対策：情報の一元化
      • 質疑応答時間と開発時間を分けて確保
  • 発注したものを作るだけの顧客価値不在の開発
    • 原因：「要件をもとにプロダクト作成する」ことのみに注力していた
      • UI など、凝るべきところをおろそかにしていた
    • 対策：価値を見出すミーティング
      • 「プロダクト作成に関する意見交換会」にオフショアメンバーも牧子m
  • 工数見積もり誤り
    • 原因：既存機能への影響の考慮不足
    • 対策：細かな進捗共有
• 日本チームとオフショアチームのワンチーム化
  • 「モブ設計ミーティング^[2]」を導入

実践！実例マッピング！うまく実施するためのチーム作り - 小川 雄喜（三菱電機）

アジャイル開発における悩み事

• 課題：PO からの要求を深掘り切れない
  • 原因：要求仕様を開発に落とし込む議論の時間がない
    • 開発者以外が参加するスクラムイベントがレビューしかない
• 課題：スプリントが進んでもなかなか完成に進まない
  • 原因：レビューの指摘ばかり重なる
  • 原因：POが技術的手法や課題についてピンとこない
    • 開発者からの提案に PO がうまく回答できずに、開発者まかせになってしまう
    • 開発者の質問は技術の面になるため、顧客のユースケースに即した議論に発展しない

実例マッピングの導入^[3]

• 概要
  • ユーザーストーリーを具体化する方法
• コツ
  • PO, SM, 開発メンバー, QA メンバ, 様々な部門を含める
• 失敗しないために
  • 実例をきちんと出すことができる多様な視点が必要
    • QAさえ呼べばいいわけではない
  • 参加者は経験をベースにした質問力が問われる
    • 過去の不具合となった事例やレアユースケースにおける対応
  • できるだけ初期段階でおこなう
    • PoC 段階で実施 (有効だった事例)
  • 開発する技術スタックに詳しい人を呼ぶ
    • それが QA部門 なのが望ましいが、横断的な知識を持つ人が好ましい
  • チーム作りを怠らない
    • SM + 開発 で閉じたチームとしない
  • ストーリーが全体のうちのどこに位置するストーリーなのかが共通認識としてあると有効.事前にイベントストーミングを行うなど
• 失敗事例
  • ハードウェア部門とソフトウェア部門のプロジェクトでそれらの部門を混ぜてマッピングしてみたが、ソフトウェア部門からの質問がほとんどになってしまった
    • => ハード部門からの事例が不足していた

遠隔拠点における新規メンバーのオンボーディングとコミュニケーション設計の事例 - 鳥渕 建樹（ビットキー）

• 課題：リモート環境での新人教育が困難
  • 原因：心理的安全性の欠如
    • 対応：Google Calendar にいつでもきてもいいよ部屋 = いつでも対面で話せる場所
      • 結果：距離が近くなり話しやすくなった。ビデオは極力 ON に
  • 原因：同じ質問が複数人からくる
    • 対応：Q&A 表を作成
• 実例：新人の１ヶ月の東京研修で、実際に bitky の製品が含まれる賃貸に住んでもらった
  • 結果：実体験を通して、ユーザー目線での製品の品質を感じてもらうことができた

AI時代の高速な開発を支えるガードレールとしての自動テスト - 末村 拓也（オーティファイ）

2つのテストタイプについて

• フェーズゲート型テスト
  • テスターが通過・承認をしないとリリースできない。最後まで見ない
  • 欠点
    • シナリオ：テスターが大量のバグを見つけた場合
      • テスターが褒められるかもだが、実装時点で守られるべき品質が担保されていない問題
      • この状態で AI が入ると、さらに大量のバグが生まれるのが予想される
• ガードレール型テスト
  • ガードレール：自動化された制約
  • 自動テストはガードレールになりうる
  • AI が入ってもガイドが可能な、自動テストで制御する

脚注

1. 4kyes - Google Cloud - エリート DevOps チームであることを Four Keys プロジェクトで確認する

2. モブ設計ミーティング - 新規プロジェクトでモブ設計を実施してみた

3. 今日から使える「実例マッピング」