メルカリのCTOをやっている @snamura です。 Mercari Advent Calendar の最後を締めくくってほしいということで、ブログを書くのが物凄く苦手なんですが無理をして書いています。技術に沿った話で締めくくりたいところですが、ここ1年はずっとエンジニア組織のことに取り組んできたので、ここでは組織の話をちょっとしようと思います。
最近メルカリの Go Bold Challenge というカンファレンスで話したのですが、メルカリのエンジニア組織は、こちらの記事で詳しく語っています。
2019年4月から本格的にCTOとして日本のメルカリのエンジニア組織を見ていくことになったのですが、課題山積みということで、次から次にやるべきことが出てくる1年でした。メルカリというサービスに対して、どういったエンジニアリングのアプローチを取っていくのか。まだ道半ばではありますが、これまでやってきたこと、来年やることを簡単にまとめて、 Advent Calendar の締めくくりにしようと思います。
目指しているエンジニアリングの姿
CTOとして考えている目下のゴールは、「エンジニアが自ら考え、決断ができる」状態です。言葉にするのは簡単ですが、実際数百人規模の組織、かつ事業の成長を大きく期待される状況においては、非常に難しいということを実感した1年でした。ここから紹介するのは、そのゴールに向かうために今年1年行った様々な意思決定になります。
Engineering Principles
id:tuttiq が既に書いてくれていますが、今までエンジニアのカルチャーというものが明文化されていなかったため、エンジニアにとっての判断基準や評価基準がずっと曖昧なままでした。そこで、エンジニアを議論に巻き込んでエンジニアとしての Principles 、行動規範のようなものを作りました。
エンジニアの数は2年で3倍近くになり、メルカリが少数精鋭だった時代のカルチャーはかなり薄まっていました。少数だからこそ成り立つようなものは、規模化に伴ってやり方を変えていかなければなりません。メルカリがエンジニアにどういった期待をしているのかを明文化することは、皆がカルチャーを認識するための第一歩でもあります。
エンジニアの多国籍化が進み、英語が重要になってくる中で、この Engineering Principles は「英語で作って日本語訳をする」というアプローチを取りました。こういったハイコンテキストな文書は実は日本語を英語にするのは非常に困難です。その逆も然りなのですが、言語の特性なのか英語の方がよりストレートな表現になっていることもあり、英語を主体に進めて日本語訳を作る、というアプローチを取りました。
Engineering Ladder
より納得度のある評価や期待値設定のために、ラダー制度を策定しています。メルカリでは等級（グレード）の概念があり、等級ごとに期待される行動についての定義があります。
Engineering Ladder は、その期待される行動についてエンジニアに特化した内容になっています。 Engineering Principles に基づき、各等級に求められる期待される行動を具体的に書いています。ここでいう期待される行動は、結果として生み出した事業成果に対する評価ではなく、起こした行動そのものに対する評価になるように設計しています。
メルカリが目指すエンジニアリングを体現するようなエンジニアを正しく評価することで、カルチャーの浸透を促していく狙いもあります。
Data-Driven Decisions
メルカリのエンジニア組織の目的は最高の体験をお客さまに届けることですが、最高の体験の解釈は人によって違いがあります。会社としてお客さまにとっての最高の体験とは何かを数値化し、作る機能の評価を行っています。多くの意思決定がなされる状況において、正しい方向の意思決定を一貫した判断をする必要があるためです。
Feature Flags (各機能の有効・無効をコントロールし、機能ごとの効果を計測できるもの）や Data Platform を推進することで、あらゆる場所で Data Driven な意思決定ができるように整理をしています。まだ完全にそういった状態にはなっていませんが、来年からは全ての機能を Feature Flags を起点として出していく方向で考えています。
エンジニアのクリエイティビティとイノベーション
日々事業成果に追われ、高い事業目標を掲げていると、自然と優先順位が決まってきます。常に事業としての優先度の高いことしかできないと、エンジニアが自ら考えて作るという力が衰えてしまう恐れがあります。イノベーションを促進するには、普段からエンジニアが持っている素晴らしいアイデアを実験したり、お披露目する場所があるべきです。
メルカリでは、エンジニアの創造力を育て、イノベーションを生み出せる源泉とすることが、エンジニアの育成だと考えています。今年はエンジニアにもの作りの原点に立ち返ってもらうために、エンジニアが事業目標を忘れて、好きなことに時間を使える Hack Week を開催しました。結果は下記の記事を参考にしてください。次回も3月末に開催することが確定し、メルカリの社内イベントとして半年に1回実施することになりそうです。
メルカリ全エンジニアが参加した1週間の「Mercari Hack Week」結果発表！受賞したのは？ #メルカリな日々 | mercan (メルカン)
意思決定を促進する開発体制へ
id:stanaka が書いているように、意思決定がより小さな単位で実行できるよう開発体制を前進してきました。Microservices は技術的なアプローチだけではなく、組織的なアプローチも含めて考える必要があります。 Backend チームは、ドメインチーム体制を経て、来年からクロスファンクショナルなチーム体制へと変遷し、 Microservices の目指す意思決定のチームへの移譲に向かっていきます。
また、プロダクト開発が事業数値の目標に偏ってしまい、存在意義が薄れたり、チームの士気が下がるようなことにならないように、各チームで何故今ここに集中するのか、メルカリは今何を解決したいのか、を言語化するような動きも始めています。
報酬確定プロセスの見直し
給与の確定は、マネージャにとって非常にコストのかかるものですし、メンバーにとっても非常に重要なことです。そのため、マネージャが結果をフィードバックするものまた一苦労です。そこで、報酬確定のプロセスを改変し、公平でかつ納得感の醸成が容易な方法をスタートします。
運用がうまくいったタイミングで、このプロセスや方法論も社外にオープンにしていこうと思います。
技術負債へのアプローチ
Microservices への移管を推進することで、技術的な負債を少しずつ解消するとともに、モダンな技術スタックへの転身を目指しています。
上記で解説した Hack Week とは別に、2週間単位で進行するスクラムのスプリントを、半年に1回、技術的な課題のみにアプローチする2週間を確保することにしました。この2週間の間は、事業的な開発を全てストップして、技術的な課題解決や負債の解消、プロダクトのコードに対して普段できないことへのチャレンジに時間を費やすことを優先します。この2週間を、Sprint buffer と定義しています。
イノベーティブなことは Hack Week で実現し、プロダクトに対するクリエイティブなことは Sprint buffer で行う。そういった区分けで事業成長と個人の成長を後押ししていきたいと考えています。
コードの書き換え指針
メルカリはサービス開始当初からずっと同じコードベースに加筆修正をしてきました。バックエンドは Microservices 化に伴い、その解消を狙っています。一方クライアント側については、アーキテクチャの改変などを伴ってその解消を目指しています。
ここまでの経験でわかったことは、既存コードを維持したまま少しずつ置き換えるということが、ゼロから作るよりもずっとコストが高いということです。この経験を元に、定期的なコードの再構築は、長くプロダクトを運営し、進化を続けるためには避けて通れないと考えるようになりました。また、コードの再構築は、技術の属人化や複雑化を解消し、モダン化を促進します。エンジニアリソースを投入して定期的なコードの書き換えを実行する指針を作成中です。
リズムのある開発スケジュール
現在、年間通して経営の意思決定や、開発の意思決定など、さまざまな意思決定を可視化、スケジュールとして明示することで、リズムのある開発を目指しています。ずっと緊張感のある状態では力が十分に発揮できません。「この時期にこういったことがある」ということをみんなが理解することで、仕事に強弱をつけたりできるようになります。
例えば、スプリント計画で言うと スプリントを4回 -> Hack Week -> スプリントを5回 -> Sprint buffer が半年で一巡するように、プロダクト開発とエンジニアリングに集中する期間をあらかじめ定義します。また、経営会議や全体共有(all-hands)の時期を明確にすることで、情報の流れや全体のスケジュールにメリハリをつけていこうとしています。
来年の抱負
今年は何もなかった大地を地ならしをするような、そんな1年でした。来年は上記にあるような、いろいろなアプローチに対する結果も見えてくると思いますので、またどこかでその結果を公開していければと思います。それでは皆さま、よいお年を。
