富士ゼロックスのモノづくり改革
田中俊毅氏（以下、田中）：みなさん、こんにちは。富士ゼロックスの田中と申します。よろしくお願いします。
まず、私の自己紹介を簡単にさせてください。私は富士ゼロックスの工場でずっとIT部門にいまして、最初はFAを10年ほどやっていました。それから基幹システムと、グループウェア等のコミュニケーションシステム、それからSCMみたいなシステムですね。それからここ5～6年は生産現場の見える化をやってきています。
私はずっとITをやってきたんですけれども、けっこう失敗したことが多くて、そのたびにある種のITの限界を感じていました。
その頃「IE」というものをやったんですね。ご存じない方がいらっしゃるかもしれません。Industrial Engineeringというんですけれども、一言でいうと、ちょっと乱暴な言い方をすれば、ムダ取りの学問ということだと思います。そういうものをやっていました。
私はIEの専門の先生に15年ほど教えていただきました。私が教えていただいたというよりは会社自身が教えていただいて、私はIT部門に所属しながらIEの事務局をやっていたんですけれども、その中で先生に教えていただいたことは、「IEの本質とはいったいなんなのか？」ということですね。IEって、物事の前提条件や制約条件を壊すもの、あるいは、なくすもの、緩和するもの。そういうものだということを学んだんですね。
私がやっていたことは、今の前提条件や制約条件をまったく変えることなく、その中でそのまま自動化しようとしていました。もし制約条件や前提条件を変えることができるのであれば、もっと軽いITができただろうし、もっといいITができたのではないかと思っています。
その後、2年ほど前に今のプロフェッショナル・アドバイザー部という部署に移りました。ここは何をしているかというと、「工場のラインの改革はいいから、そこで培った知識や経験を富士ゼロックスの営業部門に生かせ」ということで、今、富士ゼロックスの営業と一緒にお客様の課題解決のご支援をさせていただいているという立場になります。よろしくお願いします。
今日はみなさん、富士ゼロックスにおける最新の事例を聞けるのかなと思っているかもしれないですけど、全然そんなことはなくて。けっこう古い事例をお話しさせていただきます（笑）。
最近の事例というのは、先月行われた「FACTORY 2017 Fall」や、『日経ものづくり』などでご紹介させていただいています。 このFACTORY Fallでは、モノ作り本部長の生駒がお話をさせていただきました。タイトルには「モノづくり改革とスマート工場への取り組み」と書いてあります。「スマート工場によるモノづくり改革」とは書いていないんですね。
この「と」というところが大事だと思っていて、富士ゼロックスとしては、今の段階ではモノづくり改革に重点を置いているようなところがあります。そのベーシックなところを今日はお話をさせていただきたいと思っています。よろしくお願いします。
IT以前に現場力を重視する
さて、見える化の通説というものがあると思うんですけど、どんなものかというと、「まず見えるようにしましょう」と。見えたら気づく。気づけば行動するとよく言われます。私もこれはそうだと思っています。
実は私がこのプロフェッショナル・アドバイザー部に移ってから、この半年間で30社の以上のお客様の工場を回らせていただいて、半分ぐらいは工場見学もさせていただいたんですね。そこでお客様の課題や悩みを聞いていくうちに、だんだんこの通説が疑問に思えてきて、「本当なんだろうか？」と思うようになってきたんです。
それはどういうことかというと、実はこの通説が成立するためにはある前提条件があるんじゃないかと。その前提条件というものが世の中ではまったくクローズアップされていなくて、それなしで「見えればなんでも気づいてハッピーな世界が訪れるんだろう」と思っていたら、「そんな甘いもんじゃないよ」という落とし穴にハマってしまう。「いろいろなツールを入れたけどうまくいかないね」ということに陥ってしまっているんじゃないだろうかと思っているんです。
私は、先ほど申し上げたQC（Quality Control）やIEという現場力が（前提条件として）すごい大切で、その土台、基礎があってはじめてITが生きてくるのではないかと考えています。これがないと、ムダをムダと認識できないと言うんですかね。見えても気づかないということがあると思っています。
例えば、ムダを見える化するシステムをデザインしようとしたときに、当たり前なんですけど、「ムダとはなんなのか？」がわかっていなかったらムダが見えるようなシステムをデザインできるわけがないんですね。ということは、当たり前ですけれども、ムダというものに対して勉強しないことには、ムダの見える化はできないんです。
それを勉強した人が作ったとしても、勉強していない人が、他人が作ったムダが見える化されているはずの画面を見ても、なにも気づかない気がしてきているんです。
なので、やはりQCとIEという土台がまず非常に大事で、その上で先ほどのような方程式（通説）が成立するのではないかと考えています。
私たちの工場はそこに非常に重点を置いています。日本能率協会さんが毎年表彰しているGOOD FACTORY賞という賞があるんですが、先月、富士ゼロックスマニュファクチュアリング鈴鹿事業所が、パナソニックさんやトヨタ紡織さん、ダイキンさんなど数々の有名な大手さんと一緒に表彰していただきました。
（GOOD FACTORY賞の中の）ファクトリーマネジメント賞という賞をいただいたんですが、そこでの表彰ポイントは、非正規の従業員も含めて改善活動が非常に定着している、そういう文化が醸成されている、そういうマネジメントができているというところを評価していただいたと聞いています。
2011年には、中国にあります富士ゼロックス深圳もこの賞をいただいています。そのぐらい私たちは、IT以前に現場力というものを重視しているという文化があります。
キーとなる重要な部品を作る鈴鹿事業所
さて、では具体的に今日の見える化の事例をご紹介するんですが、その前に、今日の舞台である富士ゼロックスマニュファクチュアリングという会社を簡単にご紹介させてください。
富士ゼロックスマニュファクチュアリングには工場が4つありまして、新潟と富山と、小田原の近くにある竹松。それから三重県鈴鹿にある鈴鹿工場。私はそこの出身なんですけれども。4つ工場があります。
このうち竹松事業所は富士ゼロックスの直営の工場だったんですけれども、ほか3つの工場は別会社だったんですね。それを2010年に統合しまして富士ゼロックスマニュファクチュアリングという会社ができました。したがって、今、富士ゼロックスという会社自体は生産機能は持っていません。富士ゼロックスマニュファクチュアリングが富士ゼロックスの国内の生産事業会社という位置づけになっています。
作っているものは、富山と竹松はプラント型の工場になっていまして、トナーや、トナーを入れてあるカートリッジのアセンブリ。ほとんど自動化されていますけれども、そういった工場です。
新潟は、ここにありますように、かなり大型の業務用のカラーレーザープリンタを作っています。今日の舞台である鈴鹿はなにを作っているかというと、この絵はプリンター複合機の部品、原理図が描いてあるんですけれども、この1番から5番までがゼログラフィの原理なんですね。そのゼログラフィの原理にもとづいて紙に写真や字が出てくるわけなんですけれども、その重要なキーとなるプロセスを担っている部品を作っている工場が鈴鹿事業所です。
今、富士ゼロックスでは、この最終のお客様にご利用いただいているプリンターや複合機は、日本国内でほとんど作っておらず、中国およびベトナムのほうで作っています。部品をほとんど日本で作って、海外に輸出してアセンブリして、国内消費分は戻すという流れになっています。
今日の事例は、それぞれのプロセスでいろいろな見える化を行っているんですが、今日は、時間の関係上、この全体をコントロールしている電子基板のアセンブリのところの事例をご紹介したいと思います。
この工程を簡単に紹介させてください。まず電子基板とはなんなのかと言うと、みなさんももしかしたらご覧いただいたことあるかと思うんですけれども、電子部品が載っている基板なんですね。
大きい基板ですと2,000点ぐらい部品が載っていまして、ほとんどの部品は、ここにありますSMT、Surface Mount Technologyという技術を使った機械で、非常に高速で部品を置いていきます。
ですが、なかには、SMTでは打てなくて、人間が手で穴の中に部品を挿していかなければいけない部品が一部残っています。それを我々のほうでは「手組」と呼んでいます。
これは装置などをかなり省略した概略図なんですが、この後、画像で自動検査をしたあと、目視検査があるんですね。目視検査が終わってからインサーキットテスト、それからファンクションテストという装置を使って自動的に検査をしていくような工程があります。
今日の事例はこの目視検査工程での事例になります。SMTでの事例もけっこうあって、流れをよくするための見える化をやっているんですが、そこは今日はご紹介せずに、この目視検査、手組の事例はあまりないと思いますので、そこをご紹介したいと思っています。
不良の集計データが信頼できない
写真で言うとこの黄色の部分を目視検査するんですけれども、もし不良を発見したらどんな作業があるかというと、不良を見つけた部品にマスキングテープをピシャっと貼り付けるんですね。
それでこのメモを検査した人はおもむろにテープを取ってシャシャシャと書くんですね。なんというロットナンバーで、なんという部品で、なんというロケーションにあるものに、どんな不良が出ているのか、ということを書いて、現品に添付する。
そして、現物はラインアウトさせて修理工程というところに持っていきます。そこで修理したり、場合によっては捨てることもあるんですが、だいたい修理をして修理報告を入力するという流れになっています。
検査する人は不良を見つけてしまうと、ここにありますようにマスキングしたり、紙にいろいろ書いたりします。それが33秒のサイクルタイムで、基板の流れというか目の前に来るわけですけれども、33秒の間にこの作業をやらなければいけないんですね。なので、不良が来るとけっこう時間を使ってしまってギリギリという流れでした。
ここでの問題点はなんだったのかというと、先ほど修理工程で不良のデータを後で入れていると言いましたけれども、そこのシステムのデータをもとにしてグラフ化したものが、この上の不良の集計グラフなんですね。
色が違うところがありますけど、これは不良の種類を要素棒グラフとして表現してあります。けっこう古いですけれども、2015年からのデータです。
このデータが実は信用できないと誰かが言い出したんですね。実態を反映していないようだ、と。それで人間が現場に張り付いて、同じ期間、同じラインで不良をカウントしたんです。そのグラフが下のグラフです。
上のグラフと下のグラフは本来同じにならなければいけないわけなんですけれども、実はそうなっていない。例えば、この日に発生したものがシステム上は別の日に発生しているように見えている。あるいは、ここは毎日発生しているのに、あたかもまとめてドーンと発生したように見えている、ということがわかってきたんですね。
なぜこんなことが起きるのか、もうみなさんピンと来られたと思うんですけれども、修理工程という後でやる工程でやっているので当然遅れるという話です。それから、紙にもとづいて人間が画面に向かって入力しているわけですから、当たり前なんですけど、人間って面倒くさいのを後回しにするじゃないですか。「まとめて入れてしまったほうがいい」とか。1枚来たら1枚入れるなんて、そんなバカなことはしないという当たり前の行動があるわけですので、まとめて入れているということがわかってきたんですね。
もちろん「その都度入れろよ」と言ったら入れてくれるのかもしれないんですけれども、人間はこの行動のほうが都合がいいから今こうしているわけで、それを無理に強制しても、おそらくまた何ヶ月かすると元の木阿弥、ということを今まで散々経験してきているので、「そもそもこの入力の設計自体間違っているんじゃないか」と問題を定義しまして、変えたんですね。
元々の状態でなにが問題だったかというと、結局、上のグラフを信用して調査や改善活動をやろうとしたんですけれども、これが間違っている情報なので、当然、調査が後手に回ってしまったり、間違った方向に行ってしまったりしがち。ただ、現場はバカじゃないので、このグラフを鵜呑みにしてそのままやるわけではなくて、いろいろな情報を複合的に考えながら当然やっていくわけなんですけれども。
初動をよくするためにデータを取ってグラフを書いているのにもかかわらず、初動をかえって悪くしているという実態を変えたい、というのが現場のニーズだったんですね。
レポートを書くのがいつの間にか仕事に
ではどうすればいいかというと、「紙に書くのをやめちゃおうよ」ということで、これは今日もブース出していただいているシムトップスさんの「ConMas i-Reporter」というツールを使って、「データ入力をiPadで入れられないの？」というふうに変えました。
これを変えるにあたっては、当時のi-Reporterの機能、あるいはパフォーマンスでなかなかそういうことができなかったので、シムトップスの水野社長ほか責任者の方に何度も工場に足を運んでいただいて、（機能改善の）ご協力いただきながらこういうシステムを作ったんです。
これはどういうシステムかといいますと、今、流れてきている基盤の画面が出てきています。青枠のところは目視検査すべき部分です。
例えば「この部品が悪い、不良だ」というのを見つけたら、ここでタッチすると、画面上マーキングされます。そして「どう悪いの？」と。例えば「違う部品がついているんじゃないの」とタッチで入力できるようにしたんですよ。
そうすると、今までだったら「この部品はなんという部品番号か」「どの位置の部品か」「どのロットナンバーのものか」といったことをたくさん書かなければいけなかったんですけど、コンピュータは便利なので、タッチするだけで、裏で全部情報が紐づきます。ですから、いちいち紙に書かなくていい。2タッチで情報が入るようになりました。なので、今まで紙で小さいメモ書きみたいな伝票に書いていたものをタブレットで入れる方が速い、これだと不良が発生してもサイクルタイムの中で間に合う。
実は、次の画面で修理工程で入力できる画面が用意されているんですけれども、基板にあるバーコードを読むとこの画面が読み出されてきて、現物に表示がなくてもこの画面を見ながらどこの部分が悪いかを識別できるようになっているんですけれども、そういうものに変えました。
今までこの不良のデータを修理工程で入れていたんですが、もっと前段階の検査工程で入れる。今までまとめて伝票で入れていて、あんなことになっていたのを、不良を発見したらその都度入れていくように変えることができたんですね。インラインでできるようになってきました。
そうすると、データがリアルタイムで来ますので、その日に発生した不良がその日に見えるようになったんですね。これはMotionBoardで作った画面なんですけれども、今時点でどのぐらい投入していて、どのぐらい不良が出ているかというものがあって。それから今日の不良の種類別件数や、1週間分の日別不良件数、あるいは不良の明細というものが見えるようになりました。
これができた時は「MotionBoardすげえな、こんなのが簡単にできる。かっこいいな」なんて思っていたんですけれども、みなさんは、これを見て不思議に思ったと思うんです。「で？」ということですよね。「だから？」って。
リアルタイムに自動的に不良の件数が見えるようになりましたよね。「で、どうするの？」「このグラフ見てたら不良が減るんですか？」。減るわけないんですね。だって原因はここにはなにも載ってないから、減るわけがないんです。こんなものをいくら見ていても不良を減らすことはできません。
ではこの画面はまったくムダなのかというと、実はそうでもないなということがわかってきたんです。
つまり、今までああいうグラフを書くのは、（システムの描いたグラフだけではなく）いろいろな情報を寄せ集めてExcelとPowerPointを駆使してレポートを作っていて、かなり人手がかかって大変だったんですね。それをやるだけでへとへとになってしまっていて、レポートを書くのがいつの間にか仕事みたいになってしまっていた。
本当は、レポートを書いて、そこからなにか気づきを得て、改善行動に移るというのが本来の仕事。改善して効果を出すことで仕事が終わるにもかかわらず、レポートを書いたら仕事が終わった気になってしまう。なぜかというと、レポートを書くだけでもうヘトヘトになってしまうから。
ただ、そこが自動化されると不思議なもので、人間、次に意識が向いてくるんですね。そこが自動化された。「じゃあ、俺、何するの？」「改善だよね。当たり前だよ」ということになってきまして、次に「あの画面じゃどうしようもないね」とわかるわけですよね。
89台分生産性が上がり、年間数百万円の人件費が削減
そうすると、今度どうするかというと、これは不良の発生時刻をプロットしたものです。ちょっとわかりにくいですが、横に長過ぎるので縦3列で書いています。
当時のMotionBoardはこういう時刻のプロットが苦手だったので、これは実はExcelで書いています。今のMotionBoardはできるらしいんですが、当時もできたのかもしれないですけど、そんなに簡単にはできなかったような気がします。それでExcelで書いたんですね。
そこでわかったことは、不良の中でも「はんだ不良」というものがあるんですけれども、そのはんだ不良というのは「発生し出すと連続して発生している」ということがわかってきたんですね。（スライドを指して）こういうところですね。ここなんかも、ばらついてはいますがトントンと連続している。そういったことがわかってきました。
もう1つわかったことは、その連続した不良が発生してしまうと、ラインが淀むということがわかってきたんですよ。淀むというのはなぜなのか、ここでご説明したいんですが、まずその前に……。
「時刻別にプロットしよう」とか、これを見たときに「偏りがあるね」と気づくということは案外難しくて、QCとかIEの土台がないとこういう気づきには至らないんです。そもそもどう見える化すればいいか設計ができない。誰もができるわけではないということですね。
なので、やはりこの現場力という土台は非常に大切で、その土台があったからこそ、こういう発想になってきて「こう見てみよう」とデザインできるのではないかと考えています。
それで、連続して不良が発生するとなぜラインが淀むのかというと、実は検査している人は、単に検査しているだけではなくて、「はんだ不良」と呼んでいる軽微な不良については、それを発見したら検査員は、はんだゴテを持ってちゃちゃっと直していたんですね。ところが、連続して不良が来てしまうとサイクルタイム内で直しきれなくなってきてしまって、待ちが生じてしまう。次の工程の人たちは、（前からモノが流れてこないので）手待ちになってしまうという問題が生じていたんですね。
どうしたらいいのかというと、ちゃちゃっと直しているからこんなことが起きるので、もうそれを直すのはやめよう、検査だけに集中しよう、と。
では不良を見つけたらどうするのかというと、不良はラインアウトして、データから標準手持ちと呼ばれる良品在庫をいくつ持てばいいのか計算できますから、これを持っていて、サッと入れ替えて、ラインのタクトを乱さない。そういった流れを作っていくことができました。
私たちはトヨタ生産方式をベースにした「XPW、Xerox Production Way」という生産方式を標榜しているんですけれども、そのトヨタ生産方式では「流れ」というのが非常に大事です。物や情報が淀みなく流れていくことを重視していますので、やはり物に流れを作る、リズムを作るということは大事で、淀むのを非常に嫌うわけなんですけれども、これはそういう改善ができた事例なんですね。
この結果、実際にはサイクルタイムの33秒の中で焦って直したり何かを書いたりしなくてよくなったために、作業負荷が減りました。実は不良の見逃しリスクもあったんですけど、そういうものも低下していくようになってきました。
サイクルタイムもこれによって3.4秒改善しました。3.4秒って極めて短いじゃないかと思うかもしれないんですけれども、定時換算すると、今まで772台しかできなかったものが861台できることになるんですね。たったこれだけの改善で89台分の生産性が上がったということなんです。
このラインは当時900台以上流していたラインでしたので、定時では772台しかできないんだから当然残業をしなければいけない。残業の平均時間が1人あたり98分だったんですね。1時間半ぐらい毎日残業していた現場でした。
ですが、この改善によって残業時間は平均で44分で済むようになりました。（5人編成だったので）54分×5人分残業代が減った。これは年間に直すと数百万円分に相当します。たったこれだけの改善で数百万円分の人件費が削減できた。そういう改善につながったということなんですね。
作業者にその都度フィードバックすることが可能に
それだけではなくて、ここでは次のこともやっています。まず手組する人が作業をしたら、はんだ槽を通って、その後に検査をします。検査をして不良が見つかったら、ConMas i-Reporterでデータを入れると、データが得られます。
それだけではなくて、「今あなたがやった作業は不良でしたよ」ということを（MotionBoardを通して）作業者にリアルタイムに返しているんです。これはこの作業者が「こういう機能がほしい」と言い出して作ったものなんですけれども、どういう効果が得られたかというと、これによって連続した不良がなくなったんですね。
いったいどういうことかというと、今まで作業者に対するインフォメーションは、例えば週1回ぐらい、（朝礼などで）作業者に対して「先週、このラインではこういう不良がこれだけ出ました」という共有を、先ほどのグラフを見せながらやっていたんですね。「今週は頑張ってそんなことないように注意しましょうね」と。まあ、根性論みたいなところがあったわけなんです。
ただ、そういうインフォメーションは、実際には作業者になんのメリットもない。ただ単に申し訳ないと思わせるような、心理的な圧迫を与えるだけのインフォメーションにすぎませんでした。
なぜそんなことになってしまうのかというと、この作業者の人は1日900台も作っていますから、1個1個の不良がなぜ自分の作業ミスによって発生してしまったのか、その時作業がどんな状態だったのか、覚えてなんかいないんですよ。1週間も経ってから「先週1週間分の……」と言われても、そんなことは覚えていない。何が悪かったのかわからないんです。反省できないんですね。ということは、つまり行動が変化しませんから、現状は何も変わらないわけですね。
ところが、都度インフォメーションをしてあげると、今やった作業は覚えていますから、自分のどういった作業がどうつながったのかがわかるわけです。そうすると、自動的なフィードバック制御がかかって「次からはそうしないようにしよう」となるので、連続した不良はなくなりました。
では「そもそもなぜ連続した不良が発生していたのか？」という疑問が湧いてくるわけなんですけれども、それがこの作業に関係しています。この作業というのは、基板の穴の中に足のついた部品、コネクタみたいなものなんですが、こういうものを差し込んでいくという作業なんですね。
実はこの穴というのは公差があります。公差というのは、何ミクロン～何ミクロンまでにないといけないというもので、足の太さにも当然、公差がある。これは工業製品ですから、いつもぴったりミクロン単位で一緒というわけではないんですよ。大きさはばらついているんですね。
基板の穴が狭めの材料ロットが入ってくるときもあります。公差内で、合格品だけど、その狭めの穴に偏りがちな、材料ロットというものが存在しているわけですね。
同様に、太めの足というロットも存在していて、これが不幸にも重なってしまったとき、固くて入りにくいということになってしまいます。これはしばらく当然その材料ロットを使っているかぎり続いてしまうわけなんです。
今まで作業者は、これを毎日やっているわけですから、「ちょっと今日は固い」「今これは固い」とわかるわけなんですけれども、固いから当然グッと差し込みます。差し込むんだけれども、差し込みの力が足りなくてですね、不良になる。
この穴や足の大きさは毎回ばらつくものですから、毎回この力でやればいいというわけではなくて、必要な力が変わるんですけれども、そうすると不十分になるときがあるんですね。すると「浮き」という不良になってしまう。そんなことが起きてしまっていたわけです。
だけど、都度インフォメーションしてあげることができれば、「今の力の加減ではまだ不十分だった。浮きという不良になってしまっていたんだな」ということが作業者にわかるわけですね。そうすると作業者は「もっと力を入れて差し込まきゃならない」、例えばそんな判断ができるようになってくるものですから、連続した不良はなくなっていったということなんです。
見える化には2種類ある
そこで、ここまでをまとめてみますと、先ほどのグラフは日別の集計だったんですね。では「なぜ日別に集計しているの？ 日別に集計する合理性は何なの？」というと実はあんまりなくて、なんとなく日別に集計していた。「じゃあ1.5日ごとに集計しちゃダメなのか？」「3時間ごとに集計しちゃダメなのか？」。そんな発想はまったくなくて、単純に「日別に集計すればいい」ということが起きていたわけですね。
ですが、先ほどのように1個1個のデータをとることができるようになれば、時系列での個の動きが見えてきます。そうなったときにはじめて「どう集計すればより効果的な気づきが得られるのか」という設計ができるようになってくるのではないかと考えています。
もう1つは、その日や1週間の不良の件数、月別の生産高など、KPIというものがあると思います。KPIは当然集計しないといけません。それはそれで大事ではあるんですけれども、それだけでは現場の改善はできなくて、実際にはイベントの管理をしないといけない。これは当たり前といえば当たり前ですね。
イベントとはなにかというと、変化点のことです。現場にはさまざまな変化が訪れますね。私たちは日常管理項目の変化点管理と呼んでいるんですけれども、いわゆる4M2Sの変化点管理。4M2Sというのは、Man、Machine、Material、Method、System、Space。やる人が変わった。やる道具が変わった。やる場所が変わった。そういう話ですね。
そういう変化点をイベントとして捉えて、その変化点を見ていく。4M2Sが変化したときに不良が起きやすいということが経験則としてわかっているわけですから、それが起きたときは注意しないといけません。あるいは、それが起きないようにコントロールする必要があるわけで、イベントの管理をしなければいけない。
それともう1つはプロセスの管理ですね。これはいわゆる品質管理項目の変動管理。上は日常管理項目の変化点管理ですけれども、下は品質管理項目の変動管理が必要で、それもやはりリアルタイムに見ていく必要があります。そういったものを集積した結果が報告としてあるというだけのことで、結果だけ見ていてもあまり改善にはつながらないわけですね。
先ほどのように、細かいデータはMotionBoardやDr.Sumお得意のドリルダウンで見ていけばいいんじゃないか、ということはあるかもしれませんけれども、ドリルダウンして答えが見つかったという経験は、私はあまりないんです。
だからといってドリルダウンという機能がいらないといってるんじゃないんです。ドリルダウンで答えが見つかるためには、ドリルダウンしたら答えが見つかるように設計されていなくちゃならない。それは画面の設計とかじゃないんですよ。データの設計です。さっきの話で、紙に書いたものを入力した結果得られたデータだったら、紙には何時何分何秒に不良を発見したかとか、そんなことまで書かないわけですし、そんなことにも興味がなかったわけですから、そんなデータをそれ以上ドリルダウンしても何も答えは得られないわけです。
なので、やはりきちんと時刻情報とともに個の動きの管理が必要なのではないかと思っています。このとき初めて現場の生々しい姿が見えてきて、気づきが得られる可能性が高いと考えています。
それと「見える化」とMotionBoardということなんですけれども、私は最近、見える化には2種類あるのではないかと思うようになってきました。
1つは、答えが見えたらもう見なくてもいい見える化があると思います。先ほどの事例です。答えが見えた、何が悪いか原因がわかった。その原因を取り除いたら基本的にはもう起きないんです。起きないものをずっと見ていても意味がありません。以前はそういうこともお金をかけてシステム化していたんですね。
今、MotionBoardになって何がいいかというと、サッと作ってすぐ捨てられるんです。答えがわかって、もう見なくてもよくなったら、いらないんです。先ほど見せていた画面も実はもう使っていないんですね。サッと作って次の見える化、次の改善をやれる。惜しみなく捨てられる。だって、そんなに工数かからないもの。作るのに。そういうところがMotionBoardの良さです。
ただ、ここのところサッと作るというところが少し弱いかなという気もするので、そこを追求していただけるとありがたいなという気はしています。
もう1つは、継続して見なくてはならない見える化があると思っています。これはどこからでも誰もがリアルタイムに状況を把握できる。例えばこれは、ラインでの見える化のダッシュボードの1つなんですけれども、今の生産の進捗の画面が見えています。生産の進捗は、いろいろな変化点によって遅れが生じたりします。
（スライドを指して）この計画数というのは、MotionBoard上の別のシステムから持ってきています。投入数は初工程、これは装置にかかったときのセンサーのデータです。完成数は、最後、シリアルナンバーを読んで梱包しているんですけれども、そのときのデータを持ってきています。不良のデータは、先ほど言ったようなタッチのi-Reporterなどから持ってきています。いろいろなデータを組み合わせて、ノンプログラミングでこういう画面ができるのがMotionBoardの非常にいいところかなと考えています。
こういうものは日々リアルタイムで見ていく必要があると思っていて、こういう2つの見える化とMotionBoardのそれぞれの役割は違うかなと思います。
昔はこういうものを手作りで作っていたと先ほど言いましたが、1つ目の見える化のほうの手作りは、本当にムダで、時間と工数をかけて作ったシステムでも今は使っていないものがけっこうあるんですよ。答えが見えたら、いらないんですよね。「なんで使ってないの？」と現場に聞くと、「答え見えちゃったし、今きれいに流れてるものを見なくていいじゃん」と当たり前のことを言われます。「だったら、そんなものに金と時間をかけるのはもったいない。MotionBoardでサッと作ったほうがいい」という考え方を今は持っています。
こういった話を富士ゼロックスでは「MONOZUKURIコラボ」というかたちでやっています。お客様を工場にお招きして、今の現場のリアルな状況を現場の人間、実務の担当者と共有しながら、こうした悩みについてディスカッションしていくような場「MONOZUKURIコラボ」をご用意させていただいています。
今たいへん好評いただいておりまして、2ヶ月待ち、3ヶ月待ちぐらいの状態になってしまってはいるんですけれども、ぜひ富士ゼロックスの工場のほうにお越しいただければと思います。
今日はこれで私の話は終わります。どうもありがとうございました。
（会場拍手）
