Mercari Engineering Blog

We're the software engineers behind Mercari. Check out our blog to see the tech that powers our marketplace.

SETチームの設立背景と次世代のSETに向けて

はじめに

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.

書いてあるとおり、開発やテストをスムーズにし、質を担保するチームであることがわかるかと思います。

詳しくは以下の記事が参考になります。

また、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のほうに応募下さるようご了承いただければと思います)

社内の面倒な手作業はZapierにやらせよう #2 〜Webhookを使って、自動化の幅を広げる〜

f:id:tadashi-nemoto0713:20180218185222p:plain


こんにちは、メルカリの自動化&品質保証グループ(Automation & QA Group:通称AQA)で、自動化をぶりぶりしている tadashi0713 です。

私は普段、テスト自動化・CI / CD改善・その他社内の生産性を上げるための自動化・ツール作成を行っています。

以前はQA-SETでしたが、AQAになったことにより、よりチーム全体での自動化を推進していきます。


メルカリでは、去年からZapierという自動化ツールを導入し、社員がより簡単に業務自動化に取り組めるようにしています。

導入した背景や、簡単なワークフローの作り方、実際に社内でどう使われているか、などについては下記の記事をご覧ください。

tech.mercari.com


現在では、 ノンプログラマー含め250名以上のメンバーが、400以上のワークフローを作成 し、日々の作業を自動化しています。

また社内のエンジニアも、Zapierを使った自動化について、いくつか書いてもらっています。

masartz.hatenablog.jp

dev.to

2つ目の記事では、Slackのメッセージについたリアクションをトリガーに、自動翻訳するBotについて紹介されています。

グローバルメンバーと、複数言語でのSlackコミュニケーションが増えているということもあり、現在社内で一番使われています。


この約半年間、Zapierを運用する中で様々なTipsが出てきたので、定期的にこのブログでご紹介していきたいと思います。

今回は 「Webhookを使ったワークフロー作成」 についてご紹介します。

続きを読む

Meetup for Corporate Engineering Team 記念すべき第一回を開催しました!

こんにちは!Corporate Engineering Team でソフトウェアエンジニアとして働いている@alc6895です。

6月7日にメルカリオフィスでMercari meetup for Corporate Engineering Team #1を開催しました。 Corporate Engineering Teamを立ち上げた@sotarokを始め、経験豊富なエンジニアの@fivestr@rskyの2人を合わせた計3人が登壇しました。豪華ですね!
本記事ではその様子をお届けしたいと思います。

続きを読む

Mercari x Merpay Frontend Meetup で話したこと

@1000ch (id:hc0001) です。6 月 4 日にメルカリオフィスで Mercari x Merpay Frontend Meetup を開催しました。今回の Frontend Meetup では @_hitima と @1000ch が登壇し、メルカリとメルペイの Web Frontend 事情についてお話しました。本記事ではその様子を抜粋してお届けします。

メルカリとメルペイ、それぞれにおける Web

メルカリはスマートフォン向けのフリマアプリとしてご存知の方も多いと思いますが、Web 版も存在します。メルカリの Frontend チームでは、この Web 版のメルカリの他に、CS チームのオペレーションに必要な管理画面であったり、アプリ版メルカリから参照する取引画面などを開発しています。CS チームの管理画面については、4 月 25 日に行われた管理画面チラ見せ♡ナイト #6@bravewood からチラ見せがあったので、ご存知の方もいるかと思います。

メルカリの取引画面の歴史はリリース当初である 2013 年 10 月に遡ります。メルカリを支える取引機能を Web で担ってきたわけですが、らくらくメルカリ便ゆうゆうメルカリ便といった数々の機能追加をスピード優先で進めてきたこともあり、追加開発の余裕が無い段階まで来ています。

続きを読む

自動E2Eテスト結果をビューティフルなレポートにまとめてTestRail連携してみた

f:id:daipresents2:20180605153525j:plain


こんにちは。メルカリで自動化&品質保証グループ(Automation & QA Group:通称AQA)のエンジニアリングマネージャをぶりぶりしている@daipresentsです。

AQAは、従来のQAではなく、自動化を駆使した「完全自動化時代のQA」を目指すグループとして活動しています。その道のりはなかなか険しいのですが、じわりじわりとメンバーも増え、社内でも「自動化」というキーワードが広がってきました。

この記事では、テスト自動化でとても大切なポイントとなる、テスト結果をまとめたビューティフルなレポートのノウハウを共有させていただこうと思います。

続きを読む