本記事のターゲット
はじめに
こんにちは、楽楽精算プロダクトマネージャー（以下PdM）のShibaと申します。
2023年5月にラクスに入社して、半年以上が経過しました。 PdMという職種は会社毎で役割や責任範囲が異なります。 そのため、転職後の業務は多くの人が気になるポイントかと思います。 ラクスに入社して私がやってきたことと気付きを共有することで、ラクスへの転職を考えている方の参考になればと思い本記事を書くことにしました。
注意
入社者の志向やスキル/経験に基づいて適切な役割をアサインする仕組みがラクスにはあると思います。 全員が同じ流れで同じ業務をすることはないという点はご了承ください。 また、時間軸は若干曖昧なところがあります。
私のバックグランドと転職理由
前職は新卒で入社した会社でBtoB SaaSのワークフロープロダクトに約7年間携わっていました。 エンジニアからキャリアをスタートして、プロジェクトマネージャ/プロダクトマネージャ/カスタマーサポート/プリセールスなど プロダクトの成長に必要なことは何でも経験させてもらいました。非常に成長できたと実感があります。
そんな中、30歳を目前に「もっとプロダクトマネジメントに特化したスキルを伸ばしたい」という思いからPdMへの転職を決意しました。 またなんとなく「若いうちに転職を経験しておきたい」という浅い理由もあったかもしれません。
楽楽精算はARR100億以上、累計導入社数も15,000社を超えています。 国内トップシェアのプロダクトに関わることが出来るというのは私にとって非常に魅力的なポイントでした。 （ラクスを選んだ理由はあまり深掘りしません）
入社後に感じた自身のスキルとのギャップ
1.言語化する力
前職では課題の特定～設計/開発/テスト/リリースまですべてを担当していました。 自分の頭の中ではなぜそれをすべきか、なにをすべきかの情報があり、それをもとにプロダクト開発を行っていました。 しかしラクスは規模（顧客数、ステークホルダ数、開発工数など）が大きいため、役割分担によってプロダクト開発が成り立っています。
我々PdMの役割は課題の「Why」「What」を明確にして、適切な課題に適切なアプローチをすることが出来るようにすることだと考えています。 この「Why」「What」を誰が見ても理解できるような形でアウトプットし、納得してもらうための能力はまだまだ伸ばしていく必要があると感じています。
2.思考の道筋の整理
シニアPdMと一緒に仕事をすると痛感する部分です。
私は物事を整理する時、あらゆる情報を集め、そこから必要な情報の取捨選択、ストーリーの構築を行っていくスタイルだと自認しています。 対照的に、結論に向けてストーリーを構築し、必要最低限の情報を集めるパターンの人がいます。 （このタイプの人も頭の中で情報を整理し取捨選択していると思いますが、頭の中はわからない）
この違いで生じる差は、大きくはスピード感です。 情報がMECEに整理され、論理的にもおかしくないストーリーをスピード感をもって組み立てる能力は変化の早い時代において伸ばしていく必要があると考えています。
入社後の業務
入社1カ月目
はじめの1カ月は以下のような業務に必要な情報のインプットを行いました。
- 事業・組織の方針
- プロダクトロードマップやKPIなどプロダクト方針
- プロダクト（プロダクトの価値、仕様）
- 法/制度（主にインボイス制度、電子帳簿保存法）
- 経理ドメイン知識
- 組織内の役割分担
- 各種業務プロセス
- システム構成や環境情報
- 競合/市場の情報
私の所属する「製品管理課」ではオンボーディング資料が整理されており、特に重要な情報に関してはそこから参照することが出来るようになっています。 資料からわからないところは、インターネットや書籍、上司との1on1を通して理解度を深めていきました。
特にドメイン知識というのはこの資料を読めば理解できるというようなものはなく、実際の業務/作業レベルまで理解する必要があります。 プロダクトを触り業務を体験することである程度は理解することが出来ますが、 機能から逆算した業務フローでは、実務レベルまで解像度を高めるは難しいため、 この段階では「業務のイメージが出来る」「用語が理解できる」など定性的な目標を定めて学習するようにしました。
情報が多すぎるがゆえに、認知負荷がかかり何をどこまで理解するかという点は非常に悩みましたが、 自分のキャパと自分の理想の折り合いをつけることが大事です。
また、参加可能な会議には出席するようにしました。 ステークホルダ/キーマンの把握、どのような意思決定が行われているかは早めにキャッチアップし、 なるべくスムーズに実務を開始できるよう準備しました。
入社2～3か月目
2カ月目からは実際の顧客課題に対して、プロダクトバックログアイテム（以下PBI）の策定を開始しました。 PBIは事業部との課題/解決策の擦り合わせ・開発チームでの概算工数の見積もり・PRD（製品要求仕様）のインプットにも利用される重要な情報です。 楽楽精算のPBIには以下のような情報が含まれます。
- 財務効果
- 誰のどんな業務のどんな課題
- どうすればその課題を解決できるのか
- AsIs/ToBeの業務フロー
楽楽精算ではカスタマーサクセス（CS）が収集した顧客の声（VoC）が1か所に集約されており、開発サイドも常に確認ができるようになっています。 PBI作成で注意すべきは、VoCの中には課題だけではなく「〇〇できるようにしてほしい」といった要望も多く存在するという点です。
その要望通りの機能を実現するのではなく、背景にある課題に目を向け最小限のコストでその課題の解決策を考えること必要です。 （言ってしまえば、既存機能の運用回避などが提案できればそれでもよい）
課題/要望や社数、発生頻度が精度の高い状態で集まっていることで、 リリース後の効果の不確実性やユーザ調査の工程を省略しスピード感をもってリリースすることができますので、 この仕組みは非常に強力な仕組みだと思っています。
参考（ラクスエンジニアブログ）
入社4か月目～現在
4カ月目以降からは実案件（リリースが確定している案件）にアサインされ、PRDの策定やエンジニアが作成した機能要求やUX設計のレビューを行っています。
また、現在は製品戦略上重要なプロジェクトの案件の実現に向けて、 課題の深堀・ユーザ調査の設計（インタビュー、アンケート、仮説検証）・ソリューションの検討などをPMMと連携して行っていたり、 モバイルアプリの案件に着手したりと担当させてもらえる業務範囲が広がってきました。
顧客への価値提供はもちろん、社内での期待に応えられるように自分のできることを増やしていこうと思った8カ月間でした。
さいごに
前記したような売上や契約社数が多いプロダクトとなると、完成したプロダクトと思う方もいらっしゃるかもしれません。私はそうでした。 しかし、法改正やIT技術の発達、競合プロダクトの出現、顧客業務の変化などプロダクトを取り巻く環境は日々変化しています。 それらに対応していくために、楽楽精算ではPdM人材を引き続き募集しております。 是非まずはカジュアル面談からお申込みいただけると幸いです。
