リスキリングに取り組むための「スキルセットレベル」の観点とは

職業能力の再開発・再教育を意味する「リスキリング（Reskilling）」。

「リスキリング」の名称の通り、リスキリングの取り組みについての中心話題は「何のスキルを開発するか」に集中しています。

しかし、単なるスキル開発に留まらない、企業の生き残りをかけた施策がリスキリングです。すなわち、「開発するスキルは、事業の成長に寄与する」という根拠が明らかになっている必要があります。

今回の記事では、リスキリングでセットすべきスキルを、いかに会社の意思を込め、なおかつ社員の納得を得られるように絞り込んでいくかというステップを取り上げます。

今後リスキリングの実施を検討したいと思われている方はもちろんのこと、現在リスキリングを実施しているものの、開発しているスキルに課題を感じている方も、ぜひ参考にしていただければ幸いです。

１．リスキリングの実践成果が問われる「スキルセットレベル」の観点

リスキリングは単なるスキル開発の方策ではなく、環境変化が激しいこの先のビジネス環境下でも勝ち残るための取り組みです。

そのため、経営としての意思・施策としての適切さ・スキル開発のフィット感・人事施策のフォローの3つがそろって、初めて企業の競争力を高めることにつながります。

今回の記事では、リスキリングの成否を分かつ「スキルセットレベル」の取り組みにスポットをあてます。

社員が実際にスキル開発をする観点であるため、リスキリングの直接的な効果を実感しやすい施策なのはいうまでもありません。

ただ、現実的には「何のスキルを開発するか」よりも「何のためにスキル開発するのか」がしっかりと設定されている方が、リスキリングの本質的な成果が得られやすいケースが多いものです。

したがって、ここからはスキル開発の内容そのものよりも、どのようにスキル開発の内容を選定していくかのプロセスに主眼を置いてお伝えしていきます。

２．スキルセットをする上での基本的なプロセス

「ITリテラシー」「ソリューション営業スキル」「ロジカルシンキング」･･････。
リスキリングの開発を考える際、さまざまな対象が浮かぶことかと思います。

もちろん望ましいスキルの全てを開発できればいいのですが、それでは予算も時間も、社員の負荷もどんどん増大してしまうことでしょう。

ここからは、リスキリング対象の納得感を社員に伝えるために、必要なプロセスについて触れていきます。

STEP1：事業の変化の度合いと影響の見極めをおこなう

スキルの対象を絞り込む最初のステップは、外部環境・事業戦略・職種の3つの観点で、As Is（これまで）とTo Be（これから）、それぞれについて言語化することです。

具体的には、以下のようなフレームで事業の変化度合いとその影響を検討していきます。

別記事『リスキリングに取り組むための「経営・戦略レベル」の観点とは』でも触れたように、リスキリングの起点は外部環境変化であることが多いでしょう。

この変化を受けて事業戦略がどのように変わるのかを言語化していくのですが、事業戦略の変化の度合いは、おおよそ以下の3つに分類できます。

自社の事業戦略の変化がこの3つのどれに近いのか、あるいはどのウェイトが最も大きいのかを考えていきましょう。

さらに、事業戦略の変化が、どの仕事内容や人員に影響を及ぼすのかも合わせて検討します。

ここでの重要な狙いは、対象となる職種を絞っていくことです。

もちろん、全社員にリスキリングを要請していく可能性もあるでしょう。

しかし、戦略変化を推進していくためにキーとなる職種を特定することで、リスキリングを社員に要請する必然性が伝わりやすくなる効果が生まれます。

人事施策はつい一律に、と思われている方もいるかもしれませんが、それでは「なぜこのリスキルが必要なのか？」という問いについて、社員の納得を得にくくなります。

具体的な事例をひとつ紹介します。

あるメーカーでは、産業・業界全体が技術革新に伴う構造変化の真っただ中でした。しかし、既存事業にも需要があることで当面は事業が成立する見込みもありました。

したがって、新規事業創出に向け一定のリソースを投下しながらも、既存事業・業務でリソースを維持・縮小しつつも、生産性を向上させることを事業戦略に掲げていました。

つまり全体的なDXの潮流はありつつも、このメーカーのリスキリングの生命線は、既存事業での生産性を上げるための社員教育にあったのです。

STEP2：スキルの変化度合いを検討する

変化が必要な職種が特定できたとしたら、次はリスキリングの対象となるスキルの変化度合いを検討していくステップに入ります。

具体的には「その職種における業務の新規性（縦軸）× 仕事の進め方の変化（横軸）」という観点で、具体的にどのような変化が起こるかを検討していきます。

一般的に「リスキリング＝DX」と認識されがちなため、新規性が高く、仕事の進め方の変化も大きい「右上」の領域に着目されがちです。

しかし実際の社内には、新規性はなくとも仕事の進め方が変わる「右下」の領域に該当する層がボリュームゾーンになることも想定されます。

今までの事業・業務が変わらないとしても、仕事の進め方が大きく変化するケースも、昨今では増えているでしょう。

たとえば同仕事であっても、自ら課題設定して問題解決を行っていく企画型の思考が求められるようになった場合、過去のやり方に固執した思考では成果が上がりにくくなります。

前章で紹介したメーカーの生産現場の例で説明すると、求められる生産量は変わらないが、より少ない人員で現場を回す必要が生じていました。
そのために、業界固有の知識やテクニカルスキルだけで立ち行かないため、効率を上げるための企画力やプロセス改善のスキルが求められていたのです。

このステップでのポイントは、職種の定義そのものも柔軟に捉え直すことです。
場合によっては職種の分解・ポートフォリオ化も視野に入れる必要もあるでしょう。

たとえばその職種に企画を担う機能がないのであれば、当該職種内に役割を新設して人員を配置することが考えられます。
すでに企画機能が含まれている場合は、より等級・グレードが高いメンバーにその企画機能のウェイトを高めて担ってもらうことも検討に値します。

リスキリングをきっかけとし、現状にとらわれずに、本来的な職務設計まで行うことができれば、本来的な企業競争力向上への寄与も期待できるでしょう。

STEP3：スキルの網羅性をチェックする

次に、必要となるスキルの網羅性を確保するために、新しい技術そのもの、いわゆる「アプリ」と、その新しい技術を使いこなすための組織や人、いわゆる「OS」の双方のスキルを検討していきます。

リスキリングというと、ついAI、IoTなど新しい技術そのものの「アプリ」に目が行きがちですが、新しい技術を使いこなすための「OS」としてのスキルが十分であるかについても点検することが重要です。

たとえば、先ほど一例として挙げたメーカーの生産現場での既存業務の効率化では、本質的にはテクノロジーを用いた業務プロセス改善の必要があります。

その場合土台として必要なのは、「何を解決するべきか（What）」を定義する問題解決力となります。これが「OS」のスキルです。
反対に、「どのように解決するか（How）」は「アプリ」の話であり、検討の際は「アプリ」のリスキルのみに着目してしまわないよう注意しましょう。

なお「OS」のスキルは、流動的な仕事の場面において実践を通して身につけるソフトスキルの類であることが多いでしょう。
したがって全社一律に一度だけ取り組んだだけでは、業務に活かせるようにならない場合も多いため、実装を徹底していくことも重要です。

STEP4：運用を見据えたスキル管理システムを構築する

ここまでのステップでスキルの網羅性が確保できたら、最後のステップとして、スキルデータの運用を見据えた仕組みを構築していきます。

必要となるスキルを保有した人材の管理・育成をするためには、タレントマネジメントシステムなどのデータベースで管理を行うことが効果的です。

データベースの構築段階で、あらかじめスキルを社員の日常業務レベルまで定義・レベル分けしておくことで、検索性の高いデータベースが設計しやすくなります。
たとえば、各スキル項目に対しレベル1-5まで設定することで、スキルレベルや経歴など複数の条件で社員を検索しやすくなります。

なおスキルデータの運用は、紙やエクセルではなくHRTechに代表されるデジタルツールが昨今は推奨されます。

精緻にリスキリングの進捗をマネジメントしようとすると、タイムリーな更新や全社的な「見える化」が重要になります。
紙やエクセルであれば、スタート当初はよいかもしれませんが、じきに運用負荷の課題に直面し、データベースが形骸化しかねません。

社員個人のスキル評価をHRシステム上で運用することで、データを定期的に更新する仕組みを作りやすくなります。
またスキルデータを定期更新することで前期とのレベル差が分かるようになり、個人のスキル習得状況を育成に活用できるようになるでしょう。

３．スキルセットレベルで陥りがちな落とし穴

ここまでは企業競争力につながりやすいスキルの絞り方についてお伝えしました。

仮に紹介したステップをおろそかにして、開発すべきスキルを見誤ってしまった場合、どのような影響があるかを紹介します。

たとえばDX推進を行うために、社員にIT教育を施すことを例に挙げます。
DXは非常に幅広い概念のため、社内の何を優先的にDXを進めるかは各企業によって異なります。
社内の根幹システムの抜本的な入れ替えを行うITスキルと、勤怠管理のSaaSツールを社員が使いこなせるITスキルでは、全く次元が異なります。

開発するスキルを見誤ってしまうと、当然開発する学習プログラムも間違ってしまいます。
リスキリング後に一定のスキル開発成果があったとしても、それでは企業の競争力には期待していたほど寄与しないことになるでしょう。

社員の立場としても当初はモチベーションが上がっていたとしても、徐々に「なんで忙しい合間を縫ってスキル開発をしているのだろう」と疑念が生じてしまうリスクもあります。

社員にスキル開発のプログラムを提供したからといって慢心するのではなく、本質的に企業の成長に寄与するスキルを考える姿勢が求められます。

まとめ