ラクスの職務経歴書｜6職種・製品別に実績を伝える書き方

ラクスの求人を見て、セールス、マーケティング、企画、エンジニアのどこで経験を生かすか迷っていませんか。複数のクラウドサービスと職種があるため、先に応募する職種と製品を一つ決め、対象業務へ直接対応する2〜3案件を選ぶことが職務経歴書の出発点です。

本記事では、SaaS経験を一括りにせず、営業工程、顧客獲得、製品企画、開発、体験設計、管理部門の責任差に分けます。製品名が似ているかではなく、誰のどの業務を変えたかを基準に実績を選びましょう。

最初に職種と製品を一つ決める

2026年8月15日に確認した公式キャリア採用一覧は、セールス、マーケティング、企画、エンジニア、デザイナー、コーポレートに分かれていました。最初に募集要項から、職種、製品、対象顧客、利用部門、主な責任、必須経験を書き出してください。

職種	職務経歴書の先頭に置く内容	避けたい書き方
セールス	顧客の業務課題、営業工程、提案・導入の担当範囲	売上数字だけ
マーケティング	対象顧客、仮説、施策選択、営業との連携	広告・イベント名だけ
企画	利用者課題、優先順位、開発・営業との合意	要望整理・資料作成だけ
エンジニア	業務課題、設計判断、品質・運用、責任境界	技術スタックだけ
デザイナー	利用者、調査、情報・体験設計、検証	制作物の見た目だけ
コーポレート	経営・事業課題、制度・統制、定着	定型業務量だけ

同じ職種でも対象製品と顧客規模により仕事は変わります。応募先の利用者・業務・営業方法を特定した後で、比較する求人を広げると、経歴のどこが強みになるか見つけやすくなるでしょう。

6職種で職務経歴書の中心を変える

セールスは担当工程まで分ける

公式一覧にはフィールドセールス、インサイドセールス、エンタープライズセールス、営業マネージャー、パートナーアライアンスなどが並びます。フィールドセールスなら課題把握から提案・合意、インサイドセールスなら対象選定と商談設計、エンタープライズなら複数部門の意思決定を中心にします。

「法人営業を担当」ではなく、誰のどの業務を理解し、どこからどこまで責任を持ったかを書いてください。受注後を別部署へ渡したなら、利用定着を自分の成果に含めません。

マーケティングと企画は判断の根拠を示す

マーケティングでは対象顧客と課題仮説、チャネルの選択理由、営業への受け渡し、実施後の学びを示します。企画では利用者の声や利用データから何を優先し、営業・カスタマーサクセス・開発とどう合意したかが要点です。施策名や機能名より、採らなかった案を含む優先判断が本人の責任を伝えます。

エンジニアとデザイナーは業務の変化まで追う

エンジニアは技術名だけでなく、担当製品、利用者、業務課題、設計判断、品質・性能・運用を一続きにします。デザイナーは調査、仮説、情報設計、開発との合意、検証を示します。BtoB SaaSでは管理者、承認者、実務利用者が異なるため、誰の操作や判断を改善したかを分けましょう。

製品の対象業務から案件を選ぶ

「SaaS企業で働いた」「バックオフィス向け製品を担当した」だけでは、応募製品との関係が分かりません。募集要項と公式事業説明から、対象顧客、利用部門、解く業務、販売・導入方法を確認してください。

確認軸	職務経歴書で書くこと	案件選択の基準
利用者	管理者、承認者、実務担当者など	同じ利用者の判断を扱ったか
対象業務	申請、精算、請求、販売管理など	同じ業務課題を理解しているか
導入方法	営業、導入、設定、定着、改善	担当工程が応募職種と合うか
製品連携	営業・CS・企画・開発との分担	他部門との合意を説明できるか

過去に扱った製品名が違っても、利用者・業務・意思決定が対応すれば隣接経験として説明できます。反対に、同じ製品区分でも本人の担当工程が違えば、その差を明記する必要があります。

扱う案件を七問で絞る

1. 応募職種の中核責任へつながるか
2. 対象顧客・利用者・業務を言えるか
3. 課題を知った根拠を説明できるか
4. 本人とチームの決定を分けられるか
5. 比較した選択肢と制約を言えるか
6. 受注・公開後の変化を追えるか
7. 数値の期間・対象・確認元を示せるか

七問のうち多くに答えられ、互いに異なる責任を示せる2〜3案件が候補です。案件の大きさより、利用者の課題から結果まで説明できることを優先してください。

一案件を利用者・課題・判断・結果へ分ける

項目	内容	注意点
対象	顧客規模、利用部門、利用者、期間	会社名を伏せても業務は残す
課題	誰が何を完了・判断できなかったか	本人の推測だけにしない
責任	権限、担当工程、成果物、関係者	チーム全体と分ける
判断	比較案、制約、選択理由、合意	他者が決めたことを借りない
実行	提案、設計、開発、運用、定着	自分の行動を具体化する
結果	数値、状態変化、残課題	期間・対象・確認元を添える

「DXを推進」「業務効率化に貢献」という言葉だけでは、どの業務が変わったか分かりません。導入前にできなかった判断や操作と、実行後に可能になった状態を対にしてください。

職種別の成果指標と確認元

職種	指標候補	確認元の例
セールス	商談、受注、継続、提案範囲	営業記録、契約、引き継ぎ資料
マーケティング	獲得、育成、商談、利用	施策記録、分析、営業連携資料
企画	利用、完了、継続、検証	利用データ、要件、検証記録
エンジニア	品質、性能、障害、開発速度	監視、課題管理、リリース記録
デザイナー	完了、迷い、問い合わせ、検証	調査、ユーザーテスト、利用データ
コーポレート	決算、採用、統制、業務時間	社内記録、制度文書、運用実績

数値には対象期間、分母、比較基準、本人の寄与を添えます。守秘で数字を出せない場合は、誰がどの業務を実行できるようになったかを具体的に記します。

経歴別に強調する事実を変える

経歴	強調する事実	確認したい不足
SaaS営業・CS	顧客業務、導入・定着、製品部門との連携	応募製品の利用部門理解
広告・マーケティング	対象定義、仮説、営業・製品への還元	BtoBの長い意思決定
事業企画・PdM	課題源、優先順位、関係者合意、検証	業務SaaSの運用理解
受託・自社開発	利用者課題、設計判断、品質・運用	製品の継続改善責任
管理部門	制度・統制、事業部合意、定着	成長に伴う変更対応

完全に同じ経験でなくても、対象業務と本人の判断が対応すれば隣接経験になります。ただし、経験していない導入・運用・マネジメントを、表現だけで担ったように見せないでください。

弱くなる書き方と改善例

弱い表現	改善する方向
SaaS営業として売上に貢献	［顧客・部門］の［業務課題］を確認し、［提案・合意範囲］を担い、［確認できる変化］を生んだ
広告施策を多数実施	［対象顧客］の［仮説］に対し［施策］を選び、［営業・製品判断への学び］を得た
新機能の企画を担当	［利用者課題］から［比較案］を作り、［関係部門］と合意し、［公開後の結果］を確認した
システム開発を推進	［業務課題］に対する［設計判断］と［担当範囲］を示し、［品質・運用の変化］を確認した

完成例を写すのではなく、事実を分ける順序だけを使います。自分が持っていない数字や責任は追加しないことが前提です。

必須経験と隣接経験を混ぜない

募集要項の必須経験を「直接ある」「隣接している」「まだない」に分けます。製品を利用した経験や研修だけで、経験職の営業、企画、開発責任を満たすとは判断できません。

不足を文章で隠すより、現職で顧客業務の把握、施策後の検証、他部門との合意を担う方が、次の応募で説明できる事実が増えます。応募可能性を断定せず、最新の募集要項で判断してください。

書類と面接の説明を揃える

案件ごとに、課題の発見元、比較案、本人が決めたこと、関係者との意見差、実行後の結果、失敗や変更を質問にします。書類で大きく見せた責任は、面接で具体的な行動を説明できません。

説明できない部分は削るのではなく、チーム成果と本人の担当を分けて正確に狭めると、むしろ再現性が伝わります。

ラクスの職務経歴書でよくある質問

複数製品に同じ職務経歴書を使えるか？

職歴の事実は共通でも、製品の利用者・業務・職種責任に合わせて要約と案件順を変えます。製品名だけを差し替える作り方は避けましょう。

SaaS未経験でも応募できるか？

個別求人の必須経験を確認します。法人営業、業務企画、Web開発など隣接経験が対応する場合は、対象業務と本人の責任を具体化してください。

成果数値を出せない場合はどうするか？

顧客や金額を伏せ、誰のどの業務が変わったか、本人が何を判断・実行したかを書きます。確認できない数字は作りません。

扱った製品が違っても経験を生かせるか？

利用者、対象業務、営業・導入工程、本人の判断が対応するかで見ます。同じSaaSというだけで同一経験とは扱いません。

職務経歴書には何案件を書くか？

応募職種の中核責任に直接対応し、互いに異なる強みを示す2〜3案件を中心にします。残りは職歴欄で簡潔に扱えます。

提出前に求人と実績を照合する

• 第一志望の職種・製品・勤務地が決まっている
• 対象顧客・利用者・業務を説明できる
• 主な責任へ対応する2〜3案件がある
• 本人の判断とチーム成果を分けている
• 数値の期間・対象・確認元を説明できる
• 提出直前に現行の募集要項を確認している

上記がそろっているなら、まず自分で書き進められます。製品選びで迷う、営業と企画のどちらを狙うか決められない、チーム成果と本人の担当を分けにくい場合は、応募前に経験を整理するとよいでしょう。

職種と製品を一つ決め、募集要項と2〜3案件を横に並べることから始めてください。ラクス向けの職務経歴書では、SaaSという大きな言葉より、利用者の業務と自分の判断が選考側の理解を助けます。

セールス求人は営業工程と顧客規模で分ける

ラクスの公式採用情報では、セールスの中にもフィールドセールス、インサイドセールス、エンタープライズセールス、営業マネージャー、パートナーアライアンスなど異なる役割があります。「法人営業を経験」とまとめず、商談の起点、顧客規模、意思決定者、提案から導入までの担当範囲を分けてください。

フィールドセールスへ応募するなら、顧客の業務課題をどう把握し、製品で解ける範囲と運用で補う範囲をどう整理し、決裁へ進めたかを示します。受注額だけでは、提案の再現性が分かりません。失注や条件変更から提案を修正した経験も、判断の根拠を説明できれば実務証拠です。

インサイドセールスでは、架電・メール件数より、対象顧客をどう定義し、反応や営業データから優先順位を変え、フィールドセールスへどの情報を渡したかが中心です。商談化後の受注をすべて自分の成果にせず、自分が管理した接点と引き継ぎ品質を区切ります。

エンタープライズでは、一社の中に複数の利用部門・管理部門・決裁者がいる前提で、合意形成を具体化します。営業期間が長いこと自体ではなく、部門ごとに異なる課題、セキュリティ・運用条件、導入範囲、社内の支援体制をどう整理したかが証拠です。アライアンスでは、パートナーとの役割分担と顧客へ届けた価値を分けます。

製品ごとに利用者と対象業務を読み替える

楽楽精算、楽楽明細、楽楽販売などは、同じクラウドサービスでも利用者と対象業務が異なります。製品名だけを差し替えた職務経歴書では、業務理解が伝わりません。個別求人と公式事業説明から、利用者、開始前の業務、製品導入後の判断、関係部門を抜き出します。

業務領域	確認する利用者	経歴で示す責任
経費精算	申請者、承認者、経理・管理部門	申請から確認・処理までの業務理解
帳票発行	発行部門、管理部門、取引先	作成・送付・受領に伴う運用設計
販売管理	営業、受注管理、請求・経理部門	部門をまたぐ情報と判断の整合
顧客接点・問い合わせ	営業・サポート部門、管理者	対応工程、情報共有、運用定着

前職で同じ製品区分を扱っていなくても、同じ利用者や業務上の判断に責任を持った経験は接続候補です。反対にSaaS企業で働いていても、応募職種と担当工程が違う場合、その差を隠してはいけません。直接経験、隣接経験、未経験を分けた説明が必要です。

マーケティングは営業への受け渡しまで書く

マーケティング経験は、広告、セミナー、コンテンツといった施策名だけでは判断できません。誰を対象にし、どの業務課題を仮説に置き、なぜそのチャネルを選び、営業へどの情報を渡し、施策後の結果から何を変えたかを一続きにします。

弱い例：オンライン広告とウェビナーを運用し、リード獲得に貢献。
改善方向：対象業種・部門の業務課題を営業記録から整理し、広告とウェビナーの役割を分けた。獲得後の反応を営業と確認し、対象条件・コンテンツ・受け渡し情報を改めた。

獲得数や商談数を書く場合は、対象期間、対象チャネル、重複の扱い、本人が担当した範囲を説明できるようにします。受注まで追えていない場合、受注への貢献を断定せず、営業が優先判断できる状態や顧客理解の改善を結果として残します。

企画は顧客要望を優先順位へ変えた過程を示す

企画職では、顧客要望を一覧化した事実より、利用者のどの問題を製品課題として扱い、何を今回の範囲から外し、営業・カスタマーサクセス・開発とどう合意したかが重要です。リリース後に利用や問い合わせを確認し、次の判断へ反映したところまでつなげます。

弱い例：新機能の企画と要件定義を担当。
改善方向：利用データと顧客の声から完了できない業務を特定し、事業・開発上の制約を基に優先順位を決定。採らなかった案と理由を関係部門へ共有し、リリース後の利用状態から次の改善を決めた。

機能数やロードマップの規模を本人の成果にしないでください。本人が課題設定、仕様、進行管理、検証のどこに責任を持ったかを明記します。PdMという肩書がなくても上流工程や業務設計を担った場合は、個別求人の必須経験と照合したうえで事実を示せます。

エンジニアは安定運用と変更判断まで説明する

公式エンジニア職種ページは、開発組織、職種、開発環境・技術スタック、学びと発信を分けて紹介しています。職務経歴書も技術欄と案件本文を分け、案件本文では利用者の業務、設計上の制約、比較案、実装・レビュー・運用の責任を中心にしてください。

弱い例：Javaを用いたSaaS開発と保守運用を担当。
改善方向：対象業務で変更頻度と安定性の両立が課題となる中、比較した構成と採用理由を整理。本人が設計・実装・レビュー・リリースのどこを担い、障害予防や変更容易性をどの記録で確認したかを示す。

障害件数や性能数値を開示できない場合、架空の割合へ置き換えません。監視で問題を検知できるようになった、復旧手順を共通化した、安全に変更できる範囲が広がったなど、確認可能な状態変化を使います。チームの技術選定と自分の判断は別々の証拠です。

デザイナーは管理者と実務利用者を分ける

BtoB SaaSでは、契約や設定を行う管理者、承認する人、日常操作を行う実務利用者が異なる場合もあります。ポートフォリオの画面だけでなく、誰を調査し、どの迷い・誤り・判断の遅れを課題とし、情報設計と体験設計をどう変えたかを職務経歴書に残してください。

開発との合意では、デザイン案を渡した事実だけでなく、技術・期間・既存仕様の制約をどう扱い、何を優先したかを示します。ユーザーテストや利用データがある場合は、その結果で当初案をどう修正したかまで説明すると、制作物を越えた判断が伝わります。

コーポレートは事業成長に伴う判断を示す

経理、人事、法務などの経験は、処理件数や制度導入だけで終えません。複数サービスや組織の変化によって、どの判断・統制・採用・運用が追いつかなくなり、経営・事業部門と何を合意し、導入後の例外や問い合わせからどう直したかを書きます。

全社の成果を本人だけの成果にせず、課題整理、選択肢の提示、制度設計、関係者調整、運用定着のどこを担ったかを区切ります。応募するコーポレート求人の必要スキルは個別募集要項を正本とし、別機能の要件を混ぜないでください。

職務経歴書と面接の説明を一致させる

主要案件ごとに、課題を知った根拠、本人の権限、比較した案、採らなかった案、関係部門との合意、結果の確認元を事実メモへ残します。セールスなら顧客の意思決定、企画なら優先順位、エンジニアなら設計上のトレードオフ、デザイナーなら調査と検証、コーポレートならリスクと運用が深掘りの対象です。

「主導」「改善」「達成」と書いた箇所は、チームの決定と本人の行動を分けて説明できるか確認してください。数値は対象期間、分母、確認元、本人の寄与を説明できる事実だけが対象です。固定の面接回数や質問を仮定するより、書類の因果関係を同じ順序で話せる準備を優先します。

ラクス公式情報を確認する順番

採用条件の正本は現行求人一覧から開く個別募集要項です。職種ページで役割の違いを理解し、事業ページで対象サービス、キャリアパスとFAQは応募前の補助確認に使います。環境や社員例を個別求人の必須条件へ読み替えてはいけません。

公式一次情報	職務経歴書での用途
キャリア採用求人一覧	現行求人と個別募集要項の入口
セールス職種紹介	営業工程・役割差の確認
マーケティング職種紹介	対象・施策・営業連携の確認
企画職種紹介	課題・優先順位・部門合意の確認
エンジニア職種紹介	組織・職種・開発文脈の確認
デザイナー職種紹介	利用者・調査・体験設計の確認
コーポレート職種紹介	事業を支える役割の確認
事業・サービス紹介	応募製品と対象業務の理解
キャリアパス	成長環境の補助理解
採用FAQ	応募前の最新確認

求人一覧の件数は更新されます。60件という観測値を採用人数や恒久的な求人数として使わず、提出日の個別ページを開き直してください。職種、製品、勤務地、仕事内容、必要スキルが変わっていれば、職務要約と主要案件の順序も最新情報へ合わせます。

提出前の最終監査

• 応募する職種・製品・勤務地を一つに特定した
• 個別募集要項の仕事内容と必要スキルを確認した
• 営業工程や職種の違いを混同していない
• 主要案件に利用者、課題、本人の判断、結果がある
• チーム成果と本人の責任を分けた
• 数値は期間・対象・確認元を説明できる
• SaaS利用経験や学習を実務経験へ大きく見せていない
• 書類と面接で同じ因果関係を説明できる
• 提出日に現行の個別求人を再確認した

監査後に職務要約だけを読み、「どの製品の、どの利用者・業務に対して、どの責任を任せられる人か」が分かるかを確かめます。分からない場合は案件を増やすより、応募先の特定と主要案件の順序を見直すことが先です。

未経験・隣接経験は不足まで明記する

ラクスのサービスを利用した経験、個人でSaaSを試した経験、研修受講は、業務で顧客・製品・組織に責任を持った経験と同じではありません。応募する個別求人の必要スキルを一行ずつ読み、「直接経験がある」「隣接経験がある」「まだ経験がない」に分けます。

セールスなら、継続利用を前提とする法人提案、複数部門の意思決定、導入後の引き継ぎが隣接候補です。企画なら業務システムの要件整理、利用者調査、開発との優先順位調整、エンジニアなら法人業務を支える安定運用、デザイナーなら管理者と実務利用者を分けた設計が接続候補になります。

隣接経験があるだけで応募条件を満たすとは断定しません。経験が足りない箇所は言い換えで大きくせず、現職で顧客業務の把握、施策後の検証、他部門との合意、運用定着まで担当できる機会を作る選択肢もあります。応募可否は提出日の個別募集要項が正本です。

複数社の職歴は応募製品との距離で並べる

職歴が長い場合も、すべての会社・案件を同じ分量で書く必要はありません。応募製品の利用者・業務・職種責任へ最も近い案件を詳しくし、古い経歴や関連の薄い仕事は、在籍期間、役割、主要成果が分かる範囲へ圧縮します。職歴自体を省いて空白を作るのではなく、説明量へ差を付けます。

同じ案件をセールスと企画の応募に使う場合、事実は変えず焦点を変えてください。セールスでは顧客課題、提案、合意、引き継ぎ、企画では利用者課題、優先順位、仕様、検証を先に置きます。自分が担っていない局面を応募職種に合わせて追加してはいけません。

守秘義務がある案件の具体性を保つ

顧客名、契約金額、社内指標、未公開機能、システム構成を開示できない場合もあります。固有情報を削った後に、「大手顧客」「重要案件」「大規模システム」という形容だけを残すと、本人の責任が見えません。顧客の業種・部門、対象業務、制約、比較案、担当工程、確認できる状態変化は一般化して残せます。

数値を別の架空数値へ置き換える方法は避けます。開示できる数値には期間、対象、確認元、本人の寄与を添え、開示できない場合は、顧客が導入へ合意した、営業が優先判断できる情報が整った、利用者が対象業務を完了できた、安全にリリースできる状態になったなど事実で説明してください。

応募直前に一件のJDと照合する

公式求人一覧から応募ページを開き、仕事内容と必要スキルを職務経歴書へ一行ずつ対応させます。各行の根拠となる案件を一つ指せるか、本人の責任を説明できるか、不足を別の経験で無理に埋めていないかを確認してください。複数の求人を比較していても、提出時の正本は一件です。

最後に職務要約、主要案件、面接用の事実メモを並べます。職務要約で約束した強みが主要案件で証明され、案件に書いた判断を事実メモで深掘りできる状態が合格条件です。求人名や製品名の置換だけで別ポジションへ提出せず、職種責任と案件順序を改めてください。

提出前には、選んだ製品の利用部門と、自分が成果を届けた相手が一致するかも確認します。顧客企業の管理者、承認者、実務利用者、社内の営業・開発など、関係者ごとの変化を分けると、同じSaaS経験でも応募製品への接続が明確です。確認できない効果は補わず、本人が説明できる判断と結果だけを残してください。