この記事の3行要約
- プロダクトマネージャーの評価は「成果の因果×相対性×非代替性×プロセス品質×レバレッジ×持続性」の6点セットで構造化できる
- 評価者は時間不足・相対評価・事業優先・バイアスという現実の中で判断するため、短く因果で相対的に示すことが必須
- 期中の最小運用（毎日5分のDecision記録など）を回せば、期末評価はコピペ圧縮で完成する
評価は「運」ではなく「設計」で決まる
評価面談が終わってから「もっとうまく伝えられたはずなのに…..」と後悔したことはないでしょうか。多くのPdMが期末になって慌てて成果をまとめ、結局何が評価されたのか分からないまま次の期を迎えています。
しかし、「相手の判断プロセスを理解し、そこに最適化した情報設計をする」という原則に基づけば、評価も構造的にアプローチできます。評価者には評価者の現実がある。その現実に合わせて情報を構造化すれば、同じ成果でも評価は変わる可能性があります。評価は「何をやったか」だけでなく「どう伝えるか」で決まる設計可能なものなのです。
この記事では、「6点セット」という評価設計のフレームワークを紹介します。これは成果の因果、相対性、非代替性、プロセス品質、レバレッジ、持続性という6つの観点で成果を構造化し、評価者の現実に最適化して伝える方法です。
評価者の現実：時間不足・相対評価・事業優先・バイアス
まず押さえるべきは、評価者がどんな状況で評価をしているかという現実です。
1. 時間不足と情報過多
マネージャーは通常、5-10人のメンバーの評価を2-3日で書き上げなければなりません。1人あたり30分程度しか時間を割けない中で、長文の自己評価を読み込むのは物理的に不可能です。
一般的に、ビジネス文書は最初の部分が最も注目されるという傾向があります。だからこそ、Result（結果）を先頭に、8-12行で要点をまとめることが必須になります。
2. 相対評価とキャリブレーション
多くの企業では絶対評価ではなく（実質的な）相対評価が行われていることも多いです。部門横断のキャリブレーション会議（評価調整会議）では、「同じレベルの他のPdMと比べてどうか」という議論が必ず起きる。
評価者は常に「このレベルの上位何%に入っているか」を意識しています。つまり、社内四分位やパーセンタイルを明示することで、評価者の判断を助けることができるのです。
3. 事業優先の視点
評価者の上司（部門長や役員）は、OKRの進捗よりも事業KPIへの貢献を重視する傾向があります。「機能をリリースした」「実験を10回やった」という活動量ではなく、「売上が〇%増えた」「チャーンが〇%減った」という事業インパクトで判断される、ということです。
最終的には事業価値への翻訳が評価の分かれ目になります。
4. 認知バイアスとの戦い
評価者も人間です。近接効果（直近の出来事を過大評価）やハロー効果（一つの印象が全体評価に影響）といったバイアスから逃れられません。
だからこそ、一次証拠（ログID、スクショ、原文引用）をリンクで添付することで、主観を排除した評価を促す必要があるのです。
Q1：どんな成果を出したのか（アウトカム）
評価の起点は「何が変わったか」を明確に示すことです。ここで重要なのは、活動（アウトプット）ではなく成果（アウトカム）を明示的に数字で語ること。
事業/ユーザーKPIの前後差を示す
例えば、レコメンドシステムの改善を担当したとしましょう。
NG例：
「協調フィルタリングからディープラーニングベースの手法に移行し、精度が向上しました」
OK例：
「購買CVR：3.2%→4.1%（+28%）、客単価：8,500円→9,200円（+8%）。年間売上インパクト+1.2億円。施策前3ヶ月平均vs施策後3ヶ月平均の比較」
数字には必ずベースライン（施策前）と変化幅（絶対値と率）を併記します。さらに、測定期間を明記したり、季節性や外部要因の影響を考慮したりしていることを示します。
寄与分解と反実仮想
成果が本当に自分の施策によるものかを示すには、寄与分解（contribution analysis）が必要です。
例：「CVR向上+0.9ptのうち、アルゴリズム改善が+0.6pt、UI改善が+0.2pt、季節要因が+0.1pt。反実仮想：旧アルゴリズム継続の場合、CVRは3.5%（実績4.1%との差0.6pt）と推定」
反実仮想（counterfactual）とは、「もし自分の施策がなかったら」という仮想シナリオとの比較です。A/Bテストの対照群や、過去トレンドからの予測値を使って、施策の純粋な効果を切り出します。
Q2：相対的にどれだけすごいか（相対性）
また、絶対値だけでは評価者は判断できません。「28%改善」と言われても、それが良いのか悪いのか分からない。だから相対的な位置づけが必要なのです。
（前提として個人KPIとして指標と基準が設定されていることも多いと思いますが、変数の多いPdM業務ではそれ単体で評価しきれないケースもありますよね）
3つの比較軸
1. 社内四分位での位置づけ
「今期の全プロダクト施策（n=47）中、改善率で上位15%（7位/47施策）」
2. 前年同期比較
「前年同Qの改善率中央値12%に対して28%改善（2.3倍）」
3. 外部ベンチマーク
「業界ベストプラクティス（Netflix：年間20-25%改善）を上回るペース」
ボリューム×スピード×難易度
相対性は結果だけでなく、プロセスの効率性でも示せます。
- 「通常6ヶ月かかる機能を3ヶ月で実装（スピード2倍）」
- 「影響ユーザー数50万人（全体の65%）に展開（ボリューム）」
- 「レガシーコード改修を含む技術的負債の解消も同時実施（難易度）」
Q3：なぜ”自分”でなければ（非代替性）
さらに、評価で最も重要なのは、「誰でもできたこと」と「あなただからできたこと」の境界線を明確にすることです。
独自の洞察・意思決定・利害調整
洞察の例：
「ユーザーインタビュー23件から『検索ではなく偶発的発見を求めている』という潜在ニーズを発見。これを基に探索型UIへピボット」
意思決定の例：
「精度重視派と速度重視派で意見が割れた際、ユーザーセグメント別の優先度分析を実施。ヘビーユーザー（売上の70%）は速度を重視していることを定量証明し、速度優先の意思決定を主導」
利害調整の例：
「セールスチーム（早期リリース希望）と開発チーム（品質担保希望）の対立を、段階リリース案で調整。初回20%展開→問題なければ全展開という合意形成を実現」
代替案との比較
「他の選択肢もあった中で、なぜその方法を選んだか」を示すことで、判断の質を証明します。
「代替案A（外部ツール導入：初期費用500万円）、代替案B（既存改修：6ヶ月）と比較し、内製新規開発（3ヶ月・費用200万円）を選択。効いたメカニズム：既存のデータパイプラインを活用できる内製の方が、長期的な拡張性とコスト効率で優位と判断」
Q4：プロセスはどう秀逸だったか（再現性）
結果が良くても「たまたま」では評価されません。再現可能な方法論を持っていることを示す必要があります。
実験設計の質
対照群の設定：
「A/Bテストで統計的有意差（p<0.01）を確認。サンプルサイズは事前の検出力分析で決定（α=0.05、β=0.20、効果量d=0.3）」
ガードレールメトリクス：
「主要KPI改善と同時に、ガードレール指標（ページ速度、エラー率、CS問い合わせ数）をモニタリング。速度低下を検知し、キャッシュ戦略を追加実装」
意思決定ログの重要性
意思決定の過程を記録しておくことは、評価時の強力な武器になります。
「全ての意思決定をDecision Logに記録（計47件）。後から振り返ると、初期の仮説が誤っていたケースが30%。しかし、2週間スプリントでの軌道修正により、最終的に目標達成」
失敗からの学習サイクル
失敗を隠すのではなく、学習と改善のサイクルとして示すことで、成長性をアピールできます。
「初回リリースで離脱率が15%増加。ユーザビリティテスト実施により、新UIの学習コストが原因と特定。オンボーディングツアーを追加実装し、離脱率を元の水準まで回復。この経験を基に『新機能リリース時のオンボーディングチェックリスト』を作成し、チーム標準プロセスに」
Q5：レバレッジ（組織への波及）
個人の成果を組織の資産に変換できるPdMは、確実に高評価を得ます。
標準化・テンプレート化・ツール化
標準化の例：
「実験設計テンプレートを作成し、GitHub Wikiで公開。3ヶ月で8チームが採用、実験の手戻り率が40%→15%に減少」
ツール化の例：
「定型的なデータ分析をPythonスクリプト化。週8時間かかっていた作業を30分に短縮。他チームへ横展開し、組織全体で月160時間の工数削減」
採用率・再利用率・横展開数
数字で波及効果を示すことが重要です。
「作成したユーザーインタビューガイドの採用率：新規プロジェクトの75%（9/12プロジェクト）」
「PRDテンプレートの再利用：月平均12回、作成時間を平均2時間短縮」
「成功パターンの横展開：3プロダクトで同様の施策を実施、平均20%の改善」
自分不在でも回る仕組み
究極のレバレッジは、自分がいなくても価値を生み続ける仕組みを作ることです。
「定例のユーザーインタビュー会を設立。司会ローテーション制にし、現在は自分不参加でも月2回開催継続中」
Q6：持続性×コスト（リスク調整効率）
短期的な成果だけでなく、長期的な価値とコスト効率を示すことで、ビジネス感覚をアピールできます。
効果の定着と運用負荷
「リリース後6ヶ月経過後も効果が持続（CVR4.0-4.2%で安定）」
「運用負荷：初月は週5時間→自動化により現在は週30分」
「技術的負債：リファクタリングによりコード行数30%削減、保守性向上」
品質指標
「障害発生率：0.02%（業界平均0.1%の1/5）」
「ロールバック率：5%（前年15%から改善）」
「顧客クレーム：機能リリース後も横ばい（想定内）」
スピード×人時の効率
「開発期間3ヶ月×3名＝9人月で年間1.2億円の売上インパクト創出（1人月あたり1,300万円の価値創造）」
日常的にやること：最小運用で最大効果
ここまで読んで「期末にこれ全部まとめるのは無理」と思ったかもしれません。その通りです。だから日常的な最小運用が必要なのです。
毎日5分：Decision LogとKPIスナップショット
Decision Log：
「2024/3/15：レコメンドアルゴリズムをA案（精度重視）からB案（速度重視）に変更。理由：ユーザテストで0.5秒の遅延が離脱率10%上昇と判明」
KPIスナップショット：
「CVR：3.2%（baseline）→3.8%（現在）、外因：春のキャンペーン効果+0.1%と推定」
NotionやGoogle Docsに簡単な表を作って、毎日1行追加するだけです。
毎週30分：実験状態とビフォーアフター
「実験#24：検索結果の表示順変更：仮説検証中（n=5,000、3日目）」
「Before/Afterスクショ：トップページのCTRヒートマップ比較」
「関係者フィードバック原文：『新UIの方が直感的』（CSチーム田中さん、Slack #feedback）」
隔週15分：上司との3×3レビュー
上司とのミーティングで、以下の3×3グリッドを埋めていきます。
| 項目 | 今週の進捗 | 来週の予定 | 懸念点 |
|---|---|---|---|
| Decision | 速度優先に決定 | キャッシュ戦略検討 | メモリ使用量 |
| Experiment | A/Bテスト開始 | 中間分析 | サンプル不足の可能性 |
| Impact | CVR +0.6pt | 全体展開判断 | 季節要因の切り分け |
月次30分：成果の棚卸しと反実仮想
「有効セグメント：ヘビーユーザー（効果+35%）、ライトユーザー（効果+5%）」
「Top Impact施策の反実仮想：アルゴリズム改善なしの場合、CVRは3.5%に留まったと推定（実績4.1%、寄与度0.6pt）」
提出時の記述パターン：STAR+L形式
最終的な評価文書は、STAR+L形式（Situation, Task, Action, Result + Learning）で構造化します。
購買CVR：3.2%→4.1%（+28%）、年間売上インパクト+1.2億円。施策寄与度60%、季節要因10%、その他30%。対照群比較で統計的有意（p<0.01）。社内改善率ランキング7位/47施策（上位15%）。Action（何をどう変え、なぜ効いたか）：
協調フィルタリングからTransformerベースの推薦モデルへ移行。ユーザーインタビュー（n=23）から「セレンディピティある発見」ニーズを特定し、多様性スコアを導入。効いたメカニズム：コンテキスト理解の精度向上により、ユーザーの潜在的興味を補足。
Situation/Task（制約と代替案）：
レガシーシステムの制約で全面刷新は不可。代替案：A）外部API利用（月100万円）、B）既存改修（6ヶ月）。選択：段階的移行（3ヶ月）。
Learning（再現原則と次の一手）：
原則：定量データで仮説を立て、定性調査で真因を探り、小規模実験で検証。次：パーソナライズ精度向上（予測CTR改善20%目標）。
末尾一言：
「レベル+1接点：事業企画との週次連携により、プロダクト施策を収益貢献に直結させる動きを確立」
アンチパターンとその修正方法
評価でよくある失敗パターンとその修正方法をまとめます。
1. 出荷列挙
NG：「機能A、B、C、D、Eをリリースしました」
修正：「5機能の中で機能B（検索改善）が売上の80%に寄与。因果：検索精度向上→発見率増加→CVR改善の連鎖」
2. We病
NG：「チームで協力して達成しました」
修正：「田中さん（エンジニア）のアルゴリズム実装、山田さん（デザイナー）のUI設計の中で、私は要件定義と優先順位決定を担当」
3. 相関を因果と誤認
NG：「施策実施後、売上が増加しました」
修正：「A/Bテストで施策群が対照群を+15%上回る（p<0.05）。差分の差分法で季節要因を除去済み」
“6点セット×評価者の現実”を抑える
評価を「運」や「評価者の頑張り」に任せるのではなく、自ら6点セット（成果の因果、相対性、非代替性、プロセス品質、レバレッジ、持続性）を評価者の現実（時間不足、相対評価、事業優先、バイアス）に最適化して伝える。これが評価を設計する、ということです。
重要なのは、期末に慌てて準備するのではなく、日常的な最小運用を回すこと。毎日5分のDecision Log、週30分の実験記録、隔週の上司レビュー。これらを積み重ねれば、期末評価は「コピペして圧縮するだけ」になります。
最後に、評価は組織によって基準が異なります。でも、「短く、因果で、相対的に」という原則はどこでも通用する。なぜなら、評価者も人間だから。限られた時間で、公平に、事業価値を最大化したいという思いは同じなのです。
PdMが自分の成果を”正しく語れる”ようになる重要性でも触れられていますが、成果を正しく伝えることは、自分のためだけでなく、組織の学習のためにも重要です。あなたの成功パターンが言語化されることで、組織全体のレベルが上がるのです。
今日から実践できるアクション
1. Decision Logを始める（5分）
今すぐGoogle DocsかNotionに「Decision Log」というドキュメントを作り、今日の意思決定を1つ記録する。フォーマット：日付｜決定内容｜理由｜代替案
2. KPIのベースラインを記録（10分）
担当プロダクトの主要KPI3つの現在値を記録。3ヶ月前の値も調べて並記。これが全ての評価の起点になる
3. 上司との次の1on1でアジェンダ追加（1分）
「四半期の振り返りを3×3グリッド（Decision/Experiment/Impact）でやりたい」と提案メッセージを送る
Q&A
Q1. スタートアップで評価制度が整っていない場合はどうすればいいですか？
A1. 評価制度がなくても、この6点セットは「昇進」「昇給」「投資家向け説明」などあらゆる場面で使えます。むしろ制度がない分、自分で構造を提示することで、評価基準を作る側に回れるチャンスです。CEOや役員に「こういう観点で成果を報告したい」と提案してみてください。
Q2. 定量的な成果が出しにくい基盤系の仕事の場合は？
A2. 基盤系こそ「レバレッジ」と「持続性×コスト」で勝負できます。例：「CI/CD環境構築により、全チームのデプロイ頻度が週1→日3回に（生産性3倍）」「障害対応時間を月40時間→10時間に削減（工数75%減）」など、生産性や品質の指標を使いましょう。
Q3. 失敗プロジェクトでも評価される書き方はありますか？
A3. 失敗を「高速学習」として再定義します。「3ヶ月で仮説を棄却し、ピボット判断。この早期撤退により機会損失1億円を回避」「失敗から得た知見を基に、成功確率を測る新フレームワークを構築。次プロジェクトで適用し成功」など、失敗から価値を生み出したストーリーを作ることが重要です。
Q4. 複数の小さな改善の集積はどう評価してもらえばいいですか？
A4. 「改善の仕組み化」として訴求します。「週次改善サイクルを確立し、3ヶ月で23個の改善実施。個別は小さくても累積でCVR+15%。さらに改善プロセス自体をテンプレート化し、他チームも採用開始」のように、量×再現性で価値を示してください。
参考情報
1. OKRの基礎から実践までこれ1本 ー OKRで組織とプロダクトを変革する
2. 読まれるドキュメントにするPM向けのドキュメンテーション
3. PdMが自分の成果を”正しく語れる”ようになる重要性とその方法
4. Netflixのレコメンドシステムから学ぶ：PdMが押さえておくべき仕組みと進化
コメント