はじめに
SET(Software Engineer in Test)でエンジニアをやっている@masudakと申します。メルカリのSETチームは2016年10月に設立されたのち、ローカル開発環境やQA環境の構築、UIテストの自動化、フロントエンドやマイクロサービスなど各領域内において「開発生産性とプロダクト品質の向上」による取り組み等、様々な業務を行ってきました。
しかしながら、まだSETは馴染みない職種であると思われるため、この記事ではSETの設立背景やその未来像を紹介しようと思います。
SETという職種ですが、いくつかの会社で設立されており、GoogleのSETチームでは、新機能やパフォーマンスを上げるための業務を行うよりも、コードの品質やテストのカバレッジに注目した職種であるとされており、加えて単体テストのフレームワークを作りテストの記述が用意になるような共通基盤の作成も担っていると述べられています。
We are champions for code health, testability, maintainability and best practices for development and testing.
と書いてあるとおり、開発やテストをスムーズにし、質を担保するチームであることがわかるかと思います。
詳しくは以下の記事が参考になります。
- How Google Tests Software – Part Two
- The SET Career Path
- Software Engineer, Tools and Infrastructure
また、SWETやSDETなど名称は違うものの職種としては同じように想定されるものもあります（実際の業務内容はある程度差があると思われます）し、各社様々な名称で定義されているようです。
メルカリにおけるSET
メルカリにおけるSETは2016年10月に設立されました。当時メルカリでは日本と米国向けにサービスを展開していたのですが、次の年の春に英国向けのサービスを展開するということで、その英国向けの環境の整備が急務となりました。
背景としてはいくつかあるのですが、
- 開発環境やQA環境に関して、今までエンジニアが業務の合間で構築していたため、オーナーが存在しなかった
- 開発環境やQA環境に関して、ある程度はコードで管理されているものの、秘伝のタレと化している部分もあり、英国向けの拡張が難しかった
- リグレッションテストがマニュアルで行われていたが、日本・米国向けでもすでにQAエンジニア2人でそれぞれ1日、計2日ほどかかっており、英国向けを考えるとスケールしないと判断した
といった要因があります。
設立時の「ミッション・役割」としては「QA の作業も実際にやりつつ、効率化・自動化できるところを見つけそれを実際に自動化していく」「開発環境の構築〜QAまでをシームレスにできるように環境を整えていく」ということが挙げられていました。また、その後のアプローチとして、「ユニットテストやファンクショナルテストのコーディング支援、プロダクトチームへの啓蒙」なども想定されていました。
設立当初はわたくしも含め3名のメンバーで始まり、英国向けのサービスのために開発環境、QA環境、UIテスト自動化をまず推進するところから始まりました。その後マイクロサービスやフロントエンド、バックエンドなどに特化したメンバーがそれぞれの領域で成果を出し、領域を広げていきました。たとえば、フロントエンドではQAの通ったwebpackやGulpでのビルド成果物を本番に利用する仕組みを導入したり、マイクロサービスではGKE上にある各サービスをPR単位でデプロイできる仕組みを導入するなど「開発生産性とプロダクト品質の向上」に関することは何でもやり、結果的に人数は倍になりました。
2018年4月からはUIテストの自動化に関しては、ソフトウェアエンジニア（Mobile Tesing, Automation)が担うことになり、SETは「共通基盤の構築やコード品質の向上」を役割を担い、チームが分かれました。
SETは「開発やテストをスムーズにし、質を担保する」という側面を非常に重要視し、エンジニアやデザイナーなどのステークホルダーが、いかに自分の環境やQA環境で迅速に開発できるか、CIなど開発フローをよりよくすることでいかに生産性や品質をあげられるかを大切にしており、これからもそこは変わることはないでしょう。
次世代のメルカリSETに向けて
前述したとおり、たしかにメルカリSETは開発やQAのための環境を構築し、自動化や効率化を進めるところから始まりました。その後、マイクロサービスやフロントエンドなどそれぞれの領域で品質を上げる取り組みを行い、徐々に影響範囲を増やしていきました。
しかしながら、それで実現できたことは一部でしかありません。
先日SET iOSという領域を作り、iOSエンジニアとしての経験を持ちながら「開発生産性とプロダクト品質の向上」を担える職種を新しく作りました。
その募集要項では、その役割として以下のような言及をしました。
Yak Shavingという言葉に代表されるようにソフトウェア開発においては、一つのことを行うためにも、その推進のために別の多くの問題が隠れて付随しています。リリース当初はそこまで問題にならなかった問題も、時間が経つにつれ大きな問題として顕在化し、開発のアジリティに悪影響を与えていきます。
SET iOSではそのような問題に目をつぶらず、いかに事前にそういったことに手をうち、また問題が見えてきたらいかにそれを拡大せず防ぐのか、そこに注目し、成果を出して頂く職種となります。iOSチームのEngineering Managerやメンバーと密にコミュニケーションし、成果を出していただく職種となります。
「開発生産性とプロダクト品質の向上」と冒頭で書きましたが、その結果として目指しているのはここで書いたような中長期的な世界です。ここではSET iOSの領域として述べていますが、あらゆる領域で求められる世界観です。
どれほど綺麗にコードを書いても、どれほど丁寧にレビューを行っても、サービスが成長し、依存するサービスが増えていくと、コードの複雑さは増していきます。もちろん、その対策の一つがマイクロサービスではあり、社内ではその流れを押し進めてはいますが、チームごとに品質がバラバラでは意味がなく、それらを横断して「開発生産性と品質の向上」にオーナーシップを持てるチームが求められます。
たとえば、コードの複雑度を視覚化し、現状のコードの健康状態を図ったり、マイクロサービス環境下でどのように結合時のクオリティを保つのかといった業務は今後より重要視され、ないがしろにすることはできません。また、マイクロサービスが推進されたときに、いかにしてローカルの開発を行っていくのか、自動的にデプロイされるようにQA環境を作るのか、またカオスエンジニアリング導入により、本番環境でいかに質の担保するかという役割も果たしていく必要があります。
そしてそういった取り組みの結果、会社全体として「開発生産性と品質の向上」の意識がさらに高まり、結果的にお客様に安定したクオリティのサービスを届けることができる。そういうことを実現できる組織であると考えています。
そのためにも取り組むべき課題は多くまた大きく、やることは尽きません。まだまだ馴染みのない職種ではありますが、この記事をきっかけに認知され、広めることができれば幸いです。
カジュアルに話を聞いてみたいという方もいましたら、是非色々お話しましょう！以下のようなことに興味ある方是非よろしくおねがいします！
- 開発生産性やプロダクト品質の向上が好きな方
- CIに色々なツールを組み込むのが好きな方
- 古く使われていないコードがあったら、消したい方
- TODOまたはFIXMEと書かれているコードを見ると、ムズムズしだす方
- ソースコードのメトリクス化と分析、そしてその改善をしたい方
- 短期的な機能開発ではなく、中長期を目指した実装を推進したい方
- 外から依頼して改善してもらうのではなく、自分で積極的に提案して改善していきたい方
募集要項はこちらになります、よろしくおねがいします！
（今後異なった領域でも特化型の職種を設定していく可能性はありますので、AndroidやBackend, Infrastructureの領域を募集してないわけではありません。現時点ではiOS以外の領域特化型の応募に関しては、通常のSETのほうに応募下さるようご了承いただければと思います）
