テックメモ

依頼書からは始まらない

内製DXの仕事は、要件定義書や依頼書から始まるイメージがあるかもしれない。しかし数十人規模の中小製造業で実際に起きていることは、もっと雑然としている。

作業者が「これ、毎回手で集計するの面倒なんですよね」と言う。管理者が「この数字、一覧で見られないかな」と聞いてくる。きっかけは、廊下ですれ違ったときの一言だったり、昼休みの雑談だったりする。

内製DXの仕事は、この 相談 から始まる。そして相談を受けた瞬間に、頭の中でいくつかのことが同時に動き始める。

データがあるかないかを、一瞬で判断する

「この数字を見たい」という要望を聞いたとき、最初にやっていることは、その数字を作るためのデータが既にあるかどうかの判断になる。

あるなら話は早い。ないなら、誰が、どこで、どうやってそのデータを入力するのかを想像する。入力する人の手間がどれだけ増えるか。マスタデータは揃っているか。揃っていないなら、マスタを整備するところから始めなければいけないのか。

このシミュレーションは、理屈で組み立てているわけではない。どのファイルがどこにあるか、どの作業を誰がやっているか、今のデータがどういう形で保存されているか——そういうことが頭に入っているから、要望を聞いた瞬間に実現可能性が見える。

以前の記事で、AIに代替されない能力として「膨大なコンテキスト」と書いた。このシミュレーションが、まさにその具体的な使い方になる。ドキュメントには書かれていない、現場の構造が頭の中に入っていないと、この判断はできない。

→ 中小製造業の内製DX ── AIに代替されない能力は現場でしか身につかない

このシミュレーションは、現場での経験が長くなるほど精度が上がる。いけそうだと感じたものは実際にいける。ダメそうだと感じたものは、ほぼダメになる。

「いけそう」の閾値

ここでいう「いけそう」は、技術的に実装できるかどうかではない。

「いけそう」の閾値は、無理なく自然に使い続けられるかどうか にある。使う人にとって無理がない範囲に収まっているかどうか。この見極めが、相談を受けた時点での最も重要な判断になる。

画面がすべて

いけそうだと判断したら、小さく作ってみる。ここで重要なのは、内部の設計でもデータ構造でもない。 画面 になる。

使う人にとって、システムの中身は見えない。見えるのは画面だけで、判断するのは操作の流れだけになる。だから最初に見せるべきは、動くプロトタイプの画面になる。

以前の記事で、現場へのデータ入力は「いつ・どこで」を設計すると書いた。画面のプロトタイプを見せるのは、まさにこの設計を現場と一緒に検証する作業になる。

→ 中小製造業の現場にタブレットを配っても定着しない ── 入力は「いつ・どこで」を設計する

細かい話に聞こえるかもしれないが、事務職ならタブキーでフォーカスが移動するかどうかを気にする人がいる。現場なら「自分で数字を打つのは無理だから選択式にしてほしい」という声が出る。こういう操作の感覚は、仕様書には書けない。画面を見せて、触ってもらって、初めて出てくる。

画面を見ながら「これなら大丈夫そう」という反応が得られたら、ほぼ問題ない。逆に「こんな操作を毎回やるのは無理」と言われたら、そこで設計を見直すか、場合によっては中止の判断をする。

以前の記事で「話す・聞く・見せる・また話す」と書いた。画面を見せるのは、この「見せる」の部分になる。

→ 中小製造業の内製DX ── 成否は「話す時間」があるかどうかで決まる

使われなくなることは、普通にある

ここまでのプロセスを経ても、使われなくなることはある。

部門長が意気込んで始めたプロジェクトでも、「やっぱりその数字、今は要らないかもしれない」と言われることがある。機器の追加購入が必要だとわかった途端に、中止になることもある。理由は拍子抜けするほど単純なことが多い。

これに対して一喜一憂していたら、この仕事は続けられない。

以前の記事で、実績データ収集は「何と比較するか」から逆算すると書いた。この考え方で設計しても、そもそも「比較する」という行為自体を管理者がやめてしまえば、仕組みごと不要になる。

→ 中小製造業の実績データ収集は「何と比較するか」から逆算する

使われるものは自然に使われる。使われないものは自然に使われなくなる。以前の記事でワークフローやタブレットの話を書いたが、どれだけ設計を工夫しても、最終的には現場が「続けるかどうか」を決める。コントロールできる部分はあるが、限界もある。

大事なのは、プロフェッショナルでいること と、自分の作品だと思わないこと を両立させることだと思う。依頼された仕事には全力で取り組む。しかし、成果物に対して個人的な執着を持たない。これを作ったのは自分だ、使ってほしい、という感情は、判断を鈍らせる。

中止の判断が出たら、それは単に「今はこの仕組みが要らなかった」という情報が得られただけのことになる。その経験は次の相談のシミュレーション精度を上げる材料になる。

相談の精度を上げるもの

この記事で書いたことは、特別な方法論ではない。相談を受ける、シミュレーションする、小さく作る、見せる、結果に執着しない。内製DXの日常は、この繰り返しになる。

ただし、この繰り返しの精度を決めているのは、ツールでも手法でもなく、現場で蓄積したドメイン知識になる。以前の記事で「身体性→コンテキスト蓄積→構造化」という順番があると書いた。相談を受けた瞬間のシミュレーションは、この3つが噛み合って初めて機能する。

→ 中小製造業の内製DX ── AIに代替されない能力は現場でしか身につかない

逆に言えば、ドメイン知識の蓄積がない状態でこのプロセスを真似しても、シミュレーションの精度が低いので空振りが増える。「いけそう」と思って作ったが使われなかった、が頻発する。

だからこそ、以前の記事で繰り返し書いてきたように、内製DXエンジニアは現場に出る時間を削ってはいけない。相談の精度を上げるのは、開発スキルではなく、現場を知っている時間の蓄積になる。

---

このシリーズの他の記事：

• 中小製造業の内製DX ── AIに代替されない能力は現場でしか身につかない
• 中小製造業の内製DXには「管理精度型」と「工数削減型」がある
• 中小製造業の内製DX ── 成否は「話す時間」があるかどうかで決まる

シリーズ記事一覧・著者への相談はこちら →

コードを書けることが武器だった時代

少し前まで、中小製造業で「ちょっとしたスクリプトが書ける」「VBAで業務ツールを作れる」というだけで、社内では貴重な存在になれた。周りにできる人がいないので、簡単なプログラムでも武器になった。

この状況が変わりつつある。AIコーディングツールの進化で、業務をある程度理解している人なら、自分でツールを作れるようになってきた。「Excelのこの作業を自動化して」とAIに指示すれば、それなりのVBAが出てくる。以前の記事で「AIが実装を肩代わりする」と書いたが、その流れは加速している。

→ AI時代の内製DXエンジニア ── 実装の先にある仕事が本業になる

実装力の価値が相対的に下がったとき、内製DXエンジニアに残る武器は何か。

AIにはコンテキストの限界がある

以前の記事で「ドメイン知識が唯一の差別化になる」と書いた。これをもう少し掘り下げると、ドメイン知識の正体は 膨大なコンテキスト だということに気づく。

中小製造業の現場には、どこにも書かれていない情報が大量にある。この取引先には特殊なルールがある。この工程は図面通りにやると品質が出ない。この人に聞けば本当のことがわかるが、あの人に聞くと建前しか返ってこない。過去にこういう失敗があったから、今のやり方になっている。

こうしたコンテキストはドキュメント化されていない。されていないどころか、当事者自身が「これは情報だ」と自覚していないことも多い。以前の記事で「現場の人は自分の仕事を言語化できない」と書いたのと同じ構造になる。

→ 中小製造業のナレッジ管理が進まない本当の理由 ── Wikiを入れても書かれない

AIのコンテキストウィンドウは広がり続けている。しかし、ドキュメント化されていない情報はAIに渡しようがない。渡せない情報は、AIには使えない。この「渡せない膨大なコンテキスト」を自分の中に持っていることが、AIに代替されない能力の土台になる。

身体性 ── 現場に立たないと見えないもの

コンテキストはどうやって蓄積されるか。デスクに座ってデータを眺めていても、表面的な情報しか入ってこない。

現場に立つと、データにならない情報が入ってくる。機械の音で調子がわかる。人の動線を見れば、どこで作業が滞っているか見える。誰が誰に聞きに行っているかを観察すれば、情報の流れと属人化のポイントが見える。机の上に貼ってあるメモ、ホワイトボードの走り書き、棚の整理のされ方——こうした「ノイズ」の中に、業務の本当の姿が埋まっている。

以前の記事で「データの棚卸しをすれば、自然と属人化リスクが見えてくる」と書いた。しかし棚卸しの精度は、現場を自分の足で回っているかどうかで大きく変わる。ファイルサーバーを検索するだけの棚卸しと、現場の机の上まで見て回る棚卸しでは、拾える情報の量が違う。

→ 中小製造業の内製DXは「改善」の前に「地固め」から始める

この 身体性 ——五感を使って現場の情報を拾う能力——はAIに渡せない。カメラやセンサーで現場をモニタリングしても、「あ、ここが詰まっているな」という直感的な気づきは、現場に立った経験の蓄積がないと生まれない。

構造化能力 ── 混沌を仕組みに変える力

身体性で拾った情報と、膨大なコンテキスト。これだけなら、現場のベテランも持っている。ベテランは現場のことを誰よりも「わかっている」。

しかしベテランは、わかっていることを構造化できない。「なんとなくこうやっている」「長年の勘でこうしている」。これを データの設計やシステムの仕組みに落とせる かどうかが、内製DXエンジニアとベテランの違いになる。

以前の記事で「DX担当者は現場の言葉と技術の言葉の通訳だ」と書いた。通訳とは、片方の言葉をもう片方に変換する仕事になる。現場のベテランが「こういう感じでやっている」と言ったことを、データベースの項目定義やシステムのロジックに変換する。この変換ができるのは、 現場の言葉も技術の言葉も両方わかっている人 だけになる。

→ 中小製造業の内製DX ── 成否は「話す時間」があるかどうかで決まる

AIは構造化が得意に見える。しかしAIが構造化できるのは、すでに言語化された情報だけになる。言語化されていない現場の暗黙知を、まず言語化し、それから構造化する——この二段階の変換が、人間にしかできない仕事として残る。

この3つは順番がある

身体性、膨大なコンテキスト、構造化能力。この3つは同時には身につかない。順番がある。

まず身体性が先に来る。 現場で身体を使って仕事をする経験がなければ、何を見るべきかがわからない。データを見ても「この数字の裏に何があるか」が想像できない。

次にコンテキストが溜まる。 現場にいる時間が積み重なると、個々の業務がつながって見えてくる。「あの工程が遅れると、この工程にこう影響する」「この取引先がこう言うときは、実はこういう意味だ」。断片的な情報が文脈として厚みを持ち始める。

最後に構造化能力が加わる。 溜まったコンテキストを、データやシステムの形に落とす力。これは技術的なスキルだが、前の2つがないと空回りする。現場を知らずにデータベースを設計しても、使われないマスタテーブルが増えるだけになる。

自分のキャリアがまさにこの順番だった。生産管理として現場で10年。この間に業務の身体感覚とコンテキストが蓄積された。その上で社内SEに転じて、蓄積されたものをシステムの形に落としていった。もし最初からSEとして入社して、いきなりフルリモートで業務システムを設計しろと言われていたら、まともなものは作れなかったと思う。

フルリモートでは積み上がらないもの

リモートワークを否定するつもりはない。チャットもリモートデスクトップも、以前の記事で便利な道具として紹介した。

→ 中小製造業の社内連絡は、メールでも電話でもなくチャットがちょうどいい

しかし、チャットで流れてくるのは 相手が言語化できた情報だけ になる。言語化できない情報——現場の空気、人の動き、ホワイトボードの走り書き——はリモートでは拾えない。

内製DXの記事シリーズで繰り返し「現場に出向け」「話す時間を確保しろ」と書いてきたのは、この身体性とコンテキストの蓄積を止めるなという意味でもある。効率を求めてリモートに閉じると、AIと同じ制約——渡された情報しか扱えない——を自分に課すことになる。

AIが実装を代替する時代に、AIと同じ情報源しか持っていなければ、差別化はできない。AIが持てないもの——身体で蓄えた現場の感覚と、年月をかけて積み上げた膨大なコンテキスト——を持っていることが、内製DXエンジニアの武器になる。

泥臭さが最後に残る

以前の記事で「改善を飛ばして変化には行けない」と書いた。

→ AIの具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由

同じことがスキルにも言える。AIツールを使いこなす力は大事だが、それは構造化能力の一部であって、土台ではない。土台は、現場に足を運び、人と話し、業務の混沌を自分の中に取り込む——この泥臭い蓄積にある。

コードを書く力の価値は下がっていく。しかし、現場の混沌を整理する力の価値は上がっていく。そしてその力は、現場で身体を使わないと身につかない。効率化やAIの話が華やかであればあるほど、この泥臭い部分が見過ごされがちだが、内製DXの本当の差別化は、結局ここにある。

---

このシリーズの他の記事：

• AI時代の内製DXエンジニア ── 実装の先にある仕事が本業になる
• 中小製造業の内製DX ── 成否は「話す時間」があるかどうかで決まる
• 中小製造業のナレッジ管理が進まない本当の理由 ── Wikiを入れても書かれない
• 中小製造業の内製DXは「改善」の前に「地固め」から始める

シリーズ記事一覧・著者への相談はこちら →

誰も全貌を把握していない

DXの地固めとして「データの棚卸し」が必要だという話は以前の記事で書いた。

→ 中小製造業の内製DXは「改善」の前に「地固め」から始める

棚卸しの中で最も厄介なのが、Excelファイルの整理だと思っている。共有フォルダを開くと、大量のExcelファイルが並んでいる。名前を見てもわからないものが多い。中を開いても、いつ誰が何に使っているのか判別がつかない。

しかもこれが共有フォルダだけなら良い方で、個人PCのデスクトップやCドライブの奥にも散在している。社内のExcelファイルの全貌を把握している人は、まずいない。

「使っていますか？」が当てにならない理由

普通に考えれば、関係者に聞けばいい。「このファイル、使っている人はいますか？」と。

しかし実際にやると、これがうまくいかない。

• 本人が忘れている。 毎月1回だけ使うファイル、年次の棚卸しでだけ使うファイルは、聞かれても思い出せないことがある
• ショートカットの名前が違う。 デスクトップに「売上集計」というショートカットを置いているが、元ファイルは「2019_uriage_v3_final.xlsx」という名前で、別のファイルだと思っている
• マクロの中から参照されている。 別のExcelのVBAが裏でこのファイルを読みに行っているが、使っている本人はそのことを知らない
• 前任者から引き継いだまま放置されている。 「なんとなく消さないでおいてある」ファイルが大量にある

結果、「使っていない」と返ってきたファイルが、実は使われていたということが起きる。逆に「使っている」と言われたファイルが、もう何年も開かれていなかったりもする。聞いて回るだけでは、正確な現状は見えてこない。

「移動して反応を待つ」という方法

自分がたどり着いたのは、少々強引だが確実な方法になる。

正体がわからないファイルを、元の場所から別のフォルダに移動する。

削除ではない。「退避」フォルダに移すだけ。ファイルは残っているので、いつでも戻せる。

すると何が起きるか。そのファイルを実際に使っている人が、開こうとしたときに「ファイルが見つかりません」とエラーが出る。ショートカットもリンクも切れる。そうすると、その人から連絡が来る。

「あの、○○というファイルが見つからないんですけど」

この連絡が来た時点で、そのファイルは確実に使われていることがわかる。誰が、何の目的で使っているかも、その場で聞ける。聞いて回るより、はるかに正確な情報が取れる。

前提としてフォロー環境が必要

ただし、この方法には前提がある。 ファイルが見つからないときに、すぐに相談できる環境が整っていること。

チャットがあれば、「○○ファイルが見つかりません」と一言投げるだけでいい。DX担当者はすぐに対応して、退避フォルダから戻せる。

→ 中小製造業の社内連絡は、メールでも電話でもなくチャットがちょうどいい

この導線がないと、ファイルが消えたと思って騒ぎになったり、DX担当者に連絡が届かないまま業務が止まったりする。地固めの第一歩としてチャットを入れておく理由は、こういうところにもある。

この方法の弱点：1年はかかる

反応を待つ方法の弱点は、時間がかかること。

月次の処理で使っているファイルなら1ヶ月以内に連絡が来る。しかし、年に1回しか使わないファイルは、1年待たないと判明しない。年次決算、年末調整、繁忙期だけ使う特殊な集計ファイル——こういうものは意外と多い。

だから、この方法だけに頼るわけにはいかない。現実的な進め方はこうなる。

1. まず聞ける範囲で聞く。 各部署のキーパーソンに、日常的に使っているExcelを教えてもらう。完璧でなくていい。主要なものが把握できれば十分。

2. ファイルの最終更新日で機械的にふるいにかける。 2年以上更新されていないファイルは、使われていない可能性が高い。ただし、参照専用で開くだけのファイルは更新日が変わらないので、これだけでは確定できない。

3. 残ったものを退避する。 聞いても更新日で見てもわからないものを、退避フォルダに移す。

4. 1年は様子を見る。 この間に連絡が来たファイルは戻し、用途を記録する。1年経っても連絡が来なかったファイルは、ほぼ使われていないと判断できる。

重要なのは、どの段階でも 削除はしない ということ。退避であって削除ではない。万が一のときに戻せる状態を維持しておく。

棚卸しの目的はファイルの削減ではない

ここまで書くと「不要ファイルの整理術」に見えるかもしれないが、本当の目的はそこではない。

棚卸しの目的は、 どのExcelが、誰によって、何の業務に使われているかを可視化すること にある。

この情報が手元にあると、DXの次の一手が打てる。

• どのファイルが業務の流れの中で重要なのかがわかる → データの文法の整理対象が決まる
• 同じようなデータが複数のファイルに散在していることがわかる → 二重入力の解消ポイントが見える
• 特定の人しか触れないExcelが見つかる → 属人化のトリアージと重なる

→ Excelのデータは「いつでもDBに移せる形」で持つ ── データの文法という考え方

棚卸しはファイルの掃除ではなく、DXの地図作りだと思っている。どこに何があるかわかっていれば、何から手をつけるかが見えてくる。

---

このシリーズの他の記事：

• 中小製造業の内製DXは「改善」の前に「地固め」から始める
• 中小製造業のExcelが「1シート」で止まる理由 ── 関数の限界と次の一歩
• 中小製造業は「脱属人化」ではなく「属人化のトリアージ」

シリーズ記事一覧・著者への相談はこちら →

ナレッジ管理の必要性は誰もがわかっている

「ベテランの知識を残さなければ」「属人化を解消しなければ」。中小製造業に限らず、どの会社でも一度は話題に上がるテーマだろう。

→ 中小製造業は「脱属人化」ではなく「属人化のトリアージ」

しかし、実際にナレッジ管理が回っている中小企業はほとんどない。Wikiを導入しても更新されない。共有フォルダにマニュアルを置いても誰も書かない。「時間がないから」と言われるが、時間を与えても結果は変わらないことが多い。

問題はツールでも時間でもない。もっと手前にある。

自分の仕事を言語化できない

中小製造業の現場で長年働いてきた人たちは、仕事はできる。段取りも判断も的確。ただし、自分がやっていることを文章として書き出す訓練はしていない。

「なぜこの順番で加工するんですか？」と聞くと、「こうやるもんだから」と返ってくる。本人の中には明確な理由があるはずだが、それを言葉にする回路が普段使われていない。日記を書いたことがない人にいきなり業務手順書を書けと言っても、何から書けばいいかわからないのと同じことだと思う。

これは能力の問題ではなく、経験の問題になる。自分の業務を内省して、他人にわかる形で言語化する。この作業には慣れが要る。

効率化の先にナレッジが残らない問題

ナレッジ管理とは別の角度から、似た問題を抱えている会社がある。業務の多くを外注や派遣で回し、社内にはマネジメントと事務だけが残るような組織。効率化としては合理的に見えるが、実際に話をすると、業務の深みや知見の蓄積がほとんど感じられないことがある。

これは外注先に知識が分散してしまい、社内に残るのは「誰に何を頼むか」という段取り情報だけになっているケースだと思う。日常の業務は回る。しかし、外注先が変わったとき、要件が変わったとき、自社だけでは判断も対応もできない。業務の「どうやって」「なぜこうするのか」が社外にあるので、組織としての厚みがない。

ナレッジ管理が難しいのは、言語化できないからだけではない。そもそも知識が社内に存在しない、という状態にも陥りうる。

仕組みを与えれば回る組織、回らない組織

こう言うと失礼に聞こえるかもしれないが、事実として書いておく。

リモートワーク前提のスタートアップのように、言語化やドキュメント作成に慣れた人材が集まっている組織であれば、Wikiや仕組みを与えるだけで回る。リモートで仕事をするには文章で伝える力が前提になるから、書くスキルが自然と揃っている。

中小製造業の現場はそうではない。道具を用意して、時間を与えて、「書いてください」と言っても、それだけでは動かない。「書ける人がいない」という前提から出発しないと、施策は空振りに終わる。

現実的な解は「聞き取り役」を置くこと

本人に書かせるのが難しいなら、聞き出す側を用意するしかない。言語化が得意な人間がベテランの隣に座り、質問して、答えを構造化して残す。

ここで求められるのは、ただ話を聞くことではなく、業務の文脈を理解した上で「それはつまりこういうことですか」と翻訳できる力になる。業務を知らない人が聞いても、表面的なメモにしかならない。逆に、業務を理解している人間が聞けば、「この判断の裏にはこのロジックがある」というところまで掘り下げられる。

→ 中小製造業の内製DX ── 成否は「話す時間」があるかどうかで決まる

この役割は、内製DXエンジニアの仕事として自然に成り立つ。システムを作る前に業務を聞き取る工程があり、その過程で得た知識を記録として残していけば、ナレッジ管理はシステム開発の副産物として進んでいく。

一度にやろうとしない

経営者がナレッジ管理に乗り気になると、「全部門一斉にやれ」という号令が出がちになる。しかし、ナレッジの蓄積はそんなに簡単ではない。

通常業務と並行しながら、少しずつ聞いて、少しずつ残す。1回の聞き取りで完璧な手順書ができるわけではない。断片的なメモが溜まり、何度か同じ人に聞き直し、少しずつ精度が上がっていく。年単位の時間がかかる覚悟を持って、じっくり取り組むものになる。

これは見積データの再利用と同じ考え方で、日々の業務の中で自然にデータが溜まる構造を作るのが理想になる。ナレッジも同じで、特別なプロジェクトとして一気にやるのではなく、日常の業務改善やシステム構築の中で少しずつ蓄積していく方が、現実的だし定着もしやすい。

→ 中小製造業の生産計画は、見積もりデータの再利用から始められる

完璧なマニュアルを目指さない

もう一つ大事なのは、最終形をいきなり目指さないこと。

「完全な業務マニュアル」を作ろうとすると、永遠に完成しない。狙うべきは、「この人がいなくなったとき、次の人がゼロからではなく30点からスタートできる状態」で十分。

判断の根拠を一言メモで残す。「この客は仕上げにうるさいから最後に検品を入れる」──この一文があるだけで、引き継ぎのダメージは大幅に変わる。完璧な手順書ではなく、判断の手がかりを残すこと。これがナレッジ管理の現実的な着地点だと考えている。

---

このシリーズの他の記事：

• 中小製造業は「脱属人化」ではなく「属人化のトリアージ」
• 中小製造業の内製DX ── 成否は「話す時間」があるかどうかで決まる
• 中小製造業の内製DXは「改善」の前に「地固め」から始める

シリーズ記事一覧・著者への相談はこちら →

パッケージは「失敗」しにくい

最初に整理しておくと、パッケージソフトの導入で根本的な失敗が起きることはあまりない。パッケージは仕様通りに動く。合う合わないはあっても、動かないということは基本的にない。

問題が起きやすいのは、フルスクラッチやカスタマイズの領域になる。自社の業務に合わせて作り込む部分で、エラーが出る、消せないデータが残る、依頼したはずの機能が実装されていない、といったことが現実に起きる。

「失敗」の線引きは曖昧

ただし、何をもって「失敗」とするかは人による。「自分が言った要望が入っていない」と思う人もいれば、「これで十分」と思う人もいる。見方の違いであって、明確な基準があるわけではない。

ある程度客観的に「失敗」と言えるのは、こういうケースだろう。

• 操作するとエラーが出る
• 不要なデータが削除できない
• 依頼した機能が実装されていない、または仕様通りに動かない

逆に、「もう少しこうしてほしかった」というレベルの不満は、失敗というよりすり合わせ不足の話になる。

100%成功した導入はない

自分は過去に何度もシステム導入に関わってきたが、100%思い通りに仕上がったケースはない。小さなエラーは必ず残るし、どうしてもソフト側で実現できない機能が出てくる。

象徴的なのは、業者のSEが「この機能はシステムでは対応できないので」と言って、対策用のExcel VBAを書いて持ってくるケース。システム化するために導入したはずなのに、結局Excelで補完しているという本末転倒な状況は珍しくない。

→ 「ERP」という言葉の解像度が低すぎる ── 中小製造業が本当に必要な仕組みを考える

検収が終わればそこで線が引かれる

システム導入には検収というプロセスがある。納品物を確認して「これで受け取ります」と合意する手続きになる。

検収が終わった後に見つかる問題は、保守契約の範囲内で対応してもらえる軽微なものに限られる。「あの機能が足りない」「ここの動きが違う」と言っても、追加費用なしでは対応してもらえないことが多い。

つまり、検収後のシステムが「完璧ではないが致命的でもない」状態であれば、そのまま使い続けることになる。これはどこの会社でも同じで、100点のシステムを使っている会社はほぼないと思っていい。

すぐには止められない現実

「合わないなら別のシステムに変えればいい」と思うかもしれないが、中小企業にとってそれは簡単ではない。

フルスクラッチやカスタマイズで作ったシステムは、資産として減価償却の対象になる。金融機関からの融資で導入している場合もある。会計上も資金繰り上も、導入して数年で捨てるという判断は取りにくい。

現実的には、最短でも5年程度は使い続ける前提になる。だからこそ、「検収後にどう付き合うか」が重要になってくる。

使いながらできることをやる

検収後のシステムに不満があっても、ただ我慢して使い続けるだけが選択肢ではない。特にフルスクラッチで作られたシステムの場合、内部に手を入れられる余地があることが多い。

ただし、契約上はシステムの内部を勝手に触ることが禁止されている場合もある。保守契約の範囲外の操作で問題が起きた場合、責任を問われる可能性がある。

ここは交渉の余地がある。不具合が多く残っている状態なら、「これだけ問題が残っているので、自分で対応させてほしい。それが難しいならきちんと修正してほしい」と伝える。開発元が小規模なシステム会社であれば「自分で触ってもらって構いません」と柔軟に対応してくれることも多い。

大事なのは、 「自分で操作していい」という許可をメールなど文面で残しておくこと。 口頭の了承だけだと、後から「勝手に触られた」と言われたときに守れない。この一手間が、自分で手を入れる際の保険になる。

その上で、できることは意外とある。

• DBに直接接続する。 システムのデータベースにVBAやSQLで接続し、システム側では出せないレポートや集計を自分で作る。データさえ取れれば、足りない機能を補完できる場面は多い
• サーバーの設定を見て理解する。 権限設定や接続先の構成を把握しておくと、トラブル時に業者を待たずに対処できることがある
• 業者に頼らず直せる範囲を広げる。 マスタデータの修正、帳票のレイアウト変更など、自分で触れる部分を少しずつ増やしていく

これらは一朝一夕にはできないが、5年使い続ける前提であれば、じっくり取り組む時間はある。

次の入れ替えに向けた準備

5年後に入れ替えのタイミングが来たとき、前回と同じ轍を踏まないための準備もこの期間にできる。

今のシステムを使いながら「何が足りなかったか」「どの業務がシステムに乗らなかったか」を記録しておく。検収前には気づかなかった問題点が、日々の運用の中で見えてくる。

このデータがあれば、次の導入時に「ここだけは絶対に実現してほしい」と具体的に伝えられる。要件定義の精度が上がるだけで、同じ失敗を繰り返す確率は大幅に下がる。

→ 手作業で検証してからシステム化する ── 中小製造業で「作ったのに使われない」を防ぐ方法

完璧を求めず、使いながら育てる

システム導入に100点はない。これを最初から受け入れておくだけで、検収後の心構えが変わる。

70点のシステムを自分の手で80点に近づけていく。足りない部分はExcelやVBAで補完する。そして5年後の入れ替え時には、今回の経験を活かしてより良い判断をする。

中小製造業のシステムとの付き合い方は、導入して終わりではなく、使いながら育てていくものだと思っている。

---

このシリーズの他の記事：

• 「ERP」という言葉の解像度が低すぎる ── 中小製造業が本当に必要な仕組みを考える
• 手作業で検証してからシステム化する ── 中小製造業で「作ったのに使われない」を防ぐ方法
• 中小製造業のDX、どの手段が正解か ── 再現性のある内製化のレベル感

シリーズ記事一覧・著者への相談はこちら →

AIが実装を肩代わりする時代に、何が残るか

以前の記事で「AIはインフラになる」と書いた。また別の記事で「VBAでもAIに書かせる設計ができる」と書いた。

→ AIの具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由
→ 内製DXの開発にAIを使う ── VBAでも「AIに書かせる設計」はできる

この2つを合わせると、1つの問いが出てくる。AIが実装を肩代わりするようになったとき、内製DXエンジニアの仕事はどう変わるのか。

答えから言えば、 実装の「先」にある仕事——業務の理解、問題の分解、指示、検証——が本業になる。 コードを書く時間が減り、コードを書く前と書いた後の仕事が増える。

これは効率が上がるという話ではない。仕事の中身が変わるという話になる。

「何を作るか」を決める力がすべてになる

AIにコードを書かせるとき、最も重要なのは「何を書くか」の指示になる。「月別の売上集計を出して」ではなく、「受注データのうちステータスが完了のものを対象に、出荷日ベースで月別に集計し、前年同月との差額を並べて返す」——ここまで分解して初めて、AIは正確なコードを出してくる。

この分解ができるのは、業務を理解している人だけになる。「出荷日ベース」なのか「受注日ベース」なのか、「完了」の定義に何が含まれるのか、前年同月と比べるべきなのか前月と比べるべきなのか。こうした判断は業務の文脈がわからなければ下せない。

以前の記事で「DX担当者の仕事はコードを書くことではなく、現場の言葉と技術の言葉の通訳だ」と書いた。AIが実装を担うようになると、この通訳の役割がさらに重要になる。現場が「こういうのが見たい」と言ったことを、AIが実行できる精度の指示に翻訳する。その翻訳精度が、アウトプットの質を決める。

→ 中小製造業の内製DX ── 成否は「話す時間」があるかどうかで決まる

「全部読んで確認する」はどこかで限界が来る

AIがコードを書くスピードは速い。しかし、出てきたコードが正しいかどうかを確認するのは人間の仕事になる。

今の段階では、AIが書いたコードを全部読んで、1行ずつ確認して、動作をテストする——これで回る。VBAの関数を1つ書かせる、Excelの集計ロジックを1つ組ませる。このレベルなら、人間がすべて目を通すことは十分可能になる。

しかし、AIがもっと大きな範囲のコードを書くようになったとき——システム全体の処理を書かせる、複数のモジュールをまとめて生成する——「全部読む」というやり方は限界が来る。量が多すぎて、読んで理解すること自体がボトルネックになる。

ではどうするか。 テストの仕組みを使って、結果で検証する。

今のExcel VBAでもすでにやっていることがある。セルにテスト用の値を入れて、関数を呼び出して、期待通りの結果が返ってくるか確認する。これをもう少し系統的にやるだけの話になる。「この入力に対してこの出力が返るはず」というテストケースを先に作っておいて、AIが書いたコードをそのテストに通す。コードを全行読まなくても、テストが通れば正しく動いていると判断できる。

これは今すぐ必要な話ではないが、AIの活用範囲が広がるにつれて必要になる考え方になる。コードを「読んで確認する」から「テストで検証する」へ。確認の方法自体が変わっていく。

「どう作るか」の設計が、AIへの指示になる

以前の記事で「VBAのロジックをFunctionに切り出すとAIに書かせやすくなる」と書いた。これは「コードの構造を整理する」という話だが、もう一段引いて見ると、 設計がAIへの作業指示になる という構造の変化を意味している。

これまで設計とは「人間が修正しやすいように構造を分けること」だった。これからは「AIに担当範囲を伝えやすいように構造を分けること」が加わる。

たとえば、1つの大きな処理をAIに丸ごと書かせると、何がどうなっているか把握しにくい。しかし「この部分は入力の整形」「この部分は計算ロジック」「この部分は出力の組み立て」と分けてあれば、それぞれを個別にAIに書かせて、個別に確認できる。

この「分け方」を決めるのが設計であり、AIに実装を任せる時代になると、設計の意味がより直接的に問われるようになる。

ドメイン知識が唯一の差別化になる

AIはプログラミングの知識を持っている。ロジックを書く力は持っている。しかし、自社の業務のことは知らない。

受注生産で見積番号がどう使われているか。アワーレートをどう計算しているか。この取引先には特殊な納品ルールがあること。検査記録のどの項目が法的に必要で、どの項目が社内管理用なのか。こうした知識はAIの中にはない。

以前の記事で「自社固有の領域は自分たちで理解すべき」と書いた。AIの時代になっても、これは変わらない。むしろ強化される。AIが汎用的な実装力を提供するようになった分、 差がつくのは業務をどれだけ深く理解しているか になる。

→ 中小製造業の内製DXと外注の線引き ──「自社固有」か「汎用」かで決める

コードを書くスキル自体の価値は相対的に下がる。代わりに、業務を理解して正しい問いを立て、AIに的確な指示を出し、出てきた結果を業務の文脈で検証する——この一連の能力が、内製DXエンジニアの中核的な価値になる。

今やるべきことは変わらない

これまで書いてきたことの延長にある。

AIが実装を担う時代に向けて、内製DXエンジニアが今やるべきことは、結局このシリーズで繰り返し書いてきたことと同じになる。

• 業務を深く理解する。 データがどこにあるか、誰がどう使っているか、何が問題なのか。この理解がAIへの指示の精度を決める
• データの持ち方を整える。 AIに読ませるにしても、整っていないデータは使えない。データの文法を正すことは、AI活用の土台でもある
• 小さく試して検証する習慣をつける。 AIが書いたコードを検証する力は、日常の業務で仕組みを試行錯誤する中で身につく

以前の記事で「改善と変化の両方が要る」と書いた。地味な改善で足元を固めること自体が、AIという変化に乗るための準備になっている。

→ AIの具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由

---

このシリーズの他の記事：

• AIの具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由
• 内製DXの開発にAIを使う ── VBAでも「AIに書かせる設計」はできる
• 中小製造業の内製DXと外注の線引き ──「自社固有」か「汎用」かで決める
• 中小製造業の内製DX ── 成否は「話す時間」があるかどうかで決まる

シリーズ記事一覧・著者への相談はこちら →

記事が伝えるのは考え方であって、正解ではない

このシリーズでは、原価管理、生産計画、データの持ち方、ツール選定など、内製DXの具体的な進め方を書いてきた。しかし、記事に書いてあることをそのまま自社に当てはめれば済むわけではない。会社の規模、業種、経営者の方針、現場の空気——すべて違う。最終的には自分で判断する必要がある。

DX担当者の日常は、判断の連続になる。このデータは残すべきか捨てるべきか。この業務はツール化すべきか手作業のままにすべきか。この仕組みは自分で作るべきか業者に頼むべきか。1つ1つの判断に唯一の正解はないが、 判断の基準 を持っているかどうかで、判断の速さとブレの少なさが変わる。

ここでは、自分がDXを進める中で持っている判断基準を書く。DX固有の話というより、仕事全般に使える考え方でもある。抽象的な内容になるが、判断基準というものはある程度抽象的でないと、個別の場面に当てはめられない。

依存先は常に分散させる

1つの仕入先に集中すると、その仕入先が値上げしたとき、廃業したとき、対応が悪くなったときに逃げ場がない。これは調達の基本だが、DXでもまったく同じことが言える。

1つのツールにすべてを載せると、そのツールが使えなくなったとき、業務が止まる。1人の担当者にすべてを任せると、その人がいなくなったとき、何もわからなくなる。1つの業者にすべてを委ねると、その業者の言い値が自社のコストになる。さらに言えば、依存先の実力が自分たちの天井になる。仕入先がそれ以上のことをできなければ、自社もそこで止まる。

以前の記事で「入れ替えられる設計」と書いたのは、この考え方を仕組みの設計に適用したものになる。

→ 中小製造業のIT環境は「入れ替えられる設計」で組む ── OSSとSaaSの使い分け

属人化のトリアージも同じ文脈で読める。属人化の本質は「依存先が1人に集中している状態」であり、即死リスクとは「その1人がいなくなったときに業務が止まる状態」を指している。

→ 中小製造業は「脱属人化」ではなく「属人化のトリアージ」

常に変化を求める

「今のやり方でうまく回っているから変えなくていい」——この判断が正しいことはもちろんある。しかし、自分たちが止まっている間も、周りは動いている。ライバルは常に変化しているので、動かなければ自分たちが遅れる。現状維持を選び続けると、変化する力そのものが衰える。

製造業を取り巻く環境は、ゆっくりだが確実に変わっている。取引先がデータでのやりとりを求めてくる。熟練者が引退する。原材料が高騰する。そのときに動ける体制があるかどうかは、普段から小さな変化を積み重ねているかどうかで決まる。

DXで言えば、「今のExcel運用で困っていないから」と何も手を打たないでいると、データが属人化し、引き継ぎが困難になり、いざ変えようとしたときにはもう手遅れ——という事態になる。困ってから動くのでは遅い。困る前に少しずつ変えておく。

→ 中小製造業のDX、どの手段が正解か ── 再現性のある内製化のレベル感

常にコストと時間を削る方向で考える

安くする。早くする。この2つは業務改善の原動力になる。なぜなら、自分たちより安く・早く提供するライバルは常に現れるからで、これはビジネスの基本原則になる。

重要なのは、大きな投資で一気に変えるのではなく、小さな改善を継続すること。1件の見積にかかる時間を10分短縮する。月次の集計作業を半日から2時間にする。このレベルの改善を積み重ねるほうが、中小製造業のDXでは現実的だし、定着もしやすい。

以前の記事で「管理精度型と工数削減型」を分けて書いたが、工数削減型のDXはまさにこの判断基準の延長線上にある。

→ 中小製造業の内製DXには「管理精度型」と「工数削減型」がある

逆に言えば、コストも時間も変わらない改善は、優先度を下げていい。「デジタル化すること」自体が目的になっていないか、常に問い直す。以前の記事で「『作る』前に『やめる』を考える」と書いたのもこの視点になる。

→ 中小製造業の内製DX ──「作る」前に「やめる」を考える

業務改善と技術革新は別の戦い

小さな改善を積み重ねることと、大きな技術革新が起きることは、別の話になる。

業務改善でExcelの入力を効率化し、集計を自動化し、データの流れを整えても、それだけでは業界を変えるような技術革新には勝てない。AIが業務の前提を変える、クラウドが情報の持ち方を変える——こうした変化が起きたとき、小さな改善の積み重ねは一瞬で意味を失うことがある。

しかし、技術革新はいつ起きるかわからない。そして技術革新が起きていない間は、業務改善の戦いになる。日々のコストを1円でも削り、納期を1日でも縮め、ミスを1つでも減らす。この積み重ねが競争力の差になる期間のほうが、実際には長い。

だから両方やる。日常は業務改善を回しながら、技術革新の動きにはアンテナを張っておく。以前の記事でAIについて「具体的な未来予測はどうでもいい、それでも今から触るべき」と書いたのは、この考え方に基づいている。業務改善を止めてAIに賭けるのではなく、業務改善を続けながらAIにも触っておく。どちらか一方ではなく、両方持っておくことが、どちらの局面でも戦える状態になる。

→ AIの具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由

目的だけを見て、手段にこだわらない

DX担当者が現場とやりとりしていると、「やり方」へのこだわりに出くわすことが多い。この手順で入力したい、この並び順で表示してほしい、このExcelのフォーマットは変えないでほしい。

相手のこだわりを真正面から否定すると、関係が壊れる。しかし、すべてのこだわりに応えていると、仕組みが複雑になり、保守できなくなる。

ここでの判断基準は、 目的に影響するかどうか で切り分けること。入力手順が結果のデータに影響するなら、こだわるべき。表示順がただの好みであれば、相手に合わせればいい。フォーマットの変更が業務フローに波及するなら慎重に進める。

以前の記事で「成否は話す時間があるかどうかで決まる」と書いた。現場と話す中で、相手のこだわりが「目的」なのか「手段」なのかを見極める。手段へのこだわりは、否定せずに受け入れるか、別の方法で目的だけ達成する。

→ 中小製造業の内製DX ── 成否は「話す時間」があるかどうかで決まる

多様性と集中は、時間で切り替える

「選択と集中」は正しい。リソースが限られている中小製造業なら、なおさら集中したほうが成果は出やすい。一方で、「未来は予測できないから多様性を確保しておくべき」というのも正しい。1つに賭けて外れたときのダメージは大きい。

この2つは矛盾しているように見えるが、時間軸で切り替えれば矛盾しない。

まず多様性の段階。何かを選ぶ前に、広く試す。Excel VBAでもいい、GASでもいい、OSSでもいい。触ってみて、自社の業務に合うかどうかを確かめる。この段階では「絞らない」ことが正解になる。

次に集中の段階。試した中から選んだら、そこに集中して改善を続ける。あれもこれも並行して使い続けると、どれも中途半端になる。決めたら、決めたものを磨く。

そして、環境が変わったら再び多様性の段階に戻る。一度決めたことに固執せず、また広く試して、また絞る。このサイクルを回すことが、変化に対応しながら力を集中させる方法になる。

判断基準は「答え」ではなく「方向」

ここに書いたことは、自分の判断基準であって、普遍的な正解ではない。会社の状況が変われば判断も変わるし、自分自身の考えも変わるかもしれない。

ただ、判断基準を持っているかどうかで、迷う時間が減る。基準がないと、1つ1つの判断をゼロから考えることになる。基準があれば、「この場合はこの方向」と即座に仮決定ができて、そこから微調整すればいい。

DX担当者に限らず、中小製造業で仕事をしていると、前例がない判断を求められる場面は多い。そのとき「こういうときはこう考える」という軸を自分の中に持っておくことが、仕事を進める上での地盤になる。

---

このシリーズの他の記事：

• 中小製造業のIT環境は「入れ替えられる設計」で組む ── OSSとSaaSの使い分け
• 中小製造業は「脱属人化」ではなく「属人化のトリアージ」
• 中小製造業の内製DXには「管理精度型」と「工数削減型」がある
• 中小製造業の内製DX ── 成否は「話す時間」があるかどうかで決まる

シリーズ記事一覧・著者への相談はこちら →

DXを進めると、攻撃される面も増える

このシリーズでは、NASでファイルを共有する、VPNで外から社内にアクセスする、サーバーを立てて業務データを集約する、といった話を書いてきた。どれも業務を効率化するための仕組みだが、同時にサイバー攻撃の侵入口を増やしていることになる。

何も導入していなければ、攻撃者から見て「入る場所がない」。しかしVPNを設置すれば、そこが入口になる。NASをネットワークに繋げば、そこが標的になる。DXとは便利にすることだが、便利にした分だけリスクも増える。この構造を意識しているかどうかで、対策のスタンスが変わってくる。

中小製造業にとって一番怖いのはランサムウェア

サイバー攻撃には色々あるが、中小製造業にとって最もダメージが大きいのはランサムウェアになる。社内のファイルを片っ端から暗号化して使えなくし、復号と引き換えに身代金を要求する攻撃。

大企業であれば情報漏洩のほうがダメージが大きいかもしれない。しかし中小製造業の場合、データが暗号化されて業務が止まること自体が致命的になる。見積データが開けない、図面が見られない、受注履歴が消える。出荷が止まれば売上が止まる。復旧までの数日〜数週間、会社が丸ごと機能停止する。

以前の記事で「やられた後にどう戻すか」を書いた。今回はその手前、「そもそもやられないために何をするか」の話になる。

→ 中小製造業のセキュリティは「守り方」より「戻し方」

侵入経路はだいたい決まっている

ランサムウェアの侵入経路は、実はそれほど多くない。警察庁の統計でも、主な経路は次の三つに集中している。

• VPN機器の脆弱性。 最も多い経路。VPN機器のファームウェアにセキュリティ上の穴が見つかり、そこから侵入される。FortinetやPulse Secureなど、中小企業でよく使われている機器で実際に起きている
• リモートデスクトップ（RDP）。 外部からPCに接続するための仕組み。ポートが外部に開いたまま放置されていると、パスワードの総当たり攻撃で突破される
• メール。 不審な添付ファイルやリンクからマルウェアに感染し、そこからランサムウェアが展開される

VPNとRDPで全体の7〜8割を占めている。メールは印象ほど多くなく、むしろネットワーク機器の脆弱性が主戦場になっている。

分からなければ業者に頼む

セキュリティ対策は、このシリーズで書いてきた内製DXとは少し性質が異なる。

内製DXでは「自社固有の領域は自分たちで理解すべき」と書いてきた。しかしセキュリティは自社固有ではない。ネットワーク構成の設計、ファイアウォールの設定、VPN機器の選定と運用——これらは製造業だろうとサービス業だろうと共通の技術領域になる。

→ 中小製造業の内製DXと外注の線引き ──「自社固有」か「汎用」かで決める

だから、セキュリティの設計や運用は業者に任せていい。むしろ任せたほうがいい場面が多い。ただし、以前の記事でも書いた通り、丸投げと任せることは違う。業者に「セキュリティお願いします」とだけ言うのではなく、自分たちが 何を守りたいのか は伝えられるようにしておく。

• うちの業務データはここにある
• 最悪止まっても1日で復旧できれば耐えられる
• バックアップはここに取っている

こういう情報を自分たちで把握しておくだけで、業者との会話が成り立つようになる。

自分でやるなら、最低限ここから

業者に頼むほどではない、あるいは自分でできる範囲でまずやりたい、という場合。中小製造業のIT環境には「ランサムウェア以前の問題」が山ほどあるので、まずそこから手をつける。

セキュリティソフトをインストールして、アップデートを適用する。 セキュリティソフトの期限が切れている、あるいは最初から入っていない。Windows Updateも「再起動が面倒」「更新すると遅くなる」で何年も止めている——こういう環境は珍しくない。Windows標準のDefenderでも、有効になっていて定義ファイルが最新であれば基本的な防御はできる。ソフトを入れて終わりではなく、OSも含めてアップデートを止めないことが重要になる。既知の脆弱性を放置するリスクのほうがはるかに大きい。

利用しているWebサービスのパスワードを複雑にする。 メールのパスワードが全員共通、PCのログインパスワードが全台共通、あるいはパスワードなしで使っている。こういう状態では、退職者でもそのままアクセスできるし、誰がどの操作をしたかも追えない。メール、クラウドストレージ、業務システム、会計ソフト——ログインが必要なサービスすべてについて、推測しにくいパスワードを個別に設定する。パスワードマネージャーの導入まで考える必要はない。まず「共通をやめる」だけで大きく変わる。

NASやネットワーク機器のパスワードも複雑にする。 NAS、WiFiアクセスポイント、スイッチ、プリンター。こうしたネットワーク機器にも管理画面があるが、初期パスワードのまま、あるいはWiFiのパスワードが「123abc」のような文字列で運用されていることが多い。これらの機器はネットワーク上でつながっているので、一つが突破されると他にも影響が及ぶ。管理画面にログインして、パスワードを変更する。WiFiのパスワードも同様になる。

UTMやルータなど外部ネットワークと接する部分は、専門家に頼むか、マニュアルを見ながら慎重に設定する。 ここまでの対策は社内の衛生管理であり、自分でできる範囲の話。しかしUTM（統合脅威管理）やルータは、インターネットと社内ネットワークの境界に立つ機器になる。ファイアウォールの設定、ポートの開閉、VPN機器のファームウェア更新——この領域は設定を一つ間違えると外部から丸見えになる。自信がなければ業者に頼む。自分でやるなら、メーカーのマニュアルやサポートページを確認しながら慎重に進める。「なんとなく動いているからいいだろう」で放置するのが一番危ない。

完璧を目指さない

ここに書いたことを全部やっても、ランサムウェアを100%防げるわけではない。防御を固めても、すり抜けはゼロにならない。

だからこそ、以前の記事で書いた「やられた後にどう戻すか」が重要になる。バックアップをネットワークから切り離した場所に持ち、復旧手順を把握しておく。防御と復旧は両輪で、どちらか片方だけでは機能しない。

→ 中小製造業のセキュリティは「守り方」より「戻し方」

今回の記事は「やられる前の最低限の備え」。あの記事は「やられた後の最低限の備え」。この二つをセットで考えることが、中小製造業にとって現実的なセキュリティの全体像になる。

---

このシリーズの他の記事：

• 中小製造業のセキュリティは「守り方」より「戻し方」 ── バックアップを自分で握る
• 中小製造業の内製DXと外注の線引き ──「自社固有」か「汎用」かで決める
• 中小製造業のIT環境は「入れ替えられる設計」で組む ── OSSとSaaSの使い分け

シリーズ記事一覧・著者への相談はこちら →

食わず嫌いされているスプレッドシート

以前の記事で、Google Workspaceのデータ主権の問題について書いた。機能だけ借りてデータは手元に持つ、という使い分けを提案した。

→ 中小製造業に Google Workspace は必要か

ただ、リスクがあるから使うなという話ではない。開発プラットフォームとして見ると、Googleスプレッドシート＋GAS（Google Apps Script）にはExcel VBAにはないメリットが確実にある。今回はその具体的な得意・不得意の話をしたい。

まず言っておきたいのは、スプレッドシートは食わず嫌いされていることが多いということ。サービスが出始めた頃は確かに使い物にならなかった。Excelと比べて遅い、関数が少ない、操作感が違う。その頃の印象を引きずっている人がまだ多い。

しかし今のスプレッドシートは相当進化している。例えば、1つのセルに関数を入れれば末尾の行まで自動で展開されたり、別のスプレッドシートからデータを引っ張ってこられる関数がある。他にも同時編集ができるので「誰かが開いているから編集できない」がないなど、Excelにはない便利さが確実にある。

ただしプラットフォームごと入る必要がある

スプレッドシートとGASの話をする前に、大前提がある。 Google Workspaceはチーム単位で導入しないとメリットが出にくい。

全員がMicrosoft Officeを使っている中で、1人だけGoogleスプレッドシートを使っても、ファイルのやりとりのたびに変換が発生する。同時編集もできない。GASで作った仕組みも、Googleアカウントを持っていない人には使えない。

使えないわけではないが、メリットが限定される。スプレッドシート＋GASの強みは、チーム全員がGoogle Workspace上にいる前提で成立する。

導入を検討するなら、外出やリモートワークが多い会社は相性がいい。ブラウザさえあれば同じファイルにアクセスできるので、場所を選ばない。逆に全員が同じ事務所にいて、ローカルのExcelで十分回っているなら、あえて乗り換える理由は薄い。

Excel VBAとは得意・不得意が逆

このシリーズではExcel VBAを中心に書いてきた。スプレッドシート＋GASはその「クラウド版」のような存在だが、得意・不得意がきれいに逆になる。

→ 中小製造業の内製DX ── Excel VBAで済む領域と、専用言語で作るべき領域

Excel VBAが得意でGASが苦手なこと：大量データの処理。 Excelは手元のPCで動くので、数万行のデータでもストレスなく扱える。VBAの処理も、PCのスペックが許す限り一気に回せる。

スプレッドシートはブラウザ上で動くため、数千行あたりからもたつきが出る。描画が非同期で、セルに値を入れてもワンテンポ遅れて反映されることがある。Excelに慣れた人にとっては、この遅延が地味にストレスになる。GASにも実行時間の制限がある。処理が長くなるとタイムアウトする。VBAなら気にしなくていい「トリガー」や「バッチ処理」という概念を意識して設計する必要が出てくる。

GASが得意でExcel VBAが苦手なこと：共有と定時実行。 スプレッドシートは最初から共有前提で作られている。同時編集、権限管理、変更履歴が標準で付いている。VBAのExcelファイルで「共有ブック」を使ったことがある人なら、あのつらさとの差は歴然としている。

GASのトリガー機能も大きい。「毎朝8時にこの処理を実行する」がコード数行で実現できる。VBAで同じことをやるには、PCを常時起動してタスクスケジューラを設定する必要がある。

	Excel VBA	スプレッドシート＋GAS
大量データ（数万行〜）	得意	苦手（数千行で重くなる）
処理速度	PC性能次第で高速	実行時間制限あり
同時編集	苦手	標準機能
定時実行	環境構築が必要	トリガーで簡単
環境構築	バージョン差・設定の罠あり	ブラウザだけで動く
オフライン	問題なし	基本的にネット必須

データが増えると別の道具が必要になる

Google Workspace環境で開発を進めていくと、ある時点で壁にぶつかる。データ量の壁になる。

スプレッドシートで数千行のデータを集計するGASを書いて、トリガーで毎朝実行する。最初は快適に動く。しかしデータが増えてくると、処理が重くなり、タイムアウトに引っかかるようになる。

Excel VBAなら、同じデータ量の増加に対して「PCのメモリを増やす」「処理を最適化する」で対応できる。しかしスプレッドシート＋GASでは、プラットフォーム側の制約を超えられない。

結果として、Google Workspace環境ではデータ量が増えるとBigQueryやAppSheetのような専用サービスにデータ処理を移行する流れになりやすい。これは3層モデルで言えば第三層への移行と同じ構造だが、移行先がGoogleのエコシステム内に限定されやすいという点が異なる。

→ 中小製造業のExcel業務が「1シート」で止まる理由 ── 関数の限界と次の一歩

Excel VBAの場合、第三層への移行先はC#やPythonなど、プラットフォームに依存しない選択肢が取れる。ここに、以前の記事で書いた「入れ替えられる設計」の考え方がつながる。

→ 中小製造業のIT環境は「入れ替えられる設計」で組む ── OSSとSaaSの使い分け

ファイル形式の選択は思った以上に重い

技術的な得意・不得意とは別に、もう一つ考えておくべきことがある。 データをどのファイル形式で蓄積していくか という問題になる。

Google Workspaceを数年運用すると、スプレッドシート、ドキュメント、スライド、GASのスクリプト——すべてがGoogleの形式でデータが積み上がっていく。お試しで使っている段階なら乗り換えは簡単だが、数年分の業務データとロジックが載った状態から別のプラットフォームに移行するのは、現実的にはかなり厳しい。

ただし、これはGoogleだけの問題ではない。Microsoft 365に全部載せても同じことが起きる。Excelのマクロ付きファイル、SharePointのワークフロー、Power Automateの設定——どのプラットフォームでも、深く使えば使うほど移行コストは上がる。Googleが潰れるリスクを心配するなら、Microsoftにも同じことは言える。

大事なのは、どちらが安全かではなく、 データをプラットフォーム固有の形式に閉じ込めすぎないこと になる。以前の記事で「データの文法」として書いたCSVで出力できる形でデータを持つ、という原則はここでも効く。スプレッドシートでもExcelでも、業務データ本体はCSVやDBに落とせる構造にしておけば、プラットフォームの乗り換えが必要になったときにデータだけは救える。

→ Excelのデータは「いつでもDBに移せる形」で持つ ── データの文法という考え方

どちらを選ぶかは働き方で決まる

結局のところ、Excel VBAとスプレッドシート＋GASのどちらが優れているかという話ではない。

事務所にいる時間が長く、手元のPCでデータを扱う業務が中心なら、Excel VBAのほうが自然。 PCのパワーをフルに使える。データ量の制約も緩い。オフラインでも動く。

外出やリモートが多く、複数拠点でデータを共有する必要があるなら、スプレッドシート＋GASが向いている。 ブラウザさえあればどこでも使える。同時編集とトリガーが最初から使える。

中小製造業の場合、工場と事務所が一体になっていて、ほぼ全員が同じ場所で働いているケースが多い。そういう環境ではExcel VBAのほうが素直にハマることが多い。このシリーズでExcel VBAを中心に書いてきたのは、そういう現場が想定読者だからになる。

ただ、拠点が複数あったり、営業が外で動く時間が長かったりする会社なら、Google Workspace＋GASのほうが合う場合もある。道具の選択は、技術の優劣ではなく、自分たちの働き方に合っているかどうかで決めるべきものになる。

---

このシリーズの他の記事：

• 中小製造業に Google Workspace は必要か
• 中小製造業の内製DX ── Excel VBAで済む領域と、専用言語で作るべき領域
• 中小製造業のIT環境は「入れ替えられる設計」で組む ── OSSとSaaSの使い分け

シリーズ記事一覧・著者への相談はこちら →

Excelの外にも道具がある

以前の記事で、Excelの中にも複数の層があると書いた。ワークシートの操作、標準の関数、VBAでのシート操作、VBAで作るオリジナル関数。これらを重ねて使うのが現実的なやり方になる。

→ 内製DXの開発にAIを使う ── VBAでも「AIに書かせる設計」はできる

しかし、内製エンジニアの仕事は定型業務の仕組みを作ることだけではない。むしろ、仕組み化した後のほうが「想定外の問い合わせ」が増える。

「先月の不良率が跳ねたんだけど、品番別に見たい」「この顧客、去年と比べて発注ペース落ちてない？」「基幹システムから出力したデータ、フォーマットがおかしいから整形してほしい」

こういう突発的な調査・分析は、あらかじめ仕組み化しておくことが難しい。そのつど発生して、そのつど違う切り口が求められる。定型業務ならVBAやシステムで自動化すればいいが、不定形の仕事には「手で道具を使い分ける力」が要る。

こういうときに自分が使っているのは、大きく分けて3つの道具になる。Excel、テキストエディタ、SQL。どれも高価でも難解でもない。しかしこの3つを組み合わせると、突発的なデータ加工業務はほぼカバーできる。

テキストエディタ：大きなファイルと正規表現

Excelには行数の上限がある。100万行を超えるデータは開けない。しかし業務データがそこまで大きくなることは少ないから、普段は問題にならない。

テキストエディタが必要になるのは、Excelとは違う操作が求められるときになる。

正規表現が使える。 「数字3桁＋ハイフン＋数字4桁のパターンを探す」「特定の文字列の前後を一括で置換する」といった、パターンに基づいた検索・置換ができる。Excelの検索置換では対応しにくい柔軟なテキスト操作が可能になる。

矩形選択ができる。 通常のテキスト選択は行単位だが、矩形選択なら列方向に範囲を選んでコピー・削除・挿入ができる。固定長のテキストデータを切り出すとき、特定の位置の文字列だけ抜き出したいときに使える。

大きなファイルをそのまま開ける。 数百MBのログファイルやCSVでも、専用のテキストエディタなら固まらずに開ける。中身を確認して、必要な部分だけ切り出してからExcelに持っていく、という使い方になる。

自分はEmEditorを使っているが、大きなファイルを軽快に開けて正規表現と矩形選択ができるエディタなら何でもいい。道具は何を使うかより、何ができるかのほうが大事になる。

SQL：集計と突合の言語

SQLはデータベースの操作言語として知られているが、内製DXの文脈では「集計と突合の道具」として使う。

Excel関数でも集計はできる。SUMIFSで条件付きの合計、COUNTIFSで条件付きのカウント。しかし、条件が複雑になってくると関数の組み合わせでは限界が来る。

グループ化と集計。 「品番ごと・月ごとの出荷数量を集計して、前年同月と比較する」。こういう多段階の集計は、SQLなら数行で書ける。Excelのピボットテーブルでもできるが、条件が増えるほどSQLのほうが見通しがいい。

複数テーブルの突合。 「発注データと入荷データを発注番号で突合して、未入荷のものだけ抽出する」。以前の記事で、2つのデータをつなげる瞬間に壁が来ると書いた。SQLのJOINは、まさにこの壁を越えるための道具になる。

→ 中小製造業のExcel業務が「1シート」で止まる理由 ── 関数の限界と次の一歩

条件の組み合わせ。 「過去6ヶ月の注文実績があり、かつ今月の受注がなく、かつ前年同月には受注があった顧客の一覧」。こういう条件の組み合わせは、SQLのWHERE句で書くと明快になる。関数で同じことをやろうとすると、何重にもネストした式になって読めなくなる。

SQLを使うには何らかのデータベースが必要になるが、大掛かりなシステムは要らない。ExcelのデータをCSVで書き出して、SQLiteのような軽量なデータベースに読み込ませれば、すぐにSQLで操作できる。VBAからSQLを実行する方法もある。

AI：道具箱の使い方が変わる

ここまで書いたテキストエディタやSQLは、自分で操作を覚える必要があった。正規表現の書き方、SQLの構文、それぞれの道具に固有のスキルが要る。

AIの登場で、この前提が変わりつつある。

「このCSVを品番別に集計するSQL書いて」「この形式のテキストから日付だけ抜き出す正規表現を教えて」——こういう聞き方をすれば、AIがコードやパターンを書いてくれる。道具の操作方法を全部覚えていなくても、「何をしたいか」を言語化できれば、AIが道具を代わりに操ってくれる。

→ 内製DXの開発にAIを使う ── VBAでも「AIに書かせる設計」はできる

これは道具箱のハードルを大きく下げる。以前なら「SQLを覚える時間がない」で止まっていた人でも、AIに聞きながら使えば結果にたどり着ける。道具箱に入っている道具の数は同じでも、使いこなせる人の裾野が広がる。

ただし、AIが出した結果が正しいかどうかを判断するのは自分になる。業務を理解していなければ、AIの出力が合っているかどうかを検証できない。道具の敷居は下がっても、使う人間の理解力が要ることは変わらない。

仕組み化と道具箱の役割分担

内製エンジニアの仕事には2つの面がある。

繰り返す業務は仕組みにする。 毎月の集計、定期的なレポート、日常の入力業務。これらはVBAやシステムで自動化して、自分の手から離す。以前の記事で書いた「Excelでも回せる」というのは、この定型業務の仕組み化の話になる。

→ 中小製造業のデータ加工業務は、Excelでも回せる

突発的な調査・分析には道具箱で対応する。 「今すぐこのデータを調べてほしい」「この2つのデータを突合したらどうなる？」——こういう不定形の仕事は、仕組み化のしようがない。そのつど手持ちの道具を組み合わせて対応する。

テキストエディタでCSVを整形して、SQLで集計して、結果をExcelに貼り付けて仕上げる。こういう連携は定型の手順ではなく、そのときの課題に応じて組み立てるものになる。

天井は道具ではなく、自分の理解力

この道具の組み合わせで「ほぼなんでもできる」と書いたが、正確に言えば「自分が理解できる範囲のことは、ほぼなんでもできる」になる。

標準偏差を使った分析が必要だとしても、標準偏差の意味を自分が理解していなければ、道具がいくらあっても正しい分析はできない。逆に、やりたいことの意味を理解していれば、たいていの処理はこの3つの道具のどれかで実現できる。

以前の記事で「管理精度の天井は経営者の判断力で決まる」と書いた。道具の話も同じ構造になる。 天井を決めるのは道具の性能ではなく、使う人間の業務理解力。

→ 中小製造業のDX、管理精度の「天井」はどこにあるか ── 経営者の判断力という上限

高価なBIツールや分析プラットフォームを導入しても、使う側が「何を見たいか」「なぜその数字が重要か」を理解していなければ、ダッシュボードは飾りになる。逆に、ExcelとテキストエディタとSQLという安価な道具でも、業務を理解した人間が使えば、経営判断に必要な情報は十分に引き出せる。

これが内製エンジニアの価値

以前の記事で、内製DXにおける道具選びの3層モデルを整理した。市販ソフト、Excel VBA、専用言語。

→ 中小製造業の内製DX ── Excel VBAで済む領域と、専用言語で作るべき領域

定型業務はこの3層のどこかで仕組み化すればいい。しかし仕組み化できない突発的な仕事——調査、分析、トラブル対応——は、どの層にも収まらない。そこを埋めるのが、今回の道具箱の話になる。

内製エンジニアの価値は、定型業務を仕組み化する力だけではない。「急ぎで調べてほしい」と言われたときに、手持ちの道具で素早く対応できる力。業務を理解した上で、適切な道具を選んで組み合わせ、必要な情報を引き出す。大きなシステムに頼らず、現場の課題にその場で対応する。

道具そのものは誰でも手に入る。Excel、テキストエディタ、SQLの入門書はいくらでもある。しかし 「この業務にはどの道具を使えばいいか」を判断できるのは、業務を知っている人間だけ になる。道具を知っているだけでも、業務を知っているだけでも足りない。両方を持っていることが、内製エンジニアの強みになる。

---

このシリーズの他の記事：

• 内製DXの開発にAIを使う ── VBAでも「AIに書かせる設計」はできる
• 中小製造業のExcel業務が「1シート」で止まる理由 ── 関数の限界と次の一歩
• 中小製造業の内製DX ── Excel VBAで済む領域と、専用言語で作るべき領域

シリーズ記事一覧・著者への相談はこちら →