こんにちは、hacomono QA部です。
今年も開催されたJaSST Tokyo 2024 にQA部で参加しました！
ソフトウェアテストシンポジウム（JaSST）は、ソフトウェア業界全体のテスト技術力の向上と普及を目指しており、開催場所や開催年ごとに様々なテーマを掲げて発表やパネルディスカッションが企画されています。
参加したレポートをDAY1とDAY2の2記事に分けてお届けしますので、DAY2記事もお楽しみにお待ち下さい。
今回は、参加したセッションごとに各メンバーがレポートを書いていく形でお届けします。
なお、業務都合や居住地域の関係でオンライン参加とオフライン参加で分かれています。
DAY1参加の感想まとめ
セッションがたくさんありレポートが続くので、はじめにDAY1の感想まとめを書きます。
今年のJaSST Tokyoは基調講演の趣旨に類似する発表（以下の点）が多いと感じました。
- 計測対象として顧客価値・ビジネス価値が含まれていること
- 顧客価値を届けるためのリードタイムを短くすること
hacomono QAメンバーのみでJaSST Tokyo に参加しましたが、価値についてはQAエンジニアのみに限らず響く内容だと思いました。
そのため次回はQAメンバー以外のhacomonoメンバーを誘って参加し、課題に感じたところを同じ熱量でディスカッションして、よりよいプロダクトづくりに活かしていきたいと思いました。
各発表を聞いてまだまだhacomonoに足りないところもありたくさんの課題を認識しつつも
これはhacomonoでもやっている！という取り組みもあり少し自信を取り戻したりと
DAY1だけでも充実したセッションでいっぱいでした。
以降は各セッションに参加した感想が続きます。
Tangible software quality（基調講演）
“Tangible”とは直訳すると、「有形」「実体的」という意味です。
この発表の主題は、品質を目に見える、手に取れる形にしましょうということにあると捉えました。
発表の中では、Tangibleな品質について5つのポイントが話されていました。
- 品質の欠如だけでなく、存在を測定する
- 品質は1つの指標だけでは測れない
- 複数の品質がある時、それらのトレードオフが必要
- 全てのステークホルダーとコミュニケーションを取り、認識を合わせる必要がある
- ソフトウェアの品質は触れるものでなくてはならない。可視化されている状態でなくてはならない。
私が特に印象に残ったのは、2,3についてです。
「品質」というのは非常に曖昧な概念であり、それを具体化、実体化するためには多角的に分析する必要があります。
品質を多角的に捉えると、その複雑性に気付くことができます。顧客にとっての価値、あるいは自分たちにとっての価値に繋げるためには、多様な品質のうちどれを優先していくのかを選択する必要があります。
製品やビジネスの向かう先、解決したい課題、提供したい価値によって、作りたい品質を常に再定義し続ける必要がある、これはQAエンジニアとしての重大なミッションの1つだと再認識しました。
品質を可視化するための具体的な手法もいくつか紹介されていました。（QUPER modelなど）
品質目標の定義や計測の方法については、知識を深掘りし、色々と実践していきたいと思います。
ソフトウェアテストをカイゼンするためのいくつかのアイデア（特別講演）
ソフトウェアテストをカイゼンする50のアイデア という本の内容についていくつかピックアップしてお話いただきました。
内容はマインドの話であったり自動テストの管理であったり、広くソフトウェアテストに関するアイデアが書かれているようでした。
具体的な手法の話もあれば抽象度が高く解釈が分かれてしまう話もあるようなので、発表者である山口さんもおっしゃってましたが、1人で読んで実践というよりはチーム全員で認識合わせをしながら読むのが良さそうです。
中でも「感情のパターンを仮定してみる」というアイデアはすぐに実践してみたいと感じました。
ペルソナ分析を使うこともあるのですが、プロダクトを使う人がどんな感情かによっても、求められる挙動は変わってきます。
1つの観点、ユースケースとして考慮すべき項目だと感じました。
チームトポロジーに対応するQAアプローチのご紹介
エンジニアリング組織戦略について、チームトポロジーの考え方とスクラムガイドの考え方を用いて設計されていて、そのQAコンセプトについてお話いただきました。
私は元々チームトポロジーの本を読んでいることとスクラムチームでの業務経験があることで今回の発表は事前から興味が高く、実践されている例は貴重なので組織作りの参考になる話ばかりでした。
“QA Enabling”というQA領域の戦略と浸透を担うチームがあり、ストリームアラインドチームはそのQA戦略を理解して実行を行う、という関係性になっており、hacomonoのQA組織とは異なる構成であったため自組織でも活かせる点はないかという姿勢で聞いていました。
QA Enablingチームは、QAファンネルの「QAコーチ」と「インプロセスQA」の範囲と定義されており、QA Enablingチームの取り組みとして紹介されていた内容はQAコーチの側面が強く出ていたようでした。
この発表を聞いたあとに振り返ってみると、hacomonoのQA部はフェーズゲートQA・QAサービスとインプロセスQAで構成されていて、開発者とのテスト業務の受発注感があることに再認識させられました。
QAコーチとしての活動はできていないことに気づけたので、今後はこの領域へも活動を増やしくためにはどうしたらよいか、QA部全員やプロダクト組織全体で考えていきたいと思いました。
チーム単位で保守性を高める：独自指標と向上にむけた実践
独自に定めた指標について発表されていました。
冒頭で各々の担当領域で保守性を管理可能な水準に高めることを重要課題の一つとしている、という話もあり、いわゆる品質管理部門のみならず組織全体で品質について考えられているのだろうなということも伝わってきて、良い風土のある会社だなぁと聞いていて感じました。
改善などの取り組みがチームに留まり、横に広がっていかないことも多くあると思うのですが、チーム外の人にも指標を公開したことにより、状況がわかるようになった点も非常に素晴らしいなと感じました。
指標により改善すべき内容や、コミットすべきチームが見える化されている点など弊社でも参考にして、良いサイクルで動けるようになっていきたいと思います。
欠陥を誘発しやすいプロダクトコンテキストの整理
ソフトウェアの欠陥が偏在するように、仕様に起因する欠陥も偏在するのではないか、という仮説をもとに検証し、実際に検出・対策された話をしていただきました。
プロダクトコンテキストを整理する際に、メンバー間で議論をされたエピソードがありましたが、シフトレフトの取り組みをしたい！という企業においてもとても参考になる話だったんじゃないかなと思いました。
チーム内で職種にとらわれずコミュニケーションが活発であれば、プロダクトコンテキスト起因の欠陥にも気づける場が自然と多くあるのだろうなと感じました。（きっと自然に取り組まれている会社もあるのだろうなと思います）
hacomonoでも仕様レビューなど取り組んでいますが、未然防止の部分でお話しいただいたデジションテーブルを作成して条件の組み合わせを整理して考慮もれを防ぐなど、この辺りも積極的に動いていきたいと感じました。
実際に検証し、対策方法を検討し、実施した内容まで詳細に説明いただけて、具体的にイメージもでき、とても分かりやすかったです。
開発リードタイム70%短縮したアジャイルチームでQAがやったこと
スクラムチームで開発者が実装するスプリント内でテストが完了しないために、次のスプリントでテスト実施となり手戻りが発生したときには、既に開発者が次のスプリントで新しいタスクに着手しているため仕掛中のまま前のスプリントの作業を手直しするため、一つのプロダクトバックログの完了までのリードタイムが長い、という課題を解決した話。
hacomonoでも同様の状況（開発とQAが１スプリント差がついている）になっており改善した事例があったのですが、解決方法は異なっていたので面白かったです。
実例マッピングやテスト観点の事前共有を意識して取り組んではいなかったので実践で活用していきたいですし、ちょうどhacomonoでもペア作業・ペアレビューを取り組み始めたところだったので他社でも有効な手段であるということがわかってよかったです。
qa不在のスクラムチームは品質向上の夢を見るか
非IT企業という特性上チーム専任のQAをアサインする難しさを抱えるスクラムチームで、開発者をQuality Consultant という役割に選任し、解決されていなかった品質課題にどう向き合ったかについての発表でした。
クロスファンクショナルなチームとしてチーム全員で品質課題に向き合っていて、とても素敵でした！
何が問題かわからない・問題の解決手段を知らないという現在地を認識して勉強会をスタートしたり、技術ブログを読み、実践して、ふりかえるという学習サイクルをしている点がすばらしいと思いました。
特にバグの発生件数の増加がリードタイムに影響しないという点も印象深く、深刻なバグとそれ以外のバグという切り分けにより優先度付けが機能してリードタイムに影響しなかったかと推測します。
JaSST Tokyo 2024全体的にリードタイムを短縮すること（いかに価値を素早く届けるか）に関連した発表が多い印象でした。
価値提供までのリードタイムはhacomonoでは計測していないため、計測指標として取り入れるなどを検討してみたいと思いました。
QAエンジニアの〇〇UP！キャリア解剖で見える今どきの成長軸とは？
QAエンジニアのキャリアや成長軸について、プレイヤーとマネージャーの2つに分けてインタビュー形式で深掘りをしていく、という内容でした。
強く印象に残っているのは、プレイヤーのくだりで話されていた、QA/テストエンジニアのスキル領域についてです。セッションの中では、
- テストスキル
- ソフトスキル
- ITスキル
- ドメイン知識
の4つの領域に分けて自分に不足している部分や得意としている部分を分析してみよう、と紹介されていました。
自分自身QAのスキルアップキャリアアップをどう描いていくか迷っている真っ只中なため、この分類は大きなヒントになると感じました。
ただ、この4つの大きな分類から、どこからどこまでが”ITスキル”として必要とされるのか？求められる”ソフトスキル”とは具体的に何かなど、細分化していく必要はあると思いました。
マネージャーのくだりでは、「何とかする力」が必要で、その正体は何なのか？を解き明かす形で進められました。
幅広く、多様な経験が必要であり、それを元に仮説検証を繰り返していく、というお話が印象的でした。QAマネージャーを志している私自身、非常に刺激的なお話でした。
日々様々な困難に向き合い続けること、それらを「なんとかする」ために、多方面でのInputを疎かにしないようにします。
AI搭載プロダクトの品質保証の現在地点とこれから
AI製品の品質保証は、自分の挑戦したことのない未知の分野のため勉強したく参加しました。
AI製品が既存のWEBサービスと異なる点として、アウトプットの期待値が判断する人によって異なるということもあり、議論が白熱していました。
hacomonoでは自動テストツールAutifyの競合のmablを利用していて、AutifyのAIによるメンテナンス機能と同じようなAIによる自動修復（Auto-Healing機能）を有しており、日々お世話になっています。
この自動修復機能においても、mablのテスト失敗時に「この失敗はちょっとした文言変更なので自動でメンテナンスしてほしいな」と思うことは何度かあるので
やはりすべてのユーザーにベストフィットしたAIチューニングというのは難しいのだな、と思いました。
利用しているユーザーとして期待値をフィードバックすることも大事だとこのパネルセッションを聞いて思いました。
最後に
JaSST Tokyo 2024のQAメンバーによる感想・レポートはいかがでしたでしょうか。 DAY2の感想・レポートも公開予定のためお楽しみに！
DAY2はこちら techblog.hacomono.jp
hacomono QAではQAエンジニアやSETエンジニアを積極的に採用しています。
少しでも気になったらぜひ気軽にお問い合わせやカジュアル面談を申し込みください。
