JDSCのFDE求人における「経験不問」の範囲と応募条件

2026 10/25

2026年10月8日 2026年10月25日

著者: Walkers編集部公開: 2026年10月8日最終更新: 2026年10月25日

株式会社JDSCのFDE（Forward Deployed Engineer）採用では、公式求人において「FDEの実務経験」および「AIプロジェクトの経験」が不問とされています。一方で、「2年以上のソフトウェア開発経験」と「曖昧な要件を関係者との対話で整理して実装へ進めた経験」は必須条件として明記されています（2026年10月19日確認）。選考における合否や応募資格の充足に関する最終判断は企業側に委ねられますが、応募を検討する技術者自身が実務経験と募集要件の対応関係を正しく整理しておくことは重要です。本記事では、公式求人の区分を確認したうえで、機械学習や大規模言語モデル（LLM）を扱っていない開発経験から、要件整理と実装の実績を明確に伝える手順を整理します。

必須・歓迎・不問の範囲を確認する

JDSCの採用募集ページに記載された条件を確認する際は、公式に提示されている「必須要件」「歓迎要件」「不問とされている事項」の区分をそのまま把握することが基本となります。歓迎要件に含まれるLLMとは大規模言語モデルを指し、RAG（Retrieval-Augmented Generation）とは外部の文書やデータベースを検索して回答を生成する仕組みのことです。

区分	公式記載の要約	読者が確認する点
必須	開発経験2年以上、曖昧な要件を対話で整理し実装に進めた経験	実際の開発実務における従事期間、関係者との合意形成から実装まで自ら担当した実績があるか
歓迎	Python、LLM/RAGの活用、クラウド、業務改善等	実務での活用実績があるか、あるいは個人学習として取り組んでいる範囲かを整理できるか
不問	FDE実務経験、AIプロジェクト経験、学歴、特定資格	公式求人でAIプロジェクト経験やFDE実務経験が不問と指定されている範囲を確認し、必須要件である開発経験と区別して整理する点
未記載	出社頻度、英語条件（リモート可の記載あり）	求人票に記載がない項目について、英語が一切不要であることや完全在宅勤務を意味すると即断しない点

公式求人において、学歴や特定資格、AIプロジェクトの直接的な経験は不問とされています。一方、出社頻度や英語に関する条件は求人票本文に記載されていません。記載がないことをもって「英語力が完全に不要」「全日フルリモートが可能」と判断することはできないため、実際の運用体制については選考過程の面談等で確認する必要があります。

AIを使わない開発案件でも、課題整理の経験を説明できる

AIや機械学習の導入を伴わない従来のWebアプリケーションや社内基盤の開発であっても、仕様が固まっていない状況から関係者と調整して実装へ落とし込んだ実績があれば、必須要件に対応する経験として説明できます。

以下は、編集部が作成した架空の案件例です（実在の案件や測定数値ではありません）。

非AI案件における対話から実装までの担当ステップ

1. 曖昧な要望部門ごとに運用が異なり差し戻しが頻発
2. 対話による整理関係者へ聞き取り共通点と個別例外を抽出
3. 仕様の判断通常申請の自動化と例外承認の分岐を策定
4. バックエンド実装画面設計は他者が担い分岐APIを実装
5. 動作確認通常と例外の分岐を検証し削減値は未測定

たとえば「利用部門ごとに例外申請の手順が異なり、差し戻しが頻発して業務が停滞している」という状況に対し、関係者へのヒアリングを通じて共通ルールと個別例外を切り分け、バックエンドシステムを改修した事例を考えます。

職務経歴書等にまとめる際は、抽象的な改善成果を述べるのではなく、誰と対話し、どのような仕様判断を下し、どこを実装したのかという客観的な事実を整理します。

直面した状況：部門ごとに申請手順や承認経路が異なり、差し戻しによって処理の遅延が生じていた。
行った対話：総務、経理、各現場リーダーの3者に聞き取りを実施し、全社共通で必須となる承認項目と、特定部署のみで発生する例外的な確認手順を洗い出した。
下した仕様判断：所定金額以下の通常申請は承認ルートを統一して自動処理とし、規程外の申請のみ部門長の承認を必須とする分岐ルールを仕様として定めた。画面設計は他担当者が受け持ち、自らは承認ルートの分岐ロジック再設計とAPI実装を担当した。業務ルールの最終承認は部門長が実施した。
動作確認と制約事項：ステージング環境において、通常申請と例外申請の双方が設計通りに分岐してデータ更新されることをテスト検証した。なお、本番導入後の業務時間削減効果については未測定である。

このように、架空の数値成果を創作するのではなく、自分が担当した要件整理の範囲、策定した仕様の内容、実装した技術領域、未検証の事項を明確に分けることで、対話から実装に至る具体的なプロセスを伝えることができます。

開発実務と自主学習を分けて伝える

職務経歴書を作成する際は、実務として従事した開発業務と、個人で取り組んだ技術学習や検証を混同させずに記載します。歓迎要件に挙げられているPythonやLLM、RAGについて個人でコードを書いたりリポジトリを作成していたとしても、それを実務の開発年数やステークホルダーとの調整実績へ読み替えることはできません。

実務欄では、実際に携わったシステム構成、担当した工程、曖昧な要件を解消した判断の事実を記述します。個人で作成した制作物や検証成果がある場合は、補足資料として別枠に記載するのが適切です。GitHubリポジトリやREADMEを活用して成果物の前提条件や既知の制約を客観的に提示する方法については、実案件と個人制作を分けた成果物のまとめ方で解説しています。

なお、求人情報に歓迎スキルとして記載されている項目の有無が、実際の採用選考においてどの程度加味されるかについては、企業側の選考方針に委ねられています。