YOJOは全社的にマトリクス型組織に移行します！

YOJOはマトリクス型組織を取っています。

本日はその試みについて、まとめてみました！

マトリクス型の組織とは、事業軸×職種（機能）軸で、活動を分離する組織形態です。

各メンバーは職種軸のチームに属して、そこから事業やプロジェクトにアサインされます。

下記に引用させていたただいた図のイメージがわかりやすいかと思います。（引用元：https://flxy.jp/article/4823 から、LIFULLのマトリクス組織の図解）

エンジニアでいえば、全員がエンジニアチーム（エンジニアリング部門）に属していて、そのトップを私が努めている形です。私が、全体のバランスを考えて、PdMや事業部（ややこしいことにtoC事業部も私が見てますが）と意見を交わしながら、各プロジェクトへのメンバーのアサインを決めます。

YOJOでは、各職種のメンバーが増えてきたこともあり、各職種部門内での連携や教育をしやすくするためにこのような組織形態であること明確にしました。

正確に言うと、YOJOの場合は、もともとマトリクス型っぽく動いていたのを、明示的に「我々はマトリクス型組織ですよ」ということで、部門長（いわゆるCTOやCMOに当たる）の権限や役割を明確にするという狙いがあったということです。

マトリクス型組織は、職種ごとに分断される危険性もあるという意見もありますが、むしろこの時期から意識してマトリクス型組織における部門横断的な施策を打っていくことで、組織がより大きくなったときの分断を避けられるのではないかと思っています。

YOJOで始めた部門横断的な仕組みについては、私が書いた下記の記事なども参考にしてみてください！

各職能メンバーを部門ごとに強化しなければならないということが明確になったことで、CTOやEM（他の部門でもそれらにあたる人がいる）がやらなければイケないことが明確になりました。

エンジニアチーム（エンジニアリング部門）では、毎週、部門単独でのKPT、技術顧問への相談会、開発改善MTG（特に改善したい技術的課題を短時間で解決するMTG（ハッカソン的な感じ？））などを行っています。

また、下の記事のように部門ごとの目標を決めることで、各メンバーが事業・プロジェクト軸とは別にやらなければいけないことが明確になりました。

もちろん、事業には事業のOKRがあります。

詳しくは記事を見ていただくとして、部門ごとにはOKRという明確な形ではありませんが、1年後の目標とキラー戦略・やるべきことなどをまとめています。

マトリクス型組織を取っていたので有名なのはメルカリですが、メルカリはマトリクス型からマイクロサービスごとのドメインチームに移行したようです。

その際のメルカリの問題意識は下記のように述べられています。（引用元：https://mercan.mercari.com/articles/18906/）

メルカリでは、基本的にはプロジェクトにエンジニアがアサインされ、開発が進められていました。
ここでの問題は、エンジニア同士でチームをつくりづらく、育成が進まないこと。
また、四半期ごとにアサインされるプロジェクトが変わることも多く、ドメインごとのナレッジが蓄積されない問題もありました。

これは、マイクロサービスを全社的に進めているメルカリならではなのではないかと思いつつ、YOJOでもマトリクス型組織のメリット・デメリットは注視していきたいと思っています。

今後もどんどん組織形態を変えていく必要に迫られるかも知れませんが、経過もシェアしたいと思います。

メルカリがプロジェクトベースからマトリクス型組織に変わった意味について書かれた記事（2019年8月） https://techplay.jp/column/709

メルカリのエンジニアリング組織が「マトリクス型組織からドメインチームへ変わった背景」について書かれた記事（2019年10月） https://mercan.mercari.com/articles/18906/