Column

Analysis Platform + DN7でのデータ活用などに関するトピックを扱っていこうと思います。

Excelから保存したCSVをお使いになるのは止めたほうがよろしいかと。知らないと怖い、Excelのデータ破壊の罠

知らないうちにデータを破壊されているとしたら、あなたはどうしますか？
しかも不可逆破壊、多数(一部はどう頑張っても元に戻せない💦)。

機械学習やっている人はこれメチャメチャ困りますよね。すぐに「元のCSVない？」って聞きたくなる…。
AP+DN7はいろいろなデータベース、データフォーマットに対応していますが、Excelが読めないのはこういうところかと…。

ということで、Excelから保存したCSVは使うのは避けましょう。思わぬ罠に引っ掛かります。エラーが出ればまだいいですが、出なかったら誰も知らないうちに大量のごみデータが混ざっているかもしれません…。

ちなみに、巨大なCSVなど、ビッグデータを扱ううえでデータファイルを見るのはVS Codeがオススメです。なぜかは、いろいろ気が利いてて速いし、無料だからです。
そのうち紹介コラム書こうと思います。

AP+DN7で使うデータ、というかBig Data解析などでも、データはVS Codeで確認しましょう。便利だし、軽いです。

CSVの中身確認したいと起動されてますか？Excel？いろいろ起こりますし、何十MBもあるようなCSVとかだと、もさーっとなりますね。
さくさく開きたい場合は、メモ帳を使いがちですね。でも、Big Data扱っていくんだったら、是非Codeを使いましょう。

https://azure.microsoft.com/ja-jp/products/visual-studio-code/

細かい話はさておき、皆さんが使うコードは文章もデータもUTF-8にしときましょうね。
そのうちShit JISは使えなくなっちゃう可能性無きにしも非ず、です。後でつらくなるだけです。まあ、あったとしても、もうちょい先ですけど…。

ホントは怖いヒストグラム、意外と小難しいです。Big Dataでは、密度曲線の方がありがたい件。

ヒストグラムはデータの分布を見る手法としては王道ですが、ことBig Dataの解析においては注意した方がいいです。

階級の数(Bin数)を決定する目安としてよく利用されるのがスタージェスの公式(Sturges' Formula)ですね。観測数N、階級数kとして、"⌈ ⌉"は天井関数(切り上げた最小の整数)

Big Dataでは、68–95–99.7則をのたまうことなかれ

一応私も工程の品質管理に携わっていたころがあるので、例えば±3σの外は0.3%しか起こらないから、ちゃんと覚えておくように、と言っていました。±1.96σの範囲に95%のデータが収まる、っていうのも同じです。工程能力指数(算出にσを使っている)が1.33必要だとか、3σ管理限界線でLCLやUCLを算出することも間違いではありません。相手が正規分布だったら、です。SQCでは常識的に知っておかないといけないことですね。

では、Big Dataではどうか。残念ながら上記の内容はあまり意味がないんです。なぜなら、相手が正規分布であることがほとんどないからです。
ちなみに、チェビシェフの不等式というのがあって、こちらは正規分布を想定していないのですが、これによると±3σの範囲に88.9%、±6σの範囲に97.2%のデータは入っているということになります。正規分布の68–95–99.7則からだいぶ離れていますね。

SQCを否定しているわけではないですよ。工程管理はちゃんと68–95–99.7則や工程能力指数に基づいて、これまでと同じように滞りなく行いましょう。SQCではBig Data解析でできないことができるんですから。
適材適所で、Big Dataを扱うときは、68–95–99.7則はいったん忘れましょう。SQCとBig Dataでしっかり使い分けて、それぞれのメリットを享受しましょうね。

GIGOってご存じですか。"Garbage In, Garbage Out"、AIが人間を超えられない、理由の一つです。

GIGOは、"Garbage In, Garbage Out"の略、ギゴとかギーゴって呼ばれています。「ゴミを入れたら、ゴミが出てくる」って意味ですね。品質の悪い不完全なデータを入力したり、品質の悪い特徴量を使ったりすると、品質の悪い不完全なAIモデルや結果が出力される、という意味です。機械学習ならまだ解釈できて、おかしいと気付けることもありますが、深層学習であれば手の付けようがないです。それに、思わぬ拍子にその影響が出てきたりする。もし自動運転でそういうのが出たら、その瞬間に大事故ってことになりかねませんね。AIの怖さの一つです、悪いことを覚えたら悪い子になる。隠れ悪い子、であれば、怖くて使えないですね。

深層学習や機械学習は万能だ、と思い込んでいる人が未だにいますが、正直、錬金術と同じです。錬金術ではまず金は作れないけど、そこで培われた周辺技術は後に近代化学の発展に大いに役立った。似ています。未来予測まで含め完全なAIモデルなどというのは、少なくとも今の技術レベルでは実現不可能です。ましてや、誤ったデータを食わせた深層学習や機械学習は、化け物かゴーストみたいなモデルにしかなりません。正しく、用途に適正な、品質の高いデータをうまく制御して、適切に学習させれば、特定の用途において大きな成果を得ることができる、それが現時点のAIの現実です。

我々の工程のデータは、出荷検査データなど、ある程度データ品質を担保するようにとられているデータはまだしも、IoT的にPLCやIoTセンサから取り出したデータに関しては、データ品質が伴っているわけではありません。皆さんは、データを集めて満足していませんか？そのデータの中身は検証していますでしょうか。確認や検証をしていないデータが、仮に数年間溜まっていたとしましょう。それはほぼほぼゴミの山かもしれません。価値ある品質のデータを貯めてこそ、DXの時代に進めます。チェックしていないデータを溜めているようでは、デジタル革命は進みません、残念ながら。

AP+DN7には、目立たないですが、ある程度のゴミは、さくっとクリーニング・対策してくれる機能がいろいろ実装されています(限界はありますけどね)。
「AP+DN7って、BIツールといっしょでしょ」
という方もいます。確かに、見かけはそうかもしれませんが、BIツールはそんな気の利いたことはしてくれません。AP+DN7は、工程の「あるある」な問題をよしなに処理して結果を見せてくれます。同じデータをExcelで見てみていただければ、その便利さを実感していただけるのでは、と思います。

"Excelの結果を、電卓で検算しといて"は、一概にない話ではない…です

SNSで"Excelの結果を、電卓で検算しといて"というネタがときどき話題にあがりますが、Excelの計算結果を信用しないデジタル社会に乗り遅れた前時代の人間の言動と、そう言い切れる話でもない、かもです。

製造現場にも会社によってはExcelシート多いですよね。で、そういうシートを見ると、参照がずれていたり、式が入っているはずの列に忽然と訳の分からない数値が入力されていたり…。マクロが使われてたら、まあ迷宮入りですね。恐らく最初に作成されたときはちゃんと検証もなされたシートだったんでしょう。が、長年使われている間に、だんだん、不特定多数がいじり倒して伏魔殿になる…。ほんとに正しい結果が出ているかは、誰も分からない。

絶対に間違えてはいけない数値の場合、"電卓で検算しといて"という言葉はあながちダメとは言えないです。どうしてもExcelでやるのであれば、電卓で、とは言いませんが、ダブルチェックはしておくべきです。単純な計算ならまだしも、参照や式を使っているシートであればなおさらです。少なくとも大手企業で、品質保証をExcelでやっているところはあまりないと思います。いろいろ理由はあるとは思いますが、改変されてしまう可能性のあるExcelでは安心して、もしくは信頼して品質保証することはできません。間違えてはいけないものには、Excel使うのはお止めになったほうがよろしいかと。きっと、いつか、誰かが、苦しみます。

人はミスをするものですが、たとえそれが意図しないものであっても、Excel上でなんかやらかしてしまうと、そのエラーは保存され、次から次へ複製され、蔓延していきます。派生していった全てのシートをしらみ潰しに検証していくなんで地獄です…。そういうミスでトラブった経験のある人なら、"Excelの結果を、電卓で検算しといて"というのも無理はないですね。その人が信用していないのは、Excelではなく、「人」です。

Excelは便利なので私もよく使います。適材適所かと思います。が、DXの働き方として、Excelを基軸に置くのは留意しましょう。ロジックが触れてしまう以上、人災でより多くの労力を発生させてしまうリスクは拭えないです。仕事を効率的にするつもりが、未来永劫苦しまされるかもしれませんよ。

要注意なBIツールのガバナンスコントロール　無法地帯になっていませんか？DXに必須も、足かせになるリスクも

BIツールはDX化には欠かせない手法の一つです。うまく活用すれば業務改変も夢ではありません。

ただ、工程で活用する際に気を付けておかないといけないことがあります。ITガバナンスコントロールです。
IT ガバナンスとは、情報/IoTシステムのあるべき姿を示す情報システム戦略・ルールの策定およびそれらの実現に必要となる組織の遂行能力のことです。とはいえ、？な感じがすると思いますので、イメージしやすい実例を。
工程Aと工程Bで表示されている不良率の分母と分子の集計項目が異なっている、ということが現場で実際よくある事例です。例えば、分子に不良判定された製品だけ含むとか、装置内でジャムって破棄した製品も含めるとか、みたいな差です。この時、工程Aと工程BのBIツールで表示されている不良率は比較してはいけないですね、定義違うので。更に、例えば、その製品自体は正常だったのに、前の製品がジャムって、一緒に破棄したとしたときに、果たして友連れになった製品はNGとカウントするかどうか、生産管理的にはNGでしょうが、製造技術的には問題ないはずです。これ、OKとするか(機械学習的にはこうして欲しい)、NGとするか(生管はこっちでしょう)、はたまた除外するか、に答えはないです、ケースバイケースなので。それに、そもそも不良率は製造投入数基準とライン/装置投入数基準の両方があって、使い分けが必要ですが、そういうプリミティブなところも、使いどころや表記などを統一化していないと人の誤判断のもとになります。
こういうところだけでも、ガバナンスが必要ですね。同じ定義でなければ、それらの数字を例えば工程間で比較するのは意味がなくて、KPIに使ったり、工程間比較を行う場合は、標準化やガバナンスコントロールが必須になります。DXではミクロな領域からライフサイクルマネジメントLCM全体をも俯瞰することで効果を出すことが求められるので、そういう意味でも、標準化は必要です。避けて通れないですし、ほっとくと数年後には伏魔殿の出来上がり、誰も手が付けられなくなります。初期の段階からガバナンスコントロールはやっといた方がいいかと、あとで困りたくなかったら。

もう一つ、大きな問題も。ガバナンスコントロールがないと、「似て非なるツール」が至る所に乱立することになります。いったい何人の人が似たような機能を作っているか、という視点で考えるとリソースの無駄遣いに他なりません。誰かが作って、それが標準化され、皆で使えば1個だけ作ればいい。いろんな人が同じような機能を作っているとすると、人生産性の向上とは程遠い状況になります。
それだけでなく、さらに、使う側にも問題が生じます。「似て非なるツール」が至る所にある場合、その場その場で違いを学習する必要があるので多能工化などを考えた際にマイナスになります。せっかく育てたワーカーがいろいろなところでそのまま仕事できる状態は理想的です。が、毎回教育が必要となるとそれだけで重たいですね。もし同じものであれば、1つの工程で覚えれば、他のどの工程でも同じ使い方や解釈ができます。作業の標準化というのは重要ですね。「前と同じだから」で済むメリットは意外と大きいですし、長い目で見るとボディーブローのように効いてきます。

カスタマイズはBIツールの最大の利点でもあるので、そこはしっかり生かしましょう。ガバナンスコントロールすべき場所と、自由にカスタマイズしてもらうところの線引きが重要です。

DN7、いや、BIツール・Grafana・Excel？、どれやねん、問題

BIツールやGrafanaを現場で見る機会も増えてきました。「どれがいいですか？」と聞かれることが多いですが、「どれも使えばいい」と答えます。
なぜなら、適材適所だから。
目的が違うんですよね…。BIツールは最近いろいろ高機能になってきてはいますが…。

例えば、考えていただきたいのですが、BIツールやGrafanaで、不良などの原因を特定できるでしょうか？
変数が10個くらいであればできなくはないかもですが、今の工程では数百から数千の変数が測定されていて、そこから不良の原因を見抜くのは、だいぶ難しいですよね。
端的に言うと、DN7はそれがサクッとできるように設計されています。

大まかにDN7が他と違うところ
・重要変数の絞り込みができる ⇒  不良の原因を多数の変数から絞り込み、当たりをつけることができる
・結果に影響する間差を検出できる ⇒  特定の号機で発生している不良など、機差や材料間差・ロット間差などを検出できる
・多数の変数の相関関係の分析ができる ⇒  複数工程にまたがった複雑な変数関係を俯瞰して把握でき、工程改善に繋げることができる
・変化点検出や連動性把握が容易 ⇒  いつ変わったか・どこで変わったかが素早く分かり、不良率と連動している変数も見つけられる
・前処理の機能（工程データ特有のノイズ・外れ値処理） ⇒ いろいろ問題になる外れ値除去などを良しなにしてくれる(必要に応じて自動処理を外すこともできる)
・分析画面は製造工程によらない（汎用分析設計） ⇒ 一度使い方を覚えればどんな工程でも使え(教育負荷少・多能工向き)、ガバナンスコントロールも容易
・正規分布状でなくても正しく見れるようになっている ⇒ ビッグデータ(非正規分布なデータ)でもミスリーディングしにくく、データの分解能不足なども分かる
・ビッグデータで破綻しないように設計 ⇒ 従来の統計手法や可視化手法では破綻しがちなビッグデータでもデータをより正確に見れる

BIツール
　〇 集計や四則演算系・基本的なデータ可視化は得意。画面がカスタマイズできる。見慣れた系のグラフが多く、現場に合わせた運用はしやすい。
　× 画面毎に使い方覚えないといけない。外れ値に弱い。多次元の相関分析は難しい。

Grafana
　〇 時系列データ(波形データ)が得意。アラートも出せる。画面がカスタマイズできる。オープンソースソフトウェアで気軽に使える。
　× 多次元の変数を扱うのは結構大変。ビッグデータを扱うときに適当にサンプリングするのは要注意(特徴を破壊して結果に誤差やバイアスが入ることがある)。

Excel
　〇 みんな知ってる、使い慣れてる。見慣れた系のグラフで、現場に合わせた運用はしやすい。
　× データの読み込みやグラフ化などの手数が多い。DXって感じはしない。人が入力した数値はあてにならない(多くの場合、機械学習などの精度をダダ落ちさせる)。
外れ値には弱い。10万行くらいのデータが限界でビッグデータは無理。しれっとデータを破壊する(しかも元に戻せない)。
紙の書類の見た目をそのままExcel化したものは本当にいただけない(データをその先で活用するのは絶望的)し、何なら手で書いたほうが作業者の時間を奪わない。
再資源化しにくい。人手に渡っていくたびにシートが人知れず破壊される(最悪、間違った結果が表示されるけど、誰も気づけない)。
VBAという手の付けられないダンジョンに魔物が潜んでいる(ことが多い)。それを操れる職人以外は手を出せない(属人化の温床)。

ちなみに、プラグイン使えばできるよ、とか、スクリプト組み込みすればできるよ、という声も聞こえそうです。もちろんそういうことはできますが、大勢の人が使っている環境でそういうの揃えていくの結構骨が折れます。あと、スクリプトは本当に大丈夫でしょうか？計算ミスとかBugとかなければいいですが。妥当性検証には結構な専門知識・経験が必要ですし、そういうのを管理・運用するだけでも結構な手間ですね。できないとはいいませんが、一般的に分析の品質コントロールやガバナンスコントロールって結構難しいです。やるならちゃんとやりましょう。

ということで、レポーティングとか集計系の表示とかはBIツール、時系列や異常警告はGrafana、工程改善はDN7でよろしいのではと思います。

OODAはPDCAにとって代わるか？

さて、最近はVUCAの時代 と言われていますね。
　Volatility（変動性）Uncertainty（不確実性）Complexity（複雑性）Ambiguity（曖昧性）
"変化が激しく、あらやる環境が複雑性を増し、想定外の事象が発生、将来予測が困難な状態"のことです。これに対してPDCAでは対応できないという論調があります。そこででよく出てくるのがOODA(ウーダ)ですね。

OODAループ
　Observe（観察）➡　Orient（方向付け・状況判断）➡　Decide（意思決定）➡　Act（行動）

おさらいで、PDCAサイクル
　Plan（計画）➡　Do（実行）➡　Check（評価）➡　Action（改善）

PDCAサイクルは、継続的な実行/改善方法で、基本はサイクルを回す(螺旋状に回す、なんていわれます)感じです。目標・行動する内容が明確化されるため管理しやすく、アクションプランが見える化され、分かり易く組織的に対応しやすいという利点があります。一方で、日本企業ではよくありがちですが、無理な目標では破綻しがち、です。気を付けましょう。

さて、OODAループですが、迅速な意思決定と実行のための思考法になります。自由度が高く、変化に対応しやすいことが特徴です。必要に応じて途中で前の段階に戻ってそこから再開したり、状況に応じて任意の段階からループをリスタートしたりすることが前提です。どこからでも、どんな流れもあり、な感じです。
この考え方はアメリカ空軍のジョン・ボイド大佐が朝鮮戦争の空中戦についての洞察をベースにして理論化したものです。戦闘機パイロットの意思決定が遅ければ、撃ち落されて終わりですね。従来の意思決定モデルが線形であったのに対して、非線形な構造で素早いフィードバックによって迅速な状況判断と意思決定を行うフローです。

PDCAでは変化の速さについていけない、といわれることもありますが、それはサイクルを年単位や数か月単位で回すことが多いからです。週単位や日単位でサイクルを回せば、PDCAだってVUCAな状況に耐えるのは可能かと。
あと、PDCAにはCheck(分析・評価・判断)がありますね。で、これにそこそこ時間や労力をかけますし、その検証ためにDoの中で測定・数値化や客観的指標・情報をとりますが、OODAの場合はそこまで時間や手間をかけないニュアンスが強いです。すぐに判断し動くことが主目的ですので。ただし、OODAでは分析や判断が浅くなりがちですので、時々にでもCheckの要素を入れ、間違えた判断をしていないかなど正確性や客観性を確認することをお勧めします。

ここまで読むと、それぞれは異なる方向性や考え方を持っていることが分かります。そもそも別のフレームワークですね。PDCAの後にOODA的な取り組みを行うことも可能ですし、OODAからPDCAに移行するのもありかと思います。どっちかという単純なものではなく、状況に応じて、柔軟にOODAとPDCAを使い分ける、が妥当なのではと思います。

ちなみに、データドリブンはOODAループとの相性がいいです。データドリブンとOODAループを組み合わせて改善を行なうアジャイル改善は今後重要なアプローチになってきます。今後は製造業をはじめとしてアジャイル品質改善AQI(Agile Quality Improvement)やアジャイル工程改善API(Agile Process Improvement)という言葉が使われるようになるのでは、と考えられます。

侮ると怖い、DXやITのコスト、サブスクリプションの罠、気を付けましょう

最近のDX導入やIT化でよく出てくるのがサブスクリプション。いい仕組みですし、大きな初期投資をしなくて済んだり、全て経費で賄えたり、いろいろメリットはあります。が、よく考えて導入しないといけないです。

実例として、世界的に活用されているTableauさんのコストを考えてみます。いろいろ使えるTableau Explorerで月額4,200円(tableau.comより。以下いずれも2023-02の情報でボリュームディスカウントは考慮なし)とのこと。年間で50,400円ですね。まあ、大したことな金額ですし、これであれだけの機能が使えるなら安いもんでしょう。が、1000人分導入すると、毎年5千万円かかりますね。ということは毎年5千万以上の効果が出なければ、赤字ですね。5年間で2.5億円、結構な額ですね。例えば人件費が年間1千万円とすると、5人分の仕事が削減されなければROIが取れないということになります。もちろん工程改善で5千万円の効果を出してもいいのですが、毎年出し続けなければなりません。結構つらくないですか？

比較で、これまたよく使われているExcelを考えてみましょう。Excelの単価は17,904円(microsoft.comより)。ちなみにOfficeは32,784円。1000人分導入すると、1800万円。これ、買い切りですね。5年でも1800万円。5年で考えると0.36人分の仕事を削減すればいい形です。工程改善だと一回だけ1800万円分の効果を出せばPayします。
なお、今はサブスクリプションモデルもあるので月額1,360円(Microsoft 365 Business Standard)、毎年16,320円払い、1000人分で1632万円、5年で8160万円。1.6人分の仕事の削減が必要です。これも工程改善の場合、1600万円近い効果を毎年出し続ける必要があります。

5年で2.5億円と0.18億円、この差は小さくないですよね。サブスクリプションは気づかないうちに赤字を垂れ流すリスクがあります。いきなり大量導入するのはそれを覚悟する必要があります(欧州や中国などはここを経営判断や経営戦略で躊躇なく導入に踏み切ることが多いです。数年後には結果的にPayしているようなので、そういう荒療治もありかと)。
DXやIT導入に対して、通常の投資のROIと同じ考え方でいいのかはよく考えるべきかと思います。例えばDXによる働き方改革の効果金額を算出するなんていうのは眉唾物の計算をすることになるので、そういう計算でROIが出るといっても説得力はないですし、あとで困ることになると思います。グローバルな競争力を失いたくなければ、ROIが取れないとしても導入していく判断や戦略が必要ですね。まず導入して、少しでも早くDXでの効果が出せる体質への転換を図る、のがよいのではないでしょうか。

あと気を付けないといけないのが、BIツールなどもそうですが、しばらく使っていると勝手に料金が上がっていくことがよくあります。特にBIツールはこれまでに構築した画面などの資産があったりするので、そう簡単に乗り換えができなくなる、ロックインと呼ばれている状態になりがちです。ロックインとは、現在利用している製品やサービス・技術などから別のものへの乗り換えや入れ替えが困難な状態のことを指していて、スイッチングコスト(切り替えに必要なコスト・工数・時間・手間・心理的障壁)が高くなると、ロックインから抜け出せなくなって、料金が上がっても払い続けて使い続けるしかなくなってします。とはいえ、普通は自社開発するより先進的で安定な手法が手に入るので、実績のあるBIツールを使うのが得策だとも思います。

いずれにせよ、リスクを分かりつつ、上手に使うことが重要です。

リスキリング、企業戦略として取り組めていますでしょうか？

日本の製造業で最も先進的な取り組みをされてる企業がダイキン工業でしょうね。
「仕事はせんでよろしい」、いいですね、言われてみたい。毎年100人ずつ新入社員を職場に配属させずにダイキン情報技術大学で2年間みっちりAI/IoT基礎教育やPBL(Project Based Learning：課題解決型学習。アクティブラーニングの1種で、自ら課題を見つけ、その課題を自ら解決するまでの過程でさまざまな知識や解決する能力を身に付ける学習方法のこと)等を行います。大阪大学と10年間、毎年5億円の包括連携契約を結んで、1000人を超える社内データサイエンティストを育てる。素晴らしい取り組みですね。2年間ｘ1000人ｘ1000万円/人・年と考えると200億円分の労務費と50億円の大学への支出、約250億円をかけて人材育成をされている。

欧米などではリスキリングはかなり積極的に行われています。
例えば、ドイツのボッシュでは2026年までの10年間で20億ユーロ(約2800億円)をかけて40万人の従業員をリスキリングするプログラムを進めています。アメリカのAT＆Tはさらに早く2013年に10億ドル(約1000億円)を投じて、2020年までに10万人のリスキリングを行う「ワークフォース2020」を実施。取り組みの先進性や包括性という点で「米国企業史において、最も野心的なリスキリング」といわれたとか。
自動車業界ではEV化やCASEシフト(Connected：コネクテッド[インターネットへの常時接続]、Autonomous：自動運転、Shared：シェアリング、Electric：電動化の頭文字)で「100年に一度といわれる大変革期」といわれており、特に電動化には内燃機関に関する大量の雇用喪失リスクがあって、その他3つにはIT・AIエンジニアの圧倒的な人材不足という問題があります。AT＆Tはスマートフォンの急激な普及や通信の高速化などの通信業界の革命的変化に合わせて、それまでの事業の柱であるハードウェアをソフトウェアシステムに大転換する必要に駆られたというような状況。いずれも企業存続にかかわる深刻なバックグラウンドですね。

企業におけるリスキリングのモチベーションの主なものとしては、DX推進・雇用維持・事業継続があります。DX推進は「攻めのリスキリング」に含まれます。後の2つは「守りのリスキリング」ですね。欧米でリスキリングが進んでいる背景の一つに、リスキリングは外部人材の採用に比べてコストが1/6で済むということがあって、デジタルシフトやAIシフトの波に乗って大規模なリスキリングを行っている企業が多数あります。IT人材やAI人材の枯渇も後押ししている理由ですね。ダイキン工業も攻めまくってます。問題はリスキリング格差。世界中で進んでいるのに日本ではなかなか進んでいないのが現状です、残念ながら。

ついでに、ですが、気を付けないといけないことがあります。リスキリングをした後にその能力を使うところがなければせっかくスキルを身につけさせても最悪転職してしまいます(失業させるよりは転職してもらった方がいい、と書いてある欧米企業もありましたが)。それに、昇格給与制度をリスキリングにリンクさせないといけません。インセンティブです。少なくとも外の環境で評価される金額より低かったり、これまでの職種と同じ金額ではリスキリングを受けるモチベーションが出ません。AT＆Tがやったように事業毎の求人・就業機会情報とその要求スキルを透明化・明示化してリスキリングスキルに応じて社内異動や業務選択を自由化し機会提供する、なんて言うのも一種のインセンティブとして効果が出るでしょう。さらに、リスキリングの時間を就業時間内にすることも重要です。リカレント教育は自主的に行われる自己研鑽なので本人がやりたいようにさせておけばいいですが、リスキリングはDX推進・雇用維持・事業継続に対する企業戦略です。リカレントは個人主体、リスキリングは企業が主導するものであることを忘れてはいけません。

事業展開のために新しいスキルを持った人材が必要、新規事業を創出したい、ビッグデータで価値創造したい/競争力を付けたい、こういうニーズは多いですね。それに対して、短期的には大赤字になろうが、戦略的な投資をする、そういう経営判断が不可欠ですね。体力があるうちが勝負です、そこを逃すと手が付けられなくなる。特にグローバル企業にとっては、このまま欧米とのリスキリング格差が広がっていくと致命的な競争力の弱体化に結び付きかねません。今のうちですよ。ダイキン工業みたいな企業は今後も発展し続けるんでしょうが。