1 The changes of the engineering organization in Mercari - From the view of an engineering manager - Hidenori Goto （Mercari JP Backend EM） EOF 2019 (2019/10/31)
3 One big difference between Mercari and Merpay Merpay Mercari Developed in microservices In the middle of migration from a monolith to a microservices
4 Conway’s law The basic thesis of this article is that organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. We have seen that this fact has important implications for the management of system design. Primarily, we have found a criterion for the structuring of design organizations: a design effort should be organized according to the need for communication. Melvin E. Conway, 1968 “HOW DO COMMITTEES INVENT”
5 A rough history (1 year) Matrix organization + Microservice migration project team Domain teams beginning Domain teams familizalizi ng Domain teams mature ？ 2019/01 2019/04 2019/07 2019/10 ① ② ③ ④
#eof2019 6 A matrix organization to Domain teams ● In the matrix organization, engineers couldn’t form stable teams nor deepen domain knowledge ● Only a part of members was in charge of the microservices migration project [Change] ● We re-organized all backend engineers into domain teams which were based on product features. ● All backend teams started microservies migration tasks. [Unplanned] ● Skilled engineers who have worked in ms migration project tentatively moved to other division... ● We lacked the knowledge of microservices development, etc.
7 Domain teams grow mature ? ● Every domain teams got development and domain knowledges ● Every domain teams has grown into mature team. [Change] ● The number of feature development requests increased ● Our productivity seemed to decrease Have our domain teams gotten mature?
8 Problems ● Both in a microservices development and a feature development, engineers had a lot of “inter-team” communications. → a problem of a teams structure ● Engineers sometimes discussed about which team should handle instead of defining specs. That discussion took longer time, had a difficulty to reach a consensus. → a problem of a re-structuring an architecture
9 A balance of the domain team system Pros Cons Domain knowledge Team members can have a strong motivation to deepen their team’s domain knowledge. Team members don’t have so strong motivation to know other domains. Ownership Team members can have a strong ownership of their domains. Team members don’t have so strong ownership against entire system. Architecture Tends to optimized partially It’s difficult to encourage members to think about entire architecture. Team assignment Assigning new member to an existing team is not so difficult. It’s difficult to move a member across teams. It’s also difficult to build a new team. Feature development If it’s handled in one domain team, it’s easy. If there is no domain team where a feature fits in, or a feature is covered by multiple domains, the development cost tends to increase
10 A future of our team system Continuous Innovation Micro Decision Secure & Trusted system Flexibility＝Continuous restructuring （organization and system） ※This is a personal thought.
hidenorigoto
tkhresk
mtx2s
kgsi
shibuiwilliam
yuya4
h1kita
tomoaki25
minorun365
orgachem
sansantech
oracle4engineer
chloe463
tanoku
addyosmani
malarkey
vanstee
philhawksworth
bkeepers
hatefulcrawdad
lara
kevinliebholz
marktimemedia
schacon
gr2m