こんにちは。藤井 @yoshiyoshifujii です。
当記事は、 Chatwork Advent Calendar 2021 6日目です🎅 🦌 🎄 🎂
2021年4月から、とあるスクラムチームのプロダクトオーナーを担当させていただくこととなり、8ヶ月ほど経ちますので、これまでやってきたことを書こうと思います。
これからプロダクトオーナーをご担当されようとされている方、今まさしくご担当されている方の、何らかのご参考になる部分がありますと幸いです。
プロダクトオーナーとは
スクラムガイドから引用いたします。
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化すること の結果に責任を持つ。組織・スクラムチーム・個⼈によって、その⽅法はさまざまである。 プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。たとえば、
- プロダクトゴールを策定し、明⽰的に伝える。
- プロダクトバックログアイテムを作成し、明確に伝える。
- プロダクトバックログアイテムを並び替える。
- プロダクトバックログに透明性があり、⾒える化され、理解されるようにする。
上記の作業は、プロダクトオーナーが⾏うこともできるが、他の⼈に委任することもできる。 いずれの場合も、最終的な責任はプロダクトオーナーが持つ。 プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重し なければならない。これらの決定は、プロダクトバックログの内容や並び順、およびスプリン トレビューでの検査可能なインクリメントによって⾒える化される。 プロダクトオーナーは 1 ⼈の⼈間であり、委員会ではない。プロダクトオーナーは、多くのス テークホルダーのニーズをプロダクトバックログで表している場合がある。ステークホルダー がプロダクトバックログを変更したいときは、プロダクトオーナーを説得する。
このあたりを読んで思うこととしては…
プロダクトの価値を最大化することの結果に責任を持つ とか、 他の人に委任しても最終的な責任は持つ とかのあたり。
この 責任を持つ ために、プロダクトオーナーはどういう振る舞いをするか…
きっと、その人の能力、与えられる権限、スクラムチームメンバーとの関係性、開発者の能力、扱うプロダクトの特性、組織の文化などの状態によって変わってくるだろうと考えています。
完全に人にお任せして責任だけ取れますよ、って場合もあれば、すべてをコマンドコントロールしないと責任を持てません、って場合もあるのかなーと。
ぱっと思いついた2軸を雑に書くとこんな感じですかね。
その中で、自分は、どのあたりを任せて、どのあたりをコントロールするのか。
それは、プロダクト開発の 仮説、仮説検証、要件、仕様、設計、実装、テスト などのどのあたりまでプロダクトオーナーとして関わって、開発者にどのあたりをやっていただくのか。
このあたりの合意形成と、ベターな境界を経験学習し、イテレーティブにアプローチしていくのだろう。
プロダクトマネージャーとの違い
弊社では、プロダクトマネージャーをキャリア採用しており、プロダクトマネジメント部がございます。
よく、「プロダクトマネージャーとプロダクトオーナーの違いは？」となるかと思うのですが、弊社でもそのあたりを明確にしようと、取り組んでおります。
書籍「プロダクトマネジメント」から引用いたします。
プロダクトマネジメントは、あなたがチームで果たす役割だけでなく、キャリアです。 プロダクトマネージャーはビジネスと顧客の両方を深く理解し、価値を生み出す適切な機会を見極めます。 ユーザー分析や顧客フィードバック、マーケット調査、ステークホルダーの意見などのさまざまなデータを組み合わせて、チームがどんな方向に進んでいくのかを決定する責任があります。 なぜそのプロダクトを作っているのか、どんなアウトカムを生み出すのかといった点をチームが忘れないようにするのもプロダクトマネージャーの仕事です。
このあたりを読んで思うこととしては、プロダクトオーナーと同じことを書いているような気がするなーと。
ただ、 役割だけでなくキャリア というところが重要だなーと思います。
- プロダクトマネージャーは、キャリアなので、スクラムをしてようがしてなかろうが、これらを実施していくんだということ
- プロダクトオーナーは、スクラムにおける役割なので、スクラムをしているうえで、これらを実施していくんだろうということ
そこが違うところだなーと。
ということで、弊社では、原則として、プロダクトマネージャーを採用し、プロダクトマネジメントを遂行するプロダクトを、スクラムで開発するんだとしたら、プロダクトオーナーを担当するだろう、というあたりに違いを置いております。
とはいえ、弊社で扱うプロダクトは、技術的な側面を無視することができず、1人の人格でプロダクトマネジメントをしていくことの困難さがあり、一部のチームでは、プロダクトマネージャーではなく、開発者やマネージャーがプロダクトオーナーを担当することもあります。
かくいう私も、プロダクトマネージャーではありませんが、プロダクトオーナーを担当しているという状態であります。
わたしが取り組んでいるプロダクト
今年は、 Chatwork Dev Day 2021 なる催しをしておりまして、そちらで、CTOの春日が紹介しておりました サーバーアプリケーションの刷新が必要なフェーズ におきまして、まさしくこの刷新に取り組んでおります。
かとじゅんが発表しておりました ChatworkDevDay_リアクティブシステムと次世代基盤について_加藤 - Speaker Deck や、私もパネラーとしてお話させていただきました 急拡大する組織のためのスクラム・フレームワークを考える - Speaker Deck でも、紹介させていただいております。
Chatworkは、リリースしてから今年で10年。
その間、何段階かリアーキテクティングを実施してきましたが、基本的な構造思想は変えずに継ぎ足してきております。
原則モノリシックな構造を変えることができておらず、組織の構造を変えて生産性を向上しようと取り組むも、根本の構造は変わっていませんので、無理が生じます。
事業の変化に合わせて、生産性を維持・向上できるプロダクトと組織を構築することをゴールに見据えて、取り組んでおります。
わたしがプロダクトオーナーとしてやっていること
目指すゴールは、ビジネスや顧客に間接的に価値を提供する、どちらかというと技術的な要素が強い取り組みとなっています。
ステークホルダーは、社内のエンジニア、デザイナー、プロダクトマネージャーといった方々となります。
顧客に価値を届けるための最短コースを取れるよう、組織とプロダクトの構造とプロセスを模索しながら、現行の外部仕様を基本踏襲しつつ進めていく形になります。
とはいえ、仕様バグをそのままインプットすると、アウトプットも仕様バグになります。
このあたりを見直しつつ、キレイな仕様バグを高速に作る出すことなど無いよう、顧客と調整させていただくことが必要です。
技術的な視座からボトムアップに登りつつ、全体的な理想とする構造に近付けつつ、顧客への影響を調整する、そんなバランス感覚が問われています。
実際には、既存仕様をあらゆるソースコード、ドキュメントを読みまくり、プロダクトを触りまくり、顧客に届けているプロダクトの本質を掘り起こし、言語化して、そこからプロダクトバックログへと起し、理想とする構造と、組織の形を描いて、アーキテクチャを思案し、それをプロダクトバックログに起し、といったことをしています。
その中で、以前紹介させていただいた、LSPO研修を受けたテクニックを駆使して、 リリース計画をし、スクラムイベントに取り組むといった感じです。
現行仕様を把握したうえで、どのように登っていくかは、User Story Mappingの形式で合意形成をしています。
Tシャツサイズ で見積りをして、換算を駆使して、全体を見積ります。
換算で見積っているエピックは、リファインメントで徐々に見積りを入れていきます。
ある程度、エピックを達成するのに必要なストーリーの見積りができたら、換算から見積り直した数値に置き換えます。
スプリントが経過するごとに、見積りが精緻になっていき、上下します。
実績も積み上がっていきますので、Velocityも上下します。
プロダクトオーナーとして、得たい価値に対して、アウトプットの量を減らすことができないか、開発者のアウトプットを元にステークホルダーと調整します。
わたしの役割としては、スコープを最小にすることができないか。少ないアウトプットで最大の価値を出すことができないか。常にそれを模索することになります。
わたしの成果は、バーンアップチャートの青い見積りの線が下がって、狙っているアウトカムを得ることだと考えています。
開発者には、黄色の実績を積み上げて、Velocityを向上させ、緑の線が青い線になるたけ早く達成できるよう取り組んでいただきたいです。
そこに集中できるよう、迷わず取り組めるよう、プロダクトバックログを調整していくことが必要だと考えています。
将来的にどうなっていくのか
いまは、ひたすらに、技術的な視座からアプローチしつつ、Scrum@Scaleの1スクラムにおいて、プロダクトオーナーとして取り組んでいます。
この先は、プロダクトマネジメント部が取り組んでいる Product Operations と合流して、ビジネス、顧客、技術のバランスを取りつつ優先順位を決めて、高速に生産し続けられるプロダクトと組織にしていきたいと考えております。
そのときは、プロダクトマネージャーがプロダクトオーナーをする体制になっていると良いなーと思いつつ、じゃあ私もプロダクトマネージャーにキャリアを置いてプロダクトオーナーを続けるのかという選択肢もあるのかなーとか思いますが、とはいえ、エンジニアに主体を置きたいと思うところもあったりして、でもどっちも中途半端になるのもあれだなーと思いつつ…とはいえ、いまはこの役割を牽引していくことが大事と考えていたり…という感じではあります。
まとめ
- 2021年4月から、Chatworkをリライトするプロダクトにおいて、Scrum@Scaleを実践しており、1つのスクラムチームのプロダクトオーナーを8ヶ月やっているよ
- 技術的な要素が強いのもありエンジニア出身者がプロダクトオーナーをやっているよ
- いまは基盤造り。この先はビジネス、顧客、技術のバランスを取って高速に生産し続けられるプロダクトと組織に変えていくよ
ということでした。
