Press "Enter" to skip to content

3-15 Product Ownerという職

Scrumでビジネスとエンジニアリングをつなぐ役割を担うProduct Owner。その実際の業務について、Product Ownerを担われている方のインタビュー記事を参考にしながら話しています。

0:13 リクエストありがとうございます、1:28 職種としてのProduct Owner、3:42 atama plus、5:47 Product Owner、11:20 注力点、16:35 苦労

リクエストありがとうございます!

  • リスナーさんからリクエストをいただきました。MIT SDMのほか、慶應義塾大学大学院システムデザイン・マネジメント学会 (慶応SDM) にもご興味があるとのことで、私どものネットワークを辿ってなんとか慶応SDM生にインタビューなどできないか探ってみます。
  • 取り上げてほしい話題やトピックなどありましたらTwitterやe-mailでご連絡ください!

職種としてのProduct Onwer

  • マサトは前職でProduct Onwerチームのメンバを担当していました。
  • Scrumを前提とし、Product OwnerをJobとして位置付けるStartupも増えてきています。またBigTechをはじめとして、アメリカではProduct Managerが人気の職種です。

atama plus

Product Ownerの仕事

atama plusの林田さんへのインタビュー記事 https://blog.allstarsaas.com/posts/atamaplus-product を参考にして、Product Ownerの具体的な仕事を見ていきたいと思います。

まずProduct Ownerの役割は「プロダクトを通じて事業を前進させる」こと、とのこと。具体的なタスクは以下とのことです:

  • 3か月ごとのObjectives & Key Resultsを設定する <= Scrumでの「リリース計画、vision明示と共有」
  • 今週の機能開発内容を決める <= Scrumでの「Sprint Planning」
  • 開発の前提となる検証を決める <= Scrumでの「完成」の定義
  • チーム活動での良かった点他を振り返るレトロスペクティブを行う <= Scrumでの「Retrospective」
  • チーム活動への伴奏、チームの壁打ち相手となる <= Scrumでの「Visionの共有」に類似。一部Scrum Masterの役割も担われているように見えます。
  • 打ち手の有効性を確認する <= Scrumでの「検査」

マサトの経験でも、振り返りは意識して時間を取らないと上手くいかない、またフレームワークがきちんとしていると振り返りがスムーズになる、という印象です。例えば、意図していないプロダクトが出てきたときになぜそうなったか、と振り返ると、そもそも課題感がずれていたことが原因だったことがありました。このずれを初期段階で修正できたことは、Scrumを用いていたことの良かった点でした。

注力点

  • 解決すべき課題の特定をとても重視されている。そのためにプロダクトが使われている現場に何度も足を運ばれている。
  • ペルソナと現実の差分を常に確認されている。

苦労

  • 変数が多く予想がつかない、見通しが立てづらい、とのことです。目指したい方向とずれることもあるとのことです。
  • 譲らない点を明確にすることや、会社の戦略を明文化して共有することを重要視されているとのことです。

Product Owner、Product Managerはその役割になってから学ぶことが多いと仰っています。「今まで培ってきたもの」を武器として役割を担っていくのがよいのではないか、というアドバイスをなされています。

Comments are closed, but trackbacks and pingbacks are open.