業務システムは今やWebアプリが主流──スクラッチ開発の現実解（名古屋版）

1.はじめに

社内の端末がバラバラでも、URLひとつで配布なしに使えて、更新はサーバー側の一度の配信で全員に反映される。
取引先や協力会社とも画面を共有しやすく、SaaSや会計とAPIでつながる。

こうした理由から、業務システムはWeb-first（Webを軸）が主流になりました。では、既製パッケージやノーコードではなくスクラッチ開発を選ぶ場面はどこか。名古屋の現場感で、判断と進め方をまとめます。

2. なぜ“Web-first”が現実的なのか

日々の改善スピードに、Webは合っています。

配布やインストールの手間がなく、“直して即反映”ができる。
閲覧専用から始めて、少しずつ入力や承認を足す“段階導入”にも向きます。

外部のSaaS（請求、在庫、BI）とAPI/CSVの“細い管”でつなぎ、
まずは時刻連携で安定化、必要箇所だけリアルタイム化
この順番が、コストとリスクを抑えます。

一方で、完全オフラインの重作業や、ハンディ/BLE/PLCの端末深部機能はWebだけだと苦しい場合。ここはここだけネイティブ／既存機器を噛ませ、
全体はWebアプリで運用するのが現実解です。Webシステムは連携が得意なのです。

3. スクラッチ開発を選ぶのは、どんな時か

“他で代替しにくい会社独自のやり方”に価値がある時です。

たとえば、受発注〜原価〜請求のつながり方、在庫の引当ルール、出来高と請求を写真証憑で結ぶ運用など。

データモデル・権限・帳票の骨格が会社の競争力に直結するなら、スクラッチの意味は大きい。

逆に、カレンダーやチャット、一般的な経費精算のような“横並び”領域はSaaS活用のほうが早くて安定します。

結論はシンプルで、骨格はスクラッチ、周辺はSaaSやノーコードがコスパ最適になりやすい、ということです。

4. どう作るか：MVP（最小構成）→早期運用→段階拡張

最初に決めるのは、今回で必ず解決させるゴールだけです
（例：未請求を半減、棚卸時間を半分に、小停止を30％減）。
そこからMVPの範囲をA/B/Cで仕分けます。A＝今回／B＝次期／C＝当面やらない。
重たい論点（PDF/帳票、会計連携、バーコード/IoT）は、スプリント0〜1で小さくPoC。

できる・できない・時間がかかるを先に見切っておくと、後ろのブレが消えます。

画面はV1を必要最低限のミニ版で出し、V2で体裁を整える。
この“速さ優先→磨き込み”の順が、現場には合います。

5.費用と期間の目安（レンジで捉える）

スコープと連携の重さで大きく動きます。
単機能の置き換えや一工程の改善なら、300〜700万円・2〜4ヶ月。
受発注と原価、請求までの背骨なら、800〜1,500万円・4〜8ヶ月。
在庫/WMSや会計連携まで含む全社基幹寄りは、
1,600万円超・6〜12ヶ月が一般的です。

このレンジを狭めるカギは、MVPの言語化と早期PoC、移行設計の前倒しです。予備費は10〜15%を置き、重い箇所の検証に使います。

6.設計の“芯”は3つだけ：データ・権限・ログ

データモデルは、品目・得意先・案件など“会社共通の名寄せ”を先に決め、Excelの揺れを辞書で吸収します。

権限は最小権限から。誰が何を見る・出す・直すのか、監査が通る粒度で。

ログはアプリ/インフラ/操作を“後から再現できる”だけ残す。

帳票はV1＝A4ミニ版で発行し、運用で足りない欄をV2で追加。
現状帳票の完コピ沼を避ける最短路です。

7.移行と並行運用：最後に“一気”はやらない

移行が詰まる原因の多くは、現実の揺れを最後まで見ないこと。

初月からテストデータを流す、呼び方の違いを対応表（辞書）で吸収する、
2〜4週間の並行運用を計画に入れて“使いながら直す”。

これで「最後に大量の名寄せで炎上」が避けられます。

8.次の一歩

まずは無料相談でお気軽にご相談ください