在庫管理システムは自作できる?5つの手段の限界と、破綻する6つの境界線【2026年版】

「在庫管理システムを買うほどの規模ではないが、Excelはもう限界だ。自分たちで作れないか」——製造業や卸、EC事業者の担当者から、こうした相談をよく受けます。テンプレートを拾ってきて関数を足し、そのうちマクロが増え、気づけば前任者しか中身が分からない表になっている。かといって数百万円のシステムを入れる話でもない。この宙ぶらりんの状態が、いちばん長く続きます。

結論から言うと、在庫管理システムは自作できます。手段はExcel・Googleスプレッドシート、Access、kintoneなどのノーコード、AppSheet、自前開発の5つで、拠点が1つ、SKUが数百、在庫に触る人が数名までなら、自作で十分回ります。問題は「自作できるか」ではなく「どこまでもつか」です。そして、もたなくなる境界線は6つあり、拠点数、SKU数、同時利用者数、ロット・使用期限の管理、基幹システムとの連携、複数人での棚卸のどれかに触れた時点で、作り方を変えるか外に出すかの判断が要ります。

自作の可否を規模で語る記事は多いのですが、現場で先に壊れるのは規模ではなく、データの持ち方です。在庫を「いまいくつあるか」という数量だけで持っている表は、棚卸が合わなかったときに原因を追えません。逆に、入出庫の履歴で持っていれば、拠点が増えても人が増えても、同じ考え方のまま広げられます。この違いを知っているかどうかで、3年後に作り直すかどうかが決まる、というのが実情です。

本記事では、自作の5つの手段の位置づけ、手段別に作れるものと限界(料金と上限値は各公式サイトで2026年9月15日に直接確認しました)、自作が破綻する6つの境界線、自作を選ぶ場合の設計の勘所5つ、移行するときの判断基準とデータ移行で詰まる3点、当社の位置づけ、よくある質問の順に解説します。ランキングは付けません。どれが一番かは、拠点数とSKU数と人数で入れ替わるからです。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。在庫管理の相談で多いのは「Excelが重い」ではなく、「棚卸が合わない」「拠点をまたぐと数が違う」の2つです。当社に相談をいただいても、話を聞いたうえで「いまのスプレッドシートを持ち直せば足ります」とお伝えして、開発をお受けしない案件も毎年あります。この記事を読み終えるころには、自社が境界線のどちら側にいるかが判断できるはずです。

在庫管理システムの自作には5つの手段がある——「どこまで自分で作るか」で選ぶ

在庫管理システムの自作というと、Excelかプログラミングかの二択で語られがちですが、2026年時点の現実的な選択肢は5つあります。並べる順番は「どこまでを自分で作るか」の度合いです。既にあるものを組み合わせるほど早く安く始められ、自分で作るほど自社の業務に合わせられます。まず全体の地図を押さえてから、次章で各手段の限界を見ていきます。

5つの手段の位置づけ——表計算、デスクトップDB、ノーコード業務アプリ、アプリ生成、自前開発

上位の解説記事はExcel・Access・Pythonの3つで書かれているものが多いのですが、この3択はノーコードの業務アプリが普及する前の分類です。社内にコードを書ける人がいない会社にとって、実際に選べるのは1・3・4のいずれかで、2は既にAccessの資産がある会社、5は社内にエンジニアがいる会社の選択肢になります。ノーコードそのものの分類や一般的な限界は「ノーコードとは」の記事で扱っているので、本記事では在庫管理で何が作れるかに絞ります。

そもそも在庫管理システムに最低限いる機能は4つ(入庫・出庫・現在庫・棚卸)

どの手段を選ぶかを考える前に、作る対象をはっきりさせておきます。在庫管理システムに最低限いる機能は4つです。

1. 入庫の記録——仕入・生産・返品で在庫が増えたことを、日付・品目・数量・場所つきで残す
2. 出庫の記録——出荷・消費・廃棄で在庫が減ったことを、同じ粒度で残す
3. 現在庫の把握——いま何がどこにいくつあるかを、いつでも見られる
4. 棚卸——実地の数と記録の数を突き合わせ、差異を見つけて調整する

この4つに、発注点のアラート、引当(受注済みで動かせない在庫の確保)、ロットや使用期限の管理、複数拠点の在庫移動が加わっていきます。逆に言えば、この4つが成立していれば在庫管理システムと呼べます。自作を検討するときは、最初から全部を作ろうとせず、4つだけで動くものを1か月使ってみるのが確実です。

自作が向くのは「業務が自社独自」「小さく始めたい」「すぐ直したい」の3条件

自作には、市販のシステムにはない3つの強みがあります。第一に、自社独自の業務に合わせられること。仮の在庫、預け在庫、支給品、セット品のばらしなど、業種特有の扱いは市販品では設定しきれないことがあります。第二に、小さく始められること。初期費用をかけずに動かし、使いながら直せます。第三に、直したいときにすぐ直せること。ベンダーに見積もりを取って承認を待つ時間がかかりません。

一方で、この3つの強みは裏返すとリスクにもなります。自社独自に作り込むほど、作った人以外が直せなくなる。小さく始めたぶん、大きくなったときの作り直しが必要になる。すぐ直せるからこそ、誰も設計を管理しないまま複雑になる。作れることと、運用が続くことは別の話です。次章では、この5つの手段が実際にどこまで届くのかを、各社が公開している上限値で確かめていきます。

手段別に「作れるもの」と「限界」——公式の上限値で線を引く【2026年9月15日時点】

ここからが本題です。5つの手段は、それぞれ公式に上限値が公開されています。まとめサイトの体感ではなく、提供元が自分で書いている数字で線を引けば、自社が届くのかどうかを冷静に判断できます。以下の料金と上限は、すべて2026年9月15日に各公式サイトで直接確認したものです。ランキングは付けません。どれが最適かは拠点数・SKU数・人数で入れ替わるからです。

5手段の比較表(作れるもの/限界/料金/向く規模)

表の右端を見てください。手段の優劣ではなく、規模帯が違うだけだと分かります。SKU数百・1拠点の会社がAppSheetやkintoneを飛ばして自前開発に行くのは、ほぼ確実に過剰投資です。逆に、拠点3つでロット管理が必要な会社がExcelで粘るのは、いずれ人手で埋め合わせることになります。

Excel・Googleスプレッドシート: 行数ではなく「同時利用」と「履歴」で先に詰まる

Excelの限界というと行数の話になりがちですが、1シートに1,048,576行入る以上、中小企業の在庫データが行数で詰まることはほとんどありません。先に来るのは2つです。

1つ目は同時利用です。Excelは共同編集を有効にした場合に同時にファイルを開けるユーザー数が256と公開されていますが、実務で問題になるのはその手前、「同じ行を2人が同時に触ったときにどちらが勝つか」です。倉庫の担当者が出庫を入力している最中に、事務所で別の人が同じ品目を直せば、片方の入力は消えます。Googleスプレッドシートは同時編集に強く、最大100タブ/デバイスまで同時編集できると公開されていますが、それでも「数量セルを上書きする」作りである限り、同じ問題は残ります。

2つ目は履歴です。在庫表の多くは、品目ごとに「現在庫」の列を持ち、入出庫のたびにその数字を書き換えます。この作りだと、棚卸で3個足りなかったときに、いつ誰の操作でずれたのかを追えません。これが失敗のもとです。表計算で作るなら、現在庫のセルを書き換えるのではなく、入出庫を1行ずつ積む形にしてください。詳しくは設計の勘所の章で扱います。

Access: 2GBの壁と、壊れたときに直せる人がいるかどうか

Accessは表計算より一段まともなデータベースで、テーブルを分けて結合でき、入力フォームも帳票も作れます。公式の仕様では、データベースファイル(.accdb)の合計サイズは2GBからシステムオブジェクト分を引いた容量、同時ユーザー数は255とされています。SKU数千・入力担当10名程度までなら、設計さえまともなら十分に動きます。

問題は2つあります。1つは2GBの壁で、入出庫の履歴を数年ぶん貯めると現実に到達します。到達する前に古い履歴を別ファイルへ退避する運用が要ります。もう1つはより深刻で、壊れたときに直せる人がいるかどうかです。Accessのファイル破損は、ネットワーク越しの共有で起きやすく、復旧には専門の知識がいります。社内にAccessを触れる人が1人しかいない状態は要注意です。その1人が異動した瞬間、会社の在庫がブラックボックスになります。

kintone・AppSheet: 履歴と同時利用は解決する。料金体系は人数で決まる

ノーコードの業務アプリは、表計算とAccessが抱える2つの問題——同時利用と履歴——を、仕組みとして解決します。レコード単位で更新され、変更履歴が残り、権限も設定できるからです。在庫管理なら、入庫アプリ・出庫アプリ・品目マスタを分けて作り、関連づけで現在庫を出す形が基本になります。

判断の分かれ目は料金体系です。kintoneは1ユーザーあたり月額1,000円(ライト)・1,800円(スタンダード)・3,000円(ワイド)で、ライトとスタンダードは最小10ユーザーからの契約になります。5名の会社でも10ユーザー分、スタンダードなら月18,000円(税抜)からという計算です。30日間の無料お試しがあり、初期費用はかかりません。AppSheetは1ユーザーあたり月額5USD(Starter)・10USD(Core)・20USD(Enterprise Plus)で、1USD=150円換算の目安ならおよそ750円・1,500円・3,000円。無料で使えるのはアプリの試作と最大10ユーザーまでのテストで、本番運用は有償プランになります。

つまり、少人数ならAppSheetのほうが安く始められ、10名を超えて権限や業務の広がりが出てくるとkintoneのほうが管理しやすい、という傾向があります。バーコードの読み取りは、AppSheetならスマホのカメラで扱えるため、現場で現物のそばに入力を置きたい会社には向きます。では、この2つを選べばどこまでも行けるのか。ここから先が、次章の境界線の話です。

自作が破綻する6つの境界線——拠点、SKU、同時利用、ロット・期限、基幹連携、棚卸

自作が破綻するのは「規模が大きくなったから」ではありません。在庫という業務が持つ性質に、自作の作りが追いつかなくなるからです。当社が相談を受けてきた範囲では、破綻の引き金になるのは次の6つに集約されます。どれか1つに触れた時点で、いまの作りのまま続けるか、作り方を変えるか、外に出すかの判断が必要になります。

境界線の一覧表(何が起きるか/なぜ自作では届かないか)

この6つは、ツールの性能の話ではありません。仮にkintoneに移しても、拠点という軸を持たないまま移せば1番は解決しませんし、入出庫の履歴を持たないまま移せば6番は残ります。つまり境界線は、ツールを変えるだけでは越えられません。

拠点2以上・SKU数千・同時利用10名——規模の3つの境界線

規模の境界線は、数字で確かめられるので判断しやすいほうです。

拠点2以上が最初に来ます。1拠点なら「在庫数」は1つの数字ですが、2拠点になると「どこにいくつ」という2次元になり、さらに拠点間の移動という中間状態が生まれます。出荷済みだが未着の在庫を、どちらの拠点の数字に入れるか。これを決めていない表は、必ず全社合計が合いません。拠点を増やす予定があるなら、1拠点のうちから場所の列を持っておくことをお勧めします。あとから足すのは、ほぼ作り直しです。

SKU数千は、人の目で管理できる限界です。数百までなら担当者が全品目を頭に入れられますが、数千になると「同じ物が別品番で登録されている」ことに気づけません。当社が見てきた例では、品番の採番ルールが決まっていない会社ほど、この段階で在庫が実態より多く見えます。

同時利用10名は、表計算の実務上の限界です。Excelの公式仕様では共同編集で同時に開けるユーザー数は256、Googleスプレッドシートは同時編集が最大100タブ/デバイスとされていますが、公式の上限に届く前に、上書きによる入力消失が業務を止めます。倉庫・事務所・営業が同じ表を触り始めたら、その時点で仕組みを変える検討に入ってください。

ロット・使用期限・基幹連携・棚卸——要件の3つの境界線

要件の境界線は、数字では測れないぶん、越えていることに気づくのが遅れます。

ロットと使用期限は、食品・医薬品・化粧品・部品を扱う会社では避けられません。同じ品目を「いつ入荷したか」で分けて持ち、出庫時に古いものから引き当てる必要があります。表計算でも作れないことはありませんが、品目×ロットの行数が一気に増え、先入先出の引当を関数で書くことになり、間違いに気づけなくなります。

基幹システムとの連携は、二重入力が常態化したときが合図です。在庫だけを自作で切り出すと、受発注や販売管理と数字を手で合わせる作業が発生します。ノーコードでもAPI連携は可能ですが、kintoneのAPIリクエストが1アプリあたり1日1万件(ライト)・10万件(スタンダード)と公開されているとおり、上限があります。リアルタイム同期を前提に設計すると上限に当たることがあるため、連携は頻度と方式から決めてください。

複数人での棚卸は、最も見落とされます。棚卸の最中も入出庫は止まりません。「何時時点の在庫を数えるのか」という締めを決めずに始めると、差異が出たときに「数え間違い」なのか「締め後の入出庫」なのか区別できません。差異の原因が分からないまま記録を実地の数に合わせる作業が続くと、システムの数字を誰も信用しなくなります。

境界線を越えた合図は「棚卸が合わない」と「拠点で数が違う」

私は人材業界の出身で、2018年からホーチミンで約100社の開発体制を支援してきました。在庫管理について相談をいただくとき、最初に出てくる言葉はたいてい「Excelが重い」ではありません。「棚卸が合わない」と「拠点をまたぐと数が違う」の2つです。この2つが出ている会社は、6つの境界線のうち1番か6番、多くは両方を越えています。

重要なのは、この2つが出ている時点で、原因はツールではなくデータの持ち方にあるということです。ここを直さずに市販のシステムへ移しても、移した先で同じ差異が出ます。次章では、手段を変えても通用する設計の勘所を5つに絞って説明します。

自作を選ぶなら押さえる設計の勘所5つ——あとで作り直さずに済む作り方

境界線を越えていないなら、自作で十分です。ただし作り方を間違えると、越えたときに全部作り直すことになります。ここでは、Excelでもkintoneでも自前開発でも通用する設計の勘所を5つに絞って説明します。どれも難しい技術の話ではなく、最初に決めておくかどうかだけの話です。

勘所1: 在庫を「数量」ではなく「入出庫の履歴」で持つ

これが5つのうちで最も効きます。よくある在庫表は、品目ごとに1行あり、在庫数の列を入出庫のたびに書き換えます。この作りは、いま何個あるかは分かりますが、なぜその数になったかが分かりません。棚卸差異が出たときに追跡できず、間違って上書きしても誰も気づけません。

代わりに、入出庫を1行ずつ積む形にします。

この形なら、修正は「取り消しの行を足す」で行い、元の記録は消しません。差異が出たときに、いつ誰の操作でずれたかを追えます。行数は増えますが、Excelでも1シート1,048,576行まで入るので、中小企業の入出庫で行数が問題になることはまずありません。

勘所2〜3: マスタとトランザクションを分ける / 現在庫は計算して出す

勘所2はマスタとトランザクションの分離です。 品番・品名・単位・標準原価・保管場所といった「めったに変わらない情報」(マスタ)と、日々発生する入出庫(トランザクション)を、同じ表に混ぜないでください。混ざっていると、品名を直したときに過去の伝票の品名まで変わってしまい、過去の記録が再現できなくなります。Excelならシートを分ける、kintoneならアプリを分ける、というだけの話です。

勘所3は、現在庫を持たないことです。 現在庫は、入出庫の履歴を品番×場所で合計すれば出せます。ピボットテーブルでも、kintoneの関連レコード一覧でも、SQLのSUMでも同じです。現在庫を独立した列として持つと、履歴と現在庫の2か所を更新することになり、必ずどこかでずれます。データを2か所に持たない、というのは在庫管理に限らずシステム設計の基本ですが、在庫では特に効きます。

ただし、SKUが数千を超えて毎回の合計が重くなってきたら、日次で締めた在庫を保存しておき、そこからの差分で現在庫を出す形に変えます。この切り替えが必要になった時点が、表計算からデータベース側へ移る一つの目安です。

勘所4〜5: 締めと棚卸差異の置き場所を決める / 入力を現物のそばに置く

勘所4は締めです。 「何時時点の在庫を正とするか」を決めてください。月末の営業終了時点なのか、棚卸を始める直前なのか。締めを決めたら、締め後に発生した入出庫は翌月の記録として扱い、締めた月の数字は動かしません。そして棚卸で差異が出たら、実地の数に書き換えるのではなく、「棚卸調整」という区分の入出庫行を1本足して合わせます。こうすると、差異がいつどれだけ出たかが履歴に残り、翌月以降に原因を探せます。差異をなかったことにする運用は、失敗のもとです。

勘所5は入力の置き場所です。 在庫がずれる原因の大半は、記録を後回しにすることです。現物を動かした人が、動かしたその場で入力できるようにしてください。倉庫にPCを1台置くだけでも違いますが、現実的にはスマホで入力できる形が続きます。AppSheetのようにスマホのカメラでバーコードを読める手段を選ぶと、品番の打ち間違いも同時に減ります。「事務所に戻ってからまとめて入力」という運用を前提に設計すると、どんなに良い画面を作っても数字は合いません。

作る前に決めておく3つ(対象範囲・ID・運用ルール)と、要件定義に持ち込まないもの

作り始める前に、次の3つだけは紙に書いて決めてください。

• 対象範囲——どの倉庫の、どの品目までを対象にするか。試作品や支給品、預け在庫を含めるかどうか
• ID——品番の採番ルール、伝票番号の付け方、場所コードの体系。あとから変えると過去の記録とつながらなくなります
• 運用ルール——誰がいつ入力するか、修正は誰が承認するか、締めはいつか、棚卸は年に何回か

逆に、最初の要件定義に持ち込まないほうがよいものもあります。原価計算、需要予測、複雑な引当ロジック、他システムとの自動連携。これらは在庫の記録が正確になってから初めて意味を持つ機能で、記録が合っていない段階で作ると、間違った数字を高速に処理するだけになります。業務の棚卸しから始める進め方は「社内システム開発 進め方」の記事で、要件定義という工程そのものの進め方は「要件定義 進め方」の記事で扱っています。

なお、自前開発を選ぶ場合は、品質を人の注意力ではなく仕組みで担保してください。当社が開発を担うときも、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点を必ず入れています。社内で作る場合でも、せめて「作った人以外がレビューする」1点だけは守る価値があります。

自作から移行するときの判断基準——4つの問いと、移す順番、データ移行で詰まる3点

境界線を越えたとき、選択肢は「作り方を変えて自作を続ける」「市販のシステムに寄せる」「個別に開発する」の3つです。どれを選ぶかは、機能の比較表を眺めても決まりません。次の4つの問いに答えるほうが早く決まります。

4つの問い(止まると何が止まるか/直せる人がいるか/要件は自社独自か/5年で見た総額)

問い1: そのシステムが止まると、何が止まりますか。 出荷が止まるなら、復旧の見通しが立たない仕組みを使い続けるべきではありません。バックアップと復旧手順が文書になっていて、作った本人以外が実行できるかを確かめてください。答えがノーなら、その一点だけで移行を検討する理由になります。

問い2: いま直せる人は何人いますか。 1人なら属人化しています。その1人が辞めた、異動した、というのは相談でよく聞く話です。2人以上が中身を理解していて、手順書があるなら、自作の継続は現実的です。

問い3: 要件は本当に自社独自ですか。 「うちの業務は特殊だから」と言われる業務の多くは、実は市販の在庫管理SaaSの標準機能で足ります。特殊なのは業務そのものではなく、いまの運用のやり方だった、ということが少なくありません。標準機能に寄せられるなら、SaaSのほうが確実に安く速いです。

問い4: 5年間の総額で比べていますか。 自作は初期費用がほぼゼロですが、作る人の工数、直す工数、止まったときの損失が乗ります。SaaSは月額が見えやすいかわりに、人数が増えると比例します。個別開発は初期が重く、保守費が続きます。3つを5年で並べて初めて比較になります。外注した場合の費用の相場——規模別・機能別のレンジや、在庫管理を含む業務システムの目安——は「業務システム開発 外注 費用」の記事に整理してあるので、金額の当たりを付けるときはそちらを見てください。内製と外注をどう切り分けるかという一般的な判断は「システム開発 内製 外注」の記事で扱っています。

移す順番——全部入れ替えない。在庫だけ切り出すか、周辺から寄せるか

在庫管理は、受発注・販売管理・生産・会計とつながっています。だから「在庫だけ入れ替える」と決めた瞬間に、周辺との数字合わせが発生します。順番の取り方は大きく2つです。

どちらの場合も、全部を一度に入れ替えないでください。基幹そのものを入れ替える判断に踏み込む場合は「レガシーシステム 刷新 外注」の記事で進め方を扱っています。当社が支援した介護記録SaaS「CareViewer」では、日本語のブリッジSE1名とフルスタックエンジニア2名の体制で、週次で優先順位を決めながら開発を続けています。在庫管理の作り替えも同じで、一度に全部を決めきるより、動くものを出しながら優先順位を毎週見直すほうが早く着地します。

データ移行で必ず詰まる3点(名寄せ、単位、過去の履歴をどこまで持つか)

移行を決めたあと、見積もりに入っていなくて揉めるのがデータ移行です。在庫では、次の3点が必ず問題になります。

1. 名寄せ——同じ物が複数の品番で登録されている、逆に違う物が同じ品番になっている。移行先で1本化するには、現場の人が目で確認する作業が発生します。SKU数千なら数週間かかることもあります。この作業は外注できません。品物を知っているのは自社だからです
2. 単位——「箱」「ケース」「本」が混ざっている。1ケース12本なのか10本なのかが品目ごとに違う。入数のマスタを整備しないと、移行した瞬間に在庫数がおかしくなります
3. 過去の履歴をどこまで持つか——全期間を移すのか、残高だけ移して履歴は旧システムを参照するのか。全期間を移すと費用と期間が伸びます。多くの場合、移行日時点の残高+直近1年の履歴で足ります

この3点は、移行先を決める前に着手できます。というより、移行先が決まってから始めると必ず遅れます。名寄せと入数の整備は、いまの自作システムのままでも今日から進められる作業です。移行を検討し始めた段階で、まずここから手を付けてはいかがでしょうか。

自作の限界を超えたときの選択肢——当社のラボ型開発と、自作で十分なケース

ここまで読んで「まだ境界線を越えていない」と判断できたなら、この章は読み飛ばしてかまいません。自作を続けてください。この章は、6つの境界線のうち複数に触れていて、直せる人が社内に1人しかいない、という状態の方に向けた話です。当社の位置づけを書きますが、先に「作らないほうがよいケース」から書きます。

自作で十分なケース——当社が「作らないほうがよい」とお伝えする3条件

当社に在庫管理の相談をいただいても、次の3つに当てはまる場合は、開発をお受けせずに自作の継続か既製サービスの利用をお勧めしています。

1. 拠点1つ、SKU数百、在庫に触るのが5名以下——この規模なら、入出庫の履歴で持ち直したスプレッドシートか、AppSheetのようなツールで十分に回ります。開発費を払う意味がありません
2. 業務が市販SaaSの標準機能に収まる——特殊だと思っていた運用が、標準機能で説明できることは珍しくありません。標準に寄せられるなら、そのほうが安く速く、担当者が辞めても続きます
3. 1年以内に業務が大きく変わる予定がある——移転、事業の統廃合、基幹システムの入れ替えが控えているなら、いま在庫だけ作り込むのは投資の順番として得策ではありません

足りているなら作らないほうがよい、というのが当社の考えです。この3条件でお断りする案件は、毎年あります。

当社のラボ型開発の位置づけ——1名から、日本人PMフロント、月額約80万円〜

一方で、境界線を越えていて、業務が自社独自で、直し続ける必要があるなら、開発体制そのものを持つ選択肢があります。当社TALENTBASE VIETNAMが提供しているのは、ベトナム・ホーチミンのエンジニアで専属チームを組むラボ型開発です。在庫管理のように「作って終わり」にならず、業務が変わるたびに直し続ける必要があるシステムとは相性がよい形態です。

• 体制: 日本人PM/ブリッジSEをフロントに置くパターンA(推奨)と、エンジニアのみのパターンBの2つ。1名から契約でき、最短2週間で開始、増員は約1週間、縮小・交代は1か月単位
• 人財: 2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインします。協力会社や紹介を経由しないため、仲介マージンが乗りません
• 単価: 実務3年目安で1,500USD(1USD=150円換算で約22.5万円)、5年で2,000USD、10年目安・ブリッジSEで3,000USD。最小構成は日本人PMフロント+2〜3人月で月額約80万円から
• 進め方: 打ち合わせ→アサイン(約1週間)→候補者面談(約1週間)→開始。契約・支払いは日本国内法人・日本法準拠で、海外送金は不要です
• 品質: 日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点を標準にしています

実績としては、介護記録SaaS「CareViewer」を日本語ブリッジSE1名+フルスタック2名の体制で継続開発しており、従来の半分以下のコストで、週次の優先順位判断を回しています。ほかに決済アプリ(Stripe決済、二要素認証、ウォレット、PDF出力)や求人プラットフォーム(ATS)なども手がけており、在庫のように業務ロジックが複雑なシステムの継続開発は得意な領域です。

向かない案件——パッケージで足りる業務、単発で終わる開発

正直に書くと、当社が向かない案件もあります。1つは、市販のパッケージやSaaSで足りる業務です。標準機能で説明できる在庫管理に、専属チームを組む理由はありません。もう1つは、要件が完全に確定していて単発で終わる開発です。ラボ型は継続して手を入れる前提の形態なので、作って納めて終わりなら請負のほうが合います。数十名規模の一斉立ち上げや、CMMI準拠が必須の大規模基幹も、大手のSIerのほうが適任です。

自作で足りるのか、体制を持つべきなのか。判断に迷う段階でご相談いただいてかまいません。現在の拠点数・SKU数・在庫に触る人数と、いま使っている仕組みをお聞かせいただければ、作らずに済む方法があればその旨を先にお伝えします。

在庫管理システムの自作に関するよくある質問

在庫管理システムの自作について、実際にいただくことの多い質問を5つにまとめました。料金に関する回答は、すべて2026年9月15日に各公式サイトで確認した内容です。契約前には最新の情報をご確認ください。

Q1. 在庫管理システムを完全に無料で自作できますか

作れます。Googleアカウントがあればスプレッドシートは無料で使え、GASを書けば自動集計や通知も足せます。ただし「無料で使い続けられる範囲」には条件があります。kintoneは30日間の無料お試しはありますが、本番運用は最小10ユーザーからの契約で、1ユーザーあたり月額1,000円(ライト)からです。AppSheetは無料でアプリを試作でき、最大10ユーザーまでのテストができますが、本番運用は1ユーザーあたり月額5USD(Starter)からの有償プランになります。つまり、完全無料で続けられるのは表計算の範囲までと考えてください。

Q2. いまのExcelのまま続けてよいか、どう判断しますか

本文の6つの境界線のうち、1つも触れていなければ続けてかまいません。特に「棚卸が合わない」「拠点をまたぐと数が違う」という症状が出ていないなら、急いで変える理由はありません。ただし、在庫数の列を上書きする作りになっているなら、Excelのまま入出庫の履歴を積む形に直しておいてください。この直し方は、あとで別の仕組みへ移るときにもそのまま使えます。

Q3. バーコードの読み取りまで自作できますか

できます。AppSheetのようにスマホのカメラでバーコードを読める仕組みを使えば、専用のハンディ端末を買わずに始められます。kintoneもバーコード読み取りのプラグインや連携サービスがあります。Excelでも、USB接続のバーコードリーダーはキーボード入力として認識されるため、品番のセルにカーソルを置いて読ませれば入力できます。まず既存のスマホで試し、読み取り速度や耐久性が足りない場合に専用端末を検討する順番をお勧めします。

Q4. 自作と外注では費用がどのくらい違いますか

自作の初期費用はほぼゼロから、ツールを使っても月額数千円〜数万円です。外注して個別に開発する場合は、規模と機能によって数十万円から数千万円まで幅があり、一律の相場は示せません。規模別・機能別のレンジは「業務システム開発 外注 費用」の記事に整理しています。判断のうえで大事なのは、初期費用ではなく5年間の総額で比べることと、自作の場合に社内の人が使う工数を金額に換算して足すことです。

Q5. 作った人が辞めたらどうすればよいですか

辞める前に、手順書とデータのバックアップ手順を残してもらってください。最低限必要なのは、データがどこに保存されているか、復旧はどう行うか、月次の締めで何をしているかの3点です。すでに辞めてしまった場合は、まず「何が動いているか」の棚卸しから始めます。当社がこの状態のご相談を受ける場合も、いきなり作り直すのではなく、現行の仕組みを読み解いて文書に起こすところから始めます。体制としては1名からの参加も可能で、増員は約1週間、縮小や交代は1か月単位という柔軟な組み方です。属人化したまま動き続けている在庫管理の引き継ぎ

まとめ: 自作の可否は規模ではなく境界線で決まる——越えていなければ自作で十分

在庫管理システムは自作できます。手段はExcel・Googleスプレッドシート、Access、kintoneなどのノーコード、AppSheet、自前開発の5つで、それぞれ公式に上限が公開されています(Excelは1シート1,048,576行・共同編集で同時256ユーザー、Accessは2GB・同時255ユーザー、Googleスプレッドシートは1,000万セル・同時編集100、kintoneは最小10ユーザーで月額1,000円から、AppSheetは月額5USDからで無料はテスト用途。いずれも2026年9月15日に公式サイトで確認)。拠点1つ、SKU数百、在庫に触る人が5名以下なら、自作で十分に回ります。

自作が破綻するのは規模が大きくなったからではなく、6つの境界線——拠点2以上、SKU数千以上、同時利用10名以上、ロット・使用期限の管理、基幹システム連携、複数人での棚卸——のどれかに触れたときです。そして境界線はツールを変えるだけでは越えられません。在庫を「数量」ではなく「入出庫の履歴」で持つ、マスタとトランザクションを分ける、現在庫は計算して出す、締めと棚卸差異の置き場所を決める、入力を現物のそばに置く。この5つの設計は、Excelでもkintoneでも自前開発でも通用し、あとで移行するときにそのまま持っていけます。

移行を決めるときは、止まると何が止まるか、直せる人が何人いるか、要件は本当に自社独自か、5年間の総額で比べているか、の4つで判断してください。全部を一度に入れ替えず、名寄せ・入数・履歴の範囲というデータ移行の3点は今日から着手できます。外注した場合の費用感は業務システム開発を外注する費用、内製と外注の切り分けはシステム開発は内製か外注かもあわせてご覧ください。現在の拠点数・SKU数・在庫に触る人数と、いま使っている仕組みをお聞かせいただければ、自作の継続で足りるかどうかの判断と、体制を持つ場合の概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。