タグ: 中小製造業DX

投稿日:

中小製造業のExcelデータ、帳票型でも「行列が揃っていれば」救える

帳票型のデータは、どこにでもある

以前の記事で、Excelのデータは「いつでもDBに移せる形」で持つべきだと書いた。1行1件で上から下に積んでいく、いわゆる縦持ちの形式。データベースに入る形で持っておけば、集計もVBAでの自動化もスムーズにできる。

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

この考え方自体は変わっていない。しかし現実の中小製造業を見ると、この形式でデータを持っている会社はほとんどない。

圧倒的に多いのは、帳票型のデータ。月別にシートが分かれている実績表、日付ごとの日報シート、案件別のブック。横軸に日付や月が並び、縦軸に品目や工程が並ぶクロス集計のレイアウト。Excelが存在する限り、この形式はなくならないだろう。

帳票型が選ばれる理由

帳票型がこれほど広く使われているのには理由がある。

一覧性が高い。 月の実績を一枚のシートで見渡せる。どの品目がどの日に何個出たのかが、目で追える。縦持ちのデータベース形式だと、同じ情報を見るためにフィルタやピボットテーブルを使う必要がある。

そのまま印刷できる。 現場に紙で貼り出す文化がある製造業では、これは大きい。縦持ちのデータを印刷しても、そのままでは使い物にならない。

入力がしやすい。 今日の実績を今日のセルに入れるだけ。行を追加する必要もないし、日付を毎回入力する必要もない。

つまり帳票型は、人間が日常的にデータを入力し、確認し、共有するための形式としては合理的。以前の記事で否定したかったのはこの形式そのものではなく、これを「データの唯一の保管場所」にしてしまうことだった。

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

救えるかどうかの分かれ目は「行列の固定」

帳票型のデータが社内に何年分も蓄積されている。この現実に対して、自分の考えはこうなる。

行と列のレイアウトが固定されていれば、データは救える。

たとえば月次の生産実績表。毎月同じフォーマットで、A列が品目名、B列以降が日付ごとの数量。この形式が12ヶ月×数年分あったとしても、VBAやスクリプトで一括して縦持ちに変換できる。セルの位置が決まっているなら、プログラムは確実にデータを拾える。

レイアウトが固定されているなら、帳票型から縦持ちへの変換は技術的には難しくない。1シートから読み取るロジックを一度書けば、あとは全シートに同じ処理を回すだけになる。

一方、自由配置のシートは救えない。

セル結合が多用され、データの位置がシートごとに違い、余白や注釈が任意の場所に入っている。こうなるとプログラムで読み取る前提が成り立たない。人間が目で見れば情報はわかるが、機械的にデータを拾うことは不可能に近い。

この線引きは明確で、レイアウトが固定されているか、されていないか。これだけで、過去データが資産になるか、ただのアーカイブで終わるかが決まる。

今すぐやるべきことは一つ

過去のデータを今すぐ全部変換する必要はない。以前の記事でも書いたが、崩れたデータを遡って直す作業は現実的ではないことが多い。

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

しかし、これだけは今すぐやったほうがいい。

帳票型シートのレイアウトを固定する。

具体的には：

  • 行と列の構造を統一する。 今月のシートと来月のシートで、列の並びや行の数が変わらないようにする
  • セル結合を使わない。 結合セルはプログラムから見ると位置がずれる原因になる。見た目を揃えたいなら「選択範囲内で中央」を使う
  • データ領域と見た目の装飾を分ける。 タイトルや罫線、色は好きにしていい。ただしデータが入るセルの位置は動かさない
  • テンプレートから複製する。 新しいシートやブックを作るとき、毎回ゼロから作らず、テンプレートをコピーする

帳票型をやめる必要はない。帳票型のまま、レイアウトだけ揃える。これだけで、将来データを吸い出したくなったときの難易度が劇的に下がる。

変換は後からでいい

レイアウトが固定された帳票型データがあれば、必要になったタイミングで縦持ちに変換できる。

たとえば「過去2年分の生産実績を製品別に集計したい」となったとき、24枚の月次シートから品目と数量をVBAで読み取って、1行1件のデータシートに出力する。レイアウトが固定されていれば、この変換処理は数十行のコードで書ける。

全部を一度に変換する必要もない。使うデータだけ、使うタイミングで変換すればいい。レイアウトさえ揃っていれば、「いつでも変換できる」という状態を維持できる。これは以前の記事で書いた「いつでもDBに移せる形で持つ」のもう一つの形と言える。理想的な縦持ちではないが、変換可能な状態を保っているという点で、データの再利用性は確保されている。

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

自由配置のデータにも手段はゼロではない

レイアウトが崩れたデータは救えないと書いたが、最近はAIによるOCR・データ抽出の精度が上がっている。ExcelやPDFの帳票をAIに読ませて、テーブル形式に変換するといった手段は選択肢として存在する。

ただし、VBAで固定レイアウトを読み取る方法と比べると、確実性が違う。VBAはセルの位置を指定して読むだけだから、100回やれば100回同じ結果が返る。AIによる抽出は精度が高くなってきているとはいえ、読み取りミスや解釈の揺れが起きる可能性がある。件数が多いほど、目視での確認コストが積み上がる。

「どうしても過去データを救いたいが、レイアウトが揃っていない」という場面では検討する価値はある。しかし、これから作るデータのレイアウトを揃えるほうが、はるかに確実でコストも低い。AIは最後の手段であって、最初の戦略にはならない。

帳票型を否定しない、自由配置を否定する

帳票型のExcelは、現場の運用としては合理的な選択肢。そのまま使い続けて構わない。

問題は帳票型かどうかではなく、データの位置が決まっているかどうか。行列が固定されていれば、いつでもプログラムでデータを拾える。自由配置になっていると、そのデータは人間が目で見ることしかできない。

今すぐデータの持ち方を変える必要はない。ただ、レイアウトだけは揃えておく。帳票型のシートをテンプレートから複製するだけでいい。この小さな習慣が、将来データを活用したくなったときに、選択肢を残してくれる。

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

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

投稿日:

ローコード・ノーコードは中小製造業に合うのか ── 市民開発とExcel VBAの境界線

ローコード・ノーコードの広がり

ここ数年、ローコード・ノーコードという言葉を聞く機会が増えた。Power Apps、kintone、Appsheet。プログラミングなしで業務アプリが作れるという触れ込みで、大手企業を中心に導入が進んでいる。

背景にあるのは「市民開発」という考え方で、IT部門ではなく現場の担当者が自分で業務ツールを作る。これ自体は理にかなっている。業務を一番よく知っている人が、自分の手で仕組みを作れるなら、それが最も速い。

ただ、この流れを見ていて一つ面白い矛盾がある。

属人化の扱いが揺れている

DXの文脈では「属人化を解消しましょう」がほぼ定番の提言になっている。特定の人しかできない業務はリスクだから、標準化・マニュアル化しましょう、と。

一方で、市民開発は「現場の個人がツールを作る」ことを推奨している。作った人がいなくなったらどうするのか、という問いに対する答えは、正直あまり見かけない。

これは別に業者の言っていることが間違っているわけではない。属人化の解消と市民開発は、対象としているレイヤーが違う。業務プロセスの属人化は確かにリスクだが、ツールを作る能力が特定の人に集中すること自体は、中小企業では避けようがない現実でもある。以前の記事で「属人化のトリアージ」として整理したが、何を標準化して何を属人のまま許容するかは、一律に決められる話ではない。

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

ローコードが選ばれる合理的な理由

ローコード・ノーコードが大手企業で支持されている理由は、技術的なハードルの低さだけではない。もっと実務的な理由がある。

配布と改修の管理ができる。 ここがExcelとの最大の違いだと思っている。Excelで作った業務ツールは、ファイルをコピーすれば誰でも使える。しかし裏を返せば、配布したファイルを誰かが勝手に改修しても止められない。数式を壊す、マクロを無効にする、構造を変える。こういったことが日常的に起きる。

ローコード・ノーコードのプラットフォームでは、アプリはサーバー上で一元管理される。利用者はアプリを「使う」だけで、中身を触ることはできない。改修できるのは作成者だけ。この構造は、数十人〜数百人規模の組織でツールを展開するときに大きな意味を持つ。

誰が何を使っているかが見える。 IT部門の立場からすると、社内にどんなツールがあり、誰が使っているかを把握できることは重要になる。Excelファイルが各自のPCに散らばっている状態では、この把握がほぼ不可能。ローコード・ノーコードのプラットフォームなら、管理画面からアプリの一覧、利用状況、作成者が確認できる。

権限管理が標準装備されている。 閲覧だけの人、編集できる人、管理者。こうした権限の切り分けがプラットフォーム側で用意されている。Excelファイルに対して同じことをやろうとすると、フォルダのアクセス権やSharePointの設定など、別のレイヤーで対応する必要がある。

こうした特徴は、組織としてのIT統制を求められる環境では合理的な選択になる。大手企業がローコード・ノーコードを採用する背景には、こうした管理面のメリットが大きい。

データの持ち方という視点

ローコードのプラットフォームにデータを預けるということは、そのプラットフォームに依存するということでもある。以前の記事で「データが特定のツールに閉じ込められない状態を維持する」と書いたが、この原則はローコードにも当てはまる。

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

ただ、これはローコードの欠点というより、トレードオフとして理解したほうがいい。Excelファイルが各自のPCに散らばっている状態は、確かにデータは手元にあるが、統制が取れていない。ローコードのプラットフォームにデータを集約すれば統制は取れるが、プラットフォームへの依存が生まれる。

大手企業がこのトレードオフでプラットフォーム側を選ぶのは、組織規模を考えれば自然なことだと思う。数百人の社員が使うツールのデータが個人のPCに散らばっていたら、それこそ管理不能になる。

中小製造業ではどうか

では中小製造業、特に多品種少量の受注生産をやっている会社ではどうか。

自分の結論としては、ローコード・ノーコードが最適な選択肢になるケースはかなり限られると考えている。

組織の規模が違う。 ローコードの管理面のメリットは、ある程度の人数がいて初めて効いてくる。社員数十人の会社で、ツールを使う人が5〜10人程度なら、Excelファイルの管理で困る場面はそこまで多くない。誰が何を使っているかも、声をかければわかる距離感にある。

業務の変化速度に対する柔軟性。 多品種少量の受注生産では、業務プロセスが頻繁に変わる。ローコード・ノーコードは「用意された部品の組み合わせ」で作るため、プラットフォームが想定していない要件に当たると途端に行き詰まる。Excelなら力技でも何とかなる場面が、ローコードだと「できない」で終わることがある。

コストの問題。 ローコード・ノーコードはユーザー数に応じたライセンス費用がかかる。月額数百円のプランもあるが、業務で本格的に使おうとすると一人あたり数千円は必要になる。中小企業にとってこの固定費は軽くない。Excelは既にライセンスがあるケースがほとんどで、追加コストがかからない。

データの主権。 これは規模に関係なく重要な話で、ローコードのプラットフォームに業務データを預けるということは、そのプラットフォームが値上げしたり、サービスを終了したりしたときに、自社のデータと業務ロジックが人質になるリスクを抱えるということ。中小企業にとって、このリスクは大手以上に重い。代替手段を検討する体力が限られているからこそ、データは自分の手元に置いておきたい。

「管理のしやすさ」と「自由度」のバランス

結局のところ、ローコード・ノーコードとExcel VBAの選択は、組織として何を優先するかの問題になる。

管理のしやすさを優先するなら、ローコード・ノーコード。 配布管理、権限管理、利用状況の把握。組織としてのIT統制が求められる環境では、これらの機能が標準で備わっていることの価値は大きい。

自由度とデータの主権を優先するなら、Excel VBAや内製プログラミング。 業務の変化に柔軟に対応でき、データは自分の手元にある。ただし管理は自分たちでやる必要がある。

中小製造業の場合、組織の規模と業務の特性を考えると、後者のほうが合っていることが多い。Excelの「誰でも触れてしまう」という特性は、裏を返せば「誰でも直せる」「誰でも改善できる」ということでもある。この柔軟さは、多品種少量の受注生産で日々変化する業務に対応するうえで、むしろ強みになる。

管理面の不安があるなら、以前の記事で書いたようにExcelのシート構造を整理し、データシートとUIシートを分離するだけでも、かなりの部分は解消できる。ツールが大きくなって管理が追いつかなくなったら、そのときはローコードではなく、C#やPythonなどの専用言語にステップアップするほうが、長期的にはデータの主権を保ったまま保守性を確保できる。

→ 中小製造業に「脱Excel」は必要か

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

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

投稿日:

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

小回りのきく業者は中小製造業の味方

中小製造業にとって、大手SIerは現実的な選択肢になりにくい。予算規模が合わない上に、パッケージ化された提案は受注生産・多品種少量の現場にそのまま当てはまらないことが多い。

自分の経験でも、中小の現場でうまくいっているのは、小規模で小回りのきく業者との付き合いだった。いわゆる「御用聞き」タイプの業者で、こちらの事情を理解した上で、必要なときに必要なだけ対応してくれる。電話一本で動いてくれるスピード感は、中小にとって大きな価値がある。

ただし、この「何でもやってくれる便利さ」には落とし穴がある。

線引きの基準は「自社固有かどうか」

業者に頼むとき、こちらが内容を理解した上で任せているのと、よくわからないから全部お願いしているのとでは、まったく意味が違う。前者は対等なパートナーとして付き合える。後者は、提案の良し悪しも判断できないまま、言い値で進むことになる。

では、丸投げにならないために全部を理解すべきかというと、そうではない。

たとえばネットワークやサーバーのインフラ。自分のところでもインフラは業者に完全に任せている。インフラの知識は汎用的なもので、製造業だろうとサービス業だろうと基本は同じ。ここはプロに任せた方が効率がいい。

一方、自社の見積もりの構造、工程の流れ、原価の考え方、データの持ち方。これらは自社固有の知識で、外の人間がどれだけ優秀でも、本質的には社内の人間にしかわからない。

汎用的な領域は業者に任せていい。自社固有の領域は、自分たちで理解していなければならない。

理解がないと「値段」でしか選べない

自社固有の領域を理解していないとき、外注先をどう選ぶか。中身がわからなければ、比較できるのは値段だけになる。

ある会社から相談を受けた話。以前、別の外注にExcel VBAと専用ソフトの組み合わせで作ってもらった仕組みがあり、それをExcel VBAだけで作り直してほしいという依頼だった。前の外注はかなり安価でやっていたらしい。今回は「専用ソフトの部分が要らないぶん、もっと安くできるだろう」という前提での相談だった。

その会社の業務にとって重要なロジックが入っている仕組みだった。にもかかわらず、「やりたいことは説明できるから、実装だけしてもらえればいい」という感覚で話が進んでいた。

→ 手作業でできることしかシステムにできない ── 中小製造業の内製DXの正しい順番

この話に限らず、自分が何を頼んでいるかの解像度が低いと、値段の比較しかできなくなる。 「安い方がいい」は、中身を評価する基準がないときに出てくる判断軸。 そして安さで選ぶと、相手もそれなりの対応になる。結果として、必要な情報がこちらに残らないまま納品だけが行われ、次もまた別の業者に値段で発注する——というループに入る。

これは別の記事で書いた「値決めできない」問題の裏面でもある。自社の製品に値段をつけられないのと、他人の仕事を値段でしか評価できないのは、同じ構造の問題。 理解がなければ、売る側も買う側も値段でしか判断できなくなる。

→ 中小製造業の「値決めできない」問題に、内製DXはどこまで効くか

知識のロックインが一番深い

自社固有の領域を理解しないまま外注を続けると、「業者が作ったシステムを、業者にしか直せない」という依存関係が生まれる。技術的なロックインよりも、 知識のロックインの方が根が深い。 技術は乗り換えられるが、自社業務の理解を外に持っていかれると、取り戻すのが難しくなる。

見落としがちなのが、業者との関係が特定の担当者に依存しているケース。自分が見た例では、こちらの担当者が異動で変わったことで、業者との暗黙の前提がすべて崩れた。やり取りの経緯や判断の背景が担当者の頭の中だけにあると、人が変わった瞬間にすべてが失われる。

→ 中小製造業の仕入先との関係は、担当者の頭の中にしかない

逆に、自社固有の領域を自分たちで扱えるようになると、業者との付き合い方が変わる。「何をやってほしいか」を明確に伝えられるので、業者は本来の強みである技術力とスピードを発揮しやすくなる。依存が協業に変わる。

ポイントは、業者の規模ではなく 知識がどこにあるか になる。大手がドキュメントを残してくれても、読んで理解できる人が社内にいなければ紙の束でしかない。小規模の業者に丸投げして納品物だけ受け取るのも、ベンダーロックインの小規模版になるだけ。

100%内製ではなく「8割内製、2割外部」

内製とは、全部を自分でやることではなく、自社固有の部分を自分で理解・管理できる状態のこと。

100%内製を目指すから非現実的に見える。コモディティ業務はパッケージで割り切り、インフラは業者に任せる。自社の見積もり構造、工程の流れ、原価の考え方といった固有の領域は、内製を軸にする。

自社に必要な8割は内製でカバーし、残り2割は外部の力を借りる。そしてその2割の相手が、丸投げ先ではなく、こちらの事情を理解して一緒に作れる人間であれば、知識も社内に残る。この組み合わせが、中小製造業の体力に合った現実解だと考えている。

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

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

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

投稿日:

手作業でできることしかシステムにできない ── 中小製造業の内製DXの正しい順番

システム化から始めたがる問題

内製DXの相談で多いのが、「この業務をシステム化したい」という話から始まるケースになる。気持ちはわかるが、ここにはよくある落とし穴がある。

「システム化したい」が先に来ると、ツール選定や技術検討から始まってしまう。どの言語で作るか、Excelで済むかデータベースが要るか、クラウドか社内サーバーか。しかし、その業務のロジックがそもそも明確でなければ、どんな道具を選んでも作れない。

システムとは、人間がやっていることを機械に置き換えるものになる。置き換えるためには、何をどういう順番で、どういう条件で判断しているかが明確でなければならない。つまり手作業でできていないことは、システムにもできない。

手作業でできない＝ロジックがわかっていない

「手作業ではやっているが、大変だからシステム化したい」——これは正しい。手作業で回せている業務のシステム化は、ロジックが明確になっているから設計できる。

問題は、「手作業ではうまく回っていないが、システムを入れれば解決するはず」というケースになる。これは高い確率で失敗する。

手作業でうまく回っていないということは、以下のどれかが起きている。

  • 業務の手順が定まっていない。 人によってやり方が違い、統一されたルールがない
  • 判断基準が曖昧。 「ベテランの勘」で処理されていて、条件分岐を言語化できない
  • そもそもその業務の目的が不明確。 何を達成するための業務なのかが曖昧

こうした状態でシステムを作ろうとすると、要件定義の段階で行き詰まる。「この場合はどうしますか？」という質問に誰も答えられない。仕様が固まらないまま作り始めると、出来上がったものは「誰の業務にも合わない」ツールになる。

なお「ベテランの勘」で動いている業務は、言語化できなくても安定して機能しているなら、無理にシステム化しない判断もある。どの業務を仕組み化すべきかのトリアージについては以前の記事で書いた。

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

手作業で回すことはロジックの検証になる

システム化の前に手作業で回すことを勧めると、「それでは効率が悪い」と言われることがある。しかし、手作業で回すことの目的は効率化ではなく、ロジックの検証になる。

手作業で業務を1回通してみると、以下のことがわかる。

  • 実際に必要なデータは何か。 想定していたデータの半分は使わず、想定していなかったデータが必要になることは珍しくない
  • 判断の分岐点はどこか。 「Aの場合はこう、Bの場合はこう」というロジックが、手を動かして初めて明確になる
  • 例外処理は何か。 正常系だけなら簡単だが、現実には例外が山ほどある。手作業で回すと例外パターンが見えてくる

これらはヒアリングだけでは見えにくい。以前の記事で現場と話す時間の重要性を書いたが、話を聞くだけでは「普段どうやっていますか」の回答は正常系に偏りがちになる。自分で手を動かすか、現場に隣で見させてもらうかして、実際の業務を一通り体験すると、聞いていた話と実態の差に気づくことが多い。

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

手作業で回すと「やめるべき業務」も見える

手作業で業務を通してみると、ロジックの検証だけでなく、そもそも不要な手順が見えてくることがある。

以前の記事で、システム化の前に「やめる」を考える廃止型のDXについて書いた。しかし、やめるべき業務を見つけるのは簡単ではない。依頼として「これは不要です」とは上がってこないし、長年続いている業務は存在自体が当たり前になっている。

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

手作業で一通り回してみると、「この手順、何のためにやっているんだろう」という疑問が自然に出てくる。頭で考えているだけでは気づかなかった無駄が、手を動かすと見える。

あるいは、手作業で回した結果「これは手作業のままで十分に回る」とわかることもある。月に数回しか発生しない業務をシステム化するより、手作業のままにしておくほうが合理的な場合は少なくない。システム化の判断自体が、手作業で回してみて初めて正確にできる。

内製DXの正しい順番

ここまでの話を整理すると、内製DXには正しい順番がある。

多くの会社がやりがちな順番：

  1. 「この業務をシステム化したい」と決める
  2. ツールや技術を選ぶ
  3. 作り始める
  4. 要件が固まらず迷走する、または作ったが使われない

うまくいく順番：

  1. まず手作業で業務を回してみる（ロジックの検証）
  2. 不要な手順があれば廃止する（廃止型DX）
  3. 残った手順を整理して、使う人と話しながら設計する
  4. 手作業で検証済みのロジックをシステムに落とし込む

1が抜けると、ロジックが不明確なまま設計に入ることになる。2が抜けると、不要な業務をシステム化してしまう。3が抜けると、使われないツールができる。

このシリーズで書いてきたことは、すべてこの順番の中に位置づけられる。データの持ち方を正す（1の中で見えてくる）、やめる業務を見つける（2）、現場と話す（3）、ツールを作る（4）。どれも順番を飛ばすと効果が出ない。

この順番は、内製DXの着手順序全体とも重なる。以前の記事でDXの地固め——コミュニケーション基盤の確立、現状把握、保全——について書いたが、そこで言う「現状把握」は手作業での業務検証と直接つながっている。

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

手作業を「遠回り」と思わないこと

手作業で回す時間を「無駄」や「遠回り」と感じる気持ちはわかる。DX担当者としては早くツールを作りたいし、経営者からも「いつできるのか」と聞かれる。

しかし、ロジックが検証されていない状態で作り始めると、手戻りのコストのほうがはるかに大きくなる。作り直し、仕様変更、使われないまま放置——これらの時間とコストに比べれば、手作業で1〜2週間回してみることは安い投資になる。仕入管理の仕組み化を何度か手がける中で、要件定義を急いで進めた場合の手戻りは、手作業で検証してから設計した場合の数倍かかることが多かった。

手作業でできることしかシステムにできない。逆に言えば、手作業でできるようになったものは、確実にシステム化できる。この順番を守るだけで、内製DXの成功率は大きく変わる。

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

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

投稿日:

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

工数削減型は普及しやすい、それでも定着しない場合がある

以前の記事で、内製DXには「管理精度型」と「工数削減型」があり、工数削減型は使う人自身にメリットがあるため自然に広まりやすいと書いた。この考えは変わっていない。作業が楽になるツールは、押し付けなくても使ってもらえることが多い。

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

しかし経験上、工数削減型であっても定着しないケースはある。機能は揃っている。操作も難しくない。使えば確かに楽になる。それでも現場に渡しても使われない。

この原因を「現場のITリテラシーが低い」「変化を嫌う体質」と片付けてしまうケースは多い。しかし自分の経験では、使われない原因のほとんどは、ツールの問題でも現場の問題でもなく、DX担当者と現場の間で十分に話す時間がなかったことにある。

当事者意識は説明会では生まれない

ツールを作り終えてから説明会を開く。操作方法を教えて、マニュアルを配る。「来月からこれを使ってください」と伝える。

このやり方で定着することもあるが、うまくいかないことのほうが多い。理由は単純で、現場の人にとってそのツールは「他人ごと」だからになる。自分が頼んだわけでもない、自分の困りごとから出発したわけでもないツールに対して、当事者意識を持てというほうが無理がある。

当事者意識は、操作説明では生まれない。作る前から話していて、自分の声が反映されていると感じたときに生まれる。

飲みに行く話ではない

コミュニケーションが大事だと言うと、「飲み会を増やせ」「雑談の機会を作れ」という話に聞こえるかもしれない。否定はしないが、ここで言いたいのはそういう話ではない。

必要なのは、業務時間の中に、使う人と話す時間が確保されていること。これだけになる。

「今の作業で一番面倒なのはどこですか」「この帳票はどういう流れで使っていますか」「こういう画面にしようと思っているんですが、どう思いますか」。こうした会話が、ツールを作り始める前と、作っている途中に、十分な回数行われているかどうか。

特別な仕掛けは何も要らない。話す。聞く。見せる。また話す。この繰り返しだけで、ツールの精度も定着率も大きく変わる。

DX担当者は「開発者」ではなく「通訳」

内製DX担当者の仕事は、コードを書くことだと思われがちになる。実際、経営者から見ても「ツールを作る人」として認識されていることが多い。

しかし現実には、DX担当者の仕事の中で最も時間をかけるべきなのは、現場の業務を理解するために人と話すことになる。

現場の人は自分の業務の困りごとを言語化できないことが多い。「なんとなく面倒」「昔からこうやっている」「Excelが重い気がする」。こうした曖昧な不満の裏に、本当の課題が隠れている。

DX担当者の仕事は、この曖昧な不満を聞き取って、システムで解決できる形に翻訳すること。つまり現場の言葉と技術の言葉の通訳になる。通訳するためには、まず現場の言葉を聞く時間が要る。

話す時間がなぜ確保されないか

これだけ単純なことが、実際にはできていない会社が多い。理由はいくつかある。

DX担当者が兼任で忙しい。 中小企業のDX担当者は情シスや総務との兼任であることが多い。日常の問い合わせ対応やPC管理に追われて、現場に出向いて話す時間がそもそも取れない。

「話している時間」が仕事に見えない。 コードを書いていれば成果物が見える。しかし現場で話を聞いている時間は、外から見ると仕事をしていないように見える。経営者がこの時間の価値を理解していないと、「早く作ってくれ」というプレッシャーになる。

現場も忙しい。 話を聞きに行きたくても、製造の現場は手が止められない。まとまった時間を取ってもらうのが難しい。

これらは構造的な問題であり、DX担当者の努力だけでは解決しにくい。以前の記事で、DXは1人では回らず経営者の協力が必要だと書いた。ここでも同じことが言える。経営者が「現場と話す時間」をDX担当者の仕事として認め、その時間を確保する環境を作る必要がある。

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

話すことで得られるもの

DX担当者が現場と話す時間を確保できると、ツールの定着率が上がるだけでなく、それ以上の効果が出てくる。

作るべきものが見える。 依頼ベースで動いていると「これをシステム化して」という要望に応えるだけになる。しかし現場と日常的に話していると、依頼にはならないが実は大きな非効率が見えてくる。以前の記事で「やめるべき業務を見つける」話を書いたが、やめるべき業務は依頼としては上がってこない。現場の日常を知っている人間だけが気づける。

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

信頼関係ができる。 新しいツールへの抵抗感は、変化への不安からくる。しかし「あの人が作るなら」「前にちゃんと話を聞いてくれた人だから」という信頼があると、ハードルは下がる。これは飲み会で得る信頼ではなく、仕事の中で「この人は自分たちの業務を理解している」と感じてもらえるかどうかの話になる。

手戻りが減る。 作り終えてから「思っていたのと違う」と言われるのが最も痛い。途中で見せて話していれば、方向修正は小さくて済む。開発効率の観点からも、話す時間への投資は回収できる。

技術力に加えて、もう一つ

内製DXの担当者に求められるスキルは何かと聞かれたら、プログラミングだと答える人が多いだろう。確かにコードが書けなければツールは作れないし、技術力は内製DXの土台になる。

このシリーズでは、内製エンジニアがAIを活用して社内ツールを高速開発するアプローチを勧めてきた。AIのおかげでコードを書く能力のハードルは大幅に下がっている。技術面の環境は確実に良くなっている。

ただし、技術力があればうまくいくかというと、それだけでは足りないことがある。現場に出向いて話を聞く時間を持っているかどうか。地味で泥臭い話だが、これが技術力と同じくらい成果に効いてくる。

AIがコードを書く力を補ってくれる時代だからこそ、AIには補えない部分——現場に行って、話を聞いて、業務を理解すること——の価値が相対的に上がっている。技術力を磨くことと、話す時間を確保すること。この両方が揃ったとき、内製DXは最も確実に成果を出せる。

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

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

投稿日:

受注生産のデータは見積番号から始める ── 受注起点では見えないフィードバックループ

受注番号からデータが始まる会社が多い

中小製造業のデータ管理で、最も一般的な起点は受注番号になる。受注が確定した時点で番号を振り、その番号で製造指示、仕入、工程管理、出荷、請求と紐づけていく。

このシリーズでも、受注番号を軸にしたデータの紐づけを繰り返し勧めてきた。仕入管理、品質管理、納期回答——いずれも受注番号を一本の串にして情報を通す考え方になる。

受注番号を起点にすること自体は間違っていない。しかし、ここで一つ見落とされがちな問題がある。受注の前には見積もりがある。 そして多くの会社で、見積もりと受注のデータがつながっていない。

見積もりは「使い捨て」にされている

受注生産の中小製造業であれば、ほぼ確実に見積もりをしている。顧客から引き合いが来て、材料費・加工時間・外注費を積算し、見積書を出す。

このとき見積もりの中には、その案件の原価構造がすでに入っている。どの工程にどれだけ時間がかかるか、材料費はいくらか、外注はどこに出すか。受注前の段階で、これだけの情報が一度は整理されている。

しかし受注が決まると、多くの会社ではここで断絶が起きる。受注番号が新しく採番され、製造は受注番号で動き始める。見積書はファイルに綴じられるか、フォルダに保存されて、二度と参照されない。

見積もりの時点で積み上げた情報と、受注後の実際の業務が、番号で結びついていない。見積もりが使い捨てになっている。

見積番号と受注番号を紐づけるだけで変わること

やるべきことは単純で、見積番号と受注番号を紐づけるだけになる。見積台帳に受注番号の列を追加する、あるいは受注台帳に見積番号の列を追加する。どちらでもいい。

この紐づけが存在するだけで、以下のことが可能になる。

1. 積算と実績の比較ができる

見積もりの段階で「溶接3時間、材料費5万円」と積算したものに対して、実際にかかったコストを突き合わせられる。見積もり時の想定と実績がどれだけ乖離しているかがわかる。

以前の記事でアワーレート方式による個別原価管理を書いたが、原価の「実績」だけ見ていても、それが高いのか安いのか判断しにくい。見積もりの「積算」という比較対象があって初めて、乖離の大きさと方向がわかる。

→ 中小製造業の多品種少量生産における原価計算の「落とし所」

2. 見積もりの精度を改善できる

積算と実績の差が蓄積されれば、見積もりのどこにズレがあるかが見えてくる。「溶接工程はいつも1.5倍かかっている」「材料費は見積もりより低く収まる傾向がある」。このフィードバックがあれば、次の見積もりでは最初から補正できる。

以前の記事で、見積もりデータを生産計画の簡易マスタに流用する方法を書いた。見積もりを計画に使う——これは前方向への流れになる。今回の話はその逆で、実績を見積もりに返す——後方向への流れになる。前方向と後方向の両方が回って、初めてサイクルが成立する。

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

3. 見積もりデータがそのまま実用マスタになる

見積もりと受注が紐づいて、さらに実績でフィードバックが返ってくると、見積もりデータの精度が時間とともに上がっていく。こうなると、過去の見積もりデータは「正確さが検証された積算情報」の集まりになる。

以前の記事で、中小製造業ではBOMや標準時間の整備が進まないと書いた。完璧なマスタを一から作るのは工数が重すぎる。しかし、見積もりデータを起点に、実績で補正しながら育てていけば、日常の業務の中で自然にマスタが育つ。整備のための特別な作業は要らない。

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

受注にならなかった見積もりにも価値がある

見積番号で管理するもう一つの利点は、受注にならなかった案件のデータも残ることにある。

受注番号を起点にすると、受注になった案件しかデータに残らない。しかし実際には、見積もりを出したうち受注になるのは一部であり、受注にならなかった案件の情報は消えてしまう。

受注にならなかった見積もりには、価格面で折り合わなかった、納期が合わなかった、仕様が合わなかったなど、何らかの理由がある。この情報が蓄積されれば、受注率の傾向が見えてくる。「この価格帯だと失注する」「このリードタイムでは取れない」といった営業判断の材料になる。

見積番号を起点にしたデータ管理は、受注以降の業務だけでなく、受注の手前にある営業活動の可視化にもつながる。

紐づけの粒度は「見積番号＝受注番号」でなくていい

実務上、見積もりと受注が1対1に対応しない場合も多い。1つの見積もりから複数の受注に分かれることもあるし、見積もりを何度か改定してから受注が決まることもある。

ここで完璧な対応関係を作ろうとすると、仕組みが複雑になりすぎる。現実的な落とし所としては、受注データに「元の見積番号」を1つ持たせるだけで十分に機能する。改定がある場合は最終版の見積番号を入れておけば、積算との比較は成立する。

以前の記事で繰り返し書いてきたが、完璧を目指して始められないより、70点で回し始めるほうがはるかに価値がある。見積番号と受注番号の紐づけも同じで、厳密な対応関係がなくても、つながっているだけで見える景色が変わる。

→ 中小製造業の多品種少量生産における原価計算の「落とし所」

見積もりを起点にすると、データの流れが一本になる

ここまでの話を整理する。

受注番号を起点にしたデータの流れ：

受注 → 製造 → 仕入 → 検査 → 出荷 → 請求

これに見積番号を加えると：

見積 → 受注 → 製造 → 仕入 → 検査 → 出荷 → 請求 → 実績を見積にフィードバック

起点が一つ前に伸びて、終点からフィードバックが返る。直線がループになる。

このシリーズで繰り返し書いてきた「受注番号を串にする」という考え方は変わらない。ただし、その串の先頭に見積番号をつなげるだけで、データの活用範囲が大きく広がる。新しいシステムは要らない。見積台帳と受注台帳に、お互いの番号を1列追加するだけでいい。

見積もりは使い捨てにするには惜しいデータになる。中小製造業が日常的に作っている見積もりの中に、原価管理の基準、生産計画の簡易マスタ、営業分析の材料がすでに入っている。それを活かすために必要なのは、番号を一つつなげることだけになる。

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

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

投稿日:

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

システム化の依頼が来たら、まず疑うこと

内製DXを進めていると、社内からシステム化の依頼が出てくる。「この週報をExcelじゃなくてシステムで入力できるようにしてほしい」「この集計作業を自動化してほしい」。

依頼が来たら作る。それが内製DX担当者の仕事に見える。しかし、ここで一つ立ち止まって考えるべきことがある。

その業務は、そもそも必要なのか。

以前の記事で、内製DXには「管理精度型」と「工数削減型」の2つがあると書いた。管理精度型は見えないものを見える化する。工数削減型は手間を減らす。どちらも「業務が存在する」ことを前提にした改善になる。

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

しかし実際の現場には、存在自体が疑わしい業務がある。ここに手を入れるのが第三の選択肢、「廃止型」 になる。

誰も見ていない資料が作られ続ける構造

中小製造業の現場で、こういう光景は珍しくない。

  • 毎週作成される週報。上司は読んでいない
  • 月次で集計される実績表。会議資料に載るが、その数字について議論されたことがない
  • 日報を全員に書かせているが、集計も分析もされずフォルダに溜まっていく
  • 「前任者がやっていたから」という理由だけで続いている帳票

これらは、始まった当初には目的があったはず。しかし目的が形骸化しても、作業だけが慣性で残る。やめるきっかけがないから続いている。誰かが「これ要りますか？」と聞かない限り、止まらない。

そしてここに「この資料の作成をシステム化してほしい」という依頼が来る。システム化すれば作成の手間は減る。しかし、誰も見ていない資料の作成が楽になっただけで、無駄がデジタルに移っただけになる。

プロセス改善がいちばん効く場合がある

ツールを作って業務を効率化するのが内製DXの仕事だと思いがちだが、業務プロセスそのものを見直すほうが効果が大きいケースは多い。

たとえば、ある帳票の作成に毎週2時間かかっているとする。これをシステム化して30分に短縮すれば、週1.5時間の削減になる。しかし、その帳票が実は不要だったとわかれば、削減効果は週2時間。しかもシステムを作る工数がゼロになる。

作るより、やめるほうが速い。

もちろん、すべての業務を疑い始めたら何も進まない。しかし少なくとも「システム化してほしい」という依頼が来たとき、作り始める前にその業務の目的と利用実態を確認する工程を挟むだけで、無駄なシステムを作るリスクを大幅に減らせる。

ただし、DX担当者1人では「やめる」は決められない

ここが現実の壁になる。

「この資料、誰が見ていますか？」は正論だが、依頼してきた上司や他部門に対して、DX担当者の立場からは聞きにくい。特に中小企業では、DX担当者が若手だったり兼任だったりして、業務の要否を問える位置にいないことが多い。

「やめましょう」と提案するのは、その業務を続けてきた人の仕事を否定するように聞こえかねない。正しいことを言っていても、組織の中では通らないことがある。

だから廃止型のDXは、DX担当者単独ではできない。経営者の協力が必要になる。

経営者の役割は「やめていい」と言うこと

内製DXにおける経営者の役割は、予算を出すことだけではない。管理精度型であれば「何を見たいか」を決める。工数削減型であれば「何を優先するか」を決める。

廃止型では、経営者の役割は 「やめていい」と言うこと になる。

DX担当者が「この帳票、システム化の前に利用状況を確認したいのですが」と聞ける空気を作る。確認した結果「実は誰も使っていない」とわかったとき、「じゃあやめよう」と判断を下す。この判断はDX担当者にはできない。業務を廃止する権限を持っているのは経営者だけになる。

逆に言えば、経営者が「やめていい」と言えない組織では、廃止型のDXは機能しない。不要な業務がシステム化され、無駄が効率よく回り続ける。

そしてもう一つ、経営者自身が気をつけるべきことがある。以前の記事で、管理精度の向上は経営者の判断力を引き上げる「武器」だと書いた。これは正しいが、武器は多ければ多いほどいい、とはならない。

→ 管理精度の天井は、経営者の判断力で決まる

経営者が「あれも見たい、これも把握したい」と求めると、その分だけ現場の入力負荷が増え、DX担当者の開発負荷が増え、管理帳票が増える。武器を増やしすぎた結果、どの数字も中途半端にしか見ない状態になれば、武器を持っていないのと同じになる。

廃止型DXの対象は、現場が惰性で続けている業務だけではない。経営者自身が過去に「見たい」と言って作らせた管理帳票も含まれる。かつて必要だと思って作らせたが、今は見ていない。しかし自分が頼んだ手前、やめようとは言い出しにくい。こうして経営者側からも不要な業務が生まれ続ける。

本当に使う武器だけを手元に残す。それは現場に「やめていい」と言うのと同じかそれ以上に、勇気が要ることかもしれない。

「やめていいか」を確認する方法

とはいえ、経営者もすべての業務の利用実態を把握しているわけではない。DX担当者側から判断材料を出す必要がある。ここは角の立たない形で確認する方法がある。

要件定義として聞く：

システム化の依頼が来たとき、作り始める前に確認するのは当たり前のことになる。「この資料は誰がいつ、どういう判断に使っていますか？」は、要件定義として自然な質問であり、業務の要否を問うているようには聞こえない。

この質問に明確な答えが返ってこない場合、その業務は形骸化している可能性が高い。

データで確認する：

ファイルサーバーに置かれている資料であれば、最終アクセス日時を確認できる。半年間誰も開いていないファイルがあれば、それは事実として示せる。人に「見ていますか？」と聞くと角が立つが、データが示す事実に対しては反論しにくい。

どちらの方法も、DX担当者が「この業務は不要です」と言っているのではなく、事実を集めて経営者に判断材料を渡しているだけになる。判断するのは経営者。DX担当者の仕事は、判断できる材料を揃えることになる。

DXは1人では回らない

このシリーズでは、内製エンジニアがAIを活用して社内ツールを高速開発するアプローチを繰り返し勧めてきた。しかし内製DXは、技術だけで完結する話ではない。

管理精度型のDXでは、経営者が「何を見たいか」を決めなければ設計できない。廃止型のDXでは、経営者が「やめていい」と判断しなければ動けない。工数削減型ですら、現場の協力がなければ定着しない。

DX担当者は道具を作れる。しかし、何を作るか、何をやめるかの判断は、経営者と一緒にやるしかない。内製DXの成否を分けるのは、技術力よりも、経営者とDX担当者が同じ目線で業務を見られる関係があるかどうかになる。

新しいツールを作る前に、まず今ある業務を一緒に眺めてみる。「これは何のためにやっているんだっけ？」と問い直す。その結果やめられる業務が見つかれば、それはシステムを1本作るより大きな成果になることがある。作ることだけがDXではない。やめることもDXになる。

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

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

投稿日:

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

「AIで○○が自動化される」は、当たるかどうかわからない

AIに関する予測は毎月のように出てくる。プログラミングは自動化される、設計はAIがやる、営業メールは全部AIが書く、工場の検査は画像認識に置き換わる。

こうした具体的な予測が当たるかどうかは、正直わからない。5年前に「RAGで社内ナレッジが自在に引き出せる」と言われていたが、以前の記事で書いた通り、現時点でそれが中小企業の現場で安定して動いているケースは少ない。一方で、コード生成のように予想以上に早く実用化した領域もある。

→ 中小製造業がAI・RAGと付き合うための現実的な整理

個別の予測は外れることも多い。「来年にはこれが自動化される」という話に一喜一憂しても仕方がない。

ただし、大局は決まっている

個別の予測は当てにならないが、大きな方向は決まっている。AIは今後、電気やインターネットと同じレベルのインフラになる。 これはもう予測ではなく、既定路線と言っていい。

PCが普及した1990年代を思い出すとわかりやすい。当時「PCで何ができるか」の具体的な予測は玉石混交だった。「紙はなくなる」と言われたが紙はまだある。「全員がプログラマーになる」とも言われたがそうはなっていない。しかし「PCが業務インフラになる」という大局だけは完全に当たった。今、PCが使えない会社は存在できない。

インターネットも同じだった。「ネットで何が変わるか」の個別予測は外れだらけだったが、「ネットが前提になる」という大局は不可逆だった。

AIも同じ構造をたどっている。「AIで具体的に何が自動化されるか」の予測に振り回される必要はない。しかし「AIがインフラになる」という大局に対して準備しない、という選択肢はない。

「成果が出てから始める」では遅い

中小企業の経営者が慎重になるのは理解できる。限られた予算と人手の中で、成果が見えないものに投資するのはリスクに感じる。「もう少し事例が出てから考える」というのは、一見合理的な判断に見える。

しかしインフラの転換期において、この判断は裏目に出ることが多い。

PCの導入も、早い段階で触り始めた会社と、「ウチにはまだ早い」と様子を見ていた会社で、数年後に大きな差がついた。差がついたのは、PC自体の性能ではなく、組織がPCを使いこなすまでの学習時間があったかどうかだった。

AIも同じことが起きる。ツールの性能は日進月歩で上がっていくが、組織がAIを使いこなすための学習は一朝一夕にはいかない。「何を聞けばいいかわからない」「どの業務に使えるかピンとこない」——これは触って試して失敗して、初めて超えられる壁になる。成果が出てから始めようとしても、その時点では学習期間を経た他社との差がすでに開いている。

全社員に配っても使われない問題

以前の記事で、「全社員にAIツールを配る」アプローチはPCスキルのばらつきや「何を聞けばいいかわからない」という壁があると書いた。この状況は現時点でも大きくは変わっていない。

→ 中小製造業がAI・RAGと付き合うための現実的な整理

実際、ChatGPT EnterpriseやMicrosoft Copilotを全社展開した企業でも、継続的に使い込んでいるのは全体の1〜2割で、残りは数週間で使わなくなるという話はよく聞く。短期のROIで測れば、全社員分のライセンス費用に見合っていないと評価されてもおかしくない。

しかし、これを「失敗」と見るかどうかは、何を期待していたかによる。

全社員が即座にAIを使いこなして生産性が上がる——そう期待していたなら確かに失敗になる。しかし、組織としてAIに触れ始める最初の一歩——そう位置づけるなら、使わなくなった8割も含めて「AIというものが存在する」という認識が社内に共有されたこと自体に意味がある。

挑戦自体が資産になる

中小製造業がAIに取り組む価値は、今すぐの成果ではなく挑戦の過程で組織に蓄積されるものにある。

  • AIに何を聞けば使えるのか、何を聞いても無駄なのかの肌感覚
  • 自社の業務のうち、どこにAIが効きそうで、どこには効かないかの見極め
  • 「AIを使う」という行為への心理的なハードルの低下

これらは導入事例を読んだだけでは得られない。自分たちで触って、うまくいかない経験も含めて初めて身につく。

以前の記事で、内製DXは内製エンジニアがAIを活用して社内システムを高速開発するアプローチが最も効果的だと書いた。この考えは変わっていない。ただし、内製エンジニア以外の社員がAIに触れること自体を否定しているわけではない。全社員の生産性が即座に上がることを期待するのではなく、組織全体がAIに慣れるプロセスに投資していると捉えれば、短期の利用率の低さは問題にならない。

→ 中小製造業がAI・RAGと付き合うための現実的な整理

環境を与えるコストは思ったほど高くない

AIツールのライセンスは月額数千円程度。社員一人あたりの人件費と比べれば誤差の範囲になる。1〜2割しか使わなかったとしても、その1〜2割が月に数時間分の作業を効率化すれば、十分に元は取れる計算になる。

合わせて意識したいのがPCのスペック。AIツールに限った話ではないが、メモリ不足でExcelが固まる、ブラウザのタブを開くたびに動作が重くなる——こうした環境では、そもそも新しいツールを試す気が起きない。SSDと十分なメモリを積んだPCは、体感の待ち時間を減らすだけでなく、「ちょっと試してみるか」という心理的なハードルも下げる。

AIツールの月額数千円とPCの数万円の差額をケチるよりも、社員が新しい道具に触れやすい環境を整えるほうが、長期的にはリターンが大きい。

AIは「改善」ではなく「変化」、ただし土台がなければ乗れない

業務改善には2種類ある。今あるやり方をより良くする「改善」（1→2）と、やり方そのものが変わる「変化」（1→A）になる。

このシリーズでやってきたのは、ほとんどが「改善」にあたる。Excelのデータの持ち方を正す、紐づけのキーを入れる、見積番号と受注番号をつなげる。どれも今の業務の延長線上で、やり方の根本は変わっていない。

一方、AIの登場は「変化」の側にある。同じ作業を速くやるだけではなく、誰が何をできるかのルール自体が変わる。コードを書ける人の裾野が変わる。今まで人手でやるしかなかった判断の一部が委譲できるようになる。これは改善の延長にはない、ルールの変更になる。

しかし、変化に乗るには土台が要る。

AIにデータを読ませたくても、データが整っていなければ読ませるものがない。AIで業務を自動化したくても、業務プロセスが整理されていなければ何を自動化すべきかわからない。AIを活用できる内製エンジニアがいても、現場との信頼関係がなければツールは使われない。

このシリーズで書いてきたデータの文法、紐づけの設計、プロセスの見直し、現場とのコミュニケーション——これらは地味な改善の話だが、同時にAIという変化に乗るための土台づくりでもある。改善を飛ばして変化には行けない。 逆に、改善だけやっていて変化を見ないと、気づいたときにはルールが変わった世界に取り残される。

両方が要る。地味な改善で足元を固めながら、AIという変化の方向を見ておく。どちらか片方では足りない。

具体的な予測ではなく、構えを取る

「AIで何ができるようになるか」の具体的な予測を追いかけるのは、情報収集としては面白いが、経営判断の根拠にはしにくい。予測が当たるかどうかに賭けるのはギャンブルになる。

代わりに取るべきは、AIがインフラ化したときに対応できる組織の構えを今から作っておくことになる。

具体的には、このシリーズで繰り返し書いてきたことと変わらない。

  • データの持ち方を正しくしておく（AIが活用できるデータの土台）
  • 内製エンジニアを育て、AIを開発の加速に使う（最も確実にROIが出る領域）
  • 社員がAIに触れる機会を作る（学習コストは早く払うほど安い）

AIの進化は速いが、だからといって「最新のAIが出てから考える」のでは永遠に始められない。今の時点で完璧なAI活用戦略を立てる必要はない。むしろ、完璧な戦略が立てられないからこそ、小さく始めて試行錯誤する。その試行錯誤の蓄積こそが、数年後にインフラ化したAIを使いこなすための土台になる。

予測に乗るのではなく、構えを取る。それが、中小製造業にとって最も現実的なAIとの付き合い方になる。

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

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

投稿日:

データは単体では意味がない ── 在庫と原価を「つなげて見る」という内製DXの基本

数字を単体で見せることの危うさ

内製DXで社内のデータを可視化する場面が増えてくると、「この数字を見えるようにしてほしい」という依頼が出てくる。売上推移、原価率、在庫金額、不良件数。それぞれの数字を出すこと自体は難しくない。

しかし、数字を単体で見せると判断を誤ることがある。

原価率が下がっていれば「改善した」と見える。在庫金額が増えていれば「資産が増えた」と見える。どちらも単体では正しい読み方に見えるが、この2つを並べると、まったく違う景色が見えてくることがある。

内製DXの担当者は、データを経営者に渡す立場にいる。会計の専門家である必要はないが、渡す数字が単体で見ると誤解を招く構造になっていないかは知っておく必要がある。今回は在庫と原価という、中小製造業で最も身近で、かつ最もつなげて見るべき数字の組み合わせを取り上げる。

在庫が増えると、原価率が良くなる仕組み

会計上、売上原価は次のように計算される：

売上原価 ＝ 期首在庫 ＋ 当期製造コスト − 期末在庫

この式の意味するところは単純で、期末の在庫が多ければ売上原価は小さくなり、利益は大きくなる。在庫が増えただけで、売上が同じでも利益の数字が変わる。

たとえば、ある月の状況がこうだったとする：

通常月 在庫増加月
売上 1,000万円 1,000万円
期首在庫 200万円 200万円
当月製造コスト 800万円 900万円
期末在庫 200万円 350万円
売上原価 800万円 750万円
原価率 80% 75%

在庫増加月は通常月より100万円多く作っている。しかし売上は同じ。売れなかった分が在庫として150万円積み上がっている。

会計上の売上原価は「200＋900－350＝750万円」となり、原価率は75%。通常月より良い数字が出る。製造コストは増えているのに、原価率は改善している。

これは会計の仕組み上そうなるだけであって、実態として効率が良くなったわけではない。

DX担当者がこの構造を知っておくべき理由

この話は経理の人間なら知っている。しかしDX担当者がデータを可視化する立場になったとき、この構造を知らないまま数字を出すと危険なことが起きる。

たとえば、月次の管理レポートを作ってくれと頼まれたとする。会計ソフトから原価率を引っ張って、推移グラフを作る。3ヶ月連続で原価率が下がっている。「改善傾向です」と報告する。

しかし同じ期間に在庫が膨らんでいたら、それは改善ではなく在庫の積み増しで原価率が良く見えているだけかもしれない。このレポートを受け取った経営者が「原価は順調だ」と判断してしまえば、在庫の問題に気づくのが遅れる。

数字を出す人間が構造を知らなければ、正確な数字で経営者をミスリードすることになる。 データが間違っているのではなく、見せ方が足りない。

ちゃんとした原価計算でも起きる

全部原価計算で個別原価を管理している会社でも、同じ構造の問題が起きる。

全部原価計算では、固定費（設備の減価償却費、工場の賃料など）を生産量で割って製品に配賦する。生産量が増えれば1個あたりの固定費負担が下がるので、製品の単位原価が下がる。

  • 月産100個なら、固定費500万円 ÷ 100個 ＝ 1個あたり5万円
  • 月産150個なら、固定費500万円 ÷ 150個 ＝ 1個あたり約3.3万円

原価が下がった。改善が進んだ。——しかし増産した50個が売れずに在庫になっていたら、それは改善ではなく、固定費を在庫に押し込んだだけになる。

以前の記事でアワーレート方式による個別原価管理を書いた。アワーレート自体は正しい管理手法だが、生産量が増えたときに単位原価が下がる構造は同じになる。原価データだけを見ていると改善に見えるものが、在庫データと並べると実態が違うことがわかる。

→ 中小製造業の多品種少量生産における原価計算の「落とし所」

一方で、個別原価計算をやっていない会社でも同じ罠にはまる。会計ソフトから出てくる月次の原価率だけ見ていて、「今月は原価率が下がった、いい傾向だ」と思っている。在庫と並べていないから気づかない。ある日、倉庫を見て「なんでこんなに在庫があるんだ？」となる。

ちゃんと原価を見ている会社も、なんとなく見ている会社も、在庫が増えると利益が良く見えるという同じ罠にハマる。ハマる経路が違うだけになる。

ゴールドラットが指摘した構造

この問題を最も鋭く指摘したのが、エリヤフ・ゴールドラットの『ザ・ゴール』になる。

工場の「効率」を上げろと言われる。機械を止めるな、稼働率を上げろ。稼働率を上げるためには作れるだけ作る。作った分は在庫になる。原価計算上は単位コストが下がる。帳簿上は利益が出ている。しかしキャッシュは在庫に寝ていて、実際には金が回っていない。

ゴールドラットはこの構造を「原価計算が工場の判断を狂わせる」と表現した。原価を下げるための合理的な行動（稼働率を上げる、大ロットで作る）が、在庫の山を生み、キャッシュフローを悪化させる。

「たくさん作ったほうが1個あたりのコストが安い」という感覚は、規模を問わず現場に染みついている。その感覚が正しい場面もあるが、売れる見込みのない製品を在庫として積み上げる根拠にしてはいけない。在庫は帳簿上は資産だが、実質的には回収できていないキャッシュになる。

部門ごとのKPIが全部「良好」なのに、会社全体がおかしくなる

この問題がさらに厄介なのは、各部門がそれぞれの評価指標で見ると全員「良い仕事をしている」ように見えることにある。

  • 製造部門は稼働率で評価される。機械を止めず、たくさん作っている。KPIは良好
  • 経理は原価率を見ている。生産量が増えて単位原価が下がっている。KPIは良好
  • 営業は売上で評価される。在庫の問題には関心がない。売上が立っていればKPIは良好

各部門のKPIがすべて「順調」を示しているのに、会社全体では在庫が膨らみ、キャッシュが倉庫に寝ている。部門単位の数字をいくら集めても、全体の矛盾は見えない。

これは在庫と原価に限った話ではなく、部門ごとに評価指標が分かれている組織で構造的に起きる問題になる。各部門が自分のKPIを最適化する合理的な行動を取った結果、全体では非合理な状態が生まれる。

DX担当者がデータを可視化するとき、部門ごとのレポートをそれぞれ作るだけでは、この矛盾には気づけない。部門をまたいで数字をつなげて初めて、「各部門は順調なはずなのに、なぜ全体がおかしいのか」が見える。

「つなげて見せる」のがDX担当者の仕事

ここまでの話を踏まえて、DX担当者として最低限やるべきことを整理する。

原価率も在庫金額も、会計ソフトの中にすでに存在しているデータになる。問題はこの2つが別々の帳票・画面に出てくるため、並べて見る習慣がないことにある。

月次で2つの数字を並べるだけで、見え方が変わる：

月 原価率 期末在庫金額
1月 78% 320万円
2月 75% 380万円
3月 73% 450万円
4月 76% 420万円

原価率が下がっているのに在庫金額が増えていたら、効率改善ではなく在庫の積み増しを疑うサインになる。逆に、原価率が上がっていても在庫が減っていれば、滞留在庫を吐き出している健全な状態かもしれない。

新しいデータを取る必要はない。すでに会計ソフトにある数字を、並べて見える形にするだけ。しかしこの「並べる」という行為こそが、データを情報に変える最小単位の仕事になる。

もう一歩踏み込むなら、在庫を品目別または製品グループ別に見て、どこに滞留があるかを把握する。ただしこれは棚卸のデータがその粒度で残っていることが前提になる。以前の記事でデータの文法について書いたが、棚卸データも「あとから分析できる形」で残していなければ、数えた事実だけがあってデータとして使えないことになる。

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

在庫と原価に限らない

今回は在庫と原価の組み合わせを取り上げたが、「1つの数字だけ見ると良く見えるのに、別の数字と並べると実態が違う」という構造は他にもある。

  • 売上が伸びているのに、入金サイトが延びていたらキャッシュは増えていない
  • 生産量が増えているのに、不良率も上がっていたら実質的な生産性は変わっていない
  • 受注件数が増えているのに、1件あたりの粗利が下がっていたら忙しくなっただけ

この「並べて見る」原則を一般化すると、見える化の本質は 基準と実績の突合 に帰着する。

→ 中小製造業の見える化は「基準と実績の突合」── 数字は比較して初めて意味を持つ

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

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

投稿日:

品質管理の正体はデータ管理 ── 中小製造業のトレーサビリティと統計管理を阻むもの

品質管理の「手法」は足りている

品質管理の教科書は山ほどある。QC7つ道具、なぜなぜ分析、FMEA、SPC（統計的工程管理）。手法そのものは体系化されていて、学ぼうと思えばいくらでも学べる。

しかし中小製造業の現場で品質管理が回っていないとき、原因は手法を知らないことではない場合が多い。管理図を描きたくてもデータがない。不良の傾向を分析したくても記録が残っていない。トレーサビリティを求められても、どのロットがどの材料でいつ誰が作ったのか追えない。

品質管理の問題に見えて、実はデータ管理の問題であるケースが非常に多い。

トレーサビリティは「紐づけ」の問題

トレーサビリティとは、製品がどの材料から、どの工程を経て、いつ、誰の手で作られたかを追跡できる状態を指す。顧客からのクレーム対応、リコール時の影響範囲の特定、工程改善のための原因分析——いずれもトレーサビリティがなければ始まらない。

ここで必要なのは高度なシステムではなく、データ同士の紐づけになる。

受注番号、ロット番号、仕入先、材料ロット、工程、作業日、作業者。これらの情報がバラバラに存在していても、紐づけのキーがあれば追跡できる。逆に、どれだけ丁寧に検査記録を書いていても、紐づけのキーがなければ追跡できない。

受注番号と製品の紐づきは、規模の小さい工場でも大抵できている。受注を受けて製品を作る以上、どの注文に対して何を作ったかは自然と追える。

切れがちなのは、その先——仕入の情報との紐づけになる。どの受注の製品に、どの仕入先から、いつ届いた、どのロットの材料を使ったか。ここが結びついていないケースが非常に多い。検査成績書には「合格」と書いてあるが、使った材料のロットまでは追えない。これではクレームが入ったとき、同じ材料ロットで作った他の製品を特定できない。材料起因の不良なのか工程起因なのかの切り分けもできない。

もう一つ切れやすいポイントがある。以前の記事で、生産管理ではバッファ在庫を置いて前後工程を分断する考え方が有効だと書いた。管理の負荷を下げるには良い考え方だが、品質の追跡という観点では、このバッファ在庫が情報の断絶点になりやすい。前工程で加工された部品がバッファに入った時点で、どのロットの材料をいつ加工したものかという情報が消え、後工程ではただ「棚にある部品」として使われる。生産効率のための分断が、トレーサビリティの分断にもなってしまう。

→ 多品種少量・受注生産の中小製造業に、全工程スケジューリングは必ずしも要らない

ここは割り切りが要る。全部品にロット番号を貼って追跡するのは中小の体力では現実的でないことが多い。ただし、少なくともバッファ在庫に入れるタイミングで「いつの加工分か」がわかる程度の単位管理——たとえば加工日や加工週で棚を分ける、現品票に加工日を書く——をしておくだけで、問題発生時の追跡範囲は大幅に絞れる。完璧な個体追跡でなくても、「3月第2週の加工分」まで絞れれば、全数回収よりはるかにましになる。

以前の記事で、受注生産の仕入管理は受注番号を軸にした紐づけで成り立っていると書いた。品質管理のトレーサビリティもまったく同じ構造になる。受注番号を一本の串として、仕入・工程・検査・出荷のデータを通す。特別な仕組みは要らない。串になるキーが存在し、各記録にそのキーが入っていること。それだけで追跡は可能になる。

→ 受注生産の中小製造業における仕入管理は「今のやり方」から始めればいい

紙の記録が悪いのではない

誤解のないように書いておくと、紙の検査記録が悪いわけではない。中小製造業の現場で、検査のたびにPCを開いて入力するのが現実的でない場面は多い。

問題は紙かデジタルかではなく、その記録に紐づけのキーが入っているかどうかになる。

検査記録の用紙に受注番号（またはロット番号）の記入欄があり、それが確実に書かれていれば、紙の記録でもトレーサビリティは成立する。後からデジタル化したくなったときも、キーさえあれば紐づけられる。

逆に、キーのない記録を何年分積み上げても、それは「記録した」という事実があるだけで、追跡可能な品質データにはなっていない。

検査データは「社外への証明」になる

このシリーズでは、原価や負荷、仕入といった社内向けのデータ管理を中心に書いてきた。これらは自社の判断のために使うデータであり、保管方法はExcelファイルで十分だった。

しかし検査データは性質が異なる。検査成績書は顧客への品質保証の証拠であり、クレーム対応時の根拠資料であり、業種によっては法令や規格（ISO 9001など）で保管期間が定められている。社内の管理データとは違い、「あとから出せること」が要件になる。

ここで問題になるのが、紙の検査記録のまま何年分もファイルキャビネットに積み上がっている状態になる。記録は存在するが、3年前の特定の受注番号の検査成績書を探そうとすると、棚を端から探すことになる。顧客から急ぎで求められたとき、見つからないのは「記録がない」のと実質同じになる。

紙で記録すること自体は問題ないと先に書いた。ただし保管については、検索できる状態を維持する必要がある。現実的な方法としては、紙の記録をスキャンしてPDFにし、ファイル名に受注番号と日付を入れて保存するだけでも十分に機能する。検索キーがファイル名に入っていれば、フォルダの中から探せる。

以前の記事で、管理精度の向上は経営者の判断力を引き上げる「武器」だと書いた。原価の見える化や負荷の可視化は、経営者が攻めの判断をするためのデータになる。

→ 管理精度の天井は、経営者の判断力で決まる

一方、品質保証のデータは 「防具」 になる。経営者が日常的に見るものではない。しかしクレームが入ったとき、取引先の監査が来たとき、万が一リコールが必要になったとき、このデータがあるかないかで会社が受けるダメージがまったく変わる。武器と違って、防具は使わずに済むに越したことはない。しかし持っていなければ、一撃が致命傷になりかねない。

紐づけのキーと、検索可能な保管。この二つが揃っていれば、紙ベースの運用でも防具としての機能は果たせる。

統計的品質管理はデータの「形」が前提

統計的工程管理（SPC）は品質管理の中でも特にデータへの依存度が高い領域になる。Xbar-R管理図を描くには、同じ測定項目の数値データが時系列で蓄積されている必要がある。工程能力指数（Cp、Cpk）を算出するにも、十分な件数の測定値が規則的に記録されていなければならない。

ここで壁になるのが、データの「形」の問題になる。

以前の記事で、Excelのデータには「文法」があると書いた。1セル1値、型の統一、1行1件。品質データにもこの文法がそのまま当てはまる。

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

測定データが使えない形で残っている例：

日付 検査結果
3/5 外径 φ10.02、内径 φ5.01、OK
3/5 外径 φ10.05（※上限ギリギリ）、内径 φ4.98
3/6 OK

人間が読めば内容はわかる。しかしこのデータから管理図は描けない。数値と判定とコメントが1つのセルに混在し、測定項目が行ごとに違う形で書かれている。

使える形：

日付 受注番号 測定項目 測定値 規格下限 規格上限 判定 備考
2025-03-05 J-2501 外径 10.02 9.95 10.05 OK
2025-03-05 J-2501 内径 5.01 4.95 5.05 OK
2025-03-05 J-2502 外径 10.05 9.95 10.05 OK 上限ギリギリ
2025-03-05 J-2502 内径 4.98 4.95 5.05 OK
2025-03-06 J-2503 外径 10.01 9.95 10.05 OK
2025-03-06 J-2503 内径 5.02 4.95 5.05 OK

この形であれば、外径だけをフィルタして時系列に並べれば管理図が描ける。受注番号でフィルタすれば特定案件の検査結果が一覧できる。工程能力指数も計算できる。そして受注番号というキーを通じて、仕入データや工程データとも紐づく。

今すぐSPCをやるかどうかは関係ない。データの持ち方さえ正しければ、やりたくなったときにすぐできる。持ち方が間違っていれば、まずデータの整形から始めることになり、過去のデータは使えない。

「全数記録」で破綻するパターン

品質データの管理を始めようとすると、「全工程・全項目を記録しよう」という話になりがちになる。しかし中小製造業の現場で全数記録を徹底しようとすると、記録作業の負荷が高すぎて破綻するケースが多い。

以前の記事で、生産管理において全工程をスケジューリングするのではなく管理ポイントを絞る考え方が有効だと書いた。品質管理でも同じ発想が使える。

→ 多品種少量・受注生産の中小製造業に、全工程スケジューリングは必ずしも要らない

押さえるべきポイントは3つ：

  1. 受入検査 ── 材料・部品が入ってきた段階。ここで記録を残せば、不良発生時に材料起因かどうかを切り分けられる
  2. 最終検査 ── 出荷前の段階。製品品質の最後の砦であり、顧客に対する品質保証の根拠になる
  3. クレーム・不良記録 ── 発生した問題の記録。これがなければ改善のサイクルが回らない

この3点だけ押さえれば、品質の追跡は8割方カバーできる。中間工程の記録は、特定の工程で不良が頻発しているなど、必要性が見えてから追加すればいい。最初から全部やろうとして、結局どれも中途半端になるよりも、3つを確実に残す方がはるかに実効性がある。

不良データは「件数」ではなく「分類」で持つ

不良の記録で最もよく見るのが、月次で不良件数だけを集計しているケース。「今月の不良は12件」という数字はあるが、どの工程で、どんな種類の不良が、どの程度の頻度で起きているかがわからない。

パレート図を描いて不良の優先順位をつけるには、不良の分類データが必要になる。分類といっても、最初から細かく定義する必要はない。

日付 受注番号 工程 不良区分 内容 数量
2025-03-05 J-2501 機械加工 寸法不良 外径公差外れ 2
2025-03-06 J-2503 溶接 外観不良 ビード不整 1
2025-03-07 J-2505 組立 欠品 ボルト不足 1

不良区分を5〜10種類程度に絞り、ドロップダウンリストで選択式にしておく。自由記述にすると「寸法不良」「寸法NG」「寸法はずれ」のように表記がゆれて集計できなくなる。これもデータの文法の記事で書いた、名称の統一と選択式の原則がそのまま効く話になる。

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

この形でデータが蓄積されれば、月次でパレート図を作って「先月は寸法不良が6割を占めている。機械加工の外径加工を重点的に見直す」という判断ができる。件数だけでは見えなかった改善の優先順位が、分類データによって見えるようになる。

品質管理のDXは検査装置の導入ではない

品質管理のDXというと、三次元測定機や画像検査装置の導入を思い浮かべるかもしれない。確かにこれらの装置は測定の精度と速度を上げてくれる。しかし、装置が吐き出すデータの受け皿が整っていなければ、高精度な測定値が紙に印刷されて棚にファイルされるだけで終わる。

品質管理のDXの本質は、検査装置の導入ではなくデータの設計にある。

  • どの情報を、どのタイミングで、どの形式で記録するか
  • データ同士をどのキーで紐づけるか
  • 蓄積したデータをどう集計・分析できる形にしておくか

これはExcelの使い方の範囲内でできることであり、新しいシステムも高価な装置も必要ない。紙の検査記録であっても、紐づけのキーと記録項目の設計が正しければ、品質データとして機能する。

手法は教科書から学べる。装置は必要になれば買える。しかしデータは、正しい形で蓄積し始めなければ、後から取り返すことができない。品質管理の最初の一歩は、検査の厳格化でも装置の導入でもなく、記録の設計を見直すことにある。

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

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