最後を締めくくってほしいということで、ブログを書くのが物凄く苦手なんですが無理をして書いています。技術に沿った話で締めくくりたいところですが、ここ1年はずっとエンジニア組織のことに取り組んできたので、ここでは組織の話をちょっとしようと思います。いうカンファレンスで話したのですが、メルカリのエンジニア組織は、こちらの記事で詳しく語っています。logmi.jp2019年4月から本格的にCTOとして日本のメルカリのエンジニア組織を見ていくことになったのですが、課題山積みということで、次から次にやるべきことが出てくる1年でした。メルカリというサービスに対して、どういったエンジニアリングのアプローチを取っていくのか。締めくくりにしようと思います。目指しているエンジニアリングの姿CTOとして考えている目下のゴールは、「エンジニアが自ら考え、決断ができる」状態です。言葉にするのは簡単ですが、実際数百人規模の組織、かつ事業の成長を大きく期待される状況においては、非常に難しいということを実感した1年でした。ここから紹介するのは、そのゴールに向かうために今年1年行った様々な意思決定になります。書いてくれていますが、今までエンジニアのカルチャーというものが明文化されていなかったため、エンジニアにとっての判断基準や評価基準がずっと曖昧なままでした。行動規範のようなものを作りました。tech.mercari.comエンジニアの数は2年で3倍近くになり、メルカリが少数精鋭だった時代のカルチャーはかなり薄まっていました。少数だからこそ成り立つようなものは、規模化に伴ってやり方を変えていかなければなりません。メルカリがエンジニアにどういった期待をしているのかを明文化することは、皆がカルチャーを認識するための第一歩でもあります。「英語で作って日本語訳をする」というアプローチを取りました。いったハイコンテキストな文書は実は日本語を英語にするのは非常に困難です。その逆も然りなのですが、言語の特性なのか英語の方がよりストレートな表現になっていることもあり、英語を主体に進めて日本語訳を作る、というアプローチを取りました。Ladderより納得度のある評価や期待値設定のために、ラダー制度を策定しています。メルカリでは等級(グレード)の概念があり、等級ごとに期待される行動についての定義があります。その期待される行動についてエンジニアに特化した内容になっています。基づき、各等級に求められる期待される行動を具体的に書いています。ここでいう期待される行動は、結果として生み出した事業成果に対する評価ではなく、起こした行動そのものに対する評価になるように設計しています。メルカリが目指すエンジニアリングを体現するようなエンジニアを正しく評価することで、カルチャーの浸透を促していく狙いもあります。Decisionsメルカリのエンジニア組織の目的は最高の体験をお客さまに届けることですが、最高の体験の解釈は人によって違いがあります。会社としてお客さまにとっての最高の体験とは何かを数値化し、作る機能の評価を行っています。多くの意思決定がなされる状況において、正しい方向の意思決定を一貫した判断をする必要があるためです。意思決定ができるように整理をしています。起点として出していく方向で考えています。エンジニアのクリエイティビティとイノベーション日々事業成果に追われ、高い事業目標を掲げていると、自然と優先順位が決まってきます。常に事業としての優先度の高いことしかできないと、エンジニアが自ら考えて作るという力が衰えてしまう恐れがあります。イノベーションを促進するには、普段からエンジニアが持っている素晴らしいアイデアを実験したり、お披露目する場所があるべきです。メルカリでは、エンジニアの創造力を育て、イノベーションを生み出せる源泉とすることが、エンジニアの育成だと考えています。結果は下記の記事を参考にしてください。次回も3月末に開催することが確定し、メルカリの社内イベントとして半年に1回実施することになりそうです。書いているように、意思決定がより小さな単位で実行できるよう開発体制を前進してきました。技術的なアプローチだけではなく、組織的なアプローチも含めて考える必要があります。目指す意思決定のチームへの移譲に向かっていきます。tech.mercari.comまた、プロダクト開発が事業数値の目標に偏ってしまい、存在意義が薄れたり、チームの士気が下がるようなことにならないように、各チームで何故今ここに集中するのか、メルカリは今何を解決したいのか、を言語化するような動きも始めています。報酬確定プロセスの見直し給与の確定は、マネージャにとって非常にコストのかかるものですし、メンバーにとっても非常に重要なことです。そのため、マネージャが結果をフィードバックするものまた一苦労です。そこで、報酬確定のプロセスを改変し、公平でかつ納得感の醸成が容易な方法をスタートします。運用がうまくいったタイミングで、このプロセスや方法論も社外にオープンにしていこうと思います。移管を推進することで、技術的な負債を少しずつ解消するとともに、モダンな技術スタックへの転身を目指しています。別に、2週間単位で進行するスクラムのスプリントを、半年に1回、技術的な課題のみにアプローチする2週間を確保することにしました。この2週間の間は、事業的な開発を全てストップして、技術的な課題解決や負債の解消、プロダクトのコードに対して普段できないことへのチャレンジに時間を費やすことを優先します。