タイム・コンサルタントの日誌から

MES（製造実行システム）を理解したいエンジニアのために 〜 この6編の記事で全体像が必ず分かる

前回もご案内したとおり、来る9月1日(木)に、MES＝Manufacturing Execution System（製造実行システム、ないし製造管理システム）に関する、総合的なシンポジウムを開催する。

『工場スマート化のための製造実行システム”MES”　―　広がる導入と実例に学ぶ活用方法』

　(参加申込み： https://www.enaa.or.jp/seminar/57017 ）

主催は(財)エンジニアリング協会で、わたしが幹事を務める『次世代スマート工場のエンジニアリング研究会」が企画立案している。オンライン形式で、参加無料である。幸いにも、すでに200人を超える申込みをいただいているようだが、まだ受付中なので、興味がある方はぜひご参加いただきたい。

◇- — -◇- — -◇- — -◇- — -◇

このシンポジウムは製造業の実務に携わる方を、主な対象として想定して、講演プログラムを依頼してきた。ところで、いまさらだが、これは本当に正しかったのだろうか？　というか、想定として十分だったのだろうか、という疑問が頭に浮かんできた。IT業界にいるエンジニア達も、MESシンポジウムの聴衆として考えるべきだったのではないか？

というのも、この種のシステムを構築する仕事は、通常、製造業の中だけで内製することは難しいからだ（よほどの大企業は別として）。当然ながら、外部のITエンジニアの力を借りる必要がある。良く知られているように、わたし達の社会では、ITエンジニアの7割はIT業界にいて、ユーザ企業には3割しかいない。その3割の人員も、殆どは本社にいて、人事・財務・販売そしてITインフラ系などの業務に従事している。

昨年10月に同じ(財)エンジ協会で行った、MESに関する第1回シンポジウムでのアンケート結果を見ても、工場にMES導入をリードする部署が見当たらない、という回答が、製造業からの参加者の81%を占めていた。普通この種の大がかりな、複数部門をまたぐシステムの導入を主導するのは、IT部門と考えられる。いいかえると、製造現場にIT部門がありません、という回答が8割以上、ということだ。

（ちなみに昨年のMESに関するアンケート結果は、今年のシンポジウムでも簡単にご紹介する予定だが、詳細なレポートは経産省のHPから見ることができる。『令和3年度 省エネルギー等に関する国際標準の獲得・普及促進事業委託費』という、いささかその中身を想像しにくいタイトルの報告書で、後半部分のP.22からアンケート結果が示されている）

工場にIT部門がないから、製造のデジタル化が進まないのか、それとも製造現場にデジタル化のニーズが乏しかったから、工場にIT部門がないのか。卵と鶏のような問題ではある。むろん、会社の規模にもよるだろうが、昨年の参加者は比較的大企業が多かった。だから、やはり製造系のITを引き受けるITエンジニアは、工場側には足りないのだ。

もちろんMESの普及は、IT業界にとっても重要なビジネスチャンスである。ただ、これまで製造現場というのは、IT業界にとって敷居が高かった。まず、業務が複雑で、分かりにくい。それも業界・業種による違いが大きい（人事や財務などは比較的、業種を超えて業務の共通性が高い）。しかも、PLCやらロボットやら、いわゆる制御系とも、お付き合いしなければならない。おまけに、遠い（工場はたいてい大都市ではなく地方にある）。

それはしかし、逆の面を見ると「参入障壁が高い」のだから、早くマーケットに入り込んで橋頭堡を確保してしまえば、過当競争で値下げ合戦、みたいな状況を避けられるはずである。

そこで、もし製造業の外で働くITエンジニアで、この分野に興味がある方がおられたら、ぜひ9月1日のシンポジウムにもご参加いただけたら、と願っている。ただ、そのためには、MES＝製造実行システムというものについて、少しは事前に予習ができると良いだろう。

そのために新たな解説記事を起こすことも考えたが、じつは当サイトでは、MESに関する記事を、過去それなりの分量で書いてきた。その中から、MESの位置づけや概要に関するエントリを6つ、選んでダイジェストを紹介することにしよう。いわば、多忙なITエンジニア向けの、「これだけ読めばMESの概要が分かる」6編である。

• 製造現場の業務を理解する2編
  

まずは、業務を理解できないとITの話は始まらない。そのために、まず読んでいただきたいのが、次の2本の記事である

１．「生産管理システムは生産を管理できるか」 (2022-01-18)

このエントリでは、工場長の仕事、ならびに工場を構成する各部門（製造/生産管理/資材購買/生産技術など）の仕事について解説している。主題との関係上、生産管理部門の仕事をとくに詳しく書いているが、それはまさにMESと関係が強い部分なので、読んでみてほしい。

なお、文章だけだと各部門の流れやつながりが分かりにくいと思うので、念のために図をつけておこう（本図は上述の経産省への報告書p.102でも引用している）。

２． 「『生産統制』の三つの課題」 (2017-11-23)

生産管理という仕事は、生産計画と生産統制の二本柱からなる（と、日本の生産管理学の教科書には伝統的に書かれている）。その割に、「生産統制」という言葉は、あまり製造業の実務では使われていない言葉だし、生産管理部の下に、「生産統制課」なるセクションがある会社は見たことがない。

ただし英語で、生産計画＝Production planningと、生産統制＝Shop floor controlと対応づけてみると、ずっと話は分かりやすくなる。PlanningとControlはセットだからだ。海図に航路の線を引く。これがPlanningである。実際に船を操舵して、航路の通り運行する。これがControlである。Planを持たずに海に出るのは無茶だし、操舵せずに船がまっすぐ進むと思うのは素人である。

そしてMESとは、非常に簡単に言ってしまうと、生産統制のためのシステムなのだ。まあ市販のMESパッケージには計画系の機能もあるのだが、日本ではあまり使われない（理由を書くと長くなるので別の機会に譲ろう）。ともあれ、Shop floor controlでは、(1)モノと情報のトラッキング、(2)資源モニタリング、(3)パフォーマンス計測が重要である、ということを書いている。

• MESの位置づけと三層モデルを理解する2編
  

３． 「ＭＥＳとは何か」 (2011-06-02)

ということで、10年以上前の記事になるが、まずはそのものズバリ「MESとは何か」である。MESの位置づけを理解するためには、1990年代にAMR Researchが提唱した、「三層モデル」の説明を省く訳にはいかない。もともとMESは、このモデルの第1層と第3層をつなぐ『ミッシング・リンク』として定義されたからである。

「MESのないスマート工場なんて考えられない」というのが、わたし達研究会の理解だ。それは、この真ん中をつなぐ第2層の仕事を、現在は人間系が担っているために、データが蓄積されないからだ。

三層モデルはその後、ISA-95という標準規格制定活動の中で、Purdue Modelと呼ばれる5層モデル（Level 0〜4まで）に置き換えられていく。MESはそのLevel-3を担うもの、と位置づけられる。

ちなみにISA-95（S-95とも略称される）は、MES＝Manufacturing Execution Systemという言葉ではなく、MOM=Manufacturing Operation Management、という用語を使っている。このため欧米でも、MESとMOMという、二つの言葉が使われていて、若干、分かりにくい現象を起こしている。

本来、S-95の立場では、MOMはMESより広義である（MESは製造のみだがMOMは品質・在庫・保全管理もカバーする）、とされる。だが先にMESの名前でパッケージ商品が生まれ、それが機能を拡張してきたので、必ずしもこの概念規定通りにはなっていない。なので、昨年も今年も、シンポジウムでは基本的に、MES/MOMと併記することにしている。

４． 「モノの『作り方を管理する』システムとは」 (2021-09-17)

このエントリは、実は昨年10月の第1回MESシンポジウムのお知らせ記事なのだが、個人的に愛着があるので、ここに取り上げさせていただいた。上記２の記事では、生産統制に３つのエレメントがある、と書いたが、その後でもう一つ、追加すべき事があるのに気がついた。それが、「モノの作り方」に関する情報、すなわちレシピと、SOP=Standard Operation Procedureである。

従来の生産管理システムでは、このレシピやSOPなどの粒度の情報はマスタとして持てなかった。かつ、制御システムだけでも、やりにくい。しかも、レシピやSOP（もっと広くいうとBOP=Bill of Processes）は、設計業務と深くつながっている。大量見込生産を旨とする米国と異なり、日本では少量多品種・設計変更多発だから、ここの部分をいかに人間系からデジタルに置き換えていくかが、重要な課題なのである。

• MESの主機能と構成を理解する2編
  

５． 「IoT時代のMESをもう一度考え直す 〜 (1) MES普及を妨げたもの」 (2017-08-19)

わたしが2000年に、共著で「MES入門」（工業調査会：版元倒産のため絶版）を書いたとき、すでにMESは4業種で広く使われていた。その4業種とは、半導体・医薬品・石油化学・自動車（最終組立ライン）である。そして、それ以外の一般的な産業にも広まるだろうと期待して、本を書いたのだ。

だが、そうはならないまま、過去20年間が過ぎた。その普及のボトルネックは、製造現場の制御機器・デバイス類との通信にある、というのが本エントリの主題である。そして、IoT技術の登場が、この問題を解決するだろう、と、(5年前に）書いた訳だ。

だがそれにとどまらず、この記事では、新しい仕組み・システムが普及するときは、どのようなパターンがあり得るかについても論じている。この視点から、今後のMESの再普及を占ってみるのも面白いだろう。

６． 「IoT時代のMESをもう一度考え直す 〜 (2) MESの機能と階層を理解する」 (2017-08-27)

このエントリは、５の続きである。この記事では、いわゆる「MESの11機能」と呼ばれるリストの解説から始まる。この11機能は、MESA Internationalという米国の団体が発祥の地だが、正直、分かりにくい。これが分かりにくいために、MES全般が分かりにくくなってしまった面さえある。

本エントリでは、なぜ、このような分かりにくさが生じたのかについて、プロセスとディスクリートという製造の二大分野を、一緒に標準に取り込もうとしたからだ、と分析した。そして、ARC Advisory Groupの最近のレポートで（といっても2017年のレポートだが）、Upper MES/Lower MESという新概念を導入したことを、前向きに評価した。実際、この区別は、とくにディスクリート系のMESを理解する上で有用と思われる。

以上、これら6本のエントリをお読みいただければ、MES/MOMに関わる全体像が、それなりに俯瞰できるはずである。もちろんそのためには、ERPだとか、データモデルだとかいったものが、ある程度分かっている必要があるが、そこはまあ、ITエンジニアだったら敷居は低かろう。そこを踏み越えれば、あなたは今、MES/製造実行システムの玄関口に立っているのである。

お知らせ：MESに関するシンポジウムを9/01に開催します

MES（製造実行システム）なるものが最近、急速に普及している、と聞く。工場での製造のマネジメントにかかわる仕事を、見通しよく・素早く・楽にしてくれるそうだ。「スマート工場化」の流れにも合致して、現場の生産性向上に貢献するらしい。

ただ、具体的にどんな仕組みなのかが、今一つ分かりにくい。製造現場の事情に明るい「デジタル人材」は社内に少ないし、参考になる情報も限られている。誰に相談したら良いだろうか？

・・こんな風に思い悩んでおられる、製造業や関連産業の皆様のために、（財）エンジニアリング協会「次世代スマート工場のエンジニアリング研究会」は、9月1日にシンポジウムを企画しました。

タイトルは、『工場スマート化のための製造実行システム”MES”　―　広がる導入と実例に学ぶ活用方法』。オンライン形式で、参加費用は無償です。

本シンポジウムは午前・午後１・午後２の３部からなり、総勢14名の講演者によって、事例中心の実践的な報告・紹介が行われます。業種も機械・食品・電機・半導体など幅広く、国内・海外の最新ユースケースや、中小企業の動向、そして国際標準の動きなども解説される予定です。

当研究会では昨年10月にもMESの製品紹介を中心とした半日シンポジウムを開催しましたが、今年はユーザ側の具体的事例を中心に、さらにパワーアップしたイベントといたします。

開催案内と参加申込みはこちらのページです：

　エンジニアリング協会HP　https://www.enaa.or.jp/seminar/57017

---

・・さて、普通のお知らせならここで終わりなのですが、小生は本プログラムの仕掛け人なので、各講演のポイント・聴き所を、当サイトの読者の皆さんだけに内緒で教えてしまいましょう（内緒ですよ、ホント）。

10:00-　「開会挨拶/シンポジウムの狙い」は、慶応義塾大学管理工学科教授・松川弘明先生（当研究会主査で、日本経営工学会の前会長でもあります）のオープニング・アドレス。日本の生産物流とSCMの権威である松川先生から、ピリッとしたお言葉をいただけるはずです。

10:10-　「基調講演」は、経済産業省の製造産業局より講師をお招きする予定です。「ものづくり白書」を担当する部署でもありますから、日本のものづくりの実力と課題について、オーバービューをお話しいただけると期待しています。

10:20-　「基調講演　昨年のシンポジウム成果報告ほか」は、野村総研の藤野直明氏・藤浪啓氏と、わたしとで分担し、昨年実施した『MES導入動向調査』（←METI報告書の後半部分）の結果などについてお話しします。

10:40-　講演A「食品工場におけるMESの機能概要と導入事例」をお話しいただくのは、現在M2 Technology(株)社長で、博士（工学）の松本卓夫様です。松本様は前職で、国内最新鋭の大規模な乳製品工場・物流センターを構築されたプロマネです。MESと製造ラインの制御システムのアーキテクチャについても、独自の考えを披露いただけるはずです。

11:20-　講演B「日立が考えるスマート工場実現のためのデータ・システム活用」。日立製作所の大みか工場は、世界経済フォーラム（ダボス会議）がマッキンゼー社と協力して選定した、世界の「Lighthouse（灯台）工場」に、日系企業として唯一入っている旗艦工場です。吉田秀信様に、とくにデジタルの面を語っていただきます。

13:00-　講演C「『スマートファクトリ』から『ものづくりDX』へ」は、工作機械メーカーの雄、オークマ（株）の領木正人副社長による、本社工場「Dream Site」実現の取組のご紹介です。 領木様はわたしの尊敬する論客で、同社のDream Siteは機械加工組立系スマート工場のトップランナーの一つと信じます。

13:40-　講演D「国内製造業における生産システム投資動向」は、（株）日本政策投資銀行の産業調査部で、ずっとスマート工場を追いかけておられる佐無田啓様のご講演で、主に中堅・中小企業の投資動向と、金融機関から見たポイントなどをお話いただける予定です。

14:00-　講演E「生産設備メーカーから見たMES」は、知る人ぞ知る製造ラインビルダー業界の雄・平田機工（株）の神田橋嗣充様による、主に海外のMES論です。同社は半導体・自動車・電機の3分野で、世界トップクラスの製造業に、工場の生産設備ライン一式を設計・納品して来られました。その目から見たMES像、個人的にも大変期待しています。

14:40-　講演F「中小製造業におけるクラウド型MES導入事例」は、Rockwell Automation Japanの鈴木聡による、主に米国における組立加工系でのMES活用事例のご紹介です。自動化と制御分野に強い同社による、製造管理・MES系ソフトウェアの事例を聞ける予定です。

15:00-　講演G「設計・製造・オートメーションにわたるシーメンス自社工場適用事例」は、ドイツにある同社のErlangen工場での取組紹介です。同社はMESベンダーでもありますが、個別受注生産の制御システム製造にMESを適用するには、どんな知恵が必要だったか。独Industry 4.0の牽引役であるシーメンスの工夫をご覧ください。

15:30-　総括講演「生産システムDX化の鍵を握るMES国際標準の概要と動向」は、全体の締めにふさわしく、エンジ協会でも活躍中の国際標準化コンサルタント出町公二様に、MES/MOMの国際標準ISA-95を解説いただきます。

ということで、当分野に通暁した第一線の講師陣をお招きし、全3部構成・1日がかりのシンポジウムをオンラインで提供します。全体を聞いていただいても、興味ある部分だけに参加いただいてもかまいません。アンケートに回答いただいた方には講演資料を共有いたします。

自分で書くのも何ですが、内容のレベルには自信あり、です。唯一少しだけ心配なのは、盛りだくさんすぎて、時間が足りなくなりそうな事でしょうか。その場合、佐藤のムダなしゃべりは早く切り上げ（笑）、招待講演にできるだけ時間を回すつもりです。ともあれ、製造現場のデジタル化と情報化のコアとなる、「MES/MOMシステム」の導入構築に関心をお持ちの方に、役立つ場を提供する所存です。

ぜひご参加ください。

佐藤知一@日揮ホールディングス（株）

それは仕様ですか、性状ですか？ 〜 マスタ構築に見るデータ・リテラシーの勘所

• モノのマスタ・データは、どの部署が登録維持すべきか
  

先日あるところでBOMに関するお話をしたところ、聴衆の方から興味深い質問を受けた。

「BOMのマネジメントでは、マテリアル・マスタを全社で共通に使うことが大事とのお話、確かにその通りだと思いました。自分の会社では、ERPのマテリアル・マスタに品目を登録するのは製品設計部門の仕事ですが、どうもいろいろと問題が起きています。マスタ登録の仕事は、どこの部門が担うべきだとお考えですか？」

ものづくりに関わるマスタ・データの登録保守は、製造業の組織で、一体どこが受け持つべきなのか。これは「データ・ドリブン経営」だとか「製造DX」などの活動を現実化していく上で、重要な問いだろう。さらに一般化していえば、『マテリアル・マネジメントの業務』は、どこが責任を引き受けるべきなのか。皆が悩んでいる問題だ。

ただ、質疑の時間は限られていたし、この方がどの業種か良く知らなかったので、「一般論ですが」という但し書きをつけて、お答えした。

「結論から言いますと、部品などの品目の登録は、製品設計部門よりも生産技術部門の方が適していると思います。なぜなら製品設計部門は、部品の具体的な作り方については、あまり詳細を知らないのが普通だからです。それを知っているのは、製造方法と生産工程を決める、生産技術部門です。」

新規登録すべき部品について、買ってくるのか作るのか、作るなら何からどう作るのか、他の似た部品と何が違うのか。そうしたことが判断できないと、マスタを適切に登録管理できない。もちろん組織の形や機能は、企業によって違うし、生産技術部門がない会社だって存在する。だからこれが唯一の正解だと言うつもりはないが、ヒントにはなっただろうと想像する。

• 品目コード問題があぶり出す、基本的データ・リテラシーの欠如
  

同じ仕様の部品だが、異なるサプライヤーから納入されるモノは、区別して登録すべきなのか。同一モデルだが仕向地が国内と海外の場合は、別のコードを立てるべきなのか。購入品と自社で内製する場合は、区別すべきか。これらは、品目コードに関してよくたずねられる質問である。

こうした疑問が積もり重なっていくと、本社と工場で違うマスタを維持したり、設計部品表（E-BOM）と製造部品表（M-BOM）が乖離していく問題が生じがちである。同じ一つの会社の中で、本社と工場が、あるいは事業部と事業部の間で、同じ筈のモノを、別の品目コードで呼んでいる事態が非効率で不合理なことは、誰でも分かる。分かるのに、しばしばそうした状況が放置されている。

「しょせん、コード程度の問題」と、たかをくくっているのかも知れない。製品戦略とか、拠点展開とか、情報システム・アーキテクチャ変革といった、高度な問題に比べれば、マイナーな問題、と（外資系戦略コンサルだったら、きっとそう言いそうだな）。

だが、わたしの見方は違う。マテリアル・マスタ（品目マスタ）に関する問題を、あちこちの会社で聞くにつけ、これは日本企業における基本的な『データ・リテラシー』に関する、ある種の欠如を表しているのだと感じるようになった。

データはあらゆるシステムの基礎、基本である。計算機内のデータは普通、キーとなるID（識別コード）と、その属性の値の並び、という形式になっている。ところが、その属性データが、仕様なのか性状なのかについて、曖昧になっている。というか、属性データは基本的に、「仕様」と「性状」に区別される、という原則の理解（リテラシー）が、ユーザ一般に欠けているのだ。

いや、下手をしたら、データの専門家であるITエンジニアさえ、理解できていない可能性さえある。そんな状態で、データ・ドリブン経営など（それが何を意味するにせよ）あったものではあるまい。

• モノのデータには二種類ある
  

モノを扱うデータには二種類ある。一つは、「機能（要件）」に関するデータ、もう一つは、「物体（実在）」に関するデータである。

たとえば自動車には、前後で4つの車輪がある。4つの車輪は、別々の機能を持っている。ただし、そこに装着 (install)される物体は、全部同じタイヤである。物体としてのタイヤは、前後左右で、交換可能である。

機能のキーは、機械図面でいえば①②といった番号（俗にいうフーセン）であり、プラント業界の用語でいえばTag No.である。SAP R/3ではこれを抽象化して"Functional Location"と呼んでいた。他方、物体のキーは、Serial No.やLot No.である。

当然、キーがちがうのだから、もつ属性の意味も全然別のものである。同じ「内径」でも、前者は「4mm以内であること」という要件が規定され、後者は「測ってみたら内径3.9mmでした」という現実が記載される。

「このモノはかくあるべし」と規定した条件が、「要求仕様」Required specificationである。一方、「このモノは実はこんなです」と、（測定結果を）記述したのが「供給性状」Supplied propertyだ。前者が「機能（要件）」に関するデータ、後者が「物体（実在）」に関するデータになる。

そして、製造とはまさに、この「機能」と「物体」とのlinkを生成する行為に他ならない。

「機能」的なモノは観念や設計図の中にのみ存在して、目には見えない。目に見えるのは、個別の「物体」である。もしそう呼びたければ、前者はクラスであって、後者はインスタンスと言ってもいい。あるいは西洋哲学風に言えば、前者はイデアであって、後者は個物にあたる（そう、ITの認識論の背後にはつねに西洋哲学がある）。

• マテリアル・マスタとは何を記述したデータか
  

さて、それでいったい、マテリアル・マスタとは、どちらを記述したデータの集合なのか。機能（要件）なのか、物体（実在）なのか。

ここで、「従業員マスタ」はどうなのかな、などと考えると、興味深いかも知れない。従業員マスタは、従業員コードがキーになって、氏名だとか生年月日だとか教育履歴だとかいった属性値が並んでいる。そう、具体的に存在するインスタンス、個物（いや個人）のデータである。

だったら、マテリアル・マスタも実在する物体のデータではないか！　などと考えるかもしれぬ。だが、答えはまったく逆なのだ。マテリアル・マスタとは、目に見えぬ、実在しない、要件の集合なのである。

どうしてか。それはまさに、部品表（BOM）データを考えてみれば分かる。部品表はいわば、組織図だ。BOMは部品と部品の従属関係を表している。BOMで参照する部品コードの元が、マテリアル・マスタである。

たとえば、企業における組織図を考えてみてほしい。仮にあなたが部長職になって、担当役員から「自部門の望ましい組織図を設計しろ」と言われたら、書くのは、“技術部長－機械設計課長－設計第二係長”・・という職名（はたすべき機能）の図だろうか？　それとも、“佐藤部長－鈴木課長－田中係長”・・という人名を並べた図だろうか？　

答えは当然、前者であろう。人の名前は変わりうるし、異動や退職もするかもしれない。だが職名（あるべき機能）と、その間の従属関係は変わらない。職名は、存在しない・抽象的な・機能につける標識である。人名は、実在する・具体的な・個物（個人）につけられた名前だ。組織を設計するとしたら、機能（職務）とその関係を設計するのであり、その参照先である職務リスト（＝モノの世界では品目マスタに相当する）は、抽象的な職務とその記述が並ぶのだ。

同様に、マテリアル・マスタとは、“必要なマテリアル”の名称と属性が並んでいる表をあらわす。すなわち、「要求仕様」の一覧表なのである。存在しない抽象的なモノ（＝要求仕様の集合体）を列挙したテーブルなのだ。

ここまで理解できれば、異なるサプライヤーから納入されるモノは、別に登録すべきかどうか、わかるだろう。それらがどちらも自社の要求仕様を満たしているなら、その二つは同一のマテリアルである。無論、価格や納期は違うかも知れない。だがそうした属性は、マテリアル・マスタではなく、（品目コードと調達先コードを複合キーとした）調達情報マスタに記述すべきである。

同一モデルで、仕向地が国内と海外の場合、もし満たすべき仕様が異なるのなら、別のコードを立てるべきである。購入品と自社で内製する場合、製造上で差が無いなら（互換性があるなら）区別は不要である。

なお念のため書くと、実際の供給性状を記録したければ、それは製品品質を製造ロット番号やシリアル番号に紐づけた履歴データに記録すべきである。それはそれで、もちろん有用だ。だが、マテリアル・マスタとは、別ものである。

こうした、「仕様」と「性状」の違いは、もちろんエンジニア達には「いわれてみれば当たり前」であろう。違和感はないと思う。ただ、それをデータ化する際、どちらに該当するのかが曖昧だと、後々そのデータを利用しようとする人にとって混乱の元となりがちだ。

そして、こうしたことは、データに関するリテラシーの基本に属するのだ。わたしが常日頃、「ITリテラシーよりも大切なのは、データ・リテラシーである」と主張しているのも、こうした非効率を避けたいがためなのである。

＜関連エントリ＞

　 (2022-07-09)

工場づくりに関する連載記事開始のお知らせ：月間「工場管理」8月号より

お知らせです。日刊工業新聞社の月刊誌「工場管理」8月号（7月20日発売予定）より、

　『ゼロから始める新工場づくり』

と題する連載を開始します。わたしの勤務先の同僚で、ネクストファクトリー・ソリューション部の部長である丸山幸伸氏との共著で、全18回の予定です。雑誌は電子書籍でも購入可能です。

「工場管理」誌には、今年の3月・4月号にも、製造実行システム（MES）に関する記事を執筆しました。これは主に工場のデジタル化の側面について、自身の知見ならびに経産省からの受託調査の結果をもとにまとめたものです（こちらからもダウンロードできます）。幸いこの記事は好評だったようで、編集部から、より広い視野で工場づくりに関する連載記事を書いてくれないかと依頼を受けました。

もちろん、よろこんでお引き受けすることにしましたが、わたし自身は何年も前から経営企画部門におり、工場プロジェクトの現場業務からしばらく遠ざかっています。そこでこの分野に経験の深い、同僚の丸山幸伸氏と一緒に、執筆に取り組むことにした次第です。

ところで読者の皆さんが、ご自分の家を建てるとしたら、どこから考え始めますか。ちょっと想像してみてください。宝くじに当たって、大きな賞金を得たとしましょう。一生食べていけるほどではありませんが、家一軒を土地付きで建てるには、十分な金額だとします。せっかくですから、建売りではなく、自分の望む、ゆったりとしたオリジナルな家を考えてみたい。細かな設計は建築士に依頼するとしても、大きなプランは自分で決めたい、と思います。さて、皆さんなら、どこから考えますか。

まず、台所から考えよう。レンジなど最新の厨房機器を揃えて、冷蔵庫のサイズは大きめ、そして流し台のレイアウトは・・などと思う方は、たぶん、かなり少ないんじゃないかと思います。もちろん、台所は生活の必需機能です。また、家の中で一番、設計的に込み入った場所です。さらに、自分は料理が趣味だ、という方もおられるでしょう。でも、たとえそんな方でも、新しい家の構想を、台所という部分から考え始めるでしょうか？

いやいや、台所はどうでもいいが、自分だけの書斎が前からほしかったんだ、だから最新鋭のパソコンと大型ディスプレイを買って配置して、机はこうして、音声機器や無線LANは・・といった話を、当たりくじを前にして始めたら、ご家族はどう思われるでしょう？　それがたとえ寝室や風呂でも、同じことです。

ふつうだったら、まず、家はどこに建てようか？　どれくらいの大きさが良いか、家族の人数からいって、何部屋くらいあれば十分か？　そんな風に考えるのではないでしょうか。

つまり、何か新しいものや仕組みを構想する際は、まず全体像から入り、ついで個別の要素について検討するのが、当然の順序でしょう。最初に台所や書斎などの部分から、それも機器のスペックや構成を真っ先に検討してから、その入れ物としての建物を考える、というのは、なんだか奇妙に感じられます。

ところが、この不思議なことが、工場づくりに際しては、しばしば見受けられるのです。

何年か前に、ある独立コンサルタントの方にインタビューしました。電機系の一流企業の、生産技術畑出身の方です。工場設計の手順についておたずねしたところ、まず製造のための加工機を何台、ラインに配置するか、その性能とスペックをどうするか、で話が始まりました。あとは適当にスペースをとって、それを収容できる建屋をつくれば良い、と。

でも、モノはどこに置いてどう搬送するのです？　エネルギーや用役の供給の最適化は？　ICTのための通信とデータは？　そして働く人にとって最も重要な、執務空間の快適さをつくりだす建築のあり方は？　・・でもこの方にとって、工場の中核機能は製造であって、その他のことは付随的な問題にすぎない、という感覚でした。

ちなみに、日本の多くの企業では、なぜか「機械設備は生産技術部門、建屋は総務部門の所掌」となっています（この方の所属していた会社もそうだったようです）。そんな企業で新工場づくりに取り組むとき、典型的に起きるのは、三つの流れが並行して進む形態です。

図をご覧ください。真ん中にあるのは、主要な製造機械に関する設計の流れです。生産技術部門が基本設計し、機械メーカーを選定して詳細設計を進め、さらに補助製造設備等を選びます。それと並行して、左には建築系の設計の流れがあります。総務部門が、設計事務所をつかって、基本レイアウトを決めます（といってもおさめる機器はまだ決まっていないのですから、体育館のようなスペースがあるだけの建屋です）。ついで実施設計はゼネコンに任せます。他方、右側にあるのは、物流設備の設計の流れで、ここは生産技術部門が物流（マテハン）メーカーの支援を得て、すすめるのが通例でしょう。

そして、これで全体がフィットすればOKです。しかし、まま起きがちなのは、レイアウトにおさまらなくて再調整、です。つまり三つの流れが元に戻って、やりなおしとなる訳です。これを避けたければ、機械 – 建築 – 設備の間の取り合いに、余裕を見ておくしかありません。つまり、余計なコストです。

とくに建築と機械の設計が別々に動く訳ですから、拡張性やレイアウト変更が容易でない空間構造になりがちです。日本は敷地が狭いため、多層階の工場がふつうです。そのため、しばしば動線が縦に分断されます。

よく言うのですが、もし家の台所が、1階に流し台と冷蔵庫、2階にガスレンジやオーブン、という風に分かれていたら、どんなに不便か想像がつくと思います。ところが、工場ではそんな縦割りの物流動線とレイアウトをよく見かけますし、働いている人達は不便とも思っていなかったりします。なぜなら、最初からそういうものだと思って、働いているからです。

このように、バラバラにすすめられる物流動線とレイアウト設計は、結果として、見えない非効率の温床になりがちです。それは、最初に主要素（製造機械）を設計してから、全体のシステム（レイアウトや物流）を考えるという、順序の問題から生まれるのです。

全体を考えてから要素に落とし込む、という思考の順序は、『システムズ・アプローチ』の中心にあたります。わたし達エンジニアリング会社は、少しカッコつけて申し上げると（笑）、工場づくりのシステムズ_エンジニアリングと、プロジェクト・マネジメントを専門にしている業種です。ですから、この18回の連載の中で、よりベターな結果を得られる工場づくりのプロセスについて、一緒に考えていきたいと思っています。

なお、「工場づくりと言っても、自分の会社は新工場の企画なんてないし、自分がその責任者になる可能性もないから、関係ないや」と感じられる読者も多いかと思います。ただ、そういう方も、今ある工場のハード・ソフト・運用については、いろいろ改善課題を意識されているのではないでしょうか。

ちょうど、自分の新しい家をゼロから空想してみると、今の住まいの改善点が見えてくるように、新しい工場を構想してみるのも、システム的な思考の訓練として、有用であろうと信じます。この連載記事が、より多くの読者の方の眼に触れるようでしたらまことに幸いです。

佐藤知一@日揮ホールディングス（株）

それは仕様ですか、特徴ですか、ソリューションですか？

「それは仕様ですか、特徴ですか、ソリューションですか？」

次のスライドは、わたしが社内のエンジニア教育用に作った資料の一部である。質問は5問からなっており、いずれも3択問題だ。さて、皆さんなら何と答えるだろうか？

エンジニアで、客先への対応に悩む人は数多い。要求が曖昧模糊としている、気難しい、あるいはすぐ気がが変わる、いや、それどころか、技術をよく知りもしないのに無茶な要求をしてくる・・。

「そういう難しい顧客への対応は、営業の仕事さ」と言い切れる会社や、営業が身を呈して技術を守ってくれる会社に働くエンジニアは、幸せだろうな、と思う。だが大抵の場合、技術的なことに関しては、技術屋がいって説得しなければならない。それどころか、技術リッチな業種では、そもそも売り込み段階からエンジニアが営業に同行して、あれこれと説明したり提案したりするのが普通である。

さて、上記の問いにあげた５つの文章は、いずれもシチュエーションが共通している。いうまでもなく、「お客様に何かを説明しようとしている」文章だ、ということだ。つまり、一種の説得ないし売り込みの状況なのだ。お客様に何かを選んでいただく、決めていただく際に、仕様・特徴・ソリューションの3種類を、意識して使い分けられているかを、上の問題は問うている。

もちろん、この問題に答えるためには、「仕様説明」「特徴説明」「ソリューション説明」が、それぞれ何を意味するかを知らなければならない。仕様も特徴もソリューションも、わたしたちエンジニアが日常的に使う言葉だ。とうぜん皆、知っているつもりであろう。でも、その違いを説明しろと言われて、きちんと答えられるだろうか？

仕様とは、基本的にニュートラルなものだ。それは対象の製品なりサービスなりが、具現化すべき属性を規定している。横幅は50mm以下だとか、素材はステンレスSUS-316Lにしろ、とか、実効通信速度は30 Mbps以上あるべし、といった類いだ。

もちろんステンレス鋼は炭素鋼より値段が高いし腐食に強いから、高級な材料と言ってもいい。だが高級だとか高価だとかは、仕様が問題にすべきことではない。製品・サービスが性能を果たすために必要な条件を規定するのが、仕様だ。データ量から見て、通信速度が10 Mbpsで十分なら、30 Mbpsなどとムダに増量しない。そういう意味で、価値判断からニュートラルなのが、仕様だ。

ちなみに仕様は、形状・素材・構造など「つくり」に関わる条件と、性能・安定性・耐久性など「はたらき」に関わる条件の、2種類に分けることができる。「50mm以内」は、形状すなわち「つくり」に関する仕様で、「30 Mbps以上」は「はたらき」についての仕様だ。

そして設計とは、「はたらき」（＝機能・性能）を実現するために、「つくり」（＝形状・構造）を決める仕事である。だから品質機能展開に見られるように、はたらき系の仕様を先にきめて、それを、つくり系の仕様にブレークダウンしていくことになる。

そしてユーザの立場から見れば、本当は「はたらき」だけを約束してくれれば十分なのだ。だが、性能とか安定性・耐久性といった尺度は、実は非常に多元的なもので、ユーザや作り手があまり想定しないような使用シチュエーションもありうる。そうした際にも、製品が有用となり、害をなさないように、「つくり」に注文をつけておくことが、しばしば起きるのである。

では、特徴とは何か？　特徴とは、いうまでもなく、「他との際だった違い」を表す属性だ。つまり何か他に比べるべき製品・サービスがあり、それとの違い、それも優位な違いを示すのが、特徴である。世の中の普通や、比較する相手がなければ、特徴はいえない。もしも「50 mm以内」が競合製品に比べて優位に小さいなら、それは特徴と言って良い。

ただ、特徴を説明する時は、その違いを強調するようなニュアンスが必要だ。だから「この装置にはオプションが12種類あります」では、ただのニュートラルな仕様説明になってしまう。せめて、「この装置には12種類ものオプションがあります」と言わないと、特徴を訴えることにはならない。

では、ソリューションとは何なのか。この言葉は、昔はIT業界専用の用語だったが、今はずいぶん広い範囲で使われている。「お客様への最適なソリューションを提供します」「わが社はソリューション・プロバイダーとして・・」などなど。ただ元々の意味は、『解決』である。すなわちソリューションとは、問題解決に役立つものでなければならない。誰の問題？　もちろん相手（客先）の、である。

問題というのは、「本来あるはずの姿」と思っている事と、現実のとの間にギャップがある状態を指す。ちゃんと製品を納品した。ところが顧客は「品質不良だ」と突き返してきた。たしかに、これは問題だ。

ただし問題とは、当事者がそう意識していなければ、問題にはならない。電車が5分遅れた、問題だ、と感じるのは、電車が時刻表通りに来るのが当然だ、という社会にいるからだ。あなたが中東や南米で生まれ育ったら、5分遅れは上出来じゃないか、と感じるかもしれない。

「弊社の設計部門は、お客様のご要望でしたら何でも承ります」は、ソリューションの説明だろうか？　それは、顧客が「近頃の業者は設計への要望を、こころよく聞いてくれない」という問題意識を持っていることが明白な場合だけ、ソリューション説明になる。あるいはせめて、「同業他社は設計への注文をあまり聞かないのが普通だ」という業界認識があるなら、特徴説明になろう。もし、どちらも不確かならば、それは単なる仕様説明でしかない。

そして、ここまでの説明を読んでこられた読者ならば、すでにご賢察のことと思うが、他人に何かを提案し、説得し、選んでもらうためには、「ソリューション説明」でなければならないのだ。繰り返すが、仕様説明はニュートラルなものである。また特徴説明は、他との違いをいいはするが、それが相手のニーズ・問題意識にマッチするとは、限らない。人が何かを選び、何かを買うのは、自分のニーズを満たし、自分の問題を解決してくれるとの希望を持てる場合に限る。

ここまでにあげた仕様・特徴・ソリューションは、よくマーケティングの分野で言われるFAB、すなわち「フィーチャー」「アドバンテージ」「ベネフィット」の概念に、ほぼ相当する（なお、これに「エビデンス」を加えて、FABEと呼ぶケースもある）。

ちなみに、マーケティング分野では、顧客にはまずベネフィットから説明しろ（Start with Why）、それからアドバンテージ（How）・フィーチャー（What）を補足しろ、とアドバイスする。なぜなら顧客は忙しく、辛抱強くこちらの言葉に最後まで耳を傾けてくれるとは限らないからだ。だから一番訴えかける、大事なことを先にいえ、と。

そして、このアドバイスは、顧客に提案するとき以外にも通用する。たとえば、上司を説得するとき。予算の追加や人の配員を求めるのには、まず上司の説得が必要だろう。また、社内に新しいことを提起するときもある。仕事のシステムを変えたり、取組への協力を求める際も、やはり「抵抗勢力」を説得しなければならない。

こう考えてみると、エンジニアの仕事では、単なる顧客への対応を超えて、いろいろな場面で「アイデアの売り込み・説得」、すなわちマーケティングのためのコミュニケーション・スキルが重要になるのだ。

最後に、ちょっとだけ頭の体操をしてみよう。

「他のみんなも使っています」

「競合他社も皆やっています」

という文章は、仕様だろうか、特徴だろうか、はたまたソリューションだろうか？　この言葉は、現実にはけっこう有効な、セールスの殺し文句であったりする。

たとえば例を考えてみてほしい。誰もが持っているもの、あって当然だと感じるもの、たとえばスマホでもいい、車のカーナビでも良い。あるいは企業にとってのERPでもいい。どれも昔はなかった。

だが、「今ではみんな使っています」は、単純な仕様でも、特徴の説明でも、ソリューションでもなさそうな気がする。どれでもなかったなら、いったい何なのか？　そして、なぜ、それがマーケティングの切り札になりえるのだろうか。霞ヶ関の人の話では、「同じ施策を中国でもやり始めています。このままでは追い抜かれます」が、今や予算獲得の一番のセールスポイントなのだそうだ（苦笑）。もしもこれがソリューション説明だとすると、わたし達の抱える「問題」とは何なのか。

問題とは、「当然あるはずの姿」と、現実とのギャップのことだった。わたし達の『当然』とは何で、それは言語化されているのかどうか、たまには立ち止まって考えてみるのも、有益ではないだろうか。

＜関連エントリ＞

　 (2021-06-19)