SESでテストばかり任される｜開発に進めるまでの見極めと動き方

配属されてから、テスト仕様書を開いて画面を操作し、結果を記録する日々が続いていて、このまま開発に進めるのか不安になってきてはいないでしょうか。

私は1社目の客先常駐で、配属後の約3か月、仕事の中身はほぼテストでした。入社から数えると約4か月で、その現場は契約終了になっています。その後の現場でも、テスト工程の扱われ方の違いを何度も見ています。

今回は、テストばかりの状態から開発に進めるのか、いつまで待つのか、今の現場で何ができるのかを、実体験を交えてお伝えします。

この記事で分かること

SESで最初の仕事がテストになるのは珍しくないこと、問題は「期間」より「テストの中身」であること
手順書どおりに実行するだけの役か、設計や原因調査に踏み込める役かの見分け方
テストをしながら開発側に近づくための、現場で実際にやった5つの動き
リーダーと営業それぞれへの伝え方、待つ期間の目安と、現場替え・転職を考える判断ライン

SESでテストばかり任される状態から開発に進めるのか
私の1社目は、配属後ほぼテストだった
「期間」ではなく「中身」で見る理由
手順書どおりに実行するだけの役か、判断に踏み込める役か
私が最初に気づいた見分けポイント
テストをしながら開発に近づく5つの動き
疑問を出したら、最初の1か月は握りつぶしていた
課題票に端数処理の件を書いたあと
リーダーと営業に、開発に進みたい意思をどう伝えるか
リーダーへの伝え方
営業への伝え方と、うまくいかなかったこと
いつまで待つか、現場替え・転職を考える判断ライン
テストを専門にする道もある
私が開発に回れたのは、次の現場だった
まとめ

SESでテストばかり任される状態から開発に進めるのか

結論テストが中心なこと自体は普通です。見るべきは、半年後も同じ手順書を実行しているだけかどうかです。

入社直後や新しい現場の最初に、既存システムのテストから任されるのは、SESではよくある入り口です。ここでは私の1社目の中身と、そこから分かった「続くテスト」と「抜けられるテスト」の違いを見ていきます。

私の1社目は、配属後ほぼテストだった

1社目は2021年4月入社で、集合研修2週間と自習3週間のあと、Javaの業務システム開発の現場に配属されました。チームは5〜10名で、リモートは0日、残業は月10〜20時間です。

最初に渡されたのは、既存の設計書とテスト仕様書でした。仕様書に書かれた手順どおりに画面を操作し、結果を記録して、おかしければ不具合として報告する。これが配属後の仕事のほぼ全部です。

研修で書いていたのはJavaのコードだったので、研修で身につけたことと現場の仕事に、ほとんど接点がありませんでした。最初の1週間で、結合テストのケースを1日あたり25〜30件ほど消化するペースに乗りました。

この初期の様子は、新卒1年目の配属の流れを書いた記事にも出てきます。ここでは、そのテストの中身がどう変わったか（変わらなかったか）に絞って書きます。

「期間」ではなく「中身」で見る理由

不安のもとは、おそらく「いつまでテストなのか」だと思います。ただ、期間だけを物差しにすると判断を誤ります。

同じ3か月でも、毎日同じ手順書を同じように実行している3か月と、仕様の曖昧さを指摘し、不具合の原因を調べる範囲が少しずつ広がっている3か月は、まったく別物です。前者は3か月後も次がなく、後者は放っておいても次の仕事が回ってきやすくなります。

私の1社目は、配属から約8週目までは前者でした。そこから少し変えたことで、残りの約1か月の中身が変わりました。何を変えたのかは、次の見極めのセクション以降で書いていきます。

手順書どおりに実行するだけの役か、判断に踏み込める役か

結論「期待結果を誰が決めているか」と「不具合の原因を誰が調べているか」の2点を見れば、その役が実行専門かどうかはほぼ分かります。

テストの役には、大きく二つの形があります。手順書を実行して結果を書くだけの役と、仕様の穴を見つけ、原因を調べ、テスト設計にも関わる役です。自分の今の立ち位置がどちらに近いかを、具体的な観察項目で確かめていきます。

手順書を実行するだけの役

テスト仕様書は他の人が作り、完成品を受け取る
期待結果は書かれているとおりに照合する
不具合は「現象と再現手順」を報告して終わり
評価されるのは消化件数と期限

判断に踏み込める役

仕様書の期待結果に疑問があれば指摘できる
設計書とテスト仕様書を突き合わせて読む
不具合は原因の仮説まで添えて報告する
評価されるのは見つけた不具合の質と指摘

テストの役の二つの形。同じ「テスト担当」でも、半年後の景色は大きく変わります。

どちらが良い悪いではなく、前者のままでは開発に必要な力はほとんど育たないという点が大事です。この枠組みは、スキルが身につかない現場の構造を書いた記事でも整理しています。

私が最初に気づいた見分けポイント

配属から2か月ほど過ぎたころ、テスト仕様書の期待結果の欄が気になりました。「金額が正しく表示される」としか書かれていないケースが、ひと続きで20件近くあったのです。

設計書を開くと、割引後の金額の端数処理（切り捨てか四捨五入か）がどこにも書かれていませんでした。実際に画面を動かすと切り捨てで表示されていますが、それが正解かどうかを判断する材料が、仕様書にも設計書にもありませんでした。

そこで初めて、期待結果を決めている人が誰なのかを意識しました。自分は決める側ではなく、書かれた期待結果に○×をつけるだけの位置にいる。この気づきが、動き方を変えたきっかけです。

自分の役が実行専門かを確かめる5項目

期待結果の欄が「正しく表示される」のような曖昧な書き方になっていないか
仕様書を作った人に、疑問をそのままぶつけられる雰囲気があるか
不具合報告に、原因の切り分けまで求められているか（現象だけで終わっていないか）
設計書やソースを読ませてもらえる環境か（閲覧権限があるか）
テストの前後工程の人（設計者・実装者）と、直接話す機会があるか

3つ以上が「ない」なら、実行専門の位置にいる可能性が高いです。その場合でも、次に書く動きで半分くらいは変えられます。

テストをしながら開発に近づく5つの動き

仕様書の曖昧さに気づいてから、その後の約1か月でやったことを、効果のあった順に並べます。いずれもリーダーに特別な許可を取らなくても始められる範囲です。

設計書とテスト仕様書を並べて読む仕様書だけを見て実行するのをやめ、各ケースがどの設計項目に対応するのかを自分で確認しました。
疑問は課題票に書いて出す口頭で聞くのが怖かったので、質問・課題を整理するExcelに文章で書きました。
不具合報告に原因の仮説を添える「現象」だけでなく、ログやデータを見て「ここが怪しい」と書くようにしました。
該当ソースを読ませてもらう不具合の仮説を確かめるため、先輩に頼んで該当部分のコードを見せてもらいました。
次にやりたいことを一度は口に出すリーダーに、修正側の作業に興味があることを伝えました（次のセクションで詳しく書きます）。

疑問を出したら、最初の1か月は握りつぶしていた

正直に書くと、最初の1か月は何も出していません。新人が仕様書に意見するのは出過ぎている気がして、気づいた違和感を自分の中で黙らせていました。

後から分かったのは、私の疑問は黙っていても誰も気づかず、そのままテストが通り、のちのち別の人が同じ箇所で詰まるだけ、ということです。出すタイミングが遅れた分だけ、その間のテスト結果もあやふやなまま積み上がっていました。

課題票に端数処理の件を書いたあと

先ほどの端数処理の件を、課題票に次のように書いて出しました。「割引後金額の端数処理について、設計書に記載が見当たりません。現在は切り捨てで表示されますが、期待結果として切り捨てでよいか確認させてください」。

翌日、仕様書を作った先輩が設計書側に誤記があったと認め、設計書と仕様書の両方を直してくれました。結果として20件近くのケースの期待結果が書き直され、私が消化済みだった分も再実施になりましたが、「あの課題票、助かった」と言ってもらえたのは大きかったです。

私の場合：指摘が通った直後に起きたこと

端数処理の件のあと、先輩から「他の画面の期待結果も、同じ観点で見てもらえますか」と頼まれました。仕様書の見直しという、テストの前の工程に半歩だけ入れた瞬間です。

この依頼をきっかけに、配属から約10週目以降は、不具合の原因調査（ログとSQLの確認）を2件任されました。実装そのものではありませんが、手順書を実行する作業から、考えて動く作業に変わりました。

リーダーと営業に、開発に進みたい意思をどう伝えるか

結論現場の配置を実際に決めているのは客先のリーダーです。伝えるなら、まずリーダーに具体的な作業名で話すほうが早く進みます。

「開発がやりたいです」と抽象的に言うだけでは、何も動かないというのが私の実感でした。リーダーと営業それぞれに、実際にどう伝えて、何が起きたのかを書きます。

リーダーへの伝え方

配属から12週目の1on1で、客先のリーダーに次のように話しました。

私

テストの中で設計書の読み方が分かってきました。不具合の修正側の作業にも関わってみたいです

客先のリーダー

今の結合テストが終わったら、軽い修正を1件振ってみましょうか。その前に、今回の不具合の原因調査をまとめておいてください

ポイントは、「開発をやりたい」ではなく「不具合の修正側の作業」と、すぐ着手できる具体的な作業の名前で言ったことです。リーダーは仕事を振る側なので、振りやすい形で出された希望のほうが検討しやすくなります。

ただ、その後まもなく私の契約が終わり、修正の1件は実際には振られませんでした。実装に進む前に、入社から約4か月で1社目が終わっています。

営業への伝え方と、うまくいかなかったこと

自社の営業にも、月1回の面談で「テスト中心の状態で、できれば開発に進みたい」と伝えました。返事は「客先にそれとなく伝えておきます」でしたが、その後に現場の割り振りが変わった形跡はありません。

営業が客先の現場の中身を細かく知っているわけではなく、伝わるのは「本人が不満らしい」という温度感だけ、というのが私の感触です。営業が持っている情報と動かせる範囲は、別の記事で整理しました。

営業には「テストから開発に回してほしい」とお願いするより、「次の更新のタイミングで、開発工程のある案件を探してほしい」と時期つきで頼むほうが現実的でした。現場の中の配置はリーダー、現場そのものの選び直しは営業、と窓口を分けて考えるのが実務的です。

いつまで待つか、現場替え・転職を考える判断ライン

結論3か月で一度、半年で一度、動いた結果を見て判断します。待つ期間は短くて構いませんが、その間に足がかりの動きを必ず入れます。

ここからは、期間に応じた私なりの判断ラインです。統計や公的な基準があるわけではなく、1社目から4社目までの現場を見てきた上での個人的な目安になります。

経過	見るもの	動き方
配属〜3か月	期待結果の疑問を出せたか、原因調査に関われたか	上の5つの動きを入れて様子を見る
3〜6か月	作業の中身に変化があったか（修正・設計への関与）	リーダーに具体的な作業名で希望を伝える
6か月〜1年	変化がないまま、手順書の実行だけが続いているか	次の契約更新に合わせ、営業に現場替えを時期つきで依頼
1年以上	依頼しても変わらないか	転職も含めて、開発工程のある環境を探す

私の1社目は約4か月で終わりました。ただ、その後の現場では、半年以上続けて手順書を実行するだけの状態になっているメンバーを見たことがあります。その人たちは、仕様の指摘や原因調査を自分から出さずに過ごした期間が長いほど、次の仕事を選べる幅が狭くなっていました。

テストを専門にする道もある

ここまで開発に進む前提で書いてきましたが、テストを軸にしたキャリアも、れっきとして存在します。JSTQB（ソフトウェアテスト資格認定の運営団体）では、基礎のFoundation Levelから、テストアナリスト、テスト自動化エンジニア、テストマネジメントなど、役割別に資格の区分が用意されています（出典: JSTQB）。

つまり、手順書を実行する役の先に、テスト設計・自動化・管理といった専門職の道があるということです。大事なのは、自分がどちらに進みたいかを決めたうえで、今の現場の動きを選ぶことです。開発に進みたいなら上の5つの動き、テスト専門に進みたいなら、テスト設計や自動化に関われる現場を狙う、と使い分けます。

私が開発に回れたのは、次の現場だった

結局、私が開発寄りの仕事に就いたのは、1社目の中ではなく2社目でした。1社目は契約終了で入社から約4か月で離れ、2社目では設計から担当することになりました。

自分の動きだけで開発に進めたわけではなく、巡り合わせの面が大きいのが実際のところです。ただ、1社目のテストで設計書を読む目を育てていたことは、2社目の設計工程に入ったとき、明確に役立ちました。

まとめ

SESでテストが中心になること自体は、よくある入り口です。問題は期間そのものより、半年後も手順書を実行するだけの状態でいるかどうかです。

私の1社目は、配属から約8週目までは完全な実行専門でした。仕様書の期待結果の曖昧さを課題票に出し、原因調査に関わる範囲を少しずつ広げたことで、残りの期間の中身は変わりました。ただ、実装まで進む前に契約が終わったので、最終的に開発に回れたのは次の現場です。

テストばかりの現場で、今日から確かめること

期待結果と設計書を突き合わせて、疑問点を1つでも課題票に出したか
不具合報告に、原因の仮説を添えているか
リーダーに、具体的な作業名で次にやりたいことを伝えたか
営業には、現場の中の配置ではなく、次の更新時期を軸にして頼んだか
3か月・半年の節目で、作業の中身が変わったかを見直しているか

動き方を変えても、現場の都合で何も変わらないことは当然あります。その場合に備えて、変化があったかどうかを節目ごとに確認しておくと、現場替えや転職の判断を、感情ではなく事実で下せます。

テストの経験は、無駄になりません。設計書を読む力、仕様の穴を見つける目、不具合の切り分けは、のちの工程で確実に効いてきます。今の現場の中身を見極めて、変えられる部分から動いてみてください。

SESで上流工程にどこまで関われるのかは、別の記事でさらに詳しく書いています。