テックメモ

DXの入口として勧められるGoogle Workspace

中小製造業のDXを検討していると、「まずはGoogle Workspaceを導入しましょう」という提案に出会うことが多い。メール、カレンダー、ファイル共有、表計算がすべて一つのサービスで揃い、月額数百円から始められる。確かに入口としてはわかりやすい。

しかし自分の立場から言えば、中小製造業がGoogle Workspaceに「全部乗せ」する必要はないと思っている。便利な機能を部分的に借りつつ、データ本体は自分の手元に置く。この使い分けを意識するだけで、長期的なリスクとコストの構造がまったく変わってくる。

実際に使われる機能は限られている

Google Workspaceは「全部入り」のサービスだが、中小製造業の現場で日常的に使われるのは、だいたい次の三つに絞られる。

• Gmail： メールの送受信と、迷惑メールフィルタ
• Googleカレンダー： スケジュール共有
• Googleドライブ： ファイルの保管と共有

Google Meet、Google Chat、Google Sites、Currents——こうした機能は契約に含まれていても、中小製造業ではほとんど使われない。全部入りの料金を払って、実際に使うのは三つだけ。それなら、その三つだけを別の手段で手当てしたほうが合理的ではないか、という発想が出てくる。

見落とされる長期コスト

Google Workspace Business Starterは1ユーザー月額680円。安く感じるが、これは積み上がる。

社員20人の会社なら、680円 × 20人 × 12ヶ月 = 年間163,200円。5年で約80万円、10年で160万円を超える。これは「全員がメールとカレンダーを使っているだけ」の費用になる。

コスト差が決定的というわけではないが、「クラウドの月額課金は永遠に続く」という点は意識しておく必要がある。

本当のリスクはコストではない

コストよりも深刻なのは、データの主権の問題になる。

Google Workspaceにデータを蓄積するということは、自社の業務データをGoogleに預けるということ。「預ける」という表現は上品すぎるかもしれない。実態としては、Googleの規約とインフラの上にデータが存在し、Googleのさじ加減一つでアクセスできなくなるリスクを負うということになる。

実際に起きている事象として：

• アカウント停止のリスク。 Googleの規約違反と判定されると、アカウントが停止される。法人アカウントでも例外ではない。停止されると、メール、ドライブ、カレンダーのすべてに一切アクセスできなくなる
• 復旧の困難さ。 問い合わせ窓口はbot対応が中心で、人間の担当者に辿り着くまで時間がかかる。中小企業には専任の法務もいない。停止期間中、業務は止まる
• 料金改定の一方的な通告。 Googleは過去に何度も料金を引き上げている。ストレージの無料枠の縮小やAPIの仕様変更も、利用者への事前相談なく行われる

ローカルにデータがあれば、HDDが壊れてもRAIDやNASのバックアップから自分の意思で復旧できる。しかしクラウドのアカウントが停止された場合、自分では何もできない。この非対称性が最大のリスクになる。

段階的にロックインされる構造

Google Workspaceの厄介な点は、便利に使えば使うほど抜け出せなくなる構造にある。

最初はメールとカレンダーだけ使う。この段階なら乗り換えは簡単。次にGoogleドライブにファイルを蓄積し始める。これもまだ頑張ればデータを移行できる。

問題はその次。Googleスプレッドシートに業務ロジックを載せ始めると、状況が変わる。関数やGoogle Apps Script（GAS）で集計処理を組み、Google Formsで入力を受け付け、GASで通知を飛ばす——こうなると、業務フロー全体がGoogle前提で構築される。

この段階で「やっぱりローカルに戻そう」と思っても、データはエクスポートできるが、業務ロジックはエクスポートできない。GASで書いた処理はGoogle環境でしか動かない。業務フローを一から組み直す必要がある。つまり、移行コストが残留コストを上回り、事実上のロックインが完了する。

GASが便利なのは認める

一方で、Google Apps Script（GAS）には確かに便利な部分がある。

環境構築がゼロ。 VBAはExcelのバージョン差、マクロのセキュリティ設定、32bit/64bitの違いなど、環境面の罠がある。GASはブラウザだけで動く。情シスがいない会社では、この差は地味に大きい。

トリガー（定時実行）が無料で使える。 「毎朝8時にシートを集計してメールを送信する」がコード数行で実現できる。VBAで同じことをやるには、タスクスケジューラの設定とPCの常時起動が必要になる。

ファイルの同時編集ができる。 VBAのExcelファイルで「誰かが開いているから編集できない」という問題が起きない。

これらは実際に現場で効く利点であり、否定するつもりはない。

ただし、スプレッドシートでの大量データ運用は危うい

GASとスプレッドシートで数万行のデータを運用している会社もある。動いているからといって、それが適切かどうかは別の話になる。

• スプレッドシートの上限は1,000万セルだが、実用上は数万行あたりから体感が重くなる
• GASの実行時間制限は6分。データ量が増えると、この制限に引っかかる場面が出てくる
• 関数の再計算がシート全体に走るため、データ量に比例して動作が遅くなる

「動いているから大丈夫」と「安定して運用できている」の間にはギャップがある。そしてデータ量は基本的に増え続けるから、今は問題なくても数年後に限界を迎えるリスクがある。

併用という現実解

自分が考える現実的な選択肢は、GWSに全部乗せるのでも、完全に排除するのでもなく、機能だけ借りてデータは手元に持つ併用になる。

具体的には、こういう使い分けを提案したい。

ポイントは最後の行。データの蓄積と業務ロジックはローカルに置く。GWSの便利な機能——Gmailの迷惑メールフィルタ、カレンダー共有、GASのトリガー——は「機能」として借りるが、自社の業務データそのものはGoogleに預けない。

GASのトリガーが便利だからといって、処理するデータ本体までスプレッドシートに置く必要はない。トリガーで起動してローカルのデータを処理する、あるいはトリガーで通知だけ飛ばしてデータ処理はローカルで行う、といった分離は十分に可能になる。

データの置き場所を意識的に決める

結局のところ、重要なのは何をどこに置くかを意識的に決めることだと思っている。

外に預けていいもの： メールのやりとり、スケジュール、一般的な社内連絡。これらは最悪失っても業務が止まるわけではない。

手元に持つべきもの： 見積データ、受注履歴、原価情報、顧客情報、図面。これらは自社の業務の根幹であり、消失したら事業が止まる。アカウント停止や規約変更で突然アクセスできなくなるリスクに晒すべきではない。

この線引きができるかどうかが、Google Workspaceを「道具として使う」か「依存する」かの分かれ目になる。

道具は「借り物」か「持ち物」か

クラウドサービスは本質的に「借り物」になる。便利だが、貸主の都合で条件が変わる。料金が上がる、仕様が変わる、最悪の場合はアクセスを止められる。

ローカルの環境は「持ち物」になる。メンテナンスは自分でやる必要があるが、誰かの都合で突然使えなくなることはない。

中小製造業のDXにおいて、クラウドの便利さを活用すること自体は正しい。ただし、自社の業務データという最も重要な資産を「借り物」の上に全部載せるのは、長期的に見てリスクが高い。

Google Workspaceを使うなら、機能だけ借りる。データは自分で持つ。この原則を意識するだけで、クラウドの便利さを享受しつつ、データの主権は手放さないという両立が可能になる。

全部Excel VBAでいいのか

内製DXの話をすると、「結局どの道具で作ればいいのか」という問いにぶつかる。

自分の結論から言えば、中小製造業のデータ加工業務の大半はExcel VBAで回せる。以前の記事でも書いたが、シートの役割を分離してデータシートとUIシートを分け、VBAで制御すれば、受注管理や進捗管理、負荷の可視化まで十分に対応できる。

しかし、全部Excel VBAでいいかと聞かれたら、それは違うと思っている。自分自身、業務の中核になるツールはC#などで作っている。Excelでも同じことはできるが、あえて別の手段を選んでいる理由がある。

ツールの規模と「育て続ける必要性」

Excel VBAと専用の開発言語の差は、小さなツールではほとんど見えない。

たとえば、受注一覧から納期別に件数を集計するツール。こういう一瞬で全体を理解できる規模のものなら、Excel VBAで何の問題もない。壊れたら作り直せるし、引き継いだ人もコードを見ればすぐわかる。

差が出てくるのは、ツールが育ってきたとき。業務に合わせて機能を追加し、ロジックが増え、複数の業務をまたぐようになったとき、Excel VBAには構造的なしんどさが出てくる。

Excel VBAで大きくなると何が起きるか

開発者の好みの問題ではなく、構造的な制約がある。

コードが本番環境と一体化している。 VBAのコードはExcelファイルの中に埋まっている。コードを変更するということは、本番で使っているファイルを直接いじるということ。壊したら本番が止まる。だから怖くて触れなくなり、ツールが凍結する。

変更履歴が残らない。 いつ、誰が、何を変えたかを追跡する手段がない。「先週まで動いていたのに」となったとき、戻す方法がない。

構造化に限界がある。 モジュール分割はできるが、大きなロジックを整理するための仕組みが乏しい。コードの見通しが悪くなり、一部を変えたら別の場所が壊れる。

これらは小さなツールでは問題にならない。しかしツールが育って複雑になると、内製DXの最大の強みであるはずの「変化への追従速度」が、VBAの制約によって失われていく。改善したいのに改善できない、というのは本末転倒になる。

専用言語が解決すること

C#やPythonのような専用の開発言語を使うと、この問題が構造的に解消される。

開発環境と本番が分離している。 コードを変更して、テストして、問題なければ差し替える。本番を直接いじる必要がない。

変更履歴が残る。 Gitのようなバージョン管理ツールが使える。いつでも前の状態に戻せる。

保守性が高い。 コードの構造化、テスト、デバッグのための道具が揃っている。引き継いだ人がコードを読みやすい。

要するに、専用言語を使う理由は高度なことがしたいからではなく、ツールを継続的に育て続けられる環境を確保するためになる。

判断基準は「業務の戦略的重要度」

では、どこにExcel VBAを使い、どこに専用言語を使うか。その判断基準は、開発の規模だけではなく、その業務が自社にとってどれだけ重要かで決めるのがいいと思っている。

ここで、内製DXにおける道具選びを三つの層に整理してみる。

第一層：コモディティ業務 → 専用ソフト

会計、給与、勤怠、販売管理など。業種を問わず共通する業務には、安価で安定した専用ソフトがある。ここは自分で作る必要がない。

第二層：小さな改善・業務効率化 → Excel VBA

帳票の自動生成、データの集計、ちょっとした入力支援など。一瞬で理解できる規模のツールなら、Excel VBAで十分。作り直しも簡単だし、社内の「Excelに強い人」が対応できる。中小製造業の内製DXで作るツールの大半は、この層に収まる。

第三層：差別化の源泉となる中核業務 → 専用言語

自社の競争力に直結する業務プロセス。受注から出荷までのデータの流れ、独自の原価管理、顧客ごとの仕様管理など。ここは業務の変化に合わせて継続的に改善し続ける必要がある。育て続けるツールだからこそ、保守性と改善のしやすさが求められる。

「育てるかどうか」で線を引く

三つの層を分けるもう一つの見方として、そのツールを育て続ける必要があるかどうかという基準がある。

作って終わりのツールなら、Excel VBAで十分。動いているならそれでいい。壊れたら作り直すか、そのとき改めて考えればいい。

一方、業務の変化に合わせて改善し続けるツールなら、改善しやすい環境で作る必要がある。コードを安全に変更でき、履歴が残り、壊しても戻せる環境。これは道具の好みではなく、継続的な改善を可能にするための条件になる。

そして「育て続ける必要があるかどうか」は、その業務が自社の差別化にどれだけ関わっているかで判断できる。差別化の源泉である業務は、市場や顧客の変化に合わせて常にプロセスが変わる。だからツールも変わり続ける必要がある。

大半はExcelでいい、だから迷わなくていい

この三層の整理で伝えたいのは、中小製造業の内製DXは大半が第二層で回るということ。

「Excelでいいのか、もっとちゃんとしたものを作るべきか」と迷う場面は多いと思うが、迷うくらいならExcelで始めていい。一瞬で理解できる規模のツールを、必要なところから小さく作っていく。それで十分に効果は出る。

専用言語の出番は、ツールが育ってきて「これはもう簡単には作り直せない」「変更するのが怖い」と感じたとき。そのときが、第二層から第三層への移行を考えるタイミングになる。

最初から第三層を目指す必要はない。Excelで始めて、必要に応じてステップアップすればいい。その段階的なアプローチこそが、中小製造業の内製DXに最も合ったやり方だと思っている。

納期回答は誰がやっているか

多品種少量・受注生産の中小製造業では、納期回答はだいたい工場長かベテランのリーダーが担っている。顧客から「いつできる？」と聞かれたら、頭の中で今の仕掛りと先の受注を思い浮かべて、「3週間くらいですかね」と答える。

継続取引の顧客なら「○月○日までに欲しい」と納期指定で注文が来ることもあるが、その場合でも「受けられるかどうか」の判断は同じ人の頭の中で行われている。

この判断が間違っていても、すぐにはわからない。保守的すぎる回答で受注を逃しても、それは見えない機会損失になる。楽観的すぎる回答で受けてしまえば、現場が残業や外注で帳尻を合わせることになり、利益が飛ぶ。

経営インパクトが大きいのに、仕組み化されていない

考えてみると、納期回答は中小製造業における最も経営インパクトの大きい判断の一つになる。

受注するかしないか、いつ届けると約束するか。この判断が売上と利益率の両方を左右している。受けすぎれば現場が破綻し、断りすぎれば売上が立たない。

にもかかわらず、この判断を支える仕組みを持っている中小製造業はほとんど見たことがない。根拠は特定の人の記憶と経験。その人が休んだり辞めたりしたら、誰も精度の高い納期回答ができなくなる。

原因は「負荷が見えていない」こと

なぜ仕組み化されていないかというと、工場の負荷状態が可視化されていないからになる。

受注データは何かしらの形で記録されている。Excelでも、販売管理ソフトでも、受注伝票でも、品名・数量・納期は残っているはず。しかしそのデータから「来月の第2週、うちの工場はどのくらい埋まっているか」が見えるかというと、見えていない会社がほとんどだと思う。

データはあるのに、判断に使える形になっていない。これが問題の正体になる。

負荷の見える化は、簡単なExcelで始められる

大掛かりな仕組みは要らない。受注データを一覧にして、納期から逆算して週単位で並べるだけで、負荷の濃淡は見えてくる。

たとえば、受注一覧に納期が入っていれば、「納期が来月第2週の受注がこれだけある」という集計はExcelで簡単にできる。それだけで、今まで頭の中にしかなかった情報が目に見える形になる。

精度はざっくりでいい。今の比較対象がゼロ——つまりベテランの記憶だけ——なのだから、多少粗くても可視化されているだけで判断の質は大きく変わる。

「来月の第2週、すでに5件入っている」という情報があるだけで、新しい引合いに対して「この週は厳しいので翌週でどうですか」と根拠を持って答えられる。

追加で必要な入力は、最大でも1項目

ここまでは受注データの納期を並べるだけだが、もう一歩進めて負荷の「量」を積みたくなる。件数だけではなく、どのくらいの生産ボリュームがあるかを知りたい。

ここで生産スケジューラーを入れようとすると、製品別の標準時間マスタ、工順マスタ、工程別のキャパシティ設定……と、使い始める前に膨大なマスタ整備が必要になる。多品種少量の製品ごとにこれを整備するのは、現実的ではないことが多い。

しかし負荷のざっくりした可視化が目的なら、そこまでの精度は要らない。

受注金額が使えるケース。 受注金額と生産負荷がある程度相関する場合は、金額をそのまま負荷の代理指標にできる。受注データには金額が必ずあるから、追加入力はゼロ。今あるデータだけで、週ごとの負荷を金額ベースで山積みできる。

金額と負荷が相関しないケース。 材料費の比率が高い製品と加工費の比率が高い製品が混在するような場合、金額だけでは生産負荷を反映できない。この場合は、受注時に「工数ランク」のようなものを一つだけ登録してもらう。たとえばS・M・Lの3段階でもいい。精密な工数見積もりではなく、「この案件は重い・普通・軽い」という粒度で十分になる。

どちらのケースでも、追加で必要な入力は最大1項目。それだけで負荷の山積みと溢れの検知ができるようになる。

作り込む価値がある仕組み

ざっくりExcelで始められると書いたが、だからといってずっとざっくりのままでいいわけではない。納期回答は経営インパクトが大きい判断だからこそ、ある程度作り込む価値がある。

作り込むといっても、生産スケジューラーのような大掛かりなシステムを指しているわけではない。Excelの上で、受注データから負荷を自動計算し、キャパシティの上限を超えている週を警告するような仕組みを作る。受注が追加されるたびに負荷の山が更新され、溢れが一目でわかる状態にする。

過去の実績が溜まってくれば、製品の種類ごとに実績工数の傾向が見えてくる。最初はS・M・Lの3段階だったものが、もう少し精度の高い数字に置き換わっていく。仕組みを使いながら精度を上げていけるのは、内製ならではの強みになる。

生産スケジューラーとの違い

生産スケジューラーは、工程単位で詳細な計画を立てるツール。どの機械にいつどの作業を割り当てるかを最適化するのが目的になる。

ここで提案しているのは、それとはまったく違うレイヤーの話。受注データから週単位の負荷の塊を積み上げて、溢れているかどうかを見るだけ。工程の詳細な割り当ては扱わない。

これは以前の記事で書いたポイントスケジューリングの考え方と同じで、全工程を管理しようとするのではなく、経営判断に必要なポイントだけを押さえる。納期回答に必要なのは「この週は空いているか埋まっているか」であって、「火曜日の午後にA旋盤が空いているか」ではない。

まとめ：納期回答を属人化から解放する

納期回答の仕組み化は、こう進める。

1. 受注データを一覧にする。 これは多くの会社ですでにあるはず
2. 納期から逆算して、週単位で負荷を並べる。 Excelで十分
3. 負荷の量を積む指標を決める。 受注金額か、ダメなら工数ランク1項目を追加
4. キャパの上限ラインを引いて、溢れを可視化する
5. 実績を蓄積して、精度を上げていく

生産スケジューラーも、ERPの生産管理モジュールも要らない。受注データと1項目あれば、納期回答を特定の人の記憶から解放できる。

最初はざっくりでいい。ざっくりでも、ゼロよりはるかにましだから。そこから使いながら育てていくのが、中小製造業の内製DXらしいやり方だと思っている。

ERPと聞いて何を思い浮かべるか

「そろそろERPを入れたほうがいいですよ」。中小製造業の経営者なら、ベンダーやコンサルからこう言われた経験があるかもしれない。

ERPと聞くと、受注から生産、出荷、会計まで、すべてが一つのシステムでつながる姿を想像する。バラバラだったExcelや紙の業務が統合されて、経営の見える化が実現する——そういうイメージだろう。

しかし、実際にERPを導入した中小製造業で、そのイメージ通りに運用できている会社がどれだけあるか。自分が見てきた現場では、かなり少ない。

ERPの「主戦場」はどこか

ERPという言葉は守備範囲が広すぎて、何を指しているのかが曖昧になりがちになる。機能を分解してみると、ERPの主戦場は明確にある。

• 販売管理： 受注・売上・請求
• 購買管理： 発注・仕入
• 在庫管理： 入出庫・棚卸
• 会計連携： 上記のデータを会計に流す

これらがERPの中核機能であり、最も成熟している部分になる。ERPが「基幹システム」と呼ばれる理由は、この商流と金流のデータを一元管理できるところにある。

生産管理モジュールを持つERPもあるが、ここが多品種少量・受注生産の中小製造業にとっては落とし穴になりやすい。

生産管理はERPの得意領域ではない

ERPの生産管理モジュールは、基本的に標準的なBOM（部品表）と工順を前提としている。同じ製品を繰り返し作る量産型の製造業には合う。

しかし多品種少量・受注生産の現場では、製品ごとにBOMが違い、工程の順序も変わり、段取りの判断も毎回異なる。標準化しきれない部分が多すぎて、ERPの生産管理モジュールに業務を合わせようとすると、カスタマイズ費用が膨らむか、現場が入力負荷に耐えられなくなるか、どちらかになりやすい。

結果として、よく見る光景はこうなる。

ERPの受発注・在庫モジュールは使っているが、生産管理は結局Excelで回している。

これはERPが悪いわけではない。ERPの得意領域と、自社が本当に困っている領域がずれているだけになる。

「ERP」で一括りにするから判断を間違える

問題の根っこは、「ERP」という一語の解像度が低すぎることにあると思っている。

経営者が「うちもERPを入れるべきか」と考えるとき、頭の中では「業務全体が一つのシステムでつながる」というイメージが先行する。しかし実態としてERPが確実にカバーするのは受発注・在庫・会計の統合であって、多品種少量の生産管理はそもそも守備範囲の外にあることが多い。

この解像度のまま導入を決めると、こうなる。

• ERPの価格で、実質的には販売管理ソフトを買っている
• 本当に困っていた生産の流れは何も変わっていない
• 「思っていたのと違う」が、導入後に初めてわかる

ベンダーが嘘をついているわけではない。ERPには生産管理モジュールもあるし、カスタマイズすれば対応できると言われればその通り。ただ、その「カスタマイズ」のコストと、自社の業務に本当に合うかどうかは、別の話になる。

まず課題を切り分ける

ERPを検討する前に、自社が困っている課題を二つに切り分けることを勧めたい。

1. 商流・金流のデータ管理（受発注・在庫・会計）

ここは定型的な業務で、業種を問わず共通する部分が大きい。いわゆるコモディティ業務になる。

2. 製造プロセスのデータの流れ（見積→手配→工程→進捗→出荷→原価）

ここは自社の業務プロセスに強く依存する部分で、製品も工程も会社ごとに違う。

この二つは性質が違うのに、「ERP」という一語で両方を解決しようとするから噛み合わなくなる。

コモディティ業務は専用ソフトで十分

受発注・在庫・会計の管理は、中小製造業向けの安価な専用ソフトで十分に回せる。販売管理ソフトと会計ソフトを連携させれば、ERPの中核機能と同等のことが、はるかに低いコストで実現できる。

この領域にERPの価格を払う必要があるかは、冷静に考えてみる価値がある。

製造プロセスは内製の小さなツール群で回す

では、本当に困っている製造プロセスのデータの流れはどうするか。ここは自社の業務に合わせた仕組みを、小さく内製するのが現実的だと考えている。

狙うのは、データが一回の入力で下流に流れる構造。

受注の段階でデータを確定させ、そこから手配・工程・進捗・出荷へとデータが流れていく。人間がやるのは確認と修正だけ。二重入力をなくすことが、最も効果の大きい改善になる。

大掛かりなシステムは要らない。Excelをベースに、シートの役割を分離し、VBAで制御するだけでも、この流れは作れる。以前の記事で書いた「データシートをDBのように扱い、UIシートと分離する」設計がそのまま使える。

ポイントは、最初から全工程を一気に作ろうとしないこと。まずは最もデータの二重入力が多い部分、たとえば受注と手配の間をつなぐところから始めて、うまくいったら次の工程へ広げていく。

ERPが合う会社、合わない会社

ERPを否定したいわけではない。ERPが合う会社は確実にある。

• 拠点が複数あり、リアルタイムでデータを共有する必要がある
• 製品の種類が比較的限定されていて、BOMや工順が標準化できる
• 管理部門に、システムを運用・活用できる人材がいる

こうした条件が揃っていれば、ERPの統合力は大きな武器になる。

一方、多品種少量・受注生産で、拠点も一つか二つ、製品ごとに工程が変わるような中小製造業であれば、ERPの恩恵を受けにくい構造にある。その場合は、コモディティ業務を安価な専用ソフトに任せ、製造プロセスの部分は自社に合った小さなツールを内製で作るほうが、コストも導入の速さも、変化への対応力も上回ることが多い。

「ERP」の解像度を上げることから始める

「うちもERPを入れるべきか」という問いに対して、自分の答えは「その前に、ERPという言葉の解像度を上げましょう」になる。

自社が本当に困っているのは、受発注・在庫の管理なのか、製造プロセスのデータの流れなのか。前者ならERPでなくても安い専用ソフトで解決できる。後者ならERPでも解決しにくいことが多く、内製のほうが合う可能性がある。

ERPという一語に惑わされず、課題を分解して、それぞれに合った手段を選ぶ。地味だが、これが中小製造業のシステム投資で最も失敗しにくいアプローチだと思っている。

誤解される前に言っておきたいこと

「Excelで十分」と言うと、思考停止に聞こえるかもしれない。DXの文脈では「脱Excel」が合言葉のようになっていて、Excelを肯定する発言は時代遅れに映る。

自分は中小製造業で内製DXを推進してきた立場で、業務に合わせてWebアプリやデータベースを使ったシステムも作ってきた。その経験を踏まえて思うのは、多品種少量・受注生産の中小製造業において、データを加工する業務プロセスはExcelでも十分に回せるということ。ただし、使い方を変える必要がある。

対象を絞る

まず前提として、すべてをExcelでやれと言っているわけではない。

• 会計・給与・勤怠などのコモディティ業務 → 安価で安定した専用ソフトがある。それを使えばいい
• CAD/CAM・ロボット制御など → 専門ソフトの領域。Excelの出番ではない

Excelでも回せると言っているのは、それ以外のデータを加工する業務プロセス。受注管理、見積、工程の進捗把握、原価集計、在庫管理——こうした、自社の業務プロセスにフィットさせる必要がある領域の話になる。

そしてこの領域こそが、外注やパッケージでは対応しきれず、かといって本格的なシステム開発に踏み切るほどでもない、中小製造業が最も悩むゾーンだと思う。

「壊れるExcel」と「回るExcel」は別物

世の中で問題視されているExcel運用は、だいたいこういう状態だろう。

• 一つのシートに何でも詰め込んでいる
• 誰かが数式を壊すと全体が崩れる
• ファイルがコピーされて、どれが最新かわからない
• 作った人にしか構造がわからない

これは確かに問題だが、Excelという道具の問題ではなく、使い方の問題になる。包丁で怪我をしたからといって、包丁が悪い道具だとは言わない。

「脱Excel」論の多くは、この壊れた状態のExcelを前提にしている。壊れた使い方を直せばいいのに、道具ごと捨てて新しいシステムを入れようとする。そして新しいシステムが現場に合わず、結局Excelに戻る——という話は、製造業では珍しくない。

使い方を変える：シートの役割を分ける

自分がExcelで業務の仕組みを作るとき、最も意識しているのはシートの役割を分離することになる。

• データシート： マスタや実績データを格納する。直接手で編集しない前提で運用する
• UIシート： ユーザーが入力・操作する画面
• 出力シート： 帳票や集計結果を表示する

データシートはデータベースのテーブルと同じ扱い。ここにデータが蓄積され、VBAを通じて読み書きする。ユーザーはUIシートだけを触り、データシートには直接触れない。

これだけで、先ほどの「壊れるExcel」の問題はほぼ消える。データと画面が分かれているから、誰かが数式を壊してデータが飛ぶことがない。どのシートが何の役割かが明確だから、構造もわかりやすくなる。

なぜWebアプリではなくExcelなのか

Webアプリを作ればいいじゃないかという意見もあるだろう。自分もケースによってはそちらを選ぶこともある。それでも多くの場面でExcelを選んできた理由がある。

UIを作るコストがゼロ。 Webアプリを作ると、画面設計・レイアウト調整・レスポンシブ対応と、UI周りだけで相当な工数がかかる。Excelなら、セルの配置がそのままUIになる。

教育コストがゼロ。 全員がすでに使い方を知っている。新しいシステムを導入すると必ず発生する「操作方法の説明会」が要らない。

出力がそのまま帳票になる。 製造業では紙の帳票がまだ必要な場面が多い。Webアプリだと印刷用のレイアウトを別途作る必要があるが、Excelならそのまま印刷できる。

現場が自分で微調整できる。 「この列をもう少し広くしたい」「ここに項目を追加したい」という要望に、現場が自力で対応できる部分がある。開発者に頼まなくていい。

つまりExcelを選ぶ理由は、技術的な優位性ではなく導入と定着のしやすさにある。中小製造業のDXで最も難しいのは、作ることではなく使ってもらうこと。その壁が低い選択肢として、Excelはもっと見直されていいと思う。

よくある批判に答える

「データ量が増えたら重くなるのでは？」

今のPCスペックなら、中小製造業のデータ量で重くなることはほぼない。数万件のデータシートを頻繁に参照する場合は工夫が必要で、Range データを配列に読み込んでオンメモリで検索するといった対処をすれば十分に速く動く。

「作った人しかメンテできないのでは？」

これはExcel固有の問題ではない。Pythonで作ろうがWebアプリで作ろうが、作った人が辞めたらメンテできなくなるリスクは同じ。なのにExcelだけが「属人化するからダメ」と批判されるのは公平ではない。属人化は道具の問題ではなく、組織の問題になる。

「複数人で同時に使えないのでは？」

常時複数人が同時に書き込む必要がある場合は、外部データベースをバックエンドに置くべきだと思う。ただしその場合でも、UIとしてのExcelは読み取り専用で残せる。Excelを捨てる必要はなく、裏側を強化すればいい。

「脱Excel」の前に、Excelの使い方を見直す選択肢

「脱Excel」が必要な場面はもちろんある。ただ、中小製造業のデータ加工業務という文脈では、Excelの使い方を変えるだけで解決できることも多い。

変化への追従速度が速い。導入の壁が低い。教育が要らない。帳票がそのまま出る。そして何より、すでに手元にある。

100点のシステムを時間とコストをかけて導入するのも一つの道だが、今あるExcelの使い方を変えて80点の仕組みを来週から回し始めるという選択肢も、中小製造業のDXとしてはもっと検討されていいと思っている。

手段の選択肢は多いが、評価軸がぼやけている

DXを進めるにあたって、手段の選択肢は意外と多い。パッケージ導入、OSS導入、ベンダーによるフルスクラッチ開発、小規模ベンダーへの開発委託、内製エンジニアによるプログラミング、ローコード開発、業務委託の活用。どれがいいのかという問いに対して、一般的には「まずパッケージを検討し、合わなければスクラッチ」という順序が語られることが多い。

しかし多品種少量・受注生産の中小製造業という文脈に絞ると、この一般論はむしろ逆に作用すると感じている。

評価軸は「変化への追従速度」

この業態の最大の特徴は、業務プロセス自体が常に変動することにある。量産型とは決定的に違う点で、「一度作って終わり」のシステムでは対応できない。

パッケージもベンダー開発も、変更に対するリードタイムが長い。受注生産の現場は「来月からこのやり方に変えたい」が日常なのに、要件定義→見積→開発→テスト→リリースで数ヶ月かかるのでは、現場が先に進んでしまう。

どの手段が正解かを考えるとき、最も重要な評価軸は変化への追従速度になる。この軸で測ると、業務を最も深く理解している社内の人間が直接手を動かせる状態が、結果的に最も速い。

各手段の向き不向き

どの手段にもメリットはあるし、うまくいっている会社もある。ただ、多品種少量の受注生産で「現場の変化に追いつける仕組み」を作ろうとすると、内製の優位性が際立ってくるというのが、現場を見てきた実感になる。

ベンダーの規模ではなく「知識の所在」の問題

大手ベンダーと小規模ベンダーにはそれぞれ異なるトレードオフがある。大手はスピードが遅くコストも高いが、ドキュメント整備や引き継ぎは最低限やってくれる。小規模ベンダーは柔軟で小回りが利くが、ドキュメントが手薄になりがちで、知識が社内にまったく残らないケースが多い。

しかし本質的な問題は、ベンダーの規模ではなく知識がどこにあるかだと思っている。大手がドキュメントを残してくれても、それを読んで理解できる人が社内にいなければ紙の束でしかない。小規模ベンダーに頼むこと自体は悪くないが、丸投げして納品物だけ受け取るのでは、ベンダーロックインの小規模版になるだけになる。

つまり、どの手段を選ぶにしても、社内に「理解できる力」がないと同じ構造的な問題にぶつかる。内製力はDXの一つの手段ではなく、すべての手段を機能させるための土台になる。

内製化の最大のハードルは人材

ここまで聞くと「内製化最高」となりがちだが、最大の問題はハードルの高さにある。中小製造業で事務作業をしている人に「プログラミングを覚えろ」と社内命令を出すのは現実的ではない。大企業のように潤沢な人材がいるわけでもない。

プログラミングは意欲の問題ではなく適性の問題で、業務で使えるレベルまで自走できるかどうかは「好きかどうか」にかなり依存する。中小製造業に入社する人の動機は「ものづくり」であって「プログラミングがしたい」ではない。ゴリゴリのプログラマーが社内にいること自体が例外的で、それを戦略の前提にはできない。

内製化にはレベルがある

「内製化＝社員全員がプログラマーになること」ではない。自分が考える内製力のレベル感はこうなる。

• レベル0： 完全外注。中身は誰もわからない
• レベル1： 仕組みを「理解できる」人がいる
• レベル2： 設定変更・軽微な修正ができる人がいる
• レベル3： ローコード等で業務ツールを作れる人がいる
• レベル4： プログラミングで自由に作れる人がいる

多くの会社はレベル0で、いきなりレベル4を目指すから「無理だ」となる。しかしレベル1〜2に引き上げるだけでも状況は劇的に変わる。ベンダーと対等に会話できるようになるし、「この変更は自分たちでできる」という判断ができるようになる。

「育成」ではなく「発掘」

全員に求めるのではなく、1人見つけるのが出発点になる。現場や事務の中に、Excelマクロを自発的に作っているような人がいることがある。あるいは趣味でPCを触るのが好きな人。そういう人に業務時間の一部を使って取り組んでもらう。

「社内命令でプログラミングを覚えろ」ではなく、すでに素養がある人を見つけて環境と時間を与える。命令ではなく発掘。これなら再現性がある。

AI支援がレベル間の壁を下げている

レベル4の人材を社内で見つけるのはほぼ運だと述べたが、ここに今、大きな変化が起きている。AIコーディング支援によって、レベル3の人がレベル4に近いアウトプットを出せる場面が増えている。

完全なレベル4にはならない。しかし中小製造業のDXに必要なのは、最先端のWebサービスを作ることではなく、自社の業務に合った実用的なツールを作って回すことだ。それなら、レベル3にAI支援を組み合わせた「レベル3.7」程度で十分回るケースが多い。

8割内製、2割外部という現実解

ゴリゴリのプログラマーを社内で育てようとしなくていい。ツールやExcelに強い人を1人見つけて、ローコードやAI支援を使える環境を整えれば、自社に必要な8割はカバーできる。残り2割は外部の力を借りればいい。

そしてその「残り2割の外部」が丸投げベンダーではなく、製造業の文脈がわかって一緒に作れる人間であれば、知識も社内に残る。

100%内製を目指すから非現実的に見える。コモディティ業務はパッケージで割り切り、製造の中核業務は内製を軸にし、足りない部分は伴走型の外部支援で補完する。この組み合わせが、中小製造業のDXにおいて最も再現性のある形だと考えている。

一緒くたに語られがちな内製DX

内製DXという言葉で括られるソフトウェアには、実は目的が異なる二つの型がある。「管理精度を上げるソフト」と「工数を削減するソフト」。この二つは設計の方針も導入のアプローチも違うのに、あまり区別されないまま語られることが多い。

自分が内製で業務ソフトを作ってきた経験では、この区別を意識するかどうかで、定着するかしないかが大きく変わると感じている。

管理精度型と工数削減型の違い

管理精度型は、今まで見えなかったものを見えるようにするソフト。在庫の正確な把握、勤怠の記録、プロジェクト進捗の可視化など。導入後、数値化や構造化によって経営判断の質が上がるのが狙いになる。

工数削減型は、今までやっていた作業を減らす・なくすソフト。手作業の自動化、帳票生成、データ連携など。導入前後で時間が測りやすく、効果が目に見える。

この二つを混同すると問題が起きる。管理精度型を「工数削減」で評価すると、現場から「仕事が増えただけ」と反発される。工数削減型に「管理が良くなったか？」と問うても、そもそもそこは変わっていない。経営層への説明が曖昧になり、どちらも中途半端な投資判断になる。

両方を兼ねるソフトは成功しやすい

ただし、二つの型がきれいに分かれるとは限らない。ペーパーレス化はその典型で、紙を探す手間が減り（工数削減）、同時にデータが構造化されて管理精度も上がる。

こういう両立型は、導入してもまず成功する。当たり前の話だが、使う本人が楽になり、かつ管理も良くなるなら、反対する理由がない。

逆に言えば、成功しやすい内製DXには共通点がある。使う人自身にメリットがあるかどうか。ここが分かれ目になる。

分類するのは「ツール」ではなく「体験」

ここまで読んで、「そんなに簡単に二つに分けられるのか？」と思った方もいるだろう。CRMはどっちだ、工数入力はどっちだ、と。

結論から言うと、ツール単位で分類しようとするとうまくいかない。分類すべきなのは、ツールではなく使う人の体験の方になる。

CRMを例にすると、営業担当にとって商談内容を毎回入力するのは負担が増える体験（管理精度型）だが、過去の対応履歴をすぐ引き出せたり、フォロー漏れを通知してくれたりする部分は楽になる体験（工数削減型）になる。一つのツールの中に、両方の体験が混在している。

工数入力も同じ構造で、毎日作業時間を記録する部分は純粋に負担が増える。しかし、そのデータから自分の稼働状況が可視化されて、無理な仕事を断る根拠にできるなら、入力者本人にもメリットがある。

つまり、二つの型は「このソフトは管理精度型」「あのソフトは工数削減型」とラベルを貼るためのものではない。一つのソフトの中で、どの機能が誰にとってどちらの体験になっているかを見るための視点になる。

そして設計で考えるべきは、管理精度型の体験（負担が増える部分）をどれだけ小さくして、工数削減型の体験（楽になる部分）をどれだけ大きくできるかというバランス。そのバランスが「楽になる」側に傾いていれば自然に定着するし、「負担が増える」側に傾いているなら、次に述べるような設計上の工夫と導入戦略が必要になる。

管理精度だけを目的にしたソフトが定着しにくい理由

管理精度型の構造的な問題は、入力する人と恩恵を受ける人が違うことにある。

現場の担当者が毎日データを入力する。その数字を見て判断に使うのは管理者や経営層。担当者にとっては純粋に作業が増えただけで、自分の仕事が楽になるわけではない。

だから「入力が面倒」「Excelでいいじゃん」となって、次第に使われなくなる。管理精度型のソフトが形骸化するパターンは、だいたいこの構造で説明がつく。

管理精度型を成功させる設計のコツ

自分が管理精度を目的としたソフトを作るときに意識しているのは、作業者の負担をギリギリ変わらないラインに抑えること。

• 工数が減る → 現場が喜んで使う
• 工数が変わらない → まあ使ってくれる
• 工数が少しでも増える → 抵抗が始まる

この閾値はかなりシビアで、紙に手書きしていたものをフォームに入力するだけでも「前のほうが早かった」と言われることがある。

だから設計では、今の作業フローをそのまま置き換える形にする。入力項目は最小限にする。選択式やデフォルト値で手間を減らす。管理側としては「せっかく作るならあの項目もこの項目も」と欲張りたくなるが、それをやった瞬間に現場の負担が増えて失敗ルートに入る。

管理精度型のソフト設計は、言い換えれば管理側の欲を削る作業でもある。内製だからこそ、このさじ加減ができるのは強みだと思う。

導入アプローチも型によって変える

設計だけでなく、導入の仕方も二つの型で変えている。

管理精度型はトップダウン寄りで進める。上長に話を通して、「会社の仕組みとして必要」というお墨付きをもらう。現場にとって自発的に使う動機がないソフトは、組織としての後押しがないと定着しない。負担がプラマイゼロに抑えられていれば、「会社で決まったことなら」と使ってくれる。

工数削減型はボトムアップ寄りで進める。上長には「こういうの作りました、使ってOKですか」と許可だけ取る。あとは現場に自由に使ってもらえば、楽になるのだから勝手に広まる。むしろ上から押し付けると「やらされ感」が出て逆効果になりかねない。

このアプローチを逆にすると失敗しやすい。工数削減ツールをトップダウンで強制すると、自分のやり方がある人ほど反発する。管理精度ツールをボトムアップで放置すると、誰も自発的に使わないまま消えていく。

まとめ：型を見極めてから設計と導入を決める

内製DXに取り組むとき、最初にやるべきは「これは管理精度型か、工数削減型か、その両方か」を見極めること。

型が違えば、設計の方針も導入の戦略も変わる。ここを一緒くたにしたまま「内製DXで業務改善」と進めると、打ち手がぼやける。自分の実感としては、この型の見極めが内製DXの最初の仕事だと思っている。

現時点では特に使えないので、今後の備忘録として。

・以下2つをzipをダウンロード
https://github.com/WordPress/mcp-adapter/releases
https://github.com/WordPress/abilities-api/releases

・WPで作業

ダッシュボード>プラグイン>プラグインを追加>プラグインのアップロード
を選択し今すぐインストールを実行。

・プラグインを有効化

ダッシュボード>ユーザー>プロフィール>アプリケーションパスワード
新しいアプリケーションパスワード名(任意)を入力>アプリケーションパスワードを追加

・ここは通常不要。以前作った設定をコメントアウト

・Xserverの管理画面からhtaccessを更新

※パーマリンクのタイプによっては不要
※先頭に以下を追加

CGIPassAuth On
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule ^wp-json/?(.*)$ /?rest_route=/$1 [L,QSA]
</IfModule>

・ターミナル(cmd)から以下を実行。

・MCP登録
claude mcp add -s user wordpress -e WP_API_URL=”https://●●●.com/wp-json/mcp/mcp-adapter-default-server” -e WP_API_USERNAME=”●●●” -e WP_API_PASSWORD=”●●●” -e OAUTH_ENABLED=”false” “–” cmd /c npx -y @automattic/mcp-wordpress-remote@latest

・削除する場合。

・フォルダ限定
claude mcp remove “wordpress” -s local

・PC全体
claude mcp remove “wordpress” -s user

>claude
/mcp
で登録状況を確認。

全工程スケジューリングが合わない現場

手作業が多い中小製造業では、全工程の詳細スケジューリングはうまく機能しません。作業時間は人や製品ごとにばらつきがあり、段取りの入れ替えは日常的です。正確な標準時間マスタの整備が難しいケースも少なくありません。計画を立ててもすぐに崩れてしまい、管理コストだけが増加する傾向にあります。

管理するポイントを絞る

すべての工程を管理する代わりに、重要なポイントだけをスケジューリングする「ポイントスケジューリング」が有効です。例えば出荷と組立だけを管理するアプローチです。多くの中小企業では出荷日のみ管理し、社内工程は現場リーダーの経験で対応しています。

管理ポイントの置き場所は在庫バッファの手前

効果的な管理ポイントは、在庫としてバッファを持てる場所の前に置きます。例えば機械加工と受注組立がある場合：

素材 → 機械加工 → [中間在庫] → 受注組立 → 出荷

在庫で前後を分断することで、それぞれを独立して管理できます。結果として、出荷日、バッファ到着期限、投入日の3つの管理ポイントに絞られます。

現場に任せる、ただし条件付き

手作業中心の現場には、スケジューラーが持たない判断情報があります。ただし放任ではなく、最低限3つの条件が必要です：

• どの仕事がバッファに届いていないかが見えること
• 優先順位が現場に伝わっていること
• 投入量がコントロールできていること

特に投入量の管理が重要で、過剰投入は仕掛品の混乱につながります。

溢れる工程が見えない問題

ポイントスケジューリングの弱点は、受注が積み上がったときのボトルネック特定です。解決策は「スケジューリングではなく負荷の見える化」です。受注ごとに工程グループの通過と概算工数を把握し、週単位で工程別に山積みするだけで十分機能します。

時間軸で見方を変える

時間軸により見方を変えるのも有効です：

• 数年～半年先： 月単位で経営判断の材料に
• 半年～1ヶ月先： 週単位で戦術的判断に
• 1ヶ月以内： 日単位で優先度指示に

遠い先はぼんやり、近づくにつれて解像度を上げることが重要です。

それでも残る課題

完全には解決されない課題として以下があります：

• 材料手配タイミング（リードタイムの長い部品など）
• 現場の優先順位判断支援
• 管理ポイント通過の実績把握
• 負荷溢れ時の対応ルール

これらは大掛かりなシステムではなく、Excelやホワイトボードで対応可能です。骨格となるポイント管理と負荷把握が最優先で、肉付けはその後の段階です。