TDKが公表した「95・3・2」の中身
自社のMESのうち、パッケージの標準機能のまま使っている部分が何割あるか、即答できますか。答えられない場合、その理由はたいてい「何を数えればよいか決まっていない」ことにあります。
2026年10月8日、TDK Electronics のCEO兼COOであるWerner Lohwasser氏の寄稿が、MESベンダー Critical Manufacturing のブログに掲載されました。同氏がサミットで行った講演をもとにした文章で、TDK Electronics が進めている全社のMES標準化の構成が数字つきで書かれています。
寄稿によれば、同社のMESはおよそ95%がすぐに使える標準機能、3%が全拠点に共通の標準を強制する「TDKコア」層、2%が工場ごとの個別対応です。TDKコアは同社の製品フレームワークの上に作られています。工場は世界に20あり、欧州が中心で、ブラジル、中国、インドネシア、マレーシア、インドにも拠点があります。MESはPLM、CRM、ERPと並ぶ4つの基幹システムの1つと位置づけられ、Critical Manufacturing が採用されました。
ほかにも具体的な記述があります。現場向けのダッシュボードは、製品ラインごとの稼働設備、OEE、不良率を表示し、複数のデータベースから集めていたExcelの管理表を置き換えました。中国の1工場では、ソフトウェアのボットが製造指図と部品表を突き合わせ、3交替で1日およそ1,000件の倉庫から現場への払い出しを計画しています。ただし、出力は実行前に人が確認しています。全社のインダストリー4.0の取り組みは2020年に始まり、システムの選定より先に従業員との対話を置いたこと、受け入れには時間がかかったことも書かれています。
判定表:9つの確認項目と基準
TDKの比率は結果です。結果を保つには、比率を数える仕組みと、比率が崩れないように止める仕組みの両方が要ります。以下の表は、寄稿の記述を手がかりに編集部が組み立てた確認項目で、TDK自身が使っている基準ではありません。
| No | 確認項目 | 判定基準(満たしていれば可) | 寄稿の記述との対応 |
|---|---|---|---|
| 1 | 比率の分母 | 何を1件と数えるか(要件、画面、帳票、IF、工数)が文書になっており、全拠点で同じ数え方をしている | 分母は非公表 |
| 2 | 「設定」と「改造」の線引き | 画面項目の表示切替や帳票レイアウトなど、設定で済む変更を標準側に数えるかどうかを決めてある | 95%を標準機能と表現 |
| 3 | 全社コアの置き場所 | 共通の業務ルールや連携が、製品の拡張用の枠組みの上に置かれ、バージョンアップ時の再適用手順がある | 自社の製品フレームワーク上に構築 |
| 4 | 拠点個別の上限と承認者 | 個別対応の上限(件数か比率)と、上限を超えるときの承認者が決まっている | 2%を拠点個別と明示 |
| 5 | 個別からコアへの昇格 | 2拠点以上で同じ個別要求が出たらコアへ移す、などの昇格条件がある | 記述なし(編集部の追加) |
| 6 | 置き換えたExcelの棚卸し | MES稼働後に廃止したExcel管理表の一覧と、残っているものの所有者が分かる | ダッシュボードがExcel管理表を置き換え |
| 7 | 自動化の出力の確認者 | ボットやAIの出力ごとに、誰がいつ確認してから実行するかが決まっている | 払い出し計画は人が確認してから実行 |
| 8 | 展開期間とバージョン差 | 最後の拠点が稼働するまでの年数と、その間に拠点ごとに版が違う期間の扱いを計画に書いている | 選定から最後の拠点稼働まで約10年 |
| 9 | 選定前の現場への説明 | システム選定より前に、現場へ目的を説明した記録がある | 選定より先に従業員との対話 |
比率を数えるための項目(No.1〜4)
No.1の分母を最初に置いたのは、ここが決まらないと残りの8項目がすべて空回りするからです。要件一覧の行数で数えると、帳票1枚の追加も大きな連携1本も同じ「1件」になります。工数で数えると個別対応の重さは見えますが、標準機能の側は工数がほぼゼロなので比率が極端に偏ります。当社が導入を支援してきた経験では、要件の件数と開発工数の両方を並べて記録しておくと、拠点間の比較で揉めにくくなります。2つの数字のずれそのものが、重い個別対応がどこにあるかを教えてくれるからです。
No.2の線引きは、比率を見かけ上よくする抜け道をふさぐ項目です。標準機能の設定だけで済む変更でも、画面項目を拠点ごとに大量に切り替えていれば、教育資料も問い合わせ対応も拠点ごとに分かれていきます。設定変更を標準側に数えると決めた場合でも、設定の一覧を全社で見られるようにしておく必要があります。
No.3は、TDKが全社コアを製品フレームワークの上に作ったという記述に対応しています。共通ルールを製品の外側に別システムとして作ると、MESの版上げのたびに連携の改修が発生します。拡張用の枠組みの中に置き、再適用の手順を文書にしておけば、コアの3%は版上げの障害になりにくくなります。
No.4の上限は、数字そのものより承認者が決まっているかを見ます。「2%以内」と決めても、超えたときに誰も止めなければ数年で崩れます。上限を件数で持つか比率で持つかはNo.1の分母と揃えてください。
比率を保つための項目(No.5〜9)
No.5の昇格ルールは寄稿に書かれていない、編集部が追加した項目です。拠点の個別対応のうち、別の拠点でも同じものが要るとわかったものを個別のまま残すと、同じ機能が2通りの作りで並びます。2拠点で重複したらコアへ移す、と決めておけば、2%の層が膨らむ前に吸い上げられます。テンプレート方式が形骸化する典型的な経緯は、グローバルテンプレート方式の利点と落とし穴で詳しく扱っています。
No.6は、MESを入れたあとに現場へ残るExcelを数える項目です。TDKは、複数のデータベースから集めていた管理表をダッシュボードに置き換えたと書いています。置き換えたものを一覧にしておかないと、廃止したはずの管理表が拠点ごとに復活し、拠点間でOEEの定義がずれる原因にもなります。
No.7は、自動化を広げる段階で効いてきます。中国の工場のボットは1日およそ1,000件の払い出しを計画しますが、実行前に人が確認しています。確認者を決めずに自動化だけを横展開すると、ある拠点では人が確認し、別の拠点では確認せずに流す、という差が生まれます。確認するかどうかを拠点個別に任せず、全社コアの側で決めておく項目だと編集部は考えています。
No.8の展開期間は、TDKが約10年と見込んでいる点が参考になります。10年あれば、その間にMES製品は何度も版が上がります。先に稼働した拠点と最後の拠点で版が違う期間をどう扱うかを計画に書いておかないと、コアの3%を拠点ごとに作り直すことになります。展開順序の決め方はマルチサイトMESの設計を参照してください。
No.9は、システムの話の前に人の話を置いた寄稿の構成に対応しています。選定が終わってから現場に説明すると、現場からの要求はすべて「個別対応」として出てきやすくなります。先に目的を共有しておくと、同じ要求が「標準の使い方の相談」として出てくるため、2%の層に流れ込む量が変わります。
よくある質問
95・3・2の比率を自社の目標値にしてよいですか
そのまま目標値にするのは避けてください。TDKの寄稿は比率の分母を公表しておらず、何を数えた比率なのかが分かりません。まず自社で分母を決め、展開済み拠点の実際の比率を数えてから、目標を置くのが順序です。
全社コア層にはどんな機能を入れるべきですか
全拠点で同じでなければ困るもの、たとえば品目や工程のコード体系、ERPとの連携仕様、全社で比べるKPIの計算式などが候補です。TDKコアの中身は寄稿に書かれていないため、この例は編集部の整理です。
10年がかりの展開は長すぎませんか
TDKの場合、20工場が欧州、南米、アジアに分かれており、寄稿では選定から最後の拠点の稼働までを含めた期間として約10年を挙げています。期間の長さそのものより、その間の版上げとコアの再適用をどう回すかを先に決めておくほうが、計画の成否に効きます。
