こんにちは!
技術広報課のyayawowoです。
今回は、ラクスのPdMが所属している製品管理課が
どのような目的と目標を持った組織なのかを詳しくご説明します。
2021年10月にPdM組織「製品管理課」を新設してから3年目となる今、
どのような役割でプロダクトの価値を上げているのでしょうか。
PdM組織「製品管理課」を新設した背景と経緯
背景
2021年10月、東京開発部門の横断組織としてPdM組織「製品管理課」を新設しました。
まずは、製品管理課を新設した背景をご説明します。
【プロダクト開発体制:製品管理課の存続前】
製品管理課の新設前、上記の通り、ビジネスサイドに所属する「製品企画」という組織がPdMとPMMの両方の役割を担っていました。
まずは、このプロダクト体制での課題を理解することが必要です。
このようなプロダクトチーム体制の場合、プロダクト開発にてよく言われている課題は以下の通りです。
ラクスのPdMが経験を基にまとめました。
- 開発側の課題
- こうして欲しいという要望(HOW指定)が多く、顧客の声や課題がぼんやりしている
- 開発する項目の優先度が属人的で納得感が十分に持てない
- システムが肥大化し品質維持のためにかかる工数が多く、新規機能開発に時間がかかる
- 品質が安定せず、バグの発生都度高く、その対応に追われ開発が計画的に進まない
- 問い合わせや仕様確認等が多く、開発に専念できない
- ビジネスサイド側の課題
- 開発側へしっかり要望が伝わらず、何度もやり取りや資料のやり直しが発生する
- 思った通りのタイミングでリリースができないことがある
- バグが発生して、その対応に追われている
- もっと多くの要望を実現して、色々試したいがそれが十分にできない
では実際、社内の状況はどうでしょうか。
現状把握を行うため、製品管理課に所属するPdMが開発/ビジネスサイド側のキーマン数名にヒアリングしました。
ヒアリング結果が以下になります。
- ポジティブな意見
- 品質が高い、軽微なバグはあるものの致命的なものは皆無
- 開発プロセスがしっかりしているため、手戻りは少ない
- 各組織の目標や役割が明確である
- ネガティブな意見
- 事業部から開発へ課題や要求が上手く伝わらず、互いに効率が悪い部分がある
- 10年以上の運用しているシステムであり、開発規模も大きくなり
- 計画通りに進める難易度が年々あがっている
- 開発する項目の優先度を決める基準がややあいまいな部分がある
ポジティブな意見としては、役割分担でしっかりと品質が高いプロダクト開発ができているという点が分かります。
一方、ネガティブな意見として前述したプロダクト開発にてよくある課題と同様の意見と、15年弱運用してきて一気に成長したプロダクトならではの課題が上がっています。
「あるべき姿」に向けて
現状把握後、ヒアリング内容の課題が問題であるかをはっきりすべく、目標設定とあるべき姿を定義しました。
◆ 何から決めたのか
1. Missionの設定
2. KGI・KPI/コンテキストの設定
まずは、Missionの設定とKGI・KPI/コンテキストを決めました。
但し、最初から確定するには難しいため、下記ポイントを注意・意識しながらも変化を前提としております。
◆ 設定時に注意・意識したポイント
1.いずれも変化することを前提に設定
2.「KGI・KPI/コンテキスト」はいきなり理想の追及にはせずに段階を踏むようにした
3.初期の「KGI/コンテキスト」は以下を意識
・プロダクト開発チームへ価値や貢献がもたらされ、半年以内で変化をさせられる
・メンバーの現時点での強みが活かせるものにする
メンバーの強みを活かして変化や貢献できることから、設定した形になっております。
◆ 【目標設定】あるべき姿
では、製品管理課の新設時に設定した目標設定をご紹介します。
- Mission
- ビジネス、エンジニアリングの架け橋となりカスタマーサクセスに導く、売れる製品を実現する
- KGI・KPI/コンテキスト
- 【ステップ1】開発組織への貢献
- 開発者がより開発に集中できる環境の提供
- 【ステップ2】ビジネスサイドへの貢献
- PMMがより事業戦略やGTMに集中できる環境の提供
- 【ステップ3】顧客、プロダクトへの貢献
- PdMがより直接的に製品へ貢献できるようにする
- 【ステップ1】開発組織への貢献
製品管理課の新設前は、上記のステップ1〜3を順次進めていくことで、開発組織内外から見てもどのようなステップで進めているかを明確にしておりました。
ラクスのPdMは開発組織に所属しているため、まずは開発組織への貢献を第一に置きました。
次に、ビジネスサイドとPMMがより事業戦略やGTMに集中できるような環境の提供、最後は、直接的に顧客製品への貢献ができるようなステップを踏みました。
実際に実行した8つのこと
では、実際に新設時〜現在までに実行した「KGI・KPI/コンテキスト」の3ステップを細かくご紹介します。
前述にもある通り、まずは開発組織への貢献を第一に考えて実行しております。
【ステップ1】開発組織への貢献(1年目)
まずは、開発組織への貢献とPMMが得意としていない業務の巻き取りです。
製品管理課の新設前は、PRD(Product Requirements Document)の作成をPMMが担当しておりました。
開発からの信頼獲得とPMMの苦手業務を移管するために、PRDの作成はPdMが作成することに変更し、PdMの観点でPRDを作成することにしました。
これにより、開発組織向けの資料となり、開発の要件定義以降のフェーズの効率化に繋がりました。
【ステップ2】ビジネスサイドへの貢献 (2年目)
PdMのあるべき姿を踏まえ、PMMとPdMの役割分担も明確にしました。
実際にどういった開発案件をしていくかの決定フローを含め、PMMと相談をしながら決めていきました。
案件創出を担う役割をPMMからPdMに切り替え、PMMとPdMの業務の無駄を無くすことで効率化に繋げました。
【ステップ3】顧客、プロダクトへの貢献(3年目)
PdMが一番重要としている、プロダクトに価値をより出していく部分になります。
当時の課題に対して打ち手は以下の通りです。
①プロダクト開発計画の作成
問題:年間でどのような開発を進めるのかが明確になっていない
打ち手:「プロダクト開発計画の策定」を明確にすることで、開発の効率化を目指した
②PdMでの顧客解像度を向上
問題:PdMの顧客解像度が低く、一次情報が取れていない
打ち手:価値のあるプロダクト開発を目指し、「Discovery(ディスカバリー)」の領域をメインとした業務を遂行した
ラクスの代表的プロダクトである楽楽精算は、ステップ3まで取り組むことができました。
今後は、他プロダクトにもこの取り組みを活用することで、より高いレベルでPdMができる可能性があるため、担当する対象のプロダクトを増やしていく方針です。
現在のミッション/ビジョン/組織の役割
では改めて、現在の製品管理課のミッション/ビジョンと組織の体制/役割をご説明します。
■ミッション
ビジネス、エンジニアリングの架け橋となり、カスタマーサクセスに導く、売れる製品を実現する
■ビジョン
テクノロジー・UIで最高のUXを製品にもたらし続ける
【プロダクト開発体制:現在】
製品管理課のミッションは、課の立ち位置を踏まえた上でビジネス側にPMM、開発側にPdMがいることで 『ビジネス、エンジニアリングの架け橋となり』、開発本部が掲げているミッション「顧客をカスタマーサクセスに導く圧倒的に使いやすいSaaSを創り提供する」の 『カスタマーサクセス』と、PMMが所属する製品企画のミッション「ユーザーニーズを捉えた、売れる、選ばれ続ける製品を創る」の『売れる製品を創る』を踏まえた上で考えられました。
また、ビジョンの『テクノロジー・UIで最高のUXを製品にもたらし続ける』はユーザ体験を重視し、継続的に製品にもたらす状態にしておくという思いで掲げています。
続いて、「プロダクトの4階層」から見たときの製品管理課のPdMの役割を紹介します。
■PdM組織の役割
- 緑:PMM(ビジネスサイド)が担っている役割
- 紫:PdM/PMMと合同で担っている役割
- 青:PdMが担っている役割
- 薄い青:開発/デザイナー
一般的にPdMの役割は「Discovery(ディスカバリー)」と「Delivery(デリバリー)」の領域があると言われていますが、ラクスのPdMは、「Discovery(ディスカバリー)」のWhy、Whatに役割が集中しています。
製品管理課を立ち上げた際、開発側に属しているPdMが得意分野としているプロダクト、テクノロジー、顧客を紐づけた「Discovery(ディスカバリー)」を巻き取り、PdMの強みを活かしているためです。
これにより、ビジネスサイドにいるPMMは事業戦略やGTMに集中できる環境となり、開発側の生産性も上げることができました。
また「Delivery(デリバリー)」領域は、PdMとてはPMのような振る舞い等での役割は担っておらず、以下のような観点に対し、レビューアとしての役割を担っています。
- 顧客の要求を満たせているか
- プロダクトが顧客に価値を出せているか 等
このように、組織としての役割分担を明確にし、各フェーズでの専門性を高めることで、より効果的なプロダクト開発を可能としています。
◆ 関連記事
career-recruit.rakus.co.jp
新規PRJでのプロダクトへの貢献
今後、製品管理課は新規PRJでプロダクトへの貢献に力を入れていきます。
今回は、代表的な2つについてご説明します。
AIの製品活用PRJ
製品管理課が携わっている楽楽精算はこれまでAIの活用をしていましたが、しっかりと発信やロードマップを示せていませんでした。
◆ 楽楽精算のこれまでのAI活用
・「楽楽精算」が最新のAI機能を活用した領収書読み取りアプリをリリース|「楽楽精算」
・「楽楽精算」v10.5を提供開始。業務負荷が高い”紙請求書受け取り/処理の効率化”を支援し請求書の読取精度”99.9%”以上を実現|「楽楽精算」
楽楽精算は1.7万社以上のお客様に導入されており、お客様の苦労や成功体験が利用実績としてデータに蓄積されています。
今後、このデータをAI活用し、現在導入しているお客様のみならず、新たに導入されるお客様へも価値を提供できるように新しいプロジェクトにも力を入れていく予定です。
楽楽シリーズブランド統一PRJ
2つ目は、楽楽シリーズブランド統一に向けてのPRJです。
本PRJは、ブランド統一のためにUI/UXについてもシリーズ間でガイドラインを一部揃え、複数導入したお客様に対して、それぞれの製品が最適なUXを提供できるようにすることを目的としています。
今後、こういった新規取り組みをプロジェクト化し、遂行していく予定です。
製品管理課の今後に乞うご期待ください!
まとめ
PdM組織「製品管理課」の紹介記事はいかがでしたでしょうか?
有難いことにラクスのプロダクトは年々利用者が増え、会社規模も大きくなってきております。
製品管理課は、プロダクトの価値を上げるためにPdM組織としての目的/目標/役割を明確にし、顧客解像度上げることでプロダクト開発の生産性を上げているのをご理解いただけたのではないでしょうか。
また製品管理課のPdMは、弊社プロダクトの製品開発力や組織力の強みを社外に発信するべく、定期的に外部イベントに登壇しております。
直近では、「物流版AWS」をコンセプトに物流プラットフォームを展開する「オープンロジ」様と合同で、プロダクトマネジメントの在り方についてディスカッションを行います。
オフラインイベントのため、イベントに参加するPdMやPdMを目指す方との交流ができますのでお気軽にご参加ください!
開発エンジニア、デザイナー、マーケターもお待ちしております!
◆ PdMイベントのご案内
お申込みはこちらから!
rakus.connpass.com
ラクスのPdM組織で働いてみませんか?
AI・デザイン・経理分野でのドメインエキスパートついてはPdMの経験がなくても問題ございません。
しっかりとPdMの部分を支援や成長できるように努めてまいります!
少しでもご興味ある方がいらっしゃいましたら以下URLをご確認ください。
career-recruit.rakus.co.jp
製品管理課は、これらの取り組みに共感/情熱をもって一緒に働いてくれる方を募集しています!
最後までお読みいただき、ありがとうございました。
◆ 関連ブログのご案内
開発本部のミッションに込めた想いをエンジニア/デザイナーが発信した、
「RAKUS Tech Conference 2024」のまとめ記事です!是非ご確認ください。
tech-blog.rakus.co.jp