JaSST Review'22でのMatt氏の講演をYouTube上に公開しました！ #JaSSTReview

勉強会 技術 発表 JaSSTReview

目次

何をしたの？

JaSST Review'22でのMatt氏の講演「The secrets of effective collaboration 〜うまくコラボレーションするためのヒミツ〜」をYouTube上に公開しました！

公開した動画はこちらです。

www.youtube.com

どんな講演なの？

公式サイトより引用した、講演の概要はこちらです。

ソフトウェアシステムは、たくさんの人の協力により作られます。そしてソフトウェアシステムの品質は、人々がどれだけコラボレーションしているかを表しています。つまり、調和の取れたチームは、使うのが楽しいソフトウェアを生み出せます。一方、退屈したりストレスを感じたりしている人々のチームは、欠陥だらけのシステムを作り、ユーザーを苛立たせます。

私は、ソフトウェア組織のコーチングにキャリアを費やしてきました。今回の講演では、何が優れたコラボレーションを実現するのか、加えて、優れたソフトウェアを生み出すためにはどのようにすれば良いのかについての洞察をお伝えします。その際、「実例マッピング」のお話をします。「実例マッピング」は、チームのバックログの問題を曖昧にせず明らかにして、テスト可能な例に分解するシンプルな手法です。また、手法の例から自動化した仕様に変える方法を示します。この方法は、日本語を含むあらゆる言語で書かれています！

今回の講演では、ペアプログラミング、アンサンブルペアプログラミング（モブプログラミング）、テスト駆動開発（test-driven development, TDD）、継続的デリバリー、トランクベース開発についても話します。

この講演によって、コラボレーションするヒミツについてチームに共有したくなることでしょう。

講演者のMattってどんな人なの？

公式サイトより一部抜粋

2008年には、立ち上がったばかりのオープンソースプロジェクトだった振る舞い駆動開発 (Behaviour-Driven Development, BDD)フレームワークのCucumber projectに参画し、2011年には、Cucumberの生みの親であるAslak Hellesøyと共著で書籍『The Cucumber Book』第1版を出版しました。

また、実例マッピングの考案者でもあります。

実例マッピングについては次の記事をご覧ください。

nihonbuson.hatenadiary.jp

nihonbuson.hatenadiary.jp

どうしてこのタイミングで公開することになったの？

実は先日、Mattさんが家族で来日し、実際に会う機会がありました。当時のJaSST Review'22はオンライン開催だったので、リアルで会うのはこれが初めてでした。*1

一緒に東京タワーを登った時の様子

その際に、「以前の講演をYouTube上で公開しても良いか？」と聞いたところ快諾いただいたので、講演から2年近く経ったタイミングですが公開する手筈となりました。

講演内容が英語なんだけど？

はい、講演内容は英語です。これは、イベント当日は同時通訳が付いていたのですが、通訳会社との契約の関係で、同時通訳の音声を載せることができないため、英語音声のまま載せています。また、後半の質疑応答部分は、私が日本語で、Mattさんが英語で喋っているため違和感があるかもしれません。

Mattさんの英語は日本人にとっても比較的聞きやすい英語だと思いますので、ぜひ視聴チャレンジをしてみてください。

また、YouTubeが用意している機械的な字幕翻訳を設定するだけでも、ある程度は読める形になっています。とはいえ、年数を重ねても色褪せない良い講演だったので、いずれ手動での日本語字幕を用意できればな…とも思ってます。

おわりに〜ASTERソフトウェアテストチャンネルとJaSSTの宣伝〜

今回はMatt氏の講演をYouTube上に公開することができました。

ちなみに、今回のMattさんの講演については、講演直後ににしさんからこんなツイートを貰っていました。おかわり会ではないですが、今回のような形で公開できたのは本当に良かったなと思っています。

他にも、ASTERソフトウェアテストチャンネルでは、ソフトウェアテストに関する沢山の動画を公開しています。そちらも是非ご覧ください。

また、JaSST（ソフトウェアテストシンポジウム）では、毎年10回以上、全国各地でカンファレンスを開催しています。今回のように動画として残らず、現地に参加した方だけ聞ける講演もありますので、気になる方はJaSSTのサイトもご覧ください。

今月末にはJaSST'25 Tokyoもあります。基調講演は書籍『テストから見えてくる グーグルのソフトウェア開発』『探索的テストの考え方』の著者であるJames Whittakerです。当日は同時通訳付きです！

興味のある方は、以下のページからぜひお申し込みください！

https://jasst.jp/tokyo/25-about/

*1:ちなみに、東京タワーだけでなく、一緒に居酒屋に入って食事もしました。その時にこんな会話をしました。

Matt「美味しいな。これって何？」
私「（えっと、マグロだから…）Tunaだよ！」
Matt「これも美味しいな。これって何？」
私「（えっと、カツオだから…）これもTunaだよ！日本語だと『マグロ』と『カツオ』で名前が違うけど、英語だと明確に名前が分かれてはいないっぽいね」
Matt「そうなのか！」

私「そういえば、BDD関連の日本語訳をするにあたって、CucumberとGherkinの訳が難しかったよ。両方とも日本語では『きゅうり』で一緒だからね。」
Matt「Oh…」
Mattの子供たち「（笑い）」
私「CucumberとGherkinの違いってなんだい？」
Matt「えっと、Cucumberはきゅうりそのもので、Gherkinはハンバーガーに入っているやつだよ。ハンバーガーに入っているやつは日本ではなんと言ってるんだい？」
私「それはピクルスだよ」
Matt「ああ、いや、確かにそれ自体はピクルスなんだけど、ちょっと違うんだよ。」

ということで、CucumberとGherkinを日本語訳するのが難しかったということは伝わった気がします。

テスト設計に生成AIを用いるときの注意点（2025年版）

技術 テスト設計 AI

はじめに

「生成AIをテスト設計で用いた事例が出てきてますが、使う際に注意が必要だと思っています。」という言葉から始めた連続ポストをX上に行った*1のですが、しっかりと記録を残した方が良いと感じたので、本記事を書いています。

ちなみに、一昨年にも生成AIのテスト設計への活用について書いてます。

nihonbuson.hatenadiary.jp

本記事で伝えたいこと

結論は以下の2点です。

  • 生成AIはシレッと嘘を混ぜてくるので、それを見極める力が必要
  • 直交表を用いたテスト設計は苦手？

目次

前提

予めお断りしておくと、

  • 生成AIを使うこと自体を咎めたいわけではない
  • 記事にして発信すること自体は素晴らしい

という話が前提です。

そのうえで今回の記事では、とある記事に書いてあった直交表の使い方に疑問があるので言及していきます。

今回の題材

題材となる記事

この記事の記載について言及していきます。

tech.asoview.co.jp

言及の対象部分

以下の部分が言及の対象です。

因子間の組み合わせテスト

チケットの購入パターンを指示してみます。

以下の因子から組み合わせによる購入パターンのテストケースを作成してください。

結果

特に指示はしていませんでしたが、ChatGPTは組み合わせ最適化のアプローチとして直交表を採用した結果を返してくれました。

テストケース作成に生成AIを導入した効果と課題 - asoview! Tech Blog

直交表の特徴

出力内容が直交表だったので、改めて直交表の特徴を挙げてみます。特に、今回採用しているのは強さ2の直交表のようなので、強さ2の直交表の特徴について挙げます。

  • 二因子間の水準の組み合わせが必ず1回以上現れる（オールペア法の特徴）
  • 二因子間の水準の組み合わせが同一個数現れる

よって、直交表はオールペアの中でも限定された特殊形であると見ることもできます。

指摘内容

今回指摘したい内容は以下の2点です。

  • 水準の組み合わせが適切に作成できていない
  • 適切に直交表を使いこなせていない

指摘内容1：水準の組み合わせが適切に作成できていない

1つ目の指摘は、「水準の組み合わせが適切に作成できていない」です。

今回の対象記事の内容をみると、「二因子間の水準の組み合わせが必ず1回以上現れる」が満たせていません。具体的には、「券種」と「決済手段」の組み合わせとして、「大人」かつ「電子マネー」が出現していないことが分かります。（赤囲み部分）*2

「券種：大人」に対して「決済手段：電子マネー」が存在していない

かつ、出力結果の最後にポイントとして「ペアワイズ法により、2因子の組み合わせは全て含まれる」と書いていますが、このポイントを押さえられていない（嘘の報告をしている）と言わざるを得ません。

指摘内容2：適切に直交表を使いこなせていない

2つ目の指摘は、「適切に直交表を使いこなせていない」です。

今回の直交表の例は、「2水準、3水準、2水準、2水準」です。（決済手段は3種類、それ以外の券種、ポイント利用有無、クーポン利用有無は2種類ずつの水準になっています）

一方、L8は2水準系の直交表です。つまり、今回のように3水準以上の因子が入っている場合に使うことはできません。*3*4

余談

直交表について、個人的には以下のような見解を持っています。

  • 生成AIと直交表は相性が悪いのではないか
  • （現状の）生成AIの作成する直交表は基本的に信じない方が良いのではないか

この点については、以前に記事を書いた時にいただいたはてブのコメントが的を得ていたので、引用します。

AI駆動開発と現状とのギャップを示す - ブロッコリーのブログ

正しさを担保するところを、正しい結果を出すことが苦手なものに頼るってそもそもどうなんだろうね

2023/02/27 19:27
b.hatena.ne.jp

おわりに：専門家でも生成AIの不備を見抜くことが難しくなっている

最後に「生成AIは解法を示してくるが、その間違いを見抜くことは容易ではない」ことをお伝えします。

生成AIでは単純なケースならばある程度正確に作成することができます。「ある程度正確に」というのが肝で、完璧ではないということを意味しています。つまり、それを見抜く力がより重要になってくるということです。

今回はアソビュー！さんの記事に言及しましたが、テスト設計者が生成AIを用いて作成した直交表に対して言及したのは、実は今回が初めてではありません。

それぐらい、テストを生業としている人でもなかなか見抜きづらい部分であるという理解をお願いします。

以上のことに注意しつつ、生成AIのテスト設計への活用を進めてみてください。

*1:そのポストはここから

*2:ちなみに、対象記事には続きとして直交表(L12)によるケースを書いていますが、そこでも「大人」かつ「電子マネー」が出現していません

*3:もしも今回の例に対して直交表を用いてテストケースを作るには、3水準系の直交表である直交表L9を用いると良いでしょう。そして2水準しかない因子については、3水準目の記入欄に1水準目か2水準目の値を入力します。「二因子間の水準の組み合わせが同一個数現れる」という直交表の特徴は失われてしまいますが、「水準の組み合わせが必ず1回以上現れる」というオールペア法の特徴を活かすことはできます。

*4:3/5追記：akiyamaさんから直交表の作成について指摘をいただきました。

個人的には直交表L9だと無駄（任意の値の部分）が多いなと思っていたので、L8の変形は目から鱗でした！

akiyamaさん、ありがとうございました！

Developers Summit 2025で企画作成＆登壇してきました #DevSumi

Developers Summit 技術 勉強会 発表

はじめに

先日のDevelopers Summit（デブサミ） 2025にコンテンツ委員として参加し、登壇も2つ行いました。

event.shoeisha.jp

本記事では、当日を迎えるまでのいきさつなどを書いていきます。

目次

節目節目に立ち会うことができたデブサミとの関係

私が今までにデブサミで登壇したのは以下の通りです*1。

ということで、コロナ禍前最後のデブサミ（Developers Summit 2020）*2、コロナ禍中のオンライン開催のデブサミ（Developers Summit 2022）、コロナ禍後最初のオフライン開催のデブサミ（Developers Summit 2024）という節目節目で登壇を経験させてもらいました。そして今回は、コロナ禍後最初の雅叙園開催のデブサミで登壇を経験させてもらえて本当に嬉しかったです！

初のコンテンツ委員

今回は縁あって*3、コンテンツ委員になりました。

コンテンツ委員の主な仕事は2つでした。

  • 公募枠で採択するセッションの選定
  • 公募枠、スポンサー枠以外のセッションの企画

今回は両方の仕事に関わらせていただきました。

M-1審査のような公募枠セッションの選定

昨年末に公募枠セッションの選定会議が行われました。詳細な選定内容についてはお伝えできませんが、私は「ひと昔前のM-1審査みたいだ…！」と感じてました。

ここでいう、一昔前のM-1とは、立川志らく師匠などがいた頃のM-1です。この頃は、審査員ごとの好みが今よりもバラバラで、審査員間の点数にブレが発生していました。しかし、それでも優勝者は納得の結果になることが多かった印象です*4。

それと同様に、コンテンツ委員それぞれで審査基準が異なっていて、好みが分かれていました。しかし、最終的にはどれも納得して採択できたかなと思っています。結果として、（企画セッションも含めて）非常に多様性に富んだタイムテーブルになっていたと感じています。

自分がやりたい形のセッション企画

今回は自ら企画して2つのセッションを行いました。

event.shoeisha.jp

event.shoeisha.jp

両方とも、納得する形で企画できたかなと思っています。

リーダブルテストコード～メンテナンスしやすいテストコードを作成する方法を考える～

当日の登壇資料はコチラです。

speakerdeck.com

私は以前に「リーダブルテストコード」を題材にしたイベントに登壇したことがあります*5。その時からリーダブルなテストコードには興味関心があったのですが、共に登壇したt_wadaさん、末村さんがそれぞれリーダブルなテストコードについて言及していたのを見て、「これはぜひ一緒に登壇したい！」と思い、企画しました。

ちなみに、今回と同じ3人でJaSST Tokyoにも登壇するので、興味のある方はコチラにもきてください！

開発スピードは上がっている…品質はどうする？ ～スピードと品質を両立させるためのプロダクト開発の進め方とは～

当日の登壇資料はコチラです。

speakerdeck.com

昨年の夏ぐらいから、登壇者の鈴木雄介さんと「『Agile×品質』というテーマで何か一緒に登壇できたら良いね」という話をしていました。

そこから話したいネタは考えていたのですが、2人が喋る形だとどうしても聴講者を置いてけぼりにしてしまう可能性があると気付きました。

そこで、2人の考えをある程度汲み取りつつ、適度に質問し解説もできる人物として、安達さんにモデレーターをお願いしました。

結果として、とても綺麗な形で安達さんに整理してもらえて本当にありがたかったです！

安達さんによる整理（一部）

整理した内容は公開してありますので、こちらもぜひご覧ください！

雄介さん（左）と安達さん（右）に囲まれての集合写真

スピーカー控室という交流場所

当日は2つの登壇の準備もあり、基本的にスピーカー控室にいました。

スピーカー控室では、コンテンツ委員の皆さんや他イベントでご一緒した皆さんと久々の再会をして楽しむことができました。

こういう交流ができるのもスピーカー控室ならではだなと感じています。（ぜひ、公募セッションに応募し、当選して、この雰囲気を味わってほしいです！）

次回以降は同じコンテンツ委員のいくおさんのように、みんなと一緒に写真を撮りまくるぞ…！

懇親会を通じて普段は交わらない人たちとの交流を楽しむ

懇親会、2次会にも参加しました。そこでは、普段の私の参加イベント（主にテスト系やスクラム系）では交わらない方々との交流を楽しむことができました。多種多様なジャンルの参加者と交流できるのもデブサミならではだなーと感じました。

また、旧コンテンツ委員のそーだいさんと、公募セッション選定の方法について情報交換をして、以前との選定方法の違いを聞くことができて、大変嬉しかったです！

おわりに

長々と書いていきましたが、デブサミが多様性に富んだ場であったし、多様性をより加速させることができた回になったなと感じています。

また個人的には、今回のDevelopers Summit 2025は「やり切った！」と言い切れると思っています。ただ同時に、燃え尽き症候群にはならず「次回も関わりたい！」と思えています。

次回は今回よりもさらに良い回にしていきたいと思いますので*6、ぜひ参加した皆さんも、次回の改善に繋げるためにもアンケートの回答をお願いします！また、皆さんの参加レポートもまだまだお待ちしてます！

*1:毎年2月頃に行われているDevelopers Summit（無印）のみを記載しており、Developers Summit Summerなどの派生イベントの登壇は記載していません

*2:Developers Summit 2020はコロナ禍の本当に直前。この回の1週間後には続々とイベントがオンライン開催に切り替わっていきました。

*3:過去のデブサミ登壇や、主催の翔泳社さんで講座を受け持っていた関係からか、今回、運営から声をかけられました

*4:例えばM-1グランプリ2021が印象的です。

この回ではランジャタイの点数が

となり、評価が真っ二つに割れていました。しかしこれは、「誰かの評価がおかしい！」ではなく、この評価の割れ方こそが多様性だと思いましたし、その中で、審査員みんなが納得して優勝に至った錦鯉は本当に素晴らしいと思いました。

*5:その時の登壇資料はコチラ。

speakerdeck.com

*6:まだ次回もコンテンツ委員になれるかは不明ですが

2024年の活動をふりかえる

発表 勉強会 ふりかえり

年の瀬です。

昨年末に同様の記事「2023年の活動をふりかえる」を出して、良いふりかえりになったなーと感じたので、今年もふりかえってみたいと思います。

目次

本業

昨年5月から引き続き株式会社10Xで働いています。

10x.co.jp

品質管理チームのメンバーとして手を動かしている一方、今年の途中からエンジニアリングマネージャーも兼務するようになりました。

10Xでやったことについて詳しくは、先日記事を書いたのでそちらをご覧ください。

nihonbuson.hatenadiary.jp

副業

いくつか副業をさせてもらってます。その中で、公開できるものを記載しておきます。

Graat様でのコンサル業

昨年時点では公開できなかったのですが、実は前々からGraat様でもお世話になっていました。Graat様、電通大のにしさん、私で共同研究をしていました。

主にAgileにおけるテスト活動について議論していました。成果については今年のSQiPシンポジウムで発表がありました。

品質保証活動をアジャイルプロセスに溶け込ませるためのテスト活動の再構築と、それを支えるアジャイル・エンジニアリングの活用

MonotaRO様でのコンサル業

今年からMonotaRO様でテストや品質の相談に乗っていました。

テストプロセスやテスト設計に関する勉強会を開いたり、日々の業務の壁打ち相手になったりしていました。

Aidemy Business講師

株式会社アイデミー様のオンラインDXラーニング「Aidemy Business」の中で、ソフトウェアテストに関するオンライン学習コンテンツを提供しました。

aidemy.co.jp

CodeZine Academy講師

一昨年の秋から定期的に、翔泳社様主催の「CodeZine Academy」というセミナーで講師をしています。

event.shoeisha.jp

今年はオフライン開催も行いました。

ありがたいことに、毎回多くの方にご参加いただいており、3,4ヶ月に1回のペースで開催できてます。次回の開催も計画中です。

ASTER標準テキストを用いた自治体主体のセミナーの講師

自治体主体のセミナーでも講師を務めています。千葉で開催しているセミナーの担当です。こちらも3年目になります。

www.aster.or.jp

年2回開催しておりますが、こちらも毎回満席近くのご応募があります。

社内講演

その他、単発での社内講演もいくつか受け持ちました。

運営

コミュニティ活動を中心とした運営をしています。

WACATE

ソフトウェアテストの合宿型ワークショップ形式勉強会であるWACATEに実行委員長として携わっています。

毎年6月と12月に開催しています。最近はありがたいことに実行委員の数も増えまして、よりチーム運営を意識しながら開催しております。

wacate.jp

レビュー研究会

レビューの体系化を目指して、1ヶ月に1回程度集まっています。もう少しで良い感じに言語化できそうなところまで来ています。

www.aster.or.jp

Developers Summit コンテンツ委員

翔泳社様主催のDevelopers Summit（通称：デブサミ）で、次回の2025年からコンテンツ委員を拝命することになりました。

主に、公募セッションの選定や、招待セッションの企画などで関わり始めました。

執筆

いくつか執筆をしました。

雑誌『Software Design』寄稿

技術評論社様が出版している雑誌『Software Design』に2回寄稿しました。

『Software Design2024年2月号』

テスト設計についての記事を寄稿しました。 gihyo.jp

『Software Design総集編【2018～2023】』

冊子自体は過去の発行の総集編ではあるのですが、今回の書き下ろし特集として、生成AIとテストについての記事を寄稿しました。

gihyo.jp

Findy Engineer Lab 寄稿

Findy様が運営しているメディア「Findy Engineer Lab」にて2つ寄稿しました。

高速道路の出口案内のようなQAエンジニアでありたい ─自動テストより前にやるべきことがあると気づいた話

私の今までのキャリアやQAエンジニアとしての考え方についての記事を書きました。 findy-code.io

あなたのキャリアに影響を与えた本は何ですか？ 著名エンジニアの方々に聞いてみた【第四弾】

オススメの書籍についての記事を書きました。 findy-code.io

Agile Journey寄稿

UZABASE様が運営しているメディア「Agile Journey」にて寄稿しました。継続的テストモデルについての解説と、このモデルから見たシフトレフトなテスト活動/シフトライトなテスト活動についての記事を書きました。

agilejourney.uzabase.com

agilejourney.uzabase.com

登壇

いくつか登壇をしました。

依頼を受けて登壇したもの

運営側として登壇したもの

公募して登壇したもの

Podcast

Podcastも少し収録しました。

10X.fm

私が現在所属している株式会社10XのPodcast「10X.fm」の企画「QA部屋」でモデレーターを務めてます。毎回ゲストを招いて、今までの経歴やテストに関する話をしています。

2024年に出したエピソードは以下の通りです。 open.spotify.com

open.spotify.com

open.spotify.com

おわりに 〜今年のまとめと来年の抱負〜

今回は1年間の活動をふりかえってみました。こうやってふりかえってみると、年々社外活動を増やしているなーと感じてます。また、記事の寄稿が非常に多くなったと感じた年でした。

個人事業主としてのサイトb-testing.netでは、過去の講演実績を時系列順にまとめているのですが、だんだん長くなってきてます。 www.b-testing.net

来年も引き続き、依頼いただいたものは極力受けたいと考えてます。ご依頼は以下でお受けしております。

www.b-testing.net

来年に向けては、今年から継続している内容に加えて、まだ公開できない仕事もいくつかいただいているので、もう少し公開できると良いなーと思ってます。

あと、ここまで来ると法人化しといたほうが良いかもと感じている今日この頃です。

それでは2024年、お疲れ様でしたー！

河野大臣（当時）のポストから西暦のテストについて考える

テスト設計 技術

はじめに

本記事はソフトウェアテストの小ネタ Advent Calendar 2024で投稿することを忘れていたが、2024年に起こった出来事なので、今年中に公開しようとした記事となります。

本記事執筆のキッカケ

当時、デジタル大臣だった河野太郎氏がこんなポストをしていました。

このポストから学べることがいくつかあるので、考えてみたいと思います。

目次

学びその1：上の役職の人が声をあげると最優先課題になる可能性がある点

今回の場合は直属の上長では無いですが、デジタル大臣が声をあげた結果、その課題の優先度が最優先となってしまうかもしれません*1。

このような事象は度々発生します。

課題自体は解決できるかもしれませんが、そこにかける工数によって、他の課題解決に割ける時間が減ってしまうことこそが問題です。

学びその2：主観で課題を述べている点

今回のようなUI面での指摘は、主観で述べていることが多いです。その結果、優先順位を付けるのが難しくなる可能性があります*2。

今回の場合、どうすれば良いのか

QAや専門家が今回の点を指摘する場合は、今回の事象のどのような点が問題なのか/どのような部分をテストすべきか言語化するところから始めるべきかもしれません。

テスト条件

「何をテストすべきか」を示すものをJSTQBでは「テスト条件」と呼びます。*3

今回の場合、生年月日の選択肢に対してのテスト条件を考えてみます

現実的な選択肢を提示しているか

この方が述べている通り、最高齢の方（1908年）よりも昔の西暦を選択肢にする必要はないかもしれません。特に日本の場合は戸籍がしっかりしているので、さらに昔の西暦に更新される（最高齢の方が発見される）ことはないでしょう。また仮に発見されたとしても、その選択肢を使うのは1人だけですので、例外的な運用で処理しても良いかもしれません。

利用者のボリュームゾーンあたりを選択肢としているか

この方が述べている通り、利用者のボリュームゾーンあたりから選択肢が始まっているかを考えてみるのも良いかもしれません。

デフォルトの選択肢を空欄にしているか

より多くの利用者が操作しやすいということを考えると、最初から一番多いボリュームゾーンの西暦を選択した状態で始めるのが良いと考えるかもしれません。しかし、空欄にしていないと、選択するという意図をせずとも次に進めてしまうという別のトラブルが考えられます。

必須項目であり、確定申告という公的書類を作成することを考えると、元々の実装通り、デフォルトの選択肢は空欄であることが好ましいように思えます。

おわりに

今回は河野大臣（当時）のポストを元に、確定申告の西暦選択におけるテストについて考えてみました。

今回の事例には直接当てはまらないかもしれませんが、先日行われたWACATE 2024 冬にて、ユーザビリティの作り込み方についてのワークショップがあったため、参考として貼っておきます。特に資料後半の「人間中心設計によるライフサイクル」が参考になるかと思います。

speakerdeck.com

*1:なお、個人的には全く興味を持っておらず見ていないよりは、河野大臣のように見てもらっている方がありがたいと思います。問題はそれが伝え方によって最優先になってしまう点です。

*2:これは「河野大臣の指摘の仕方が良くない！」と伝えたいわけではありません。専門家でもない一般ユーザーが指摘をすること自体は否定されるものではありません。ただし、専門家が同様の指摘の仕方をしていた場合は改善点がありそうな気がしているので、今回話題にしています。

*3:JSTQBではテスト分析の成果物として定義されています。JSTQBの最新版シラバス（ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02）には以下のように書かれています。

テスト分析の作業成果物には、（優先順位を付けた）テスト条件（例えば、受け入れ基準など、4.5.2 項参照）、およびテストベース内の欠陥についての（直接修正しない場合の）欠陥レポートが含まれる。

10Xに入って1年半でやったこと・感じたこと

ふりかえり アドベントカレンダー

はじめに

10X 2年目のブロッコリーです。この記事は10X アドベントカレンダー 2024の9日目の記事です。

昨日はAnalytics Engineerのtenajimaさんが「入社エントリからの差分、入社1年9ヶ月目の現在地」という記事を公開しています。

10Xの推しポイントは、案件受注前の状況から問い合わせ内容まで、なんでもSlack上で見える状態になっていることです。

本記事では、2023年5月に入社して1年半経った私が、今までどんなことをやってきたのか書いていきます。いわゆる在職エントリーです。自分にとっても良いふりかえりになるかなーと思っています。

目次

在職していてどう感じているのか

最初に、現在在職していての感想を書きます。

入社時に期待していたこと

前職までよりも小さい組織で、開発者やビジネスチームと協働して仕事を進められそうだったからです。また、シフトレフトなテスト活動を目指している点も期待していました。

入社してどうだったか？

入社時に期待していた通りでした！

1人のエンジニアとして見てもらえている

「QAさん」ではなく、「ブロッコリーさん」として、開発者やビジネスチームと協働して進められている気がしています！実際に進めた結果については、本記事の後半部分をご覧ください。

プロダクトをどのように使ってもらえているのか気にしながら開発できている

プロダクトで新しい機能を開発している際、それがどのように使われることになるのか気にしながら開発できています。ただ単に作るだけでなく、「それが機能として使われていることを確認するためにはどういうログを仕込めば良いか」を開発時点で議論して進められているのは非常に良いなと思ってます。

経営陣ともフラットに話せている

経営者ともわりかしフラットに会話できているかなと思ってます。10X アドベントカレンダーの初日を担当したCFOの山田さんとは、日ハムの話題で盛り上がったりしました。もちろん、雑談だけでなく仕事の話もします！

最近は、新規事業関連でCEOのyamottyさんと会話する機会も増えてます。

情報の透明性が高い

冒頭の推しポイントにも書いている通り、様々な経過状況がSlack上で逐一見えている透明性はすごい良いなと思っています。開発するに至った背景情報を知る上で非常に助かってます。

仕事に集中できる環境が整っている

福利厚生も満足しています。特に、子供が病気になったときに、病児保育の費用補助が受けられるのは、仕事に集中できて非常に助かってます。

10Xから転職したい気持ちはあるか

以前の記事で書いている通り、「転職意向が無くてもどんどんカジュアル面談を受けるべき」というスタンスでいるので、転職サービスからのスカウトを受け取ったりもしているのですが、いただいたメッセージと10Xを比較して、改めて10Xで働き続けようと感じています。

ということで、総じて満足して働いてます！

在職中にどんなことをやったのか

上記で在職した感想を書きましたが、ここからは1年半で実際にどんなことをやったのか書き連ねてみます。

テストプロセスを観察した

入社して最初にやったこととして、どんなテストプロセスを経てテスト活動を行っているか観察しました。そしてプロセス改善を試みました。

詳しくは記事にしていますので、そちらをご覧ください。

nihonbuson.hatenadiary.jp

新機能のQAに明け暮れた

テストプロセス改善を行った後は、リリース予定だった新機能のQAを行っていました。開発者やPdMとの距離が近く、分からないところはすぐに聞けたのが非常に助かりました。

実際にリリースした機能はこちらです。切り替え対象となっている「シングルピッキング」の機能開発のQAに携わっていました。

prtimes.jp

パートナーの現場に行ってアプリの利用状況を観察した

2023年10月10日。それは私にとって、10Xに入ってから最も印象に残った日の1つです。

実際に店舗に行き、我々が開発しているアプリを使っている様子を観察しました。

この経験によって、

  • 我々が開発している内容が本当に役に立っているのか
  • 現場での運用上の工夫は何か

などを自分の目で見ることができました。

この経験について詳しくは、カンファレンスの登壇資料に記載しました。

speakerdeck.com

Feature Flagを活用するようになった

2024年に入って、Feature Flag(Toggle)を積極的に活用するようになりました。

できるだけmainブランチとの差分を少なくするためにRelease Flag(Toggle)として活用したり、少しずつ計画的にパートナーへ適用するためにOps Flag(Toggle)として活用したりしました。

詳しくは、以下の執筆記事にまとめたので、そちらをご覧ください。

agilejourney.uzabase.com

QAのEMになった

2024年の下半期には、QAチームのEMにもなりました。

普段の業務もこなしつつ、どうすればQAチームメンバーが良い方向で進めていけるかを考えていきました。

詳しくは先日12/4にイベントで発表したので、その資料をご覧ください。

speakerdeck.com

新規事業のQAも担当した

現在は、新規事業のQAも担当するようになりました。

こちらについてはまだまだこれからなので、何も示せるものがないのですが、日々新しくなっていくアプリに対してのQAを考える毎日です。

実際に新規事業の開発をしているみんなでワイガヤしている様子は以下の記事内の写真にあります。

product.10x.co.jp

Podcastのホストになった

10Xが運営しているPodcast「10X.fm」の企画の1つ「QA部屋」のホストになりました。

QA部屋の最新エピソードはこちらです。

open.spotify.com

おわりに

今回は入社して1年半でやったことをつらつらと書いてみました。

こうやってふりかえってみると、業務はどんどん行いつつ、やったことに対してアウトプットを示してきた1年半だったなーと思えました。

10Xではソフトウェアエンジニアを募集しているので、今回の内容を見て「興味がある」「一緒に働いてみたい！」と思った方は、ぜひ採用ページもご覧ください。

ソフトウェアエンジニア(SWE) / 株式会社10X

テスト自動化の前に大切にしていることについて発表してきた

アドベントカレンダー 技術 発表 勉強会 BDD

はじめに

この記事はソフトウェアテスト Advent Calendar 2024の8日目の記事です。

昨日、登壇してきました

昨日、ソフトウェアテスト自動化カンファレンス2024というイベントで登壇してきました。

登壇資料はこちらです。 speakerdeck.com

「振る舞い駆動開発（BDD）におけるテスト自動化の前に大切にしていること」と題して、BDDにおける大切な「発見(Discovery)」と「定式化(Formulation)」について発表してきました。

今回の発表を行ったきっかけ

今回このような発表を行った理由は、BDDについて考えている人たちが訴えているBDDの3つの要素が、あまり世の中に浸透していないと感じているからです。

特に、BDDというと「自動化(Automation)」の部分ばかりに目が行きがちですが、それ以前に「発見(Discovery)」と「定式化(Formulation)」を行うことの重要性も今回強くお伝えしました。

発見(Discovery)では、具体例を重視する

発見(Discovery)では具体例を用いることが大切であることを伝えました。

登壇資料には載せられていませんが、発表時に示した具体例の大事さを伝える動画は、Cucumber School Onlineにて無料で見れますので、気になる方はこちらをご覧ください。

school.cucumber.io

もしくは、YouTube上でも一部公開していますので、そちらをご覧ください。

www.youtube.com

定式化(Formulation)ではシナリオを改善する

定式化(Formulation)では読みやすいシナリオ作成に注力することが大切であることを伝えました。

その中でBRIEFの原則について紹介しました。

BRIEFの原則については、過去に当ブログで紹介しているので、そちらもご覧ください。

nihonbuson.hatenadiary.jp

今回の発表では、以下のテストシナリオの改善を試みました。

改善の過程は今回の発表資料をご覧ください。

おわりに

今回はソフトウェアテスト自動化カンファレンス2024で発表した「振る舞い駆動開発（BDD）におけるテスト自動化の前に大切にしていること」の中身を紹介しました。

個人的に今回の発表の考え方は、BDDだけに限らず、自動テストを作成する上でも大事な考え方かなと思っています。

以前に「テストコードにはテストの意図を込めよう」という発表で、「自動テストはテストプロセスのテスト実装を注力しがち」「自動テストを作成する際にも、テスト分析やテスト設計を考えよう」という話をしました。

今回のDiscoveryやFormulationを大事にしようという話に通ずるところかなと感じています。

ぜひ、BDDを利用している人もそうでない人も、自動化の前にDoscoveryやFormulationのような考え方を取り入れてみてください。