町工場のDXはパッケージよりAppSheetが効く理由【設計図公開】

「機能はすごいんだけど、ウチの現場には合わなかったんだよね…」

ある町工場の社長様からご相談をいただいた際、最初に出てきたのはそんなため息交じりの言葉でした。

実はこの工場様、以前に月額制（サブスク）の生産管理アプリを導入していました。しかし、高機能なパッケージソフトは、独自の工程や特殊な商習慣を持つ現場には馴染まず、結局契約したまま放置され、現場では相変わらずExcelと紙が飛び交っていたのです。

「もう、システム選びで失敗したくない」

そんな切実な想いに応えるために、私がDXコンサルタントとして提案したのが、ノーコードツール「AppSheet」を使った「自社業務に100%合わせるアプリ開発」でした。

今回は、実際に開発したアプリの設計図（データ構造）を特別に公開しながら、なぜ町工場のDXにはパッケージよりAppSheetが効くのか、その裏側をお話しします。

---

1. 町工場のDXが「パッケージソフト」で失敗する理由

なぜ、多くの町工場でシステム導入が失敗するのでしょうか？ 決して社長の決断が間違っていたわけでも、現場の意識が低いわけでもありません。最大の原因は「パッケージソフト（既製品）と、現場のリアリティとのギャップ」にあります。

• 特殊な工程に対応できない: 「割り込み加工」や「端材の管理」など、工場独自のルールがシステムに登録できない。
• 帯に短し襷に長し: 使わない機能が山ほどあるのに、本当に欲しい「日報のこの項目」がない。
• カスタマイズが高額: 独自の機能を追加しようとすると、数百万円の見積もりが出てくる。

結果として、「システムに合わせて仕事を変える」ことを現場に強いることになり、拒絶反応が起きてしまうのです。 DXの本質は、業務をシステムに合わせることではありません。「自社の強みである業務フローをそのままに、デジタルで効率化する」ことこそが、本当の町工場DXです。

---

2. 戦略：DXコンサルタントが「AppSheet」を提案した3つの根拠

そこで今回、私が提案したのがGoogleが提供するノーコードツール「AppSheet」でした。 私はプログラマーではありません。あくまでお客様の課題解決を支援する立場の人間として、以下の3つの理由から「これしかない」と確信しました。

①「低予算」でも「フルオーダーメイド」が可能

スクラッチ開発（ゼロからプログラミングで作る手法）ではコストが合いません。しかしAppSheetなら、Excel感覚でデータベースを構築でき、開発工数を劇的に削減できます。予算を抑えつつ、パッケージでは不可能だった「御社専用の仕様」を実現できます。

② 修正のスピード感（アジャイルな改善）

現場から「ここの入力、面倒だから選択式にして」と言われたら、その場ですぐに直せる。このスピード感こそが重要です。契約して終わりのパッケージとは違い、使いながら育てていくことができます。

③ 私の役割は「翻訳」

技術的な実装は弊社の技術チームが行いますが、最も重要なのは設計の前段階です。 社長が「何を実現したいか（経営視点）」と、現場が「どう使いたいか（UX視点）」をヒアリングし、それをシステム要件に翻訳して伝える。これが成功の鍵でした。

なお、こうした「コンサルタントの役割」は業種を問わず共通しています。ECサイト運営における費用相場や依頼内容については、以下の記事で詳しく解説していますので、あわせてご参照ください。

---

3. 【設計図公開】現場の声をカタチにしたデータ構造

では、実際にどのようなアプリを作ったのか？ 今回はお客様の許可をいただき、アプリの心臓部である「データ構造定義（設計図）」を公開します。

パッケージソフトのような汎用性はありません。しかし、この工場様にとっては「これ以上ない最適解」となっています。

アプリの全体像（ER図）

まずはデータの関連図をご覧ください。

こだわりのテーブル設計

特に工夫したポイントを抜粋して解説します。

■ メイン処理：生産指示（親）と工程指示（子）

1つの注文に対して、切断・加工・検査など複数の工程が発生します。これを「親子関係（IsPartOf）」で結ぶことで、現場は画面を行ったり来たりせず、スムーズに入力できます。

テーブル名	カラム名	Type	設計の狙い・コンサルメモ
生産指示(親)	生産指示ID	Text	システム管理上のキー（UNIQUEID）。
	顧客ID	Ref	顧客マスタを参照。入力ミス防止。
	製品ID	Ref	製品マスタを参照。図面データも自動で紐付け。
	QRコード	Image	現品票に印刷し、スマホで読み取るだけで工程入力画面へ。
工程指示(子)	工程指示ID	Text
	生産指示ID	Ref	親テーブルへの紐付け。ここが切れると迷子データになる。
	工程ID	Ref	切断、旋盤、フライスなどの工程を選択。
	目標サイクルタイム	Time	予実管理（予定と実績の比較）のため設置。
	実績数	Number	現場での入力項目。

TYPEについての詳細はこちらを参照ください。

■ サブ処理：発注明細での自動計算

現場担当者が最も嫌がるのが「文字入力」です。 素材を選ぶだけで、サイズや材質が自動的に表示される仕組み（Dereference機能）を採用し、「選ぶだけ」の体験を作りました。

テーブル名	カラム名	Type	設計の狙い・コンサルメモ
発注明細	素材ID	Ref	素材マスタから選択。
	サイズ	Text	[素材ID].[直径] などの計算式で、規格を自動結合して表示。
	入荷日	Date	分納管理や納期遅れチェックに使用。

4. 導入後の変化：やらされるITから、武器にするDXへ

このアプリを導入して数ヶ月。現場には大きな変化が起きました。

かつてパッケージソフトを導入した際は、埃を被っていたタブレット。 今では、油まみれの手袋をした職人さんが、休憩時間に「昨日の実績、ここ間違ってたから直しといたよ」と操作している姿があります。

• 「これなら使える」: 自分たちの業務フローそのままだから、マニュアルがいらない。
• リアルタイム化: 社長が外出先からでも、工場の稼働状況がスマホで見える。
• 自分たちの道具へ: 「ここの項目、邪魔だから消していい？」といった要望が現場から出るようになりました。これは「やらされている」のではなく「自分たちの道具」として認識し始めた証拠です。

---

5. おわりに：町工場のDX成功は「ツールの選定」で9割決まる

今回の事例で証明されたのは、「過去のシステム導入の失敗は、決して無駄ではない」ということです。 「何が合わなかったか」を明確に知っている企業こそ、次は必ず成功します。

町工場の強みは、その独自性にあります。 既製品のパッケージソフトに無理やり合わせる必要はありません。御社の強みである「独自の業務フロー」を崩さず、ITの力で効率化する。それが本当のDXです。

「ウチも昔、システムを入れて失敗したんだよな…」 そんな経験をお持ちの企業様こそ、ぜひ一度私たちにお話をお聞かせください。 技術の話は後回しで構いません。まずは御社の「現場の悩み」を、そのままぶつけてみませんか？

弊社では製造業DXで生産管理や在庫管理の業務効率を推進していくため、ノーコードでの業務アプリ開発と伴走支援を行っております。

関連記事：AppSheetで業務アプリを作成する方法と活用事例を配送予定アプリで解説