中小企業は「社内FDE」を育てるほうが早い ―― 採用競争に参加しないという選択
2026/9/4 01:00
採用競争の実勢 ―― 求人約35件、年収900万〜2,500万円
日本国内のFDE求人は、2026年春時点で約35件、提示年収は900万〜2,500万円超が中心レンジとされています。募集しているのはAIスタートアップ、大手SaaS、コンサル、SIerが中心です。
この数字を見て、中小企業や非IT企業の経営者が「うちもFDEを採らないと」と考えるのは自然です。ただ、結論から言えば、この争奪戦に参加して勝つのは現実的ではありません。
争奪戦に参加しないという判断
件数が少ないということは、供給も少ないということです。需要は指数関数的に伸びている一方で、FDEを名乗れる人材の供給は直線的にしか増えません。
この需給ギャップの中で、知名度もストックオプションもない企業が、AIラボや大手SaaSと同じ候補を取り合う。採用コストを考えても、プロセスの長さを考えても、合理的な選択とは言い難いでしょう。
もう一つ見落とされがちなのがドメイン学習コストです。外から優秀なエンジニアを迎えても、自社の業務を理解するまでに数か月かかります。その時間を短縮できる人材は、実はすでに社内にいます。
外から技術を連れてくるより、中にいる人に技術を持たせる方が、中小規模では圧倒的に早い。
社内FDEとは何をする人か
社内FDEとは、自社の業務を知っていて、AIを使って自分で自動化を作れる人のことです。高度なアーキテクチャ設計ができる必要はありません。
必要なのは3つだけです。自社の業務フローを説明できること、どこが無駄かを見つけられること、そしてAIツールを使って小さく作って試せること。この3つが揃えば、外部の高額な支援なしでも相当な範囲が回ります。
実際に効果が出やすいのは、エンジニアではなく業務側の人です。経理、総務、営業事務といった、毎日同じ作業をしていて不便を一番知っている人が、最短距離で成果を出します。
育成の段階設計
最初の段階は、自分の手元の作業を1つ自動化することです。スプレッドシートの転記、定型メールの作成、ファイルの振り分け。小さすぎるくらいでちょうどいい。
次の段階で、他人の作業に手を伸ばします。ここからはヒアリング能力が必要になり、実はFDEの仕事の本質部分に入っていきます。自分の業務と違い、相手の困りごとを言語化する工程が入るからです。
その先が、部門をまたぐ仕組みです。ここまで来ると、権限やデータの持ち方といった設計判断が必要になるので、外部の知見を入れる価値が出てきます。逆に言えば、そこまでは自力で進められます。
一人目で終わらせない
社内FDE育成で最もよくある失敗は、1人が相当なレベルまで到達したものの、仕組みの中身をその人しか知らない状態になることです。異動や退職で、積み上げたものが一瞬で使えなくなります。
対策は2つです。作ったものの「何が・いつ・どこから・どこへ」を1枚のメモに残すこと。そして、2人目を早めに育て始めることです。
2人目は1人目よりはるかに早く育ちます。社内に成功例と相談相手がすでにあるからです。このコスト逆転を知っているかどうかで、育成計画の組み方は変わります。
伴走者の使いどころ
外部を使うなら、作業を丸投げするのではなく、「作り方を残す」ことを前提に発注するのが合理的です。同じ金額を使うなら、成果物だけでなく手順が社内に残る方が後々効いてきます。
特に効果が高いのは、最初の1件を一緒に作る形です。型さえできれば2件目以降は社内で回ります。
Desiaでは、この「社内に作り方を残す」形のAI導入伴走を行っています。人を採るべきか、育てるべきかで迷っている方は、現場の状況を伺うところからご相談ください。お問い合わせはこちら：https://desia.jp/contact
OTHER
その他記事一覧
求人票から読むFDE ―― 肩書きが六つに割れた職種の見分け方
2026年のFDE求人で最も目立つのは肩書きの分裂です。1つの役割が少なくとも六種類のタイトルで募集され、同じ「FDE」でも任される範囲は大きく異なります。求人票を集計すると顧客対応60%・デプロイ固有のコード30%・社内業務10%という配分が見えてきます。タイトルではなくスコープで見極めるための実務的な読み方を解説します。
【2026年版】FDE市場の現在地 ―― 巨大テックが「職種」に数千億円を投じ始めた
FDE（Forward Deployed Engineer）は2026年、話題の職種から巨額投資の対象へと段階を変えました。AWSは6月にFDE専門組織に10億ドル、Microsoftは7月に約6,000人を顧客に常駐させる25億ドル規模の新事業を発表。求人数は前年比四桁の伸びを示し、日本でも市場が立ち上がり始めています。数字で追うFDE市場の現在地と、小さな事業者にとっての意味を整理します。
FDEを入れたのにスケールしない ―― 4つの失敗パターンと段階設計
FDE型の体制を導入したのに、最初の1件から2件目・3件目へ広がらない。この問題の原因は担当者の能力ではなく、ほぼ例外なく仕組み側にあります。属人化、負荷集中による疲弊、知見の非還元、内製と外部委託の判断ミス——実務で頻出する4つの失敗パターンと、6〜12か月の段階設計の組み方を整理します。
中小企業は「社内FDE」を育てるほうが早い ―― 採用競争に参加しないという選択
日本のFDE求人は2026年春時点で約35件、提示年収は900万〜2,500万円超が中心レンジ。中小・非IT企業がこの争奪戦に参加して勝つのは現実的ではありません。自社の業務を知っている人にAIで自動化を作れる力を持たせる——「社内FDE」という選択肢と、その育成の段階設計を解説します。
AI導入の95%が成果を出せない ―― FDEが埋めているのはどのギャップか
MITのNANDAイニシアチブは2025年のレポートで、企業の生成AIパイロットの95%が測定可能なビジネスインパクトを生んでいないと報告しました。しかし失敗しているのはAIそのものではなく、AIと業務の間にある層です。FDEが埋めている4つのギャップと、小さな組織でも同じ構造が使える理由を解説します。
なぜ今FDEが注目されるのか ── AI時代の需要構造を読み解く
2024〜2026年にかけて、OpenAI・Anthropic・SalesforceなどがFDE（Forward Deployed Engineer）の大量採用に動き、日本でも求人が急増しています。背景にあるのは生成AIの「汎用性と現場適合の非対称性」です。FDEブームの需要構造を解説します。
非エンジニアからFDEになれるか ── 越境キャリアの入口設計
FDE（Forward Deployed Engineer）は実装力が土台の職種ですが、ITコンサル・PM・業務部門出身者にも現実的な参入ルートがあります。非エンジニア・越境層がFDEを目指す際の強み・弱みと、AI時代ならではのキャッチアップ戦略を解説します。
FDEのプロジェクトはこう進む ── 課題発見から定着までの実務フロー
FDE（Forward Deployed Engineer）のプロジェクトは、ヒアリング→課題定義→高速プロトタイピング→本番展開→定着・改善という流れで進みます。従来のウォーターフォール型開発とは別物の、現場密着型の実務フローをフェーズごとに解説します。
Webサイト改修提案を「論証可能」にする6つの分析レンズ
Webサイトの改修提案をしても、「なぜその改修が必要なのか」をクライアントに説明できないと採用されません。デザイン評価だけ、データだけ、主観コメントだけ、という一点集中の提案では説得力が出ません。DesiaがWebサイト提案を作る際にチェックしている「6つの分析レンズ」を公開します。
Robloxゲーム開発の落とし穴 ── 「板1枚問題」と「目的不明瞭問題」を事前に防ぐ設計原則
Robloxゲーム開発を始めた多くのクリエイターが「セッション時間が伸びない」「リテンションしない」という課題に直面します。この裏にある「板1枚問題」と「目的不明瞭問題」という2つの設計ミスと、それらを防ぐためのアセットドライブンデザイン思想を公開します。
AIで作るアプリUI動画素材の使い分け ── Lottie / Three.js / Renoise
WebサービスやアプリのUIを動んず「静止だと伝わらない」というケースで、動画・アニメーション素材の制作ニーズが高まっています。Lottie、Three.js、Renoiseの3つのツールはそれぞれ得意領域が違うため、実際に何を作るかによって選択が変わります。Desiaの実例をもとに使い分けを解説します。
Claudeスキル設計の500行制限 ── スキルが肥大化したら必ず分割するべき理由
Claudeのスキル機能([SKILL.md](http://SKILL.md))を使い始めた多くのユーザーが陥るのが、「スキルファイルが肥大化していく」問題です。最初は100行だったスキルが、機能追加・例外処理の追加で500行・1000行と膨らみ、ある日「スキルが動かなくなる」「Claudeが指示を読まない」という事態が起きます。Desiaが実務で確立した「500行制限」の原則と、3つの分割パターンを公開します。
デザイン品質を保つAI3スキル分業設計 ── アートディレクター・デザイナー・QAをスキルで分ける
AIによるUIデザイン生成は、プロンプト1本で完結しません。「アートディレクション」「デザイン生成」「品質QA」という3つの役割を1人のAIで兼ねさせると必ずどこかで品質が破綻します。Desiaが実務で確立したdesign-art-director/ai-ui-prompt-gen/design-qa-reviewerの3スキル分業設計と、それを統合するオーケストレーターのノウハウを公開します。
地方企業が東京の競合に勝つためのローカルSEO・AEO戦略
「東京の競合と比べてSEOで不利だ」という相談を、地方企業からよく受けます。確かに被リンク数も発信ボリュームも東京企業に分があります。しかしローカルSEO・AEO・Google Business Profileを組み合わせれば、地方企業のほうが圧倒的に有利な領域があります。Desiaが秋田から実証してきた地方企業の差別化戦略を公開します。
GA4とSearch Consoleの「見られないレポート問題」を解決する標準フロー ── 月次から年次までの4段階ステップアップ
Web制作案件を納品して終わりではなく、その後の運用フェーズで「結局GA4もSearch Consoleも見てもらえていない」という事態が頻発します。Desiaが標準フロー化したGA4・Search Consoleレポートのハンドオーバー手順を公開します。月次の3指標ダッシュボードから年次戦略提案まで、4段階のステップアップで運用に乗せるノウハウです。
業務AIセキュリティの基本 ── プロンプトインジェクションから機密情報を守る3レイヤー対策
ChatGPTやClaudeを業務で使い始めると、必ず話題になるのが「セキュリティ大丈夫?」という懸念です。特に最近は「プロンプトインジェクション」という攻撃手法が知られるようになり、AIに業務データを渡すリスクが論点になっています。Desiaが実務で運用している、業務AIセキュリティの基本(信頼境界・機密情報の取り扱い・検出と対応)の3レイヤー対策を公開します。
プロンプト過剰最適化問題 ── AIツールごとの適切な詳しさとは
Claudeやv0、Figma Makeを使い始めた点、「プロンプトを詳しく書けば書くほど良い出力が出る」と考えてしまうわなけではありません。しかし詳しすぎるプロンプトはむしろ出力品質を下げることがあります。Desiaが7つのAIツールごとにチューニングした「適切な詳しさ」のガイドを実例とあわせて公開します。
Claudeで「ナレッジが流れない組織」を作る5つのレイヤー設計
ChatGPTやClaudeを業務で使い始めた企業の多くが、「便利なやり取りが個人の中に閉じてしまい、組織のナレッジにならない」という壁に当たります。Desiaが自社運用とクライアント支援で確立した、Claudeを「組織の知的資本」に変えるための5レイヤー設計を解説します。
Notionで「公開と非公開」を両立させる構造設計 ── ストックDBと公開DBの分離戦略
Notionをコンテンツ管理ツールとして使っている企業で必ず突き当たるのが、「Notion Sites公開時に閲覧者がフィルターを変更できてしまう」問題です。Desiaがクライアント案件で確立した「ストックDBと公開DBの分離戦略」と、運用負荷を最小化する設計のコツを共有します。
Figmaプロトタイプの「擬似インタラクション」設計術 ── 入力フォーム・条件分岐ボタンを作る
Figmaのプロトタイプには「テキスト入力」も「条件分岐（if文）」もありません。それでも実案件では、入力可能なフォームや「全項目入力後にボタンが活性化する」演出が求められます。Desiaが現場で確立した擬似インタラクション設計の3つのテクニックを公開します。
Webコンサル提案書を作る前に知っておきたい「無料で使える分析ツール」の組み合わせ
Webサイトのコンサル提案書を作る際、有料分析ツール（Similarweb、Ahrefs有料版等）に頼り切ると、案件単価次第ではコストが合いません。Desiaが実運用している「無料・低コストツールの組み合わせ」だけで、競合分析からSEO/AEO戦略、Gamma連携の提案書生成までを完結させる方法を共有します。
業種別BIダッシュボードのKPI設計テンプレート ── Looker Studioで失敗しないための設計原則
Looker Studioでダッシュボードを作ろうとして「何を載せればいいか分からない」と止まる経験はないでしょうか。Desiaが10業種超の案件で蓄積したKPI設計テンプレートと、絶対に外せない設計原則を整理しました。クライアント提出物として通用するダッシュボードを作るための実践ガイドです。
コードからFigmaへ、戻す側のベストプラクティス ── Manus / Claude Code / v0 出力をデザインデータ化する
ManusやClaude Code、v0で生成したサイトコードをFigmaに「編集可能なデザインデータ」として戻したい、というニーズが急増しています。Desiaが多くの試行錯誤を経て確立した、安全に運用できる「コード→Figma反映ワークフロー」を、5つの原則と8フェーズのプロセスに整理しました。
高齢者向けアプリUI設計のリアル ── 80代でも迷わず使える設計原則とは
医療・福祉領域のアプリ案件で必ず直面するのが「高齢者向けUI」の難しさです。Desiaでは在宅酸素療法を利用する80代以上の患者向けLINEミニアプリを設計する中で、一般的なアクセシビリティガイドラインだけでは足りない、実装現場ならではの設計原則を確立してきました。本稿では、その核となる8つの原則を共有します。
広告レポートを毎朝Slackで自動配信する仕組み ── GAS × Claude API × Slack の作り方
「広告レポートの作成に毎週半日取られている」「分析コメントを書くのが地味に大変」というご相談をよく頂きます。Desiaでは、Google Apps Script（GAS）とClaude API、Slack Incoming Webhookを組み合わせ、広告KPIのレポートを毎朝自動でSlackに配信する仕組みを実運用しています。月額わずか100〜150円で構築できる、その実装の核心を公開します。
AI UIツール7種を使い分ける実務者向けガイド ── Relume / Stitch / Figma Make / v0 / Bolt / Lovable / Manus
「結局、どのAI UIツールを使えばいいですか？」というご質問を本当によく頂きます。Desiaでは複数のクライアント案件で全主要ツールを使い込んだ結果、それぞれが得意とする領域が明確に分かれていることが分かりました。本稿では、目的別の使い分けと、実務でハマりやすい落とし穴を整理します。
AI時代のWebサイト立ち上げで失敗しないための「上流設計」3ステップ
「とりあえずAIツールでサイトを作ってみよう」と着手して、後から構成のやり直しに陥るケースをよく見ます。AIによるサイト生成が当たり前になった今だからこそ、実はサイトマップ・情報設計・コンテンツ設計という「上流工程」の質が成果物の出来を決めます。本稿では、Desiaが実際の制作現場で固めてきた、AI時代に通用する上流設計の3ステップを公開します。
View more →