受注生産の現場は、変化が常態
多品種少量・受注生産の中小製造業では、業務プロセスそのものが常に変わる。顧客が変わり、製品が変わり、工程が変わる。以前の記事で「変化への追従速度」をDX手段の評価軸として挙げたが、この話はアプリケーション層だけの問題ではない。
→ 中小製造業のDX、どの手段が正解か ── 再現性のある内製化のレベル感
アプリケーションをいくら素早く作り変えられても、その土台となるIT環境が固定的では、結局どこかで詰まる。メールはこのサービス、ファイル共有はこのサービス、データベースはこのベンダー——それぞれが長期契約やベンダー固有の仕様で固まっていると、業務の変化に合わせてIT環境を組み替えることができない。
変化への追従は、アプリケーションだけでなく、その下のIT基盤層でも求められる。
IT環境が固定化すると何が起きるか
IT環境の固定化がもたらす問題は、使い勝手の悪さではない。変化のたびにコストが発生する構造になることにある。
たとえば、あるSaaSに業務データを蓄積していて、別のツールに切り替えたくなったとする。データのエクスポート機能が貧弱であれば、移行に多大な手間がかかる。業務ロジックをそのSaaSの上に組んでいれば、ロジックの移植も必要になる。結果として「合わないとわかっているが、変えるコストが高すぎて変えられない」という状態に陥る。
以前の記事でGoogle Workspaceについて「GASで業務ロジックを組むとロックインが完成する」と書いたが、同じ構造はどのサービスでも起きうる。問題はサービスの良し悪しではなく、環境が入れ替えられない設計になっていることにある。
設計原則は「データの再利用性」
では、入れ替えられる環境をどう設計するか。原則は一つ。データが特定のツールに閉じ込められない状態を維持すること。
具体的には：
- データは標準的な形式で手元に持つ。 CSV、JSON、あるいはPostgreSQLのようなオープンなデータベース。特定のサービスでしか読めない形式に依存しない
- 業務ロジックはデータと分離する。 ロジックをSaaSの上に組むのではなく、データを手元に持った上で、処理は自分の環境で行う
- ツールは「部品」として使う。 一つのサービスに全機能を求めるのではなく、機能ごとに最適な部品を選び、組み合わせる
この原則を守っていれば、ツールが合わなくなったときに、そのツールだけを差し替えられる。データは手元にあるから、新しいツールに繋ぎ直すだけで済む。
OSSが「部品」として優れている理由
この「入れ替えられる設計」において、OSSには構造的な強みがある。
データが手元にある。 OSSは自社のサーバーやPCで動くから、データは最初から手元にある。サービス終了やアカウント停止でデータにアクセスできなくなるリスクがない。
判断の手綱が自分にある。 商用サービスを導入するとなると、少額でも稟議が要る。展開するなら説明責任が発生する。活用されるかどうかわからない段階で会社にお金を出してもらうと、「使われなかったらどうするのか」という話になる。OSSなら、まず数人で試してみて、合わなければ静かにやめればいい。この「試して、だめなら引く」という判断を自分の裁量でできることが、結果的に導入のスピードを上げる。
浸透に時間をかけられる。 商用サービスは「契約しているのに使われていない」という組織内のプレッシャーがかかる。OSSにはそれがない。一部署で半年試して、手応えがあれば広げる。なければ静かにやめる。この「急がなくていい」という性質は、ITリテラシーにばらつきがある中小製造業の現場において、地味に大きい。
標準的な技術の上に成り立っている。 OSSの多くは、オープンな標準技術をベースにしている。PostgreSQLのデータは他のツールからも読めるし、Mattermostのデータは標準的なデータベースに格納される。特定のベンダーに閉じた仕様ではないから、ツール間の接続や将来の入れ替えがしやすい。
SaaSが合う領域もある
一方で、何もかもOSSにすればいいとは思っていない。SaaSには中小製造業にとって明確な利点がある。
構築と運用の手間がゼロに近い。 OSSは自分で構築し、自分で運用する必要がある。アップデート、バックアップ、障害対応、すべて自分持ち。情シス不在の中小企業にとって、この運用負荷は軽くない。SaaSならそれを丸ごとサービス側に任せられる。
すぐに使い始められる。 契約すれば翌日から全社で使える。OSSは構築だけで数日かかることもある。
SaaSを使う際のポイントは、データのエクスポートとAPI連携がしっかりしているサービスを選ぶこと。データをCSVやAPIで取り出せるなら、そのSaaSが合わなくなったときに別の手段に移行できる。逆に、データの取り出しが難しいサービスは、いくら便利でも長期的にはリスクになる。
つまりSaaSを使う判断基準は「便利かどうか」ではなく「データを人質に取られないかどうか」になる。
基幹業務そのものはOSSでは回らない
正直に言うと、生産管理や原価管理をそのままカバーできるOSSはほぼない。ERPNextのようなOSS ERPは存在するが、多品種少量の受注生産には合わないことが多い。
OSSが効くのは基幹業務そのものではなく、基幹業務の周辺を支えるIT環境の部分になる。情報の流れ、データの可視化、ファイルの共有、業務間のデータ連携。こうした「つなぎ」の部分をOSSで固めて、基幹業務は内製ツールや既存のやり方で回す。以前の記事で整理した三層構造でいえば、OSSは第一層（コモディティ）と第二層（小さな改善）の間を埋める「インフラ部品」として位置づけるのが現実的になる。
ハードウェアも同じ原則で選ぶ
ソフトウェアの話が中心になったが、PCやサーバーといったハードウェアの調達も同じ考え方が使える。
ハードウェアは完全にコモディティで、どこで買っても同じものが届く。違いが出るのは、購入後の面倒を誰が見るかという点だけになる。
PCであれば、メーカー直販で買って社内でキッティングするのが最もコストが低い。OSのセットアップやソフトのインストールは、ITに詳しくない社員でもマニュアルがあれば対応できる範囲のことが多い。台数が少ない中小企業では、リースの管理メリットも薄く、総コストで購入に負ける。
一方、サーバーやネットワーク機器は話が変わってくる。障害が起きたとき自力で復旧できるかどうかが判断基準になる。自力で対応できないものについては、地場のIT業者に調達と保守をセットで頼むのは合理的な選択になる。業者に払っているのはハード代ではなく、何かあったときの対応力に対する保険になる。
つまりハードの調達も、ソフトウェアと同じく 「自分たちで面倒を見られるかどうか」 で線を引けばいい。
OSSをどこで動かすか ── オンプレ・VPS・クラウドの選び方
ここまでOSSの「何を使うか」を書いてきたが、「どこで動かすか」も重要な判断になる。選択肢は大きく3つ。社内のサーバー（オンプレ）、VPS、クラウド（AWS・Azure・GCP等）になる。
結論から言えば、社内からしかアクセスしないなら、オンプレが最もシンプルで安全になる。サーバーがインターネットに出ていなければ、外部からの攻撃リスク自体が発生しない。データの主権という観点でも、物理的に手元にあるのが最も確実な形になる。社内のPCやNASの延長として、MattermostやMetabaseを動かすだけなら、これで十分機能する。
問題になるのは、外からもアクセスしたいケースになる。リモートワーク対応、拠点間の情報共有、外出先からのデータ確認。こうした要件が出てきたとき、選択肢に入るのがVPSとクラウドになる。
「クラウド」というと最先端で正しい選択に聞こえるが、AWS・Azure・GCPのようなクラウドサービスは、中小製造業には過剰なことが多い。IAM（権限管理）、VPC（仮想ネットワーク）、セキュリティグループ、従量課金の見積もり——学習コストが高く、設定を間違えるとセキュリティホールになる。そもそもこれらは大規模なシステムを柔軟にスケールさせるための仕組みで、数十人規模の会社がMattermostを1台動かすには大げさすぎる。
VPSはもっと単純で、月額固定で1台のLinuxサーバーを借りるだけの話になる。SSHで入って、ソフトを入れて、設定する。クラウドのような複雑な概念は出てこない。月額1,000〜3,000円程度で、コストも読みやすい。
ただし、VPSはインターネット上にサーバーを置くことになるので、セキュリティは自己責任になる。ファイアウォールの設定、SSH鍵の管理、OSやソフトウェアの定期的なアップデート。これを怠ると、外部から侵入される可能性がある。
整理すると、判断基準はシンプルになる：
| 条件 | 選択肢 | 理由 |
|---|---|---|
| 社内からのアクセスだけで済む | オンプレ | 最もシンプルで安全。外部リスクがゼロ |
| 外からもアクセスしたい | VPS | 安価で構成がシンプル。セキュリティは自己管理 |
| 大規模・高可用性・複数拠点統合 | クラウド | 中小製造業ではほぼ不要 |
多くの中小製造業では、まずオンプレで始めて、外部アクセスの必要が出てきたらVPSを検討する、という順番で十分だと思っている。「とりあえずクラウド」という判断は、ERPと同じで解像度が低い。何のために、どこからアクセスする必要があるのかを先に整理すれば、おのずと答えは決まる。
内製力がなければ始まらない
ここまで読んで気づいた方もいると思うが、OSSの導入には内製力が前提になる。構築、設定、運用、トラブル対応——SaaSならサービス側がやってくれることを、自分でやる必要がある。
以前の記事で整理した内製力のレベル感でいえば、OSSの導入・運用にはレベル2（設定変更・軽微な修正ができる）以上が必要になる。レベル0の会社がいきなりOSSを導入しようとしても、構築の段階で止まる。
→ 中小製造業のDX、どの手段が正解か ── 再現性のある内製化のレベル感
逆に言えば、OSSの導入は内製力を伸ばす実践の場にもなる。Mattermostを立てるだけでも、Linuxの基礎、ネットワークの設定、データベースの概念に触れることになる。そしてこの経験は、その後の内製DXの土台になる。
「止められる」から始められる
IT環境は一度作って終わりではない。業務の変化に合わせて、環境自体を組み替え続ける必要がある。商用サービスは導入にも撤退にも組織的な判断が伴うが、OSSにはそれがない。このサイクルを自分の裁量で回せることが、変化の多い受注生産の現場において、環境を最適な状態に保ち続ける力になる。
入れ替えられる部品で環境を組んでおくことが、長期的に見て最も堅実な設計になる。OSSはその「入れ替え可能な部品」として、中小製造業のIT環境に組み込む価値がある。
このシリーズの他の記事：