工程のDX化って難しいですよね DX版のQC7つ道具ってご存じですか？
今は猫も杓子もDX化といわれて、奮闘されている方々も多いかと思います。
製造業の工程のDX化ってなかなか難しいです。特に効果を出すところとか、そもそもデータ分析なんかしてこなかった現場の人たちにどう分析させるか…。
工程にデータはたくさん溜まっているけど、全然見ていないとか、どう改善に結びつけていいか分からない、そんな悩みもあるのではないでしょうか？
QC7つ道具
工程改善のツールとしては誰もが知るQC7つ道具。最近はソフトウェア化されてだいぶ便利になってきています。が、これは電子化でDXではないですね。合理化とか高効率化にはなりますが、作業が自動化されただけで、何か変革要素があるかというとつらいものがある…。
あと、工程のIT化でたくさんのデータが集まるようになってきていますが、せっかく集まったデータはいわゆるビッグデータであることが多く、QC7つ道具のほとんどの機能で扱うことができません。折角集めたデータを活用できない、これ結構致命的です。電子化や自動化されればいい、というものではないんです。
DX版のQC7つ道具 DN7
GitHubにオープンソースとして公開されている分析ツールです。QC7つ道具をベースとして開発された工程改善用のデジタルツール群です(と紹介されていますが、QC7つ道具とはだいぶ別な機能と考えた方がいいかも)。
GitHub - apdn7/AnalysisPlatform
Analysis Platform ＋ DN7 for Industorial DX
いろいろなデータベースやCSVなどからデータを集約して、紐付けして、いろんな工程改善に活用できる分析ができるようになっています。工程のエンドユーザでも簡単にグラフ化できるとか、自動で最新の情報を表示し続けてくれるとか、気の利いたソフトウェアになっています。クラウドも必要なく、Windows PCが1台あれば動くとのこと。私もノートPCに入れて使っていますが結構なデータ量でも問題なく動いています。
全体的にデータドリブンを前提として作られています。データの前処理もある程度自動的にやってくれるので、外れ値などで悩まされることも少ない、ここらへんはBIツールと大きく違うところですね。工程のデータは汚いことが多くBIツールなどでは骨が折れますがうまいことやってくれていて使いやすいです。
7つの分析機能では、個体管理・変化点検出・デジタル版魚の骨・長期変動/変動パターン把握・多変数の相関分析・層別・共起性検出など、工程改善に役立つような分析が数クリックでできたりします。普通の分析ツールやBIツールではどう組み立てれば工程に役立てられるか、といったことなどを考えて作ったりしないといけないですが、それが専門的な知識なくスパッとできるところがいいですね。
こういう分析ツールがオープンソースなんて、いい時代になりましたね。
こっから先はOODA考えようね、ってお話 データドリブンで行こう
OODAループという言葉をご存じでしょうか？
OODAループ(ウーダループ)は、迅速な意思決定と実行のための思考法です。元々は戦闘機のドッグファイトから洞察されたモノですが、ビジネスやスポーツなどあらゆるシーンでの改善に役立つ考え方です。OODAは、Observe(観察)→Orient(状況判断)→Decide(意思決定)→Act(実行)の4つで構成されています。
変化に強い「OODAループ」とは？「PDCAサイクル」との違い (keyence.co.jp)
状況を観察し、状況判断・方向付けを行い、意思決定、そして行動、といった迅速な意思決定と行動のためのフレームワークです。
OODAなんて知らないよ
よく大企業で、予算を計画通り使いきれ、とか、年計を立てて1年間その計画通り寸分たがわず実施しなさいとか、KPI目標を1年で達成、とかありますよね。これがPDCA、というかその弊害。もちろんテーマなどにもよりますが、不確定要素が強いテーマでは、これやると数か月もたたないうちに状況が変わって意味ない計画になったりしかねません。DXは正にこの類なのではと思います。誰も正解が分かっていないのに1年単位で計画立てて予算も使い切る、こういうやり方してたらうまくいくものもいかないですよね。状況に応じてフレキシブルに仕事したいと思いませんか？その考え方、OODAループなんです。
データドリブンは基本OODA
データドリブンはデータから始める、という考え方ですね。「まず見てから考える」なんて言われ方もします。理論がどうだろうが、経験がどうだろうが、データは正しい。データが正しくないとすると計測や情報伝達に問題があるときだけ(これはデータサイエンティストがよく陥る落とし穴です。データサイエンティストはデータが正しいと妄信して解析しちゃいがち。検証しようにもドメイン知識であることが多いので専門外のデータサイエンティストには難しいですね)です。
データが正しくて、データが真実、故にそこに現れた現象を通じて問題解決を図る、これがデータドリブンですね。改善にドメイン知識が必要となったときも、優先度付けや新たな知見を与えてくれ、役立ちます。
データの観測から始める、Observe(観察)からスタート、出てきました、OODA的アプローチ。データドリブンは基本OODAスタンスですね。
とはいえ、Act(実行)のところで改善、となるとそこからPDCA回したりもします。ということで、OODAとPDCAのベストミックスで行きましょう。
AIは面白くなってきましたが、まだまだのところも 選球眼が重要になってきます
巷ではChatGPT旋風が吹いていますね。詳細な動作原理は、他のページを見ていただくとして、確率的に最も人間が自然と感じる回答を生成するのが特徴です。確率的に最も自然、というところがミソですね。TransformerというものすごいAI技術があるんですが、それに強化学習を組み合わせたことによってかなり自然な回答ができるようになってきています。
ChatGPTは賢いのか
ChatGPTが返す回答は、ChatGPTが創造したものではないです。人間が作った文章をデータセットとして学習しています。プロンプト(人が入力した質問)の内容をもとに学習したデータの中からもっともらしい答えを返してきます。故に、情報が少ないことなどは結構間違った回答を返します。それがよく分かるのは言語の差で、同じ質問を英語と日本語で実施すると、ほとんどの場合、英語の方がちゃんとした回答が返ってきます。日本語は正直まだだいぶ怪しい(先日OpenAIのサムCEOが来日して日本御の学習データのウェイトを引き上げるといっていたので数か月で状況変わるかもしれないですが)。
ChatGPTにプログラムを書かせるとよりはっきりします。一見きちんとしたプログラムを返してきたりもするんですが、実際には間違ったものや動かないものを返したりもします。普通の質問に対する回答は真偽の判定が難しいときもありますが、プログラムの場合はイケてるイケてないははっきりしますね。全部書かせてまともに動くかというと難しいレベルです。ただ、あの機能どういう関数だったかな、とか、プログラムの骨格やパーツを先に書いてもらってちょいちょい修正して長めのプログラムをサクッと完成させちゃう、みたいな使い方としては非常に便利です。サポートツールとしては有能だと思います。返ってきたプログラムが正しいか否か、どう修正すればいいか、プロンプトはどう書くべきか、ここら辺はちゃんとやらないと使えません。
ちなみに、賢さの原点は人が書いた文章やコンテンツでしたが、もう一つ、強化学習というところもChatGPTの賢さの理由です。が、この強化学習をしているのがまた人間なんですね。結局は過去の人間の蓄積と判断に大きく依存しているということです。「賢っ！」って思ったとしたら、その元ネタを書いた人達や回答にイイネを付けた人達のことをそう思っているという感じですかね。
情報が少ないAIはどう動くか
AIの勘違いの面白い例を。TwitterでAIが考えるというシリーズを投稿しているツノウサさんの作品？です。これ、英語のことわざとかだったらこうはならないでしょうし、学習が進んでいけば、そのうちこういうものは見れなくなるでしょう。ある意味今だけ楽しめるコンテンツです。
ツノウサ on Twitter: AIが考える「豚に真珠」 AIが考える「二兎追う者は一兎も得ず」
ツノウサ on Twitter: AIが考える「ひじきのタイタン」 AIが考える「奈良県」
ツノウサ on Twitter: AIが考える「ウミネコ」 AIが考える「モスバーガー」
ツノウサさんの作品他にもたくさんあるので是非ご覧になってください。笑えます。この笑えるところが重要です。この情報はイケてるイケてない、イケてないところが面白くて笑える、ここは人の判断だからこそ、ですね。この絵の妥当性をAIは判断できてなさそうです(笑えるようにチューニングされている可能性もありますが、もしくは単に学習データ量不足かも)。確率的に妥当、の一形態、といった感じですかね。
結論ですが、サポートツールとしてAIは日常生活や仕事でも活用できるレベルになってきています。時短のためにもどんどん利用しましょう。ただ、その情報が妥当か否か、選球眼が必要になってきます。鵜呑みにすることなく、うまく活用していきましょう。
クラウドファースト、という言葉に潜むダブルスタンダード性
自分をよく知っている人、と思っていた人から、クラウド否定派なんですか？と聞かれました。その人に比べたらだいぶクラウド利用しているんですが…知ってるやろ、と思わず突っ込みたくなりました。クラウドは基本肯定派ですし、普通の人よりは活用してる方だと思います。が、確かに、クラウドの利用を否定しているところはないことはない。クラウドと一言で片づけているところに問題がありますね。
クラウド活用の種類
クラウドといってもいろいろあります。パブリッククラウド、プライベートクラウド、ハイブリッドクラウド。
パブリッククラウドは、ユーザーを問わず提供されている一般的なインターネット上のサービスの基盤と考えていいでしょう。一方、プライベートクラウドは、特定のユーザーが占有しているクラウド環境で、ユーザーが独自に構築したクラウドか、クラウドプロバイダーが提供した隔離されたクラウド環境を利用する形態などがあります。ハイブリッドクラウドはそれらの折衷版ですね。
さらに、今はクラウドファーストからクラウドネイティブにシフトし始めています。クラウドの利用を"優先"して考えようね、から、クラウドを”前提”として、クラウド環境に最適化されたシステムやアプリケーションを設計・開発することにメインストリームが移りつつあります。まあ、これはいいですよね。
クラウドはなぜ早く使えて、安いのか
クラウドファーストでよく語られる理由は、クラウドはオンプレミスに比べて、"低コスト"で”早期の導入・運用が可能”という点です。嘘じゃありませんし、私もこの理由で多くのサービスを理由しています。が、皆さんがこれを考えるときに気を付けないといけないのは、この前提にある過程です。
この話、多くはパブリッククラウドが前提なんです。多くのパブリッククラウドは、安いか、無料だったりします。なんでそういうビジネスが成り立つのか、その答えがタイムシェアリングです。
さて、クラウドの基盤であるデータセンタは高額です。例えばAWSの日本での2022年単年データセンタインフラ投資は3480億円で、こんなデータセンタをAWS単独で使い切る訳がないですね。様々な企業、ユーザがこのデータセンタを共同利用します。例えば1万社で使っているとします。1社あたりの投資額は1000万円/年となって、大した額じゃなくなります。もちろん大規模投資によるボリュームディスカウントはありますが、複数の企業で共同で使うことによって、データセンタの稼働率を上げると共に、如何にも大量の人が同時にリソースを利用しているように見せかけているとも言えます。分かり易い例で考えてみます。1日は60[s/min]x60[min/h]x24[h/day]=86,400秒です。1万社の社員が8.64万人いたとして、1人が1日1秒しかPCを使わなかったとすると、全員がばらばらに使ってくれれば、データセンタはPC1台あれば事足りることになります。これは極端な例ですが、ユーザ全てが100%負荷でCPUやメモリを同時に使うことはなく、使ってもちょっとずつずれているので、実は全員分のPCを集めた能力はデータセンタには要らない、ということになるんです。これがクラウドのメリットで安くなる理由です。
パブリッククラウドが安くならない条件
パブリッククラウドは、システムのメンテナンス料とかも入っているので中小規模でシステム管理者などを雇うのが厳しい場合は活用を考えてもいいと思います。
ただし、システムを100%負荷で使い続ける場合はどうなるか。極論でデータセンタを丸ごと占有しているような負荷を考えてみます。この場合、データセンタを建設した金額を丸ごと払わないといけません。それにシステムメンテナなどの労務費、電気代とクラウドベンダの利益が載ってきます。はい、この場合は自分でデータセンタを用意した方が安くなりますね。これがプライベートクラウド(ユーザ構築の場合)とか、オンプレミスになります。
これは言い過ぎですが、負荷が高くて、ある程度データ規模がある場合(規模が少なすぎるとメンテナの労務費などが無視できなくなる)は、パブリッククラウドを主に選択するのはよく考えなければなりません。プライベートクラウドをメインとして、利便性やアクセス容易性などの利点を鑑みパブリッククラウドを適宜融合して使うハイブリッド構成が多くの場合妥当な構成になります。もちろん負荷が高くてもランニングを常に上回るような利益が出る事業であればパブリッククラウドもOKです。
パブリッククラウドは、利用料金は全てクラウドベンダに行きます。で、サブスクリプションでランニングコストがかかり続け(初期投資が必要なく、経費で済む、というのは利点でもありますが欠点でもあります)、どこかで損益分岐点を迎えます。すなわち、同じ規模の設備を初期投資した金額と、払い続けるランニングの累計金額がどこかで逆転してしまうんですね(本来の損益分岐点とは少し意味合いが違いますがイメージしやすいと思いますのでこう表現しています)。で、負荷が高い工場のデータでは、この分岐点が2～5年できてしまうことが多いんです。年間の経費がすごいことになって、どうしようもなくなる、という事例が後を絶たないです。気を付けましょうね。
DXという多大なる見栄の代償、という笑えない話
DXという御旗のもと、数多くの方がDX化に向けた取り組みをされていると思います。無理やりやらされている方はご苦労様です。
企業利益を減らし続ける罪悪
久々に、日本にもましなことをいう人がいるな、と思った記事がありました。
以下、引用しながらざっくりまとめます。
「誰も嬉しくもないし、得もしていないのに止められないことがある」
DXの名のもとに、データ収集基盤や分析基盤、活用基盤に多大なる投資をし、DXらしきことを始めてみたのに、嬉しい変化を得ることができないケースがある。
「お金を使ってITシステムを構築すれば何とかなる」というスタンスで、分かっていながら結局、ITシステムに膨大な投資をし、成果の出ないモノが量産されていく。
勝手に量産されるだけならまだましで、
最悪は、使いにくいモノや、誰も使わないモノや、使っても成果の出ないモノが生き残り続けるクラウド上で構築したシステムに対し、サブスクリプションというワードで表現された、一見すると少額だが冷静に計算すると高額になりがちな月額課金サービスを利用してしまい、ひっそりと企業利益を減らしている。
うーん、分かってますねー。サブスクリプションというのは、クラウド企業への献金ですよ、特にリソース占有率の高い製造業の工程データでは…。
基本納得、ですが、"量産されるだけならまだしも"のフレーズは危険ですね。量産される＝現場に導入される、なので、裏で工程の改造など導入コストがかかっています。お金だけでなく、人工も。労務費まで考えるときっと全然無視できないコストですよ。
ROIは、ITとはいえ、ちゃんと考えましょう
サブスクリプションというのは、お金を永続的に使い続けます。なので、そのランニングコストより多くのコストダウンを実現できなければ、せっかく現場が頑張って稼いだ利益を減らすことになります。現場がどれだけ頑張っているかはみなさんご存じですよね。それをごっそり他人にあげちゃう、って、まずいと思いませんか？
「IT投資に投資対効果ROI(En: Return On Investment)を考えたら何もできない！」これはこれで正論。私も都合がいいときにこう言いますが、ちゃんと考えていただきたいのは、初期投資とランニングコストでは全然意味合いが違うということです。初期投資は効果の累計で消していけます。いつかは償却できる、50年後だろうが…。が、ランニングコストはコストも累計されるので、結構エグイんです。別の言い方をすれば、初期投資はいつかはPayします。ランニングコストは効果金額がそれを上回らければ、赤字を永遠と垂れ流すことになります。さらに別の言い方をしましょう。出血しても、血を止めれば、いつかは回復します。出血しっぱなしで、止血せずに血を垂れ流し続ければ、いつかは死んでしまう、かもしれません。そういうことです。
まあ、最悪の最悪、使いにくいモノや、誰も使わないモノや、使っても成果の出ないモノもよしとしましょう。が、それに、永遠とコストを払い続ける(クラウドベンダに献金し続ける、血を流し続ける)は、まずいです。ここら辺、分かってない企業は、カモネギ状態ですね。特にGAFA系が相手では、日本企業の利益が海外に流出するだけです。
なんでそうなるのか
「DXだからとりあえずデータを集める」、ということをするとこうなりがちですね。「とりあえず集めてから、何に使えるか考える」、あー、失敗するお手本ですね…。
「こうしたいから、このデータを集める」がスタート地点です。マネタイジングともいわれますね。どう利益化するか(どう損失を減らすか)、視点で考える必要があります。
個人的には、データドリブンになれ、と口外していますが、こと何のデータを集めるか、のMustアイテムの選定には「データドリブンで行くなら使うな」といいつつ魚の骨を使います。
データドリブンでは、「取得出来得る全てのデータを記録する」が重要です。が、我々が生きているのは現実世界なので、ビジネスとして成り立つためにROI(センサ一つお金がかかります。配線だって、送信プログラムだって、ただではできません。データを保持するストレージだってお金必要ですよね)を考えなければならないので、妥当な投資額に抑えるために魚の骨で必須のデータを絞り込むことを考慮した方がいいケースは多数あります。使うならこういう感じで。
ターゲティングが重要ってことです。もしくは、これでどれだけコストダウンできるから、やろうって感じですね。その代わりその際にITコンサルでありがちな、「皮算用で大風呂敷」は止めましょうね。適当に水増しした情報で稟議通して、あとで困るのは現場かあなたです…。
AIは人の仕事を奪うか？それとも寄り添うのか？
AIが人の仕事を奪うと話がよく聞かれます。果たして、どうなのか。
AIは人を超えるか？
シンギュラリティという言葉をご存じですか？技術的特異点(En: Technological Singularity)とも言われ、発明家にして思想家のレイ・カーツワイルがAIの技術的成長が指数関数的に続く中で、AIが「人間の知能を大幅に凌駕する」時点が存在し、それをシンギュラリティと主張しました。
少し古い映画ですが、ターミネータではスカイネットのコンピュータが自我を持った結果、人間と対峙する結論に至ったというSFがありました。核攻撃による全面戦争を起こし、人類を一掃したってやつ(地球の存続に人類の存在が問題と結論した)です。シンギュラリティが現実に起これば、このような話も空想ではなくなるかも、ですね。
人の仕事を奪う、かもしれないAI
少し前に話題になった論文が、イギリスのオックスフォード大学マイケル・A・オズボーン准教授が2013年に発表した論文です。これから10~20年程度で、アメリカの総雇用者約47%の仕事がAIによって自動化される、将来90%以上の確率で消える職業リストも挙げられており、ショッキングな内容の論文でした。現時点ではこれを否定する論評も出ていて、まあまあ、という内容ですが、一方的に否定できないのも事実です。
数年前にはニューヨークのウォール街には数億円プレイヤという金融トレーダが数多くいました。今はほとんどの取引はAIがやっています。海外のパラリーガルという弁護士のサポートを行う職種はAI技術によって激減しています。今危ないといわれているのはタクシードライバですね。自動運転が実用化されれば、人件費の削減ですぐに淘汰されかねない。トラックのドライバも一緒です。今は人が足りず、求人しても人が取れなくて大騒ぎしていますが、AIが実用段階に入れば、途端に失業になりかねない。
「不可能とは言えないが、ほぼありえない」AIの非可能性
グーグルのResponsible AIグループに所属していたシニアエンジニアのブレイク・レモインは、AIを搭載したLaMDAというチャットボットと会話しているうちに、LaMDAが｢感情｣を持つようになった、つまり人間と同じように感じることができるようになったと思い始めたとワシントン・ポストに語りました。これは否定されたものの、まあ、今の技術ではね、というのが本音かと思います。不可能とは言えないが、がどこまで言えるかは、誰も分からないです。それこそ神のみぞ知る…。ある日、超えちゃうかもね。
ロボットの3原則
SF作家アイザック・アシモフが1950年に発表した「我れはロボット」(I, Robot)の冒頭部分で、"人間に危害を加えてはならない", "人間の命令に従わなければならない", "自己を守らなければならない"というロボットの行動を支配する3原則を示しました。 AIにも守って欲しいですよね。AIは合理性まっしぐらなので、そう思ってくれるのを願うしかないです。さて、人の仕事を奪うことは、人に危害を加えていないのか、ちょっと考えなきゃ、ですね。というかとにかく前向きに判断してもらいたいものです、AIに。
で、どうする？
過去にあった状況の中で、どうすべきかは、実はAIをうまく使えば人間が太刀打ちできない領域まで来ています。人間のすごさは、空気を読み、人を読み、これまでにない新しいものを創造するところです。少なくとも今のところ究極にはAIは人にかなわない、今はね。AIに負けないようにしていきましょう！
分析プログラムもAIが書いてくれる世界が来る、かも。
ちょっと、いつもと違う話題を。
データ分析をしていると、分析コードは多かれ少なかれ、書かないといけませんね。少し前に、「プログラマはAIに駆逐される職業」みたいな話がありましたが、それが少し真実味を帯びるようなソリューションが出てきました。
AI Programmerという黒船
「何をやりたいかを」適当に日本語で書くと、それに相当するプログラムを各種言語でAIが自動生成してくれる、というサービスが出てきました。
結論から言うと、よくできていると思います。まだまだの所はありますが、将来に期待が持てる内容です。しかも、日本で開発されているところがすばらしい。
SQLや正規表現はかなり実用的なレベルまで動いていると思います。分析コードやプログラムは、ある程度小規模だとOKな感じですね。ただし、人がある程度寄り添ってあげないと、ドンピシャなプログラムは書けないことが多いです。それに、出てきた結果が妥当かどうかは、ある程度プログラムを読めるスキルがないと厳しいかも、です。それなりに動いちゃうので…。
で、ちょっと、試した感じで、かなりざっくりな推測ですが、こんな感じかと。
1. 入力された日本語を英語に訳す (既存技術)
↓
2. 英語からNLP分析を経て、ある言語(例えばpython)でのスクリプトを生成
多分、ある程度ルールベースっぽい感じがする
↓
3. 生成した言語から、他のプログラム言語に変換 (既存技術)
とはいえ、よくできていますね。素晴らしい！
プログラマはAIに駆逐されるか
プログラミングが不得意なデータ分析者がAIの助けを借りて、というのは現実味が出てきました。バリバリ、プログラミングをする人でも、「あの処理どう書くんだっけ」をググるよりは、このような機能を使う方が効率的になるかもしれません。AIのプログラミング支援というのは、ありですね。
今回のAI Programmerを見ていて思いましたが、AIの合成するコードは非常に合理的です。ワンライナーになりがちな傾向が見られます。これは人間のプログラマにとって必ずしもよくはない、特に可読性が高いとは言えないですね。デバッグとかもしにくい(きっとAIにはそんなものがいらない!?)し、メンテナンスもやりにくい。まあ、こういうところも、そのうち調整できるようになるでしょうから、ありはありでしょう。
で、プログラマが駆逐されるか、というと、まだまだな感じはします。短文のプログラムではまだしも、大規模なプログラムや、システム構築、となると少し、いえ、だいぶ先の話になるでしょう。とはいえ、油断してると気付いたら仕事奪われるかも、です。
プログラミングの素人にとっては、プログラミング手法を手に入れられる、玄人にとっては仕事の初動効率を上げられる、ある意味DX的な働き方の一角となる技術かもしれません。楽しみな技術です。
データ分析者にとっては、コーディングは分析の手段なので、コーディングの自動化は喜ばしいことかもしれません。データ分析に集中できるようになりますね。
暫くは、共存共栄というか、我々としてはうまく活用して効率のいい開発・分析をしていきたいところですね。
