Nihonbashi Test Talk #4 に参加しました。
イベントの概要
日本橋・馬喰町近辺の会社でソフトウェアテストの話をする会です。
第4回はAutifyの会場で、Autify、10X、Ubieの3社＋LT枠で15分程度の短いトークをやります。
引用：
nihonbashitesttalk.connpass.com
イベント参加の背景
- QA、テストに対しての解像度をあげたい。
- 登壇者の方たちのアウトプットに大きな学びを頂いている。
- そんな方たちのお話を近くで聞けるだなんて！と参加！
Nihonbashi Test Talk
-
QAも知っておきたいマーケティングの話
Autify末村さん。
■メモ
エンジニアで働くとレバレッジの効く働き方ができないという思いから、
品質、QAの領域のエバンジェリストに。
マーケターになったことで、主戦場が変わった。
QAの主戦場はポストセールス。品質は使ってみるまで分からない。
マーケターの主戦場はプリセールス。購入に至るまでの説得。
マーケターの武器。カスタマージャーニーマップ。
プロダクトのターゲットとなる中央値のペルソナを使ってシミュレーションする。
たくさん売る、継続してもらう、どちらを優先する？
NRR（Net Retention Rate、売上継続率）を参考にする。
バグが無ければ売れる訳ではない。
売れていれば品質が高い訳ではない。
品質が低くても売れるものがある。
なので、適切な指標にのっとって会話をする必要がある。
参考：Tangible Software Quality, with Gojko Adzic
品質保証を従来の指標から離れｍ多角的な指標で説明をする必要がある。
他参考。Gojkoといえば、過去のAgile Testing Daysの動画が日本語字幕付きで公開してますーhttps://t.co/jfdMXKyQNx#nihonbashitesttalk
— broccoli (@nihonbuson) 2025年5月22日
■感想
プロダクト開発で本当に求めるべきものがビジネスの成功だとした場合、従来の品質指標では不十分であり、多様な側面で品質を捉える必要があることを理解しました。
少し前まで、管理していた案件でケース密度やバグ密度を一生懸命整理していたけど、改めて儀式になっていたと反省しました。
そのうえで、目的に見合った指標で品質を判断することで、プロダクトの品質に対してチームが主体性を持って取り組むことができると理解しました。
■お知らせ気になってカートに眠っております。
- なぜ採用のJSTQB FLの資格保有を"必須"ではなく"推奨"の応募資格としているのか
10Xさんブロッコリーさん。
最近マルチプロダクト戦略に。
■メモ
JSTQB FLを応募資格の推奨に。
・資格取得≠業務活用
実際の業務でどう活用するかが重要。資格取得より勉強が重要。
・資格より求めていることが明確にある
資格に必要のない範囲がある。必要な範囲が無い。JSTQBは最大公約数。
・共通言語として知っておくことは重要
10xが求めているQA能力は、
・テスト設計スキルと説明能力
・積極的な議論とコミュニケーション能力
・テストを通して相手に納得してもらうこと
参考：https://qualab.jp/materials/stdc-kansai2012.121103.bw.pdf
■感想
共通言語と専門性の重要性。
資格名に依らず求める人物像を明瞭化できることは、とても重要なことであると改めて理解しました。
そのうえでも、【テストを通して相手に納得してもらうこと】はとても重要な要素だと理解しました。西さんのPDFもちゃんと読みたい。 - Ubieの開発者に「みんなに理解してほしいQAの話」をした話
Ubie Mayさん。
■メモ
QAやテストについての疑問を投げかけるMTGを開催し、自企業内でのスタンスを明らかにした。
QAは開発ライフサイクル全体での取り組み。みんなでやる。
QA＝品質保証。QAエンジニアのことではない。QAエンジニアはQAの専門家。
QAはユーザーの信頼を築く礎。安定した事業成長を支える土台。Giant Leapを後押しする安全網。安心してアクセルを含むための役割。
価値提供を最大化するためのカギ。
ユビーのQAに求められるのはKeep Full Throttle。
価値提供を最大化するために各品質がどの程度必要かを意識する。
そのための原則。
原則１：品質は全員で達成する
原則２：品質は目標を達成するための手段。ROIで判断でする
原則３：QA活動はライフサイクル全体で変化に強く
原則４：学び続けて、プロセスを改善する
原則５：専門知識とツールを活かしてQAを加速する
参考：
※当記事内にUbie Quality Assurance ガイドありました。
■感想
QAとは何か、どんな役割なのか、何を目的としているのか、そのために何をするのか。
そうした認識を組織全体で揃えることはとても重要だと思いました。
改めて品質保証をサイロに閉じ込めるのではなく、関係者全体で取り組んでいくことと、そのための巻き込みが重要であると認識しました。 - いまあらためて読み返したい、バイザー本
■メモ
バイザー本。
テスト担当者の成熟モデル。レベル０～４。
一番上はテストしやすいソフトウェアを目指す。
生成AIもこの成熟モデルにあてはめて考えることができる。
■感想
この本と自分が生まれた年が一緒なことに驚きました。
その頃の指標が生成AIに適用可能ということは、どれだけ普遍的な軸になっているのか。
懇親会
ブロッコリーさんにお声がけして、今日の講演や実例マッピングについてお聞きしたかったことをお伺いしました。
たくさんのお時間頂いてしまいありがとうございました。
お話させて頂いたことを通しての気付きのメモです。
- テストを通して相手に納得してもらうこと
相手は個人ではなく、チーム。
質問を通して、考え、整理し、回答するというプロセスを導くだけでも価値がある。
回答するという開かれたアクションにより、第三者への共有も生まれる。
回答に対する第三者からの見え方を気づきとしてチームに与えることで具体的な像に近づけることができる。
チームの認知を揃えることで、チームにオーナーシップが生まれる。 - 実例マッピングの適用について
まずは具体例を出すことが重要。
具体例が出ないのだとしたら、プロダクトやステークホルダなどに対する解像度をあげる。
具体的ではなく、抽象的な具体例を出すと、「恐らくこうだろう」という思考に引きずられる。
BDDの進化はGarkinやそれによるテスト自動化ではなく、ふるまいを保証できること。
ふるまいとは使われ方であり、使い方ではない。
実例マッピングを通して関係者でふるまいに対する認識を揃えていくことで、プロダクトに求められる要求を捉えることができる。
まとめ
多くの気づきと学びを頂いたイベントでした。
特に登壇者の方たちのアウトプットにいつも学びを頂いていたので、それを直接お聞きできることは嬉しかったし、
何よりもブロッコリーさんに懇親会でいろいろお話お伺いできたのは自分の認知をブラッシュアップできる最高の時間となりました。ありがたい。。
帰り際に末村さんにサインを頂いてしまいました…！
もしチャンスがあればと鞄に忍ばせていたので嬉しい。。
自分のQAに対する理解の扉を開いてくれたのは末村さんのイベントだったので、本当に感謝してもし足りないです。
次回も是非参加したいです。
