スキルスタンダード研究所は、各業界へのスキル標準の活用・推進、プロフェッショナル人材育成に向けたコンサルティングサービスを提供します。
ITスキルスタンダード研究所
スキルスタンダード研究所についてニュースサービスドキュメントコラムお問い合わせ
コラム
第167話:人材開発推進者の悩み 〜スキル標準企業導入の様々な課題・制約に、どう立ち向かうかA
 163話の@から少し時間が経ってしまいましたが、人材開発責任者がスキル標準の企業導入を進める上で直面する課題や制約、またその解決策を実例を基に探っていきます。
必要性からボトムアップで上層部を説き伏せたM社
 163話では、順調に進んでいるかに見えたM社のUISSの導入が、管理者層による思わぬ反対にあい、頓挫するかもしれない局面に陥ったところまでお話ししました。

 一般的には、情報システム部門の方は、運用しているシステムの規模や数に対して、おおむね人数が少なく、ひとりいくつものシステムに責任を持っている場合が多いと言えます。つまり、担当している方しか、そのシステムのことは分からず、完全に属人化していることになります。
 また、菅理者層の方々は、システムを構築・運用する上で、様々な経験を経て現在のポジションに就いています。したがって、現状での課題、問題、将来発生する事象の推測は、過去の経験に照らし合わせて考えていくことになるでしょう。
 
 そのような環境の中で、UISSのように組織力を上げるために、能力を可視化し論理的に計画を積み上げていくという考えに直面した時に、関係者はどのような反応を示すのでしょうか。

 まず容易に想像できるのは、システム担当者からすると、自分しかできないという牙城をどのような形であれ、脅かすようなことはされたくない、という防御の態勢に入ってしまうということでしょう。
 また、管理者層からすれば、うまくいっている(それなりに廻っている)現状なのに、部下に不必要な作業を課したくないということや、能力の可視化が部署をコントロールする要素だとすれば自分の中でクローズさせたい、という気持ちが働くかもしれません。

 しかしながら、管理者層はもちろん、主力として一翼を担っている方々は、自社の環境を客観的に見ることが、できないはずはありません。どうすれば、さらによくなるかのイメージを持たない方はいないのです。

 自己中心的な考えを打ち破り、いかに心に響く内容にするかがポイントであり、M社の推進責任者・E氏は、見事にそれをやりとげました。
こんな地道な?!
 その方法とはこうです。

 徹底して「腹に落ちるミッション定義、スキル定義にする」を具現化するということです。

 まず、一般的な「ミッション」の定義ではなく組織機能をまとめた形で、「ユニット」という新たな概念を定義しました。いわば機能の塊です。
 次のような12種類と定めています。

・マネジメントユニット
 ラインマネジメント、ヒューマンリソースマネジメント等
・システム投資戦略ユニット
 中期的および半期ごとの全社ベースでのシステム投資戦略立案・事後評価
・ユーザーコンサルティングユニット
 ビジネスの視点で部門ごとのシステム投資戦略を策定し、システム活用を推進
・システム化企画ユニット
 各部門のシステム投資戦略に則り、全体のシステム化計画を策定
・アーキテクチャーユニット
 社内標準策定時の品質統制、システム基盤戦略の策定、適切な調達の管理
・プロジェクトマネジメントユニット
 個別の開発案件におけるプロジェクト管理とプロジェクト実行推進
・設計ユニット
 個別の開発案件におけるアプリケーション設計とシステム基盤設計
・製造ユニット
 個別の開発案件におけるアプリケーション開発・基盤構築・ネットワーク設定・移行
・運用管理ユニット
 既存システムに関する保守・運用、および、ヘルプデスク等のサポート運用
・内部統制ユニット
 セキュリティ対応・システムリスク評価・IT全般統制(SOX)・手続管理
・リソース管理ユニット
 契約に関する管理、投資予算・経費予算に関する執行と予実績の管理
・品質管理ユニット
 障害管理・ディザスタリカバリー・BCP・開発管理

 これは、関係者の皆さんに大変好評で、すんなり受け入れられることになりました。
責任者のE氏いわく、どういう表現をすれば受け入れられるかを、根気よく探すことが重要、とのことでした。
スキル定義の見直し
 もう一方のスキル定義に関しては、1つのユニットに関して徹底的に議論し、スキル定義を見直すという方策をとりました。

 合宿形式で、2日かかってA4・1枚程度しかまとめることができませんでしたが、このことで参加メンバに明確な共通認識が醸成され、残りのユニットを参加者各人に振り分けても、個別に見直しを実施できる土壌ができました。

 UISSにしてもITSSにしても、どのような企業でも活用できるよう、あえて共通化したスキル定義などコンテンツの提供が中心となっています。
 言いかえると、抽象的で手を加えないと企業で活用するのは難しいということになります。

 具体的には、次のような考え方で見直すことになります。

・提供されている定義は、機能をブレークダウンして作業(Activity)にし、スキル表現している
 ○○○計画立案 → 市場調査できる
                調査データをまとめることができる
                  ・
                  ・
                 ○○○計画書としてまとめることができる
・一般的な言葉、社内では使われていない言葉で分かりにくい
・作業まで落としたものをスキル表現しているので、ひとつでも抜くと成り立たない
 よって安易に数を減らすことはできない
・社内用語や書類などで、代替できないか
 たとえば、社内で使用している書式の中に、「○○○計画申請書」があるとすれば、
 「○○○計画申請書を作成することができ、上司、および関係部署の承認を得ることができる」
 という一つの定義に置き換え可能

 つまり10個程度あるスキル定義が、社内用語や実物名を使うことで、説明する必要がなくなり、作成するや説明する、また承認を得るなどの表現で十分となり、大幅に数を減らすことができるということです。

 これをすべての定義に対して、みんなで議論するのは大変ですが、一つの塊を議論することにより、ルールや考え方を徹底することは可能なのです。

 結果から言うと、スキル定義のひとつをとってみても、理解できるものを提供するだけで、現場は思ったよりはるかに受け入れてくれるということです。

 また、この合宿での作業が、組織力を向上させる施策に対する全員の思いを一つにさせた大きな機会になったということは、言うまでもありません。
登録:2010-09-07 15:25:31
 サイトの利用について | プライバシーポリシー | 情報資産管理方針 |
トップページへ戻る