CI/CD(継続的インテグレーション/継続的デリバリー)は、ソフトウェアを素早く開発し、お客さまに素早く価値を届けるために必要不可欠です。バックエンドやフロントエンド、それぞれの技術レイヤーにおいてCI/CDが必要ですが、この記事はモバイルアプリやWebにおけるCI/CDを提供するクライアントCI/CDチームにスポットを当てます。

今回はクライアントCI/CDチームの@y-kazamaと@kaito、@thiそして@aha-oretamaにインタビューを行いました。現在の業務とこれからの取り組み、そしてチームが実施してきたユニークな取り組みについて話を聞いています。組織が大きくなる中でもエンジニアの生産性を低下させないように取り組む、彼らの思いをご覧ください。

聞き手はEngineering Officeの@afroscriptです。

クライアントCI/CDチームのメンバーについて

— まずは自己紹介をお願いします。

@y-kazama: 私は2019年7月にメルカリに入社しました。前職はメーカーにて海外の企業と共同で、エンタープライズ向けのドキュメント管理ソフトウェアを開発していました。メルカリに入社してからはエンジニアリング・マネージャー（以下EM）として複数チームのマネジメントをしています。現在はチームメンバーの成果を高められるように、チームマネジメントを担っています。

@kaito: 私は2018年10月に入社しました。タイミング的に海外から多くの新卒メンバーが入社した時で、中途入社ながら入社式に参加したのを覚えています。前職はレシピ動画アプリのiOSエンジニアで、そのときに現職と同じようにiOSアプリのCI/CDの改善も行っています。その前は学生時に立ち上げたスタートアップで、CTOという名の開発全般何でも屋をしていました。

メルカリではiOSアプリにおけるCI/CDの改善や自動化、開発メトリクスの収集、および見える化を行っています。チームの移動はありましたが、一貫して同じ領域を担当しています。

@thi: 私は2021年5月に入社しました。前職ではiOSエンジニアや、iOSアプリのビルドインフラを担当していました。ユーザ向けだけでなく、SDK開発にも関わっています。

メルカリでは、主にiOSアプリのビルドインフラの改善を行っています。基礎となるビルドシステムの維持、改善を担当しています。

@aha-oretama: 私の入社は2018年8月です。それまではバックエンドやフロントエンドの大規模開発をしていました。そのあと、SET（Software Engineer in Test）活動を自分ではじめて、しばらくしてからCI/CDチームのあるメルカリに入社しました。

メルカリではQA Automationチームや現在のチームにて、WebのCI/CDやテスト自動化を担当しています。品質、生産性向上につながることなら何でも行っています。

CI/CDの生産性を測るメトリクス

— クライアントCI/CDチームの業務内容について教えてください

@y-kazama: メルカリのエンジニアリング組織は、プロダクト・エンジニアリングとプラットフォーム・エンジニアリングに分かれています。プロダクト・エンジニアリングはメルカリアプリの新機能開発を行っており、プラットフォーム・エンジニアリングは開発生産性やシステムの信頼性を高めるプラットフォームの開発を担っています。私たちのチームはプラットフォーム・エンジニアリングに属しており、モバイルやWebアプリケーションといった、クライアントサイドの開発で必要になるCI/CD環境を支えるツールやインフラ開発を行っています。

各メンバーの役割としては、@kaito と @thi がモバイルの、 @aha-oretama がWebのCI/CDをそれぞれ担当していて、@y-kazama がEMとしてチームをみています。

— チームができる前は、どのようにCI/CD環境を提供していたのでしょうか？

@y-kazama: 元々は、プロダクト開発のエンジニアがCI/CD環境の提供を担当していました。しかし開発が忙しくなると、CI/CDのメンテナンスが後回しになってしまいます。そうすると日々の改善で手一杯になってしまい、中長期的な視点でのCI/CDに対する取り組みが難しくなっていました。

バックエンドについてはマイクロサービス・プラットフォームチームがありましたが、モバイルやWebを支えるチームは存在しませんでした。そこで2020年半ばに作られたのが現在のクライアントCI/CDチームになります。生産性の高いCI/CD環境を実現することで、プロダクトエンジニアが新機能開発に集中できるようになります。その結果として、メルカリアプリをより安定的に、かつ速くお客さまに届けられるようになります。

— チームの運用上、工夫されていることはありますか？

@kaito: 専任のチームになることで、プロダクト開発におけるボトルネックに気付きづらくなるのを懸念しています。そのためビルドタイムなどのデータを検知する環境を作っています。

@aha-oretama: プロダクト開発のプロジェクトにジョインしたり、定例に参加しています。それによって何を開発しているのかを把握したり、CI/CDとしてできることについてフィードバックを得ています。

あとはプロダクト開発のエンジニアとモブプログラミングを行ってコミュニケーションを取ることもしています。

— プロダクトエンジニア側からの機能要望とチームのやりたいことの優先順位はどのように調整していますか？

@kaito: そうした要望は、より効果が大きいものや開発体験にどれくらい効果があるのかによって、優先順位を付けて対応しています。

@y-kazama: 目の前の改善を行いつつ、中長期的にチームとして実施したいこともあるので、両者のバランスを取りつつ取り組んでいます。

— CI/CDを運用する上で気をつけていることはありますか？

@y-kazama: メルカリでは、日々収集されたデータを基に、日々の活動を改善していくデータ・ドリブンに意思決定を行う文化があります。このチームでも同様に、CI/CDの生産性を阻害する要因を見つけ、それを改善するためには何が必要かを常に考えています。例えば、モバイルアプリのビルドが遅ければ、ビルド速度を改善する仕組みを導入したり、インテグレーションテストの安定性が悪い時は、テストを安定させる仕組みを提供するといった具合です。

— CI/CDの生産性はどのように把握しているのですか？

@y-kazama: まず生産性を把握するためのメトリクスを定義します。次に、そのメトリクスをダッシュボードで可視化します。特に重視してるのがビルドスピードと安定性、開発者体験、そしてコストです。これらの数値が目標値を下回った場合、ログなどから原因を調べます。その上で改善施策を実行し、メトリクスが改善するかモニタリングしています。

開発者体験はプロダクトエンジニアへのアンケートという形で、定性的データを収集しています。

— これまでに苦労したストーリーがあれば教えてください

@kaito: フロントエンドを刷新するプロジェクトが大変でした。そこでBazelというビルドツールを導入決定し、CI/CD環境を作っていったのですが、導入事例が少なくて大変でした。

Bazelは通常のiOS開発とビルドの方法や利用するツールが異なります。そのため依存関係の解決や、iOSのエコシステムで用意されているものが利用できず、インテグレーションさせていくのが難しかったです。

@thi: Bazelは導入事例が少なくて、一般的なiOSプロジェクトでは使われていないため、iOSエンジニアの中でも慣れている人は多くありません。しかし、Bazelを使ったことがない人でも、依存ライブラリの追加作業を容易に行えて開発をはじめられるようにするなど、導入に際してバランスを取るのが難しかったです。

@aha-oretama: Webについては、フロントエンドを刷新する際にWeb Componentsを採用しました。Web Componentsは最新の技術でライブラリが未サポートだったり、知見があまりなかったため、開発はもちろん、テストもその難易度が上がりました。Web Componentsは既存のテスティング・ライブラリとの相性が良くなくて、開発者がどう楽にテストを書けるようにできるか悩みました。結果的に、プロジェクト開始時からサポートしたことにより、テストが書きやすい環境を作ることができました。

— CI/CDの改善において何が最も重要でしょうか？

@y-kazama: プロダクトエンジニアが、プロダクトの開発に専念できる状態にしなければなりません。水道やガスのように、いつでも当たり前のように使える環境を提供するのが大事です。

@thi: デベロッパーメトリクスは4つ（ビルドスピード/安定性/開発者体験/コスト）ありますが、主に私が取り組んでいるのはビルドスピードになります。今後、開発者が増えて規模が大きくなると、ビルドスピードは低下して生産性の低下につながってしまいます。そうならないようモニタリングして、改善していく予定です。

@kaito: 継続的に回していくものなので、高い信頼性が大事です。小さいチームだとよくあるのですが、CI/CDを導入したもののテストに失敗することが多くなり、CI/CD自体の信頼性がなくなることがあります。CI/CDが成功し、常に稼働し続けている状態を維持するのが重要だと思います。

@aha-oretama: CI/CDは導入して終わりではなく、運用し続けていくことで価値が生まれます。特にテストが失敗し続けると、形骸化することが多いです。信頼できるテストを提供し続けることが大事です。

メルカリのクライアント CI/CDを支える技術

— チーム内でよく使っている技術、ツールについて教えてください

@aha-oretama: Webについてはプロダクト要件に合わせて、最適な技術やツールを選定しています。もっと人が増えて複数プロジェクトに関われるようになり、ツールの共通化ができる良いですね。

@kaito: モバイル向けとしてはBazelやRBE (Remote Build Execution）はあまり事例がなくて、特徴的なツールになるかと思います。iOS開発ではビルドタイムがボトルネックになりがちですが、それを解決できるツールとして面白いです。

@thi: Bazelは元々大規模、モノレポ向けのビルドシステムになります。そのため、規模が大きくなっても生産性に影響しないように、スケーラブルなツールとしてデザインされています。

— 実際Bazelの効果はどれくらいありましたか？

@thi: たとえば新しく入ったエンジニアの方が最新のソースコードを取得して、開発を開始するためにビルドを行います。これが平均30秒くらいです。Bazelを使わなかった場合、200〜300秒くらいはかかるはずです。そのため、7〜10倍くらい高速になっています。

@y-kazama: メルカリくらいの規模のアプリになると、ソースコードの規模が大きくなる中でビルドスピードを維持するのも大変です。それがさらに改善にまでつながっているという意味で、Bazelの導入効果は大きいです。

もっとエンジニアに使われるプラットフォームを作りたい

— 今後を見据えて技術的に楽しみなことを教えてください

@y-kazama: エンジニアに喜ばれる、必要不可欠なインフラを提供していきたいです。現在はサードパーティやOSSを利用したツールの開発と運用が多いですが、将来的には社外でも活用してもらえるツールを開発できる組織にしたいです。そのためにも、より多くの仲間が必要になるので、採用活動に力を入れています。

@kaito: モバイル、Webのフロントエンドの刷新を進めていますが、各プラットフォームにおいて技術的チャレンジをしているので、開発体験がどう良くなるのかが楽しみです。開発インフラの改善に関して、データ収集から問題発見、解決策の検討、そして実装まで一貫して行えるのがこのチームの面白さだと思います。

あとはBazelのさらなる改善ですね。導入自体が技術的なチャレンジでしたが、 @thi がジョインしてくれたことで大きく改善されました。これからエンジニアが増えて、コード量も増加していきます。その中で、どのようなボトルネックが発生し、どう改善していくかが楽しみです。

@thi: 社内のエンジニア誰でも使えるビルド基盤を提供することです。ビルドのインフラは、ソフトウェアエンジニアリングプロセスの基礎になります。大規模プロジェクトであっても、エンジニアの生産性を低下させることなく、かつどこでも作業できるなど、様々な可能性を秘めています。これからも楽しみです。

@aha-oretama: もっとエンジニアに使われるプラットフォームを作っていきたいです。いまは人数が少なく、少数のプロジェクトしかサポートできていません。エンジニアが必要とするプラットフォームを作ることで、チームが活躍できる幅が広がると信じています。

— 人数が少ないとのことですが、着手できていないプロジェクトや課題の中で、特にやりたいものはありますか？

@y-kazama: 直近ではAndroidエンジニアが不足しているため、Androidプロジェクトが後手後手になってしまっています。AndroidエンジニアでCI/CDに興味がある方がいれば、ぜひ来て欲しいです。

@aha-oretama: メルカリのWeb全体で使われるような機能を開発したいです。例えばビルドやテストについて、プロジェクトを横断して可視化するなど。それによって、私たちのチームが活躍できる幅が広げられるはずです。

@thi: 今、チームで取り組んでいるのはクライアントアプリだけなのですが、将来的にこの仕組みをバックエンドにもフィードバックしたいですね。

— メルカリに興味がある方向けに、メルカリやクライアントCI/CDチームのおすすめポイントを教えてください

@y-kazama: 自分がやりたいと思ったことに対して、制約なくチャレンジできる点です。例えば @thi がRBE (Remote Build Execution） を導入したいと提案し、それを進めています。また、プロダクト開発の片手間ではなく、100%専任でインフラに取り組める点もお勧めです。

@kaito: 問題の発見から解決策の検討、実装までを一貫して行える点です。クライアントサイドにおいて、プラットフォームの改善をメインで行うチームはあまり多くないでしょう。エンジニアが増えていますので、プラットフォーム改善のインパクトはより大きくなっています。

メルカリ全体に関しては、サービス規模が大きくなりつつも、技術的チャレンジや改善がしやすい環境だと思います。また、よりパフォーマンスを出すために、働きやすい仕組みを定期的にアップデートしている点もお勧めです。

@thi: ビルドシステムやツールチェーン、ビルドパフォーマンスなどについて、解決すべき興味深い問題がたくさんある点です。ビルド関連が好きな方には楽しめるチームだと思います。

@aha-oretama: 自分でデータを集めて、自分で課題を考えて、それを解決していく面白さがありますね。開発生産性を向上させるために自立して課題設定から解決まで一貫して動いていきたいという方にはぜひオススメしたいです。

採用情報

クライアントCI/CDチームではメンバーを募集中です。 少しでも興味を持っていただいた方は、ぜひともMercari Careersの募集要項をご覧ください。

• Mercari Careers for Engineering