Excel・自社開発 vs パッケージ — どこで限界が来て、いつ乗り換えるか

「そろそろExcelでの管理は限界かもしれない」——そう感じていても、いつ・何に乗り換えるべきかの判断は簡単ではありません。本記事では、ExcelやAccess・自社開発での部品/図面管理が限界を迎えるラインを、人数・拠点・変更頻度といった具体的な目安で示します。そのうえで、パッケージへ移行する際のコストとリスク、見落とされがちな「自社開発の塩漬け」問題まで、中立に整理します。製造業でよく語られる「脱Excel」は、実のところ「延命・自社開発・パッケージ」という3つの選択肢の比較問題です。

1. 「乗り換えるべきか」は3つの選択肢の比較で考える

Excelでの管理に限界を感じ始めたら、どんな選択肢があるのでしょうか。大きく分けて3つあります。

①Excelを延命する

Excelのさらなる機能や、他のMicrosoftサービス（クラウドやPower Automateなど）と組み合わせることで、Excelを使い続ける方法です。

②自社開発する

社内のITリソースを駆使して、自分たち専用の課題解決システムを自前で開発する方法です。Accessなどの簡易データベースで内製ツールを作るのも、広い意味ではここに含まれます。

③パッケージ（PLM等）を導入する

自社の課題を解決してくれそうな市販のパッケージシステムを探し出し、標準機能をそのまま利用したり、一部カスタマイズしたりして導入する方法です。

ここで押さえておきたいのは、「乗り換える＝パッケージを導入する」ではない、ということです。パッケージ導入はあくまで選択肢の1つにすぎません。それぞれにメリット・デメリットがあるので、順に見ていきましょう。

2. 3つの選択肢の特徴

3つの選択肢のメリット・デメリットを整理しながら説明していきます。

①Excel（＋運用改善）を続ける

メリット：運用コストが低いです。ExcelやMicrosoftの機能拡張のためにライセンスをアップグレードしたとしても、他に比べれば低コストで済みます。ただし、Power AutomateやSharePointなど専門性の高い機能を使うとなると、専門家への依頼など追加費用の考慮が必要なこともあります。また、基本的な機能はほぼ全員が使いこなせる点も重要です。使い慣れていて直感的に作業できるので、教育に時間をかけなくても済みます。

デメリット：同時編集と共有に制限がかかる点は、どうしても限界を感じてしまうところです。ファイルの命名規則や版管理は運用でしのげる面もありますが、なかなか手間がかかるのも事実です。そして、BOMと図面、部品表と在庫といったデータ同士の「つながり」だけは、延命の工夫では埋めにくい本質的な限界として残ります（詳しくは「Excelでの部品・図面管理の限界」で解説しています）。

②自社開発する

メリット：自社の課題に完全に合わせて開発を進められるので、自由度は非常に高いです。サーバーや開発言語、開発方針など、好きに決められると言っても過言ではありません。近年ではAIを活用した「バイブコーディング」という手法も出てきたので、以前より自社開発に取り組みやすい環境になってきたとも言えます。

デメリット：いわゆる「スクラッチ開発」にあたるので、開発や保守管理のコストは自社1社持ちです。開発規模や機能の選定を間違えると、コストは膨らみ続けます。保守面でも、サーバーのアップデートやセキュリティ対策が自社対応となるので、コストだけでなく専任に近い担当者が必須になります。さらに、自社開発は担当者に依存しやすく、開発経緯の資料や運用にかかわる資料（要件定義書・仕様書・データベース定義書など）がまとめられていない、という問題も起きやすいです。担当者が在籍しているうちは表面化しにくいのですが、辞めてしまうと「誰も知らない・誰も触れない」システムになりがちです。ブラックボックス化してしまうと、トラブルが起きた際に非常に大変です。

③パッケージ（PLM/ERP等）を導入する

メリット：何社も使っているものなので、ベストプラクティスがまとまっている点はありがたいところです。もちろんベストプラクティスが自社にとっての正解とは限りませんが、導入時に迷った際などには、とりあえずベストプラクティスに沿っておけば大きな失敗は避けやすくなります。また、保守管理はベンダーが担当するので、システムの利用に専念できます。拡張性のあるパッケージであれば、ベンダーとの折衝次第でカスタマイズできる可能性もあります。

デメリット：導入コストは、利用ユーザー数や機能、カスタマイズの有無によって変動しますが、決して安くはありません。また、自社に合わせるための調整や、現場のオペレーションの見直しが必須になります。

3つの選択肢を並べて比較すると、次のようになります。

3. 「いつ」乗り換えるか — 限界を見極める具体的な目安

Excelでの管理が限界に近づいているかどうかは、感覚だけでは判断しづらいものです。ここでは、人数・拠点・変更頻度・工数という4つの軸で、判断の目安を示します。数値はあくまで目安ですが、自社の実態に当てはめる”ものさし”として使ってみてください。

同じデータを同時に編集する人数

同じデータを見る人数は、何人いても読み取り専用で開ければよいので大した問題にはなりません。ポイントとなるのは、同時に編集する人数です。目安は次のとおりです。

3人を超えてくると「作業したいときにできない」と感じ始めることが多くなり、人数が増えるごとにその機会は増えていきます。自分だけでなく他のメンバーも同じことを感じているので、社内の生産性は同時編集人数が増えるごとに確実に落ちています。同時編集者が5人に達したら乗り換えを真剣に検討し、10人に達したら、いつでも乗り換えを実行できる体制を目指すのが一つの方法でしょう。

拠点の数

複数拠点になった時点で限界を迎えることは珍しくありません。目安としては、2拠点になった時点で兆候が現れ始め、3拠点以上、あるいは海外拠点を持つ段階なら、システム化を真剣に検討してよいでしょう。特に海外拠点が増えると、時差や言語、商習慣も異なるので、Excel管理以外の限界——つまり人材マネジメントの限界——にも同時に直面し、余計に限界を感じやすくなります。色使いや情報のまとめ方など、自分の知っているものと異質のファイルが送られてくると、「自由で誰もが使いやすい」というExcelのメリットが、かえってデメリットに感じられることもあるでしょう。複数拠点になると直接会うことも難しくなり、電話やメール、社内チャットでのやりとりが中心になります。共有しても適切に使われなかったり、共有してほしいものが共有されなかったりといった問題にも、頭を悩ませることになります。

設計変更などの変更頻度

同じ作業でも、件数が増えれば非効率を感じるポイントが増え、ストレスにつながります。たとえば設計変更という作業で考えると、目安は次のとおりです。

もちろん、単純な件数だけでなく、1件の変更で何か所修正する必要があるかによっても作業負荷は変わります。検討や周知という業務もセットなので、月に10件以上になってくると、徐々にしんどさが出てくるでしょう。

「作業のための作業」の工数割合

作業には、価値を生む重要な作業と、そのための準備作業があります。後者は付加価値を生まないのでできるだけ短くしたいところですが、BOM・図面・在庫を人手で転記するなど、IT環境やITリテラシーに応じて一定の割合で発生してしまいます。目安は次のとおりです。

「作業のための作業」は単純な転記だけでなく、検討打ち合わせのための資料作りや日程調整など、気を使うものも含まれます。これらの工数が増えると、気を使う場面が増えたり、重要な作業に当てられる時間が減ったりして、ストレスを感じやすくなります。

なお、上記の数値はあくまで目安です。自社の実態に当てはめて判断してください。

4. 乗り換えの「コストとリスク」を見落とさない

乗り換えを決断したからといって、課題が確実に解決するわけではありません。あくまでもスタートラインに立ったにすぎません。その先にどのような現実が待っているかを説明します。

システムコストだけでなく、移行・教育コストがかかる

要件定義やシステム構築に費用がかかるのは、イメージしやすいでしょう。一方で、既存の紙やExcelのデータをどうやってシステムに移行するか、実際に現場に使ってもらうための教育はどうするのか、といった「使い始めて現場を回すためのコスト」は忘れられがちです。

特に自社開発では塩漬けリスクが高い

どんなシステムを入れても、当初の理想どおりに稼働するとは限りません。「課題だと思っていたものが実は根本的な課題ではなかった」という構造的な原因もたまにありますが、往々にしてあるのは「思っていたものと違った」というフワッとした原因です。これは特に自社開発で起こりがちです。本来は一度作ってからPDCAサイクルを回してブラッシュアップしなければならないのに、途中で心が折れて開発が続かなくなります。属人化したものは新たな人が引き継ごうにも引き継げないので、結局、塩漬けになってしまいます。もちろんパッケージでも起こり得ますが、ベストプラクティスが詰まっているぶん、塩漬けになる可能性は低くなります。

パッケージの”合わせ”コストは痛みを伴う

パッケージの場合、自社専用ではないので、現場をパッケージに合わせる必要があります。基本的には効率化と標準化が進むので、属人化業務が多かったメンバーや、「作業のための作業」を担ってくれていたメンバーの役割が減ります。会社としては給与を払っている以上、減ったぶんの業務を他で埋めることになり、配置転換など、本人が望まないであろう現実を提示しなければならないこともあります。お金というコストには表れませんが、精神的な痛みを伴います。

このように、乗り換えはバラ色ではありません。いかにこれらのリスクや痛みを抑えるかが、乗り換えのポイントと言っても過言ではありません。そのためにも、スモールスタートでリスクを抑えながら進めるのが現実的です（費用や進め方は「PLM導入の費用感とスモールスタート」「PLM導入でよくある失敗パターンと進め方」で詳しく解説しています）。

5. まとめ：乗り換えは「手段の選択」

乗り換えの選択肢として、Excelの延命・自社開発・パッケージ導入の3択と、それぞれのリスクを説明してきました。どれか1つが唯一の正解というわけではなく、置かれた状況次第で、取るべき手段は異なります。「脱Excel」はそれ自体が目的ではなく、あくまで手段の選択です。目安となる人数・拠点・変更頻度・工数を示したので、自社の状況に当てはめて判断する材料にしてください。そして「乗り換える」と決めたら、次は「どのシステムか」を見極める段階です。

• 乗り換え後、どのシステムが必要かを課題から逆引きする →「製造業システムの選び方」
• 仕組み（PLM）の詳細 →「PLMとは」
• Excel管理の限界の実感 →「Excelでの部品・図面管理の限界」