QA・テストの最初の打ち合わせで聞くこと｜後戻りを防ぐ

2026年7月28日

丸山桃子

この記事のポイント

✓QA・テストの初回の打ち合わせで何を聞けば後戻りを防げるのかを
✓範囲・合格ライン・環境・不具合の扱い・報告の五つに整理して解説します
✓聞きにくい質問の切り出し方と

QA・テストの案件で初回の打ち合わせに臨むとき、多くの人が「何を聞けばいいのか分からないまま、相手の説明を聞いて終わってしまう」という状態になります。そして数週間後、テストを進めた段階で「そこは対象外だった」「その環境では確認しなくていい」と言われ、書いたテストケースの一部が丸ごと無駄になる。この後戻りは、能力の問題ではなく、初回の打ち合わせで確定させる項目が決まっていないことから起きます。この記事では、初回の打ち合わせで必ず確定させるべき項目を、範囲・合格ライン・環境とデータ・不具合の扱い・報告の五つに整理し、聞きにくい質問の切り出し方と、議事録での握り直しまで具体的に書きます。

初回の打ち合わせが弱いと、後半に全部戻ってくる

ソフトウェアテストの外部委託は、開発の内製化が進んだ企業ほど「開発は自分たちでやるが、品質保証だけは外の目を入れたい」という形で発注されます。この形の案件は、発注側がテストの実務に詳しくないことが少なくありません。発注側は「バグを見つけてほしい」という一言で依頼を出し、受け手は「どこまでを見るのか」を確認しないまま着手する。この状態で走り出すと、テスト設計を終えた頃に前提のずれが表面化します。

後戻りの怖さは、作業量そのものより、信頼の目減りにあります。テスト設計に5営業日かけて、その半分が対象外だったと分かったとき、発注側の頭に残るのは「認識合わせができない人」という印象です。実際には、対象範囲を書面で示さなかった発注側にも原因があります。それでも、最初に確認しなかった側が損をする構造は変わりません。

現場の実務でどれだけ前提の確認が重いかは、テストの見積りと実績の話を読むとよく分かります。

テスト設計の見積り含め、経験豊富なメンバーの協力により総テストケース数(予測値)は途中増減しつつも、最終的には誤差が5%前後に収まり改めて予実管理の必要性を感じました。出典: note.com

ここで注目すべきは「経験豊富なメンバーの協力により」という部分です。テストの物量は、対象の範囲と粒度が決まって初めて読めます。逆に言えば、初回の打ち合わせで範囲と粒度を確定できていない案件は、見積りが当たらないのが当然です。当たらない見積りは、途中の追加交渉か、無償の残業のどちらかで埋めることになります。

後戻りが起きる典型的な三つのパターン

一つ目は範囲のずれです。発注側が「新しく作った予約機能をテストしてほしい」と言ったとき、その予約機能から呼ばれる決済処理や通知メールが対象に入るのかどうかが決まっていない。受け手は当然入ると考え、発注側は「そこは別チームが見ている」と考えていた。この食い違いは、対象を機能名でなく画面と処理の一覧で確定させれば起きません。

二つ目は合格ラインのずれです。発注側は「致命的な不具合がなければリリースしたい」と言い、受け手は「見つけた不具合は全部直してからリリースするもの」と考えている。この状態で不具合を大量に報告すると、発注側は「そんなに直す時間はない」と困り、受け手は「報告したのに直さないのか」と不満を持ちます。どのレベルの不具合ならリリースを止めるのか、その判断を誰がするのかを最初に決めておけば避けられます。

三つ目は環境のずれです。テストする環境が開発環境なのか、検証環境なのか、本番相当のデータが入っているのか。ここが曖昧なまま進めると、「その環境では再現しません」という応酬が起き、不具合報告そのものが信用されなくなります。

打ち合わせの前に手元に用意しておくもの

初回の打ち合わせは、聞くだけの場ではなく、こちらが用意した枠に相手の情報を流し込む場です。枠がない状態で相手の説明を聞くと、話の順番どおりにメモが並び、抜けた項目に気づけません。準備するものは三つあります。

一つ目は確認項目のリストです。この記事の後半に挙げる項目を、そのまま一枚のシートにしておきます。打ち合わせの場で上から順に潰していけば、聞き漏らしが構造的に起きなくなります。相手の話が脱線しても、リストに戻れば復帰できます。

二つ目は簡単な想定の下書きです。事前に資料をもらえているなら、対象と思われる画面を一覧にして、テストの観点を粗く並べておきます。完成品である必要はありません。「こういう理解で合っていますか」と見せる材料があると、相手は言葉で説明するより早く、正確に訂正してくれます。これが初回の打ち合わせで最も効率が上がる準備です。

三つ目は自分の稼働の見通しです。週に何時間動けるのか、返信できる時間帯はいつか、他の案件との兼ね合いはどうか。ここを曖昧にしたまま「頑張ります」と答えると、後で報告の遅れが不誠実に見えます。

資料が事前にもらえないときの動き方

初回の打ち合わせの前に資料が出てこない案件は珍しくありません。機密の都合で契約前には出せない場合もあれば、単に社内に整理された資料がない場合もあります。どちらなのかは、打ち合わせの冒頭で「資料はこのあと共有いただけますか、それとも口頭で伺う形になりますか」と一言聞けば分かります。

社内に資料がない場合は、それ自体が重要な情報です。仕様書がないということは、テストの正解を発注側の頭の中から引き出す作業が発生するということです。この場合、テスト設計の前に仕様の聞き取りという工程が必要になり、その分の時間を見込む必要があります。ここを見込まずに見積もると、必ず持ち出しになります。

私が過去に関わった案件でも、仕様書が存在せず、現行の画面を触りながら「これが正しい動きなのか」を一つずつ確認する必要がありました。最初はそれを作業時間に入れておらず、テスト設計の期間内に確認作業を押し込もうとして、初週で無理があると分かりました。この経験以降、仕様書の有無は初回の打ち合わせで最初に聞く項目にしています。

対象範囲を確定させるための質問

範囲の確認は、抽象的に聞くと抽象的な答えが返ってきます。「どこまでテストしますか」と聞けば「一通りお願いします」と返ってくる。これでは何も決まりません。範囲は、対象と非対象の両方を具体物で挙げて確定させます。

対象を機能名でなく画面と処理で並べる

「予約機能」「会員機能」といった機能名は、人によって範囲が違います。画面の一覧と、画面から呼ばれる裏側の処理を分けて並べ、一つずつ対象かどうかを確認します。予約の入力画面、確認画面、完了画面、予約一覧、キャンセル画面。ここまで並べれば、相手も「キャンセルは今回は触っていないので対象外です」と具体的に答えられます。

裏側の処理も同じです。予約が完了したときに送るメール、外部の決済サービスへの連携、在庫の引き当て。これらは画面に見えないため、口頭の説明では抜け落ちます。「この操作をしたあと、裏で動くものはありますか」と聞くのが有効です。

非対象を明示的に聞く

対象を聞くだけでは足りません。「今回テストしなくていいものは何ですか」と、非対象を明示的に聞きます。この質問は、相手の頭の中にある前提を引き出す力があります。「既存機能の回帰は前回やったので不要です」「管理画面は社内利用なので今回は見なくていいです」といった答えが出てくれば、その分の設計時間を丸ごと節約できます。

非対象は、議事録に必ず書き残します。後から「そこも見てくれると思っていた」と言われたときに、非対象として合意した記録がなければ、受け手が押し切られます。

対応する端末とブラウザの組み合わせを数える

範囲の物量は、機能の数だけでは決まりません。同じ画面でも、確認する端末とブラウザの組み合わせが増えれば、その掛け算で作業量が増えます。パソコンのブラウザが3種類、スマートフォンが2種類となれば、単純計算で5倍です。

ここは相手も深く考えていないことが多い部分です。「主要なブラウザで」と言われたら、具体的に何と何を指すのかを確認します。さらに、全画面を全組み合わせで見るのか、主要な導線だけを複数組み合わせで見て、残りは一つの組み合わせで済ませるのかを決めます。この方針が決まるだけで、物量は大きく変わります。

品質の合格ラインを言葉でなく基準で決める

「品質を担保してほしい」という依頼は、そのままでは実行できません。何をもって合格とするのかを、判断できる形に落とす必要があります。ここを決めずに走ると、テストがいつ終わるのかも決まりません。

不具合の重大度の定義を先に合わせる

不具合の重大度は、多くの現場で「致命的」「重大」「軽微」といった段階に分けられます。問題は、この言葉の中身が組織ごとに違うことです。データが壊れるものを致命的とする現場もあれば、業務が止まるものを致命的とする現場もあります。表示の崩れを軽微とするか、ブランドの信用に関わるとして重大とするかも分かれます。

初回の打ち合わせでは、段階の名前ではなく、具体例で合わせます。「ログインできない状態はどの段階ですか」「金額が1円ずれるのはどの段階ですか」「ボタンの位置が少しずれているのはどの段階ですか」。この三つを聞くだけで、相手の基準の輪郭が見えます。

リリースを止める条件と止めない条件

重大度の定義ができたら、次はリリースの判断です。どの段階の不具合が残っていたらリリースを止めるのか。止めるかどうかを最終的に決めるのは誰なのか。この二つを確認します。

受け手の立場として大事なのは、リリースの可否を自分が決める立場ではないと明確にしておくことです。テストの担当者の役割は、事実を正確に伝えて判断材料を渡すことです。判断そのものを引き受けると、後で問題が起きたときに責任の所在が曖昧になります。「私の役割は、残っている不具合とその影響を正確にお伝えするところまでで、リリースの判断はそちらでお願いします」と最初に言っておくと、双方が楽になります。

終了の条件を数で決めておく

テストの終了条件は、期間で決める場合と、消化率で決める場合があります。「予定したテストケースを全部実行し、重大度の高い不具合が残っていないこと」という形が基本ですが、実際には期日が先に来ることも多い。その場合、優先度の高いケースから消化し、期日の時点で消化率と残りのリスクを報告する形になります。

この運用にするなら、テストケースに優先度を付ける前提を最初に合意しておきます。優先度の設計がないまま期日が来ると、消化したケースが偏っていて、リスクの説明ができなくなります。

環境とデータの確認が、実は一番止まる

初回の打ち合わせで軽視されがちで、着手後に最も進行を止めるのが環境とデータです。テストの設計が完璧でも、動かす場所がなければ一行も進みません。

アクセスできる環境の種類と権限

テストをどの環境で行うのかを確認します。開発中のものを見る環境なのか、リリース前の検証環境なのか。その環境は誰が管理していて、落ちたときに誰に連絡するのか。ここが分かっていないと、環境が落ちた日に問い合わせ先を探すところから始めることになります。

アカウントの権限も重要です。一般の利用者としてのアカウント、管理者としてのアカウント、権限の違う複数のアカウント。権限によって見える画面が変わる仕様なら、その数だけアカウントが必要です。「テスト用のアカウントは何種類いただけますか」と、数を伴った聞き方をすると具体的な答えが返ってきます。

テストデータをどう作るか

データの準備は、外部の立場で入る人にとって最も詰まりやすい部分です。会員のデータ、商品のデータ、過去の取引のデータ。これらを自分で作れるのか、発注側が用意するのか、既にある本番相当のデータを使うのか。

本番相当のデータを使う場合は、個人情報の扱いが絡みます。実在の個人情報が含まれるデータを扱うなら、契約書に加えて、保管の方法や作業する場所の制限が付くことがあります。「実データを使いますか、それとも匿名化されたデータですか」と聞き、実データなら取り扱いの取り決めを確認します。ここを曖昧にしたまま作業を始めると、後から重い問題になります。

環境が使えない時間帯の扱い

共有の検証環境は、開発チームの作業でリセットされたり、デプロイで一時的に止まったりします。テストの最中に環境が入れ替わると、それまでの実行結果の一部が無効になります。

そこで、環境が更新されるタイミングと、更新の連絡がどう来るのかを確認します。更新の連絡が来ない運用なら、テストを実行する前に対象のバージョンを確認する手順を自分で組み込む必要があります。この手順を最初に決めておくと、「その結果は古い版のものです」という指摘を受けずに済みます。

不具合を報告したあとの流れを先に決める

不具合の報告は、書いて終わりではありません。報告してから修正され、再確認して閉じるまでが一つの流れです。この流れが決まっていないと、報告した不具合が宙に浮きます。

どこに書くか、誰が見るか

不具合の記録先が課題管理のツールなのか、表計算のシートなのか、チャットなのかを確認します。ツールを使うなら、こちらがアカウントをもらえるのかどうか。もらえない場合、誰かに代理で登録してもらう手間が毎回発生します。

書式も確認します。再現の手順、期待する動作、実際の動作、環境、証跡の画像。この五つが基本ですが、現場によって必要な項目は違います。既存の書式があるなら、それに合わせるのが早い。既存の書式がないなら、こちらから提案します。書式が統一されていないと、修正する側が状況を再現できず、往復が増えます。

差し戻されたときの扱いを決める

報告した不具合が「仕様どおりです」と差し戻されることは普通にあります。このとき、受け手が引き下がるのか、根拠を出して再度提起するのかを最初に決めておくと、無用な摩擦が減ります。

実務としては、仕様書に書かれていることと違う動きなら仕様書の該当箇所を示し、仕様書に書かれていない部分の指摘なら「仕様の確認」として別枠で出すのが穏当です。この二つを混ぜると、指摘の信用が落ちます。「仕様に明記がない挙動について気づいた点は、不具合とは別の一覧でお出ししてよいですか」と聞いておくと、後で扱いやすくなります。

再確認の依頼はどう来るか

修正されたあと、再確認の依頼がどう届くのかを決めます。修正が終わるたびに個別に連絡が来るのか、まとめて週に一度来るのか。個別に来る運用だと、こちらの作業が細切れになります。まとめて来る運用だと、期日の直前に集中します。

どちらにするかは相手の開発の進め方に依存しますが、少なくとも「どちらの運用になりそうか」を聞いておけば、自分の稼働の組み方を決められます。

進捗の見せ方と報告の頻度を約束する

外部の立場でテストに入ると、発注側からは作業の中身が見えません。見えないものは不安になり、不安は細かい確認の連絡として返ってきます。報告の設計は、相手のためだけでなく、自分の作業時間を守るためにも必要です。

何を数字で見せるかを決める

進捗の報告は、感覚の言葉ではなく数字で見せます。予定したケースのうち何件を実行し、そのうち何件が合格し、何件が不具合として報告されたか。この三つがあれば、相手は状況を掴めます。

進捗の測り方について、実務の解説を一つ引きます。

QAのプロジェクトにおいて「今のテストがどれくらい進んでいるのか」または「どれくらい遅れているのか」といった進捗を測定して状況を把握することは、テストの実行を管理する際にとても重要なタスクとなります。出典: sqripts.com

進捗の測定が重要なタスクだということは、その分の時間が作業に含まれるということでもあります。記録の付け方を最初に決めておけば、報告のたびに集計し直す手間が消えます。実行の結果と実施日をその場で記録しておく形にしておくと、集計は自動化できます。

報告の頻度と手段

報告を毎日出すのか、週に一度出すのかを決めます。短期の案件なら日次、数か月にわたる案件なら週次が基本です。手段も決めます。文書で出すのか、打ち合わせの場で口頭に添えるのか。

ここで一つ提案しておくと相手に喜ばれるのが、悪い知らせの伝え方です。「重大度の高い不具合が出た場合は、定例を待たずにその日のうちにご連絡します」と最初に言っておく。この一言があるだけで、相手は定例までの間の不安から解放されます。

質問の窓口を一人に決める

テストを進めると、仕様の確認が大量に発生します。この質問を誰に投げるのかが決まっていないと、質問が滞留し、確認待ちのケースが積み上がります。

窓口を一人に決めてもらうのが原則です。そのうえで、その人が答えられない領域があるなら、二人目を確保します。「仕様の質問はどなたに伺えばよいですか」「その方が不在のときの代わりはどなたですか」。この二つを聞いておくだけで、確認待ちの時間が大きく減ります。

契約と体制について確認すること

技術の話に集中していると抜けやすいのが、契約と体制の確認です。ここが決まっていないと、あとで支払いの条件や責任の範囲でもめます。

成果物が何かを言葉にする

契約の形が請負なのか準委任なのかで、求められるものが変わります。請負なら成果物の完成が条件になり、準委任なら決められた稼働の中で誠実に業務を行うことが条件になります。テストの業務は、結果を保証できない性質があるため、準委任の形が選ばれることが多い分野です。

いずれにしても、納品するものが何かを言葉にしておきます。テスト計画の文書、テストケースの一覧、実行結果の記録、不具合の一覧、最終の報告書。このうちどれを出すのかを確認し、書式の指定があるかも聞きます。ここが決まらないと、最後に「報告書の形式が違う」というやり直しが発生します。

秘密保持と作業の場所

NDAの締結が必要かどうか、いつ締結するかを確認します。資料を受け取る前に締結するのが一般的です。あわせて、作業する場所や機材の条件を聞きます。自分のパソコンで作業してよいのか、貸与された機材を使うのか、画面の撮影に制限があるのか。在宅で進める前提なら、その前提が相手にも共有されているかを確認します。

契約や報酬の取り決めについては、フリーランス全般に関わる基礎を押さえておくと判断しやすくなります。業務委託の働き方や契約の考え方は、独立の準備をまとめた定年後のフリーランス独立｜退職金を活かした起業プランと注意点でも整理されています。年齢に関わらず、業務委託で働くときの基本の考え方は共通です。

稼働の時間帯と連絡の速さ

どの時間帯に連絡が取れる必要があるのかを確認します。相手の定例に出る必要があるのか、チャットの返信はどれくらいの速さを期待されているのか。ここを合わせておかないと、「連絡が取れない人」という評価がつきます。逆に、こちらの都合も伝えます。夜間や休日の対応を前提にされていないかを、最初に確認しておくのが安全です。

聞きにくい質問をどう切り出すか

ここまで挙げた項目の中には、初対面で聞きにくいものがあります。仕様書がないことを指摘するような質問、体制の弱さが露呈する質問、契約の条件に踏み込む質問。これらを避けると、後で困るのは自分です。

切り出し方には型があります。相手を責める形にせず、自分の作業のためだと伝える形にすることです。「仕様書はないんですか」ではなく、「テストの正解を判断する材料として、仕様が分かる資料があれば拝見したいのですが、どういった形で残っていますか」と聞く。前者は相手の準備不足を突く質問に聞こえますが、後者は自分の作業のための確認になります。

もう一つの型は、選択肢を示す聞き方です。「どうなっていますか」と開いた形で聞くと、相手も考えがまとまっていない場合に答えられません。「AとBのどちらに近いですか」と示すと、相手は選ぶだけで答えられます。環境の話でも「本番相当のデータが入っていますか、それともテスト用に作ったデータですか」と二択で聞けば、即答が返ってきます。

打ち合わせの終わりに必ずやること

打ち合わせの最後に、決まったことを口頭で復唱します。対象と非対象、合格の判断基準、環境とアカウント、不具合の記録先、報告の頻度と窓口。この五つを1分で読み上げ、相違がないかを確認します。この場で違いが出れば、その場で直せます。

そのうえで、当日中に議事録を文章で送ります。議事録に書くのは、決まったことと、決まらなかったことの両方です。決まらなかった項目には「次回までにご確認いただく」と誰が確認するのかを書き添えます。この一通があるかないかで、後半の摩擦の量が変わります。

私が最初に外部の立場でテストに入ったとき、打ち合わせのメモは自分のためだけに取っていて、相手に送っていませんでした。三週間後に対象範囲の認識がずれていると分かったとき、こちらのメモには「対象に含む」と書いてあったのに、それは相手が確認していない記録でした。結局、こちらの理解が正しかったかどうかは証明できず、追加の作業を引き受けることになりました。議事録は自分の記憶のためではなく、相手と共有した記録を作るためのものだと、この経験で理解しました。

この仕事を長く続ける人が初回にしていること

フリーランス・在宅ワークの市場を20年運営してきた立場から見ると、テストの領域で継続して依頼される人には共通点があります。技術の深さより先に、初回の打ち合わせの進め方が違うのです。

続く人は、初回の場で相手に「決めさせる」ことをしています。自分が質問して相手が答えるという一方向のやり取りではなく、「こういう形でどうでしょうか」と案を出し、相手が承認する形に持っていく。案を出されると、人は違和感のあるところだけを指摘できます。ゼロから説明するより圧倒的に楽なので、相手は「話が早い人だ」と感じます。これが二回目の依頼につながる最大の要因です。

もう一つ、運営者として見てきた限りでは、長く続く人は「自分の作業が相手の何を楽にしているか」を言語化しています。テストの担当者が入ることで、開発側は自分たちで確認する時間を削れ、リリースの判断材料が揃います。ここを理解している人は、報告の粒度が相手の判断に合っています。逆に、不具合の件数だけを並べる報告をする人は、相手にとって使いにくい情報を渡していることに気づきません。

金額の面では、中間のマージンが乗らない直接の取引は、同じ予算で発注側はより多くの作業を頼めて、受け手の手取りは厚くなります。手数料0%という条件は、単に安いという話ではなく、同じ費用の中で使える時間が増えるという意味を持ちます。テストのように「どこまで見るか」で作業量が伸縮する仕事では、この差がそのまま品質の差になります。運営者として見てきた限り、直接の取引に慣れた発注側ほど、範囲の相談を細かくしてきます。予算が中間で削られない分、相談する余地が残っているからです。

職種としての位置づけを踏まえて話す

テストと品質保証の仕事は、開発の周辺業務ではなく、独立した専門領域として扱われるようになっています。仕事の具体的な内容や求められる範囲は、QA・テスト・コードレビューのお仕事で整理されています。テストの実行だけでなく、コードレビューや設計の確認まで含めて依頼されることがあり、初回の打ち合わせではどこまでが自分の担当かを確認する必要があります。

近い領域として、セキュリティの観点での確認や、自動化の仕組み作りを求められることもあります。この周辺の仕事の広がりはAI・マーケティング・セキュリティのお仕事を見ると掴みやすく、依頼の中に「ついでにこれも」と含まれてくる作業を見分ける助けになります。範囲外の作業を無自覚に引き受けないためにも、隣接する職種の切り分けを知っておくと役に立ちます。

報酬の水準を判断するときは、ソフトウェア開発の周辺職種としての相場感を踏まえるのが実務的です。ソフトウェア作成者の年収・単価相場には職業分類に基づく統計が整理されており、テストの担当として提示された条件が市場からどの程度離れているかを見る材料になります。初回の打ち合わせで金額の話が出たとき、根拠を持って答えるための下地になります。

技術の裏付けを示す材料として、資格に触れられる場面もあります。ネットワークやインフラの知識が求められる案件では、CCNA（シスコ技術者認定）のような認定が、環境の話を理解できる人だと伝える材料になります。資格そのものが受注を決めるわけではありませんが、初回の打ち合わせで環境や構成の話についていけることは、実務の信頼に直結します。

初回の打ち合わせを一枚のシートにする

最後に、この記事で挙げた確認項目を一枚にまとめておきます。対象の画面と処理の一覧、非対象として合意した項目、端末とブラウザの組み合わせ、不具合の重大度の具体例、リリースを止める条件と判断者、環境の種類と管理者、アカウントの種類と数、テストデータの作り方と個人情報の扱い、不具合の記録先と書式、差し戻しの扱い、再確認の依頼の来かた、報告の頻度と項目、質問の窓口と代理、成果物と書式、契約の形とNDA、稼働の時間帯。

この一覧を打ち合わせの前に開き、終わったときに空欄が残っていれば、それが次に確認すべきことです。空欄をゼロにしてから着手すれば、後戻りはほとんど起きません。逆に、空欄を残したまま着手した項目は、必ずどこかで問題として戻ってきます。初回の打ち合わせは、情報を集める場ではなく、空欄を埋める場だと考えるのが正確です。