見出し画像

[導入編]10人から100人へ:組織拡大ためにプロダクトマネージャーがフォーカスすべきこと

こんにちは、株式会社ZealsにてBizDevをしている、おしみ(@_oshimin)です。

早速ですが、プロダクト組織のマネジメント・拡大って正直めっちゃむずかしくないですか?
組織は生き物だなぁと思うことが多々あるのですが、やっぱり複数人で一つの物事を進めていくというのは、1人で何かを進めることよりも抜群に難しいですよね。

プロダクトとなると、リリースはどうしていくのか、要件はどこにどういうフォーマットで書くのがベストなのか、どの粒度まで情報として書かないといけないのか、とはいえかっちりしすぎると効率性落ちるし。こういう悩みを抱えながら、日々プロダクトと向き合っているプロダクトマネージャーは少なくないと思います。

なので、自分の経験が幾許か誰かを助けられるのではないかと思い、自分がこれまでやってきた中で、実感してた人数規模ごとに異なる、プロダクトマネージャーが集中して取り組むべきこと、および、それを実現するために何を知っていないといけないか?について書いてみることにしました。
同じように開発組織の拡大を考えている方現在拡大の苦しみを乗り越えようとしている方の参考になれば嬉しいです。

また、前回のnoteでは、「デザイナーからプロダクトマネージャーになる時にぶつかった3つの壁」について書きましたが、その中の一つである「オペレーション」を作るために使える知識となります。もし読んでいない方いらしゃったらこちらも合わせて読んでいただけると嬉しいです🙇

本記事を読んで欲しい人

  • StartupにてCPO、CEOを兼務している方

  • PMとして開発をリードしている方

  • 開発組織をスケールさせて行きたいと考えている方

自己紹介

そもそも、おしみって誰なん?って方が多いと思うので、改めて自己紹介を。

  • 2014年: 大学2年の時にZEALSの立ち上げメンバーとして入社

    • 受託開発事業のセールス、デザイナー、ディレクターを担当

    • 自社ロボット、チャットボットプロダクトのプロダクトマネージャー兼デザイナーを担当

  • 2017年: 新卒としてDeNAに入社

    • マンガボックス、エブリスタ、Pocochaにて、UI/UX デザイナーを担当

    • Pocochaでは同時に、初期ユーザー定着を目標としたプロジェクトの企画も担当。

  • 2020年: ZEALSに再入社

    • プロダクトマネージャーとして、LINE MINIアプリ、RPAシステムや、チャットボットデザインの管理画面など複数機能をリード

    • VPoP (Vice President of Product)として、20人から100人へ組織拡大を進め、SAFeをベースにしたアジャイル(スクラム)開発オペレーション、組織の設計を実行

    • 現在はBizDevとして、事業拡大を支えるプロダクトの要件定義を担当

大事なことは「プロダクトオペレーションを、自社の状況に最適化して導入する」こと

自分は過去に少人数での0→1開発、複数チームでの1→10開発、大規模チームでのシングルプロダクトの0→1, 1→10, 10→100など様々な規模のチームでプロダクトマネージャーを担ってきました。

前提、プロダクトの目標は、事業KPIを達成していくことです。そのため、プロダクトマネージャーをやるには、プロダクトマネジメントトライアングルにある様なスキルが求められると言われています。

引用:https://tumada.medium.com/product-management-triangle-job-description-d18d1855ef65

ただ、ここにないもので一個めちゃくちゃ求められたなと実感していることが「プロダクトオペレーション」と言われるスキルです

なぜかというと、プロダクトマネジメントトライアングルは「正しい仕様」を書くために必要スキル群となっています。しかし、仕様はあくまで社内向けのものでしかなく、ユーザーが感じる「価値」にはなっていません。

開発しユーザーが使えるものにして初めて「価値」になります。書いた仕様をチームと協力してリリースできないのであれば、ただの絵に書いた餅です。
そうなった時に、大事なのが「プロダクトオペレーションを、自社の状況に最適化して導入する」ことです。

改めてになりますが、プロダクト組織の人数規模によってプロダクトマネジャーは仕様を書くだけではなく、変化をリードすることも求められます。
そして、どれだけスケールさせられるかどうかは、約33人名の組織サイズに至るまでに何を仕込んでおくかで、その後のスピードが変わります。

なぜなら、適切なアジャイルチームサイズは5~11人とされています。そのため、3チーム以上を同時に走らせ始めたあたりから苦しくなり、4チーム同時になるとお手上げ状態になります。
なんとかできないこともないのですが、それは属人的な状態であり後々に大きな負債を作っているので、それ以上へのスケールがどんどん苦しくなっていきます。

自分の経験上、プロダクトマネージャーがオペレーション観点でやるべきことは、ざっくり以下の3ステップがあります。

  1. Kanbanを活用しながらAgileマインドセットを組織の文化基盤の構築

  2. Agile Frameworkを活用したオペレーションの構築

  3. Scaling Agile Frameworkを活用したオペレーションの構築

これらを全て一つのnoteで書こうとすると、膨大になってしまうので、このnoteを導入編として、

  • 導入編

  • 小規模:11人以下のチーム

  • 中規模:12~24人のチーム

  • 大規模:24人以上のチーム

と、それぞれの組織規模のチームにおいてプロダクトマネジャーが向き合うべきことを4本のnoteに分けて書いていこうと思います。

プロダクトオペレーションとは?

すごーーーーーく簡単にいうと、Scrum Masterの責任範囲を拡張し、データ収集やツールの管理までのプロセス全てに責任を持ち、プロダクトマネージャーとともにプロダクトのグロースをさせていく役割になります。

Product Opsと呼ばれる職種があり、その職種がこのプロダクトオペレーションにミッションを持っています。
専門の職種があるほど重要な役割となっていますが、日本ではまだあまり馴染みがないものとなっています。なので、知らない方もいらっしゃると思います。以下の記事が参考になるので、ぜひ読んでみてください。

どうプロダクトオペレーションを、自社の状況に最適化していくのか?

ただ、スタートアップにおいて、そんなにリソースが潤沢な状態はなかなかありません。なので、プロダクトマネージャーとして、オペレーションのことも知っておくと、結果的にリスクを削減することができます。

オペレーションときいてパッと頭に浮かぶ言葉として、アジャイルやスクラム、ウォーターフォールなどがあるかと思います。ちゃんと説明すると、それだけで複数のnoteが書けてしまうので、ここでは簡単な概要と参考記事を紹介とさせていただきます。

Agileとは?

Image from:https://agilemanifesto.org/iso/ja/manifesto.html
  • 「ソフトウェア開発はこうすべき」という手順を規定するものではなく、コラボレーションワークフローについての考え方

  • 何をどのように作るかを決める指針となる価値観の集合のことを指す。

  • 一般的に各種フレームワークを活用して実行される。

なので、アジャイル(Agile)はあくまでも、アジャイル化を促進するフレームワークを使って管理していこうね、というマインドセットのようなもので、それ自体がフレームワークではありません。

また、最近のdigital.aiの調査では、以下の調査結果が出ています。

71% of survey takers use Agile in their software development lifecycle (SDLC).
調査対象者の71%が、ソフトウェア開発ライフサイクル(SDLC)でアジャイルを使用している。
Scrum continues to be the most popular team- level methodology: 63% of Agile users are team Scrum.
スクラムは63%が採用しており、チームレベルで最も人気のある方法論であり続けている。
The top benefits from using Agile? Improved collaboration and better alignment to the business.
アジャイルがもたらす最大のメリットとは?コラボレーションを改善し、ビジネスとの整合性を高める。
Engineering/R&D are the fastest growing adopters of Agile, up 16% over 2022.
エンジニアリング/研究開発部門は、アジャイルの採用者が最も急増しており、2022年比で16%増加している。

https://digital.ai/resource-center/analyst-reports/state-of-agile-report/
https://digital.ai/resource-center/analyst-reports/state-of-agile-report/

Just over 70% of survey takers report using Agile in their SDLC, while 42% said their organizations use a hybrid model
that includes Agile, DevOps, or other choices (respondents could choose all that apply to answer this question, which
is why the percentages add up to more than 100). To look at it a bit differently, the larger the organization, the more likely it is to use a hybrid model — 49% of large companies and 45% of medium-sized companies are doing so. Bigger teams are also more likely to still use Waterfall (31% of large and 38% of medium-sized).

調査対象者の70%強がSDLCでアジャイルを使用していると回答し、42%が彼らの組織はアジャイル、DevOps、またはその他の選択肢を含むハイブリッドモデルを使用していると回答した(回答者はこの質問に回答するために当てはまるものを全て選択することができ、これがパーセンテージが100以上になる理由である)。少し見方を変えると、組織が大きいほどハイブリッドモデルを使用する傾向が高く、大企業の49%、中堅企業の45%がハイブリッドモデルを使用している。また、大規模なチームほど、ウォーターフォールをいまだに使用している傾向が強い(大企業の31%、中堅企業の38%)。

https://digital.ai/resource-center/analyst-reports/state-of-agile-report/
https://digital.ai/resource-center/analyst-reports/state-of-agile-report/

Perhaps not surprisingly, the top two reasons organizations choose Agile (at 41% each) are broadly related to increasing business value: respondents were equally split between prioritizing delivery and measuring customer/business value and accelerating time to market. Other reasons to scale Agile in the enterprise include digital transformation at 34% and delivery predictability at 30%.
驚くことではないが、組織がアジャイルを選択する理由の上位2つ(それぞれ41%)は、ビジネス価値の向上に大きく関連している。回答者は、デリバリーの優先順位付けと顧客/ビジネス価値の測定、および市場投入までの時間の短縮の2つに等しく分かれていた。企業でアジャイルを拡大するその他の理由には、34%のデジタルトランスフォーメーションと30%のデリバリーの予測可能性が含まれる。

https://digital.ai/resource-center/analyst-reports/state-of-agile-report/

詳細については、ぜひ調査レポートを直接見てもらいたいですが、簡単にまとめると

  • アジャイル化の推進は引き続きされており、特にスクラムを用いての導入がメジャーとなっている

  • 組織規模が大きくなるにつれて、いくつかのフレームワークを混合して利用している

  • 導入理由のトップ2は、デリバリーの優先順位付けと顧客/ビジネス価値の測定、および市場投入までの時間の短縮であり、どちらもビジネス拡大するために紐づく

となっています。最新の17thの原本は英語なのですが、15thについて日本語で解説してくれているnoteがあるので、こちらもぜひ。

Scrumとは?

では、最も人気のあるアジャイルフレームワークとされているスクラムとは何なのでしょうか?

Image from:https://www.scrum.org/resources/blog/difference-between-scrumorg-professional-scrum-master-classes
  • チームベースで、プロダクトの開発を素早くかつ継続的に機能追加・改善を進めていくためのプロセスを実行するためのフレームワーク

  • 各チームはスプリントと言われてる一定期間の決まったサイクルを作り、その期間にて、チームで要件定義、開発、テスト、レビューを行う

正直、スクラムについては、多くの本や記事が転がっているので、それからインプットしてもらう方がいいかと思います。
自分が、最初にスクラムの導入を検討した時には下記の本を読んで実践してきました。

まとめ

プロダクトオペレーションは馴染みのない言葉かもしれませんが、プロダクトマネージャーとして、それにまつわる知識を持っていると、より効率的に物事を進めていけるようになります。
AgileやScrumについては書籍も充実しているので、ぜひ一冊でも手にとって読んでみてください。

冒頭にて、「プロダクトオペレーションを、自社の状況に最適化して導入する」が大事と言いましたが、digital.aiの調査にもあるように、規模が拡大するにつれて、ハイブリッド化していくとあります。
というのも、一社一社の経営資源が異なれば、最適な方法やツール、フローも変わってきます。また、どれくらいのリスクを許容できるのか、そういう部分でも変わってきます。

それでは、次回は「11人以下の小規模チームにおいて、プロダクトマネージャーがやるべきこと」として、

  • 実際に何をやっていくべきなのか、

  • どういう壁にぶつかるのか、

  • それを乗り越えるために何をするのか

などについてnoteを書いていきます。
書いたらXにもシェアするので、noteやX(@_oshimin)もフォローしてもらえると嬉しいです🙇

この記事が参加している募集

この記事が気に入ったらサポートをしてみませんか?