はじめに
こんにちは！ラクスルのエンタープライズ事業部でプロダクトマネージャー(以下、PdM)をしている平光です。 ラクスルアドベントカレンダーの19日目を担当します。
簡単に自己紹介します。
ラクスルに新卒で入社して、現在6年目になります。学生時代に、LPO/CVR改善のSaaSにて営業・マーケティングのインターンを行った後、Edtechの会社でエンジニアとしてインターンをし、ラクスルに入社しています。ラクスルでは、ECやサプライチェーンマネジメント(以下、SCM)など、様々な領域でPdMを行ってきました。 今は、エンタープライズ事業部にて、ラクスルを大企業・中堅企業の方にも利用していただくことを目的に、事業開発およびプロダクト開発をしています。
エンタープライズ事業の紹介
現在、ラクスルでは大企業・中堅企業向けのサービスとして ラクスル エンタープライズ を提供しています。決算説明会資料にもある通り、以下の3つを今後の成長ドライバーと捉えており、本事業は3を担っています。
- EC化の進展による対象市場の拡大
- オーガニック・買収によるカテゴリー拡張
- 個人事業主/SME中心の事業展開から、大企業セグメントへの顧客基盤の拡張
不確実性を下げるために意識していること
「リリースしたプロダクトを実際に利用してもらえるか」「そのサービスの利用が事業成長に繋がるのか」その答えはリリースしてみないとわからない状態だと思います。 PdMは、生みの苦しみに苛まれながらプロダクト開発に向き合うことと思います。
そのような中で、新しく生んだプロダクトが確実に事業の成長に繋がるように、不確実な状態をさげていくことが、PdMの大事な役割だと思っています。
本記事では、プロダクト開発の不確実性をさげるために、私が意識している3つのことをまとめられたらと思います。
1. 1Wayな意思決定を避ける
まず1つ目は、1Way(一方通行)な意思決定を避けることです。
その意思決定は「あと戻りできるのか？」「やり直しがきくのか？」を意識しています。
プロダクト開発においては、初期のアーキテクチャーや設計がその後のサービス展開の成否をわけます。 1機能の追加によるデータベースのスキーマ変更などが、今後のサービス展開を妨げる要因にならないか？その可能性がある場合、自分は意思決定に確信を持ててるのかを自問します。
初めから、その後のサービス展開をすべて見通せていれば、それに越したことはもちろんありません。 しかし、そのようなスーパーマンはいないでしょうし、当時は考えもしなかった展開を作っていけるのが、長期で事業価値を作っていくことのおもしろさだと思います。
したがって、1Wayな意思決定を避けることは非常に大切なことだと思います。
2. 具体と抽象を行き来する
プロダクト開発をしていると、よく耳にすると思いますが、非常に難しいですよね。
具体の定義をGoogleで調べてみたところ、Oxford Languagesの定義では、以下でした。プロダクト開発においては、実際の顧客の声を聞くこと・一次情報を取りに行くことなどが当てはまると思います。
（そのものが単に考えられるというだけでなく）形・姿を備えること。具象。
反対に、抽象の定義をGoogleで調べてみたところ、Oxford Languagesの定義では、以下でした。
多くの物や事柄や具体的な概念から、それらの範囲の全部に共通な属性を抜き出し、これを一般的な概念としてとらえること。
当たり前ですが、言葉の定義からもわかるように抽象は数多くの具体の事柄から生まれます。したがって、起点は、顧客の声を聞くこと・一次情報を取りに行くことです。
具体の事柄を集めたら、抽象化を行います。似ていること、共通していることを探して、事柄の関係性を見抜きます。
ラクスル エンタープライズのプロダクト開発において、抽象化するときに意識している観点は「ステークホルダー」「顧客のビジネスモデル」「印刷物の利用用途・シーン」「業務の流れ」です。たとえ業界・業種が異なる企業であっても、印刷物の利用用途や業務の流れが一緒であることは多々あります。外から見える情報だけで抽象化するのではなく、一歩踏み込んだ情報から抽象化していくことが大事なのかもしれないと感じています。
事柄の切り取り方、グルーピングの粒度など、具体をどれだけ抽象化してプロダクト開発に落とすのかはPdMの腕の見せ所ですね。
チームのエンジニアにアーキテクト思考という書籍をおすすめしてもらったので、貼っておきます。
3. リターンを複線化する
プロダクト開発の優先順位をみなさんはどのようにつけていますでしょうか？ROI(Returen on Investment)は多くの会社において、意思決定の基準の1つになっていることと思います。では、リターンをどのように定義していますでしょうか？
私は、1つのプロダクト開発によって、複数箇所からのリターンを設計できないかを検討します。
たとえば、とあるセグメントの顧客に向けて機能Aをリリースするとします。機能Aを利用する顧客は、利用しない顧客と比べてリピート率がN%改善すると見込みました。リピート率の改善からリターンを設計し、リリースしました。結果は想定していたより顧客の機能Aの利用率が低く、当初のリターンを下回りました。しかし、機能Aで作ったアルゴリズムを社内オペレーションシステムに組み込むことによって、社内業務の効率化をすることができると考えていました。結果、機能Aの開発によって生み出された資産を活用して、他のユースケースでリターンを得ることができました。
このように、メインでは顧客が機能Aを利用するユースケースからのリターンを設計しつつ、他のユースケースでも活用できるようにプロダクトを設計していくことで、リターンの確度をあげられると思っています。
ただし、そればかりを考えすぎて、本来向き合う課題・提供したい価値とずれてしまうのは本末転倒なので注意が必要です。
まとめ
ここまで、プロダクト開発の不確実性を下げるために意識している3つのことをまとめてきました。みなさん、いかがでしたでしょうか？
とはいえ、不確実性をゼロにすることはできないので、最終的にはリーダーやオーナーがどれだけ顧客に向き合い、プロダクトについて考えてきたかだと思っています。スタンスを取って意思決定をし、それを正解にすることが一番大事でしょう。
まだまだ日々試行錯誤しながら取り組んでおります。みなさんの意見も聞けると嬉しいです。
最後に
この記事を読んでラクスルに少しでも興味を持っていただいた方に向けて（勝手に）TO DOリストを用意しました。
▼すぐにラクスルに応募したい方 ・レジュメをアップデートする ・応募する
▼転職を検討するタイミングで応募したい方
- RAKSUL Engineer Recruitment Bookをブックマークする
- タレントプールに登録する(ご希望のポジションで募集を開始する際に採用担当からご連絡いたします)
- レジュメをアップデートしておく
みなさまのアクションをお待ちしています！
