こんにちは！SmartHR QAエンジニアのwattunです。 私事ですが、2024年7月から文書配付機能のプロダクトオーナー(以下、POと表記)に正式に就任できました。 今回はPOをやろうと思った理由や就任までの話をします。
POとは
SmartHRでは、POはスクラムチームにおける役割の1つです。スクラムチームから生み出されるプロダクトの価値の最大化に責任を持ちます。
SmartHRの職種の1つであるプロダクトマネージャー(以下、PMと表記)に求められることが近いためSmartHRではPMがPOをやることが多いですが、他の職種(ドメインエキスパートやプロダクトデザイナーなど)がPOを担当することもあります。QAエンジニアの私の場合もこのケースに該当します。
入社からPO就任までの流れ
入社からPO就任までの流れを説明します。
2022年1月にSmartHRに入社後はプレイヤーとして文書配付機能のQAを担当しました。入社してから半年後にオプション機能を担当する2つのQAチームのうち、1つのチームのチーフに就任しプレイングマネージャーとして活動していました。
2024年3月に上司へPOに挑戦したい意向を伝え、4月〜6月にPOとしてワークするかのお試し期間を経て、晴れて7月に正式に就任できました。
なぜPOに挑戦しようと思ったのか
POに挑戦しようと思った理由は、開発チームの一員として「プロダクトの価値の最大化に責任を持ち、何を作るか・なぜ作るかの意思決定」に深く関わっていくためです。
2023年に品質保証部では、プロダクトやプロダクト開発チームの急激な拡大に適応するため、開発チーム全員で品質保証していくことで、専属のQAエンジニアがいないプロダクトでも品質保証が行なえるようにしていく方針転換をしました。
部の方針転換には納得しており、私が所属するチームでもプロダクト開発チームにテスト活動の移譲を進めています。移譲の結果、QAエンジニアが抜けてもテスト活動ができるプロダクト開発チームが増え、各プロダクト開発チームの状況にあわせた関わり方の選択ができるようになってきています。
一方で私自身は「何を作るか・なぜ作るか」の部分にもっと貢献したいという想いが強くあったため、事業戦略上でQAエンジニアに求められる役割と自身の志向のズレをどう埋めていくかを悩んでいました。
深く関わりを持ちたいなら役割を持てばいいじゃない
悩んだ末に出た答えは、私が「何を作るか・なぜ作るか」の部分に責任を持つ役割を担うことでした。
幸いなことに、文書配付機能チームはPOの業務の移譲が積極的に進んでいるチームであり、QAを担当する中でPOの業務の一部をやった経験があります。当時のPOのfumiya sanへ品質保証部の方針転換にあたっての相談を持ちかけた際に「wattun sanがPOやるって選択肢はないんですか？」と冗談交じりながらも評価いただいていたので、自身の意向があれば挑戦できるかも、と考えました。 元々スクラムへの関心があってアジャイル推進室という社内のコミュニティにも所属しており、「POなら、スクラムチームの一員として活動もできるね！」という気持ちもありました。
諸々を勘案し、大変なのは覚悟のうえで挑戦のために動いてみることにしました。
まずは現任のPOと上長に相談だ！
自身がPOをやる場合、当時のPOとの交代・引き継ぎになるため、POの交代を真剣に検討して良いものか改めて確認しました。POの交代にあたってどのようなハードルがあり、誰と調整していく必要があるのかをすり合わせました。
その後、品質保証部マネージャーのarmin sanにPOに挑戦したい旨の意向を相談しました。品質保証部内では前例のないことだったのですが、ありがたいことにarmin sanは私の意向を受け止め、応援してくれました。その後、armin sanが各所との調整・相談を進めてくださり、POに挑戦する機会を得られました。
挑戦へのセーフティネット a.k.a お試し期間
POの挑戦にあたり、スキルマッチ・兼務による勤務状況を確認するため、お試し期間を設けることになりました。お試し期間があることで、私がPOとして期待に応えられるかどうかを確認したうえで就任できるため、お試し期間はセーフティネットを設けつつ挑戦できる良い仕組みだなと感じています。
お試し期間中にやったこと
POのお試し期間に以下のことをやりました。
POタスクの引き継ぎ
お試し期間といってもPOに期待されることは変わらないため、次の形で引き継ぎを進めました。
- POとしての業務はwattunが行なう
- 業務の中で迷うことがあれば当時のPOやPMの方々へ相談・壁打ちする
- 当時のPOから仕掛中のタスクや心残りのある課題を聞く。どう対応するかはwattunが判断する
- お試し期間中にwattunがやったことは適宜共有して当時のPOからフィードバックを受ける
POとしての裁量を持って取り組むことで、自身で解決できること・迷ったり解決できないことの切り分けができたため、壁打ちや相談をしながら解決できる範囲を広げていけました。
OKR・ロードマップの策定
私がPOに挑戦するにあたって一番の不安要素だったのがOKRとロードマップの策定です。 今までPOがアウトプットしたOKR・ロードマップを目にしたことはあっても、アウトプットされるまでの過程は知りませんでした。
まずは、当時のPOに今までのOKR・ロードマップをアウトプットした際のインプットや過程をヒアリングし、ヒアリング結果を参考に、自身でOKR・ロードマップのドラフトを作成しました。 その後、当時のPOへの壁打ち→文書配付を担当するプロダクトマーケティングマネージャー(PMM)への壁打ちを経て、労務プロダクト内に共有し、修正を加えながら合意できました。
壁打ちや、共有の際にいただいた質問やフィードバックから、想定しているソリューションでビジネスゴールの達成が現実的に見込めるかなど、OKR・ロードマップ策定時に考慮すべき点を学びつつ、より良いものにしていけたため、ご協力いただいた方々には深く感謝しています。
PMの会議体への参加
お試し期間の開始後、PMの定例に参加するようになり、開発チームから見えていたPMの活動は本当に極々一部だったんだとわかりました。
各PMは担当プロダクトのことだけではなく、マルチプロダクト戦略に適応するための分科会が活発に活動していて、チームで型化したものを共有してフィードバックを求めたり、各PMが経験した失敗や学びを共有するなど、それぞれが持つ知見や経験を広げていくための工夫が為されていました。挑戦し始めた私にとっては有用な情報が山盛りなため、各PMが何を見て・どのように考え・どのように解決しているかを聞くことで、たくさんの学びを得ています。なるべく早く私から周囲へ還元できるように、新しいことにどんどん挑戦しながらレベルアップしていこうと思っています。
開発アイテムのソリューション決め
各フィーチャーの開発の際、「どのような価値をユーザーに提供したいのか」を明確にし、そのために必要な開発スコープをスクラムチームメンバーと議論しながら決めています。 文書配付機能のスクラムチームはPOの業務移譲が進んでいるチームであるため、プロダクトエンジニアもフィーチャーの開発スコープやソリューションを決めることができるのですが、POとして価値提供に不要な部分をスコープアウトすることで、考慮事項や関心事を減らして価値を生み出すことに集中しやすい状態作りを心がけています。
プロダクトバックログの整備
スクラムチームが行なう作業の情報源をプロダクトバックログに統一すべく、プロダクトバックログの整備に日々取り組んでいます。 具体的には、タイムラインで各開発アイテムの計画を示したり、直近2〜4スプリント分のプロダクトバックログアイテムの優先順位を決めています。 タイムラインやプロダクトバックログアイテムの内容は、フィードバックや開発状況にあわせて適宜アップデートをかけています。
スクラムチーム内で発生した課題の解決
お試し期間に入ってから間もないタイミングで、スクラムチームより、「smarthr-uiのバージョンアップを始めとした継続的に取り組み続けなければいけないタスクに十分な時間が取れず、やるべきことが溜まっている」という相談を受け、相談してくれたエンジニアと協働して必要な時間が割けるようなプロセスにしました。
ざっくり次のような調整をしました。
- スプリント中に他の開発アイテムとは別に継続的にやるべきことに取り組める時間を確保する
- 確保する時間の過不足を感じたら、都度スクラムチーム内で協議して調整する
- チーム内の合議コストを削減するため、確保した時間内で何に・どう取り組むかの意思決定は開発者(プロダクトエンジニア)に委任し、スプリント中の完了は確約しない
- レトロスペクティブの最後に継続的にやるべきことが十分なペースで消化できているかの検査を行ない、課題があれば対策を協議する
試行段階ではありますが、以前よりも確実に時間が取れるようになり、相談時点で感じていた課題を解消していけていると感じます。
挑戦してみて感じたこと
文書配付のPOに挑戦して以下のことを感じました、
役割が変われば捉え方が変わる
POをやる前は機能を開発してリリースするまでをゴールのように捉えていましたが、いざPOに挑戦してみると「機能のリリースはアウトプットであり、望ましい成果(アウトカム)を得るための手段なんだな」と捉えるようになりました。
アウトプットを中心に考える癖がついている状態から、事業に対するインパクトやそのために達成すべきアウトカムを考えられるように切り替えるのはかなり大変です。でも、周囲には模範にできるPMの方々がたくさんいて、悩んだ時はすぐに相談に乗ってくれるので「大変だがこの環境なら絶対にできる」とも感じています。
改めて感じる品質保証の重要性
必要な機能をリリースしたとしても機能がユーザーのニーズや期待を満たせなければ、期待するアウトカムは得られません。もし、インシデントが発生した場合、サービスの信用低下を引き起こしたうえ、本来は価値を生み出すことに割けるはずだったリソースをインシデント対応に割かなければいけません。 幸いなことに現在はインシデントの発生率は稀と言える程度に収まっています。SmartHR内で品質文化の醸成や開発チームへのテスト活動の移譲が進んでいるからこそ、POへの挑戦に集中できているんだな、と改めて感じます。
今後やっていきたいこと
文書配付機能のPOの就任後は以下のことをやっていきたいです。
労務プロダクトのディスカバリーへの挑戦
お試し期間では文書配付機能の業務の遂行で手一杯でしたが、労務プロダクトで解決していく業務課題の中には、複数のプロダクトで協働しなければ解決できないものもあります。そういった業務課題を解決するためのディスカバリーにも挑戦してプロダクトの境界を越えて貢献できるようにしていきたいです。
文書配付機能以外のプロダクトマネジメントができるようになる
文書配付機能はQAエンジニアとして関わっていた経験もあり業務を遂行できていますが、ゆくゆくは文書配付機能のPOを他の人に引き継いで、他のプロダクトを担当する可能性もあります。そういった際に二つ返事で引き受けられるように、プロダクトマネジメントの能力をあげていきたいです。
POの業務にQAエンジニアの経験・知見を活かす
QAエンジニアがPOの役割を担うことで、POの業務においてQAエンジニアの視点が活かせると考えています。例えば、QAエンジニアというバックグラウンドを持った人がPOをやることで、プロダクトのディスカバリーや仕様策定などに対して「妥当性を確認する」から「自身が作る（あるいは主導する）」という立場に変わります。その結果、作られたアウトプットはすでにPOとQAエンジニアという2つの視点が合わさったものとなります。 これにより、意思決定のコミュニケーションパスを増やすことなく、従来は気づけず後工程で顕在化した問題に作成段階で気づくことができます。
また、POという役割を自身が担うことで、今まで気づけなかったプロセスの改善点に気づき、それを解決・発信するということもできそうです。そういった取り組みを通じて、QAエンジニアが貢献できる領域を拡げる新たなきっかけを作りたいです。
品質保証部チーフとしても成果を出す
2024年7月時点では、文書配付機能のPOと品質保証部のタレントマネジメントプロダクトを担当するチームのマネジメントを兼務しています。プレイヤーとしてPOの責任を果たしつつ、品質保証部のチームとしてタレントマネジメントプロダクト全体の品質への責任を果たしていきたいです。
最後に
正式に就任したといっても、まだスタート地点に立ったばかりで、これからも挑戦の日々は続きます。数年後、この挑戦が正解だったと言えるようにこれからも頑張っていこうと思います。
We Are Hiring!
SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！ 少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
