Yappli Tech Blog

株式会社ヤプリの開発メンバーによるブログです。最新の技術情報からチーム・働き方に関するテーマまで、日々の熱い想いを持って発信していきます。

JaSST24 Tokyoに参加しました!

参加メンバー(寄稿者)

山口、 楠原、 鈴木

はじめに

ヤプリQAエンジニアの山口です。

ヤプリQAチームとは初となるQA向けカンファレンス「JaSST'24 Tokyo」に参加しました!

JaSSTソフトウェアテストシンポジウム-JaSST'24 Tokyo

「JaSST」とは年数回全国各地で開催されるソフトウェア業界全体のテスト技術力向上と普及を目指したカンファレンスです。 今年はオフラインとオンラインのハイブリット開催となり、現地会場への参加を申し込みましたが満員御礼でオンラインでの参加となりました。

今回はそんなカンファレンスの様子や、参加したヤプリQAエンジニアの感想などをレポートしていきます。

当日の様子

オンラインでの開催では各セッションごとのZoomリンクから見れたのですが、それとは別にJaSST用のDiscordサーバーが設置され、 開催前後の交流やセッションごとのチャンネルで実際に発表を受けての質疑応答をリアルタイムで回答いただいたり、 参加者同士での意見交換もできてオフラインさながらの楽しみ方ができたのが印象的でした。

実際のDiscordでの様子。各セッションごとのチャンネルでの参加者のリアクションなど楽しめました。

印象に残ったセッション

寄稿者:山口

チーム単位で保守性を高める:独自指標と向上にむけた実践

チーム単位で保守性を高める:独自指標と向上にむけた実践 - Speaker Deck

資料もわかりやすく聞き手として聴きやすかった点が印象的でした。

登壇の方のプロダクトを事例にチームに起きている課題に対して、CTOを含めて議論し独自の指標を定めてから、改善に向けた施策を各チームの品質管理メンバーの方達が主導で推進していくといったものでした。
ヤプリQAチーム内でも課題の洗い出しやそれに向けた施策検討は行っていたりしますが、指標を固めていると課題からのチーム単位で施策検討をしてもブレが出ずに、且つ改善施策を実施した後に数値として追いやすくなるので、勉強になりました。
この手の問題は社内でも他社さんでもよく耳にしますので、課題に対して向き合う際に有効だなと感じました。


テストだけで品質は上がらない?! エセ自己組織化した品質組織からの脱却

テストだけで品質は上がらない?! エセ自己組織化した品質組織からの脱却 / JaSST'24 Tokyo - Speaker Deck

こちらも非常に聞き応えのあるセッションでした。
ヤプリも同じく開発チームとQAチームは同じ部署に配属されており、開発・リリースのスピードと品質とのトレードオフに関する問題はよく取り上げられる課題なのかと思います。
ただ、本来はトレードオフではなく、品質を向上することで見える開発側のメリットとリードタイム短縮による品質向上に対するメリットの相乗効果が期待できます。 また、役割のバイアスによって対立構造を起こしがちですが、そうさせないためにも事業価値と品質に対する紐付けと、品質価値の共有を全体で行うのは大切。

バグ1件流出するにも、事業価値に対してどう影響してしまうのかを考え、QAチーム内で共有する時間というのはなかったので、まずはQA内でも認識揃えてみるなどは取り組めそうだなと思いました。


開発リードタイム70%短縮したアジャイルチームでQAがやったこと

こちらは先述したセッションにも関連がありますが、開発のリードタイムを短縮するために価値共有以外で具体的にQAが取れる手法として考えられるものは何かを実例で取り上げていただきました。

取り組む前にリードタイム短縮の阻害となる要因を洗い出し、それに対するアプローチをご検討される中で、「実例マッピング ※」の導入は参考になりました。
(※実例マッピング=開発機能のユーザーストーリーをPO、開発、QAなど様々な職種のメンバーと擦り合わせ付箋などを使い洗い出していく手法)

後工程のテストフェーズで要件考慮漏れ不具合が混入すると要件を検討する時間が上乗せになる場合があります。

もちろん、テストフェーズになって初めて検知できる観点やパターンもありますが、なるべく要件考慮漏れの不具合をなくすために、実例マッピングを用いて開発、QA、POなどと一緒に検討を重ねていきます。あらかじめ受け入れの基準を定めていくことで、実装開始がスムーズになったり、テストフェーズの段階の観点出し考慮の工数削減などが期待できます。 実装前の上流工程での工数確保する必要があるなど別課題はありあそうですが、結果的に実装での考慮漏れ検討の軽減、後工程のテストフェーズでの短縮にもつながるので、実際に取り入れてみる検討をしていこうかと考えています。




寄稿者:楠原

チームトポロジーに対応するQAアプローチのご紹介

このセッションでは、『顧客に価値をすばやく届ける適応型組織』(チームトポロジー)における、QAの関わり方についての内容でした。

参加してみた感想は大きく2つです。1つ目は、「品質」についてです。
チームの振り返り(KPT)で「品質」について挙がったことはありますが、各メンバーが「品質」についてどう考えているのかについては話したことってないな。と感じました。 メンバーが考えている「品質」と、ヤプリのQAチームが目指す「品質」とは?を話し合ってみたら、新しい理想像が見えてくるかもと思いました。

2つ目は、「インシデント0件は防ぐことができない。」というのは共通の認識ということを改めて感じました。発生したインシデントをいかに早く収束させるかが鍵であること、また、再発防止に向けてポストモーテムでチーム間で議論することの大切さを実感しました。


最速思考でバクラク品質を!スタートアップのリアルな課題とQAの実践

最速思考でバクラク品質を! スタートアップのリアルな課題とQAの実践 - Speaker Deck

このセッションでは、アジャイルにおける高速な開発サイクルの中で実際に直面しているテストや品質の課題をもとに、現在の取り組みや乗り越えていくための戦略、そしてQAのスタイルについての内容でした。

現在担当しているプロジェクトはリリーススピードを重視しているため、楽しみにしていたセッションでした。 高速なデリバリーのためには、適切な品質を目指す(=バグ0を目的としない)。というのが印象的でした。 グッと刺さったのは、「ユーザーにとっては仕様かバグかは関係ない。『使いやすい』『使いづらい』『使えない』という体験だけが残る」という言葉でした。 (リモートにも関わらず、めちゃくちゃ納得して頷いてましたw)

MVP重視の機能のQAでは、クライアントへスピーディーに最適な価値を提供できるよう優先度を付けて、プロジェクトメンバーも巻き込んで取り組んでいこうと改めて身が引き締まりました。




寄稿者:鈴木

Tangible software quality

基調講演としてのセッションで90分と少し長かったですが改めて品質の重要性を考えることができたセッションでした。

「Tangible」を日本語にすると「有形の、触れて感知できる」というような意味ですが、一般的にはソフトウェアの品質というのは「無形」で「触ることができない」ものだと思います。
私自身、より良い品質にしたいという思いでテスト活動等を行なっていますが、実際に品質が良くなったのか、自分がどれだけ品質の向上に役立っているのかを測ることはとても難しいなと感じていました。

目に見えない品質を「Accurate(正確性), performant(性能), trustworthy(信頼性), fun(親しみやすさ), fast(速達性), beautiful(審美性)」などの観点から数値化して視覚的にしていくと効果的とのことでしたが、プロダクトやサービスによってどの観点が重要なのかは異なってくるので、まずはヤプリとしてどの観点が大事なのかを組織内で意識を合わせていく必要があるなと感じました。


既存プロセスからの脱却と変化に適応するために必要なこと

長らく既存のQAプロセスを踏襲する傾向が続いていたサイボウズさん。ここ数年でQAプロセスを大きく改善し、その改善を促進させるために行った取り組みを紹介されていました。

このセッションに参加して1番印象的だったのは「機能別観点一覧の廃止」をしたというお話しをされていたことです。
廃止したことでメンテナンスのコスト削減でき、柔軟なテストを行うきっかけになった一方デメリットとしては一定水準のテストができない懸念があるそうですが、レビューを行なうことでそこまで問題が発生していないとのことでした。
現在ヤプリでは逆に機能別一覧の導入を開始していたのでビックリ!でした。ヤプリとしては機能別一覧を使用するのが現状適切と感じていますが、プロダクトの規模やフェーズ、チームの体制などによってより適した方法があるんだなと実感しました。

また、「振り返りをするけれどなかなか改善が進まない」という課題があったという点はヤプリでも同じ課題があります。振り返りで出てきた課題の優先付け、そしてそれをいつまでに行うのかまで一つ一つしっかり決められていなかったな、と気づけたので今後ヤプリでも意識していけたらなと思いました。


テスト管理ツールの向かう先

テスト管理ツールを開発・提供している3社がテスト管理ツールについて議論するセッションでした。
各社ともにエクセル/スプレッドシートが1番使われているツールであり、これら何でもできちゃうのでなかなか敵わないと認めていましたw

ヤプリでは新規機能や改修確認のテストはスプレッドシートをリグレッションテストはTestRailを利用しています。
私が入社した時からリグレッションテストはTestRailを利用しており何も考えずに使っていましたが今回のセッションを聞いてせっかく有料ツールを使っているのにTestRailの良さを活かした使い方ができていないなと言う気付きがありました。ツールを使いこなしてよりスムーズなQA活動が行えるようにしていきたいなと思いました。



まとめ

今回初めてヤプリQAエンジニアとしてJaSSTに参加してみましたが、どのセッションも聴き逃したくない内容だったので、複数名で参加することでセッションの聞き逃しがなく、情報共有できたのは良かった点だなと思いました。 実際に聴講してみて実践できそうな内容もいくつかありましたので、弊社として検討し取り組んでみた結果などもレポートしていきます。
また、Discordサーバーが設置されたことにより対面したことのない他社のQAさんのご意見が伺えたところも新鮮でしたし、勉強になりました。
近年、QA求人数が増えて外部イベントも盛んになっていますので、外部からも刺激を受けながら、ヤプリの品質をさらに向上できるように日々研鑽していきたいです。

※この記事はJaSST'24 Tokyo に参加した際の個人的な感想と学びをまとめたものです。公式情報や他の参加者の意見とは異なる場合がありますので、ご了承ください。

PR

ヤプリはカンファレンス参加など、エンジニアのキャリア支援を積極的に取り組んでいる会社です。 QAチームとしても今後、外部イベントの参加レポートや、内部取り組みの発信などをしていきます。
ヤプリQAの品質改善活動や社内の様子などが知りたい!興味がある!という方は、ラウンジカフェもあるのでお気軽にお越しください。

www.wantedly.com