RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

プロダクトマネージャーはどう目標設定するべきか― 試行錯誤と経験からの実践知

こんにちは、プロダクト部 部長の稲垣です。(自己紹介やこれまでのキャリアについて↓をご覧ください。) tech-blog.rakus.co.jp

今回は自分がかなり苦手なテーマ「目標設定と評価は難しい」について書こうと思います。(カジュアル面談をすると、ここを聞かれることも多いので。)

私は現在、株式会社ラクスでPdMとデザイナー組織を見ていますが、ここに至るまでにSIer、技術サポート、そしてBtoCプラットフォームの企画・開発と、多様な立場で「目標」と向き合ってきました。

いずれの環境においても難しさは感じていますが、現在のラクスでは自分がこれまで経験したことがない状況でしたので、より難しさを感じています。

もし今、あなたが自社の評価制度にモヤモヤしていたり、これからPdMとしてキャリアを積む上で「どう評価されるのか」に不安を感じていたりするのであれば、本記事はきっと何かのヒントになるはずです。

私がラクスで過ごした4年間の試行錯誤と、現在運用している評価の仕組みについて、かなり生々しい部分まで踏み込んでお話しします。

※本記事は自分のの経験に基づく一例で、制度や運用は組織・フェーズにより異なります

目次

比較してわかる「目標設定」の難易度格差

まず、前提としてお話ししたいのは、業種や職種によって「目標設定のしやすさとしにくさ」が存在するという事実です。

私が経験したキャリアを振り返ると、その違いは明白でした。

比較的シンプルだったSIと技術サポート

SIer時代や技術サポート時代、目標設定にそこまで頭を抱えた記憶はありません。なぜなら、見るべき指標が極めて明確だったからです。

  • SIer: プロジェクトの売上、利益率、納期遵守。

  • 技術サポート: 問い合わせ対応数、解決までのリードタイム、顧客満足度(CS)。

特に外資系企業にいた頃は、グローバルで定義されたメトリクスが決まっているため、それを達成するか否かという非常にシンプルな世界でした。

「全員野球」で乗り切れたBtoCプラットフォーム時代

前職のファッションEC(BtoC)では、企画・開発・デザイナー合わせて40名弱を管掌していました。ここでは「個人目標」という細かい粒度での設定は行わず、組織全体でのゴールを掲げていました。

BtoC、かつECというビジネスモデル上、ユーザーの行動と売上がダイレクトに結びつきます。

  • 売上直結KPI: 商品ページへの遷移率、カート投入率、購入率。

  • システム基盤: サイト遅延率、障害頻度。

これらを企画とエンジニアのセットチームに割り当て、「全員で売上を作らないとサービスが終了してしまう」という危機感(良い意味での当事者意識)を共有できていました。

数字が動きやすく、フィードバックループが速いため、「ざっくりとした方向性」でも組織が機能していました。

しかし、現在私が身を置く「ラクス」のようなBtoB SaaS企業では、この勝手が大きく異なるなと感じています。

なぜBtoB SaaS(SLG)の評価は難しいと感じたのか

ラクスに入社し、PdM組織のマネジメントを担うようになって直面したのは、前職までの経験が活用しづらい「3つの壁」を感じました。

1. ビジネスモデルの壁(SLG vs PLG)

最大の違いは、ラクスがSLG(Sales-Led Growth:営業主導の成長)モデルであることです。 BtoCやPLG(Product-Led Growth:プロダクト主導の成長)のSaaSであれば、「機能改善→ユーザー行動変容→売上増」のパスが比較的短く、KPIツリーも描きやすい。

しかし、SLGモデルの「楽楽シリーズ」では以下の特性があります。

  • ユーザー ≠ 決裁者: 機能が良くても、導入を決めるのは別の担当者であることが多い。

  • リードタイムの長さ: 1つの施策をリリースしてから、それが営業活動を経て「受注」という成果になるまでに長い時間がかかる。

  • 因果関係の遠さ: 受注が増えた要因が、新機能のおかげなのか、営業のトーク力なのか、市場要因なのかの切り分けが困難。

つまり、「購入率=受注率」「訪問者数=リード数」といった単純な図式が成り立たず、「プロダクトの価値づくり」単体での貢献を定量的に測るのが極めて難しいということを感じました。

2. 担当領域の範囲の壁(機能別組織の宿命)

前職では開発まで含めた全体を見ていましたが、現在はPdMとデザイナーという「企画・上流」に特化した組織を見ています。エンジニアリングは別の本部が管掌しており、私の組織の目標に「開発効率」や「システム安定性」を直接組み込むことはできません。

また、事業戦略そのものは事業部長の管掌であり、PdMはその事業戦略を元にプロダクト戦略や戦術に落とし込む役割が主として担っています。関与できる範囲が限定されている中で、いかに納得感のある目標を立てるかという難しさがありました。

3. 個人目標への落とし込み(MBOの厳格さ)

これが最も大きな違いかもしれません。ラクスでは半期に一度、MBO(目標による管理)によるパフォーマンス評価を行います。つまり、給与や賞与に直結する評価制度です。 そのため、「なんとなく頑張った」や定性的なアピールだけでは不十分で、第三者(人事や上位層)が見ても納得できる客観性と公平性が求められます。「恣意性が疑われない」ためにも、しっかりとしたロジックが必要です。

この「担当領域の成果が見えにくい中」で「厳格な個人評価」を行う。これが、私がこの4年間向き合ってきた難題の正体です。

ラクス流:納得感を生む目標設定のアプローチ

では、この難題に対して私たちはどうアプローチしているのか。4年間の試行錯誤を経て、現在運用している「型」についてお話します。

「あるべき姿」からのトップダウン設計

戦略が未整理な状態でボトムアップだけに寄せるとブレやすいと考えています。個人の想いは大切ですが、組織としてのベクトルが揃わなければ成果は出ないからです。 私は必ず以下の手順を踏んでいます。

  1. 組織目標の策定: 半年や1年で終わる数値目標だけでなく、数年先を見据えた「組織のあるべき姿」と言語化された「現状」をセットで定義
  2. マネージャー(私)の目標設定: 組織目標を達成するための自身の目標を策定
  3. リーダーへの展開と差配: 私の目標を噛み砕き、各リーダーに割り振る
  4. メンバー目標への落とし込み: ここで初めて個人の目標

このプロセスを経ることで、メンバーは「自分の仕事が組織のどこに繋がっているのか」を迷わずに認識できます。

評価の「ガイドライン」を作る

メンバーが目標設定に迷う時間を極小化するために、等級ごとの難易度や方向性のガイドラインを策定しました。

  • 事業・プロダクト貢献目標(70-80%): いわゆる業務の成果。

  • 組織貢献・自己成長目標(20-30%): 採用、育成、仕組み化など。

リーダー層には組織貢献の比重を高めるなど、グレードに応じたチューニングを行っています。これにより、目標設定にかかるコストを下げつつ、質の高い目標設定が可能になりました。

具体論:PdMは「何を」目標にするのか?

ここが皆さんが一番知りたいポイントかと思います。「売上に直結しない」「結果が出るのに時間がかかる」中で、PdMは何を目標に置いているのか。 結論から言えば、私たちは「アウトカムが出る蓋然性の高いアウトプット」を評価対象にしています。そして、“アウトカムの蓋然性が高いアウトプット”を評価する狙いは、顧客課題の解像度を上げ続け、提供価値の質を落とさないことにあります。

1. 事業・プロダクト貢献目標(仮説と品質の評価)

SLGモデルにおいて、リリース直後の「売上」や「利用率」を個人の短期評価にするのは酷です(前述の通りタイムラグがあるため)。そのため、以下のプロセスを完遂し、その質を担保することを目標とします。

  • 担当重要テーマのディスカバリーと要求仕様策定: 顧客課題を深く理解し、解決策としてのPRD(製品要求仕様書)を高い品質で仕上げたか。

  • デリバリーまでの完遂: エンジニアやデザイナーと協働し、仕様を落とすことなくリリースまで導いたか。

  • 次期バージョンの計画策定: 確度の高いロードマップを描けているか。

ここで重要なのは、「アウトカム(結果)」そのものではなく、「アウトカムが出る可能性があるという仮説」の精度と、それを実行する力を評価している点です。リリースサイクルが1〜3ヶ月かかる環境では、この「仕込み」の質こそが、将来の事業成長を左右するからです。

2. 組織貢献・自己成長目標(仕組みと基盤の評価)

こちらは、組織全体の生産性や再現性を高めるための活動です。

  • 共通指標(NSM [North Star Metric:長期的な成長と成功を示す最重要指標]など)の設定: 開発・事業が同じ方向を向くための指標作り。

  • AI活用による業務の標準化: 生成AIを用いたPRD作成の効率化など、個人の知見を組織の資産にする活動。

  • ナレッジシェア: 勉強会の主催やドキュメント化。

これらは、直接的な売上ではありませんが、「組織が継続的に勝つための基盤」として明確に評価します。

パフォーマンス評価とコンピテンシー評価の両輪

ここまでお話ししたのは、半期ごとの「パフォーマンス評価(MBO)」の話です。しかし、ラクスにはもう一つ、「コンピテンシー評価(行動評価)」が存在します。

  • パフォーマンス評価: 「何を」成し遂げたか(What)

  • コンピテンシー評価: 「どのように」行動したか(How)

note.com

たとえ短期的な数値目標が未達でも、そのプロセスにおいて、その等級に求められる再現性のある行動(周囲を巻き込む力、課題発見力など)が発揮されていれば、コンピテンシー評価で報われる仕組みになっています。

この「成果」と「行動」の二軸があるからこそ、難易度の高いPdMという職種でも、納得感を持ってチャレンジし続けられるのです。

最後に:ラクスでPdMとして働くということ

「目標設定が難しい」と嘆くだけでなく、私たちはその難しさを因数分解し、システムとして運用可能な形に落とし込んできました。 もちろん、これが完成形ではありません。事業フェーズの変化に合わせて、組織目標も評価の仕方もアップデートし続けています。

ラクスのPdM組織は、単に機能を作るだけの工場ではありません。 ビジネスの複雑性と向き合い、不確実性の中で仮説を立て、組織全体を巻き込んで価値に変えていく。そのプロセス自体を楽しみ、正当に評価される環境を作ろうとしています。

もしあなたが、 「目標があいまいで、自分の成果がどう評価されているかわからない」 「BtoBの難しさに直面しながらも、より本質的なプロダクトづくりに挑戦したい」 と感じているなら、ぜひ一度カジュアルにお話ししませんか?

ここでは書ききれなかった「泥臭い試行錯誤のリアル」や、あなたのキャリアにおける悩みについても、マネージャー対マネージャーとして、あるいは先輩PdMとして、ざっくばらんにお話しできると思います。私たちの組織は、こうした「難しさ」を一緒に面白がれる仲間を待っています。

●採用情報 デザイナー career-recruit.rakus.co.jp

  └ デザインマネージャー career-recruit.rakus.co.jp /アシスタントマネージャー career-recruit.rakus.co.jp

Copyright © RAKUS Co., Ltd. All rights reserved.