はじめに
くろ: こんにちは黒瀧(くろ)です。SUZURIではシニアエンジニアリングリードをしています！
みるてぃ: こんにちは、みるてぃです！今年の11月から、SUZURIのプロダクトマネージャー（以下、PM）として入社しました。
くろ: 今回は最速でプロダクトを成長させるために、みるてぃさんと協力してSUZURIの開発体制をアップデートしたので、その話をします。
解決したかったこと
みるてぃ：SUZURIの事業拡大に伴い、開発メンバーの人数も年々多くなり、自分が入社した11月には開発メンバーだけですでに20人を超える大人数チームになっていました。 タスクの進行について他のPMに話を聞いていると、急激にメンバーが増えたが故に、「誰が、何を、いつまでにやるのか」ということがPM側で把握しづらい状態が発生していることがわかりました。
くろ：エンジニアメンバーと1on1をしている中でも、タスクの優先度が分からないという話をよく聞くようになってきて、プロジェクトの進め方を組織拡大に合わせて変えていかないと、エンジニアが疲弊していってしまうと感じていました。
みるてぃ：これらの課題を解決するにあたり、まずは「誰が何のタスクを持っているのか」ということから俯瞰できるようにするためにGitHubのプロジェクト機能を使ってチーム全体のカンバンを作って運用することに決めました。それによって、手探り状態だったタスク状況を可視化することができました。
ただ、その上で、以下3つの課題が浮上しました。
1. 各メンバーのタスクの進捗状況を把握することが困難
みるてぃ：組織も大きくなり、メンバーひとりひとりのタスクの進捗状況全てをPMもしくはエンジニアリードが把握することが困難になりました。その結果、タスクの進捗の確認が難しく、かつ意思決定者が不明確であることから、思いも寄らないところで開発が止まってしまっている開発もありました。
2. タスク割り振りの際、誰をアサインするのかの判断コストがかかる
みるてぃ：「誰に何を頼むか」の判断基準が曖昧なため、タスク割り振りの際非常に判断コストがかかるということは深刻な問題でした。
特に私自身はエンジニア出身ではないことから、工数などを加味したタスク割り振りが難しく、だからと言ってエンジニア側も「全てのタスクを把握した上で最適な人に担当者を割り振る」というのは人数規模的にも不可能な状態であったため、「とりあえずやれそうな人がやる」という状況に。
その結果、担当分野とタスクの空き状況を判断しながら最適な人にスムーズにタスクを割り振ることができず、新規タスクのアサインが宙に浮いてしまったり、担当者が偏ってしまったりすることもありました。
3. タスクの優先度をエンジニア自身で判断しにくい
みるてぃ：コミットするKPIが明確でないため、明確な期日がないタスクを複数持っている場合にそれぞれのタスクの優先度がエンジニア自身でつけづらく、本当に優先してやるべきタスクが後回しになってしまう場合もありました。
もちろん、基本的なスケジュール感や優先度はPMがつけているのですが、前述の通り全タスクの進捗状況をPM一人が把握し、都度優先度をつけることは困難なため、優先度を誰でも判断しやすい仕組みを作る必要がありました。
とにかく、上記3つの課題を解決するために、チームを少人数チームに分けて動くということが意思決定の速さにつながると考え、開発体制の刷新を黒瀧さんに相談しました。
SUZURIのエンジニア組織とSpotifyモデル
くろ：エンジニア組織が大きくなってきて、権限委譲と組織づくりを行う必要性が高まってきました。ピザ2枚ルールみたいな話がありますが、ミッションごとに小さいチームに分けて、自己組織化したチームを作っていかないと、組織が拡大していく中でコミュニケーションのコストが大きくなると判断しました。
ペパボ社内でホスティング事業部がSpotifyモデルというものを取り入れて組織づくりをしていると聞いたので、縦軸にKPI、横軸に職能を置いたマトリクス型の組織構成をSUZURIでも取り入れてみることにしました。大きい集団から、小さいチームに分けて意思決定ができるようになりました。
Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds より
Spotifyモデルは失敗したという話も聞きましたが、プロダクトマネージャーとエンジニアリングマネージャーが協力することが大事という話や、チーム間のコラボレーションのためのプロセスを定義する必要があると感じていました。 SUZURIでは、上記のような失敗を踏まえて、そういったところもカバーできる独自のアレンジを加えた体制を整えることを意識しました。
どんなプラクティスもその価値を理解した上でソフトウェアのように継続的にアップデートして実行しないと上手くいかないものです。私たちも定期的に見直してアップデートしていきたいと思っています。
余談ですが、エンジニアのyuta25さんはMTGの時によくSpotifyでモーツァルトの音楽をかけてくれます。BGMがあると落ち着いた気持ちになれてよいですね 😉
実際にSUZURIで取り入れた開発体制
みるてぃ：プロダクトチームのメンバーを、Spotifyモデルでいう「Squad」、すなわち解決するべき課題別の担当分野という縦軸で少数チームに分けました。 また、横軸は同じくSpotifyモデルの「Chapter」、すなわち職務軸として、それぞれ人員を配置しています。
Squadのチーム構成
みるてぃ：Squadは、
- プロダクトオーナー 1名（現状はPMが担当。場合によってはサブでもう一人配置。以下PO。）
- エンジニア3〜4名（各Chapterから1〜2名ずつ）
- デザイナー1〜2名
の、平均6名ほどで構成されているチームで分かれています。
各Squadごとにそれぞれ課題解決のためのミッションとKPIが設定されており、メンバーは基本的にこのSquadが掲げているミッションとKPIを達成するためのタスクを優先的に着手します。
Squadには、プロダクトオーナーとエンジニアのリーダーそれぞれ1名ずつ配置しており、それぞれ以下のような役割を担っています。
プロダクトオーナーの役割
Squadで行う施策の立案、優先度づけ、要件定義、スケジュール管理、効果検証まで全て責任を持ちます。また、Squadの担当分野に関する他チームからの相談があれば窓口となり、施策のやる・やらない、ならびに仕様の最終決定をします。
エンジニアリーダーの役割
エンジニアメンバーのタスクならびに進捗状況の把握、新規タスクの割り振りをします。また、Squadの担当分野に関する技術的な相談などがあれば窓口となり、他メンバーに共有する責任を持ちます。
Chapterのチーム構成
- Web（フロントエンド、バックエンド）
- モバイルアプリ
- デザイン
- インフラ
- セキュリティ
という軸で、エンジニアならびにデザイナーを配置しています。 また、各Chapterにも、デザインならびに技術的な最終判断をするリーダーを設けることによって、Sqaudを横断した協力体制を整えました。
SquadとChapter、ならびにそれぞれのリーダーの呼称について
くろ：最初はみるてぃさんと「ギルドの方がなんかかっこよくない？」という話から、縦の集まりをギルドと呼ぶ事にしました。
ただ、サービスも含めて、一貫した「世界観」を重視するSUZURIチームの呼称として、いまいちそうした中世風な名称がしっくりきませんでした。しっくりこないということは、名称や役割もチームに浸透しづらいであろう、ということを踏まえて、再度上記の仕組みを説明した上で、他メンバーにも呼称を募ったところ、他メンバーの提案で、社内で使っているScrapboxにこんなページが作られました。
SUZURIって名前は硯から来ていて、スリスリくんは忍者だし、CSSフレームワークは那智黒だし、なんか良い感じじゃんと思って、上記の呼び方をベースに再度各呼称の見直しをしました。チームのみんなが楽しく呼べる名前になっていくと嬉しいです。
その結果、以下のような体制で進めていくことになりました。
座（＝Squad）
座長
プロダクトオーナー。施策立案、仕様決定、スケジュール管理、効果検証など、タスク進行の責任者並びに他チームからの関連施策の相談窓口。
頭（かしら）
座におけるエンジニアのリーダー。メンバーのタスク管理責任者並びに関連施策の技術的な相談窓口。
衆（＝Chapter）
棟梁
衆のリーダー。各技術的な部門にて、エンジニア/デザイナーとしてデザイン・技術的な最終判断の責任を持つ。世間で言うと、いわゆるテックリード的なポジション。
メンバー
所属する座のタスクを最優先に担当&開発する。タスクが空いたときは、棟梁に相談して別の座のお手伝いをしてもOK。
みるてぃ：メンバーについては、「タスクが空いたときは、棟梁に相談して別の座のお手伝いをしてもOK。」というルールが意外と大事だなと思いました。
「自分の座のタスクしかしない」という考えになってしまうと、効率的なタスク進行ができなくなってしまいます。（これがSpotifyモデルの失敗の要因の一つとも言われています。）
実際このルールを適用して、手が空いた人が他の座のタスクを担当することもよくあります。
みるてぃ：また、図には記載していませんが、前述の通り、各「座」にミッションとKPIを設定しています。それによって、「この数字をあげる施策だからこの座担当でやろう」とか、「（所属している座の）KPIに大きく影響する施策だから、このタスクの優先度を高めよう」など、タスク割り振りの判断コストを下げられるだけでなく、各メンバー（特にPO）がそれぞれのタスクを自分ごと化できるようになってきました。
解決できてきたこと
みるてぃ：結果として、今までの課題が大きく改善されました。
タスク状況の確認コストが大幅に削減、意思決定者の明確になった
みるてぃ：少人数の「座」に、メンバーのタスク状況を把握するエンジニアのリーダー（＝頭）を立てることによって、タスク状況の確認コストが大幅に削減されました。また、意思決定者としてPOこと「座長」を配置することで、仕様面で議論する余地があった場合に最終的な判断を誰がするのかが明確になり、意思決定者不在で放置されるケースがかなり減りました。
また、各POが担当の「座」を分担することによって、優先度づけや意思決定について担当領域が明確になり、ひとりひとりの負担が大幅に削減されました。また、新しく人が入った場合も担当領域が明確になりそうという点もメリットだと感じています。
誰に何をアサインするべきかが明確になり、判断コストが下がった
みるてぃ：「頭」がメンバーのタスク状況を把握できるようになったことで、自分の「座」の担当タスクを迷わず適切な人に割り振ることができるようになりました。また、各「座」ならびに所属メンバーが明確になることにより、誰に何を頼む（or相談する）かの判断コストも下がったため、いわゆる「頼まれやすい」人ばかりに相談が偏るということも減りました。
タスクの優先度の把握がしやすくなった
みるてぃ：各「座」のミッションとKPIを設定することにより、メンバーそれぞれがやるべきこととタスクの優先度を把握・理解しやすくなったと思います。 少なくとも、前述の通りPOは担当領域が明確になったため、優先度の判断コストが下がり、エンジニアにも漏れなく優先度の脳内同期がしやすい環境になりました。 今後、各「座」ごとのミッションとKPIがPOだけでなくエンジニアやデザイナーにもきちんと浸透することで、各自が優先度をより判断しやすくなるようにしていきたいと思っています。
新たに見えてきた課題
どこにも所属しない案件をどう処理するのか
みるてぃ：簡単なタスクであれば、日直さんにお願いするという運用にしています。ただ、思いもよらず工数がかかるものについては、「誰がやるのか？」についての判断がまだ難しいところがありますね。
なのでそういった宙に浮いた案件について誰が担当するのかを判断するエンジニアのポジションの創出や、大型案件については別途（座に囚われない）プロジェクト化ができると、より早い意思決定ができるのではないかと思っています。
エンジニアの個々の成長にも繋げていきたい
くろ：座のKPIにコミットしていくのはもちろん大事なのですが、エンジニアとして技術スキルを向上させていかないと、できることが限られてきてしまうので、一人一人が学習して成長し続けられる環境を同時に作っていかないと行けないと思っています。
そのためにも、棟梁を中心とした衆の動きも加速させていきたいと考えています。エラスティックリーダーシップという書籍の中で、チームには自己組織化モード、サバイバルモード、学習モードという3つのモードがあるということが書かれていましたが、これからは学習モードを作る流れも生み出していきたいです。