この記事はクラウドワークス アドベントカレンダー14日目の記事です。
クラウドソーシングサービス「クラウドワークス」(以下 crowdworks.jp)にてプロダクトオーナー(PO)をしておりますチャンタマです。
2年前のアドベントカレンダーで「サービスの成長モデルを定義し、「森も見ながら木を見る」プロダクトマネジメントへ」という記事を投稿しましたが、その頃からまた弊社のプロダクトマネジメント環境も変わってきました。
今回は、ある程度プロダクトマネジメントのプロセスが確立してきた中で、改めてPOの役割とは?を考え直してみた話をしたいと思います。
目次
なぜやろうと思ったのか
結論から言うと以下の2つだったかなと思います。
1. なんかPO忙しすぎん…?というモヤモヤ
ryuzeeさんの記事「プロダクトオーナーのアンチパターン」で一番最初に出てくる程度には重要なアンチパターンだと理解はしていても、POあるあるですよね…
やるべきことができてるのか?逆にやらなくてもいいことをやってないか?ということを考え始めると、必然的に「やるべきこと」とは何なのかを定義する必要が出てきます。
2. POメンバーが増えた!
嬉しいことに、この1年で3人のPOメンバーが増えました!!!!!わーい (余談ですが、そのうちの1人の@e-takazawaさんもアドベントカレンダーの記事を書いてくれています!ぜひご一読ください)
3人ともPOとしてのバックグラウンドは無いため、POのやるべきことが何かを伝えていく必要がある一方で、そもそも元からいるPOたちの間での認識も揃っていないのでは、という話になり考え直しの機運が高まったのでした。
何をやったのか
前提:crowdworks.jpにおけるPOの2つの顔
まず前提として、開発組織構造の説明をしておきます。
crowdworks.jpでは、PO・エンジニア・デザイナーが属するチームを1チームとし、各チームがそれぞれミッションを持って開発をおこなっています。 (チームによってはPOがいなかったり、デザイナーが兼任していたりしますが、詳細は割愛します)
一方で、POはプロダクトマネジメントグループ(以下PMG)、エンジニアはプラットフォーム開発グループ、デザイナーはデザイングループとして組織上所属しています。 いわゆるマトリックス型組織です。 PMG組織の最終意思決定者としてPdMが存在しています。
したがって、crowdworks.jpのPOは2つの顔を持つことになります。
- PMG組織の一員としてのPO
- 開発チームにおけるPO
開発チームにおけるPOは、スクラムにおけるPOをイメージするとよいと思います。わかりやすいですね。 自チームのミッションだけでなくcrowdworks.jp全体のミッション、業績目標なども意識して活動をしているときは、PMG組織の一員としてのPOの顔になります。
現在では、POの中でもより経験を積み複数組織にまたがる取り組みができるメンバーをシニアPO(SPO)、自身の担当領域・担当チームについては任せることができるメンバーをPO、POになりたてのメンバーをアシスタントPO(APO)と呼んでいます。
APOの間は主に「開発チームにおけるPO」の顔が中心で、徐々に経験を積みSPOに近づいてくると「PMG組織の一員としてのPO」の顔も出てくるようになる、といったイメージでしょうか。 (この、2つの顔を持つ”兼任”状態が本当に良いのかどうかは議論が生まれるところかもしれませんが…)
やったこと①「PMG組織におけるPO」としてやるべきことを洗い出し、コア/ノンコアを整理
- やった人:PdM+SPO3人
まずは、プロダクトマネジメントトライアングルなども参考にしながら、PMG組織としてやるべきことをFigmaで洗い出しました。 ここでは、今やっていることに捉われず全部洗い出すことを意識しました。 「やってないけど本当はやるべきだよね」と思うものもテーブルに出したことで、参加者全員で議論し認識を揃えられたと思っています。
その後コア/ノンコア1を分類していきます。 一つの「やるべきこと」に対してコア/ノンコアが分けられる時はカードを分割しました。
例)
コア:組織編成、人員配置の提案
ノンコア:組織編成・人員配置の意思決定
→人員配置の決定権限はPOにはないものの、その提案はPOが積極的にすべきだろう、ということで明示的に分けた
実際の作業内容はお見せできませんが、おおむね以下のように整理しました。
(顧客/ビジネス/サービス品質/チームマネジメントという大枠の分類に関しては、抜け漏れなく考えやすくするために行っただけなので、分類が妥当かどうかはあまり議論してません。参考程度にとどめてください)
やったこと②「開発チームにおけるPO」としてやるべきことを洗い出し、コア/ノンコアを整理
- やった人:PdM+SPO3人
もともと①のみで終えるつもりでしたが、やはり日々の業務量でいうと開発チームにおける活動の比重が多いため、「開発チームにおけるPO」としての内容も整理することにしました。
こちらもプロセスは同様に、Figmaで洗い出し、コア/ノンコアを整理していきます。
また、この際「開発チームにおけるPO」としてのコアの中でも、SPO/APOそれぞれの観点も含めて分類、整理しました。
実際にはもっとカードはありましたが、おおむね以下のようなイメージでしょうか。
これによって、SPO/PO/APOという概念が整理され、参加者全員の認識が揃いました。 (後述しますがこの内容の詳細はまだAPOメンバーとは議論できていないので、そのうちやらねば…)
現在ではSPO+APOの2人1組で1チームを担当し日々の業務を行なっています。
やったこと③PMGステートメントを作る
- やった人:PdM+SPO3人+APO3人(=PMG組織全員!)
①、②を経て細かい業務に関しては整理できたものの、ミッションビジョンのような立ち返る場所が必要なのでは無いかという議論が起こりました。
結局自分たちは何をする人で、何を大事にするのか、の認識が揃っていないと、”細かい業務” の中での優先度の認識もバラバラになってしまいますよね。
こちらに関しては、PMGメンバー全員で以下のアジェンダで議論しました。
1. 自分はなぜここにいるのか:個人としてのWhy
次にやる「我々はなぜここにいるのか」に向けての、頭の体操的なアジェンダです。 なぜクラウドワークスにいるのか、なぜ(他の職種ではなく)POをやっているのか、といった切り口を例に挙げて各自付箋に書いて出していきました。
2. 我々はなぜここにいるのか:チームとしてのWhy
「プロダクトの価値を最大化する」が一般的に言われているPOのミッション → プロダクトの価値を最大化するとはどういうこと? を切り口に、我々がなぜここにいるのかを各自考えて付箋に書いた上で、共有していきました。
その後、「PMGは「プロダクトの価値を最大化する」すなわち....」という仮の書き出しをベースにして、最終的なステートメントに落とし込んでいきます。
この場では綺麗なステートメントにはまとめられなかったので、ステートメントに盛り込む内容の認識が揃った段階で終えて、後日ひとりのSPOが最終アウトプットとして整理しました。
3. 自分はそのために何をしたいか
ステートメントを踏まえて、今後何を意識/行動/実行していきたいか、各自の思いを出してもらいました。
前の議論が白熱して時間が足りなかったこともあり、共有だけにとどめましたが、ユーザーリサーチなどは全員が触れていたりして、一人ひとりの認識が揃ったいい会だったと思います。
これからどうしていくのか
今後やっていかなければならないと考えているのは、主に以下の3点です。
- PMGステートメントに基づいて①「PMG組織におけるPO」としてやるべきこと②「開発チームにおけるPO」としてやるべきことを見たときに、①と②はその内容で良いのか?という検討
- ①②についてはSPOでは認識揃ったけど、APO含めた全員ではまだちゃんと話せていないため、その議論と認識合わせ
- エンジニアやデザイナー、マーケターに対しても同じ擦り合わせの実施
- イメージとしては、「POはhogeに集中したいから、代わりにfugaはお願いしたいんだけどどうですか?」といった議論。逆パターンの議論ももちろんありそう。
「プロダクトマネジメント」は一度定義して終わりじゃない
今回の経験を通じて個人的に感じたのは、「プロダクトマネジメント」は一度定義して終わりじゃない、ということです。
数年前にもプロダクトマネジメントプロセスについて考え、整備していた時期もありましたが、メンバーが変わり、組織も変わり、自分自身の役割も変わる中で、過去に定義したものがうやむやになっていました。
また、プロダクトマネジメントのスタイルは各組織やプロダクトの性質・フェーズなどによっても向き不向きが生じると思うので、「この会社のやり方を真似たら解決する」とはなりませんよね。
正解のプロダクトマネジメントにしていく、というよりも、その時々の状況に合わせた最適解を見つけていくことが重要なんだろうなと思うと、改めてアジャイルって開発じゃなく組織作りの場でも必要だよなとしみじみ感じた2022年でした。
最後に、クラウドワークスでは様々な仲間を募集しております。 ご興味のある方は以下のリンクからご応募ください! https://crowdworks.co.jp/careers/
-
コア/ノンコアの基準
コア=POも実務やる、ノンコア=POじゃないメンバーが実務をやってもよいはず(できる人がいなければPOがその実務をやることもありうる)という説明が一番近いでしょうか。
POはプロダクト価値最大化に責任を持ちますが、それゆえに「なんでも屋」になりやすいです。
最大化につながるすべてのことが責任範囲になってしまうからです。
crowdworks.jpのSPOメンバーの中でも、あらゆることが責任範囲になることについてはおおむね合意していました。
とはいえ専門家がいるなら、専門家に任せたほうがいいこともあるはずです。
そういった観点も踏まえ、より「PO以外にやるべき人はいないだろう」というものがコアに入ってくるよう分類をしていきました。↩