AGEST の技術ブログ

全487件

2023/10/23

「1人目QA」というワードを、2020年ごろからよく聞くようになりました。もちろんそれ以前から、組織の中で1人目のQAとして活動をされてきた方はたくさんいました。しかし、QAエンジニアという職種の認知が広まったことで「いままでQA専門の人は居なかったけど、ウチにも要るよね」と思いはじめた会社が多くなり、採用募集や実際に1人目QAとしてお仕事をする方も増えたように思います。私自身も、現在は1人目のQAとして試行錯誤をしている身です。そこで、本記事からは“1人目QAとしての立ち回り”シリーズとして、1人目のQAに求められていること、実際にやってみて大事だと思ったことなどをお伝えしていきます。なお、本記事では「QAエンジニア」を指して「QA」と表現します。 1人目QA、とはなにかまずはタイトルにもある「1人目QA」がそもそも何なのか、から考えてみましょう。会社の1人目なのか、部署の1人目なのか、などは組織によってバラバラですが、共通するのは「前任者や同僚のQAが居ない状態」に新たに入ってきたQAエンジニアという点です。前任者や同僚が居ないということは、テストや品質保証を開発者が試行錯誤しながら行っている、テストや品質保証の体制が整っていない QAの具体的な役割やロール設定がないということです。つまり、1人目QAはプロダクトのテストや品質保証業務と並行して、これらを決める・つくることも担う存在、といえます。需要が増えている1人目QA 冒頭にも触れたように、2020年ごろからX（旧Twitter）上でも1人目QAに関する言及が増えてきており、求人サイトでも「QA立ち上げメンバー」や「1人目QA」などを募集する企業を目にするようになりました。要因はさまざま考えられますが、そもそもの「QAエンジニア」というロールの認知・必要性の理解が進んできているため、募集する企業が増えた、と考えられます。それに伴って、「今はQAエンジニアやQA専任の組織はないけれども、新たに立ち上げをしたい」という企業も増えてきました。 QAチームをつくるうえで、1人目のQAはとても重要です。そのチームや組織のカルチャーを創る存在でもありますし、組織におけるQAや品質への期待を把握しつつゴールとタスクを具体化しながら進めていく、という高難度の仕事を担うことになります。開発組織へのアプローチの仕方そんな難度の高い仕事を担う1人目QAについて、本記事と今後の連載を通じていくつかの切り口で分類を試みます。今回は、1人目QAによる、開発組織へのアプローチの仕方について考えます。 1人目QAが新たにJoinして開発組織と一緒に業務を行う場合、考えられるパターンは大きく2つあります。パターン1:特定のチームに入り込むひとつは、特定のチームに入り込んで、そのチームの専任QAとして実務を行うパターンです。開発しているプロダクトが一つだけのところに1人目のQAとして入る場合や、専任QAが居ない状態で複数プロダクトを開発していたうちの1プロダクトに専任QAとして入る場合などがあります。特定のチームに1人目のQAとして入る場合、それまでのテストのやり方や品質に対する考え方などを把握しつつ、そのチーム・プロダクトにとって最適な品質向上のプロセスや仕組みづくりを担っていきます。同時に、そのプロダクトのリリースに向けた普段のテストや改善活動なども行います。チームや組織によって求められることはさまざまですが、例としてテスト計画・分析・設計・実装・実行・報告までの、テストプロセスに沿ったテスト活動全般テストプロセスの整備探索的テストによる “バグ出し” チーム内の不具合管理や分析要件や設計、単体テスト等のレビュー開発者に対するテスト技法や品質についての考え方のレクチャーテスト自動化などがあります。実際に1人目QAとしてJoinする方にとってのパターン1のメリットは、開発チームと密に連携できる、プロダクトの仕様や過去の経緯などをキャッチアップする範囲が狭めという点が挙げられるでしょう。範囲や対象がある程度絞りつつ、1人目QAとしての取り組みをタスクレベルに分解・取り組みがしやすい一方で、ある程度短期的な成果が求められることもあります。パターン2:複数チームに広く浅く関わるもうひとつは、複数のチームやプロダクトに横断的に関わり、兼務のような形で外から品質向上の手助けをするパターンです。専任QAが居なかった会社において、組織全体として品質向上の取り組みを始めるために1人目QAとして入る場合や、社内のQA業務を外部の会社に依頼しているところに1人目の正社員QAとして入る場合などがあります。こちらはパターン1とは異なり、より組織にフォーカスした働きを求められる傾向にあります。たとえば組織全体でのテスト・QA活動状況の把握「QAエンジニアとは」の認知向上 2人目3人目のQAエンジニアの採用関連業務「品質基準」や「テスト標準」など、組織全体に関連するルールや基準の制定および普及チームをまたいだテストプロセスや不具合の管理・分析方法の設定などがあります。こちらのパターン2の1人目QAとしてJoinするメリットは、パターン1と比べてより広い範囲に携われること、中長期的な視点で品質向上施策やチームをまたいだ土台づくりに着手できることなどがあります。一方、横断的に関わるQA側が積極的に開発チームに対して働きかけをしていかないと、品質向上施策がなかなか進まないなど、成果が出づらくなってしまう面もあるでしょう。 2つのパターンを行き来する場合も実際に私自身も「1人目QA」として仕事をしており、パターン2に近い形で動いています。便宜上パターン1と2、という区別をしましたが、これらは完全に別物であったり、一方を選択したらもう一方は選べない、というものでもありません。状況によっては、それぞれを切り替えたり、ある程度両立させようとすることも考えられます。たとえば私が所属する部門では、複数の開発部が存在しており、私が入社するまで専任のQAは居ませんでした。そこに1人目のQAとしてJoinしたわけですが、最初に考えたのが「特定のチームに入り込んで動く（パターン1）のと、広く浅く全体をみる（パターン2）のと、どちらがいいだろう？」という点です。最初はパターン2を選択して、各開発チームに対して少しずつ関わっていました。しかし、しばらく行ってみたところなかなか品質向上活動が前に進んでいない実感があり、これは特定のチームで成功事例を作らないと難しそうだと考え、パターン1に近い形に変更をしました。その後、ひとつのチームに入り込んで活動をしつつ、そこで行った内容を他のチームにも共有することで「それならウチも」と声をかけてもらえるようになりました。結果として、再度パターン2の形に近づいています。これはあくまでも私の例であり、これが正解ということはありません。組織規模や開発チームの文化などに応じて、つど考えていくことが大切です。「1人目QA」が活躍するために、2つのパターンをもとに考えましょう今回は、1人目QAについての概要と、1人目としてJoinしたQAが開発チームに関わって活動していく際の2パターンについてご説明しました。特定の開発チームに入り込む場合と、複数の開発チームに対して外から関わる場合。組織の状況や募集時の要件などによってどちらかのパターンに定まることもあれば、どちらかを選択したり行き来しながらQA活動を進めることもあります。もし選択できる場合には、開発組織のマネージャーなどと「どちらのパターンでいくか」を一緒に考え、合意することが大切です。1人目QAとしてJoinした場合、もしくは1人目QAを迎え入れる場合は、いずれのパターンが適切かを考えてみてください。 The post 1人目QAの位置づけと、開発組織へのアプローチの仕方 first appeared on Sqripts .

AGEST の技術ブログ

コンテンツ