テスト自動化エンジニアの参画初月にやること｜現場で信頼される進め方

テスト自動化エンジニアの参画初月は、既存のテストを手元とCIで動かして現状を数字でつかみ、落ちたテストを誰がどう扱うかを関係者と決め、月末に「改善の見立て」と「手をつける順番」を出して合意を取るところまでを目標にします。最初の1か月で求められるのは、テストを大量に書くことより、この人に自動テストを任せて大丈夫だと発注側が判断できる材料を示すことです。

この記事では、初月のゴール、週ごとの進め方、案件の型による重心の違い、避けたい動き、月末の振り返りを整理します。参画初日から最初の1週間の一般的な動き方は参画初日から最初の1週間でやることで扱っているので、ここではテスト自動化ならではの点に絞ります。

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

1か月で目指すことを、次の3つに分けておくと、日々の作業の優先順位がつけやすくなります。

この3つは、案件の型にかかわらず共通です。新しくテストを書くことは、この3つを進める中で、小さく始めます。

1週目：手元とCIで動かし、話を聞く

テストを手元で全部動かす

最初にやるのは、既存のテストを自分の手元で動かすことです。手順書どおりに環境を作り、テストを全部走らせて、どこで詰まったかを書き留めておきます。詰まった箇所はそのまま、次に入る人がつまずく箇所でもあり、手順書を直すという最初の小さな成果になります。

CIの履歴を読む

次に、CIの実行の履歴を、ここ数週間分さかのぼって見ます。見るのは次の点です。

• 1回の実行にかかる時間と、その推移
• 失敗した実行の割合と、再実行で通ったものの割合
• 落ち続けているテスト、ときどき落ちるテスト
• 失敗したときに、誰かが反応しているか

この段階では、直すより記録することを優先します。CIでの失敗の調べ方はテスト自動化エンジニアのリモート案件の記事でも触れています。

関係者と短く話す

QAの担当者、開発リーダー、発注側の窓口と、短い時間でよいので話します。聞くのは、自動テストに何を期待しているか、どのテストの結果を信じているか、困っていることは何か、です。立場によって期待が違うことが多く、その違いを知っておくことが、後の提案の土台になります。

2週目：失敗を分類し、小さな修正を出す

落ちているテストを分類する

1週目に集めた失敗を、原因の見立てで分けます。仕様が変わってテストが古くなったもの、待ち方やデータの扱いで不安定なもの、環境の不調で落ちたもの、本当の不具合を見つけているもの、の4つくらいに分けると、話が整理しやすくなります。

小さな修正を、現場の流れで出す

分類の中から、すぐに直せるものを一つか二つ選び、現場のレビューの流れに沿って修正を出します。目的は成果の量ではなく、ブランチの切り方、レビューの頼み方、マージの条件など、現場の流れに乗れることを示すことです。コードの書き方も、最初は既存のテストに合わせます。

失敗の扱いを話し合う

落ちたテストを誰がいつ見るか、再実行を何回まで認めるか、どの条件で一時的に外すかを、窓口と開発リーダーに提案します。決まりが既にあれば、その運用の実態を確かめます。合意した内容は、開発チームが見られる場所に書き残します。

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

現状の見立てをまとめる

3週目には、集めた数字と分類をもとに、現状の見立てをまとめます。「E2Eに偏っていて実行時間が長い」「データの共有が原因の不安定さが多い」のように、原因の傾向と、それが開発の流れにどう影響しているかを書きます。

改善の案は選択肢で出す

改善の案は、一つに絞らず、選択肢として出します。たとえば、不安定なテストを先に直す案、E2Eの一部をAPIのテストに移す案、実行を並列にして時間を縮める案、などです。それぞれに、手間と効果の見込み、発注側に決めてほしいことを添えます。どれを選ぶかを決めるのは発注側、という形をとると、優先順位を巡る食い違いが起きにくくなります。

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

合意した案をもとに、次の1〜2か月で何に手をつけるかの計画を引きます。新しくテストを増やす範囲もここで決めます。週ごとの報告の形も、この時点で窓口とそろえておくと、翌月から進めやすくなります。報告の書き方は週報・進捗報告の書き方をご覧ください。

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

立ち上げの案件

自動テストがまだない、または少ない現場では、現状の把握より、どの層から始めるかと、枠組みの選定が初月の中心になります。道具を選ぶときは、開発チームの言語と、社員が引き継げるかを判断の軸に入れ、選択肢と理由を出して決めてもらいます。月末までに、主要な流れを確かめる最初のテストがCIで回っている状態を目指すと、方針が絵に描いた餅ではないことを示せます。

立て直しの案件

テストはあるものの信頼されていない現場では、失敗の分類と、扱いの決まりづくりが初月の中心です。全部を書き直したくなりますが、まずは残すもの・直すもの・やめるものに分け、合意を取ってから手を入れます。

拡充・保守の案件

基盤ができていて、テストを増やしたり保ったりする現場では、既存の書き方の決まりを覚え、それに沿って早く書けることが初月の評価につながります。増やす対象の優先順位を、QAの担当者とすり合わせておくと、手戻りが減ります。

初月に避けたい動き

• いきなり道具や構成を変える：前の現場で慣れた枠組みに置き換える提案は、現状を理解したうえで、選択肢の一つとして出します
• 黙ってテストを外す：不安定なテストでも、無断で外すと確かめていない範囲ができたことが伝わりません。外す条件と戻す期限を合意してから行います
• 大きな修正を一度に出す：レビューする側の負担が大きく、現場の流れに乗れていない印象を与えます。小さく分けて出します
• AIで作ったテストを確かめずに増やす：何を確かめているかを自分で説明できるものだけを出します
• 相談せずに抱え込む：CIや環境の不具合など、自分の範囲の外にある原因は、分かった時点で窓口に共有します。チャットでの相談の書き方はチャットでの報告・相談の書き方をご覧ください

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

月末には、次の点を自分で振り返り、窓口とも短く確かめます。

1. 現状の数字と見立てを、関係者が理解し、合意できたか
2. 落ちたテストの扱いの決まりが、実際に使われ始めているか
3. 現場の流れに沿って、修正を出し、レビューを通せたか
4. 期待されている役割と、自分の動きにずれがないか
5. 契約の業務範囲を超える依頼が来ていないか

5つ目で範囲のずれが見えた場合は、早めに扱いを話し合います。考え方は作業範囲が広がったときの記事で整理しています。初月以降につまずきやすい場面はテスト自動化エンジニアがつまずきやすい点と対策をご覧ください。

よくある質問

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

テストを手元で全部動かすことと、CIの履歴を読むことから始めてください。コードとCIの記録は、引き継ぎの資料がなくても残っています。動かしたときの詰まりどころを手順書にまとめると、現状の把握と最初の成果を同時に得られます。引き継ぎの一般的な進め方は契約終了時の引き継ぎの記事も参考になります。

初月から新しいテストをたくさん書くよう求められたら、どうすればよいですか？

求めに応じて書きつつ、既存のテストの現状も並行して把握してください。土台が不安定なまま増やすと、後で直す手間が増えます。増やす前に、失敗の扱いの決まりだけでも合意しておくことをおすすめします。

開発チームのレビューがなかなか通りません。

最初は、既存のテストの書き方に合わせ、修正を小さく分けて出すのが基本です。指摘の内容から、現場が大切にしている書き方の決まりが見えてくるので、それを自分のメモにまとめておくと、2か月目以降の修正が通りやすくなります。