はじめに
スタンバイではスクラムを取り入れてプロダクトの開発を行っています。
本記事では、スクラム開発の役割の1つである「Product Owner(PO)」と、会社組織としての役割である「Manager」という種類の異なる役割の交差点について記載してみたいと思います。
スタンバイの開発組織と会社組織の話
スタンバイの開発は、UI,求人,検索,広告など領域によりスクラムチームを組成して開発をしています。
それぞれのスクラムチームにはPOと開発メンバーが役割として存在し、スプリントでの開発を進めています。
一方で、会社組織としては上述の領域ごとにManagerが役割として存在します。
それぞれの役割定義としては以下のように定めています。
| 役割 | 概要 |
|---|---|
| Product Owner(PO) | 担当プロダクトの開発・運用の実行責任者として、担当領域のROI最大化を図る。 ・ 担当プロダクトが受け持つ目標とする状態の達成に責任を持つ。また、スタンバイプロダクトの全体最適を実現するために、部長や他グループPOとグループ内で洗い出した課題や状況の共有/議論等の連携を行う。 ・定められたロードマップを遂行し、最大の成果を実現するためにチーム開発における最適な業務プロセスを決定する。 |
| Manager | 所属メンバーの育成・評価・労務管理・キャリア構築に責任を持つ。 【組織マネジメント】 ・事業目標を達成するために、担当組織におけるパフォーマンスの最大化及びグループの成長を実現する。 【ピープルマネジメント】 ・会社の定めるルールに従って所属メンバーの育成・評価・労務管理を行い、キャリア構築を支援する。 |
スタンバイの開発組織において、この２つの役割は別の定義がされていますが、組織編成の都合上、同一人物が務める場合があります。
PO と Manager の役割を同時行う上でのチームビルディング
POがロードマップを推進していくにあたり、チームパフォーマンスを最大化していくことも必要になります。
一方で、プロジェクトなどへのメンバーのアサインはManagerが担います。
チームパフォーマンスが最大化され、ロードマップの推進、プロダクト成長へ寄与することになります。
個人が成長することでさらに効果が大きくなります。
切っても切れない関係のため、同一人物が行うことがメリットになることも多いです。
ただし、1人の人間のリソースの限界があるため、その時その時の状況によって最適な形は異なると思います。
ゼロからのチームビルディングでのPO , Manager の動き方
上記に 「その時その時の状況によって最適な形は異なる」 と記載しました。
僕自身が携わったチームのことを少し紹介します。
チーム創生期
僕自身は、まさにPO と Manager の役割を同一人物が努めているパターンです。
約2年前、プロダクトは存在するがメンバーはほとんどまっさらな状態からチームビルディングがはじまりました。
まっさらというのは、チームが人事異動などの関係でその領域のナレッジや経験のないメンバーが大半を占める状態です。
この状態の時は、ロードマップも重要なのですが、『まずチームとして立ち上がり開発活動ができる状態にする』 ことが重要なポイントでした。
まず開発活動ですが、プロダクト組織としてスクラム開発を前提としていますが、イベントなどの枠組みはありつつも中身は各チームに任せられているような形となります。
つまり、チームで決めていく必要があります。
POとしては、担当領域における 『対象ユーザーとそのユーザーにまずはどのような価値を提供していくべきか』 について整理していきました。
この整理の過程においても、チーム全員を巻き込んで議論、ビジネス関連部門とのコミュニケーションなども行いながら進めました。
ここで全員を巻き込むのは、ゼロからのチーム作りにおいてとても重要な要素です。
どのような組織においても誰もがフラットな状態はなかなかないのですが、このときのチームはそのフラットな状態から意見を出し、集約し、決定していく、ということを行うことができました。
このプロセス自体がチームビルディングの一環となります。
一方、サービスの運用やプロダクトロードマップで期日が定められている 「必ず実行する開発」 については、POとしてプロダクトマネジメントしつつ、スクラムチームのビルディングをしながらも進めていく必要があります。
この 「必ず実行する開発」 においては、開発が発生する上ではWorkingAgreementなどのチーム合意事項や、開発進捗マネジメント、品質管理の仕組みなど、スクラム活動の中で定めていきます。
チームは足場も固まらない中、どんどん決めたり、進めたり、大忙しです。
ただ、チームメンバー全員が、チームがどのような状況であるかを理解し、自分たちは何をやるべきか、を常に考えて動くことで、大変ながらも一体感が生まれてくるものです。
このようなことを1年続けながら進めていくと、素晴らしいチームが出来上がりました！
ここまででManagerが出てきていないのですが、これらの活動が円滑に進むように工夫したり、個々のメンバーとの対話から改善へ進めたり、大変な中でも 『個人が成長できる環境を整える』 という、プロダクト開発とは少し別角度でチームビルディングを進めていきました。
チームチェンジ期
2年目になる時に人事異動などもあり、なんと1年一緒にやってきたチームの半数が入れ替わることになります。
「もう一度チームビルディングか」
「去年やったことをやれば大丈夫か」
など考えてはじまりました。
ゼロから進めてきたメンバーと新しい仲間の融合です。
最初に躓いたところがあります。
1年間進めてきたことで、素晴らしいチームとなりました。
ただ、あくまでトライを繰り返した状態で、まだしっかり足場が固まり誰がチームに参画しても大丈夫な状態ではなかった点です。
領域に対する知識も、触れたものは理解できるがその周辺は分からなかったり、触れてことがない部分は全く分からない状態でした。
また、トライを繰り返した状態で、まだ体系的な部分が確立している状態ではありませんでした。
ということで、またまたチームビルディングの開始です。
POとしては、プロダクト全体ロードマップでも重要案件と位置づけられるものをProject計画し推進していきつつ、中期目線での変遷するユーザー層への提供価値なども検討していきます。
チームとしては、2年目も基本的にチーム全員で考え、議論し、集約し、決定していくことは継続しています。
1年目と異なるのは、一部は ベース ができている、ということです。
ただし、この ベース がメリットにもデメリットにもなり得ます。
メリットは、ゼロから考えなくても良い、というシンプルなものです。
デメリットは、ベースが荒い状態のものについて、その構築に携わっていなかったメンバーにとっては不十分に感じる部分があります。
デメリットは当然のことなのですが、「その状態である」と元からいたメンバーも新しいメンバーも含めてチーム全員が同じ認識を持つ必要があります。
『同じ認識を持つ』 ことがスタートです。
また、『「不十分」を「十分」にすることが必要か』という認識合わせもあります。
今のチームは、『不十分だとしても具体的な課題がなければよしとして課題が明確にできたら取り組もう』 というチーム内の合意形成ができています。
この合意形成は、簡単にできるものではありません。
この合意形成ができるようになるのも、チームビルディングの1つです。
お互いが意見を出し合い、チームとして最善の方法を考えようという人が集まっているから成り立ちます。
Managerとしては、新旧メンバーどちらの話も聞きつつチームとして一番良い方向を目指すことについて対話します。
また、その方向に各メンバーの成長や働き方も重ねられるように、時にはMTGのファシリテーションで工夫したり、目標設定を調整したり、担ってもらう業務の種類を調整したり、Projectのアサインを検討したりします。
Product Owner と Manager の役割バランス
これまで簡単にチーム状況についても共有しました。
では『Product Owner と Manager の役割バランス』とは。
もう冒頭で記載したのですが、
その時その時の状況によって最適な形
だと思っています。
ただ、それはあいまいすぎるのでシンプルになんのバランスを取るか、以下のそれぞれの重点のバランスをどれぐらいの重みにするのかではないかと思っています。
| 役割 | 重点 |
|---|---|
| Product Owner | プロダクトと開発チームに向き合う |
| Manager | 人としてのチームと個々のメンバーと向き合う |
そして、1人が2つの役割を担う段階ではなく、それぞれの役割を別の人が担う段階がくると、それは個人でのバランスではなく2人の人物同士でバランスを取る必要がでてきます。
そうするとまた別の課題が出てくるでしょう。
結局、どこでも誰でも当てはまるような答えはないんだろうな、といつも考えています。
ということでこの辺にしたいと思います。
2024年、今年もありがとうございました！