JaSST'25 Niigata レポートと振り返り（ロング版）
JaSST'25 Niigataに参加してきました。
お誘いいただいて感謝
この度は、素晴らしい場にお誘いいただき、またスポンサーセッションとLT会という2度もの登壇機会を賜り、誠にありがとうございました。
お声がけいただいたおかげで、自身の考えを多くの皆様と共有し、また素晴らしいセッションから学びを得ることで、自らのQAへの思いをさらに解像させることができました。このような刺激的で実りある一日を過ごせたのも、ひとえに運営の皆様、そして温かく迎えてくださった参加者の皆様のおかげです。
この場を借りて、改めて心より感謝申し上げます。ありがとうございましたmm
会場に行くまで
私は成田空港の近くに住んでいるため、まずは京成線で上野まで。
早朝のスタバで新幹線までの時間を潰します。
早朝の上野も軽くパシャリ。
左上に見える「大統領」という居酒屋は当QAチーム随一の 酒ヤクザ 酒お姉様とよくいきます。
新潟についてから上司&デザイナーと真っ先に行ったのは「回転寿司 佐渡弁慶」。
人生で食ってきた回転寿司で一番美味いです。これはガチ。
どうやら弁慶グループ？と言う感じでいろんなお店を出しているようで、元バンドメンバーの地元民から若旦那も美味しいよ！と教えてもらいました。
特にウニが、北海道旅行で食べた時のウニと全然変わらないレベル。こんなに濃厚なウニは久々に食べました。
と言うわけで、美味しすぎるランチで気合いを入れて会場入り。
JaSST'25 Niigataセッション振り返り：『デザインから考えるアプリにおける品質とは？』
フラー株式会社 取締役CDO 櫻井裕基氏によるセッション「デザインから考えるアプリにおける品質とは？」です。
本セッションは、アプリの「品質」を機能的な側面だけでなく、デザインの視点から多角的に捉えた内容です。QAとしての自身の役割を改めて考えさせられるような内容でした。
1. アプリとは何か？ ― Webとの違いから見るアプリの本質
セッションは、まず「アプリとは何か」という根本的な問いから始まりました。WebがURLで容易に共有・拡散できるのに対し、アプリはストアでのインストールが必要で、よりコアなファンに向けたプロダクトであるという位置付けが語られました。
特に印象的だったのは、アプリが「プラットフォーム依存」であるという点です。OSのガイドラインへの準拠が求められ、ストアの審査という避けては通れないプロセスが存在します。また、オフラインでの利用も想定する必要があり、これらはWebプロダクトとは異なる複雑なテストケースを生み出す要因となります。ネイティブな機能を活用したインタラクション（ハプティクスなど）を提供できる点はアプリならではの魅力であり、OSの世界観を深く理解した上での設計が不可欠であると再認識しました。
2. 「良いアプリ」を構成する6つの品質要素
櫻井氏は、良い（品質の高い）アプリを実現するための要素として、以下の6つを挙げました。
- 認知性: 見つけてもらえるか
- 利用適合性: 使われる状況があるか
- 信頼性: 正常に動作するか
- ユーザビリティ: 使いやすいかどうか
- 情緒性: 魅力的かどうか
- 持続性: 進化し続けているか
この中でも特に深掘りされた「認知性」「利用適合性」「情緒性」「持続性」についての学びは大きいものでした。
-
認知性（見つけてもらえるか）
膨大な数のアプリの中からユーザーに見つけてもらうためには、覚えやすく呼びやすい名前、記憶に残りやすいアイコン、そしてスクリーンショットで価値が直感的に伝わるストアページが重要です。広告から利用体験まで、世界観が一貫しているかというブランディングの視点は、アプリに限らず全てのプロダクトに通じる重要な観点だなと感じました。 -
利用適合性（使われる状況があるか）
多様化した現代において、単一のペルソナでユーザーを定義することは困難です。そこで提唱されたのが、ペルソナではなく「ユースケース」でユーザーを捉えるアプローチです。ゴールに即してユーザーを分類し、そのユースケースを「主なケース」「レアケース」「クリティカルケース」のようにレベル分けする手法は、非常に実践的だと感じました。私もテスト設計においては抽象度で分けたり、グルーピングしたりなどをしているので、近いものを感じました。このような考え方は、私たちが担当するプロダクトのユーザー像を捉え直す上でも有効だと思いました。 -
情緒性（魅力的かどうか）
「バグがなくても退屈なら次は開いてもらえない」という言葉が象徴するように、機能的な正しさだけではユーザーを惹きつけられません。心地よいハプティクス（触覚フィードバック）や、例えば「あすけん」のお姉さん（名前なんて言うんですか？）のようにユーザーとのコミュニケーションをデザインすることが、継続利用を促す「情緒的な品質」に繋がります。これはゲームデザインにも通じる考え方であり、QAとしても「使っていて心地よいか」という視点を持つことの重要性を感じました。特に、デザイナー視点では意図して作ったものであるため作成者視点のバイアスがあると思います。QAという視点から何か提供できることを探したいと思いました。
やはりキャラクターがいるというのは大事なことです。
-
持続性（進化し続けているか）
OSのアップデートや技術の進歩といった外部環境の変化に常に追従し、進化し続けることがアプリの品質を維持する上で不可欠です。これはWebプロダクトにおいても同様であり、常に学び続け、プロダクトを改善し続ける姿勢が求められると思いました。
3. まとめ：QAとしてどう向き合うか
本セッションを通じて、アプリの「品質」とは、不具合の有無といった静的なものではなく、ユーザーにいかに見つけてもらい、価値を感じ、心地よく使い続けてもらうかという、ビジネスや体験価値を含む動的な概念であることを深く理解しました。
時に、「Quality is value to some person at some time」という言葉がありますが、私は「Quality is value」と言う言葉よりも「to some person at some time」が一番大事だと思っています。なぜなら、品質とは誰が使うのかによっても、いつ使われるかによっても変わると考えているからです。それはプロダクトを触った時点のスナップショットだけでなく、プロダクトのフェーズや事業のフェーズによっても求められる品質は変わると考えています。それだけに非常に共感できる内容でした。
「60点を120点にするのは人間の仕事」というお話があったと思います。AIによる自動化が進む中でも、こうした情緒的な価値や細やかなディテールを追求し、プロダクトの魅力を高めていく領域には、私たち人間の介在価値が確かに存在すると思います。
QAのカンファレンスでこれほどデザインに踏み込んだ話を聞けたことは非常に新鮮であり、デザイナーとQAがより密に連携し、ユーザーの体験価値という共通のゴールに向かって協力していくことの重要性を再認識する、大変有意義なセッションでした。
JaSST'25 Niigataセッション振り返り：『自分たちがターゲットになりにくい業務アプリケーションのユーザビリティを担保する取り組み』
続いて、freee株式会社の森川裕美氏による「自分たちがターゲットになりにくい業務アプリケーションのユーザビリティを担保する取り組み」です。
本セッションは、会計士や税理士といった専門家向けの「記帳機能」という、作り手自身がユーザーになり得ないニッチなドメインにおいて、いかにして高いユーザビリティを担保したかという事例紹介でした。
1. 「使いやすさ」の解像度を上げる
セッションは、「体験が大事」といった曖昧な言葉に対し、「ここでいう『体験』とは何か？」と問いから始まりました。森川氏はISO/JIS規格を引用し、ユーザビリティが「特定のユーザー」が「特定の利用状況」で目的を達成する度合いであるとしました。これは、"You Are Not the User"という原則がより強く働く専門業務アプリケーションにおいて、開発の根幹をなす考え方だと思いました。
特に、ユーザーの業務を代替するアプリケーションは、その「道具」を作ることでユーザーの業務プロセス自体を規定してしまう責任が伴う、という指摘には身が引き締まる思いでした。
2. ユーザーを「知らない」から始める、ユーザーのナラティブへ橋をかけるプロセス
-
ユーザー理解と業務観察
まずビジネス上のターゲットセグメント（キャズム理論）を明確にし、社内の有識者へのヒアリングからドメイン知識を吸収。そして、最も重要だと感じたのが、実際の会計事務所に赴いての業務観察です。
会計士がマウスをほとんど使わず、キーボードのテンキーを駆使して「バチバチ打つ」という、文字情報だけでは伝わらない速度感やリズム。この「当たり前品質」をチーム全員で肌で感じられたことが、後の設計思想に大きな影響を与えたことが伺えました。 -
要求の明確化と設計
観察から得た要求を具体的な仕様に落とし込むために 「実例マッピング」 が用いられました。実例マッピングにより、チーム内での認識齟齬を防ぎ、リスクや異常系を早期に洗い出すことができたといいます。このセッションではQA的なネタが所々で語られていて、なんて勉強家なのだろうとすごく感動しました。 -
リリース前の徹底的な検証
業務アプリケーションは一度導入されると乗り換えコストが高いため、「初見バイバイ」を避けることが極めて重要です。特に 「定常業務に乗るUIはリリース後に変えづらい」 という言葉は、変更コスト曲線を想起させ、リリース前のユーザビリティテストの重要性や上流からの作り込みの大切さについて改めて認識させられました。
3. まとめ：QAとしてどう越境していくか
本セッションはデザイナーの事例でしたが、聴講しながら「もし自分たちのプロダクトでもこのプロセスで進んだとしたら、QAはどう関われるだろうか」という問いが常に頭にありました。ユーザーの業務を観察し、実例マッピングで仕様を具体化する。これらはまさに、品質保証活動を上流工程にシフトさせるための大切なアクションプランだと思うからです。
デザイナーやPdMとQAの間に明確な責任分界点を設けるのではなく、互いにボールを拾い合いながら、ユーザーの業務達成という共通のゴールに向かう。そのために、私たちQAもドメインを深く学び、ユーザーの元へ足を運び、開発プロセスへ積極的に越境していく必要があると強く感じました。
「使いにくいとは何か？」という問いに真摯に向き合い、泥臭くも体系的なアプローチで答えを導き出した本事例は、専門領域のプロダクト開発に携わる人たちにとって、大きな勇気を与えてくれる素晴らしい内容だったのではないかと思います。
JaSST'25 Niigataセッション振り返り：『一次体験を起点にしたUX改善の取り組み』
最後のセッションとして、株式会社ビットキーのNatsuho Ide氏による「一次体験を起点にしたUX改善の取り組み」を聴講しました。
本セッションは、「品質の高いプロダクトを作る」というデザイナーとQAの共通目的を達成するために、ユーザー理解の根幹となる「一次体験」の重要性を、具体的な取り組みと共に紹介するものでした。
1. 共感の起点としての「一次体験」
Ide氏は、良いユーザー体験（UX）の創出は「ユーザー理解」から始まると述べ、そのための最も強力なアプローチとして 「一次体験」 という考え方を定義いただきました。これは、作り手自身がユーザーとしてプロダクトを実際に使ってみたり、利用される現場に身を置いたりすることを指します。
観察やヒアリングといった手法でユーザーを理解することを補完しつつも、自らがユーザーになりきるような深い共感は、この一次体験によってこそ得られるというメッセージは、非常に説得力がありました。
2. ハードウェアが絡むからこそのリアルな取り組み
ビットキー社の取り組みが特に興味深かったのは、スマートロックというハードウェアとソフトウェアが融合したプロダクトならではのリアルです。
-
ドッグフーディングの実践: 自社オフィスに自社サービス
workhubを導入し、開発メンバー全員が日常的にユーザーとしてサービスを体験する。 - 現場での一次体験: 新築マンションでのスマートロック設置作業を体験することで、ソフトウェアの画面設計だけでは想像し得ない「手が塞がっている」「通信が不安定」といった物理的な制約や環境要因を発見する。
- QAチームによる徹底した体験: QAチームのメンバーが1ヶ月間スマートロック付きの物件に住み込み、入居者としての生活を丸ごと体験する（QAエンジニアとしてこのような体験ができることって本当にすごいことだと思います）。
これらの活動は、机上の空論ではない、地に足のついたユーザー理解です。特に、雪国や雑居ビルといった多様な環境での利用を考えると、こうしたフィールドテストに近い一次体験から得られる知見は、ユーザーにとっての品質について考える上で不可欠だと感じました。
3. QAも当事者へ。誰にでもできる品質向上の一歩
本セッションは、QAが「一次体験」の重要な担い手として描かれていた点が印象的でした。先のfreee社のセッションが「観察」による業務理解に焦点を当てていたのに対し、ビットキー社はQAも含むチーム全員での「体験」を重視しており、ユーザー理解へのアプローチの多様性を学ぶことができました。
認知的ウォークスルーや実際の利用環境でのテストは、テストケースをなぞるだけでは見えてこない「使いにくさ」や「心地よさ」といった情緒的な品質を評価する上で極めて有効だと感じました。
4. まとめ：共感でチームの壁を越える
「一次体験は、特別なスキルがなくても誰にでもできる品質向上の一歩」。このセッションの結論は、私たちに大きな勇気を与えてくれます。
デザイナーとQAがそれぞれの持ち場で仕事をするのではなく、「ユーザーへの共感」を共通言語として連携していく。そのための最もシンプルで強力な武器が「一次体験」であると、本セッションを通じて強く認識しました。チーム全体でユーザーになりきることで、私たちはもっと一緒に、プロダクトの品質を高めていけるはずです。
JaSST'25 Niigata スポンサーセッション登壇を振り返って（自身の振り返り）
この度、JaSST'25 Niigataにて「『テストの知識』と『バグの知識』」というテーマで登壇させていただきました。ご清聴いただいた皆様、誠にありがとうございました。
結構緊張しまして、バンドマン時代を思い出すようなドキドキ感でした。
自身の発表を振り返ると共に、同日に聴講した3つの素晴らしいセッションとの共通点から得た学びをまとめたいと思います。
発表内容の要約：『テストとバグの考え方』
本発表は、アジャイル開発におけるQAの役割を再定義し、より質の高いQA活動を実践するための2つの重要な概念、 「テストの知識」 と 「バグの知識」 について解説するものです。
まず、テストとは単なる機能検証ではなく、 「分からないことを試して確かめる」 ための、人間が学びを得る広範なアクティビティであると定義します。
私たちが「分からない」と思える範囲は、ドメイン知識だけではなく、チームの文化やその人の癖といったものや、法律や社会通念といった自身の「知識」に強く依存します。知識がなければ、そこにリスクやチャンスがあること自体に気づけません。
1. テストの知識：テストの範囲を拡張する
上記の考えに基づき、QAが持つべき「テストの知識」として、テストの対象を以下の3つの領域に拡張します。
- 製品の「品質」のテスト: 正しく製品を作れているか (機能、性能、セキュリティなど)
- 製品の「価値」のテスト: 正しい製品を作れているか (課題解決の妥当性、市場受容性など)
- 開発の「プロセス」のテスト: 正しいやり方で作れているか (チーム連携、プロセスの健全性など)
この広い視野を持って様々なことをテストと捉え、QAは企画からリリースまで全ての工程に「継続的テスト」として関与し、顧客にとっての真の品質に貢献できます。
2. バグの知識：ユーザーが直面する問題の根本原因を深く探る
次に、バグとはコードの不具合だけでなく、 「ユーザーが体験するあらゆる不利益」 そのものであると定義します。
ユーザーが直面する表面的な問題の根本原因は、より深い階層に潜んでいます。この構造を体系的に理解するためのフレームワークが「バグの5階層」です。
- 第1階層：製品・サービスのバグ (コード、設計、UI/UXの欠陥)
- 第2階層：プロセスのバグ (開発プロセス、品質管理、コミュニケーションの欠陥)
- 第3階層：事業・戦略のバグ (ビジネスモデル、KPI、リソース配分の欠陥)
- 第4階層：組織・文化のバグ (企業文化、評価制度、意思決定プロセスの欠陥)
- 第5階層：社会・市場のバグ (法律、市場構造、社会通念の問題)
この深い視座、すなわち「バグの知識」を持つことで、QAは表面的な事象の奥にある本質的なリスクを発見し、先回りして対処することが可能になります。
例えば、テスト中に「商品の単価が見えてしまう」という問題を発見したとします。
- 開発者に確認すると「仕様通り」だが、ユーザー視点では不利益です。これが第1階層：製品・サービスのバグです。
- 「なぜテストまで誰も気づかなかったのか？」と掘り下げると、「仕様検討時のコミュニケーション不足」といった第2階層：プロセスのバグが見えてきます。
- さらに「なぜそんな仕様でOKになったのか？」を考えると、「まずこの価格で売るという事業戦略があった」という第3階層：事業・戦略のバグに行き着くかもしれません。
- もっと深く「なぜユーザーに不利益な戦略が通るのか？」まで考えると、「『ユーザーファースト』という理念の形骸化」といった第4階層：組織・文化のバグが見えてきます。
このように、深くまで原因を考察すると、QA一人の力では解決できない深い問題もあります。ですが1人のQAとして、問題を発見したら、解決のためにチームを巻き込んでいくことが重要です。この深い視座、すなわち「バグの知識」を持つことで、QAは表面的な事象の奥にある本質的なリスクを発見し、先回りして対処することが可能になります。
5分で話しきれなかったこと： 知識を武器に「試す」ことで貢献する
「テストの知識」と「バグの知識」は、特に探索的テストにおいて、より多くの「分からないこと」を発見し、価値ある「学び」を得るための強力な武器になると思います。
自社で独自に実践している事前準備手法 「MAX (Modular Agile eXploration)」 があるのですが、まさにこの2つの知識を活用してテストを作戦盤に落とし込み、チームでの議論を通じて正しいモノづくりを推進するための仕組みです。ちょっと怖いですが、いつか発表してみたいと思います。
結論として、QAは広い視野（テストの知識）と深い視座（バグの知識）を常に意識し、積極的に「試す」ことで、チームとユーザーに貢献し続けるべきである、というのが本発表の要旨です。
自身の発表と3セッションに共通する思想
私の発表では、QAが持つべき視点として、テストを「分からないことを試して確かめる」広範な活動と捉える 「テストの知識」 と、ユーザーの不利益を多階層で捉えリスクを先回りする 「バグの知識」 を提唱しました。
奇しくも、今回聴講したフラー櫻井氏、freee森川氏、ビットキーIde氏のセッションは、それぞれ異なるアプローチを取りながらも、勝手ながら私の考えともシナジーを感じる部分がいくつかありました。
3つのセッションに共通していたのは、「ユーザーの不利益」を広く捉え、それを発見するために能動的に検証しようとする姿勢 です。
- 機能不全だけでなく、「見つけてもらえない」「退屈で使われない」といった体験的な損失も品質の問題と捉える視点（櫻井氏）。
- 仕様書を待つのではなく、自らユーザーの業務を「観察」し、業務のリズムを阻害する要因を突き止めるアプローチ（森川氏）。
- 開発チーム自身がユーザーとして「一次体験」することで、身体的な不便さや心理的な不快感を自分ごととして発見する文化（Ide氏）。
これらの活動は、まさに私がセッションの中で話した広い視野や高い視座（深い視座）の実践であり、ユーザーの不利益を「バグ」と定義し、その根本原因を探る試みだなと感じました。今回の事例発表の数々を通して、私の考えが独りよがりではなく、業界の先進的な取り組みにも似ている部分があると感じられて、とても安心しました。
まとめ：QAとして、私たちは何をすべきか
今回の登壇と聴講を通じて、QAが目指すべき方向性を改めて再認識しました。
私たちのチームが目指すQAは、 「テストの知識」 を武器に、機能検証の枠に留まらず、例えば今回のセッションに登場したユーザーインタビューや業務観察、一次体験といったあらゆる活動も「テスト」と捉え、企画からリリース後の改善まで積極的に関わっていくということです。そして、 「バグの知識」 を使って、ユーザーが直面する表面的な問題から、その根源にあるプロセスや事業の課題にまで視座を広げ、本質的な品質向上に貢献しなければならないと考えました。
そのためにはQAエンジニアたった1人だけで解決すると言うことは難しく、どうやって周囲を巻き込んで解決していくのか？ということが大切です。
今回のJaSST'25 Niigataは、そのための具体的なアプローチと、明日から実践するための大きな勇気を与えてくれる、非常に有意義な一日となりました。
JaSST'25 Niigata LT会登壇を振り返って（自身の振り返り）
はい、なんと2回もお話させていただきました（笑）
JaSST'25 Niigataでは、スポンサーセッションに続き、LT会にて「テストケースが思わず叙述トリックになってしまうかも！？」というテーマで登壇させていただきました。ご清聴いただいた皆様、ありがとうございました。
また、発表後に内容に突っ込む形でとっても深いトークセッションを展開していただくことになってめちゃくちゃびっくりしましたことと、とっても楽しい時間になりました。皆様、ありがとうございました。
LT発表の要旨：「冷蔵庫の牛乳」と探索的テスト
こちらの記事をスライドにする形で今回発表させていただきました。
私の発表では、「冷蔵庫から牛乳を取ってきて」と頼まれた際に、多くの人が「白い紙パック」を想像し、もし牛乳が「ガラスボトル」に入っていたら見逃してしまう、という日常的な例え話を起点としました。
これは、人間の認知が先入観に縛られやすいことを示しており、ソフトウェアテストにおいても同様の現象が起こります。テスト手順書は、確認すべき項目に注意を集中させる一方で、それ以外の予期せぬ問題（フォントの違和感など）を見逃す「手順書の呪い」を生む可能性があります。
これに対し、探索的テストは特定の観点に縛られず、「何かおかしなことはないか？」という広い姿勢でソフトウェアと向き合います。これはまさに、仕様書という「紙パック」の思い込みから自由になり、ユーザーの体験全体という「冷蔵庫の中身」を隅々まで確認する行為です。探索的テストとは 「先入観から自由になるプロセス」 であり、だからこそ予期せぬバグを発見しやすい、というのが発表の要旨でした。
探索的テストとは自由にやって良い、と言うようなイメージに受け取ってしまった可能性があり、発表の仕方が非常に悪かったなと思いました。反省しております。
JaSST'25 Niigataに参加して 〜品質を追い求める僕たちは、どこへ向かうのか〜
今回のJaSST'25 Niigataでは、スポンサーセッションとLT会の登壇者として、そして一人の聴講者として参加させていただきました。この一日を通じて、私が漠然と抱いていた「これからのQAの在るべき姿」について、大きな勇気を得ることができました。
地図から現地へ：3つのセッションが示した共通の方向性
これら3つのセッションは、アプローチこそ違えど、一貫したメッセージを私たちに投げかけていたように感じました。
それは、 「仕様書をなぞるだけでは、本当の意味での品質にはたどり着けない。ユーザーが生きる『今の場所』に直接赴き、その中で彼らの文脈の中で品質を探求してほしい」 というメッセージです。
彼らが「現地」で発見していたのは、コードの不具合といった分かりやすい「バグ」ではありませんでした。「なんとなく使いにくい」「業務のリズムが悪い」「心地よくない」といった、ユーザーが体験する言語化や定量化が難しい 「不利益」 や 「違和感」 です。
私たちの武器：「テストの知識」「バグの知識」そして「探索的マインドセット」
この潮流の中で、私たちQAはどう振る舞うべきか。その問いに対する私なりの答えが、今回発表させていただいた内容にありました。
スポンサーセッションで提唱した 「テストの知識」 は、こうした観察や一次体験といった活動すら「テスト」として捉え、QAが様々なフェーズに積極的に関与するための理論的支柱となります。そして 「バグの知識」 は、発見した「不利益」の根本原因を、プロセスや事業戦略、組織文化にまで遡って考察するためのフレームワークです。
さらに、LT会で話した「冷蔵庫の牛乳」の例えは、この一連の活動を実践するための心構えを象徴しています。仕様書という「紙パック」の思い込みから自由になり、ユーザーの体験全体という「冷蔵庫の中身」を隅々まで見ようとする探索的マインドセット。これこそが、手順に描かれていない「ガラスボトルの牛乳」、すなわち予期せぬ品質問題を発見するための鍵なのです。
さいごに
今回のJaSST'25 Niigataは、現代のQAに求められている役割が、もはや単なる「バグを見つける専門家」ではなく、 「ユーザーの成功を支えるための追い風」 であることを明確にしてくれたような気がします。
そのためには、仕様書だけの世界から一歩踏み出し、ユーザーの文脈に飛び込む勇気が必要だと思いました。今回のカンファレンスは、その勇気と、具体的な武器（知識、手法、マインドセット）を与えてくれる、非常に有意義な一日となりました。
最後になりますが、素晴らしい発表をしてくださった登壇者の皆様、そしてこのような学びの場を設けてくださり、お誘いもしていただいた運営の皆様、参加者の皆様に、心より感謝申し上げます。ありがとうございました。
Discussion