製造業のAI導入

Industory4.0、SmartFactory

@yutakikuchi_です。 Industory4.0, SmartFactoryという言葉があるように製造業の工場ラインに対してIoT・AIを導入し生産工程をデジタル化する計画がある。生産工程のデジタル化の先に人が担っていた作業を補助する目的でのAI・IoT導入検討が進められている。

https://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%83%80%E3%82%B9%E3%83%88%E3%83%AA%E3%83%BC4.0

製造業といってもIoT・AIの活用検証は多岐にわたる。 1. 製造ライン・プロセスでの検品作業の自動化 2. 製造機器の故障発生をセンサーログデータなどから予測する予防保全 3. 製造ラインを効率化するための生産計画の効率化

引用 : https://www.projectdesign.jp/201704/ai-business-model/003521.php

上記以外にも様々な検証が進んでおり、2030年にはAI活用業界のTopとして名を連ねることが予想されている。製造物に異常が発生したときの予算ロスはビジネス的なインパクトとして非常に大きいので、今後AI導入の注目業界であることは確かである。ただし、現状の製造業はAI導入のための課題はたくさん存在する。下記は製造ラインの異常検知の課題を列挙している。

データ収集の課題

• 紙などで情報を記録、デジタルデータを保存していないケースが存在する
• 製造ラインに対してIoTデバイスの設定が物理的に難しく、デジタルデータを収集するのに時間を要する。現状の製造ラインがIoTを導入することを前提とした設計になっていない。
• 熟練者に依存するタスクが多く、その人でないと判断ができない。また基準化、言語化がされていない。作業者の暗黙知、形式知のそれぞれのナレッジメントとデータが明確化されていない。
• 検品作業自動化のための異常データが発生する確率が少なく、これからデータを貯めるフェーズだとAI導入に時間が掛かる。
• 各社のデータ管理ポリシーが強固である。製造ラインのオンプレミスな環境から、クラウドなど外部にデータを預けることはポリシーに反することがある。

AI導入の課題

• 検品作業の人が担っているプロセスにおいては異常を検知する精度が高い。またAIが出力可能な精度はまだ100%にないため、作業すべてを置き換えることができない。
• IoT・AIの両方をセットで新規導入するケースについては、IoTで撮像条件を良い状態にしつつ、AIの精度を上げる必要があるので、対応の時間が長期化するケースが多い。仮に精度問題が発生したときに、初期においてはどちらに原因があるかを都度分解する必要がある。
• 業務プロセス側のドメインを知らない作業者がAIのモデル運用を続けることで、実運用と乖離した最適化をしてしまうリスクがある。
• AIによる異常検知が目的となってしまい、本質的な製造機やパーツが不良となる原因分析の方にフィードバックができない。

新しい動き

一方で最近の取り組みとしては良い材料も多い。工場の老朽化により製造ラインを新しく設計するケースも有り、その場合はIoT・AIの導入を見据えた形でリプレイスが検討されている。また製造ラインの担当者も異常検知が主目的ではなく、異常が発生する原因を特定するための製造物の正しい状態把握をデジタルデータで蓄積し、可視化から分かる機械工学の改善シフトに軸を移そうという動きも見受けられる。

製造業のAI導入の課題はまだまだ山積みではあるが、技術的な取り組みとしては非常にチャレンジングな領域であり、今後もこの方面には継続してトライをしていきたい。

運のコントロール

逆説のスタートアップ思考 (中公新書ラクレ 578)

@yutakikuchi_です。 馬田隆明さんの逆説のスタートアップを読んだ。アイディア、戦略、プロダクト、運についてそれぞれの章ごとに書かれており、スタートアップに携わる人は一読することをおすすめする。起業の科学などアイディア〜プロダクトについては説明がある他の本もあるが、運についてはなかなか見ることがなかったコンテンツなので、読んでいて非常に面白かった。なお、馬田さんはスタートアップについて様々なコンテンツをslideshareで共有している。

※ 第四章、運についての言及をメモとして共有。ただし、内容は意訳とし記載しています。 「運もある程度コントロール可能である」。①成功している起業家こそ、リスクを嫌う傾向があり、リスクを管理するためのポートフォリオを作成する。スタートアップの一つの行動がリスクであるのだとすると、それ以外の分野では慎重に行動をする。アインシュタインは特許庁に勤めながら相対性理論を、カフカは保険局員として働きながら返信を書き上げた。②成功している起業家はタイミングを伺ってる。一番乗りで市場に入ることが正しくもなく、適切なタイミングまでじっくりと待っている。盛り上がっている市場に焦って参入することにより失敗する確率が高くなっているという報告もある。加熱が過ぎた、もしくは悪い時期に参入している方が成功確率が高くなる。③成功している起業家はチャンスを失うリスクのほうがリスクであると認識をしているので、今あるもののリスクではなく、将来を見て判断をしている。特にチャンスを失うというリスクの方を危惧する傾向がある。

ブラックスワンのように予期せぬリスクが発生する事も当然有り得て、そこの対しての回避戦略がいくつかある。一つの例としては「バーベル戦略」とい言われるもので、ハイリスクな投資を10〜15%、それ以外には健全な投資として85%〜90%を確保しておく。中間な投資は一切持たないという手法であるが、相対的にはミドルなリスクを取っていることになる。ミドルなリスクとして全てを保有していると予期せぬブラックスワンに耐えられず、全てが吹っ飛んでしまう可能性もある。

アンチフラジャイルという脆弱性を逆にうまく活かすことこそがスタートアップである。現実世界にあるボラティリティによる非対称な良いブラックスワンこそがイノベーションであるという説があるように、良いリスクに張ることがスタートアップであるという考え方。

挑戦の量が質を生みだす。 とある事例として、あるグループを量で評価する試験、質で評価する試験を同じ時間で回したときに、最終的には量で評価するグループの方が良い質を生み出せた。量による試行錯誤の回数を増やすことが非常に効果的であることを裏付ける例。アインシュタインは248、ダーウィンは119、フロイトは330の論文を書いている、エジソンは1093の特許、バッハは1000曲以上を作曲、ピカソは2万以上の作品を残しているように、天才も数多くの挑戦をしており、彼らの成功している時期は失敗を重ねていた時期と一致するという内容もあり、如何に試行錯誤が重要であるかが分かる。

以上が意訳内容。運もある程度コントロール可能であるという背景は、失敗のリスクも合わせてコントロールすることで、大きな失敗をする前に成長を持続させるという話。第四章だけでも時間があったら読み返したいと思える内容でした。

www.slideshare.net

そこに張る勇気

逆説のスタートアップ思考 (中公新書ラクレ 578)

@yutakikuchi_です。 未来を正しく予測すること、どんなに優秀な人物が未来を考えても非常に難しいという事実がある。数多くの発明家や起業家が自分が描く未来へ投資を行い、失敗し続けてきた歴史もある。「未来は予期せぬところからやってくる」Y Comibinatorの設立者でもあるポール・グレアムも未来を予測することの難しさから、未来へのアイディアではなく考える人に注目すべきという話もある。

正しく予測できなかったとしても、現在〜未来を目指す中で「失敗の確率を減らすこと」は可能である。一見ダメそうなアイディアでも、隠れた良いアイディアを見つけることがスタートアップでは重要な要素とされているが、隠れた良いアイディアを実現する際に、検証というプロセスを入れることである程度のリスクを回避することができる。検証は最大の効果としては、その領域に携わる人間に対してアイディアを投げかけてみたり、課題となる一次情報を集めることで、自分のアイディアに対して客観的な感覚を注入することである。

検証されたアイディアに対して実施すべきかどうかの判断に必要なもの、それは経営者としてそこに張る勇気である。小さな市場にまずは目を向けて、そこの独占的なプレイヤーとなること。それを基に次は大きな市場を狙う。小さく成功を作って、大きく展開する。仮にそこで失敗、やり方を変えるためにピボットしても、バッターボックスに立ち続けてバットを振り続ければ、おそらく立ち直れる。そこに張る勇気。これが本当に重要。

RPAとAIの違い

RPAとAI

@yutakikuchi_です。 - RPA = Robotic Process Automation - AI = Artificial Intelligence

これらの違いは？ なるほど、言葉の定義だけでは違いが分からん。

RPAとは狭義の意味では、ルールベースをロジックとした人間の作業を簡易化・もしくは自動化する仕組みで、Webツールなどで提供される。狭義の中では人間の作業が全てルールに落として、それをシステムの機能で再現させることである。RPAの定義では人の簡易的な脳を機械にコピーをしていくため、機械が自ら学ぶような世界観は含まれない。RPAを広義に捉えると簡易的なAIも含めて人間の作業をルール化していく仕組みを示すが、AIとの境界面が明確化されないので、ここでは狭義のRPAについて記載している。狭義のRAPにおいては金融系会社などで人の作業を代わりに対応させる実施、例えば伝票への自動入力等が多く進んでいる。

AIは、過去のデータを利用した様々な判断をするための予測をする仕組みを提供する。人間が予測のロジックを事前に提供することで、データからの読み取れる判断ポイントや特徴については機械が解釈をする。例えば写真の中にどのような物体が写っているかを自動的に判別する場合、RPAのように人間が物体を見たときの判断ポイントの全てをルールとして機械に与えるのではなく、それらを機械が自動的に判断するために過去のデータから解釈をしてく。

簡単なまとめ

• RPA(Robotic Process Automation) : 人間の作業を機械が解釈可能なルールに落とし、ルールに基づいた作業を機械が自動化するような取り組み。
• AI(Artificial Intelligence) : 人によってルール化されないポイントも機械が自動的に解釈し、自動的に物事を判断や予測するための仕組み。

参考URL

www.itmedia.co.jp thefinance.jp https://winactor.com/column/819/winactor.com

見えない人工知能を売ることの難しさ

結果が見えない人工知能

@yutakikuchi_です。人工知能をCustomerに販売することは難しいとされる。その要因は何か。

一番のポイントはCustomerへの販売を担当するSales担当者も人工知能を開発することにより、Customerの課題が解決できるかが受注のタイミングでは分からないということである。結果が見えないというのは受注のタイミングの話である。

Machine Learning・DeepLearningのどちらの手法を基にしたとしても、Customerの課題に対してデータを集め、人工知能のモデルを作り、その後に評価を行う。このプロセスを踏まえないと、そもそもCustomerが求めるKPIに対して成功・失敗するということが分かりにくい点である。

経験を持った技術者であれば先行研究の内容から特定の課題に対して、どういったデータ量と質、更にはMachine Learning・Deeplearningの手法を採用、モデルのチューニングをすると予測精度◯◯%ぐらいは出るかも、というざっくりした見積もりは可能である。ただし、この経験を持った技術者が人工知能を提供する側にはいたとしても、Customerの中に存在するとは限らない。むしろ存在する可能性は低い。提供側が精度◯◯%出ますのでご安心をという説明が出来たとしても、Customer側は何故そのような結果になるか、という点が理解しづらいはずである。

対して、一般的なWebシステムを開発する場合は、Inputのデータを与えてApplicationのlayerで演算をし、DBに格納・結果の可視化しOutputする一連の流れは、このシステムの業務手続きのフローを明確化したり、結果の出力サンプルをSales担当でもおそらく作成はできるであろうし、そしてこれらの内容を受注の前にイメージの共有がCustomerにでき、おそらく理解も可能なはずである。人工知能のように上記評価プロセスを実施しなくても、結果までがある程度見えてしまうという点が大きい。

最近は人工知能の評価プロセスを回す前、具体的には受注の前のタイミングで簡易的に評価プロセスを回すツールなども多く出てきている。今後これらのニーズは高まっていくであろうが、下記にまとめるように売ることを難しくしている要因全てを解消できるわけではないので、これらは業界の課題としてまだ残り続ける。

難しい要因のまとめ

• 売ることが難しい要因① : Sales担当者が受注の前にどれほど顧客課題を解決できるかの見積もりが難しい。
• 売ることが難しい要因② : データを集めて、モデルを構築し、その後に評価を行うプロセスを入れないとプロジェクトの成功・失敗が正確に分からない。
• 売ることが難しい要因③ : 一般的なシステムと異なり、InputとOutputまでの業務ロジック、更には演算(途中結果を含む)の可視化が難しい。
• 売ることが難しい要因④ : 人工知能が得意とする、もしくは課題解決可能なものは日々広がりを見せているが、まだまだ人間の能力を大きく超えることが出来ていない。それをCustomerの期待値に合わせて説明するということも難しい。

売る側の人間からのレポートは以上です。

何を問題とし、どのように解くか

@yutakikuchi_です。ビジネスの立場の違う人間同士だと、向き合っている問題が世界情勢、市場、顧客課題詳細など自分が一番解くべき問題についてはレイヤーが異なることが多い。それが故に一緒に問題解決の話をしていても、プロトコルが合わずに、意見の食い違いが発生する。

巷には問題の定義より、課題に対するHowtoのノウハウが溜まっており、方法論ってそんなに重要なんだっけという思いが増してくる。それらにはなぜその問題を解こうとしたのかが書かれていないからだ。重要なのは「何を問題とするか」、その次にどのように解くかの流れである。立場の違う人通しでも、問題の定義がレイヤーごとに明確化され、なぜその問を選定したのかの背景が伝わるだけでも価値があり、そのステップが事前にあれば立場の違う人同士の中でも、意見の食い違いは緩和されるであろう。

ソリューション型とプロダクト型

[asin:B00TCM8TB4:detail]

経営者が考えるビジネスのロジック

@yutakikuchi_です。会社の経営は一言で言ってしまえばビジネス(営利・非営利の事業)を作ることであり、そのために人・モノ・金を動かす権限を持つ。ビジネスには様々なモデルが存在し、どのようなエコシステムを目指すかはその会社の経営者が自身で判断しなければならない。最近良く話す内容としては会社経営も成功ロジックを書くことであり、システムエンジニアが処理手続きを書く事と非常に似ている。成功までの最短となるプロセスをロジックを積んだ言語によって書き起こしているだけである。

ソリューション型

成功ロジックの中身をどう書くか。経営でよく上がる話として、ソリューション型、プロダクト型のどちらのビジネスを目指すべきかという点。または両社を目指す場合のコミット度合いの配分をどのように線を引くか。ソリューションは"顧客の課題を解決すること"であり、コンサル、SIなどはここでは含まれる。顧客のビジネスの深い業務知識を保有し、そこに対して他の誰も届けることが出来ない課題解決のコミットメントが継続できるのであれば、顧客の成功体験サポートをし満足度を得ることで、安定的な収益を重ねることができる非常に有効なビジネスだ。その一方で顧客に向き合う人数と時間を必要とする人工型になってしまう。

プロダクト型

対してプロダクト型とは"自社が開発した製品・商品を必要とされる市場に提供する事"とここでは定義する。モノやサービスを中心として顧客の需要に応えていく方針を持ち、自発的なプロセスを回していく。プロダクト型でも製品の提供結果として顧客の課題を解決する(上記のソリューション)ことは可能なので、ソリューション型の定義の中にプロダクト型も含まれるという定義がより近いであろう。自身たちが作るプロダクトの定義や展開先の市場特定もプロアクティブな意思決定が可能であり、課題に対する時間のコントロールが可能。その一方で開発初期においては本当に市場を取れるかどうかの不安が常に残る。

決定的な違いはなにか

ソリューション型、プロダクト型の決定的な違いはなにか。それは顧客課題解決に対しての時間の使い方とキャッシュの発生である。どちらを会社の中心ビジネスとして採用するかによって対応する人の姿勢とスキル要件が大きくことなってくるので、会社全体としての顧客課題への向き合い方というものが自然と決定される。ソリューション型は役務ベースでのコミット成果に対する収益であり、プロダクト型は市場浸透に対しての収益となる。両方の型をビジネス目指す会社も多く、特にソリューション型で得られた具体的な知見をヒントに汎用化プロダクト型にシフトしていくやり方だ。ソリューション型の具体例を基に共通化して使える部分を抽象化した形で汎用型のテンプレートを開発し、ビジネスや業務の効率を目指すスタンスはソフトウェアの開発業務でもよく行う。会社内でビジネス変換を個別ソリューション型 => 汎用型プロダクト型に行う場合は全社にその戦略転換を伝達し共通理解と認識を持ち、採用要件が異なる中で集められたメンバーで役割を担う組織を作り、実行していく必要がある。