QAマネージャー・品質保証リードの参画初月にやること｜現場で信頼される進め方

QAマネージャー・品質保証リードの参画初月は、品質の実態と判定の流れをつかみ、報告の型を判断する人と合わせ、月末に「品質の見立て」と「見直し案」を出して合意を取るのが基本です。最初の1か月で基準や手順を大きく変えるより、現状を正しく把握し、手を入れる順番に発注側の納得を得ることが、その後の信頼につながります。

この記事では、初月のゴール、週ごとの進め方、案件の型による重心の違い、避けたい動き、月末の振り返りを整理します。参画前の準備と、職種を問わない立ち上がりの心得は参画前の準備の記事と参画初期の進め方の記事で扱っているので、ここではQAマネージャーならではの動きに絞ります。

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

3つ目まで届かなくても、1つ目と2つ目ができていれば初月としては十分です。逆に、実態をつかむ前に3つ目だけを急ぐと、的外れな提案になりやすくなります。

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

QAマネージャーとして最初に読むもの

• テスト方針・テスト計画：何を、どの段階で確かめることになっているか
• 品質の基準：リリースや受け入れの条件、不具合の重大度の定義
• 不具合の記録：直近数か月の件数の推移、重大度の内訳、見つかった工程
• リリースと障害の履歴：延期や例外のリリース、本番で見つかった障害とその原因
• 体制図と契約の関係：社内のテスト担当、外部のテスト会社、開発チームの分担

文書と実際が食い違っていることは珍しくありません。方針には書かれているのに実施されていない確認、記録の上では閉じているのに直っていない不具合など、食い違いそのものが品質の実態を示す手がかりになります。

関係者と短く話す

開発責任者、事業側の責任者、テスト担当者、外部のテスト会社の責任者などと、15〜30分ずつ話します。聞くことは「品質で一番困っていること」「最近のリリースでうまくいかなかったこと」「QAに期待していること」の3つほどに絞ります。立場によって品質の困りごとが違うことが分かれば、それが後の基準づくりの材料になります。

2週目：判定の流れと報告の型を合わせる

判定の流れを一枚にまとめる

リリースの判定を誰が下し、誰が判断の材料を出し、例外を誰が認めるのかを、一枚に書き出します。そのうえで、発注側の責任者と「自分の役割は判断の材料を出すことか、判定そのものか」を確かめます。ここが曖昧なまま進むと、障害が起きたときに責任だけが向きやすくなります。考え方はQAマネージャーのつまずきの記事で扱っています。

報告の形を判断する人と合わせる

品質の報告は、読む人が決めやすい形でなければ意味がありません。開発責任者には不具合の内訳と修正の見通しを、事業側の責任者には利用者への影響と選択肢を、というように、相手ごとに何を見たいかを聞き、最初の報告で形を試します。指標の選び方はQAマネージャーのスキルの記事をご覧ください。

既存の定例や判定会議を引き継ぐ

前任者がいる場合は、定例や判定会議の運営をまずはそのまま引き継ぎます。進め方を変えたい点は書き留めておき、3〜4週目の見直し案にまとめます。引き継ぎの受け方は引き継ぎの記事が参考になります。

3〜4週目：見立てを出し、見直し案に合意を取る

品質の見立てをまとめる

1〜2週目に集めた材料から、「どこで不具合が作り込まれ、どこで見逃されているか」「確かめていない範囲はどこか」「基準は守られているか」をまとめます。数字は手元の記録から言える範囲にとどめ、推測で補った部分は推測と分けて書きます。

見直し案は選択肢で出す

見直し案は一つに絞らず、手間と効果の違う2〜3案で示します。たとえば「次のリリースから重大度の定義だけをそろえる」「仕様のレビューに品質の観点を加える」「外部のテスト会社の受け入れ基準を作り直す」のように、すぐできるものと時間のかかるものを並べ、発注側に優先順位を決めてもらいます。

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

合意した案を、誰が、いつまでに、何をするかに落とします。この計画が、2か月目以降の自分の仕事の範囲を示すものにもなります。初月の時点で、当初聞いていた範囲から大きく外れる仕事が出てきた場合は、早めに業務範囲の扱いを確かめてください。考え方は業務範囲が変わったときの記事で整理しています。

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

立ち上げの案件

QAの担当がいない組織では、読むべき資料そのものが少ないことがあります。初月は、関係者への聞き取りと直近の障害の振り返りに重心を置き、最低限の重大度の定義とリリースの条件の案を作るところまでを目標にします。

立て直しの案件

手戻りや障害が続く現場では、原因の見立てが初月の中心です。不具合の記録と障害の履歴から、作り込みと見逃しの工程を分けて示します。関係者が疲れていることも多いため、責める形ではなく、仕組みの問題として示すことが大切です。

大規模開発の品質管理の案件

複数のチームや外部の会社が関わる案件では、体制と指示の流れをつかむことが先です。誰が誰に作業を依頼するのかは、契約の形とも関わるため、体制図で発注元と確かめておきます。

品質責任者の補佐・助言の案件

週数日の関わり方では、初月に何を渡すかを最初に決めておかないと、関わりが浅いまま月が終わります。「月末に現状の見立てと見直し案を渡す」のように、成果物を先に合意しておきます。

初月に避けたい動き

• 前の現場の基準や帳票をそのまま持ち込む：現場の事情を知る前に重い手順を入れると、形だけになりやすくなります
• 一人で判定を背負う：判定の権限を確かめないまま「QAとしてOK」と答えると、責任の範囲が広がります
• 指標を一気に増やす：最初は判断に使う指標を数個に絞ります
• 開発チームの失敗を報告の場で責める：原因は仕組みの問題として示します
• 気づいた問題を月末まで抱える：重大なリスクに気づいたら、見立ての完成を待たずにすぐ共有します

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

• 品質の実態を、根拠とともに説明できるようになったか
• 判定の流れと、自分の役割の範囲を発注側とそろえられたか
• 報告の形は、読む人が判断に使えるものになっているか
• 見直し案に合意が取れ、次の1〜2か月の計画があるか
• 当初聞いていた業務範囲と、実際の依頼にずれはないか

ずれがあれば、2か月目に入る前にエージェントや発注側の窓口と確かめておくと、その後の進め方が楽になります。リモート中心の案件での進め方はQAマネージャーのリモート案件の記事も参考になります。

よくある質問

前任者からの引き継ぎがほとんどありません。何から始めればよいですか？

不具合の記録とリリース・障害の履歴を読み、関係者に短く話を聞くところから始めます。文書がなくても、記録と人の話から品質の実態はかなりつかめます。分からない点は一覧にして、発注側の窓口と一緒に埋めていきましょう。

参画初月から判定会議で「QAとしてOKか」を聞かれたら、どうすればよいですか？

その時点で確かめられた範囲と、確かめられていない範囲、残っているリスクを分けて伝えます。そのうえで、最終的に決めるのが誰かを確かめ、自分の役割は判断の材料を出すことだと共有しておくと、責任の範囲を広げずに済みます。

社員のQA担当がいる現場では、どう振る舞えばよいですか？

参画の初期に、品質の基準を誰が決め、日々の運営を誰が担うかを言葉で確かめます。社員の担当者が積み上げてきた運用を尊重し、変えたい点は根拠とともに提案する形を取ると、関係を損なわずに進められます。