この記事は自動テスト Advent Calendar 2020の25日目です。
TL;DR
- 自動テスト/SETチームのマネージャー( https://twitter.com/ozonohiroaki )
- これの続編
- 自動テストやればそれで良しなんて時代はとっくの昔に終わっている(もしくは、最初からそんな時代は来ていない)。その先を考えなきゃ生き残れない
- テスト系エンジニアの職種は細分化されつつある。それぞれの職種に合ったキャリアパスや採用方針を考える必要性が高まってきている
はじめに
12月初旬アドカレなに書こうかなぁと考えていた矢先、Selenium Grid4のBeta prerelease版Docker imageが上がってるのを見てこれで遊んでみるかと軽く考えていたんです。ですが、「お前はそういうのはいいからポエムでも書いとけよ」という謎のプレッシャーを感じたので、去年のアドカレに書いたあなたが自動テストを行う目的は何ですか？の続編でも書いてみようかなと思い立って今に至ります。Selenium Gridは別の記事にでもしときます。
簡単に前回書いた内容を振り返っておくと、
- スクラッチから自動テスト専門の部隊を作ったはいいものの、
- 目的をあやふやにしたまま業務に取り組んでしまい、
- たくさんの失敗をしてしまった。だから反面教師にでもしてください
このような内容を書きました。
思えばこの一年はこの記事をきっかけにてすらぼというコミニュティを立ち上げさせてもらったり、会社の大きなイベントでも取り組みを発表させていただくなど、動きの大きな一年だったなと感じています。
もとから対外的な活動にはなんの抵抗もないタイプの人間ではあります。ただし、ここ一年会社外での活動量を増やしたのには大きな理由があり、それは間違いなく危機感から来るものでした。
今回は自動テスト系のエンジニアという職種に絞った話を書きたいなと思います。
自動テストをやる「目的」をもう一度考えてみる
前回の記事では目的は大事だ、ということを散々強調しました。目的を定めていないと上手くいきにくくなりますよ、と。ただ、どのような目的があるかなどに関しての細かい言及まではしていませんでした。今回はもう少しそのあたりを深堀りしていきたいと思います。
まず思い浮かぶのはアプリケーションの品質向上でしょう。特にE2Eテストの文脈では品質のことを取り上げられることがほとんどだと思います。ただ、テストにはもう一つの大きな役割があります。それは開発をしやすくする環境を作るためにテストを有効活用するという側面です。
例えばREST API serverのControllerやサービスロジックに対するテストは、品質のためだけに書かれているでしょうか？
はたまた、frontendのViewに対してsnapshot testをするのは、出来上がったアプリケーションの品質を担保するためだけに書くでしょうか？
もちろんこういった側面もありますが、多くは自分自身が素早く開発するためというむきが強いのではないでしょうか。
新しい機能を開発したらCIですぐにテストが実行され、静的解析などで潜在的に危ないところを素早く検知する。このような環境があるかないかで開発の速度が全く違うということは私が語るまでもないでしょう。
私は数年前にiOS/Android/Browserのアプリケーションを自動テストするためのチームを立ち上げ、それらに特化した業務を続けてきましたが、がむしゃらにE2Eテストを実施するだけではアプリケーションの品質担保には貢献できても開発者の働きやすさにはあまり貢献できていないということを痛感しました。このあたりの話はLINE Developer Day2020でお話させていただきましたので詳しくはこちらをご参照ください。
端的にお伝えすると、E2Eテストはどうしても時間的、空間的、はたまた人的なコストがかかりやすいものであり、かつ不安定になりやすい。工夫なく実行するとイテレーションの頻度が低くなってしまう。つまり、開発者へのfeedbackに時間がかかってしまうというものでした。
こうして私のチームはアプリケーションの品質向上の目的に加え、エンジニアの働きやすさ、すなわち開発者体験(Developer eXperience)を良くするという目的を定めました。
SET/自動テストエンジニアの採用戦略
こうしてDXの向上に取り組み始め、いくつかのプロジェクトで手応えを感じ始めたところでチームを拡大していくというのは当然の流れとなるでしょう。しかしこれが一筋縄ではいかないのです。
アプリケーションの品質担保を目指すE2Eの自動テストエンジニアは、私の知る限りQAエンジニアやTesterからのジョブチェンジが多いように思います。もしくはQAをしながら自動テストをやるか。アプリケーションの品質にフォーカスを当てているのだから、これは必然の流れと言えるでしょう。手で動かす場合も自動で動かす場合も、ブラックボックスなテスト戦略を考える上では大きな違いはありません。QAとしての知識や経験を存分に活かすことができるでしょう。加えて、QAやTesterという職種は日本にもたくさんありますし、海外も視野に入れればある程度採用市場はあるように思います。
ところが、DXの向上にフォーカスを当てるとこれが極端に減ります。なぜか。DXの向上を目的にしているのだから開発経験がほぼ必須で要求されるのです。開発経験がなければ開発者の痒いところは想像するのが難しいですし、課題を解決する技術的な方法を提案するには、既存のサービスがどうやって作られているのか理解する必要があります。
開発能力がある上で、かつテストへの知識・理解をもち、エンジニアをサポートするエンジニア。
なかなかにニッチな職種であることは間違いありません。
私のチームでは今DXの向上にフォーカスを置いた職種を**SET(Software Engineer in Test)**というふうに呼んでいます。SETはSRE(Site Reliability Engineer)に近い職種だと思っています。ソフトウェアエンジニアでありテストのスペシャリスト。しかし、SETと聞いてあーあんな感じの仕事する人たちね、と思い浮かぶ方は残念ながらほとんどいないのが現状です。
冒頭でお話しした危機感というのはまさにこのことで、積極的な活動をして仲間を増やしていかないとこのままでは尻すぼみになっていくのは必然だ、という思いがあるのです。
キャリアパス的な話
そしてもう一つ大事なことに、会社にどう貢献するかというころがあります。
例えば、私は数年前から自動テストエンジニアの部下に、自動テストを書くだけの職種はすぐにでも無くなるということを散々言ってきました。10年近く前であれば自動テストに関わるほとんどのものを自前で用意する必要があったかもしれませんが、昨今ではWeb系に限ってもSeleniumだけでなく、CDP(Chrome Devtool Protocol)を利用したPuppeteerやCypress、またはPlaywrightのようなOSSやライブラリが広く使われていますし、有償の自動テストサービスも質・量ともにかなり充実してきています。つまり、昔より遥かに誰でも書けるのです。自動テストエンジニアのハードルは間違いなく年々上がっています。現状から目を背けてはいけません。
会社が、チームが、同僚がどういう仲間を求めているのか、そこを深堀りしていくことでもしかしたら答えは見つかるかもしれません。
それはもしかしたら新たなframeworkを作るような技術的なものかもしれませんし、
もしかしたらテストに関わる知識と自動テストの技術の組み合わせかもしれません。
価値がどこにあるのかを見極めることができれば、自ずと必要なことが見えてくる気がしています。
さいごに
私はSETや自動テストエンジニアを存続させるために認知を広げて仲間を増やしたいのではありません。価値が出せないのであれば存続させる意味はないですし、今の会社に合わないのであれば価値が出せるように形を変えるべきでしょう。
ではなぜ仲間を増やしたいのかと言うと、ひとえに会社の、またはプロダクトの利益になると思っているから、ということに他なりません。同じ理念を共有できる仲間を増やして、もっと楽しい仕事がしたいのです。
開発者を支える開発者としてのお仕事に興味ある方、ぜひカジュアルなお話しましょう！年明けにはてすらぼも活動しようと思っているのでそちらもぜひ！