IT人材ゼロでも業務システムは内製できる — 2030年最大79万人不足時代の中小企業ノーコード戦略(Lark Base)

この記事でわかること

• なぜ中小企業のIT人材不足は「採用」では解決しないのか（経済産業省の2030年試算の読み方）
• SIer外注型とノーコード内製型の違い — コスト・スピード・変更容易性・属人化リスクの比較
• なぜ Lark Base が中小企業のノーコード内製に向くのか（定着障壁の低さと料金の考え方）
• 非エンジニアの当社が自社EC業務を月240時間 → 24時間に圧縮した内製プロセスの中身
• 最初の業務システムを内製で立ち上げる30日ロードマップ（週次の具体手順）
• 内製化で「別の属人化」を生まないための Docs/Wiki 運用と、つまずきポイントTOP5

目次

1. 結論 — IT人材ゼロの壁は「採用」ではなく「ノーコード内製」で越える
2. なぜ採用では解決しないのか — 2030年最大79万人不足という構造
3. 外注型 vs ノーコード内製型 — 5つの観点で比較する
4. なぜ Lark Base が中小企業のノーコード内製に向くのか
5. 自社EC事例 — 非エンジニアが月240h→24hを内製で実現したプロセス
6. 30日ロードマップ — 最初の業務システムを内製で立ち上げる順序
7. 内製化で「別の属人化」を生まないための Docs/Wiki 運用
8. 内製でつまずくポイントTOP5と回避策
9. よくある質問（FAQ）
10. まとめ — 内製は「全部自分で作る」ことではない

結論 — IT人材ゼロの壁は「採用」ではなく「ノーコード内製」で越える

結論を先に述べます。社内にIT人材がいない中小企業が業務システムを持つ最短ルートは、エンジニアを採用することでも、丸ごとSIerに外注することでもなく、現場の担当者がノーコードツールで「作りながら育てる」内製化です。理由はシンプルで、採用は競争が激化して現実的に難しく、外注は変更のたびに費用とリードタイムが発生して業務の変化に追いつけないからです。ノーコード内製なら、業務を一番わかっている現場の人間が、その場で作り、その場で直せます。

もちろん「内製＝全部自分で作る」ではありません。正しくは 「基幹の会計・給与のような領域は既製SaaSや専門ベンダーに任せ、日々変化する現場の業務台帳・進捗管理・申請フローだけをノーコードで内製する」 という切り分けです。この線引きさえ間違えなければ、非エンジニアでも業務システムは回り始めます。実際、当社（アウフヘーベンジャパン株式会社）は専任エンジニアを置かずに、自社EC事業のバックオフィス業務を 月240時間 → 24時間（90%削減）まで内製で圧縮しました。

本記事では、その根拠となる公的データ（経済産業省「IT人材需給に関する調査」）を確認したうえで、外注と内製の比較 → Lark Base が向く理由 → 自社事例 → 30日ロードマップ、の順で「今日から始められる粒度」まで分解します。

なぜ採用では解決しないのか — 2030年最大79万人不足という構造

結論から言うと、IT人材不足は一時的な景気変動ではなく構造的な問題であり、中小企業が採用競争でエンジニアを確保し続けるのは年々難しくなります。だからこそ「作れる人を採る」から「現場が作れる道具を持つ」へ発想を切り替える必要があります。

経済産業省が委託し、みずほ情報総研株式会社が実施した「IT人材需給に関する調査」（2019年公表）では、IT人材の不足は調査時点の約17万人から、2030年には需要の伸びが高位のシナリオで約79万人、中位のシナリオでも約45万人に拡大すると試算されています（出典: 経済産業省「IT人材需給に関する調査（概要）」2019年）。ここで重要なのは、「79万人」は複数シナリオのうち需要が最も伸びた場合の最大値である点です。数字を過大に受け取る必要はありませんが、中位でも45万人という水準は、採用市場が今後さらに売り手優位になることを示しています。

この構造は、中小企業のDXが進まない理由と直結しています。2026年版 中小企業白書によれば、AI活用に取り組んだ中小企業は約3割にとどまり、ビジネスモデルの変革まで踏み込んだ「DXの段階」に到達している企業はわずか 2.8%です。そして活用が進まない最大の理由は「活用する業務のイメージができていない」こと。つまり技術そのものより、「誰が、どの業務を、どう形にするか」が詰まっているのです。

ここに採用のジレンマがあります。DXを進めるにはIT人材が要る。しかしそのIT人材が採れない。そして今いる従業員は、DXで無くすべきはずの手作業の転記・集計・確認作業に時間を奪われ続けている——この悪循環を断つには、外部人材の確保を待つのではなく、今いる現場の担当者が、コードを書かずに業務システムを組める状態を作るのが現実解です。それがノーコード内製化です。

外注型 vs ノーコード内製型 — 5つの観点で比較する

結論から言うと、基幹領域は外注、日々変わる現場業務はノーコード内製が最適解です。両者は対立ではなく役割分担ですが、「変化の速い業務」を外注に出すと、コストとスピードの両面で不利になります。以下の比較表で、その理由を5つの観点から整理します。

ただしノーコード内製にも弱点があります。作った本人しか触れない「新たな属人化」と、ベンダーロックインならぬ「担当者ロックイン」です。これは後述の Docs/Wiki 運用で防ぎます。また、会計・給与計算・在庫の基幹管理のように法対応や高い正確性が求められる領域は、無理に内製せず既製SaaSや専門ベンダーに任せる——この線引きが内製成功の分かれ目です。会計まわりは freee/マネーフォワードと Lark を連携させる方法で「既製SaaS＋Lark」の形に寄せるのが定石です。

要するに、「変化が速く、現場が主体で回す業務」ほど内製が有利で、「変化が遅く、正確性・法対応が重い業務」ほど外注・既製品が有利という切り分けです。多くの中小企業が抱える案件管理・進捗管理・申請フロー・顧客台帳・シフト管理は、前者に該当します。

なぜ Lark Base が中小企業のノーコード内製に向くのか

結論から言うと、ノーコードで作れる「業務データベース」を持ちながら、チャット・承認・カレンダー・ドキュメントと同じアプリの中にある——この一体感が、中小企業の内製の「定着障壁」を大きく下げるからです。

ノーコードで業務システムを作れるツールは Lark Base のほかにも kintone や Notion があり、それぞれ良さがあります。そのなかで Lark Base が中小企業に向く理由は主に3つです。

理由①：定着障壁が低い。 内製の最大の失敗は「作ったけど誰も使わない」です。Lark Base は、社内のチャット・ビデオ会議・承認・カレンダー・Docs と同じアプリの中にあるため、従業員が「別のシステムにログインする」心理的ハードルがありません。通知もそのまま Lark のチャットに届きます。ツールが分散していないことが、そのまま定着率に効きます。この点は Lark Base が中小企業の業務効率を変える3つの理由でも詳しく解説しています。

理由②：料金がシンプルで、内製の初期投資がほぼゼロ。 Lark の料金体系は下表のとおりです（税抜・年払い、2026年7月時点、出典: Lark 公式料金ページ）。20名までは Starter プランで無料のため、小さく試すコストが実質ゼロで済みます。

たとえば30名の会社なら、無料枠（20名）を超えるため Pro プランが必要で、1,420円 × 30名 = 月額42,600円（税抜・年払い）が目安です。SIerに1つ業務システムを外注する初期費用と比べれば、内製の投資回収は圧倒的に早くなります。行数上限がボトルネックになるのは、1テーブルに数万件のレコードを溜める場合だけで、多くの中小企業の業務台帳は Pro の2万行で十分に足ります。

理由③：作った後の自動化・承認まで内製で完結できる。 Lark Base は、レコードの作成・更新をトリガーにチャット通知や条件分岐を動かす自動化ワークフローを標準搭載しています。「案件が受注ステータスになったら担当者に通知」「申請が承認されたら台帳を更新」といった処理を、コードなしで組めます。承認フローの作り方は Lark Base × Workflow で承認フローを自動化する実装ガイドを参照してください。

自社EC事例 — 非エンジニアが月240h→24hを内製で実現したプロセス

結論から言うと、当社が業務時間を 月240時間 → 24時間（90%削減）に圧縮できたのは、特別なエンジニアがいたからではなく、「転記が発生している業務」を1つずつ台帳に集約し、通知と自動化で人手を減らしたからです。専任のIT担当は置いていません。

当社は群馬・前橋を拠点に自社EC事業を運営しています。以前のバックオフィス業務は、受注管理をスプレッドシート、在庫を別ファイル、問い合わせ対応をメールとチャット、発送指示を手作業のコピペ——という「ツール分散＋手作業の転記」の典型でした。ここに毎月240時間が溶けていました。

内製で取り組んだのは、次の順序です。

1. 受注台帳を Lark Base に一本化。 複数ファイルに散っていた受注情報を1つの Base テーブルに集約。ステータス（受注／出荷準備／発送済／完了）をフィールド化し、目視の突き合わせをなくしました。
2. ステータス変化を自動通知に。 「出荷準備」になったら担当チャットに自動でカード通知。「毎朝ファイルを開いて確認する」作業そのものを消しました。
3. 問い合わせ対応を同じ Lark 内に集約。 顧客対応の履歴を Base に紐づけ、チャットから台帳を参照できる状態に。担当者間の引き継ぎコストが激減しました。
4. 定型のレポート集計を Base のダッシュボードに。 手作業の月次集計をやめ、Base 上で自動集計。数字を作る時間がゼロになりました。

ポイントは、最初から完璧な設計を目指さなかったことです。まず受注台帳という「1つの業務」だけを内製し、回りながらフィールドと自動化を足していきました。この「作りながら育てる」進め方こそ、外注では真似できない内製の強みです。脱スプレッドシートの具体的な置き換え手順は Lark Base 脱Excel 30日チャレンジに、EC事業での削減の全体像は 中小EC事業者の Lark 活用（240h→24h の現実）にまとめています。

30日ロードマップ — 最初の業務システムを内製で立ち上げる順序

結論から言うと、内製は「30日で1つの業務システムを本番稼働させる」を最初のゴールに置くと成功します。以下は、IT人材ゼロの中小企業がつまずかずに進むための週次ロードマップです。

この30日を1サイクル回せば、2つ目・3つ目の業務は同じ型で速く作れるようになります。全社的にDXを軌道に乗せる順序は 中小企業のDXを90日で軌道に乗せる実践ロードマップで、より大きな時間軸を解説しています。まずは本記事の30日で「内製で1本作れた」という成功体験を作ることが何より重要です。

内製化で「別の属人化」を生まないための Docs/Wiki 運用

結論から言うと、内製の最大のリスクは「作った本人しか触れない台帳」を量産してしまうことです。これを防ぐ鍵は、作った本人が異動・退職しても回るように、設計意図と運用ルールを Lark Docs/Wiki に文章で残すことです。

SIer外注のベンダーロックインを嫌って内製したのに、今度は「Aさんしかこの Base を直せない」という担当者ロックインに陥る——これは内製あるあるの失敗です。ノーコードは「誰でも触れる」のが利点なのに、ドキュメントが無いと結局属人化します。

対策はシンプルで、業務システムを1つ作るごとに、次の3点を Lark Docs に1ページで残します。

• この台帳は何のために作ったか（対象業務・想定利用者）
• 各フィールド・ステータスの意味と入力ルール（「この列は何を入れるか」）
• 自動化・承認フローの動き（何をトリガーに、誰に、何が通知されるか）

これを Lark Wiki に集約しておけば、担当者が代わっても、新しい人が読んで引き継げます。ノウハウを組織の資産に変える運用は Lark Wiki で社内ナレッジを蓄積する 30日プランで詳しく解説しています。「作る」と「残す」をセットにする——これが内製を一過性で終わらせないための鉄則です。

内製でつまずくポイントTOP5と回避策

結論から言うと、内製の失敗はツールのせいではなく、ほぼ「進め方」で決まります。中小企業が実際につまずきやすい5点と回避策を挙げます。

1. 最初から大きく作ろうとする。 → 全社システムを一気に内製しようとすると挫折します。「1業務・1台帳」から始め、30日で1本を回すこと。
2. 凝った設計にこだわる。 → 完璧なデータベース設計を目指すと着手できません。今使っている項目だけで作り、運用しながら足すのが正解です。
3. 基幹業務まで内製しようとする。 → 会計・給与・在庫の基幹管理は既製SaaSや専門ベンダーに任せ、変化の速い現場業務だけ内製する線引きを守ること。
4. ドキュメントを残さず属人化する。 → 前章のとおり、作るたびに設計意図と運用ルールを Docs/Wiki に残すこと。
5. 作って終わりで定着させない。 → 旧Excel/紙を正式に廃止し、通知を現場のチャットに流し込むところまでやって初めて定着します。

これらは、Lark に限らずノーコード内製全般に共通する落とし穴です。Lark 導入そのものでよくある失敗は Lark 導入失敗パターン3つにまとめているので、あわせて確認しておくと安全です。逆に言えば、この5点さえ避ければ、IT人材ゼロでも内製は十分に回せます。

よくある質問（FAQ）

まとめ — 内製は「全部自分で作る」ことではない

IT人材が2030年に最大約79万人不足するこの時代、中小企業が業務システムを持つ現実解は、採用でも丸ごと外注でもなく、「変化の速い現場業務だけをノーコードで内製する」という切り分けです。基幹は既製SaaSに任せ、日々変わる台帳・進捗・申請フローだけを Lark Base で内製すれば、IT人材ゼロでも業務システムは動き出します。

当社は非エンジニアで、自社EC業務を 月240時間 → 24時間（90%削減）まで内製で圧縮しました。特別な才能ではなく、「1業務・1台帳から始め、通知と自動化で人手を減らし、Docs/Wiki に残して属人化を防ぐ」という順序を守っただけです。まずは本記事の 30日ロードマップで、最初の1本を本番稼働させてみてください。

関連記事

• Lark Base が中小企業の業務効率を変える3つの理由 — 内製の土台となる Base の基礎理解。
• Lark Base 脱Excel 30日チャレンジ — 最初の台帳を作る具体的な置き換え手順。
• 中小EC事業者の Lark 活用（240h→24h の現実） — 本記事の自社事例の全体像。
• Lark Wiki で社内ナレッジを蓄積する 30日プラン — 属人化を防ぐ Docs/Wiki 運用の詳細。
• 中小企業のDXを90日で軌道に乗せる実践ロードマップ — 内製を全社DXへ広げる時間軸。
• Lark vs kintone どっちを選ぶべきか【中小企業向け徹底比較】 — ノーコード内製ツールの選定比較。
• Lark 導入失敗パターン3つ — 内製・導入でつまずかないための注意点。
• Lark Base 業務システム構築サービス — 内製の伴走メニュー。
• アウフヘーベンジャパン株式会社 会社案内 — 群馬・前橋拠点。Lark 導入を支援する独立系コンサルティング事業者。