開発体制をSquad化してきてわかってきたコツと課題

2020年12月9日 21:20

今年の4月からクラシルの開発体制をSquad化したので振り返りとコツ、課題をまとめてみました。

このnoteは dely Advent Calendar #2 の9日目の記事となります。昨日の記事は、@RyogaBarbie のクラシルとRxSwiftデビューです。

クラシルのSquad体制は、Spotifyモデルを参考にSquad部分だけを取り入れたスタイルです。

スクリーンショット 2020-12-07 18.11.22

Spotify Engineering Cultureについては、Henrik Kniberg氏のYouTubeが参考になると思います。この図は組織設計する上で何度も見返しました。

何故Squad化したのか

意思決定やディレクションが特定の人に集中し、ボトルネック化する規模になってきたので、課題毎にチームを分け、達成に必要なメンバーをアサインして、その領域に特化した議論を重ねられるようにしたのが狙いです。

クラシルは100人超で一つのサービスを作っていますが、人数、タスク規模が大きくなればなるほど複雑化して自分の仕事と成果の結びつきがわかりにくなるため、Squad単位でKPI or 定性目標を定めて、アクションの成果がわかりやすくなるように意識しました。

例えば、アプリのパフォーマンスを改善する速度改善Squadのプロダクトマネージャーはその領域に一番詳しいiOSエンジニアがリードしたり、検索改善Squadはアルゴリズム × コンテンツ両軸で話し合い続ける必要があるため、管理栄養士も参加してユーザーの立場となって必要な議論と実行ができる状態にしました。

少数部隊にすることで、個が埋もれにくくチームワークを発揮しやすくなる

Squad毎に目標KPIを定めて、2週間以内の見積もりタスクは現場裁量でリリース → データモニタリング → 分析/議論 → チームで学習するサイクルを取り入れてます。

ディスカッション量をより増やすために下記のような工夫をしてます。

・1Squadの人数はMAX4人を基本とする
・Squadの座席は背中合わせにして一つの島にまとめる
・議論や会議はカレンダー化せず座席で実施する
・Squadの兼務しない

人数が多いと抽象度が高い話になりがちで濃い議論が継続できるよう1Squadの最大人数は基本4人までとしてます。

過去の反省で、開発者全員でデモアプリを触って意見を言う会を定期的に実施していたのですが、人数が多いと深い議論がしにくく当たり障りのないフィードバックになってしまう状況がありました。

今はSquadメンバーは担当領域最後の砦として、仕様を深く把握し、ユーザー体験を考え抜くスタイルにしてから自分ごと感も高まって議論の活性化ができたと思います。

目標設計で重要視しているのはSquad内で完結する目標に落とし込むこと

スクリーンショット 2020-12-09 19.33.20

この体制では、Squad内で完結できる粒度のプロジェクト化・目標設定化が重要で、自チームはやりきったが他のチームの優先順位が釣り合わず、実装遅れなどで目標が達成できないなど、外部要因が増えると非効率ですし、メンバーのモチベーションが保てません。

チームを横断型のプロジェクトは、タスクの優先順位が釣り合わなかったり、責任所在とタスクのたらい回しが起こりがちです。横断が必要な場合はSquad横断で解決するのではなく、そのためのSquadを新たに作って対応してます。

僕の開発マネジメントは、チームが自走できる仕組み作りをテーマにしてるので、良くも悪くも実行したアクションと結果が感じられるような設計を意識してます。

抽象度が高い仕事は難易度が高く、具体化するとコトに向かって自走しやすくなるので、プロジェクトマネジメントの難易度として下記のようなレベル設計でチームやメンバーアサインを考えてます。

レベル1：目的明確：金脈がハッキリして掘れば金が出る領域のグロース
レベル2：目的明確だけどステークホルダー多数：外部パートナー巻き込み
レベル3：不確実性高い：新機能、0-1の新事業、抽象的なミッション
レベル4：10-100フェーズのサービス全体設計

クラシル開発のPdMはバランス型

スクリーンショット 2020-12-09 19.51.31

組織が100人を超えてサービスが10→100のグロースフェーズになると、個々がスタンドプレーをしても結果がでなくなり、それぞれのSquadで作る価値(機能)の掛け算でサービスをグロースさせていく必要があります。

そのため、Squad毎にビジョンや独自文化を作るのではなく、コース料理を提供するレストランがメインに合う前菜を考えたり、料理に合わせたペアリングワインを提供するなど多くの料理人の力を合わせて一つのコース料理を提供しているように、会社のビジョンを逆算して、自チームの持ち場の役割を理解して実行する文化が必要だと考えています。

Squad間の情報シェア精度はまだ模索中ですが、ドキュメンテーション文化、毎週全社が参加するUX改善会でプロセスシェア文化で情報格差を生まないように意識してます。

サービス議論が何よりも最優先

行動指針として、Squadメンバーは、サービスやプロダクト改善を最優先とするカルチャーにしてます。

優先順位の考え方は「Squad MTG >>>>>> 職能MTG｜1on1」で、サービス議論が白熱している場合、それ以外の定例や上司1on1の時間がきても途中離脱せずサービス議論を優先するし、昨日のデータに違和感があれば、納得行くまで朝会で議論し問題を発見する文化を提唱してます。

ユーザーファーストはユーザビリティの品質だけではなく、組織や上司よりもユーザー第一主義の立ち振舞いがにじみ出る行動だと考えています。

朝会運営のコツは、1週間かかる作業でも進捗を毎日切り出して可視化して見せて、話す文化を作っていくこと

タスク進捗を言い合うだけの朝会はあまり意味を感じておらず、1週間かかる作業でも進捗を毎日切り出して可視化して話す文化を作っていくプロセス可視化の標準化を意識してます。

例えば、下記のような感じです。

・デザインであればFigmaの途中経過を見せること
・プログラムであれば仕様設計の考えをDocbaseに書く / 不完全でも良いので実機で触れる状態を見せながら話す
・企画であれば議論のメモを貼る、考えやフローズをシェアする
・計画するならロードマップの叩きをシェアする

こんな雰囲気。デザイナーと管理栄養士とエンジニアなどが居て日々話してます。

悩み

Squad化してから優先順位や目標は明確になったモノの、兼務禁止にしてるがゆえのリソース枯渇、Squad化してない領域のタスク実行が難しくなったので、どうしたもんかというのが最近の悩みです。

例えば、どのSquadにも属さない領域のバグや要望改善。

もし同じような悩みを持ってたり知見のある方がいればぜひ情報交換させてください。