2021年12月、メルカリが新サービス『メルワーク』の試験提供を開始した。

このプロダクトは、ユーザーが『メルカリ』内で「ワーク」と呼ばれるタスクを行うことで『メルカリ』のポイントが得られ、そのデータはメルカリ各サービスのサービス品質の向上に寄与されるというもの。

開発チームを立ち上げたのは、これまでメルカリ新規事業チームで活躍してきたEngineering Manager（以下、EM）のAymanさんだ。

Aymanさん曰く、新プロダクトの立ち上げはまさに“カオス”。「社内外から集まった新しいメンバーと、正解のない難解な問いを数々乗り越えていかなければならなかった」と振り返る。

『メルカリ』を軸に、これまでにも数々の新サービスを立ち上げ、リリースしてきたメルカリでは、そのようなカオスをどのようなチームビルディングによって乗り越えてきたのだろうか。

今回の『メルワーク』リリースでAymanさんが工夫したことや、メルカリに蓄積されてきたサービス立ち上げおよびチームビルディングのノウハウを紹介してもらった。

ユーザーの隙間時間を価値に変える新サービス『メルワーク』

『メルワーク』は、これまでメルカリが培ってきたCtoCのマーケットプレイスを活用し、お客さまの隙間時間を有効活用してもらおうと開発したサービスです。

好きな時間に、好きなサービスの改善に自分が寄与できる、そんな新たな仕組みをつくれたらと考えてスタートしました。

具体的には、お客さまがメルカリのマイページから「ワーク」を選択して、表示される質問に「○」か「×」で答えていきます。すべての質問に答え終わるとワーク完了。お客さまは報酬としてメルカリで使えるポイントがもらえる仕組みです。

ワークで答えた内容は、メルカリのサービス品質・機能向上のために使われるデータとなり社内の開発チームにフィードバックされます。

今リリースしているワークは「類義語チェック」というタスクで、ある言葉のペアを見て「類義語かどうか」を答えていくもの。

例えば「かばん」と「カバン」が類義語であるかどうかを〇×で答えていきます。そのデータを開発チームにフィードバックすることで、メルカリの検索機能向上に活かせるのです。

つまりお客さまはポイントを得られるだけではなく、『メルカリ』のサービス改善に寄与することができる。単なる作業ではなく、お客さまの時間や「メルカリをもっと使いやすいアプリにしたい」という気持ちを価値に変えられるのです。

今はお客さまにとって分かりやすいワーク「類義語チェック」のみを実装していますが、今後はこうしたマイクロタスクを次々とリリースしていく予定です。

私はEMとして採用、チームビルディング、開発手法やリリースプロセスの構築を行うなど、開発チームが個々人のバックグラウンドや専門性を発揮しながらプロダクト開発ができる仕組みを整備しています。

もともとは2年前まで新規事業チームでEMを務めていたのですが、担当していたプロジェクトの立ち上げフェーズが終わり、その組織はかなり安定していたんです。

そこでもっとチャレンジングなプロジェクトに携わって、コンフォートゾーンから抜け出したいと考えていた時に、『メルワーク』の話が耳に入って。ぜひ挑戦してみたいと、自ら手を挙げました。

当時は『メルワーク』の仕様もメンバーも何も決まっていない状態だったので、解きがいのある難しい課題がたくさん転がっていましたね。

開発にあたってこだわったことは大きく三つあります。

一つ目は、「開発は小さい単位で始めるものの、発想は大きくいこう」ということ。国内外のメルカリのお客さまにとってメリットのあるサービスにするべく、プロダクトがスケールできる設計にしなければならないと考えました。

もう一つは、「モジュラリティー」です。開発当初から開発コストを抑えるため、再利用できるシステムにすることを意識しました。

例えばお客さまに実施してもらうマイクロタスクの質問表や、お客さまがタスクを行った際の報酬制度などは、他のサービスにも横展開できる、再現性のある仕組みを整えていったんです。

三つ目は、アジャイルに開発できるように「1週間単位で大きなスプリントを置いていた」ことです。特に最初のバージョンのリリースまでは、こまめにスプリントを行うようにして、大きな変更にもすぐ対応できるよう、柔軟な開発手法を取るよう心掛けました。

チーム立ち上げ時から守り続ける、メルワーク独自の「三つのバリュー」

プロジェクトの立ち上げで社内外から集めたメンバーは、とてもダイバーシティに富んでいました。それ自体は素晴らしいことなのですが、それぞれの異なるバックグラウンドや意見を、どう統合していくかは非常に難しかったですね。

チームビルディングのプロセスとして、Form（組成）、Storm（カオス状態）、Norm（体制の整備）、Perform（スペシャリティーの発揮）という段階があると思いますが、このプロセスをできるだけ早く進めるよう工夫していきました。

まず、チームの立ち上げ初期から三つのバリューを定めました。メルカリは全社的に、バリューを重要視するカルチャーがありますから、その素地を生かすことができたんです。

『メルワーク』チームバリューの一つ目は「Trust」です。お互いをちゃんと信頼し合いましょう、ということですね。「互いの仕事や意思決定は、その人が責任を持ってしたことだから大丈夫」と信じきること。そして、メンバーの行動を疑わないことをチームとして大切にする、と決めました。

二つ目は、「Blameless」なカルチャーをつくること。つまりお互いを責めないということです。たとえ誰かが間違ったことをした時でも、責めるのではなく問題を解消して失敗から学んでいくことを大切にしています。

それから三つ目が、メンバーが「Open」に発言できる場をなるべく多く設けること。そのために、独自のディスカッション方法をいくつか設けました。

例えばモノレポ（単一のレポジトリで特定のプロジェクトのコードをすべて含めるアーキテクチャパターン）を用いて、新しい提案や意見があればモノレポにドラフト（草案）として書いてもらいます。もちろん、そこにはプロコン（メリット・デメリット）も記載します。

それに対してまずはチーム内で意見を交わし、次に他のマイクロサービスやアーキテクチャ、セキュリティーなどのチームからも意見を聞き、レビューしてもらうといった流れです。

またこうした取り組みに加えて、週次で特にテーマを設けないミーティングを開催することにしています。

これはメルカリでよく行っているチームビルディングの方法で、ミーティングで話す内容に制限なく、誰でもオープンに発言できる心理的安全性の高い場にすることを心掛けています。

こうしたバリューやカルチャー、仕組みによって、いろいろな問題を解消できているのではないかと思いますね。

まさに、モノレポの管理はすごく難しく、初期は大きな課題の一つでした。

モノレポの中にはいくつかのアプリやサービスがあって、それぞれのサービスはプログラム言語が違います。Go言語で書かれたのものもあれば、ReactやNode.jsのものもある。各言語にはそれぞれパイプラインがあるので、デプロイもテストの仕方も、レンダリングの仕方も異なります。

その時は、このモノレポを管理するためにGoogleの『Bazel』というビルドツールを導入してはどうかと一人のエンジニアがドラフトに書いてくれて。その後、メリット・デメリットを洗い出した上で、みんなでディスカッションして導入を決めました。

しかし実際使ってみると今度は「使いづらいから他のツールに変えたい」という意見が出てきたんです。Bazelを使い続けるか、他のツールにするのか意見が分かれました。

そこで改めてモノレポのドラフトに意見を書き込んでもらい、メリット・デメリットを整理して。みんなが納得するまでディスカッションしたんです。

こういう議論をするときに大事にしているのは、常にメリット、デメリットを明確にすること。Bazelを使い続けるメリットと、使い続けた時に直面する問題、その両方をオープンに議論し、他のツールに変えたときに出てくる問題についても率直に議論していきました。

「納得感」を持って価値を出せるカルチャーを維持したい

チームのみんなにとって、常に納得度の高い技術選択ができることで、モチベーション高くより良いパフォーマンスを発揮できるようになりました。

私はリーダーの役割として最も大切なのは、チームメンバーをちゃんとエンパワーすることだと思っています。これは以前EMを務めていた新規事業チームでも心掛けていたことです。

もちろん、立ち上げ期においては一つ一つみんなで議論するより、トップダウンで意思決定した方がスピーディーだと思う人もいるかもしれません。

しかし特に技術面においては、トップダウンで意思決定してしまうと、メンバーの不満につながることが多い。過去にもトップダウン型で意思決定し、メンバーが離脱してしまうチームを何度か見たことがありますから。

時にはクイックに決断しなければならない局面もありますが、そうだとしても必ず後でチームで振り返って、なぜそういう状況になったのか、なぜその意思決定をしたのかについてディスカッションするようにしています。

当初私を含めて3人だったチームも、今ではエンジニア、PM、アナリスト、そしてプロダクトオーナー、機械学習エンジニア、カスタマーサービス、デザイナー、などで構成される大きなチームになってきました。

しかしこれからも、今あるカルチャーを保ち続けるチームでありたいと強く思っています。一人一人がちゃんとエンパワーされ、相互にサポートし、その中で自由に仕事をしたり学んだりできる。そんなカルチャーを大切にしたいですね。

一人一人のエンジニアが、自分の仕事に価値があると思えるように、オープンにディスカッションできるチームでありたいですし、このカルチャーをメルワークのユニークネスとして全員で育んでいきたいと考えています。

取材・文／石川香苗子　撮影／赤松洋太