はじめに
サービス開発部部長の勝間(@ryo_katsuma)です。 普段は、エンジニア、デザイナ、ディレクターを含む様々な職種のメンバーのマネジメントを行っています。 今日は、私の部署における組織づくりの取り組みについてお話いたします。
背景
現在、私が所属しているサービス開発部は、年初の組織改編時に発足しました。レシピをさがす、のせるなどを含むレシピサービス、いわゆる「クックパッド」において、広告事業、会員事業など事業にまつわる開発以外のユーザーに触れる部分の開発を行っています。 クックパッドはPCウェブ、モバイルウェブ、モバイルアプリといくつかのプラットフォームをサポートしていますが、ここ最近の部署での開発はモバイルアプリを中心に行っています。
メンバーの数も他の部署と比較しても多く、学生アルバイトも含めて約45人が所属し、役割ごとに分割されたグループにも10人前後のメンバーが配置される、全社で見ても大規模な部署となっています。
課題感
モバイルアプリ「クックパッド」は2009年に最初のリリースが行われました。iOS, Android共に何度かリニューアルを経て今に至り、コードベースも関わる人の規模も大きなアプリです。部署としてはモバイルアプリの開発にフォーカスを行う中、このような環境下で価値を早く多く生み出していきたいという思いはあるものの、部署が立ち上がって2, 3ヶ月ほど経過した時点で次のような課題感を抱きました。
チーム内での課題
前述の通り、チーム規模も大きいものになっていることからか、なかなか開発のスピードが上がらないという現象が生まれていました。純粋に開発そのものの速さについての課感もありましたが、マネジメントの観点での課題が目立ちました。例えば、方向性の確認、デザインのすり合わせ待ちなど、チーム内でコミュニケーションの渋滞が起きるケースも少なくなく、「もっと意思決定を早く行い進めることができるはず」という考えを持っていました。
チーム外での課題
クックパッドでは、部署内の役割や施策の目的に応じて「グループ」という単位で組織を分割を行うケースが多くあります。たとえば私の部署では、レシピ検索の体験向上を目的にした「さがすグループ」調理後の料理の記録体験を目的にした「きろくグループ」など、期初の段階で幾つかのグループを設置していました。
一方、グループで分割されたメンバーは、良くも悪くもグループでの施策に閉じてしまう傾向がありました。たとえば「レシピをさがす観点で記録系プロダクトはどうあるべきか」「レシピの調理という観点で、記録のあるべき姿を考える」など、グループをまたいでサービスを捉え、どのような体験をユーザーに提供すべきか？という議論は十分に実施できていませんでした。
個人の成長の課題
前述のような観点での課題に対する取り組みを進め、部署の目標達成を目指す中、個人の成長を促す機会もしっかりつなげたい思いがありました。つまり、ただ業務効率の最適化を目指すだけではなく、業務を通じて個人の役割と責任範囲を広げ、結果として各メンバーが成長している状態を目指したいと考えました。
Spotifyモデルの適用
このような課題を解決する上で、自分たちだけでいろいろ試行錯誤を行うことも可能でしたが、まずは他社の「うまく回っている」開発スタイルについて事例調査をすすめることにしました。そんな中、Spotifyの考え方、カルチャーにたどり着きました。
この中で、特に注目したものは「Alignment and Autonomy」という考え方です。
ここでの「Alignment」とは、いろいろなものや人を1つの考えのものに一致させていくこと、「Autonomy」とは、自律的に動いていくことです。これらの概念は、相反するものといっても過言ではないですが、「リーダーがどの課題をなぜ解くのかということにフォーカスし、どのように解くか？はチームに任せる」というアプローチによって、両立を目指そうとする考え方です。
- Growing up with agile - how the Spotify ‘model’ has evolved
- Enabling Autonomy at Spotify
- Growing Up Spotify
会社の方向を向きながら、チームメンバーは自律的に垣根を超えて協力体制を作り進んでいく。これは、前述の課題に対して最適なアプローチで、理想の姿の1つとして目指していく価値はあるのでは？と考えました。
なぜSpotifyか？
Spotifyは以下のような特徴を持っています。
- 組織の人数規模が数百人
- グローバルな開発チームを構成
- 音楽プレイヤーという１つのアプリケーションを多くのプラットフォームで展開
これらは、エンジニアが国内だけでも約100人、レシピサービス「Cookpad」をグローバルで展開するクックパッドの今の状況と非常に似ています。
また、Spotifyの取り組みについて研究、および言及されている文献も非常に数多くあります。たとえばHarvard Business Schoolでもその開発スタイルについて言及されており、アジャイル開発における１つのスタイルとして、デファクトスタンダードと言っても過言ではありません。
国内外含めていくつかの企業の事例を調査していましたが、これらの背景からSpotifyのモデルの導入検討は十分に価値があるものとして考えました。
Spotifyモデルの導入
以下の３つのステップでSpotifyモデルの導入を試みました。
ミッションの棚卸し
期初でも会社の方向性とそれに基いた部署で実施していくことのすり合わせは実施していましたが、Alignmentを改めて強化する観点で
- 会社としてやるべきこと
- 部やメンバー自身がやりたいと考えていること
を再整理しました。
前者は、「Spotify Rhythm」と呼ばれる全社的な戦略立案のフレームワークをそのまま採用しました。Data→Insight→Belief→Betという観点で現状を整理し、サービス開発の観点で「Company Bets (会社として賭けるもの)」について、上長（本部長）との議論を通じてお互いの認識を揃えました。また、後者は、私自身の考えや部署のグループリーダーたちの考えをもとに再整理しました。
結果として、部署で進めるテーマは期初に計画していたものと大きく変わることはありませんでしたが、Spotify Rhythmによって関係者の認識を改めて整理し、揃えることに大きく貢献をしました。
グループを撤廃した少人数のチーム編成
前述の通り、部署において「グループ」という構造を置くことで、メンバーは「これはxxグループの担当だから」と、グループ間の線引きを無意識に行ってしまうことがありました。 マネージメントの観点では、グループを作ることが重要ではなく、KPI達成に向けて目標管理を含めメンバーの日々のマネージメントを行うことが重要です。 そこで、思い切って組織構造上のグループを全て撤廃することにしました。メンバーは全て部付けにして、「みんな同じ立場である」ということを組織構造上で再認識してもらいました。
とはいえ、45人前後の部付けメンバーを全て直接私がマネジメントすることは不可能なので、さすがにチームの概念は導入します。チームはAutonomyを向上させる観点で以下の戦略で構成しました。
- Spotify Rhythmで再定義した部署で開発をすすめるいくつかのテーマを「ミッション」と定義
- たとえば「日本中の料理を記録する」「日本中の人がクックパッドで毎日の料理を見つけている状態にする」などのミッション
- 各ミッションには、リーダー役として「ミッションオーナー」を設置する
- ミッションに応じて1~2のチームに分割
- 1チームは最大で5人前後
- ロールは下記の人たちで構成し、チームによってはエンジニアはiOSエンジニアのみ、ディレクターはなしのようなケースも
- チームリーダー（1チームの場合はミッションオーナーと同義）
- エンジニア (バックエンド / iOS / Android)
- デザイナ
- ディレクター
人数を5人前後に絞っているのは、既存の10人前後のグループでの構成において、コミュニケーションに渋滞を引き起こし意思決定のスピードを下げていると判断したことが背景です。人数を絞った上で、ミッションに紐づくチームの役割を明確化することで、チーム内での意思決定を推し進めてAutonomyの強化を図りました。
余談ですが、ここでの「チームリーダー」のロールはエンジニアやデザイナ含めて若いメンバーにもどんどん挑戦してもらっています。チーム規模を小さくすることで、チームをまとめることが最悪うまくいかなかったとしても影響範囲を小さく留めることで、「将来的にミッションオーナーを任せたい人」「ミッションオーナーに興味がある人」「個人の役割を広げてもらいたい人」などに、積極的にトライをしてもらっています。
チームをまたいだ横断会の実施
小さいチームに分割しただけでは、結局既存のグループを分割しただけでチーム間の連携を取る、チームを俯瞰してユーザー体験を考えることは大きく変わらないと考えました。
そこで、ディレクターのチーム横断会、デザイナーのチーム横断会、Androidエンジニアのチーム横断会など、職種別の横断会を設けて、参加者のコンテキストを揃えた上で、お互いの持つ課題を解決できる環境を作ることにしました。各横断会では責任者を立て、それぞれの会ごとに最適な運営を実施しています。たとえば、ディレクター会ではチームを横断した知見共有を目的において、互いの施策に活かしたりスキルの向上に役立て、 iOSエンジニア共有会では、普段抱えている開発上での課題感や設計方針について議論をするなど、技術力の向上に繋がる取り組みを行っています。
このように、横断会を通じて、俯瞰して物事を捉え各メンバーのスキル向上の実現を試みています。
導入の結果
Spotifyモデルを導入し、組織構造に手を入れてから3ヶ月ほど経過しました。全て数字で測れるものではありませんが、次のような変化が見えてきました。
意思決定の速度向上
少人数のスモールチームを推し進めたことで、関係者とのコミュニケーションパスの数が減り、チームの中での意思決定を早く進められるようになりました。あわせて、少人数化を進めることによって施策における1人当たりの責任感が増すことになることで、施策における課題の定義の議論も徐々に活発になってきたように感じられます。
チーム間の協調
そもそもSpotifyモデル導入にあたって「もっとチーム間の協調を推し進めよう」という話をしていたという前提もありますが、「これはXXチームとやろうとしていることが似てるから、声をかけて一緒に進めよう」「XXチームが次の方向性を掘り下げようとしているみたいだから、話を聞きに行こう」のような会話が増えてきました。施策を進めるに上で、相乗効果を生み出すために、お互いに気を配る姿が見受けられます。
これらの効果の1つ1つはまだ小さいものではありますが、当初から期待している効果でした。継続的に取り組みを磨き込むことで、より高いレベルの「Alignment and Autonomyな組織」を目指したいと考えています。
新たな課題感
一方で、今回の取り組みを実施しても、また新たな課題感も感じています。
数字レベルでの成果
施策を遂行するスピードは上がってきていますが、まだまだ十分に数字レベルで目に見える効果が出てきているものは多くありません。より数字や効果の規模を意識した施策の進め方を考える必要がある、言い換えれば、Autonomyは高い状態になっているものの、施策の方向性についてのAlignmentはまだ高いレベルを目指す必要があると言えるでしょう。
もちろん、チームリーダーを含めて若いメンバーも多く、経験が十分に無いということもあると思いますが、同時にミッションに対して目指す方向性と高さについて、自分を含めてマネジメント側がメンバーと認識をもっと合わせていく必要があるでしょう。
開発そのもののスピード向上
作るものを決める、リリース計画を立てるなど、開発以外のマネジメントの観点において今回の取り組みによって開発のスピードの改善は進みました。 一方で、マネジメント以外での開発のスピード向上、つまり開発そのもののスピード向上については、今回の取り組みのスコープ外ではありますが、まだまだ工夫の余地があると考えています。
アプリ開発とWeb開発は当然、単純に比較することはできませんが、アイディアを形にしてユーザーに届けるまでに現状は大きな差があることは事実です。この点については、技術部など他部署を巻き込み、コードレビューや採用などいろんな観点で課題の整理と解決方法の模索をしているところです。スピードを上げることは同時に品質の問題も発生することになるので、なかなか難しいテーマですが、継続的に改善を目指していきたいです。
まとめ
規模が大きな組織において、意思決定のスピード向上や個人の成長を目指すために、Spotifyの開発モデルを自分たちなりに導入し、「Alignment and Autonomyな組織」を目指した経緯を述べました。背景として抱えていた課題感は少しづつ解決されてきたものもありますが、理想として目指したい状態とはまだまだギャップがあるのも事実です。
「組織は生きもの」と(2年前から同じことを)言いますが、組織のサイズもメンバーも常に変化し続ける中、同じ取り組みをし続けても効果はありません。課題に対して、常に最適なアプローチを考え、時には外部から適切な手段を導入するなど、トライし続ける必要があります。読者の皆さんの周りでも規模はともかく、組織的な課題感があると思いますが、本エントリがそのトライの手助けになると幸いです。
また、「もっと良い組織を目指せるんじゃないの？」と思ってもらえた方は、ぜひ一緒により良い組織作りを目指しましょう！)