PKSHA Technologyの職務経歴書｜職種別に実績を伝える書き方

研究、開発、顧客導入のどこで責任を持ったかを先に決めると、PKSHA Technologyへ提出する職務経歴書は書きやすくなります。「AIに関わった経験」を広く並べるのではなく、応募職種と代表案件の責任範囲を対応させてください。アルゴリズムエンジニア、ソフトウエアエンジニア、BizDev、プロダクトマネージャー、カスタマーサクセスでは、同じプロジェクトでも注目される工程が異なるからです。

PKSHA Technologyの公式採用情報と現行求人を基に、過去経験を課題・制約・判断・実装または定着・結果へ分け、職務要約、職務詳細、自己PRへ配置する方法を解説します。目的は、実在人物の完成例を写すことではなく、自分の事実を守秘義務に配慮して編集できるようにすることです。

最初に応募職種を一つ決める

書き始める前に、第一候補の職種を一つ選びます。複数職種に関心があっても構いませんが、1通の書類で「研究も開発も事業も幅広く挑戦したい」とまとめると、本人がどの成果に責任を持てるのか見えにくくなります。

第一候補	職務経歴書の中心	代表案件で答える問い
アルゴリズムエンジニア	データ・評価・手法選定と社会実装への接続	どの制約下で、なぜその設計を選んだか
ソフトウエアエンジニア	AIや業務要件を利用可能なシステムへ組み込む工程	信頼性・運用性・連携をどう成立させたか
BizDev	顧客課題の再定義、提案、技術チームとの合意、導入	曖昧な相談を何の課題へ変え、誰を動かしたか
プロダクトマネージャー	顧客課題、価値仮説、優先順位、リリース後の学習	何を作らないと決め、結果から何を変えたか
カスタマーサクセス	導入条件、利用定着、顧客成果、改善のフィードバック	契約後に利用できる状態をどう作ったか

応募求人が変わる場合、経歴や数値を書き換える必要はありません。職務要約の結論と代表案件の順番を、各求人の成果責任に合わせて変えます。

PKSHAの事業循環を、経験を置く地図にする

PKSHA Technologyの公式ページは、研究開発、顧客別のAI Solution、プロダクトとして提供するAI SaaSが相互にフィードバックする構造を示しています。採用メッセージでは、AI Research & Solution、AI SaaS、AI Powered Workerの事業レイヤーと複数のカンパニーも案内されています。

職務経歴書で会社説明を長く書く必要はありません。この構造は、自分がどの接点で価値を出してきたかを判断するために使います。

接点	使える経験	追加すると具体的になる情報
Research	データ設計、評価設計、モデル・手法の検討、研究開発	制約、比較案、採用理由、技術的限界
Solution	顧客課題の定義、提案、個別開発、業務への組み込み	顧客との合意、本人の担当、実運用までの距離
SaaS	プロダクト開発、信頼性、外部連携、導入、利用定着	継続利用の条件、利用後の反応、改善の意思決定
人とAIを組み合わせる事業	業務設計、プロジェクト推進、利用者支援、事業開発	人が担う判断とソフトウエアに委ねた工程

この区分は配属組織を確定するものではありません。現在の職務範囲、雇用主体、配属は、応募する個別求人と採用担当者の案内を優先してください。

代表案件は7項目の原始メモから選ぶ

完成文を先に作ると、「高度な技術を活用」「顧客に寄り添った」といった抽象語が増えがちです。まず案件ごとに事実を分け、その後に応募書類へ縮めます。

1. 利用者・顧客と、解く必要があった業務課題
2. データ、技術、期限、体制、規制などの制約
3. 比較した選択肢と、本人が選んだ理由
4. 本人が実装・提案・推進した範囲
5. 顧客、上司、他職種が担った範囲
6. 結果と、その測定条件
7. 利用後の反応や失敗から変えたこと

代表案件は、規模が最も大きいものではなく、この7項目を説明でき、応募職種の仕事に近いものを2〜3件選びます。成果が大きくても本人の寄与を分けられない案件は、補助実績へ下げた方が説明しやすくなります。

自分の実績として書くのは、質問を受けたときに担当範囲と根拠を説明できる事実だけです。第三者の成果を含む数字や、後から確認できない数字を強く見せるために補わないでください。

前職の経歴ごとに、最初に見せる証拠を変える

同じ求人へ応募しても、前職によって読み手が確認したい不足は異なります。経験をPKSHAの仕事と同じだと言い換えるのではなく、つながる行動と未経験の工程を分けてください。

主な前職	先に見せる証拠	補う説明	避ける飛躍
研究者・データサイエンティスト	課題設定、評価設計、手法選定、再現可能な検証	顧客対話、ソフトウエアへの組み込み、運用への関与	研究成果だけで社会実装まで担ったとする
Web・バックエンド・クラウドエンジニア	API、データ基盤、可用性、外部連携、保守運用	モデル提供やデータ特性を踏まえた設計判断	AI機能に接続しただけでモデル開発経験とする
SIer・ITコンサルタント	要求整理、要件定義、複数部門調整、リリース推進	技術チームへ渡した評価条件と、導入後の利用状態	プロジェクト全体を本人単独で動かしたとする
SaaS営業・カスタマーサクセス	顧客課題、導入条件、利用定着、製品側への改善入力	技術的な制約をどう確認し、誰と合意したか	契約実績をプロダクト改善の実績へ読み替える

たとえばバックエンドエンジニアがアルゴリズムエンジニアへ応募する場合、API開発を機械学習研究へ言い換えるのは不適切です。一方、モデルを安定して提供する仕組み、データ更新、監視、機械学習担当者との設計判断は、社会実装に近い経験として担当範囲を明示できます。

リメディの見解では、隣接経験を強く見せるときほど「できること」だけでなく「専門担当へ委ねたこと」を一文入れる方が、役割の境界を確認しやすくなります。弱みの告白ではなく、協働時の判断を示すためです。

PKSHAの5職種に照合できる証拠台帳を作る

アルゴリズム、ソフトウエア、BizDev、PdM、CSでは、同じ案件でも評価につながる工程が違います。最初から文章にせず、案件ごとの台帳を作り、PKSHAで応募する職種の仕事内容との近さと説明可能性で並べ替えます。

台帳の列	記録する内容	確認先
対象と課題	匿名化した利用者、業務、変えたかった状態	当時の職務分掌、公開可能な案件概要
制約	データ、性能、期限、体制、法務・セキュリティ	記憶だけで断定せず、開示可能な範囲を上司・規程で確認
本人の判断	比較案、採用理由、対象外としたこと	設計・提案時に本人が決めた範囲
協働	誰に何を依頼し、どこで合意したか	役割分担と承認者
結果	数値または到達状態、計測条件	持ち出し可能な記録ではなく、許可された事実の確認
次の変更	利用後、失敗後、振り返り後に変えたこと	後続案件で実際に採用した行動

台帳には「応募書類へ掲載」「面接だけで補足」「守秘義務のため非掲載」の列も追加します。職務経歴書を短くするために削る情報と、外部へ出せないために削る情報を混同しないのがポイントです。

代表案件を選んだ後、応募求人の仕事内容を横に置きます。対応する経験が一つもない仕事内容は、抽象的な自己PRで埋めず、隣接経験として説明できるか、応募前に補うべきかを判断してください。

アルゴリズムエンジニアは「精度の先」を書く

AI Research & Solutionのアルゴリズムエンジニア求人は、表形式データ、自然言語、画像などを使う設計・実装だけでなく、課題・制約に合う提案、分析結果の説明、Web API等への組み込み、社会実装可能な水準までの研究開発、横展開を職務として挙げています。

そのため、使用モデルと精度だけでは途中までしか伝わりません。案件の始点と終点を足します。

確認項目	原始メモで残すこと
課題	予測、分類、検知等が、どの業務判断を変えるために必要だったか
データ	量だけでなく欠損、偏り、ラベル、更新頻度、利用許諾の制約
評価	ベースライン、指標、誤りのコスト、速度や説明可能性との両立
実装	API、バッチ、監視等へ、どこまで本人が関与したか
運用	モデルやデータの変化を何で検知し、何を更新したか

たとえば「自然言語処理モデルの開発を担当」を、[問い合わせ分類の業務課題]に対し、[データ制約]を踏まえて[比較した手法]から[採用案]を選び、[評価条件]で検証。本人は[実装・説明・組み込みの範囲]を担い、[利用後の変更]まで進めた、という構造へ変えます。角括弧に入れるのは、本人が確認できる事実に限ります。

ソフトウエアエンジニアは「使われ続ける条件」を書く

公式オープンポジションにある業務例は、AI SaaSの対話エンジン用バックエンド、機械学習以外のロジック、モデルを提供するアプリケーション、他サービスとの連携です。AI Solutionでは機械学習を軸にしたアプリケーション、MaaS領域ではIoTや画像・動画解析に関わる開発も示されています。

職務詳細では、技術スタックの一覧より、システム境界と設計判断を先に置いてください。

• 誰が何の場面で使うサービスだったか
• モデル、アプリケーション、データ基盤、外部サービスの境界
• 性能、信頼性、セキュリティ、保守性のうち何を優先したか
• 障害、負荷、仕様変更を受けて何を変えたか
• 機械学習エンジニア、PdM、BizDev、顧客との意思決定の分担

「APIを開発した」で終えず、[利用場面]に必要な[応答・可用性・連携等の条件]を定め、[設計上の比較]から[採用した構成]を選び、[運用で得た反応]を受けて[変更したこと]まで示すと、使われ続けるための判断が明確です。

BizDevは顧客の言葉を技術課題へ変えた過程を書く

AI Research & SolutionのBizDev求人は、顧客の課題・ニーズを捉え、ソリューションを企画し、社会実装へ進める役割です。必須経験の例には、戦略・業務・DXコンサルティング、エンジニアが参加するプロジェクトの管理、デジタルビジネスの企画・立ち上げ・運用などがあります。

売上や提案金額だけでは、技術と顧客の間で何を決めたかが分かりません。次の変換を一続きにします。

職務経歴書では「AI導入を提案」ではなく、顧客が当初求めていたこと、確認して分かった真の制約、検討対象から外した案、エンジニアと合意した評価条件、本人が担った導入工程を分けて記載してください。

PdM・CSはリリースや導入の後まで書く

AI SaaSのプロダクトマネージャー求人には、製品価値の定義、顧客課題の深掘り、社内外への提案、エンジニアとの協働が含まれます。カスタマーサクセス求人では、法人顧客との接点と、プロジェクトを遂行した経験が要件です。

職種	書類で弱くなりやすい終点	追加する事実
PdM	機能をリリースした	顧客課題、優先順位、採らなかった案、利用後の学習、次の判断
CS	導入を支援した	利用開始条件、定着の障害、社内外調整、利用状態、製品側へ戻した情報

PdMで中心になるのは、作った機能の数より、限られた開発資源を何へ配分したかという意思決定です。CSでは、契約後の連絡回数ではなく、顧客が利用できる状態へ変わった過程を示してください。チームの売上や継続実績を使う場合は、本人の担当範囲を分けます。

PKSHAの職種ごとに異なる指標の条件をそろえる

アルゴリズム職のモデル指標、ソフトウエア職の性能・運用指標、BizDev・PdM・CSの事業・顧客指標では、分母も測定方法も違います。比較条件をそろえずに数値だけを並べると、PKSHAのどの成果責任へつながる実績か判断できません。

数値の種類	併記する条件	混ぜないもの
モデル指標	対象データ、評価条件、ベースライン、期間	別データセットや本番指標
システム指標	対象機能、負荷条件、計測期間、変更内容	サービス全体と担当機能
事業・顧客指標	対象顧客、利用段階、計測期間、本人の施策	会社・チーム全体と個人寄与
プロジェクト規模	工程、期間、体制、本人の役割、完了条件	予算規模と本人の裁量

開示できない数値は推測しません。対象業務、制約、比較、担当範囲、到達した状態を定性的に書き、面接で確認されても守秘義務を越えない粒度が必要です。

PKSHAの面接まで同じ案件を三層で使う

PKSHAの応募職種へ接続する同じ案件でも、職務要約、職務詳細、面接用メモでは情報量が違います。すべてを本文へ詰め込まず、読み手が最初に知るべき責任範囲から段階的に詳しくします。

置き場所	残す情報	省く情報
職務要約	専門性、代表課題、担った工程、到達状態、応募職種	技術選定の細部、全案件の列挙
職務詳細	課題、制約、本人の判断、実行、協働、条件付きの結果	判断に影響しなかった周辺情報
面接用メモ	比較案、反対意見、失敗、途中変更、再現条件、本人の限界	社外秘、個人情報、契約上開示できない事項

アルゴリズム案件なら、職務要約には「需要予測の評価設計から業務システムへの接続まで担当」といった責任範囲を置きます。職務詳細ではデータ制約、比較した手法、業務上の誤りの扱い、実装連携を示し、面接用メモには不採用案や本番化の判断材料を残すという分け方です。

BizDev案件なら、職務要約では顧客課題の再定義と導入工程を示し、職務詳細で検討対象・評価条件・技術チームとの合意を説明します。面接用メモには、顧客の当初要望をそのまま採らなかった理由、導入を見送った条件、次の提案で変えたことを残してください。

この3層を分けると、本文を短くしても判断の根拠を失いません。また、面接で初めて思い出した情報が職務経歴書の記載と食い違う事態を防ぎやすくなります。

PKSHAの第一志望を職務要約の冒頭に置く

職務要約は経歴の年表ではありません。PKSHAで第一志望にする職種と、その仕事内容へ接続する代表経験を冒頭に置き、この書類の読み方を示します。

1. 現在の専門性と経験領域
2. 代表的な課題と担った工程
3. 測定できる成果または到達状態
4. 応募職種で再現したい経験

職務詳細は会社ごとの時系列を保ちながら、各社内では応募職種に近い案件を先に置いてください。案件名の直後に「課題 / 本人の責任 / 結果」を短くまとめ、その後に判断と協働の詳細を続けます。

弱い表現を事実の構造へ直す

弱い表現	不足しているもの	修正する問い
AIプロジェクトを推進した	課題、本人の判断、終点	何を決め、どの工程を動かし、どこまで到達したか
高精度なモデルを開発した	評価条件と業務上の意味	何と比べ、どの誤りを重く見て、利用判断にどうつながったか
顧客に寄り添った提案を行った	確認・比較・合意の内容	顧客の言葉をどの課題へ変え、何を対象外にしたか
部門横断で連携した	役割境界と対立点	誰と何を決め、意見が違った点をどう処理したか
プロダクト成長に貢献した	本人の施策と測定条件	どの利用者行動を変え、何を見て次の判断をしたか

強い形容詞を足すのではなく、読み手が事実関係をたどれるように直します。すべての案件で同じ型を繰り返す必要はありません。アルゴリズム案件なら評価判断、開発案件ならシステム境界、BizDev案件なら課題変換を厚くしてください。

自己PRは専門性と接続方法を一組にする

「分析力」「推進力」「顧客志向」だけでは、PKSHAのどの仕事で使える強みか判断しにくい表現です。自分が判断できる領域と、他者の専門性へつなぐ方法を一組にするのが要点です。

• 専門性: どの課題・技術・業務なら、自分で比較して判断できるか
• 接続: 顧客、研究者、エンジニア、事業側の間で何を翻訳できるか
• 根拠: 代表案件で実際に行ったこと
• 再現条件: 応募先で同じ強みを使える状況
• 限界: 他職種の判断に委ねる範囲と、未経験の領域

たとえば「機械学習の専門性」だけでなく、「評価指標と業務上の誤りのコストを整理し、顧客・開発者と実装条件を決める」と書けば、専門性を価値へ接続する行動が明確になります。

AI・SaaS案件の守秘義務を守りながら具体性を残す

AI・ソフトウエア案件では、顧客名、元データ、モデル構成、セキュリティ設計、未公開機能など、外部に出せない情報が少なくありません。具体性は秘密情報の多さではなく、判断過程の明確さで作れます。

情報	安全な処理	残せる具体性
顧客・サービス名	業界・利用場面へ匿名化	誰のどの業務を変えたか
元データ	項目名・規模・入手経路を必要最小限へ	欠損、偏り、更新等の制約
モデル・構成	未公開の詳細を削る	比較軸と採用理由
数値	社内規程に従い、非開示なら定性化	計測方法と到達状態

アルゴリズム職なら未公開のモデル詳細、ソフトウエア職なら構成・セキュリティ、BizDevなら顧客の事業情報、PdM・CSならロードマップや利用状況が境界になります。削る情報を職種ごとに分けても、比較軸、本人の判断、実装や定着の到達状態は残せます。

退職時に社内資料や顧客データを持ち出すことは勧めません。本人用の根拠メモには、許可された記録をどの項目で確認したかだけを残します。

志望動機・面接と同じ貢献仮説へそろえる

職務経歴書の代表案件は、志望動機の根拠であり、面接で深掘りされる材料です。3つの書類・場面で主張を変えないようにします。

場面	役割	同じにする核
職務経歴書	過去に行ったことの証拠	課題、判断、担当範囲、結果
志望動機	なぜPKSHAのその職種で再現したいか	価値を出す接点と貢献仮説
面接	判断過程、別案、失敗、再現条件の説明	本人の寄与と限界

応募理由をまだ固めていない場合は、PKSHA Technologyの志望動機の作り方で、Research・Solution・SaaSのどこに貢献するかを整理できます。選考全体の準備は、PKSHA Technologyの選考難易度と対策で確認してください。

応募前に求人条件と書類のずれを確認する

最後に、公式求人の「仕事内容」と「必須要件」を、職務要約と代表案件へ一つずつ対応させてください。歓迎要件を満たしていても、主な仕事内容との接続が弱ければ、案件の順番を見直す必要があります。

要件との対応は、「職務詳細に証拠がある」「隣接経験として説明できる」「現在は証拠がない」に分けます。証拠がある案件は前方へ移し、隣接経験は共通する行動と未経験工程を分け、証拠がない要件は学ぶ意欲だけで満たしたように書きません。

アルゴリズムエンジニアの顧客対話、BizDevの技術プロジェクト、PdMのエンジニアとの協働など、職種境界にある要件ほど、単なる「連携経験」ではなく、相手へ渡した情報と共同で決めた事項を確認してください。

• 第一候補の職種が職務要約の冒頭で分かるか
• 代表案件が求人の主な仕事とつながっているか
• 本人が担った範囲と他職種の範囲を分けたか
• 検証、本番、運用、定着のどこまで進んだか正確か
• 求人の更新日と、現在の配属・雇用主体を再確認したか

PKSHA Technologyだけに限定せず、AI・ソフトウエア企業の求人も比較すると、自分の経験に近い職種名と業務範囲を確認できます。

提出前チェック

• 応募職種を一つに絞り、職務要約の冒頭に置いた
• 代表案件を課題・制約・判断・担当・結果へ分けた
• アルゴリズム、システム、顧客、事業のうち本人の責任範囲を明示した
• 数値の期間・条件・分母と本人の寄与を確認した
• PoC、本番導入、利用定着を混同していない
• 顧客名、データ、未公開仕様、個人情報を安全な粒度にした
• 志望動機と職務経歴書で、応募職種と貢献仮説が一致している
• 最新の個別求人で仕事内容と要件を再確認した

条件面も含めて応募判断を進める場合は、応募する個別求人の雇用条件を別に確認してください。職務経歴書には給与情報を混ぜず、応募職種との接続に集中させます。

PKSHA Technologyの職務経歴書に関するよくある質問

複数職種へ応募するとき、同じ職務経歴書でよいですか？

経歴と数値の事実は共通で構いません。ただし、アルゴリズムエンジニア、ソフトウエアエンジニア、BizDev等では成果責任が異なるため、職務要約の結論と代表案件の順番は求人ごとに変えます。第一候補の職種を曖昧にした一つの汎用版で済ませない方が、経験との接続を確認しやすくなります。

AIの実務経験が短くても書けることはありますか？

経験期間を長く見せる必要はありません。データ・モデルの実務が短い場合でも、ソフトウエア開発、顧客課題の整理、プロジェクト推進、SaaS導入など、応募求人に接続する隣接経験があれば、担当範囲と未経験部分を分けて示せます。個別求人の必須要件を満たすかは、最新の募集要項で確認してください。

精度や売上を開示できない場合はどうしますか？

数値を推測して補わず、対象業務、制約、比較した選択肢、本人の判断、担当範囲、到達した状態を書きます。「改善した」とする場合は、何を見て変化を確認したかを説明できるようにします。社内規程や顧客との契約を優先してください。

PoCで終わった案件は書かない方がよいですか？

課題設定や技術判断の証拠になるなら記載できます。ただし、本番導入や社会実装まで進んだように広げません。検証目的、評価条件、本人の担当、見送った理由、次の判断に残したものを正確に書きます。