受注生産の現場は、変化が常態
多品種少量・受注生産の中小製造業では、業務プロセスそのものが常に変わる。顧客が変わり、製品が変わり、工程が変わる。以前の記事で「変化への追従速度」をDX手段の評価軸として挙げたが、この話はアプリケーション層だけの問題ではない。
アプリケーションをいくら素早く作り変えられても、その土台となるIT環境が固定的では、結局どこかで詰まる。メールはこのサービス、ファイル共有はこのサービス、データベースはこのベンダー——それぞれが長期契約やベンダー固有の仕様で固まっていると、業務の変化に合わせてIT環境を組み替えることができない。
変化への追従は、アプリケーションだけでなく、その下のIT基盤層でも求められる。
IT環境が固定化すると何が起きるか
IT環境の固定化がもたらす問題は、使い勝手の悪さではない。変化のたびにコストが発生する構造になることにある。
たとえば、あるSaaSに業務データを蓄積していて、別のツールに切り替えたくなったとする。データのエクスポート機能が貧弱であれば、移行に多大な手間がかかる。業務ロジックをそのSaaSの上に組んでいれば、ロジックの移植も必要になる。結果として「合わないとわかっているが、変えるコストが高すぎて変えられない」という状態に陥る。
以前の記事でGoogle Workspaceについて「GASで業務ロジックを組むとロックインが完成する」と書いたが、同じ構造はどのサービスでも起きうる。問題はサービスの良し悪しではなく、環境が入れ替えられない設計になっていることにある。
設計原則は「データの再利用性」
では、入れ替えられる環境をどう設計するか。原則は一つ。データが特定のツールに閉じ込められない状態を維持すること。
具体的には：
- データは標準的な形式で手元に持つ。 CSV、JSON、あるいはPostgreSQLのようなオープンなデータベース。特定のサービスでしか読めない形式に依存しない
- 業務ロジックはデータと分離する。 ロジックをSaaSの上に組むのではなく、データを手元に持った上で、処理は自分の環境で行う
- ツールは「部品」として使う。 一つのサービスに全機能を求めるのではなく、機能ごとに最適な部品を選び、組み合わせる
この原則を守っていれば、ツールが合わなくなったときに、そのツールだけを差し替えられる。データは手元にあるから、新しいツールに繋ぎ直すだけで済む。
OSSが「部品」として優れている理由
この「入れ替えられる設計」において、OSSには構造的な強みがある。
データが手元にある。 OSSは自社のサーバーやPCで動くから、データは最初から手元にある。サービス終了やアカウント停止でデータにアクセスできなくなるリスクがない。
入れ替えのコストが低い。 ライセンス費用がないから、「試してみて合わなければやめる」が気軽にできる。SaaSのように年間契約の縛りや、解約時のデータ移行の壁がない。
浸透に時間をかけられる。 月額課金のサービスは「契約しているのに使われていない」というプレッシャーがかかる。OSSにはそれがない。一部署で半年試して、手応えがあれば広げる。なければ静かにやめる。この「急がなくていい」という性質は、ITリテラシーにばらつきがある中小製造業の現場において、地味に大きい。
標準的な技術の上に成り立っている。 OSSの多くは、オープンな標準技術をベースにしている。PostgreSQLのデータは他のツールからも読めるし、Mattermostのデータは標準的なデータベースに格納される。特定のベンダーに閉じた仕様ではないから、ツール間の接続や将来の入れ替えがしやすい。
SaaSが合う領域もある
一方で、何もかもOSSにすればいいとは思っていない。SaaSには中小製造業にとって明確な利点がある。
構築と運用の手間がゼロに近い。 OSSは自分で構築し、自分で運用する必要がある。アップデート、バックアップ、障害対応、すべて自分持ち。情シス不在の中小企業にとって、この運用負荷は軽くない。SaaSならそれを丸ごとサービス側に任せられる。
すぐに使い始められる。 契約すれば翌日から全社で使える。OSSは構築だけで数日かかることもある。
SaaSを使う際のポイントは、データのエクスポートとAPI連携がしっかりしているサービスを選ぶこと。データをCSVやAPIで取り出せるなら、そのSaaSが合わなくなったときに別の手段に移行できる。逆に、データの取り出しが難しいサービスは、いくら便利でも長期的にはリスクになる。
つまりSaaSを使う判断基準は「便利かどうか」ではなく「データを人質に取られないかどうか」になる。
中小製造業に刺さるOSSの具体例
では実際に、中小製造業のIT環境の「部品」として使えるOSSはどんなものがあるか。
社内コミュニケーション：Mattermost
Slackの代替として使えるチャットツール。自社サーバーで動くから、やりとりのデータは完全に手元に残る。LINEで業務連絡をしている会社が、まず情報の流れを整理する入口として使いやすい。
ファイル共有：Nextcloud
Google DriveやDropboxの代替。ファイルの保管と共有を自社サーバーで行える。以前の記事でデータの主権について書いたが、図面や見積書といった中核データをクラウドに預けることに抵抗がある会社には、具体的な選択肢になる。
データの可視化：Metabase
既存のデータベースやExcelファイルに接続して、グラフやダッシュボードを作れるBIツール。SQLが書けなくても、画面上の操作でデータの集計や可視化ができる。管理精度型の内製DXで、現場のデータを経営層に見せる場面で効く。
ワークフロー自動化：n8n
「Aのデータを取得して、加工して、Bに渡す」という業務の自動化ツール。IFTTTやZapierのOSS版と考えればいい。手作業でExcelからデータを転記しているような業務を、画面上でフローを組んで自動化できる。
タスク・案件管理：Redmine
案件ごとの進捗管理、タスクの割り振りと追跡ができる。製造業では古くから使われており、情報が豊富。Excelで案件管理表を回している会社が、次のステップとして検討しやすい。
データベース：PostgreSQL
内製でツールを作る際のデータの置き場所として。Excelの限界を超えたデータ量を扱う必要が出てきたとき、最初の選択肢になる。オープンな標準であり、上に挙げたMetabaseやn8nとも直接接続できる。
基幹業務そのものはOSSでは回らない
正直に言うと、生産管理や原価管理をそのままカバーできるOSSはほぼない。ERPNextのようなOSS ERPは存在するが、多品種少量の受注生産には合わないことが多い。
OSSが効くのは基幹業務そのものではなく、基幹業務の周辺を支えるIT環境の部分になる。情報の流れ、データの可視化、ファイルの共有、業務間のデータ連携。こうした「つなぎ」の部分をOSSで固めて、基幹業務は内製ツールや既存のやり方で回す。以前の記事で整理した三層構造でいえば、OSSは第一層（コモディティ）と第二層（小さな改善）の間を埋める「インフラ部品」として位置づけるのが現実的になる。
環境の構成図を描く
ここまでの話を整理すると、中小製造業のIT環境は次のように設計できる。
| 領域 | 手段 | 考え方 |
|---|---|---|
| 会計・給与・勤怠 | パッケージ／SaaS | コモディティ。自分で作る必要なし |
| メール | Gmail等のSaaS | 運用の手間を考えるとSaaSが合理的 |
| ファイル共有 | Nextcloud or SaaS | 中核データの主権を重視するならOSS |
| 社内チャット | Mattermost or SaaS | 情報の蓄積と検索性を重視するならOSS |
| データ可視化 | Metabase（OSS） | 手元のデータに繋いで使う |
| 業務の自動連携 | n8n（OSS） | ツール間のデータの橋渡し |
| データベース | PostgreSQL（OSS） | 内製ツールの基盤 |
| 業務の中核ツール | 内製（VBA／専用言語） | 自社の差別化に直結する領域 |
全部OSSにする必要はないし、全部SaaSにする必要もない。データの再利用性を保つという原則の下で、領域ごとに最適な部品を選ぶ。そしてどの部品も、合わなくなったら入れ替えられる状態にしておく。
内製力がなければ始まらない
ここまで読んで気づいた方もいると思うが、OSSの導入には内製力が前提になる。構築、設定、運用、トラブル対応——SaaSならサービス側がやってくれることを、自分でやる必要がある。
以前の記事で整理した内製力のレベル感でいえば、OSSの導入・運用にはレベル2（設定変更・軽微な修正ができる）以上が必要になる。レベル0の会社がいきなりOSSを導入しようとしても、構築の段階で止まる。
逆に言えば、OSSの導入は内製力を伸ばす実践の場にもなる。Mattermostを立てるだけでも、Linuxの基礎、ネットワークの設定、データベースの概念に触れることになる。そしてこの経験は、その後の内製DXの土台になる。
「止められる」から始められる
OSSの最大の利点は、高機能であることでも無料であることでもない。合わなければ止められることにある。
SaaSは契約と移行コストがある。パッケージは導入費用を回収するまで使い続けるプレッシャーがある。OSSにはそのどちらもない。試して、合わなければやめる。合えば続ける。このサイクルを低コストで回せることが、変化の多い受注生産の現場において、環境を最適な状態に保ち続ける力になる。
IT環境は一度作って終わりではない。業務の変化に合わせて、環境自体を組み替え続ける必要がある。そのとき、入れ替えられる部品で環境を組んでおくことが、長期的に見て最も堅実な設計になる。OSSはその「入れ替え可能な部品」として、中小製造業のIT環境に組み込む価値がある。