QAエンジニアの参画初月にやること｜現場で信頼される進め方

QAエンジニアの参画初月は、対象と仕様と環境をつかみ、テストの範囲と報告の型を関係者と合わせ、月末に「確かめたこと・確かめていないこと」を示して次の計画に合意を取るのが基本です。初月から不具合の数で成果を見せようとするより、品質の状態を正しく伝えられる土台をつくるほうが、現場の信頼につながります。

この記事では、初月のゴール、週ごとの進め方、案件の型による重心の違い、避けたい動き、月末の振り返りを整理します。参画前の準備の全体は参画前の準備の記事、参画初期の一般的な動き方は参画初期の記事で扱っているので、ここではQAならではの進め方に絞ります。

初月のゴールを3つに分ける

QAの初月は、次の3つを月末までにそろえることを目標にすると、動きがぶれにくくなります。

1週目：資料と環境と人から現状を集める

QAとして最初に読む資料

1週目は、手を動かす前に次の資料を集めて読みます。

• 仕様書・要件の資料：どこにあり、どれが最新か。古いものが混ざっていないか
• 既存のテスト計画書とテストケース：どの範囲を、どの観点で確かめてきたか
• 不具合の記録：どの機能に、どんな不具合が多いか。重さの付け方の傾向
• リリースの予定と過去の障害の記録：次の区切りがいつか、本番で何が起きたか

不具合の記録は、どこにリスクが偏っているかを知るうえで特に役立ちます。前任者がいる場合の引き継ぎの受け方は引き継ぎの記事をご覧ください。

環境とデータを早めに確かめる

検証の環境に入れるか、テストデータはそろっているか、検証用の端末は手元にあるかを、1週目のうちに確かめます。ここが止まると、2週目以降の計画がすべてずれます。足りないものは、誰がいつまでに用意するかを窓口と決めておきます。端末を自宅で扱う案件の決めごとはQAエンジニアのリモート案件の記事で整理しています。

関係者と短く話す

開発のリーダー、仕様の持ち主（プロダクトの責任者や業務の担当者）、自動化の担当者がいればその人と、短く話す時間をもらいます。聞きたいのは「今いちばん心配している機能はどこか」「過去に困った不具合は何か」です。関係者が心配している箇所は、テストで重く確かめるべき箇所の手がかりになります。

2週目：範囲と報告の型を合わせる

テストの範囲と質問先を決めてもらう

2週目は、自分が担う範囲を関係者と確かめます。どの機能を手動で確かめ、どこを自動化に任せるのか、今回は確かめない範囲はどこかを一覧にし、窓口の了承を得ます。仕様の質問をどこに、誰に出すかもこの時期に決めてもらいます。

不具合の報告と優先度の決め方を合わせる

不具合の報告の書き方、重さの区分、優先度を誰が決めるかは、現場ごとに違います。前の現場の書き方を持ち込まず、まずは今の現場の型に合わせます。そのうえで、再現の手順や影響の大きさが伝わりにくい点があれば、少しずつ提案します。

自分でも確かめ始める

範囲が決まったら、リスクの高い機能から実際に確かめ始めます。最初のうちは、見つけた不具合を報告する前に、既存の記録に同じものがないかを確かめると、重複の報告を減らせます。

3〜4週目：見立てを出し、次の計画に合意を取る

品質の現状をまとめる

3週目に入ったら、ここまでに分かったことをまとめます。確かめた範囲と結果、残っている不具合とその重さ、まだ確かめていない範囲、環境やデータの課題を並べ、「今の品質の状態」を一枚で示せるようにします。

見直したい点は選択肢で出す

既存のテストケースに抜けがある、優先度の付け方が現場で揃っていない、といった気づきがあれば、すぐに直すのではなく、選択肢として出します。「観点をこう足す案」「今回は見送る案」のように並べ、影響と手間を添えると、相手が選びやすくなります。

次の1〜2か月の計画を引く

月末には、次のリリースまでの範囲と優先順位、必要な環境とデータ、自分の稼働の見込みを計画にまとめ、窓口の了承を得ます。計画が契約で決めた業務の範囲を超えそうなときは、先に相談してください。考え方は業務範囲が変わったときの記事で扱っています。

案件の型によって初月の重心は変わる

案件の種類の全体はQAエンジニアの案件の仕事内容で整理しています。初月の重心は、型によって次のように変わります。

自社サービスのQA

短い周期でリリースが続くため、初月から確認の流れに入ることになります。重心は、スプリントの中でいつ確かめるか、開発者とどう情報をやりとりするかをつかむことに置きます。

業務システムの総合テスト・受け入れテスト

工程の途中から入ることが多く、既存の計画と進み具合をつかむことが先になります。業務の流れを担当者から聞き、業務の目で重く確かめるべき箇所を早めに押さえます。

QAの立ち上げ

テストの進め方そのものがない現場では、初月にすべてを作ろうとしないことが大切です。まず現状の確認のやり方と過去の不具合を聞き取り、月末に「最初に整えること」を絞って提案します。

自動化を中心に担う場合の初月はテスト自動化エンジニアの参画初月の記事で扱っています。

初月に避けたい動き

• 前の現場の型を持ち込む：報告の書き方や重さの区分を、了承なく変える
• 確かめていない範囲を伝えない：時間が足りずに削った範囲を、報告に書かないまま進む
• 仕様を自分の解釈で決める：分からない点を確かめずに、合否を判断する
• 環境の待ちを黙って抱える：使えない環境やデータの不足を、共有しないまま待つ
• 件数だけで成果を示す：不具合の件数を前に出し、重さや影響の説明を後回しにする

1か月の終わりに振り返ること

月末には、次の点を自分で振り返っておくと、2か月目の動きが安定します。

1. 対象の全体と、リスクの高い機能を自分の言葉で説明できるか
2. 仕様の質問先と、不具合の優先度を決める人が分かっているか
3. 確かめた範囲と確かめていない範囲を、関係者と同じ認識で持てているか
4. 環境・データ・端末の課題は、誰が対応するか決まっているか
5. 稼働が契約の想定から外れていないか

つまずきやすい場面と対策はQAエンジニアのつまずきの記事で整理しています。

よくある質問

仕様書がほとんどありません。何から始めればよいですか？

まず、仕様を知っている人が誰かを確かめ、話を聞く時間をもらいます。聞いた内容は箇条書きで残し、「この理解で合っているか」を相手に確かめてもらうと、仕様の代わりになる資料ができます。不明な点は質問の一覧にまとめ、回答がない項目は保留として報告に残してください。

参画初月から、リリースの可否を聞かれたらどうすればよいですか？

対象に慣れていない段階で一人で判断を言い切るのは避け、確かめた範囲と残っている不具合、確かめていない範囲を事実として示し、判断する立場の人に決めてもらいます。分からないことを分からないと伝えるほうが、後の信頼につながります。

前任者のテストケースに抜けが多いと感じたら、どうすればよいですか？

すぐに作り直すのではなく、どの観点が抜けているか、そのままだと何が起きうるかを整理して、選択肢として提案します。前任者の判断には現場の事情があったこともあるため、経緯を聞いてから提案すると受け入れられやすくなります。