はじめに
みなさん、こんにちは！SmartHRでプロダクトマネージャー（PdM）をしています岸（@kissy）です。
SmartHRでは2020年1月から大規模スクラムのフレームワークであるLarge-Scale Scrum（LeSS）を採用しており、 現在、LeSSに属するスクラムチームは4チーム、PdMは私を含めて総勢4名（10月から5人に増えました！）という体制で開発をしています。
そこで本記事では、「大規模スクラムで見えてきたマルチPdM体制の面白さと難しさ」についてお話し、 SmartHRのPdMは日々どんなことを考え、どのようなことをやっているのかをお伝えできればと思います。
「SmartHRのPdM」連載については 「SmartHRのPdM」連載をはじめます をご覧ください。
現状の SmartHR の開発体制について
SmartHRはプラットフォーム化構想を掲げており、従業員データベースである「SmartHR本体」と、 そのデータを活用するアプリ群である「プラスアプリ」の2軸で開発を進めています。 開発チームもSmartHR本体と各プラスアプリ単位で分かれており、LeSSを採用しているのは私が所属するSmartHR本体の開発を担うチームです。
SmartHR本体も2020年1月以前までは、いわゆる普通のスクラムで開発をしてしましたが、 開発スピードの加速のために単一のスクラムチームでは限界を感じ、LeSSの採用に至りました。
4つの数字で「いまSmartHRに入社してやることあるの？」という疑問に回答します にもある通り、 当時も現在もSmartHRはまだまだ未完成の状態で、やるべきことも課題も山積みです。
SmartHRを利用してくださるユーザーの業種・業態や企業規模の拡大に伴い、これまで提供してきた機能ではやりたいことができなかったり、 我慢をしながら使ってもらっている部分があるため、「既存機能のカイゼン・拡張」は不可欠です。 さらに、他社に負けない競争力をもったプロダクトになるためには「新機能の開発」も優先度を上げて対応しなくてはいけません。
開発スピードを加速させるためにプロダクトサイド全体の規模も拡大していくうちに、 単一のスクラムチームでは限界があることに気づき、大規模スクラムへ移行したのはとても自然な流れでした。
コンポーネントチームではなくフィーチャーチーム
一般にLeSSでは、コンポーネントチームではなく、フィーチャーチームが望ましいとされています。 コンポーネントチームとはシステムの一部を完成させることを専門とするチームのこと、 フィーチャーチームとはユーザに価値を届ける機能を完成させるための一連の知識とスキルを兼ね備えたチームのことです。
SmartHRでは、フィーチャーと呼んでいる「ドメインごとに分割した一連の機能群」単位でチームをアサインしており、 チームがひとつないしふたつのフィーチャーを担当し、そのチームで企画〜設計・開発を行っています。 PO（プロダクトオーナー）はPdM4名のうち1名が兼務し、SmartHR本体全体のバックログの優先順位の最終決定権を持っています。
なお、上記の体制は現時点のものであり、最適解とは思っていません。
現在直面している課題のひとつが、1チームでは賄えない大規模なフィーチャーに対してどのような体制で臨むのがよいのかという点です。 教科書的にはどのチームでも任意のフィーチャーアイテムを扱える状態が理想形と言われていますが、われわれにあった最適解を模索中です。
また、現在は職種の壁を超えてアジャイルな状態になれているとは言い切れないため、 まずは仕様検討のフェーズからエンジニアやデザイナーが加わるなど、 互いの領域を越境し合いながらプロダクトグループ全体で様々な実験を行っています。
一貫したプロダクト体験を提供するためにマルチPdM体制で心がけていること
SmartHRのPdMの役割、それは「課題を解決するために、何を作るかに責任を持つ」ことです。 複数のPdMがいるSmartHR本体でもその役割は同じです。自分の担当するフィーチャーに対して、各々が責任をもって業務に臨んでいます。
しかし、ユーザーに提供する体験がフィーチャーごとに異なっては意味がありません。 ユーザーにとってはひとつのプロダクトだからです。そのため、互いの持っている情報をオープンにし、全員が納得感のあるものになっているかどうかを非常に大切にしています。
例えば、PRD（プロダクト要求仕様書）は完成までに複数回、複数人でレビューを行い、ブラッシュアップをしています。 ユーザがどのようなペインを抱えているのか、この機能を提供すると何が解決されるのかという Why の部分を厚めに書くようにしているのも特徴です。
他にも、以下のような取り組みを行っております。
- プロダクト全体の開発状況の棚卸しを月1回行い、フィーチャーの依存関係や提供時期をみなで確認する
- 日々寄せられるユーザーの声、ユーザーヒアリングの結果を共有する
- 仕様や開発の進め方に困ったらいつでもSlackやZoomでコミュニケーションを取る
バックグラウンドや強みが異なるメンバーで互いに意見を出し合い、補完し合いながらプロダクトマネジメントするというこのやり方は、 「自律駆動」、「早いほうがカッコイイ」というSmartHRのバリューにもマッチしたやり方ではないかなと思っています。
難しさと課題
こう見ると順調そうに見えますが、マルチPdM体制ならではの難しさと課題はあります。
そのひとつが、フィーチャー間の依存関係です。例えば、私は「権限管理機能のカイゼン・拡張」というフィーチャーを担当しているのですが、 権限管理機能はすべての機能と絡み合っているため、他チームの開発の状況を加味しながら、 最短でデリバリーできる方法を検討しなくてはいけません。チームの規模が拡大し、 同時に開発できる量が増えると考慮すべきことが増えるため、チーム間の連携をより密にする必要があると考えています。
また、PRDの段階でいくらレビューを重ねても、いざ動くプロダクトとして目に見える形にしてみると、 挙動に一貫性がなかったり、文言や言い回しにブレが出てしまうことが多々あります。 そこで最近、プロダクトデザインチームを中心にデザインガイドラインを、UXライティングチームを中心に文言ガイドラインを策定し、 SmartHRらしいプロダクト体験自体を明文化する営みも行っています。
自分一人でプロダクトマネジメントするよりもスケールの大きなことができることがマルチPdMの面白さであり醍醐味です。
チームの規模が拡大するにつれて、意見が多様化し、相互理解が難しくなることが予想されますが、 弊社のバリューに新しく追加された「認識のズレを自ら埋めよう」をみなで体現し、この壁を乗り越えていきたいと思います。
「早く行きたければ一人で進め、遠くまで行きたければ皆で進め。」
最後に
今回は「大規模スクラムで見えてきたマルチPdM体制の面白さと難しさ」についてお話ししました。 SmartHRのPdMが日々どんなことをやっているのか、少しでも伝わっていれば幸いです！
「SmartHRのPdM」連載では今後、SmartHRにいる10人のPdMそれぞれに
- どんなプロダクトを手がけているのか
- どんな課題に向き合っているのか
- どんなことにやりがいを感じているか
などを答えてもらうインタビュー形式の記事の公開を予定してますので、そちらもご期待ください！
いつもの
先ほど述べた通り、SmartHRは組織としてもプロダクトとしてもまだまだ未完成です。 課題もやることも盛り沢山。一緒にやっていきな仲間を絶賛募集してますので、 興味をお持ちいただけた方は、ぜひご応募ください。
