UISS、ITSS V2の導入手順については、今のところ国側からは提供されていません。UISSの概要の最後に考え方は記述してありますが、ITSS V2は概念レベルしかありません。UISSの発表資料には、経済産業省の今後の考え方が明示されていて、その中では活用ガイドラインを作成する旨が正式に書かれています。ITSS V2の方は、残念ながら活用ガイドラインについては明確な情報がありません。本格的導入事例があまりにも少ないために、参考になる情報が少ないのも確かです。今回から数回に分けて、弊社の導入実績をベースとした本格導入の手法や手順について、解説して行きます。9月初旬に翔泳社から出版されるITSS著書の前段と呼べる内容です。
|
|
|
UISSとITSS V2の違い |
 UISSとITSS V2の提供物は少し異なります。その差は、UISSは活用する側となるユーザ企業のIT部門の方々が策定し、ITSS V2は提供側のIPAが主体に策定しているというところから来ていると考えられます。しかし、考え方のベースは同じところにありますので、スキル定義や評価指標などの差はありません。ただし、UISSはユーザ企業が対象ですから、その企業のビジネスモデルや業界が色濃く反映され、キャリアフレームワークについては、ITSSのような共通化はあまり意味が無いといえます。企業間比較もあまり必要とされません。また、ITサービス企業よりも、よりビジネスに踏み込む分、対象範囲が広いことも特徴です。
また先に述べたようにUISSは活用する側であるユーザ企業の方々が、自社活用を前提に議論されているので、自らがいかに使えるものにするかを最重要視されています。ITSSのように職種ごとにプロフェッショナルコミュニティを作って縦割りで議論していくことも、UISSでは非常に考えにくいものです。あくまで自社のモデルを全体観を持って考えていくというスタンスでしょう。
一方、ITSSはITサービス企業の立場からすると、企業間比較による自社の位置づけや、職種ごとのプロフェッショナリティがビジネス上も大変重要で、企業価値を決める大きな要素になります。ITサービス企業が、まずスキル診断をして現状を把握したくなるのも容易に理解できます。ユーザ企業がITサービス企業とは異なり、トップダウンによる本格的な導入を目指すのも当然のことでしょう。 |
|
|
経営マネジメントと人材マネジメント |
 この図は、企業として人材を中心に考えて、経営マネジメントと人材マネジメントの2つの視点で捉えた図です。企業としては、ビジネス目標に貢献する人材を育成するわけですから、目標達成の時点で必要になる人材について仮説を立てることになります。したがって育成プランは、その仮説を実証していくための重要な計画となります。単純に育成担当者の考えだけで研修メニューを揃えることが、育成プランの策定ではないことを認識する必要があります。
また、個人からすれば自分の将来を自分で考える環境が提供されるのは、素晴らしいことで、会社からの要請に対して色々な意見や提案を持つことができ、チャンスに変えることが可能になります。モチベーションを高く持ってパフォーマンスを発揮するかしないかは、企業にとっても個人にとっても将来に関わる大きな要素です。 |
|
|
導入プロセス |
 今回は、まず導入手順の大きなプロセスを説明します。
「要求モデリング」、「ファンクションモデリング」は、システム構築の上流で言う「要求分析」と「機能分析」に相当します。
①システム構築での「要求分析」は、ユーザーのニーズをまとめ上げ要件定義をしますが、ITSS導入の場合は経営戦略、たとえば3ヵ年プランを元に3年後に必要な人材(目標人材)に対する要求をまとめることになります。
②「機能分析」については、システム構築の場合そのシステムに必要な機能を整理してまとめます。その機能をもとにDFDなどを書いて行き、ブレークダウンして行くとプログラムやモジュールに落ちていきます。UISS、ITSS導入の場合は、3カ年経営計画を元にしたなら、3年後に目標を実現するために企業として必要な機能を定義して行くことになります。UISSは、この機能定義が網羅的に提供されており、自社ビジネス観点から選択することができます。
ここまでは一切スキルについては出て来ず、またシステム構築はエンジニアの得意分野であり、この方法であるとエンジニアがレビューに入っていくことが十分可能となります。「ITスキル」は現場のものであり、人事や人材開発、ましてや外部のコンサルが作ったものを使うのではなくて、現場自らが作成に参加していくことに価値があります。レビューの中で手法や内容を詳しく説明しなくても、「3年後にそのビジネスを目指すなら、機能をもっとブレークダウンして詳細化しておいたほうが良い」など、積極的な意見が普通に出て来ます。③3年後の機能モデル(To-Beファンクションモデル)が固まれば、次にその機能を実行して行くにはどういうスキルが必要か、という観点でスキルセットを構築して行きます。この時点でUISS、ITSSの定義を使えば非常に効率的です。UISS、ITSSの定義の中で自社に必要の無いものも明確になります。逆に不足していて追加しなければならないものも明確になります。
ここでもUISSの場合は、提供機能にサブセットとして必要スキルが付いてくるので、議論のベースになるものは、手をかけずに用意することができます。
このように経営戦略を基にした必要機能からスキルを確定して行くと、誰に対しても説明が可能となります。また、ビジネスモデルの変更などで機能が変化したから、このスキルが不要になり、新たにこのスキルを追加する、ということも論理的に説明できることになります。メンテナンスも機能を元に実施して行く仕組みを作ると、引き継いで行くことも容易になります。この流れを踏まずにいきなりスキルを求めても、その内容は作った方の属人的なものになり、説明するにも根拠が不明確で周囲の賛同を得られず、継続していく上でも問題があります。失敗事例の多くはこの部分に起因しています。
さらに、企業の視点でビジネスモデルに合った職種や、必要があれば専門分野、及び人事制度とのリンクなど将来を見据えたレベルを定義し、確定したスキルセットを職種ごとにレベル観を付けて振り分けて行きます。これで、「目標人材モデル」を策定できたことになります。
④⑤⑥この中でスキル棚卸を実施し現状把握をすると、目標とのギャップが明確になります。その内容を元に育成プランを策定すれば、経営戦略に沿った形での人材育成ができ、優先順位も明らかになります。また、実施効果の測定も可能になり、人材戦略の改善にも役立つことになります。
次回以降で、それぞれのステップの詳細について説明していきます。 |
|
|
|
▲▽ 関連サイト ▲▽
|
・ 9月20日出版「ITSS V2の分かる本」
|
登録:2011-01-30 15:48:25
|
