UISSやITSSなどスキル標準の企業導入を進める場合、推進者がぶつかってしまう課題や制約が必ず存在します。今回は実例を基に、どのような壁があるか、またそれをどのように解決していけばいいのかを探って行きます。
|
|
変わらぬ環境 |
景気の低迷が続き、ビジネス環境が改善しないこともあり、人材開発の予算が取りにくかったり、優先順位がかなり低くなっている現状は否めません。
あきらめて、限られた範囲で可能なことだけを黙々とこなす、という担当の方が多いのではないでしょうか。権限もなし、冒険をしてリスクを犯すこともためらわれるという具合です。それでも、経営層の方々は「人材が最重要」とメッセージアウトしており、空々しく感じるのは筆者だけでしょうか。
一方で、こういうときだからこそ、将来のためにできることを精一杯やるべき、という考えで熱く燃えて進めている方も確実に存在します。 |
|
M社の課題認識 |
ここでは金融系のM社としておきます。 M社での課題認識は、次の通りです。
・ベンダーへの依存度が増し、情報システム部門本体の技術力が一部空洞化の恐れ ・業務の属人化によるリスクの潜在化 ・中核人材の世代交代が進まず、技術・知恵の継承が困難 ・人材の機動的な再配置が困難 ・情報システム子会社との機能分担が不明確
合併を繰り返してきたこともあり、仕事や組織は縦割りになっており、変化に対応するには各エリアごとに人数を増やさざるを得ないということになっています。
推進責任者のE氏は、これを「タコツボ」と呼んでいて、コンサルに入った我々は、その表現の妙に感心したものでした。
E氏は、合併当時は縦割りであろうが何であろうが、仕事を停滞させないために、組織として横に並べるしかなかったが、将来を考えるとこのままでは立ち行かなくなるという考えでした。 |
|
取組みスタート |
誰がどんなことができるかというよりも、組織力を向上させることが第一の考えであったことから、ITSSのように職種や人材ではなく、組織機能を中心に定義しているUISSの選択に至ったことは必然と言えます。
UISSをベースとして取り組みの基本方針が次のように定められました。
「まずは、情報システム部門の果たすべき“ミッション”と“執行単位”を意識した 『ユニット』概念を導入し、ユニットごとに具備すべき『機能』、機能実行のために必要な個々の『スキル』の順で考える。 個々の要員が持つ『スキル』を“見える化”し、『機能』⇒『ユニット』における具備の度合いをマップ化する。 再配置、育成等の手段を用い、『スキル』を強化することで『ユニット』が機能する体制へ。」
UISSの構成や活用プロセスに合致した考えであったため作業はスムーズに進み、機能で表現した「タスクフレームワーク」に、各要員のスキルが映し出されるところまでは、大変順調でした。ところが・・・。 |
|
現場管理者からの反対 |
活用のための運用のステップに進めるために、各エリアの責任者に対して報告会を実施することになりました。
ここで、思ってもみない反対にあうことになります。
現場管理者である各マネジメントからの意見は、次の通りです。
・ミッションが一般的で当社の独自性が表現されていないのではないか 機能、ユニット、ミッションのさらなる明確化と「らしさ」が必要。
・ITスキルだけではなく、過去の実績評価やプロジェクトの大小を合わせて判断したい ITSSの達成度指標のようなシンプルな経験実績の組合せではなく、「らしさ」「コンプテンシー」なども含め。
・スキル診断そのものが目的でないはず。どう活用するかをはっきりしてほしい 推進者−現場管理者−情報システム部門責任者−要員の目的の共通認識の難しさ。
簡潔な文章では以上の通りですが、結果としてこのままでは継続を許さないという、大変厳しい評価になったということです。この現場責任者の反対を乗り越えられなければ、取り組み自体が頓挫してしまうことにもなりかねない局面になりました。
この後、推進者一同何度も深い議論をすることになるわけですが、そのことでさらに目的が共通認識され、より強固なワンチームになるという副産物を生み出すことになるのです。
〜つづく |
|
|
|
登録:2010-06-21 10:42:22
|