はじめに
こちらはe-dash advent calendar 2025の3日目の記事です。
はじめまして。2025年8月にe-dashのQAエンジニアとしてjoinしましたrinです。
新しい環境に入った際、皆さんは最初に何をされますか？ すぐに仕様書を読み込みますか？ それとも自動テストの整備に取り掛かりますか？
もちろん、それらはQAとして非常に重要なことです。
しかし、私はjoin後、すぐにQAらしい具体的なタスクには手をつけませんでした。
この記事では、新任QAエンジニアである私が、最初のActionに何を選んだのか、そして、どのように実行し、何を感じたのかを共有したいと思います。
新しい環境やチームで「まず何をすべきか？」を考えた
私がjoinした時点で、既にリグレッションテストや自動化の取り組みは行われていました。
それ以外で私ができる即効性のありそうなことは何かを考えたときに、不具合管理や分析も選択肢として浮かびましたが、そこで立ち止まって考えました。
「それは、本当に今やるべきなのか？ 今やるべきことは他にあるのではないか？」
まず過去と現状を把握しなければ、結局どこから手を付けていいか見えません。
逆を言えば、未来を予測することで具体的に何をしたら効果があるのかが見えてくるのではないかと考えました。
そのため、私は「過去を知り、現在を把握し、未来を予測する」ための、最初のActionとして課題ヒアリングを選択しました。
課題ヒアリングが 過去 と 現在 を知る手段であり、 未来 へと視点を持っていく流れが作れます。
ヒアリング対象とその理由
では誰にヒアリングするのか。今回はQAメンバーをヒアリング対象としました。
ヒアリング対象の選択肢としては全社や開発チームなどもありますが、対象を絞った理由としては以下になります。
- 自分が即座に改善アクションに移せる範囲（QAチーム内）に限定することで、施策の実行可能性と効果検証のスピードを重視
- 全社など対象者が広すぎると情報収集に時間が必要となり、施策の実行性が低下する
自分自身がオーナシップをもって推進していくことや過去のQA経験を活かすことを前提に考えると、最も改善インパクトを出しやすい、QAチーム内の課題を特定することが優先だと考えました。
なぜテストではなくヒアリングなのか？
正直なところ、サービスの理解やQAとしての立ち上がりを優先すべきか、迷いもありました。
ただ、ドメイン知識やお作法は、インプロセスQAとしての活動を通じて、必然的に身につきます。
つまり、それは時間をかければ解決する課題です。
しかし、チームの生産性のボトルネックや、メンバーが慣れすぎて気づけていない潜在課題を見つけ出すことは、日々のテスト業務だけでは困難です。
また、顕在課題（日頃からメンバーが感じていること）も把握し、 それによってチームの 現状 と 目指すべき 理想 を整理することも重要です。
テスト活動に入る前に、バイアスのかかっていないフラットな視点で課題を見つけ出し整理することが、新任QAとして今しかできない最大の価値提供になると考えました。
どのように進めたのか？
前置きが長くなりましたが、ここからは、私が実際に行ったヒアリング項目作成までの流れを、STEPごとに説明します。
STEP1 様々なヒアリングフレームワークを応用する
SPIN BANT 3C 5W2H などのヒアリングフレームワークがあります。
一般的には営業・商談やコンサルティングの戦略立案などで活用されることが多いようですが、これらを今回の課題ヒアリングに応用・転用することにしました。
ヒアリングフレームワークは、あくまでヒアリングの質を高めるための指標や補助的なものであり、状況や目的に応じて柔軟に使い分けることが重要です。
そのためヒアリング方法に決まった正解はないと考えています。
STEP2 ヒアリングフレームワークをどのように使うか考える
それぞれ特徴があるので、様々な視点・切り口から質問が投げかけられそうだと考え、以下のように用途を整理しました。
| ヒアリングフレームワーク | 本来の用途 | 応用 |
|---|---|---|
| SPIN | 顧客の潜在ニーズに気づかせる | 潜在課題や困りごとを言語化 |
| BANT | 受注可能性の判断 | チーム施策の実行ハードルや優先順位を明確にする |
| 3C | 事業戦略の外部・内部環境分析 | チーム・関係者・組織構造の課題を見つける |
| 5W2H | 必要な情報の聞き取り | 問題を整理する |
STEP3 質問内容を具体化する
どのような質問をするのか以下のように具体化しました。
| SPIN | 視点 | 質問内容例 |
|---|---|---|
| Situation | 状況確認 | ・主にどんな業務を担当していますか？ |
| Problem | 問題発見 | ・業務で困っていること、やりにくさを感じていることはありますか？ |
| Implication | 影響の明確化 | ・問題が続くと、どんな影響があると感じますか？ 自分やチームへの影響は？ |
| Need-payoff | 理想と改善ニーズ | ・改善に向けて、こんなサポートがあれば助かる、というものはありますか？ |
| BANT | 視点 | 質問内容例 |
|---|---|---|
| Budget | リソース | ・改善を実現するには、どれくらいの時間やスキルが必要そうですか？ |
| Authority | 関係者・承認 | ・改善するには、誰の協力や許可が必要だと思いますか？ |
| Needs | 必要性・優先度 | ・改善はすぐにでも必要ですか？ 余裕があればのような感覚ですか？ |
| Timeframe | タイミング | ・いつ頃までに改善されているとよいと感じますか？ |
| 3C | 視点 | 質問内容例 |
|---|---|---|
| Company | 自チーム | ・QAチームの強みってどんなところにあると思いますか？ |
| Customer | 他チーム・関係者 | ・開発チームやPOと仕事をする中で、ギャップやすれ違いを感じたことはありますか？ |
| Competitor | 他のQAチーム・他社事例 | ・他のプロジェクトのQAや、聞いたことのあるやり方で いいな と思ったものはありますか？ |
| 5W2H | 視点 | 質問内容例 |
|---|---|---|
| When（いつ） | タイミング・頻度 | ・それはいつ頃から、どれくらいの頻度で起きていますか？ |
| Where（どこで） | 発生場所・工程 | ・どの工程・どの場面でその問題を感じていますか？ |
| Who（誰と） | 関係者の特定 | ・誰との関わりでそのようなことが起きていますか？ |
| What（何を） | 具体的な内容や対象の把握 | ・どんな業務で手間や負担を感じていますか？ |
| Why（なぜ） | 理由 | ・なぜその業務に手間や負担を感じるのですか？ |
| How（どのように） | 実際のやり方 | ・普段はどのように対応されていますか？ |
| How much（どのくらい） | 程度・量的負荷 | ・その作業には、1日にどれくらいの時間を使っていますか？ |
STEP4 質問内容からどんな情報を得るのか
闇雲に質問をしても狙った回答が得られたかわからないと意味がないので、質問内容からどういった情報を得たいのかある程度イメージを持っておきます。
5W2H については以下の表にまとめませんでした。
SPIN BANT 3C で質問をした回答に対して、深掘りや言語化をする補助として使用したほうが良さそうだと考えたためです。
SPIN BANT 3C の3軸でヒアリングをしつつ、回答内容に応じて 5W2H で深堀する流れをこの段階でイメージしました。
| ヒアリングフレームワーク | 目的 | 狙い |
|---|---|---|
| SPIN | 個人の業務課題や心理的障壁を可視化 | 個人の感じている「日々のモヤモヤ」や「本音」を引き出す |
| BANT | その課題に対しての実行可能性や優先度を判断 | 課題の優先順位付け・実行性の判断材料を得る |
| 3C | チーム・他部署・組織構造の課題を洗い出す | 組織・チーム間のギャップや構造的な課題を見つける |
STEP5 ヒアリング項目を完成させる
STEP1 ～ STEP4 で整理した結果から、以下のヒアリング項目が完成しました。
ヒアリング項目
ある程度、仮説立てた質問は有効であると考えますが、フォーカスしすぎた質問をしてしまうと、ヒアリング対象者の思考を狭めてしまい、潜在的なことに気づきにくくなる可能性があると考えたため全体的に抽象度の高い内容で構成しました。
ヒアリング実施・結果
ヒアリング項目が完成したので、実際にヒアリングを進めていきます。
始める前に何のためのヒアリングなのか、最終的なゴールを理解いただくため、冒頭に以下をお伝えした上でQAメンバー全員に1on1形式でヒアリングを実施しました。
-
ヒアリングの目的
- 現在の業務やチームにおいて、どんな課題や困りごとがあるかを把握すること。
- その課題の背景や要因を深掘りして、必要な改善や支援のヒントを得ること。
-
ヒアリング結果の活用
- 今回のヒアリング内容は、個人を特定しない形で整理・分析させていただく。
- 分析結果は、今後のチーム運営や施策の検討材料として活用させていただく。
-
所要時間と進め方
- 所要時間は30分で、10項目ほどピックアップしてお話させていただく。
- あくまで雑談の延長くらいの感覚でお話いただく。
- すべての質問に必ず答える必要はありませんので、負担なく進めさせていただく。
所要時間を30分にした理由は、長時間拘束してしまうと集中力が持続しにくいので、30分程度の短時間で実施し、必要に応じて複数回に分けて重ねた方が良いと考えたためです。
また限られた時間の中で情報を引き出すために、MUST（絶対に聞きたい質問） と WANT（できれば聞きたい質問） を予め整理しておきました。
結果的に様々な視点から回答をいただき、改善活動を行うための情報やヒントを得ることができました。
ただ、抽象度が高い質問が故に、悩ませてしまったシーンもあったため、この点は反省点として次に活かしていきたいです。
この先はどうするのか？
そう、大事なのはここからです。
ヒアリングで得た情報から具体的な課題を明確にしていかないと、単純に会話しただけになってしまいます。
では次に... と行きたいところですが、続きの課題分析フェーズは、次回に詳しくご紹介したいと思います。
今回は、新任QAエンジニアである私が最初に課題ヒアリングを選択し、どのようにヒアリングしたのか、を共有させていただきました。
ヒアリングはQAに限らず色々な場面で使える方法だと思います。読んでいただいた皆さんの少しでもプラスになったら嬉しいです。
Discussion