Groovesが目指すプロダクトエンジニア組織について

組織

こんにちは！GroovesでCrowd Agent開発チームのエンジニアリングマネージャーをしています、とりい(@hirot_san)です。

皆様はプロダクトエンジニアというロールをご存知でしょうか。 Product Engineering Night (旧Product Engineer Night)というコミュニティイベントも開催されており、その中ではプロダクトエンジニアについて以下のように説明されています。

Product Engineering Night はプロダクト志向を持つエンジニアたちが集まり、知識と経験を共有し互いに学び、議論を深める場を創ることを目的としています。

「Product Engineer」という新しい職種を定義する企業が国内外で出始めており、技術中心のエンジニアリングから一歩進み、プロダクトの価値を中心に据えたエンジニアリングへと進化する動きが出ています。プロダクト開発はその不確実性が特徴であり、単一の知識や手法だけでは価値を生み出すことは難しい総合戦とされる領域です。多様な知見と視点を持つことがプロダクト価値追求には欠かせません。

プロダクトエンジニアに関する note はこちら（https://note.com/niwa_takeru/n/n0ae4acf2964d）

私も都合がつく際にはこちらのイベントへ参加し、プロダクトエンジニアリングについての学びや議論を楽しんでいます。 2月の話にはなるのですが本コミュニティで、「プロダクトエンジニア構想を立ち上げ、プロダクト志向な組織への成長を続けている話」というタイトルでLT(ライトニングトーク)を発表させていただく機会にも恵まれました！

speakerdeck.com

スライドの内容も踏まえて、この記事ではGroovesのCrowd Agent開発組織が目指すプロダクトエンジニア組織像について説明できればと考えています。

背景

Crowd Agentは10年来続くWebアプリケーションであり、ビジネスを進める上で組織としての役割分担が良くも悪くも明確になっています。SalesやCSがユーザーとの接点を多く持つ一方で、プロダクト開発組織はユーザーの声やドメイン知識を深める機会が構造的に限られていました。さらに、開発組織内でもプロダクトマネージャー(PdM)、プロダクトデザイナー(PD)のロールが機能しており、エンジニア自体はユーザーとの関わりから遠いポジションでありました。プロダクト開発を介してユーザーに価値を届けたいという志向を持つエンジニアが多くいながらも、プロダクトに対するオーナーシップやモチベーションがなかなか醸成されにくい構造だと言えます。Groovesの行動指針である「ユーザーへの提供価値にこだわる」という観点から見ても、開発組織としては停滞感に直面していました。

目指す姿

停滞感を乗り越えるためにも、プロダクト開発組織が目指すべき姿として以下2つの事項を定め、ここに向かって成長するためにプロダクトエンジニアの考え方や要素を組織に取り入れることを考えました。 既存のエンジニアをプロダクトエンジニアに変えることが目的ではなく、組織として目指すべき姿へ成長していくためにお互いがカバーできる要素を取り入れてみようというのが趣旨になります。

  • ユーザー価値を素早く提供し続けられる

  • ユーザーへの提供価値の質を高められる

違和感なく組織へ導入するために、MVVや行動指針とのつながりを整理したのが以下図になります。

MVVと目指すべき組織像との関係性

追求するエッセンスの項目がチーム単位、個人単位で発揮できるほど大きなアウトカムが創出できると考えています。

  • オーナーシップ

  • 顧客理解・ドメイン理解

  • 仮説検証と機能開発のスピード

一方で組織として必要なベースも整えていくことで、プロダクト志向に必要なエッセンスが組織全体へより速く浸透し、これを維持できると考えています。

  • ビジョン、事業KPI、ロードマップなど方向性を言語化／可視化し伝える

  • 仕組み(プロセスやテンプレート)の整備

  • 文化の醸成

これまでの取り組み

目指す姿が抽象的な話だったので、ここでは具体的な取り組みについて代表的なものを紹介させてください。

  • プロダクトをさわる会の実施

    • いわゆるドッグフーディングとして、自社プロダクトをロールプレイングしながら操作してみる会を実施しました。Crowd AgentはBtoBのプロダクトになるので、採用企業側や紹介会社側それぞれの立場でプロダクトを操作するのは新鮮な機会となり、プロダクトに対して気になる改善ポイントが多く出てきました。UXを学ぶために他プロダクトもさわってみたいというアイデアも新たに生まれています。

ドッグフーディングでの感想

  • 顧客理解を高める資料や情報を集めたページの作成と共有

    • 元々社内でクローズドにあったVoC(Voice of Customer)チャンネルを全員が見れるようにしたり、ユーザーインタビューの動画をNotebookLMで要約し、それらをNotionへ集約したりと情報収集しやすい環境を作ろうとしています。

  • プロジェクト単位でのリードエンジニアの設置

    • 私達はプロジェクト推進において、仮説検証(ディスカバリー)トラックと開発(デリバリー)トラックそれぞれでアジャイルな状態でサイクルを回しています。エンジニアが仮説検証フェーズにおいても、技術的な観点での事前フォローや仕様改善提案を積極的に、PdMやPD、Bizメンバーと行える構造を作るためにリードエンジニアを設置しています。リードエンジニアは毎回固定のメンバーではなく、プロジェクトごとに挙手制など担当メンバーを調整するようにしています。

成果

まだまだ取り組みは道半ばで成長途中の組織ではあるのですが、定性面・定量面での取り組み成果が出ています。
※ただしプロダクトエンジニア構想の施策だけが要因ではなく、毎スプリントでのレトロスペクティブなどでチームが継続的に改善を繰り返してきたからの成果と言えます。

  • 定性面：チームに対して行っている定期アンケートの項目、例えば「最近の業務にやりがいを感じる」のチーム平均は継続的に増加し維持傾向にあります。 (定期アンケートの運用については以下の記事に詳細を記載しております)

zenn.dev

  • 定量面：具体的な数値を公開できなくて恐縮なのですが、デプロイ頻度やPR作成からマージまでのリードタイムは改善傾向へ進んでいます。

これからの課題

目指すべき組織の姿である「ユーザー価値を素早く提供し続けられる」「ユーザーへの提供価値の質を高められる」に対し、足元の方向性として以下を考えています。

  • 顧客理解やオーナーシップをさらに高めた先でより自律的な判断が行えるチームを目指したい

    • チームが自律的に活動するうえで、エンジニア、PM、UX、Sales、CSなど事業に関わる幅広い視点を持つことで納得感のある全体最適な意思決定ができると考えています。それと顧客理解が合わさることで、より質の高い価値提供が行えると信じています。もちろんエンジニアであれば開発業務を軸として、顧客理解や多角的な視点を磨く活動とのバランスを都度考える必要がある認識です。

  • プロダクトや開発に対しての広範なアイデアをもっと取り上げられる環境を目指したい

    • たくさんのアイデアを比較検討したり、そういった議論に参画している感覚というのがまだまだ道半ばなように感じています。多くの人がリスクを感じることなく、アイデアを比較検討できたり議論が行えることで、(上の項目と合流するのですが) 多角的な判断を通したアイデアが生まれ、より質の高い価値提供が行えると考えています。ユーザー価値を提供し続けるという持続可能性を担保する観点でも重要な認識です。

方向性のため抽象的な記載となっていますが、具体についてはチームメンバーとも話し合いながら今後の実践につなげていきたいと考えています。