この職種で評価される実績
IT・SaaS業界のプロダクトマネージャーでは、担当業務を並べるだけでなく、業界課題に対してどの実績を出したかを明確にする必要があります。 以下の観点で数値化すると、採用担当者が再現性を判断しやすくなります。
IT・SaaS業界のプロダクトマネージャーでは、プロダクト戦略立案を「担当範囲・判断・成果」の順に書くと評価されます。
改善率で補強IT・SaaS業界のプロダクトマネージャーでは、開発優先順位付けを「担当範囲・判断・成果」の順に書くと評価されます。
担当規模で補強IT・SaaS業界のプロダクトマネージャーでは、ステークホルダー調整を「担当範囲・判断・成果」の順に書くと評価されます。
達成率で補強IT・SaaS業界のプロダクトマネージャーでは、KPI設計・管理を「担当範囲・判断・成果」の順に書くと評価されます。
短縮期間で補強STAR形式での書き方例
実績は「状況・課題・行動・結果」の順に分解すると、プロダクトマネージャーとしての判断力と成果が伝わります。抽象的な表現を、数字と役割が見える表現へ置き換えます。
プロダクト戦略立案を担当し、チームに貢献しました。要件定義を使って業務改善を行いました。
エンジニアに関する課題に対し、プロダクト戦略立案を主導。要件定義・ロードマップ策定を活用して 3か月で主要KPIを18%改善し、関係部門5名との運用定着まで推進しました。
Situation
IT・SaaS特有の背景
Task
開発優先順位付けの課題
Action
要件定義を使った行動
Result
数値で示せる成果
よくあるNG例
担当業務だけで終わっている
プロダクト戦略立案を「何人・どの範囲・どんな成果」まで分解して記載します。
業界文脈が薄い
エンジニア・プロダクトなど、IT・SaaS業界で評価される言葉に接続します。
スキル名だけを羅列している
要件定義・ロードマップ策定・ユーザーインタビューは、活用場面と成果をセットで書きます。
業界×職種別頻出キーワード
ATSや採用担当者の検索で拾われやすいよう、実績の文脈に自然に入れます。単語だけを詰め込むより、 成果文の中に含める方が読みやすくなります。
補足ガイド
SaaS業界でのPM需要は高まる一方、採用基準も年々厳格化しています。エンジニア出身のPMとビジネス出身のPMが混在する中、採用担当者が共通して見るのは「プロダクトの成果を数値で語れるか」と「エンジニア・デザイナー・経営との間で意思決定を動かした経験があるか」の2点です。
職務経歴書において最も差がつくのは、KPIの選定理由と改善施策の因果関係を論理的に記述できているかどうかです。「DAUを増やした」ではなく「ユーザーインタビュー18名を通じて特定した課題を解消する機能を優先リリースし、週次アクティブ率を3.2ポイント改善した」という水準の記述が求められます。
---
## 書き方のポイント5選
**1. 担当プロダクトのフェーズと規模を明記する**
0→1(PMF前)、1→10(グロース)、10→100(スケール)でPMに求められるスキルは全く異なる。プロダクトのARR規模・ユーザー数・チーム規模を記載することで、自分の経験フェーズが伝わる。
**2. KPI設計の意図を記述する**
「KPIはDAUとMRR」ではなく、なぜその指標を選んだか、North Star Metricとの関係を説明する。OKR設計経験がある場合は具体的なObjectiveとKey Resultを記載すると説得力が増す。
**3. 機能開発の優先順位付けプロセスを示す**
ROI・ICEスコア・ユーザーインタビューなど、どのような意思決定フレームワークを使って優先順位を決めたかを記述する。「バックログ100件から四半期スプリント計画で12件に絞った選定基準」のような具体性が評価される。
**4. ステークホルダー調整の実績を記述する**
経営・営業・エンジニア・デザイナーの利害が衝突する局面でどう調整したかを記載する。コンフリクトマネジメントの具体例はPMとしての成熟度を示す重要な証拠になる。
**5. 失敗からの学びも記述価値がある**
「リリースした機能が期待した効果を出せず、3ヶ月で撤退判断をした経験」のような失敗からの学びは、判断力と謙虚さを示す。失敗の原因分析と次の施策への転用を添えると評価がむしろ高まる。
---
## STAR形式 例文:SaaSオンボーディング改善プロジェクト
**プロジェクト:中小企業向けSaaSのオンボーディング完了率改善(PMとして主導)**
**Situation(状況)**
従業員管理SaaSにおいて、トライアル開始から14日以内の有料転換率が8.3%と業界平均(15%前後)を大きく下回っていた。解約アンケートと直接インタビュー(n=22)の分析から、初期設定の複雑さによるオンボーディング離脱が主因であることが判明した。CSチームへの問い合わせの58%が初期設定に関するものだった。
**Task(課題)**
PMとして、90日以内にトライアル→有料転換率を8.3%から12%以上に改善することをミッションとしてアサインされた。エンジニア3名・デザイナー1名・CSリード1名のクロスファンクショナルチームをリードした。
**Action(行動)**
① ユーザーインタビュー(22名)の定性データとプロダクトアナリティクス(Mixpanel)の定量データを組み合わせ、離脱が最も集中するステップ(従業員一括インポート画面)を特定。② Figmaでのプロトタイプを3パターン作成し、実ユーザー5名を対象にモデレートテストを実施して最有力案を選定。③ 開発優先順位をICEスコアで定量化し、エンジニアと工数交渉。全6施策を2スプリントで実装するロードマップを合意した。④ リリース後はMixpanelのファネル分析で週次モニタリングを実施し、リリース3週間後に追加の軽微修正を2件実施した。⑤ CSチームにリリースノートと対応スクリプトを事前共有し、問い合わせ対応の質を担保した。
**Result(結果)**
リリースから60日後に有料転換率が13.1%に達し、目標の12%を超過達成。CSへのオンボーディング問い合わせ数が月42件から18件に58%減少し、CS工数が月30時間削減された。この成果を起点に、翌四半期のプロダクト投資計画でオンボーディング改善チームの専任予算確保に貢献した。
---
## NG パターン3選
**NG1:「橋渡し役を担当しました」で終わる記述**
「エンジニアとビジネスサイドの橋渡しをしました」はPMの定義を言っているだけ。その橋渡しの中で何を意思決定し、どんな困難を乗り越え、何が改善されたかを具体的に示す必要がある。
**NG2:機能一覧の羅列**
「機能A・機能B・機能Cのリリースを担当」という記述は担当した事実を示すだけで、PMとしての判断力は何も示さない。優先した理由・リリース後の数値変化・学びを必ず添える。
**NG3:ユーザー声のみで判断した印象を与える**
定性情報だけでなく、定量データとの組み合わせで意思決定したプロセスを示す。データ分析ツール(Mixpanel・Amplitude・GA4等)を使った分析経験を明記することで、データドリブンなPMとしての信頼感が増す。
---
## IT・SaaS PMの差別化ポイント
他業界(受託SI・Web制作)のプロジェクトマネージャーとの差別化は「プロダクトの継続的な価値改善責任を持っているか」にあります。SaaS PMは単発プロジェクトではなく、ユーザーが継続利用し続ける仕組みを作ることが仕事です。チャーンレートの改善・LTVの向上・NPS向上といったサブスクリプションビジネス固有の指標を扱った経験は、SaaS企業への転職で明確な差別化になります。また、B2B SaaSにおけるエンタープライズ対応(SSO・監査ログ・権限管理)の要件定義経験もアピールポイントになります。
---
## FAQ
**Q1. エンジニアからPMへのキャリアチェンジです。どう職務経歴書を書けば良いですか?**
A. エンジニア時代の経験をPM視点で再解釈することがポイントです。「技術仕様の決定においてビジネス要件との優先順位調整を主導した」「スプリント計画でのバックログ整理に深く関与した」など、PM的な動きをしていた実績を掘り起こして記述してください。小規模なPM経験(社内ツール開発のリード等)があれば前面に出してください。
**Q2. PdMとPMの違いを聞かれる場合に備えて職務経歴書に書く際の注意点は?**
A. 企業によって定義が異なりますが、プロダクト戦略の意思決定責任を持っていたか(PdM)、プロジェクト進行管理が主だったか(PM)を正直に記述してください。KPI設計・ロードマップ策定・投資判断への関与があれば積極的にPdM的な経験として記述してください。
**Q3. プロダクトの詳細を守秘義務の関係で書けない場合はどうすればよいですか?**
A. 「BtoB SaaS・ARR3億円規模のHRプロダクト」のように業態・規模で表現することは一般的に許容されます。具体的な機能名や顧客名を伏せた上で、KPIの改善数値(パーセンテージ・ポイント等)は原則開示可能です。守秘義務の範囲について不安がある場合は応募前に前職の法務に確認することをお勧めします。
---
## IT・SaaS×プロダクトマネージャー・プロジェクトマネージャーの採用市場データ(2026年)
SaaS PMの求人数は2026年時点で2024年比40%増。書類通過率は20〜30%と厳しく、KPI改善の定量実績が必須です。エンジニアリングバックグラウンドを持つPMは特に希少で、CTO→PMというキャリアパスを歩む候補者が高評価を受けます。選考期間は5〜8週間で、ケーススタディや課題解決プレゼンが課されます。
---
## STAR形式 追加例文:IT・SaaSでの実績
### 例文2(応用):チャーン率改善プロジェクト
**Situation(状況)**
月次チャーンレートが3.5%に上昇し、新規顧客獲得コストを解約によるARR流出が上回る状況になっていた。定性的なCSチームへのフィードバックでは「使いこなせない」「ROIが見えない」という声が多く、オンボーディングの質に課題があることが推測された。
**Task(課題)**
PMとして、チャーン率を6ヶ月以内に2.0%以下に改善するためのプロダクト施策を立案・推進。CSチーム・エンジニアリングチーム・データチームと協働し、プロダクト改善の優先度設定と実行を担当した。
**Action(行動)**
① Mixpanelを使ったコホート分析でチャーンユーザーの行動パターンを特定。主要機能の初回利用率が低いことが判明。② オンボーディングチェックリストUI・プログレスバー・インタラクティブチュートリアルを実装し、機能発見率を向上。③ リスクスコアリング(直近7日間のログイン回数・機能使用頻度)でチャーン予備軍を自動検出し、CSが介入できるアラートシステムを構築。④ NPS調査とCSインタビューを月次で実施し、製品ロードマップへのフィードバックループを確立。
**Result(結果)**
6ヶ月でチャーンレートを3.5%→1.8%に改善。年間ARR保全額として約4.2億円相当。オンボーディング完了率が32%→71%に向上し、初月の機能利用率も48%改善した。
---
### 例文3(上級):0→1プロダクトのPMO推進
**Situation(状況)**
新規SaaS事業の立ち上げが決定し、競合調査・要件定義・MVP設計から商用リリースまでを8ヶ月で完了させる必要があった。エンジニア5名・デザイナー2名・CSリード1名の体制で、外部プロダクトとのAPI連携も含む複雑な開発が求められた。
**Task(課題)**
リードPMとして、要件定義から商用リリースまでの全工程を管理。月次でステアリングコミッティに進捗報告を行い、スコープ・スケジュール・コストのバランスを維持する責任を担った。
**Action(行動)**
① ユーザーインタビュー(30件)とジョブ理論分析でMVPスコープを確定。② 2週間スプリントのスクラム体制を構築し、バーンダウンチャートとEVM(アーンドバリュー分析)で進捗を可視化。③ 外部API連携の遅延リスクを早期特定し、モックAPIで並行開発を実現。④ クローズドβで20社50名の早期ユーザーからフィードバックを収集し、商用版に20件の改善を反映。
**Result(結果)**
予定通り8ヶ月でリリース。初年度ARR1.2億円を達成し、事業計画比120%を達成。β期間のNPS45はカテゴリ平均を15ポイント上回り、競合との差別化に成功した。
---
## 実績を数値化する3つの観点
数値化は職務経歴書の説得力を決定的に左右します。IT・SaaSのプロダクトマネージャー・プロジェクトマネージャーとして経験した実績を数値化する際は、以下の3観点で整理してください。
**観点1:インプット数値(規模感)**
自分が関わったシステム・プロジェクト・組織の規模を示します。
- Before: 「大規模プロジェクトを担当」
- After: 「年間予算3億円・関係者50名のプロジェクトを担当」
**観点2:アウトプット数値(行動量・改善量)**
自分の行動が生み出した変化を示します。
- Before: 「業務改善に取り組んだ」
- After: 「業務フローを再設計し、処理時間を従来比40%削減(週8時間→4.8時間)」
**観点3:ビジネスインパクト(金額・率)**
最終的にビジネスにどう貢献したかを示します。
- Before: 「売上向上に貢献した」
- After: 「施策の結果、対象プロダクトの月次売上が+1,800万円、年間ARRで+2.2億円増加」
数値が社外秘の場合は「前年比XX%向上」「業界平均比XX倍」など相対値や匿名化した形で記載できます。
---
## 提出前セルフチェックリスト10項目
職務経歴書提出前に以下10項目を必ずセルフチェックしてください。
- [ ] **1. 数値化の確認**:各実績に少なくとも1つの定量データが含まれている
- [ ] **2. 担当範囲の明確化**:「チームで実施」ではなく「自分が担当した部分」が明記されている
- [ ] **3. 直近重視**:直近2〜3年の実績が全体の60%以上を占めている
- [ ] **4. 専門用語の適切使用**:IT・SaaSで通用する業界固有の用語を正しく使っている
- [ ] **5. スキルと実績の紐付け**:スキルリストが実績の根拠として機能している
- [ ] **6. 誤字・表記統一**:社名・製品名・固有名詞のスペルが正確で表記が統一されている
- [ ] **7. チーム規模の記載**:各プロジェクトのチーム規模と自分の役割が明示されている
- [ ] **8. 読み手への配慮**:採用担当者(業界外の人事)が読んでも理解できる記述になっている
- [ ] **9. PDFの体裁確認**:PDF化した際にレイアウト崩れ・フォント崩れがない
- [ ] **10. NG用語の排除**:「キャリア実績」「転職活動」「転職希望者」「ES」等の用語が一切含まれていない
---
## IT・SaaS×プロダクトマネージャー・プロジェクトマネージャーの専門用語ガイド
**積極的に使うべき用語**: チャーンレート、MRR/ARR、DAU/MAU、LTV、NPS、OKR/KPI、プロダクトロードマップ、スプリントレビュー、バックログ管理、PMF(Product-Market Fit)、ユーザーインタビュー、コホート分析
**避けるべき用語・表現**: 「要件定義を行った」(誰とどんなプロセスで何を決定したかを明示)、「チームをまとめた」(具体的な成果に転換する)
---
## 採用トレンド2026
2026年のIT・SaaS採用では**AIエンジニアリング経験**が新たな差別化要素として台頭しています。LLMとのAPI連携・RAG構築・プロンプトエンジニアリングの実務経験は、バックエンド・フルスタック問わず加点評価されます。また、リモートファーストを維持しつつオーナーシップ文化(自律的な意思決定力)を重視する企業が増加しており、「誰かに指示されなくても動ける」証拠を職務経歴書で示すことが重要です。