人材育成コラム

リレーコラム

2017/05/22 (第84回)

2万人のITSSレベル診断

ITスキル研究フォーラム 理事
株式会社日立インフォメーションアカデミー 取締役社長 学院長

石川 拓夫

 まずはご挨拶から。4月から日立インフォメーションアカデミーの取締役社長に就任した。日立系のITベンダーに入社し、一貫して人事を担当してきたが、キャリアの終盤にこのような機会を頂けた事に感謝したい。長年ITエンジニアの採用、育成、活性化、リテンション、セカンドキャリア支援などキャリア開発支援を担当してきたが、日立グループの人財育成サービス会社でもう少しやりたいことができるのは幸せである。

 ただ個人的には、「キャリア自律」を標榜し、「自分の人生自分が主役、自分のキャリアは自分で築け」といい続けてきたので、究極の理想は、キャリア開発は自律した個人が、会社が用意した学べる環境を活用して、主体的に自分で行うものだと考えている。会社は成果を発揮するステージであり、受動的な人に無理やり教育を付与するなどキャリア開発の背中を押すものではないと考えている。

 だが、人財育成サービスを提供する身として、ステークホルダーとのWin-Winの関係をめざし、より考えなくてはならないと思っている。研修を提供するだけの会社ではなく、経営課題からひもとく人財戦略に寄り添い、人に関する課題を解決するソリューションを提供できる会社になりたいと考えている。それが理想とする「キャリア自律」に一直線につながれば、これ以上のことはないと思う。

 さて、今回は3月まで日立の情報・通信部門のIT人財育成担当として仕上げたiCD(アイ・コンピテンシー・ディクショナリー)活用によるITSSレベル診断システムのリニューアルについて書きたいと思う。ITSSを長く導入し、ここにきてどうしようかと思っている企業や、iCDを活用しようと思っている企業のご担当者に少しでも参考になればと考えている。
 日立製作所の情報分野では、約10年前からITSSスキル診断を行い、人財育成などに役立ててきた。このシステムのリニューアルの必要性から全面的な見直しを行った。要点は以下の通りである。

(1)iCDを活用して定義を全面的に見直し、スキルではなくタスクの診断でITSSのレベルを診断する

(2)日立の情報・通信分野の共通基盤として、日立製作所だけでなくグループ会社にも提供する

(3)経営戦略を踏まえ、新たに必要な役割(一般的には職種)を定義し、追加する

(4)これを期に、経営・事業部門・個人のPDCAを再構築し、連動した効果的な人財育成をめざす

(5)診断結果は職種別レベルの結果だけでなく、個々のタスクの診断結果も分析し、課題の見える化(事業戦略とのギャップ)やその対策の提言に役立てる


 約1年かけて取り組み、2017年1月に稼働した。2016年度分はグループ会社も合わせて約2万人が対象だ。3月末で従来より早く90%台の受診実施率となり、好調なスタートを切った。(3月末締め切りの会社の実施率。グループ会社により実施時期が異なるところもあり)今後この結果を活用した取り組みが各所で行われることになる。一歩踏み込んだ取り組みに期待が膨らむ。

 同じように長年ITSSの診断を人財育成、ポジションマネジメント、評価、調達などに活用し、ここにきて見直しを考えている会社は少なからずあると思う。社外交流の中でも、時々相談を受ける。「ITSSはもう時代遅れだ」「今の環境変化に対応していない」などの理由で捨て置かれているのはもったいないと思う。せっかくiCDというITエンジニアのジョブカタログが発表になっている。これを活用して、有効なPDCAサイクルを再構築することがお勧めである。ただし、趣旨の異なるITSSとiCDを融合させて利活用するのはそう簡単ではない。

 日立の事例でいうと、まず事業戦略を鑑み、ITSSにない必要な役割(職種)を設定した。BA(ビジネスアナリスト)とサービスである。SIのプロセスを役割ごとに定義したITSSでは足らない領域である。この新規職種と従来のITSS職種を、iCDを活用して全面的に見直し、タスクによる設問を設定した。単にiCDで職種を定義(設問化)してもITSSの7レベルは算出できない。ここで職種ごとに旧診断システムと同等のレベル診断結果が出るように検証を繰り返しながら調整した。

 iCDを活用した新診断システムのメリット、デメリットを簡単にまとめると以下の通りである。
【メリット】
  • 職種定義を早く行うことができる
  • 業務と関連しているため、後で分析がしやすい
  • 業務の変化に対応しやすい。職種・専門分野とタスク対応を調整するだけですむ
  • タスクベースのため、OJTなどのアサインメントに活用できる

【デメリット】
  • 職種定義にあたって、現場との調整が必要である(ITSSのような標準ではない)
  • iCDが毎年更新されるため、職種定義の見直し検討の負担が比較的大きい
  • スキルベースで作成された現研修施策との関連付けを見直す必要がある
  • 「用語」の調整が必要な場合がある(社内規格に翻訳の必要あり)

 少し手間はかかるが、iCDを活用することにより、より柔軟に事業戦略に対応でき、メンテナンスもやりやすい。また受診者であるITエンジニアから見ると、タスクで設問化されているので納得感が高いという利点も大きい。どのくらい役割を果たせているかでレベルが診断されるのだからわかりやすいことだろう。

 ただ課題もある。ひとつは技術基点のレベル診断の限界である。役割においては複数のタスクの診断で可能だが、技術テーマごとのレベルの診断にはiCDは適応していない。セキュリティやOSS、IoTなど先端分野においてこのニーズは高まっているが、それを診断するには、もうひと軸が必要になる。これは鮮度との戦いになるので難易度は非常に高くなる。投資対効果からいって踏み出しにくいものである。

 ITエンジニアを共通定義で見える化し、これを基点にAsIsとToBeのギャップ分析を行い、計画的に人財育成を行うことは普遍的な定石だと思う。共通定義が役割基点か技術基点かなど、どのようなものかは様々だと思うが、PDCAをどんどん回して前進することが重要だと思う。レベル診断などアセスメントに正解はない。満点よりはスピード、仮説検証こそが大切だと思う。そして忘れてならないのは、社員とのエンゲージメントである。これを高めるものでないと意味がない。個人のキャリア自律を促進する納得感は絶対に必要だと思う。


この記事へのご意見・ご感想や、筆者へのメッセージをお寄せください(こちら ⇒ 送信フォーム