Product Opsの取り組みに見る、変革期のストアーズの製品開発
こんにちは。宮里（@miyahirok）と申します。STORES 株式会社でプロダクトマネージャーをしております。
私事ですが、STORES（ストアーズ）に入社してから2年半と少しが経ちました。
ストアーズは今まさに大きな変革期を迎えており、私のミッションも長らく担当していた「STORES 予約」から変わり、現在は「プロダクトを横断した顧客データ基盤」のプロダクトマネジメント と「プロダクトを横断した組織運営の仕組みづくり」を担うプロダクト部門Ops室のマネジメントを担っています。
Ops室はいわゆる Product Ops の機能を担当し、「最高の製品をつくり、届けるためのプロダクト開発組織の仕組みづくりと運営」をミッションとしています。
ストアーズはそれぞれのプロダクトが単体でも大きな事業規模に成長しながらも、フロントオフィスの領域でコンパウンド戦略を推進するために、出自の異なる複数の製品を連携させるという難易度の高いプラットフォーム開発に投資をし、その成果が徐々に身を結びつつあります。
今回の記事では、その稀有なポジションにあるストアーズでの挑戦の機会の魅力と、変革期だからこそ生まれるカオスな現状と課題をお伝えしたく、ストアーズのプロダクト組織の現在地をProduct Opsの取り組みを振り返りつつご紹介できればと思います。
特に、
・ストアーズやフロントオフィス領域のプロダクトに興味がある方
・複数のプロダクトを横断したプロダクトマネジメントや共通基盤開発に興味がある方
・中長期的に腰を据えて挑戦できる機会を探している方
といった方に読んでいただけると嬉しいです。
以下の記事も合わせて参照ください。
Product Ops の立ち上げ
昨年（2023年）まではプロダクトごとの事業部門制となっていた組織体制でしたが、今年（2024年）から業種領域ごとのGoToMarketを担うビジネス部門と、全ての製品のプロダクトマネジメントを担うプロダクト部門に再編しました。
昨年までは事業部門ごとにプロダクトのロードマップの意思決定を行なっており、もちろん各部門で全社戦略・全社最適の観点は意識しつつも、特に横断テーマが急増する中で責任の所在が難しい構造にありました。
Product Ops の取り組みは、プロダクト型の開発からプラットフォーム型の開発に移行し、コンパウンド戦略を加速させるために、
・全社プロダクト戦略に紐づく検討アジェンダ・優先順位をどのように議論するか
・ロードマップとリソース配分・体制をどのように意思決定するか
・議論の進捗や意思決定のアウトプットをどのように可視化し共有するか
といったプロセスを整備・実行する必要性から立ち上がりました。
組織改編前の昨年夏頃から、当時はセカンダリー組織だったプロダクト部門として横断の会議体を整備し議論を開始したのですが、やはり意思決定プロセスは組織構造に規定されやすく、立ち上げ当初はなかなか横断した議論が難しい面があったと記憶しています。
そういった課題感もあった中で、上述の組織改編を行うことが決定し、プロダクト組織は独立部門化し、Product Ops も組織化して取り組むためにプロダクト部門にOps室という部署が新設されることとなりました。
新しい組織体制になるにあたり、改めてCPOやVPoPとともに急ピッチで会議体とロードマップの策定プロセスを再設計し、向こう半年のロードマップと開発体制を合意。バタバタの中で12月のプ会（※）にてメンバーへの全体共有を行いました。また、議論すべき検討アジェンダを洗い出したところリストの数が膨大になり、とてもカオスな状態で今年がスタートしたことを覚えています。
※プ会：プロダクト開発に関わる組織全員参加の会議。リンク先を参照。プ会も Product Opsの一環としてOps室が企画・運営をしています。
コミュニケーションツールとしてのロードマップの運用
プロダクトマネージャーは1つの組織に全員が集約する形となりましたが、実際の開発はエンジニア・デザイナーと共に「ユニット」という単位でチームを構成し、担当するプロダクトの開発と運営責任を担っています。
ユニット全体を統括する責任者であるユニットオーナー陣は毎週オフィスに集まり、ロードマップや横断するテーマを議論することで密に連携をとりながらそれぞれの開発を進めています。
プロダクトロードマップに関する議論は様々あり不要論も語られる昨今ですが、それでも組織横断のコミュニケーションをするための重要なツールとしてロードマップを位置付けて運用しています。
具体的には、これまでプロダクトごとに作成していたロードマップを一元化し、各ユニットが半年から1年先の開発テーマと優先順位に基づき機能レベルまで記載する運用としています。
社内外の様々な環境変化も多く、開発する機能ベースでロードマップをつくってもすぐに陳腐化してしまいますが、同時に複数のプロダクトと共通基盤を開発し連携を進めているため、全てのプロダクト・基盤についてどのタイミングで何の機能をどういったスコープで開発しようとしてるのか、本来共通化すべき機能を個別に開発しようとしていないかといったことまで密に連携を取る必要があります。
計画したロードマップの変更については、誰もが正しくタイムリーに変更の情報を取得できるようにするため、変更管理と情報展開のプロセスを設定しています。
こうしたプロダクト横断でのロードマップ運用と体制構築のプロセスはまだまだ練度を高める必要があるものの、変化に応じて重要なテーマに機動的かつ大胆なリソースアロケーションを行えるようになってきました。
｢戦略とは本質的にはリソース配分｣と言われることがありますが、組織体制の変更とその後のOpsの取り組みの効果が出てきていると感じています。
最も重要なユーザー理解への時間投資
Product Ops のテーマとしてもう一つ最重要課題として優先的に取り組んだのは、ミドル規模の事業者様のユーザー理解の向上です。
ストアーズのプロダクトは、個人事業主や1つの店舗を経営する事業者さまを中心に利用いただいていますが、複数の製品が連携し、提供できる価値や解決できる課題の幅や深さが大きくなってきたことで、規模の大きい事業者さまの導入が増えてきています。
一方で、例えば多くの店舗を展開する事業者様は既に基幹システムを利用していたり、本部と店舗のスタッフで異なるニーズを持っているなど、これまでとは違ったユーザー理解が必要になってきていました。しかし具体的にどんな業務課題や経営課題があり、どんなシステムやデータがどのように利用されているのかの解像度が組織としてまだまだ不足している状況です。
このような一定規模以上の事業者様を社内ではミドル事業者と定義し、プロダクト部門としてロードマップ開発の仮説検証とは別に、リサーチやインタビューを組織的に行い解像度を高めるディスカバリー活動に時間投資することを決めました。
全プロダクトマネージャーとプロダクトデザイナーを対象に、Ops室が音頭を取って仮説立案のためのワークショップを開催したり、業種ごとにチーム分けをしてリサーチやインタビューを行った結果を全体で発表する機会を設けるなど、徐々にナレッジが蓄積されつつあります。
セールスやCSなど直接の顧客接点を持たず、ともすれば目の前の諸々に忙殺されがちなプロダクト組織だからこそ、ストアーズの「オーナーさん（事業者様）から学ぶ」という文化を改めて醸成するための仕組みづくりは継続していきたいと考えています。
ストアーズのプロダクト組織の現在地
ロードマップ策定以外にも統合したいプロセスや、コンパウンド戦略を進めるためのアジェンダは山積しています。
やりたいことを挙げればきりがなくリソースも限られているため、特に重要なイシューに絞って解決のためのワーキンググループやプロジェクトを組成している状況です。
コンパウンド戦略を成功させるためには、提供価値と開発生産性を複利的に高めるプラットフォーム開発への積極投資と、マルチプロダクトを運営可能にする組織体制の構築が鍵となると言われています。
出自の異なる複数のプロダクトを連携させる開発自体が非常に難しく、それだけでも頭を悩ませているのですが、複数の製品を開発し複数のマーケットの事業者へ届けるというチャレンジは非常に変数が多く、組織づくりの難易度もとても高いということを実感しています。
全社横断の Product Ops としてはまだまだ取り組みを始めたばかりですが、これからプロダクトの数も2倍3倍に増やしていく予定であり、組織としてスケールするためのケーパビリティを高めていきたいと考えています。
そして仕組み云々の前にプロダクトマネージャーが全然足りません。エンジニアもデザイナーも足りません。。助けてください！
さいごに
フロントオフィスの領域でコンパウンド戦略に挑戦できる会社は数少なく、ストアーズは稀有なポジションにありますが、まだまだつくるべき共通基盤や新規プロダクトがたくさんあります。
人口減少、人手不足が叫ばれる世の中ですが、多くの資本体力を持つ会社だけが生き残れる社会ではなく、こだわりから生まれる多様な商品やサービスが溢れる街をつくること、その支援のための最高の製品づくりに一緒にチャレンジしていただける方を絶賛募集しています！
はじめましての方でもカジュアル面談などお気軽に @miyahirok までDMください。
旧知のみなさま、ご飯でも食べにいきましょう。
この記事が気に入ったらサポートをしてみませんか？