私はQAエンジニアとして仕事をしており、直近でテスト会社から事業会社に転職をしました。テスト会社や第三者検証会社については既出の記事で説明していますので、「テスト会社ってなんだ?」と思った方はぜひ前回の記事も読んでみてください。

自分自身が転職活動をする中でも経験し、また他のQAエンジニアのつぶやきでたまに話題に上ることとして「テスト会社のエンジニアは事業会社では活躍できない」と思っている方が一部にいる、ということがあります。

この意見について、私はそのようなことはないと考えています。実際にテスト会社にいた優秀なQAが事業会社に移り活躍しているのを多数見ていますし、所属会社の事業形態によって十把一絡げにQAエンジニアを評価してしまっては、誰も幸せになりません。

そこで今回はこの「テスト会社のエンジニアは事業会社では活躍できない説」について、なぜそのように思われているのかを考察し、テスト会社のエンジニアも事業会社で十分活躍できるというポイントを説明します。

なぜ、活躍できないと思われているのか

まず、なぜ活躍できないと思われているのかを考えてみましょう。

この背景には、テスト会社・第三者検証会社のビジネスに対する誤った認識、もしくは過去にテスト会社に対して不満を抱いた経験があるのだと考えています。

よく聞かれるのは、たとえば

・QA業務を発注している事業会社側が仕様書を作成し、テスト会社のメンバーはその仕様書にしたがってテストを実行するだけ
・「第三者検証」であることを理由に開発チームに入らず、独立したテストチームとして動くために連携ができない

などです。

 ―誤解1:受け身である

前回の記事で触れたように、事業会社はテスト会社にQA関連の業務を依頼し、請負契約や派遣契約でテスト会社のQAエンジニアに入ってもらうという形をとります。この、QA業務を依頼する・依頼を受ける、という関係性から「テスト会社のQAエンジニアは受け身である」と誤解をしてしまう方がいるようです。

誤解をしている方の前提には、仮に自社の正社員のQAエンジニアであれば、自分から主体的に「開発プロセスのこの部分を改善しよう」や「他部署と協力してQA活動を見直そう」等の動きが出てくるはずだという考えがあります。

一方、テスト会社のQAエンジニアに対しては「言われたことしかしない」「自分たちの仕事の範囲を区切ってその中でしかやらない」と感じている、という状態です。

この誤解は、過去に受け身のQAエンジニアと働いて不満を抱いた経験から、全体がそうだと考えているために起こっています。

 ―誤解2:開発チームの外にいる

昨今のソフトウェア開発においては、役割を明確に分けて「担当範囲はここまでです」という線引きをするよりも、ある程度ロールをまたいで協力する形が良いとされています。しかし、テスト会社のエンジニアは「開発者が作ったものに対するテスト」しかしない。一緒になってより良い開発のために取り組んでほしいのに、不満である。私自身、そうした声を聞いたことはたしかにありました。

これは「受け身である」という点にも通じますが、テスト会社のエンジニアがあくまでも「第三者」としての線引きをして、開発チームの外で活動を行うと思われているようです。

実際はどうなのか

これらの誤解があるものの、実態はどうなのでしょうか。

 ―テスト会社のQAにも主体性はある

この点に限らず、ある業態の会社に勤める全員が同じような性質を持つ、ということはありません。

テスト会社にも主体性を持って動けるエンジニアが数多くいます。もちろん言われたことしかやらない・できないエンジニアもいますが、それはテスト会社だからではありません。事業会社にも主体性を持ったエンジニアとそうでないエンジニアがいて、テスト会社における割合とは特段変わらないと感じています。

では「テスト会社のQAは主体性がない」と思ってしまうのはなぜでしょうか。

1つは、スキルと単価の都合があります。

普段の業務に加えてさまざまな改善活動に取り組んだり、メンバーの教育に力を入れたりできるエンジニアは、当然テスト会社の中でも評価されます。その結果、現場でのリーダーになったり、複数チームをマネジメントする立場になったりします。そうしたQAエンジニアに業務を行ってもらうには当然単価も高くなりますし、テスト会社に業務を依頼する事業会社間での取り合いのような形にもなります。

テスト会社のQAに主体性がない、と思っている場合は、主体性のあるQAエンジニアをテスト会社がアサインできるほどの金額を出していない可能性があります。

その他に考えられるのは、契約や業務体制の都合でQAエンジニア側が動きづらくなっている可能性です。

QAエンジニア本人には主体性があってさまざまな取り組みをしたいと思っているものの、たとえば

・事業会社側から適切な情報が提供されない、情報が絞られている
・業務改善の提案をしたが聞き入れられない、という経験を何度も味わった
・日々の業務に忙殺されている、本人のスキルや職能に対して過度な要求をされている

などの理由で、主体性を発揮できない環境になってしまっている、というケースもあります。

 ―開発チームとの協力を望む

もう1点の「開発チームの外にいる」という点についてもテスト会社のQAが望む形ではないと考えています。

たしかに、過去には「第三者」として、開発チームとは別組織として動いているテスト会社もあったかと思います。

しかし、昨今の内製化の動きやアジャイル開発などの普及にともない、多くのQAエンジニアは開発チームとの協力・協調や、開発チームの中に入ってともに品質向上のために取り組むことを望んでいます。

そうしなければ、昨今の早い開発サイクルにおいてはテストがボトルネックになってリリーススピードを落としてしまいます。また、品質はQAが後からテストするだけでは担保できず、開発サイクル全体で早い段階から意識するべきものというのが共通認識になっています。

そのため、テスト会社のQAであっても「開発と自分たちとは別」といった線引きをすることは、基本的にはないでしょう。

テスト会社で身につけたスキルを事業会社で活かす

ここからは私個人の経験談になりますが、実際にテスト会社から事業会社に転職して、テスト会社時代に身につけたスキルが役に立っていると感じるポイントも数多くあります。

 ―品質課題を見つけ、改善を行う

テスト会社のQAエンジニアは、顧客である事業会社などからくる「***で困っているのでなんとかなりませんか?」という相談に対して適切な対策を検討したり、逆にテスト会社側から「ここが課題なので、***に取り組んで改善していきませんか?」と提案をし、業務を受注します。

つまり、業務を受注する=テスト会社が売上を得ていくためには

・顧客の悩みや課題を適切に把握し、
・課題に対するアクションを検討し、
・課題とアクションを顧客に伝え、納得してもらう

というステップが必要になります。

私もテスト会社での業務を通じ、何度もこれらの提案活動を経験しました。もちろん100%うまくいったわけではありませんが、上司からもていねいに指導をしてもらい、さまざまなことを学びました。

事業会社、とくに1人目のQAを募集している会社にJoinする場合、QAエンジニアは自ら仕事を作る動きが求められます。決まったタスクがない中で、開発チームの話を聞きながらやるべきことや目標を決め、交渉し、実行に移す。実際に私が今やっていることですが、これはまさにテスト会社での提案活動と同じです。

 ―さまざまな業種・会社での知識と経験

また、テスト会社のQAとして関わったことがある業種・会社の幅も、事業会社におけるQA業務の役に立っていると感じています。

テスト会社ではWebや組込み、toBやtoCなど、さまざまなQA業務に関わる機会があります。これらの経験は、品質保証のやり方・考え方について幅を広げる役に立ちます。

事業会社においても、「他社ではどのようなやり方をしているのか」「世間一般ではどうなのか」といった質問を受けることがあります。テスト会社のQAとして働いた多様な経験から、他社の良い点を取り入れつつ、自社の特色に応じた改善施策を検討するなどができていると実感しています。自社しか知りません、この業界しか知りません、という状態のQAエンジニアよりも、活躍できるのではないでしょうか。

テスト会社のQAエンジニアは事業会社でも活躍できる

テスト会社のQAエンジニアも、事業会社で十分活躍できる、と私は考えています。

もちろん、テスト会社にも多様なQAエンジニアがいて、それぞれスキルや経験は異なります。しかし、テスト会社だから大半のQAは受け身だ、ということはないです。それぞれ業種は異なりますが、同じQAエンジニアというロールである以上、その役割や求められる振る舞い・スキルには共通する部分も多いです。

実態として、事業会社の中において自分たちでQAエンジニアをゼロから育成できるところは決して多くなく、テスト会社がその役割を担っている部分があります。それを無視して、市場で他社が育成した優秀なQAエンジニアを求めつつ、そのようなQAを育成しているかもしれないテスト会社に対して「テスト会社のQAはいまいち」と思ってしまうのは問題です。

これではソフトウェアテスト・QA業界にとっても良くないことなので、ぜひ事業会社とテスト会社それぞれに勤めるQAエンジニアのことをフラットに見てもらいたいと思います。

(文:伊藤由貴

 presented by paiza

Share

Tech Team Journalをもっと見る

今すぐ購読し、続きを読んで、すべてのアーカイブにアクセスしましょう。

続きを読む