かとうです。ついに住宅ローンを組みました。

こちらの記事はGunosy Advent Calendar 2021の1日目の記事です。昨年最後の記事はkoidの事業部制組織とCTOでした。今年もよろしくお願いいたします。

そんな昨年のkoidの記事で、Gunosyのエンジニアリング組織について下記のような説明がありましたが、

現在は事業部制に移行し、Product Owner / Business Owner を中心とした Product Teamを組成しています。（グノシー, ニュースパス, LUCRA, オトクル, Gunosy Ads, Network Ads, ...）

1年たつと状況や組織も変わるものでして、グノシー、ニュースパスなどのプロダクトごとに開発チームを設ける形から、メディア開発部という形に再編をいたしました（下記の図を参照）。

今回はそのような判断に至った経緯や、組織の変更とともに変えたことをご紹介したいと思います。

組織の歴史
評価と育成の課題
意思決定、そして再編とCompany Bets
変更して実際どうか
まとめ

組織の歴史

再び昨年のkoidのエントリからの引用ですが、

以前は、「開発本部」という組織の中に、全エンジニアが所属していましたが、現在は事業部制に移行し

2016年までのメディアプロダクトはグノシーのみであり、そこからニュースパスを立ち上げ、翌年LUCRAを立ち上げ・・・と新たなプロダクトを立ち上げるタイミングで少数の既存の社員＋新規採用という形でチームを作ることができておりました。事業部制に移行するにしてもつつがなく組織改編ができていました。

事業部制に移行したことで自分の所属する事業部のプロダクトに集中できるというメリットはあります。しかし、事業部としてサービス規模を拡大しつつ、少数精鋭でサービスを開発している状況になる中でオトクル、auサービスTodayと立て続けにプロダクトを作っていくにしたがって、少数の既存の社員＋新規採用という形でチームを作るという形をとることが難しくなり、既存プロダクトと新規プロダクトとの兼務や一時的な事業部間でのエンジニアのヘルプが見られるようになりました。

このような状況で起こる課題として、主担当として所属している事業に貢献することで評価される前提の中、より上位の事業本部の優先度により想定していないプロダクトのヘルプに携わり、評価者・被評価者間でお互いに見えない成果が発生する*1という事態が起こります。

評価と育成の課題

チームを構成する規模の問題とは別に、エンジニア自体の評価にも課題がありました。 Gunosyでは長らくサーバサイドエンジニア、Androidエンジニア、iOSエンジニア・・・といった技術領域ごとの肩書はあえて用意せず、強みとする技術領域・軸はあれど必要に応じてiOSのエンジニアがGoでAPIまで開発する、といったような助け合い、技術領域を広げるチャレンジを応援する文化を持っていました。

その文化もあって事業ごとの開発チームにも、プロダクトを開発するためにiOS/Android/サーバサイド/...とバランス良く配置をしていましたが、そのチームのEMは1名といった構成になります。 EMもそれぞれ強みとする技術があるわけですが、日々の1on1や半期フィードバックの際に、技術領域にとらわれずプロダクトを開発するエンジニアとしての壁打ちはできてもその技術領域特有の話になると限界がありました。

意思決定、そして再編とCompany Bets

ここまで述べてきた課題をどうすべきかと悩んでいた時に読んでいたのがユニコーン企業のひみつだったのですが、この本で述べられていたトライブ/スクワッド/チャプター/ギルドという考え方、そしてカンパニーベットをヒントにトライできないかと考えはじめました。 Spotifyモデルについての解説はこちらが参考になります。

https://lean-trenches.com/scaling-agile-at-spotify-ja/lean-trenches.com

現在は冒頭に載せた組織変更の図のようになっており、Spotifyモデルとその組織の対応として下記のようなイメージを持っています。

このような形にすることで事業部制での、単一のプロダクトに集中する意識が分散してしまうのではないかという懸念はありました。しかし、一部ではすでに兼務が発生している現実なども踏まえ、Gunosy全体として解決すべき課題に優先して取り組む方を重視するという意思決定を行い、上記のような形にしました。*2

また、第1開発グループ、第2開発グループという組織名についても悩みました。 EMの技術バックグラウンドでチームを構成する発想までは迷いがなかったため、もともとはアプリ開発、サーバサイド開発といった名前で仮置きしていたのですが、技術領域ごとの肩書はあえて用意せずという文化も残したいと思いチーム名に技術領域を連想させないような名前にすることにしました。とくに数字の順序には意味がありません。

（そのため、うにチーム、マグロチームなど寿司ネタとかどうかという提案もしてみましたが、冷静に却下されました。冷静な判断だと思います。）

組織改編に伴い会議体も変更を行いました。その中でとりわけ重要になるのがCompany Bets ミーティングです。 Company Betsはその名の通り会社が取り組みたい重要事項（賭け）の順序で並べたものです。プロダクトを横断して開発する組織に変わったため、どの課題から着手するべきかはその順序を参考にして取り組みます。まだ始まったばかりですが、役員陣も含め四半期ごとに開催し、終わった課題、新たに生まれた課題、順序に大きな変更がないかを確認しています。

変更して実際どうか

変更に伴い、これまでプロダクトごとに設定していた監視体制をどうするか、これまで開発していなかったプロダクトのキャッチアップを実際にどうするめるかといった課題はまだ解決に向けて対応している最中です。再編したのは9月からですが、まだまだ再編前にかかわっていたプロダクトの開発を引き続き担当するメンバーが多いのが現状です。ただ「共有していこう」というだけで進むのは難しいと思っているため、課題のアサインなどの仕組みで解決する方針を検討中です。

また、Company Betsも再編前からある各プロダクトの取り組むべき課題が多くあるため、まだ順序がついていないものがたくさんある中で、新たな課題も生まれてくるため整理に苦労しています。やるべきことがたくさんあるというのは前向きな悩みではありますが。