生産管理をExcelや自作システムで回している製造業の担当者に向けて、「いまの仕組みがいつまで持つのか」「作り直すとしたら今の資産はどうなるのか」を判断できる形で整理します。書いているのは、自作されたシステムを引き継いで調査し、作り直す側の立場です。
結論を先に伝えると、Excelや自作システムをやめるべきかどうかは、機能の不足ではなく「同時に触る人の数」「例外処理の量」「作った人が説明できるか」の3つで決まります。 機能が足りないだけなら足せばよく、この3つが崩れている場合は、足しても持ちません。
この記事でわかること
- Excel・自作システムで「まだ回る」条件と、限界に来ているサイン
- 自作の生産管理が破綻する5つの典型パターンと、それが表面化する時期
- 引き継ぐ側が最初に調べること（作り直しを頼む前に自分で確認できる項目）
- 自作した資産のうち、個別開発へ持ち越せるものと捨てるもの
- 自作の「本当の費用」の数え方
生産管理システムは自作できるのか
結論から言えば、自作できます。実際に動いている例は多数あります。
Excelとマクロ、Access、最近ではノーコードツールやPythonで、生産管理の仕組みを自社で作っている製造業は珍しくありません。現場を知っている人が作るので、パッケージより業務に合っていることもよくあります。「自作は避けるべき」という一般論は正しくありません。
問題は、作れるかどうかではなく、続けられるかどうかです。自作システムの相談を受けるとき、ほぼ全てが「作れなかった」ではなく「作った後に想定していなかったことが起きた」という形で来ます。
「まだExcelで回る」条件
次の条件に当てはまる間は、Excelや小規模な自作で十分に回ります。無理にシステムを入れる必要はありません。
| 条件 | 目安 |
|---|---|
| 同時に編集する人 | 実質1人（他の人は閲覧のみ、または時間をずらしている） |
| 管理する品目・案件の数 | 数百程度まで |
| 業務ルールの変更頻度 | 年に数回 |
| 例外処理 | 担当者が都度判断して手で直せる範囲 |
| 作った人 | 在籍していて、かつ中身を他人に説明できる |
ここに収まっているなら、システム化のコストに見合いません。入力の手間を増やすだけの仕組みを足すより、いまのExcelを整理するほうが効果があります。
限界に来ているサイン
逆に、次のうち2つ以上に当てはまる場合は、足し続けても持ちません。
- 同じ内容を2か所以上に入力している（Excelと基幹システム、Excelと紙の日報など）
- 「最新版がどれか」を人に聞かないと分からないファイルがある
- 月末に手で辻褄を合わせる作業が恒常化している
- マクロの中身を説明できる人が1人しかいない、またはもう社内にいない
- 同時に開いて上書きしてしまう事故が起きたことがある
- 過去に誰が何を変えたかが追えない（履歴が残っていない）
このうち後ろの3つは、機能を足しても解決しません。Excelというファイル形式そのものの制約だからです。
自作の生産管理が破綻する5つのパターン
引き継ぎの相談で実際に多いのは、次の5つです。それぞれ、破綻が表面化する時期が違います。
| パターン | 何が起きるか | 表面化する時期 |
|---|---|---|
| 作者の異動・退職 | 誰も直せなくなり、業務ルールの変更に追随できなくなる | 作者がいなくなった直後ではなく、次に業務が変わったとき |
| 同時編集 | 上書き事故、「昨日入れた実績が消えている」 | 使う人が3人を超えたころ |
| 例外処理の増殖 | 「この取引先だけ別シート」が積み重なり、全体の整合が取れなくなる | 運用2〜3年目 |
| データ量 | ファイルが重くなり、開くのに時間がかかる／壊れる | 品目・履歴が数千件を超えたころ |
| 正のデータが分からない | 基幹とExcelで数字が合わず、どちらを信じるか決められない | 棚卸・決算・監査のタイミング |
この表で重要なのは時期のほうです。多くの場合、破綻は「作った直後」ではなく作ってから数年後、担当者が変わったタイミングで起きます。そのとき、当時の判断の記録は残っていません。
引き継ぐ側が最初に調べること
作り直しを外部に頼む前に、自社で確認しておくと話が早い項目です。開発会社が最初の調査でやるのも、ほぼこの内容です。
- どのデータが「正」か — 同じ数字が複数の場所にあるとき、どれを信じる運用になっているか
- 誰が、いつ、何を入力しているか — 工程の順に並べる。入力していない項目があれば、それは要らない項目の可能性が高い
- マクロ・数式の作者と、変更の履歴 — 分からなければ「分からない」と記録する。これ自体が調査の結果になる
- 例外処理の一覧 — 「この取引先だけ」「この製品だけ」の分岐を書き出す。ここが見積もりを最も動かす
- 止められない処理と、その締め時間 — 月次締め、出荷指示など、止まると業務が止まるもの
4の例外処理を出せるかどうかで、見積もりの精度が変わります。 逆に言えば、ここが出せない状態で受け取った見積もりは、前提が不足しています。見積書の読み方はシステム開発の人月単価の相場と見積もりの読み方で整理しています。
いまのExcel・自作システムを引き継げるか、先に確認したい方へ
シンシアでは、稼働中のExcel・自作システムを調査し、「どこまで持ち越せるか」「作り直す範囲はどこか」を切り分ける相談を無料で承っています。ファイルを1点共有いただければ、構造から分かる範囲でお答えします。
自作した資産は、作り直しで無駄になるのか
なりません。 ただし、持ち越せるものと捨てるものがはっきり分かれます。
| 自作した資産 | 作り直しでどうなるか |
|---|---|
| 業務ルールそのもの（計算式・判定の条件） | 最も価値がある。要件定義の入力としてそのまま使える |
| 例外処理の分岐 | 価値がある。パッケージ導入時にFit/Gapの材料になる |
| 蓄積されたデータ | 移行できることが多い。ただし表記ゆれの整理が必要 |
| 画面・帳票のレイアウト | 参考程度。そのまま再現するとかえって使いにくくなることがある |
| マクロのコード | ほぼ捨てる。ただし何をしていたかは仕様として拾う |
つまり、自作した年月は「業務要件を言語化した期間」として残ります。 ゼロから要件定義を始める会社より、むしろ有利です。パッケージで足りるのか個別開発が必要なのかの判断は、パッケージと個別開発の判断基準で整理しています。
自作の「本当の費用」
自作は無料ではありません。見えている費用は「ツール代0円」ですが、実際には次が発生しています。
- 作成にかけた時間 — 作った人の人件費。本来の業務時間を使っている場合、その業務が止まっている
- 維持の時間 — 業務が変わるたびの修正、トラブル対応、問い合わせ対応
- 引き継げないリスク — 作者が抜けたときに業務が止まる確率と、そのときの損失
3つ目は金額にしづらいので、たいてい計算から漏れます。ただし実際に止まったときの損害は、開発費より大きくなることがあります。判断するときは、開発費と比べるのではなく「いま自作の維持に使っている時間 × 年数」と比べてください。内製と外注の比較はシステム開発の内製化のメリット・デメリットでも扱っています。
作り直す場合の進め方
全部を一度に置き換える必要はありません。実務では、次の順で進めるのが安全です。
- 止めても業務が壊れない範囲を1つ選ぶ — 1ライン、1製品群、1帳票
- その範囲だけ、正のデータを決める — 基幹とExcelのどちらを信じるかを確定する
- 現場が実際に入力できるか、本番相当のデータで確認する — ここで入力されない項目は落とす
- 既存の基幹システムは残したまま連携する — 全面刷新を前提にしない
既存の基幹を残したまま現場側の仕組みを足す方式は、基幹・ERPを残したまま現場システムをつなぐで具体的に説明しています。生産管理そのものの設計単位は生産管理システムを生産方式から設計する、在庫の粒度の決め方は在庫・調達管理を実在庫と合う状態にするにまとめました。
なお、生産管理に限らず一般的なExcel業務のシステム化手法（VBA・RPA・SaaS・ノーコードの選び分け）は、脱エクセルは必要か｜残す業務と移す業務の分け方で解説しています。
よくある誤解
「自作したのは失敗だった」 違います。自作されたものがあるということは、業務が言語化されているということです。要件定義の出発点としては、何も無い状態より有利です。
「作り直すなら全部を一度に」 逆です。一度に置き換えると、現場の入力負荷と移行リスクが同時に立ち上がり、検証ができなくなります。
「パッケージを入れれば解決する」 業務を標準化できるなら有利ですが、製品ごとに工程が変わる多品種少量では、標準機能に業務を合わせきれないことがあります。判断はFit/Gapで行います。
FAQ：生産管理システムの自作に関するよくある質問
生産管理システムはExcelで作れますか？
作れます。実際に動いている例は多数あります。ただし、同時に編集する人が複数いる、履歴を追う必要がある、月末に手で辻褄を合わせている、という状態になったら、Excelの形式そのものが制約になっています。
自作とパッケージ導入、どちらが安いですか？
初期費用だけを見れば自作が安く見えます。ただし自作には、作成時間・維持の時間・作者が抜けたときのリスクが含まれます。比較するときは、開発費とツール代を並べるのではなく、「いま自作の維持に使っている時間 × 年数」を含めて計算してください。
作った人がもういません。引き継げますか？
多くの場合は引き継げます。ただし調査の工数がかかります。マクロのコードを読むより、いま何が入力され、誰がその数字を見て判断しているかを確認するほうが早いことが多いです。コードが読めなくても、業務としての仕様は再構成できます。
AccessやPythonで作るのはどうですか？
Excelより同時編集やデータ量には強くなりますが、作者への依存はむしろ強くなります。社内で複数人が読み書きできる体制があるかどうかで判断してください。1人しか触れないなら、言語を変えてもリスクは同じです。
自作を続けながら、部分的にシステム化できますか？
できます。むしろ実務ではこちらが主流です。止めても業務が壊れない範囲から切り出し、既存の基幹やExcelとはデータ連携でつなぎます。
どのくらいの規模から作り直しを検討すべきですか？
品目数やファイルサイズより、同時に触る人の数と例外処理の量で判断してください。使う人が3人を超え、「この取引先だけ別扱い」が増えているなら、規模が小さくても検討の対象です。
相談するとき、何を用意すればよいですか？
いま使っているExcelを1点（項目が分かれば内容はマスキング可）、現在のシステム構成が分かるもの、そして「誰が入力し、誰が結果を見るのか」の3点です。揃っていなくても構いません。
まとめ
生産管理システムの自作は可能で、実際に動いているものは多数あります。判断すべきなのは作れるかどうかではなく、同時に触る人の数・例外処理の量・作った人が説明できるかの3点です。
機能が足りないだけなら足せば済みます。この3点が崩れているなら、足しても持ちません。そして作り直す場合でも、自作した年月は「業務要件を言語化した期間」として残ります。捨てることにはなりません。
次に読むべき記事
