
こんにちは。株式会社ラクスで「楽楽債権管理」のPdMをしている柴、PMMの江良です。
「楽楽債権管理」は 請求(債権)データと入金データの照合・消込を自動化するクラウドサービスで、入金の過不足、まとめ入金、名義違いといった実務で頻発する複雑なケースにも対応します。消込後の仕訳データも自動生成し、手作業では時間のかかる債権管理業務を正確かつスピーディーに進められるようにします。
https://www.rakus.co.jp/rakurakucloud/saikenkanri/
「楽楽債権管理」は2025年7月、「楽楽明細」のオプション機能からスピンアウトし、単独プロダクトとして販売を開始しました。単独化によって事業のポテンシャルは大きく広がりましたが同時に、ステークホルダーの増加や組織の拡大により、立ち上げ期のような少人数の阿吽の呼吸だけではスケールしなくなりました。
そこで必要になったのが、体系的で再現可能なプロダクトマネジメント、そしてチーム全員が「同じ地図」を持って進むための仕組みでした。この記事では、「楽楽債権管理」が新たなフェーズに向かう中で、どのようにその「地図」が整備され、プロダクトと組織が変わっていったのかをご紹介します。
このnoteは、プロダクトの立ち上げ期〜成長前夜にいるチームに向けて書いています。戦略や役割がまだ曖昧で、「自分たちはどこへ向かっているのか」「どうやって再現性のある組織を作るのか」に悩む方に、少しでも参考になれば幸いです。
- 立ち上げ期にあった課題感
- 役割を明確化し、組織の“ハブ”をつくる
- 戦略設計を「共通言語」に
- 顧客の声(VoC)の仕組みづくり
- データ活用による顧客行動の可視化
- ロードマップを“見える化”する協働
- おわりに
- 採用情報
立ち上げ期にあった課題感
単独化前後のチームには、次のような課題がありました。
- データが整備されておらず、お客様の課題や利用状況を定量的に把握できない
- 戦略がなく、商談でよく出る要望を“積み上げ式”に対応していた
- チーム内の役割が曖昧で、意思決定の軸が人によって異なっていた
こうした状況では、「プロダクトとしてどこへ向かうべきか」も「組織としてどう動くべきか」も不明瞭になります。ここから、再現性のある意思決定・役割分担・戦略共有に向けた取り組みを進めていきました。
役割を明確化し、組織の“ハブ”をつくる
これらの課題に向き合ううえで、最初に取り組んだのが役割の整理でした。組織が拡大する中で、誰がどの領域をリードするのかを明確にすることも重要な課題でした。役割が曖昧なままでは情報が滞り、意思決定が遅くなってしまうためです。ラクスでは職能別組織体制を採用しており、それぞれが持つ専門性を最大限に活かしながらプロダクトを前に進めています。一方で、職能が分かれているからこそ、情報をつなぐためのコミュニケーションコストが一定かかるという側面もあります。そこで「楽楽精算」や「楽楽明細」と同様にPdMとPMMは役割を明確にし、“分断”ではなく“補完”として機能するよう再定義しました。
PdMは「開発・デザイン」のハブ
- エンジニアとの仕様検討
- デザイナーとの構造・UI議論
- 技術的制約と顧客価値のバランス調整
PdMはプロダクトを「どう作るか」の中心に入りこみ、ビジネスの意図を開発に翻訳する橋渡し。
PMMは「営業・CS」のハブ
商談やデモからの学び
CSが拾った利用実態や課題
市場動向・競合比較
PMMは顧客や市場のリアルをプロダクトへ返し、現場とプロダクトの温度差をなくす存在。
このハブ構造により、開発/デザイナー ←→ PdM ←→ PMM ←→ 営業/CSという情報の流れが生まれ、意思決定が早く、滞留しない組織へ変わりました。
戦略設計を「共通言語」に
最初に取り組んだのは PMF(Product-Market Fit)の定義 でした。当時は「PMFを目指す」という言葉だけが独り歩きし、何をもって達成と言えるのかチーム内で解釈がバラバラでした。そこで他プロダクトの状況や事業状況、プロダクトの利用データを整理し、いくつかの定量指標を設定。チーム全員が “PMFとは何か” を同じ言葉で語れる状態 にしました。さらに ICP(Ideal Customer Profile)を定義 し、「誰に価値を届けるのか」を明確化。業種、規模、利用システム、入金件数などの基準でターゲットを整理することで、ロードマップ、優先順位、マーケ施策の判断軸が一貫するようになりました。戦略を明文化したことで、議論のスタートラインが揃い、チームとして“同じ方向を向く”状態を作りました。
顧客の声(VoC)の仕組みづくり
次に取り組んだのが、顧客の声(VoC)を意思決定に活かす仕組み です。私たちはLookerによるデータ可視化に加え、VoCを毎月1回、PdMとPMMがあえて手動で整理する運用を取り入れています。自動集計ではなく全件に目を通すことで、数値化しづらいニュアンスや深層の課題を捉えられるためです。
VoCとPBIはすべて Notionで一元管理。PdM・PMMはもちろん、開発・営業・CSまで誰でもリアルタイムにアクセスできます。さらに、RICEスコアを参考にVoCを以下のような軸でスコアリングしています。
- 顧客規模
- 課題の頻度
- 代替手段の可否
- その課題が事業成長に与える強さ(失注や解約につながる課題か)
- ICPとのマッチ度
定量的に整理することで、「大口顧客の1件の声」と「中堅顧客の複数の声」を公平に比較でき、単なる“要望リスト”ではなく戦略と一貫したロードマップに落とし込めるようにしています。
データ活用による顧客行動の可視化
VoCとは別に、実際の利用行動データから顧客の状態を捉える仕組みも構築しました。お客様ごとの利用ログを取得し、主要機能の利用状況を業務フロー単位で可視化。これによって、
- 主要業務がどれだけ実施されているか
- どの機能が活用されていないか
- どの工程で“詰まり”が生じているか
といったプロダクトの実態が明確になりました。さらに、これらをスコアリングし利用が停滞しているお客様を自動検知。CSチームが能動的にフォローできる体制が生まれました。「ログの可視化 → スコアリング → CSアクション」の流れによって、プロダクトの価値をお客様の業務に定着させる循環を作りやすい仕組みにしています。
ロードマップを“見える化”する協働
ロードマップ策定は、PdM・PMMに限らず営業・CS・開発まで巻き込みながら進めています。
- セグメントごとのニーズ整理
- 競合比較
- 商談だけでは見えにくい非定量な課題感の抽出
- 顧客価値の大きい領域を優先する判断
- 機能開発における規模や難易度
上記のような情報を現場から吸い上げ、プロセスを透明化することで、「このタイミングで、この顧客セグメントに、こういう価値を届ける」という共通理解が生まれ、プロダクトの方向性が揺らぎにくくなりました。
おわりに
こうした取り組みの積み重ねにより、PdMとPMMが互いの領域に自然と“越境”しながら協働する文化が育ってきました。役割は分担しつつも、共通言語と共通の地図を持ち、チーム全体でプロダクトを育てる文化へと変化しました。
楽楽債権管理は今まさに成長フェーズへ踏み出しているプロダクトです。その中で積み重ねてきた仕組みと文化は、これからステークホルダーが増えても迷わず進んでいくための土台になると信じています。プロダクトが変わると組織が変わり、組織が変わるとまたプロダクトが変わる。この循環をこれからも回し続けていきたいと思います。