IOT・AI活用事例ウェブセミナ

本文

分析プロジェクトの進め方 -製造業においての具体事例-

2018.11.19

今回は分析プロジェクトの進め方と事例を紹介します。
*分析手法の詳細については書籍で勉強していただき、ここでは活用のヒントとなる事例を二つ紹介します。
*機密保持のため、若干抽象的な表現になっている部分があります。

1)データ分析の進め方

・現状の課題とあるべき体制
製造業において、データ分析をどのように実行、活かしていくかというと後述のような複数人が関わるプロジェクト方式がおすすめになります。ただし、私が見聞きする範囲で例えば以下のような状況で開始となる場合が多いです。

上司:「社内に製造条件に関するデータがあるから〇〇君ちょっと分析してみてよ。規格に収まるような条件の時を見つけてほしい。」
部下:「なんかそう言えば昔大学の時に、分析の勉強もしたなぁ。」
上司:「よく分からんが、これからはAI時代だろ!良い感じのやつを頼むよ!」
部下:「わかりました...(内心どうしようかと困る)」

実際にこれは「私がよく聞く話」です(笑)。そしてだいたい上手くいっていません。どうつまづくかというと6つに集約されます。
・データ分析からわかる事が出来たとしても、他部署やITインフラ部門との交渉が必要で、社内的に動かすことが難しい。
・異常データが思ったよりも少ない or 多すぎる事で分析が難しい。
・データ化がされていない事によってデータ分析事態出来ていない。
・データ分析からの業務プロセスの変更を生産現場にお願いが難しい。
・実は現場の一部の人しか持っていない情報があり、データ不足であった。
・そもそもやりたいことを上司がわかってない。何回聞いてもわからない。

分析手法に加え、プロジェクト実行プロセスや結果の現場への落とし込みが非常に難しいのが現状と言えます。そのため最初からしっかり生産現場を変えられるような合意を取っておく必要があり、複数の組織・人から構成されるプロジェクト形式かつ以下のようなメンバー構成が必須条件です。

事業側(分析結果を活用する側)
・現場担当者:アウトプットを活用する人、仮説出しや施策への落とし込みを担当
・現場マネージャー:プロジェクト実施可否の意思決定、成果責任

分析側
・プロジェクトマネージャー(コミュニケーション):プロジェクト立上げ、マネジメント
・データアナリスト(サイエンス/エンジニア):データ処理・分析、アウトプット作成

・分析プロジェクトのおおまかな流れ
有名なのはCRISP-DMと呼ばれるデータ分析のプロセスが有名です。IBM・NCR・ダイムラーがデータ分析の手順として決められたものになります。

1.ビジネス課題の理解
当然ながらデータ分析をするのにあたって、現状の課題を把握する必要があります。例えばですが、生産運転条件が熟練の人しかわからない(技術を伝承したい)/歩留りを向上したい/故障予知をしたい/生産効率の向上をしたいといったどういった点に着目を置いているかを把握する必要があります。

2.データの理解
どんなデータが存在していて、どんなデータが存在していないかは非常に重要な項目となります。 ビジネス課題の理解で定めた課題を解決するために必要なデータが揃っていか、という点において必要なデータがなさそうであれば、課題自体を別な視点から捉えるように考え直すかも考える必要があります。実際には、すべての要素を観測してデータとして記録することはできません。そのためどんなデータがどれぐらいも含めて存在しているかを確認する必要があります。

3.データの準備
データを揃えるような処理(日付フォーマットがバラバラ)、欠損値に対する処理、データをくっつける必要がある場合はここで行います。また外れ値もここで確認する必要があります。

4.データのモデリング
さていよいよ肝のプロセスになります。このプロセスでは様々な手法を利用して、最も良い結果を出すような手法を見つけることになります。 数値の予測をしたい、不良か良品かを判別したい、など、どのようなことをしたいかによって使える手法はある程度限定されますが、それでもモデリングの手法は数多くあります。 その中のどれが最適かについては、「これを使っておけばいい」というベストな選択肢は存在しません(ノーフリーランチ定理と言います)。

5.モデルの評価フェーズ
モデルを使って予測して、費用対効果があるか等を検証します。ビジネス上の課題を現場で展開できるかどうかも検討する必要があります。

6.実装フェーズ
データ分析のモデルから実装を行うフェーズになります。

これらのフェーズは全て重要であり、どれがこけても分析プロジェクトとしては失敗する事になります。

2)製造業での分析プロジェクトの進め方事例1

成功例
業種:造船メーカー
従業員数:非公開
ポイント:プロジェクト形式データ分析と分析対象の選定

データ分析を進めるのに、データを持っている製造部門だけではなく、IT部門の人、経営企画の人、生産技術部の人も含めて進めている会社があります。製造部門はちょくちょく人が変わるのですが、経営企画の人が音頭を取りデータ分析でプロジェクトを進めています。やはり経営企画の参画・音頭とりがないと、失敗すれば製造原価に逆に悪影響が出かねない活動は現場だけでは実施できません。インフラを整える費用まで考えると赤字という事もあります。

また私たちのようなコンサルの人も外部有識者として入りますが、基本的には事例の紹介や分析の仕方の紹介、分析のお手伝いをたまにやるぐらいです。改善は社員自らが自主的に率先して行わなければ進まない、定着も難しいと考えているためこういった形での組織づくりになっています。

メインの仕事があるので、活動は週1回か2回程度としてメンバーの定常業務に支障が出ることないようにしています。これも経営企画の音頭とりがあればこそ継続実施できることです。課題だし、出した課題に対して製造部門でもやはりデータはあるか、データの理解や活用が出来そうかを議論しています。例えば異常データが一件しかなく、分析できないという事もありました。

最初プロジェクトとして考えられるものとしては、約20件は超えるネタがありました。そんな中、1年間で2件プロジェクト化し、実装から運用まで成功しました。しかし最初考えた件数からは1割未満で、分析プロジェクトを進めていくのにハードルが高いものであるというのがわかります。

実際にそのうち1件であった保守に関する事例を紹介します。お客様からの問い合わせで、故障がわかるのですが、それではダウンタイムが発生するので、故障前にメンテでいつ伺えば良いかを分析でわかるようになりたいとの話でした。

私は、お客様の問合わせ履歴と納入した機械の警告メッセージから分析すれば、予測は出来そうだなと考えていました。そして実際にお客様とデータを見て、分析をしてみるとどうやらお客様の問い合わせ発生するエラーの前に特定の警告が多い事までわかりました。これはしめしめ上手くいったぞと私と経営企画の人、IT担当の人は思いました。

IT担当の人が元々乗り気でした。なぜならばこれは以前から「何かに使えそうだ」と思いデータを貯めていたが、ストレージの費用がかかるばかりで大した活用方法を思いつかず何とかしたい状態になっていたからです。

予兆を基に、修理のサービススタッフをお客様の所に行けばお客様からのクレームを抑える事ができます。IT担当・私・企画担当・製造部署は考そうえていました。しかしながら致命的なミスがあったのです。一番署関わる所をこの会議に呼んでいなかったのです。そうサービススタッフの部署です。

勿論分析が終わった後に、サービススタッフに話をする機会を設けました。意気揚々と私達は説明します。ただサービススタッフの部門の人から一言、「警告340?あぁその後に故障よくあるよね。当然だよね。警告340が出たら当然保守しに行っているよ。」そうです・・・現場ではどうやら当然だったようです。IT担当や経営企画の人及び私は、「今まで思いもしなかった意外な事」と思っていたのです(苦笑)。この時のプレゼンは失敗です。

という事でもう一度サービススタッフの人たちにヒアリングを行いました。その結果分かった事ですが、一部のベテランさんがどうやら定性的に知っていた事だったようです。そのためしっかり全員に周知をまずする事、特にこの警告340が実は2回続く場合においてだと特に故障が起こる事が定量的にわかっていたために、サービススタッフの現場で活用する事になったのです。

実際のところデータ分析で、意外な事はわかるというのはそうそうありません。勘や経験で定性的にわかっていたことを、定量的に裏付ける事で上手く次のアクションにつながる事ことが多いです。

3)製造業での分析プロジェクトの進め方事例2

失敗例
業種:部品メーカー
従業員数:約1000名
活用ポイント:流行ってる技術は難しい、いきづまったら外部の意見も積極的にきく。

データ分析と言えばディープラーニングという形で近年流行っています。そんな会社の流行りを試した1社さんでした。私たちがデータ分析相談受けたときは、ディープラーニングでよくあるサンプルもやった事があり、実際に自分達で試したが上手くいかないというお話でした。この会社とは別部署で付き合いがあり、その関連で相談を受けた案件になります。たしかに課題であることは事実ですが、まず技術を使いたい的な案件でした。

どうやら部品の画像認識をしていました。ただし部品を当てる精度が非常に悪く、モデルが使えないとの事で諦めていたようでした。そこで私も行って認識アルゴリズムと学習データを見てみると部品が画像に複数入っているために上手く学習が出来ない事が原因のようでした。https://tech-blog.abeja.asia/entry/object-detection-summaryの中で記載されているように領域検出を追加する事で、対象が複数あったとしても検出できるようなりますが、実際のアプリケーションでは性能面でほぼ課題発生します。技術者としてはそのアルゴリズムに固執して悶々としていたということになります。

そこで部品毎に検出するよう認識アルゴリズムに5行追加してみたら、その日のうちに解決してしまいした。相談受けたこの段階で、解決してしまったので・・・コンサルタントとしての費用は取れず後で上司からお金取れずと怒られてしまいました(笑)勿論苦労する案件も多いですが、このように割とあっさり行くようなケースもあります。

データ分析はいまだ難しい分野です。データ分析のプロジェクトの流れでもいきづまったら外部の意見も積極的にきくという姿勢も重要です。

コラムへのお問い合わせ

・オムロンエフエーストア編者から
製造でのデータサイエンス応用って難しいと思われませんか?事例が少なく、数式・数学・各種手法が難しい、費用対効果がわからない、正答率が高くないと実用にならない、などハードルは高いです。
エフエーストアでは製造現場へのデータサイエンス活用に関して専門家に依頼、ウェブセミナを開始します。できるだけ事例紹介を多くしてヒントになる、かつ一方通行的内容にならないよう各回で質問をお受けしてFAQとして回答を掲載します。FAQ形式として、回答に会社名、個人名等は記載されません。またご質問が質問のあった次回以降にとりあげる内容の場合FAQには非掲載にさせていただきます。本セミナのご質問は、各回のお問い合わせフォームより行ってください。エフエーストアフリーダイヤルお客様相談室フリーダイヤルでは受け付けておりません。