ローコード技術者の採用難は「候補者がいない」問題ではなく、「求人票と評価基準がエンジニア採用の型のままである」問題だ。必須要件からコーディング経験を外すだけで、応募を見送っていた層が動きはじめる。

TL;DR（要点まとめ）

• ローコード人材こそ採用難：市場の絶対数が少なく、求人票をエンジニア基準で書くと候補者が消える。外部採用と社内育成の二枚看板が現実解

• IT人材不足の規模：経済産業省は2030年までに最大79万人のIT人材が不足すると予測。ノーコード・ローコード人材の活用は構造的解決策の一つ

• 採用対象の拡張：プロの開発者に加え、Excelや業務知識に長けた非エンジニア人材を「市民開発者」として育成・採用する動きが加速

• 3つの採用ロール：「ローコード開発エンジニア（プロ寄り）」「市民開発者候補（非エンジニア寄り）」「CoE（Center of Excellence）推進担当」を切り分けて要件定義する

• 評価軸の再設定：コーディング力より「ビジネスプロセスの理解力」「ツール習熟度」「現場調整力」を優先する選考設計が成否を分ける

• 組織設計とセット：採用後の活躍環境（ガバナンス・ライセンス・ゾーニング）を整えないと、シャドーIT化・品質劣化リスクが高まる

1. なぜ今、ノーコード・ローコード人材が採用の焦点になるのか

エンジニア採用の競争が激化するほど、「コードが書ける人材だけを採る」という前提そのものが採用のボトルネックになる。母集団を拡張する打ち手として、ノーコード・ローコード人材と市民開発者の採用・育成が現実的な選択肢に浮上している。

データで見る：IT人材不足という構造問題

公的統計を並べると、エンジニア採用の競争環境がどれだけ厳しいかが数値で確認できる。

• 経済産業省「IT人材需給に関する調査」：2030年時点で最大約79万人のIT人材が不足すると試算

• 厚生労働省「一般職業紹介状況」（令和8年7月）：情報処理・通信技術者の有効求人倍率は1.50倍、全職業計は1.18倍

• doda「転職求人倍率レポート」（2026年8月）：全体2.86倍、前月差+0.15pt。ハローワーク統計の全職業1.18倍とは倍率の水準が大きく異なる

注目すべきは、ハローワーク経由の全職業1.18倍と転職市場全体2.86倍の乖離だ。公的な職業紹介ルートに現れない転職市場では、1人の候補者に対して約2.9件の求人が競合している。この環境で「エンジニアをもっと採れ」という従来策を続けても、スタートアップが大手と同じ土俵で母集団を確保するのは難しい。

「プログラミング」から「問題解決」への転換

国内のノーコード・ローコード開発市場は2026年度に約1,330億円に達すると試算されており（IDC Japan推計）、業務アプリ内製化の裾野は急速に広がっている。Microsoft Power Apps・Google AppSheet・Salesforce Flow・Retoolといったプラットフォームが成熟し、コードを書かずに業務アプリを構築できる環境が整ったためだ。

Gartnerは「2026年にはローコードツールのユーザーの80%がIT部門外の市民開発者になる」と予測している。採用担当者にとってこれは、コーディングスキルを持たなくても業務システムの設計・開発・改善を担える人材像が成立することを意味する。

2. ローコード技術者はなぜ採用難なのか｜4つの構造要因

ローコード・ノーコード人材の採用は「エンジニア採用より簡単」と誤解されがちだが、実際にはローコード技術者そのものが採用難の職種だ。母集団が拡張できるのは要件定義を正しく設計した場合に限られ、従来のエンジニア採用の型をそのまま持ち込むと応募がゼロのまま止まる。

採用難を生む4つの構造要因

採用難の要因は次の4つに整理できる。

1. 市場の絶対数が少ない：ローコードプラットフォームの実務経験を数年積んだ人材は日本語圏ではまだ限られる。特にOutSystems・Mendixのような大企業向け製品の経験者はSIerや事業会社の情シスに滞留しており、転職市場に出てきにくい

2. 職種名が定着していない：求職者は自分を「業務改善担当」「情シス」「DX推進」と名乗るため、「ローコード開発エンジニア」という職種名で検索してもマッチしない

3. 求人票がエンジニア基準で書かれている：必須要件に「開発言語の実務経験」「GitHub利用経験」を入れた瞬間、本来採れたはずの候補者が自己判断で応募を見送る。採用難の相当部分は市場ではなく求人票が作り出している

4. 評価する側にスキルの物差しがない：面接官がローコードの実装品質を判断できず、結局「コードが書けるか」で評価してしまう。その結果ローコード人材が選考で落ち続ける

つまりローコード人材の採用難は「候補者がいない」問題であると同時に、「見つけ方と評価の仕方を組織が持っていない」問題でもある。

4要因のうち、自社で今日から動かせるのはどれか

4つの要因のうち市場の絶対数（要因1）は自社では動かせない。一方、残る3つはすべて自社の設計変更で解消できる。優先順位は次のとおりだ。

1. 要因3（求人票）を最優先で直す：着手コストが最も低く効果が最も早い。必須要件から開発言語・GitHubを外し「業務改善の実務経験」に置き換える（第4章）

2. 要因4（評価の物差し）を整える：コーディングテストを業務シナリオ型の実技課題に差し替え、4軸の評価表を面接官で共有する（第5章）

3. 要因2（職種名）は検索語で補正する：「業務改善」「DX推進」「情シス」「Power Apps」「kintone」という候補者側の語彙を求人票とスカウト文に混ぜる（第8章）

4. 要因1（絶対数）は社内育成で埋める：外部市場に存在しない分は既存社員のリスキリングで供給する（第6章）

私は採用コンサル営業を経て現在はエンジニアとして事業を運営しており、BizReach・Forkwell・Greenなど13サービス以上でスカウト運用を見てきた。この職種で応募が止まる案件は、ほぼ例外なく要因3と要因4が同時に起きている。市場が枯れているのではなく、自社の入口と出口の両方で候補者を弾いている状態だ。要因1だけを理由にして採用を諦めるのは早い。

3. 採用すべき「3つのロール」を整理する

ノーコード・ローコード採用を設計するとき、最初に混乱するのが「誰を採ればいいのか」という問いだ。実際には採用対象は1種類ではなく、組織の成熟度と課題に応じて3つのロールに分けて考えると整理しやすい。

1. ローコード開発エンジニア（プロ寄り）：プログラミング経験があり、OutSystems・Mendix・Power Appsなどを専門にする開発者。要件定義・DB設計・APIインテグレーションまでカバーできる

2. 市民開発者候補（非エンジニア寄り）：コーディング経験はないが、Excelマクロ・スプレッドシートに慣れ、業務フローへの深い理解がある人材。Power Apps・AppSheet・kintone・Notionで業務アプリを自作できる素養がある

3. CoE推進担当：Center of Excellenceとして社内の市民開発者を束ね、ガバナンス設計・品質管理・ライセンス管理・技術支援を担う。エンジニアとビジネス側の橋渡し役

最初の1名は、既存にエンジニア組織があるならロール1、なければロール2から入るのが現実的だ。ロール3は市民開発者が3〜5名を超えたあたりで必要になる。

4. 求人票（JD）の書き方：ノーコード・ローコード採用の要件定義

ノーコード・ローコード採用の求人票は、従来の「開発経験〇年以上、言語は〇〇」という書き方が通用しない。コーディング経験を必須要件に入れた瞬間、採用ターゲットが大きく絞られてしまうからだ。

2ロールの必須要件・歓迎要件の書き分け

NG例（母集団を不当に絞る書き方）：「Python・JavaScriptの実務経験3年以上」でローコード人材が脱落し、「GitHub利用経験必須」で市民開発者候補が脱落し、「Agile / Scrum経験必須」で業務側出身の候補者が脱落する。いずれも第2章の要因3そのものだ。

給与・年収レンジを明示する

ノーコード・ローコード採用では給与の透明性が特に重要だ。候補者自身が「自分は市場でどのくらいの価値があるか」を把握しにくいため、レンジを開示することで応募障壁を下げる効果がある。非公開にすると「評価されないかも」という不安で辞退される。

5. 選考プロセス設計：コーディングテストに依存しない評価

ノーコード・ローコード採用の選考は、コーディングテストを業務シナリオ型の実技課題に差し替えることで機能する。評価対象は「コードの正しさ」ではなく「業務課題を正しく捉えて、使える形に落とし込めるか」だからだ。

選考フローの設計例

1. 書類選考：職務経歴書 + ポートフォリオ or 実績スライド（5分でわかるもの）

2. カジュアル面談（30分）：キャリア確認、ロール説明

3. 実技課題（60分）：業務シナリオを与え、ノーコード・ローコードツールで解決策を設計・実装する

4. 技術面接（60分）：実技課題のデモと設計思想のヒアリング

5. 最終面接（30分）：カルチャーフィット・志望動機確認

実技課題の設計：業務シナリオ型アサインメント

ノーコード・ローコード選考の肝は「実技課題」だ。通常のコーディングテストではなく、業務シナリオ型のアサインメントを設計する。

課題例（市民開発者候補向け）：「営業チーム10名の案件管理をExcelで行っているが、入力ミスと転記作業が問題になっている。AppSheet（またはkintone）で、案件一覧の管理・フェーズ変更時のSlack通知・月次の売上集計ビューを実現するアプリを1時間以内に設計してください」。ツールのアカウントは事前に用意し、設計意図のデモ説明までをセットにする。

この形式の実技課題で以下を評価する。

1. 業務課題の理解力：シナリオを正確に把握できるか

2. ツール選定の判断：与えられたツールの中で最適な実装を選べるか

3. 説明能力：実装した意図を非技術者にも伝えられるか

4. 完成度より思考プロセス：完璧な実装より「なぜそう設計したか」を重視

評価軸の設定

ノーコード・ローコード採用では、以下の4軸で候補者を評価する。

6. 市民開発者を「採用」と「育成」の両軸で確保する

市民開発者は外部採用だけで揃えようとすると、必ず数が足りなくなる。市場の絶対数が限られている以上、業務知識をすでに持っている既存社員のリスキリングを並走させるのが、採用難に対する最も確実な供給源になる。

外部採用だけに頼らない：社内育成の組み合わせ

市民開発者の確保は、外部採用と社内育成を組み合わせるのが現実的だ。理由は3つある：

1. 市場の絶対数が少ない：ノーコード・ローコードの実務経験者はまだ少なく、採用競争になりやすい

2. 業務知識が先に必要：外部採用者は自社のビジネスロジックを学ぶ時間が必要。逆に既存社員はすでに業務知識を持っている

3. コストが低い：既存社員のリスキリングは採用コスト（紹介料・媒体費）なしで実現できる

社内育成のステップ（90日ロードマップ）：

採用時の「市民開発者適性」チェックリスト

書類選考・面談で市民開発者候補を見極める確認ポイントは次の5つだ。

1. Excelの高度活用経験：VLOOKUP以上の関数・ピボットテーブル・条件付き書式を業務で使っている

2. 業務改善の実績：「この作業を〇時間削減した」「この仕組みを自分で作った」という経験がある

3. 新ツールへの好奇心：Notion・Slackワークフロー・Zapier等を趣味や業務で使っている

4. 説明力：自分が作ったものを他者に説明できる（＝仕様を言語化できる）

5. ITへの忌避感のなさ：「ITは苦手」ではなく「使えれば便利」というスタンス

7. ノーコード・ローコード採用で避けるべき落とし穴

採用できても定着しない組織には共通パターンがある。いずれも採用活動そのものではなく、受け入れ側の設計不足に起因する。代表的な4つを挙げる。

1. ガバナンス設計を後回しにする：市民開発者が増えると「野良アプリ」が乱立する。採用と同時に「承認フロー」「ライセンス管理」「セキュリティゾーニング」「廃止ルール」の4点を整えておく

2. 「プロエンジニアの下位互換」として扱う：この姿勢は組織文化を壊す。彼ら・彼女らの強みは「業務フローに沿った実装スピード」「非技術者への説明力」「ビジネス要件の翻訳」にあり、プロエンジニアが苦手な領域を埋める補完関係として設計する

3. 成長機会を用意しない：学習支援（資格補助・コミュニティ参加・ツールへのアクセス）がないとエンゲージメントが下がり離職につながる

4. スカウト文面がエンジニア採用と同じ：「React・Python経験者を募集」では刺さらない。「コードは書かなくていい、業務改善力を活かしてほしい」という訴求に組み替える。文面設計の基本は「エンジニアに響くスカウトメールの書き方」も参照

市民開発者向けキャリアパスの例：

• Lv.1 市民開発者：自部門向けアプリを制作

• Lv.2 シニア市民開発者：複数部門へ横展開・メンタリング

• Lv.3 CoEメンバー：全社のノーコード・ローコード基盤設計

• Lv.4 CoEリード：IT部門・ビジネス部門を横断するデジタル変革推進責任者

8. 2026年のノーコード・ローコード採用市場：最新動向と媒体選び

この職種で媒体選定を誤ると、そもそも候補者の目に求人が触れない。ローコード人材はエンジニア向けスカウト媒体と業務改善・DX系コミュニティの両方に分散して存在しており、エンジニア採用と同じ媒体だけを回しても母集団が立ち上がらないからだ。

主な採用チャネル

コミュニティからのリーチが有効

ノーコード・ローコード人材は求職意識の低い「潜在層」が多く、求職サイトに登録していない層に届かせるにはコミュニティへの直接アプローチが有効だ。JBUG（kintone活用者）、Power Platform ユーザーグループ（Power Apps / Power Automate ユーザーの勉強会）、AppSheetやBubbleのノーコードハッカソンが主な接点になる。採用担当者自身が参加し、登壇・情報提供を通じてブランド認知を高めるDevRel的アプローチが効く。

ローコード開発エンジニアの年収相場（2026年）

9. 成功事例に学ぶノーコード・ローコード人材活用

事例1：大手製造業の市民開発者急拡大（LIXIL）

株式会社LIXILはAppSheetを導入し、約9ヶ月で4,000人弱の社員が約17,000個のアプリを開発するまでに至った。このスケールを実現した鍵は、専門エンジニアに頼らず「現場社員が自分たちの課題を自分たちで解く」環境を整備したことにある。

スタートアップが参考にできるポイント：

• 最初は1〜2部門での小規模パイロット

• 成功事例を社内に横展開するCoE（推進担当）の存在

• ツール習得のための研修とライセンスの整備

自社で小さく始めるときの評価設計

LIXILのような大規模展開はいきなり真似できない。スタートアップが最初の1名を採るときは、採用の成否を「入社後90日で何が起きたか」で判定する設計にしておくと、経営層への説明も次の採用判断も進めやすい。判定に使う観点は次の4つだ。

1. アプリが1本、本番運用に乗ったか：試作止まりではなく、他人が日常業務で使っている状態になったか

2. 削減時間が申告ベースで把握できているか：「この転記作業が週◯時間から◯時間になった」と現場の担当者自身が言えるか

3. 現場から次の依頼が来たか：本人が探しにいかなくても、他部署から「うちのこれもできる？」と相談が届くか

4. 引き継げる形で残っているか：作った本人が不在でも、設計意図と項目定義がドキュメントとして参照できるか

4つのうち3つ以上を90日で満たせていれば、2人目の採用やCoE設置に進んでよい。逆に1つも満たせていない場合、原因は本人のスキルではなくミッション設定にあることが多い。着手業務を「部門内で完結し、関係者が5人以内で、既にExcelで運用されているもの」に限定し直すと動きはじめる。

10. 協業設計とセキュリティガバナンス｜既存エンジニア組織との摩擦を防ぐ

採用後に想定されるのが「既存エンジニアとの摩擦」だ。「素人が作ったアプリで品質が落ちる」という懸念は現実的で、ゾーニングとレビューの2つを事前に設計しておくことで摩擦を最小化できる。

ゾーニング：使ってよい領域と禁止領域を定義する

コードレビューに相当する「アプリレビュー」を設ける

市民開発者が作ったアプリのリリース前に、CoE担当者がレビューする仕組みを設ける。観点は「セキュリティ（不適切なデータアクセス・権限設定がないか）」「パフォーマンス（大量データでの動作）」「メンテナンス性（担当者交代時に引き継げる構造か）」「命名規則（統一したフィールド名・テーブル名か）」の4点だ。

「新形態シャドーIT」というリスク

市民開発者が増えると、従来型のシャドーIT（未承認のクラウドサービス利用）とは別種のリスクが生まれる。未承認のアプリケーション自体が社内外のデータにアクセスする状態だ。営業部門が作った顧客管理アプリが誤って外部公開設定になる、人事部門の評価情報アプリのアクセス権限が「社内全員」になる、といったケースが典型例になる。

問題は、これらが「IT部門が把握していないところで起きる」点にある。承認を経ずに作られたアプリは資産台帳にもライセンス管理にも載らないため、権限設定のミスが起きても誰も気づけない。だからこそ、採用や育成を始める前にガバナンス設計を置く必要がある。

採用と同時に整備すべきセキュリティ設計

次の4点を採用と並行して整備する。

1. データ損失防止（DLP）ポリシーの設定：Power Apps・AppSheet等では外部データ連携コネクタを制限できる。機密データ（顧客情報・決済データ・人事情報）を含むデータソースに、承認なしで接続できないよう制御する

2. 環境分離：市民開発者が実験的に作ったアプリが本番データに触れないよう開発用サンドボックスを用意する。Power Platformでは環境（Environment）、AppSheetではデプロイ設定で対応できる

3. セキュリティ研修の必修化：採用後研修に「最小権限の原則」「公開範囲の確認」「市民開発の対象にしてはならないデータの定義」の3点を組み込む

4. 定期監査の仕組み化：四半期に一度、CoE担当者が全市民開発アプリを棚卸しし、未使用アプリと不適切な権限設定を整理する

11. ノーコード・ローコード採用のロードマップ：段階別に進める

ノーコード・ローコード採用は、最初から全社展開を狙うと必ず頓挫する。1部門での成功事例を1つ作り、それを横展開の材料にする順番で進めるのが定石だ。

フェーズ1で最も多い失敗は、採用ロールを絞らずに「ローコードができる人なら誰でも」と募集することだ。まずは1ロールに絞り、90日で1本という明確なゴールを置く。

FAQ（よくある質問）

Q1. ノーコード・ローコード人材採用は、エンジニア採用の代替になりますか？

代替ではなく補完です。コアシステムの開発・セキュリティ対応・パフォーマンスチューニングには従来のエンジニアが不可欠です。一方、現場の業務アプリ開発・データ集計・簡易自動化はノーコード・ローコード人材が効率よくカバーできます。両者を組み合わせることで採用リソースの最適配分が実現します。

Q2. 採用のどのフェーズでノーコード・ローコード人材を入れるべきですか？

社員数10〜30名フェーズ（バックオフィス業務が複雑化しはじめる段階）が導入の目安です。エンジニアに業務ツール改善を依頼するほど優先度が高くないが、現場のオペレーションが回らなくなっているタイミングに最適です。

Q3. ノーコード・ローコード人材は採用後、何を使って仕事しますか？

Microsoft Power Apps / Power Automate（Microsoft 365環境）、Google AppSheet（Google Workspace環境）、kintone（業務アプリ内製）、Retool（社内管理ツール）、Notion + Zapier（オペレーション自動化）が代表例です。自社のツールスタックに合わせて採用時のスキル要件を調整してください。

Q4. 市民開発者候補をスカウトする際、どの媒体が効きますか？

Wantedly・Green（カジュアルな求職意識層）、connpass（勉強会参加者）、JBUG・Power Platform UG（ツール特化コミュニティ）が主な媒体です。「DX推進」「業務改善」「ノーコード」のキーワードで検索する候補者が多いため、求人票・スカウト文にこれらのキーワードを含めるのが効果的です。

Q5. 既存のエンジニアチームはノーコード・ローコード人材をどう受け入れますか？

「プロの開発者の代替」という誤解が摩擦の根本原因です。採用前にエンジニア側に「担当領域のゾーニング」を説明し、市民開発者が対応する業務とエンジニアが対応する業務を明確に分離することで、役割の重複を防げます。

Q6. ノーコード・ローコード採用にかかるコストはどのくらいですか？

人材紹介（成功報酬型）は年収の30〜35%が相場で、ミドル層（年収500万円）なら150〜175万円程度です。ダイレクトリクルーティング（BizReach・Greenのスカウト）なら月額費用（5〜15万円）と工数が中心になるため、採用人数が増えるほどコスト優位になります。

Q7. ノーコード・ローコード市場は今後どうなりますか？

国内市場は2026年度に約1,330億円（IDC Japan推計）と成長を続けています。Gartnerは「2028年までにエンタープライズアプリの70%以上がローコード・ノーコード技術を使って構築される」と予測しており、この人材の需要は今後さらに高まります。今のうちにノーコード・ローコード採用のパイプラインを作っておくことが、2〜3年後の採用競争力に直結します。

Q8. 求人を出しても応募がゼロです。まず何を疑うべきですか？

最初に疑うのは求人票の必須要件です。「開発言語の実務経験」「GitHub利用経験」「Agile/Scrum経験」が必須欄に残っていれば、まずそこを削ってください。ローコード人材の多くは自分をエンジニアだと認識していないため、これらを見た時点で「自分向けではない」と判断して離脱します。次に疑うのは職種名です。「ローコード開発エンジニア」とだけ書いても検索に引っかかりません。「業務改善」「DX推進」「Power Apps」「kintone」といった候補者側の語彙を併記してください。

Q9. AI時代にノーコード・ローコード人材の価値は下がりませんか？

下がるというより、求められる能力の重心が移ります。生成AIがアプリの雛形を出せるようになった分、「作れること」自体の希少性は相対的に下がりました。一方で価値が上がったのは「どの業務を仕組み化すべきかを見極める力」「出てきたものが現場で使えるか判断する力」「関係者を巻き込んで運用に乗せる力」です。選考では「AIに何を任せ、どこを自分で判断したか」を具体的に語れるかを確認してください。AI時代の採用要件全般の考え方は「AI時代のエンジニア採用完全ガイド」にまとめています。

Q10. 市民開発者として採用した人が辞めてしまいました。何が原因でしょうか？

私が見てきた範囲では、成長機会とキャリアパスの不在が最も多い原因です。この層は「もっと複雑なものを作れるようになりたい」という動機を持つことが多く、同じ部門の同じ業務アプリを作り続ける状態が続くと意欲が落ちます。入社時点で第7章のキャリアパス（Lv.1〜Lv.4）を提示し、半年ごとに担当範囲を広げてください。もう一つは、ガバナンス不在のまま「なんでも屋」になるケースです。担当範囲を第10章のゾーニングで明示し、引き受けない業務を決めておくことが定着につながります。

まとめ：ローコード技術者の採用難は設計で解ける

ローコード技術者の採用難の大半は、市場ではなく自社の求人票と評価基準が作り出している。今日から着手できる打ち手は次の5つだ。

1. 求人票の必須要件から開発言語・GitHubを外す：「業務改善の実務経験」に置き換える（第4章）

2. 候補者側の語彙を求人タイトルに入れる：「業務改善」「DX推進」「Power Apps」「kintone」（第2章・第8章）

3. コーディングテストを業務シナリオ型の実技課題に差し替える：評価は4軸で面接官間に共有する（第5章）

4. 外部採用と社内育成を並走させる：市場の絶対数不足は既存社員のリスキリングで埋める（第6章）

5. ガバナンスを採用と同時に置く：ゾーニング・承認フロー・定期監査を採用前に初版だけ作る（第10章）

母集団を「コードが書ける人材」に絞ることは、候補者プールを自ら狭める行為だ。採用対象を広げれば、フルスタックエンジニアを業務ツール改善から解放し、より価値の高い開発に集中させる効果も同時に得られる。

techcellarでは、エンジニア採用支援（スカウト運用代行・AIスカウト・採用AX）を提供しています。ノーコード・ローコード人材採用の設計から実行まで、13以上のスカウト媒体での運用経験をベースにサポートします。まずはサービス詳細ページをご確認ください。