Amazon Web Services ブログ
その製造データ、ユースケースは決まってますか？
こんにちは。元自動車メーカー生産技術出身でAWSへ転身した、変わり種ソリューションアーキテクトの岩根です。
さて、ものづくりの DX が叫ばれて久しい昨今、「データドリブンな意思決定」という言葉を聞く機会も増えていると思います。AWS の製造業に携わるメンバーでも、お客様とデータドリブンについてディスカッションすることが多いです。私個人としてもそれはテーマとなっており、例えば 「Amazon QuickSight で製造サプライチェーンのデータドリブンな意思決定を実現する」でご紹介したような可視化の考え方や、「製造現場でデータドリブンとクラフトマンシップは交わるのか？」で考察したような実装のためのアプローチなど、至らないながらも様々な発信をしてきました。
今回は原点に立ち戻って、データドリブンな意思決定の進め方について考察してみたいと思います。
製造業のデータは宝の山
こちらの調査によれば、製造業は年間約 1,812 ペタバイト(PB)のデータを生み出しており、通信、金融、小売業などほかの産業よりも多いことがわかっています。また、過去 20 年間のデジタル情報の急増により意思決定プロセスが複雑化したため、製造業者はデータパターンの発見や従来予期できなかった問題への対応に、デジタル技術を活用して情報をより効率的に処理、活用しようとしています。総じて言えることは、データ活用が十分に進んでいない製造事業者は、膨大なデータという宝の山の上にいると言えます。一方で、同じ調査の中の中国を対象にした調査によると、データ活用の一環としての AI 活用において、91 %のプロジェクトが期待通りの効果や投資額を達成できていないことを伝えています。このことから、製造業が抱える膨大なデータは、ビジネススピードの飛躍的改善による競争力強化につながるポテンシャルがあるものの、その手段として様々な意思決定をデータドリブンに変革することは決して簡単ではなく、一朝一夕にはなし得ないものであると言えます。
データドリブンの「鶏・卵問題」
製造業において、データドリブンな意思決定を、会社の各階層、すなわち製造現場だけでなく、工場などの現場マネジメント層、経営層に至るまでで行うためには、必要なデータを一元化し、分析・可視化できる環境を整える必要があります。ここではそれを「データ基盤」と呼びます。ここでくせ者なのが「必要なデータを」という部分です。必要かどうかは何によって決まるのでしょう？そう、「ユースケース」です。では以下のうち、アプローチとして正しいのはどちらでしょうか？
- どのようなデータが「必要なデータ」かを網羅的に見積もることは不可能だから、取れるデータはすべて取ってデータ基盤を整え、あとからユースケースを考える
- 不要なデータを集めるリスクを最小化するために、ユースケースを網羅的に調査して、すべての必要なデータを洗い出してからデータ基盤を整える
いじわるな質問ですが、どちらも「不正解」だと私は考えます。いつわりの「鶏・卵問題」に惑わされてしまっている状態とも言えます。また、製造業においては、何らかの実体のあるモノを作る、という特性上、計画駆動の文化が根強く、上記の罠にはまりやすいのではないかと思います。結果として、使われないデータ基盤が誕生したり、永遠に終わらない「検討」を続ける、といったアンチパターンに陥ってしまいます。ではどのように進めればよいのでしょうか？それは仮説検証プロセスを導入して、ユースケースを生み出す連鎖を設計することです。次の章で詳しく説明します。
仮説検証プロセスによるユースケースの連鎖
前項で述べたいじわるな質問の回答 1 と 2 は、どちらも共通する問題点があります。それは「正解」を「何かをする前から」探そうというアプローチで、ビッグバンスタートとも呼ばれるものです。何もかも決めきってからスタートする、というのは、その対象によっては正しいアプローチであることもあります。しかし「データドリブン経営」という、社内で誰も経験していない、未知のことをなすときに正しいアプローチとは言えません。一寸先は闇、ではないですが、やってみないとわからない、というのが現実ではないでしょうか。
仮説検証アプローチが必要
そこで、仮説検証プロセスを導入しましょう、というわけです。若干ニュアンスは異なりますが、敢えて製造業のみなさまに慣れ親しんだ言葉に置き換えると、PDCA サイクルを「小さく早く」回す、となります。そうする理由としては、「わからないことは学習しながら探っていく」「そうすることで失敗リスクを最小化する」ところにあります。具体的な手順は以下です。
- 達成したいビジネス成果とユースケースの仮説を立てる
- 仮説を検証するために、必要最小限のデータを取る
- 仮説の確からしさをユースケースで検証する
- 仮説を棄却するか、改善するかを決め、必要に応じて1に戻る
当たり前のように感じるかもしれませんが、各ステップに落とし穴があるのでステップごとに解説していきます。最初に達成したいビジネス成果の仮説を立てるのが非常に大事です。「手元に XXX のデータがある。何に使えるか考えよう」という発想だとうまくいかないことが多いです。その重要性は、一般にゴールデンサークル理論という思考プロセスと共通します。ゴールデンサークル理論でいう Why、How が、データ活用においてはビジネス成果とユースケースに該当することになります。
ゴールデンサークル理論
次に、2の「仮説を検証するために、必要最小限のデータを取る」ですが、ここで2つのハードルが待っています。1つ目はコストです。例えば PLC からのデータが必要であれば、PLC のデータを収集するためのエッジ装置や、ソフトウェアを導入する必要があります。ここでお勧めしたいアプローチが、代替手段でコストをかけずに収集できないか？ということです。詳しくは後述します。2つ目は、データのオーナーの理解と協力です。PLC の例でいうと、データのオーナーは製造現場となります。日本では、データ基盤を整えて事業部門に提供する役割を負うのは、DX 推進部門や IT 部門であることが多いです。製造現場から見ると遠い存在の部門から「XXX のデータを取らせてもらえないか？」と言われると、現場側から断られることも多いです。私は前職時代、実際に断られたことがあります。それは、製造現場の役割と密接に絡みます。製造現場は、製品を安定した品質で、安定した数量、安全に製造し続けることが使命です。そのため、変化に対して敏感になる傾向があります。実際、製造現場では「変化点管理」を徹底して、設備の消耗品交換などのメンテナンス履歴や原材料のロットなど、変化が宿命的に発生する事項に対して、後追いができるように記録することが当たり前に行われています。そんな中に、手ぶらで「XXX のデータを取らせてもらえないか？」と言っても、断られるのは道理というものです。現場の納得感を高めるために、1 の仮説「達成したいビジネス成果とユースケース」を訴えたとしても、現場現物を大事にする製造現場側の納得を得られないこともあるでしょう。
ただ、ここを乗り越えて「役に立つユースケース」がいくつか生まれてくると、様々な部門からアイディアが溢れてくる、「ユースケースの連鎖」が期待できます。過日のre:Invent reCap インダストリー編 製造業向けウェビナーで触れたVolkswagenの事例は、まさにその連鎖が起きている状態だと思います。
泥臭いアプローチも有効となる
製造現場の納得と協力を得られないなか、仮説検証サイクルの「ひとまわし目」を回せるようにするにはどうしたら良いのでしょうか？DX 推進部門や IT 部門に所属していると、ソフトウェアや自動化されたプロセスでのデータ収集にとらわれがちです。それは最終的には正しいのですが、「仮説の確からしさを検証する」ことと「製造現場の理解・協力」を両立させるステージでは、それが最適とは限りません。前述した代替手段でコストをかけずに収集できないか？がここで登場します。製造現場の安定生産志向に不安を持たせないために、PLC のラダーに手を加えず、ネットワークにも繋がず、データを取る方法はないのでしょうか？実際に私が見聞きした事例をいくつか挙げます。
課題：複雑な自動機の組み合わせのラインにおける、ステーションごとの稼働状態の把握
対応：人が張り付いてストップウォッチにより計測し、稼働状況を把握
課題：異音検査工程の検査方法が、人による官能検査で非効率
対応：市販のマイクとラズパイを用いて簡易検査機を開発、効果測定
課題：数千秒のサイクルで多品種少量生産をするときの習熟期間をモデル化したい
対応：企画メンバーが自分たちで実際にトレーニング用の製品で繰り返し作業し、結果をモデル化
これらは私個人が見聞きした例ですが、いずれも製造現場の制御系統に手を加えることなく、仮説を検証できた例と言えます。製造現場との距離感はまちまちなので、ここまで極端な手段を選ぶ必要はないですが、「必ずしも電子的・自動的にデータが取れなくても良い」のは確かなのかなと思います。
仮説検証でデータ駆動を進めていくための産業データファブリック
最後に、仮説検証プロセスでデータドリブンを進めていくために必要な要素をお話します。それは、「スケーラビリティ（拡張可能性）」です。仮説検証で小さく始めて育てていく、というアプローチを採り、その結果狙い通りに「ユースケースの連鎖」が起きた場合に、それらを支えるバックボーンのスケーラビリティ不足はボトルネックになりかねません。そういったスケーラビリティの問題や、サイロ化されたデータを統合する課題を解決するために AWS が提唱しているアーキテクチャフレームワークが、産業データファブリック（IDF）です。細かくはこちらのリンクやブログ記事に譲りますが、仮説検証のサイクルが回り始めた暁には、このフレームワークを元にスケーラブルな基盤を構築できます。AWS での中核となるサービスは AWS IoT SiteWise で、エッジからの様々な産業用プロトコルによるデータ取り込みに対応しています。また、パートナーソリューションも増えてきています。これらも参考にしていただき、スケーラブルな仕組みを、仮説検証が何サイクルか回り、役立つユースケースが社内で認知されてきたタイミング（＝予算がつけられるタイミング）で検討するとよいかと思います。
産業データファブリック
まとめ
本ブログでは、データドリブンを進めるために重要な要素として、以下を挙げました。
- 仮説検証プロセスを採用すること
- ゴールデンサークル理論に則って、Why から始めること
- ユースケースの連鎖に備えて、スケーラブルなアーキテクチャを早い段階で導入すること
既にデータ基盤を整え始めているみなさまには、ブログの表題である「その製造データ、ユースケースは決まってますか？」に対して「No」や「わからない」とならないか点検してみると、新たな気づきがあるかも知れません。
アポロ 11 号のアームストロング船長は、月面に降り立ったとき「これはひとりの人間にとっては小さな一歩だが、人類にとっては偉大な一歩である」と名言を残しました。ぜひともみなさんが、自社のものづくり DX に向けて偉大な一歩目を踏み出すことを願います。
著者紹介
 |
岩根 義忠 (Yoshitada Iwane) |