はじめに
こんにちは。ソウゾウHead of Engineeringの@keigowです。「メルカリShops [フライング] アドベントカレンダー2022」の1日目を担当します。ソウゾウのエンジニア組織で大切にしているMove FastというValueと、それを支える仕組みについて書きたいと思います。
Move Fastとは
メルカリグループで大切にしているValueとしてGo Bold（大胆にやろう）、All for One（全ては成功のために）、Be a Pro（プロフェッショナルであれ）があり、面接の選考の基準やEngineering Ladderとして実際の評価にも使われています。
ソウゾウではそれらに加えて「Move Fast」というValueを掲げています。
Move FastというValueには、ただ大胆に早く動けばよいというわけではなく、成功のために必要なことを考え、1人のプロとしてオーナーシップを持って物事を前に進めることが大事であるという思いが込められており、前述の3つのValueの意味合いを含んだものとして捉えています。
ソウゾウでは「できるを、つくる。ソウゾウした未来を、はやく。」というミッションの達成のために、メルカリShopsという新規事業の立ち上げを行っています。Move FastというValueを大切にしているのは、新規事業の立ち上げにおいては、失敗することも含めて試行回数がより重要になってくるためです。
Move Fastするために必要なこと
Move Fastを実践していくにはMicrodecisionsを行えることが大切だと考えています。MicrodecisionsとはメルカリグループのEngineering Cultureでもあり、個々のエンジニアそれぞれがオーナーシップを持って意思決定していくことと定義されています。
Microdecisionsを推進するための仕組み
Microdecisionsの推進のためには「意思決定の独立性」と「意思決定のサポート」が重要だと考えており、ソウゾウではそれを後押しできるように組織を作っています。以下その一部を紹介できればと思います。
全員ソフトウェアエンジニア
ソウゾウのエンジニアはMachine LearningやSREなどの一部の職種を除き、Frontendが得意なメンバーもBackendが得意なメンバーも「全員ソフトウェアエンジニア」として働いています。もちろん実際にはそれぞれのエンジニアに専門性があり、得意不得意もありますが、Backendの実装はBackendチームにお願いしなければいけない、というような縛りを無くすことで意思決定の独立性を担保できるようにしています。
Product Team
最近は採用が進むことでプロダクトを開発するチームの人数も増えてきています。直近のプロダクト組織は上記のようになっており、ドメインごとに分けることで、できるだけチーム内で意思決定が完結できるように工夫しています。
また各チームごとにEngineering Managerがおり、Product OwnerやScrum Masterと協力してチームの運営をしていますが、Tech Leadのようなポジションはあえて置かないことにしています。ソウゾウでは個々のエンジニアが意思決定の責任者であり、担当するプロジェクトや機能においては責任者として振る舞うことが求められます。
Enabling Team
意思決定の責任者として振る舞うことが期待されると、相応の負荷がかかることになるため、それをサポートするための仕組みが重要になります。
Enabling Teamは以前のBlogでも紹介したように、Team Topologiesを参考に作りました。チームのコンセプトとして大切にしているのは、技術的に難しいことをなんでもやるチームではなく、技術的に難しいことをProduct Team内で実施できるようにするということです。
Enabling Teamが新しいサービスのPoCを主導したり、Product Teamのエンジニアがスピード感を持って開発に取り組むことができるような基盤やガイドラインの整理に取り組むことで、Product Teamが考えるべきことを減らし、意思決定を行うサポートができるようにしています。
Design Docs
Design Docsの仕組みも工夫の一つです。一人で意思決定を行うのは大変ですが、新しいマイクロサービスを作成するときなどは一度Design Docsに考えをまとめることで、チーム内外のエンジニアやセキュリティチームから適切なReviewを受けることができ、意思決定の精度を高め、負担を減らすことができると考えています。
Design Docsの仕組みを導入するときに論点の一つになるのが、特定の誰かまたはチームのApproveを必要とするかだと思います。ソウゾウでは現状特定の誰かというものを定めないようにしています。あくまでDesgin Docはより良いアーキテクチャを目指すためのツールであると位置づけており、最終的な意思決定者はDesign Docsを書いた本人としています。Design Reviewを依頼するためのSlackのメンショングループは存在しますが、あくまでサポートとしての位置づけであり、興味を持っている人がメンショングループに参加することにしています。
意思決定に伴う責任
一見矛盾するようですが、Microdecisionsを推進することと、どんな内容でも自由に意思決定を行うというのは異なるものだと考えています。少し極端な例を出すとソウゾウで作られているマイクロサービス（現在60以上あります）が全て違う言語で書かれていたら、メンテナンスどころでは無くなってしまいます。
それを防ぐためには、Microdecisionsを推進する際に、意思決定のスコープを正しく定義することが重要になると考えています。裁量のある意思決定には大きな責任が伴うので、前述したようなサポートの仕組みで解決したり、考えること自体を減らしていくような取り組みが求められると考えています。
おわりに
生産性やコードの品質を保ちつつ、Microdecisionsを推進することは、どこまでを基盤と捉えるかの線引も含め、難易度が高いものだと思います。実際にソウゾウでも上手くいっていることばかりではなく、ドメイン知識を強く必要とするようなマイクロサービスに対して専任するチームを作った方が良いのではないかという課題を始め、現在の人数規模なのでギリギリなんとかなっている部分はたくさんあると思います。
今後もエンジニアの採用を進めていく中で、今のソウゾウの良い部分が失われていかないように、常に課題と向き合って変わっていくことのできる組織でありたいと思っています。
余談にはなりますが、ソウゾウ代表の@mazeさんはミッションの一部である「できるを、つくる。」という箇所は、社内のメンバーに対してもEnablingしていく（できることを増やしていく）という意味を含んでいると常日頃から言っています。自分もこの考え方には強く共感しており、Microdecisionsを推進することでエンジニアの成長にも寄与できることを期待しています。
Souzohでは現在以下のポジションでメンバーを募集中です。SouzohのMove Fastな組織に共感した方はぜひ以下のページをご覧ください！
- Software Engineer
- Software Engineer, Site Reliability
- Software Engineer (Internship) – Mercari Group （※新卒採用に応募するにはまずインターンへの参加をお願いしています。）
またカジュアルに話だけ聞いてみたい、といった方も大歓迎です。こちらの申し込みフォームよりぜひご連絡ください！
