開発組織デザイン
開発組織としてマトリクス組織という形態が存在します。代表的なのがユニコーン企業のひみつで紹介されているSpotifyモデルと呼ばれる組織形態。原典はScaling Agile @ Spotify で この図
職能横断でチームを分割し、プロジェクトを進行させる組織形態
そしてこのマトリクス組織を導入している企業は多く見られます
techplay.jp qiita.com tech.pepabo.com
自分もマトリクス組織で開発をしているが、「組織デザイン」という本では基本的には組織設計の論理・原理原則が説明されておりマトリクス組織についても説明されています。これを読んで読書の記録、備忘録としながら、われわれのようなインターネット企業での一般的な開発に当てはめて自分の経験を交えながら開発組織としてはどうすべきか考察などを残したいと思います
本としてはさらっと読んだ感じとても示唆に富むような、いつ何時に読んでも新たな発見が得られるような内容でした。目次は
- (序章)組織デザインとは何か
- (1)組織形態の基本型
- (2)分業のタイプ
- (3)標準化を進めるー事前の調整
- (4)作業の流れー処理プロセスのスムーズな連動
- (5)ヒエラルキーのデザイン
- (6)水平関係とその他の追加的措置
- (終章)結びに代えて
となっています
まず(1)組織形態の基本型について読んでいきます
まず単純な組織形態としては、機能別組織(以後馴染みのある職能別組織と呼ぶ)が存在します。例えば、エンジニアの組織とデザインの組織が完全にわかれ、それぞれにトップが存在しており、個々の組織内で複数の事業を扱っているようなイメージです。この組織の特徴は単独で存続しえないということです。デザイン部門だけで事業を成り立たせることはできません。特徴としては、エンジニアの組織であればエンジニアリングに関する目標が立てられ、自分の専門を通じて会社に貢献するという傾向が強くなるかと思います
そしてこれに対して、個々の組織が自律的に存続できるように分割するのが事業部制組織です。その中にそれぞれエンジニアやデザインの組織を扱います。特徴としては、事業の数値目標が立てられ、自分の専門が何であろうと扱っている事業の成長に貢献するという傾向が強くなるはずです。またトップがどのような職種であろうとエンジニアリングやデザイン、その他もろもろの意思決定をする必要があります
どちらにするかという判断をすることになると思うのですが、職能を集約するのか、内部で統合したほうがメリットが大きいのかの判断になるかと思います。多くの議論があるかと思いますが、会社の規模や、扱っている事業、目標の立て方や、メンバーの能力、仕事の進め方などなどにより決まってくるのだと思います。仕事をするにあたって、他の職能のメンバーと頻繁にコミュニケーションを取る必要があれば内部で統合したほうが良いのかもしれません。しかし会社の規模がそれほど大きくなく素早く連携できるのであれば統合のメリットもそこまでなく、別のメリットがあるかもしれません
ではどちらにすれば良いのか?ということですが、簡単に答えが出ない場合や、意思決定のたびに柔軟に対応する必要がある場合に両方盛り込んだ組織形態としてマトリクス組織が存在すると書かれています。各事業の部門長と各職能の部門長の2軸で構成されるような形態です。そして、意思決定のたびに対立を組織内で議論し、最終的にトップがバランスさせていくという形になります
以上が基本的なマトリクス組織の紹介ですが、実際にそのままこういう大きなマトリクス組織をやっているところは自分が知る範囲のネット企業ではまだ見たことがないように思います。全社的に複数の事業をまたがった意思決定を各事業と各職能の部門長が実施するということはあまり見たことがないかもしれません
基本的には事業部制であり、その中のバックエンド、フロントエンド、デザイナー、PMなどの職能組織でのプロジェクトの進行やコミュニケーションのやり方として、職能横断でチームを作り自律させるという小さなマトリクス組織がほとんどだと思っています
今後事業部制組織でマトリクス組織を作らない組織を職能別組織と呼びます。ここで、マトリクス組織を作るか作らないかについて考えたいと思います
マトリクス組織がない場合の特徴としては、何かしら案件、プロジェクトを進行するときに各部門のマネージャーが入りプロジェクト進行を整理し、部門内のメンバーにアサインし、プロジェクトを管理進行していくということになるはずです。メリットとしてはしっかりプロジェクトを管理して進行していけるというところにあると思います。スケジュールや品質などマネージャーがすべてを把握し管理しながら進行することができます。デメリットとしては、スケールさせることができない点にある。マネージャーが管理できるメンバーの数やプロジェクトの数には限界があります
マネージャーがボトルネックにならないための解決策としては、、メンバーに移譲していくという動きになります。あらゆる組織が目指すべきは自律した組織であり、メンバーに移譲しプロジェクト進行させられるようにするのがマネージャーの仕事の1つです。これが高度化してくると自然とマトリクス組織になるのではないかと思っています。それぞれのメンバーはそれぞれのプロジェクトで集まり、チームを作り、そのチーム内で完結してプロジェクトを進めることができることが理想です
メリットとしては、プロジェクト進行に管理コストがかからないこと。デメリットとしては、管理が行き届きにくいことです。メンバーの能力もある程度任せられるくらい成熟したメンバーが多く必要になるはずです
マトリクス組織を目指すのが理想ではないか(さらに大きいマトリクス組織も)と思うが、これもその時の会社や事業、メンバーなどあらゆる要因から決定する必要がある。マトリクス組織である必要もないし、すべてがマトリクス組織である必要もないです
そもそも職能別組織であっても、それぞれのアウトプットを統合する作業というのは必ず存在します。そこで必ずコミュニケーションは発生し、何らかの連携はあるのだからそれはマトリクス組織なのではないかという話もあるかもしれませんが、個人的には個々の組織、チームが事業のことを考え取り組んでいけるよう自律させるような組織を考えることがマトリクス組織なのだと勝手に思っています
ここから、具体的にわれわれのような昨今のインターネットサービスの開発でマトリクス組織を機能させるにはどうすれば良いのかについて考えてみます
前述したように本書で述べられている各事業の部門長と各職能の部門長が議論し、責任者が意思決定をするという内容だったが、小さなマトリクス組織ではどうすべきか。基本形を考えてみます
わかりやすく対応する各職能としてはビジネス、PM(PO)、エンジニア(EM)が存在し、事業責任者が意思決定するということになると考えられます。それぞれ以下のような責任範囲となるかなと思います。少し話はそれますが、当たり前かもしれませんが責任範囲や役割を明確にすることは大事です。それは自分のなかだけではなく実際に任命される人はもちろん、関わる人全員がその人は何の役割と責任があるのか理解していることが非常に重要です。これがないとコミュニケーションがうまくできず、物事がうまく前に進みませんし、仕事のクオリティも向上していきません
ということになり、ビジネスは経営方針などについて、POはプロダクトについて、EMはエンジニアリングについて、これを元に事業責任者がバランスさせて意思決定をしてチームを作って開発していくことになるでしょう
(1)組織形態の基本型については以上です。以降の章についても少しでもご興味持っていただければ頑張って書きます @tsuwatch
2021年振り返り
ZOZOテクノロジーズではWEARのバックエンドエンジニアとしてお世話になっています。本当にいい方たちばかりで、コロナ禍で3ヶ月間くらい一度もリアルでお会いすることができなかったのですが、とてもあたたかく迎えていただきました
自分が入社する前くらいまでのWEARの取り組みはこちらで発表されています
ファッションコーディネートアプリWEARの リプレイスと組織の変遷 / wear-replace-2021 - Speaker Deck
マネージャーとしてこういうことをやろうと意気込んでいたのですが、入社するとすでに自分がやろうとしていたことと同じような方針でチームが運営されていることに正直驚きましたが、嬉しくもありました。自分はそれをより浸透させ、正統進化させようと取り組んだ半年ほどでした
来年はよりチームとして成熟し、スケーラブルなチーム、大きな成果を出せるように引き続きチャレンジしていきたいと思います
来年もよろしくお願いいたします