経済産業省やIPAが、「ITスキル標準」リリース当時から言い続けている「経営戦略から入らなければ有効活用できない」という話しを、理解できている経営者の方や担当の方が、あまりにも少ない現状があります。だからどう活用すればいいかが分からない、ということになり、普及を妨げる原因にもなっています。
|
|
|
経営戦略と人材戦略 |
「戦略」、「ストラテジ」という言葉は、いかにも抽象的に感じたり、身近に感じることが難しいイメージがあります。しかし、「What」を定義し「How」を考えること、と言い変えると具体的に受け取り易くなるのではないでしょうか。
例えば3年後にどういうビジネスモデルを目指すか、また今から3年間でそのために何をしていけばいいか、ということを具体的に考えることになるわけです。その3年後の姿を、売り上げやマージンなどの数字で表すことが重要ですし、それを実現するために、どのようなスキルを持った技術者がどのような割合で必要かということを定義し、現在の状況を把握した上で、その目標の姿とのギャップより、育成プラン・採用プランなどを検討する、これが人材戦略になります。 |
|
|
IT戦略の具体化 |
では、3年後のビジネス目標のために、どのようなスキルを持った技術者をどれ位の割合で揃えなければいけないかということを、どうやって明らかにしていくのでしょうか。
これは、余り選択肢がありません。まず3年後の姿を機能で表すことが前提になります。これは、組織や属人性が反映されたものではありません。あくまで、3年後のあるべき姿を機能で表すのです。システム構築のシステム分析フェーズで、ファンクション・モデリングを行いますが、それと同様です。また、AsIsではなくて、ToBeのモデルとして表現します。EA(Enterprise Architecture)の業務分析での内容と同じですが、システム構築ではないので、DFD(Data Flow Diagram)は用いません。あくまでファンクション・モデルのみです。
システム構築の手順で言いますと、何をしたいかという要求モデリングを行なって、現状（AsIs)の機能を明らかにし、その両方をぶつけて新しいあるべき姿（ToBe)のファンクション・モデルを策定することになりますが、経営戦略を元に要求モデルを明らかにしておけば、現状のファンクション・モデルを作らなくても、あるべき姿は構築できます。
このToBeファンクション・モデルができれば、あとはその機能を遂行するために、どのようなスキルが必要になるかを、求めていくことになります。 |
|
|
ファンクション/スキルの変換 |
|
ToBeファンクション・モデルから必要スキルを出していくわけですが、機能から一つひとつスキルを求めていくのは至難の技です。ここで「ITスキル標準」を活用すると、かなりのスピードでスムーズにスキルセットを作り出していくことが可能です。コラムで何度も書いていますように、11職種・38専門分野のあのフレームワークは、企業間や、個人のバリュー把握・キャリアデザイン構築などに利用するには有効ですが、企業のビジネスに貢献する人材を育成するためには、ほぼ使えません。ビジネスモデルが各社異なるから、という明確な理由があります。ほぼと言ったのは、無理に合わせるということをするなら話は別だという意味です。各企業の独自の視点で見ないと、何処に投資すれば効果的か、ビジネス目標達成にヒットするかは、分からないのです。フレームワークではなく、その中に定義されているスキル定義項目をうまく利用するのです。その項目群はスキル領域という分類の仕方で、うまく統制されています。これを使って、あるべき姿のファンクション・モデルから、それを遂行するために必要なスキルを抽出し、必要なスキルセットを固めていくことになります。 |
|
|
目標人材モデルの策定 |
「ITスキル標準」のフレームワークは、とてもうまく考えられています。その中で、キャリアパスを考えたり、また示したりすることが可能です。皆さん、上司と若手との会話を思い浮かべて下さい。「君は、現在プログラミングは十分にこなせるようになったので、来期はプログラム設計ができるようになるよう、頑張ってくれ」といった類の会話がよくあります。これは、システム構築のフェーズを下から上がって行っているに過ぎません。コーディングの次はプログラム設計、ではその次はシステム設計ですか？これでは、キャリアパスとは程遠い内容です。では、主任、係長、次長、部長と人事制度上の上がり方は、というとこれも技術者のキャリアパスではありません。「ITスキル標準」のフレームワークでは、ITスペシャリストのレベル3の上は4、そのまま専門職としてレベルを上がっていくのもよし、ITアーキテクトの方へ移って上がっていくのもよし、ゴールをしっかり定めてそのためにこれから何をすべきかが明確になります。これをキャリアパスと言うなら納得できる方は多いと思います。この考え方を使わない手はありません。
しかし、自社ビジネスモデルを標準に合わせても仕方が無いので、独自のフレームワークを作ることになります。これは「カスタマイズ」とは呼びません。あくまで自社独自のフレームワークなのです。これこそが、3年後にどのようになっているかを表現できるフレームワークです。同じPMでも、企業によって守備範囲、責任範囲が異なります。それを無理に標準に合わせることはありません。そんなことをすると、逆に競争力を削がれることにもなりかねません。どの会社も同じになってしまう世界を作るために、「ITスキル標準」ができたわけではありません。
独自フレームワークに「ITスキル標準」フレームワークと同じようにレベルを持たせることで、目標と現在が明確に認識でき、そのギャップから効果的な育成プランを策定することができるのです。 |
|
|
「ITスキル標準」フレームワークと独自フレームワーク |
「ITスキル標準」フレームワークは、カスタマイズしてはいけない、だから独自フレームワークを作るのはルール違反だ、と言われる頭の固い人がいます。では、何のために「ITスキル標準」を活用するのでしょうか。また、他社と比較して自社の価値を知ることが重要だと言われる方もいます。もちろん重要ですが、それは手段です。目的は「ITスキル標準」を活用して、ビジネス目標達成に貢献するプロを育成するためなのです。使うことや比較することが目的ではありません。
また、独自フレームワークはカスタマイズしているわけではなく、新たに作り出すものです。「ITスキル標準」フレームワークは、そのままの形で利用します。両方とも技術者のスキルデータを映して見るだけのビュー的位置付けです。各々用途が異なります。何度も繰り返し書いていますが、以下の通りです。
・「ITスキル標準」フレームワークは、企業間、及びエンジニア個人のために使用する。
・独自フレームワークは、企業内での人材育成に利用する。
どちらかだけあっても機能しません。
自社ビジネスモデル上での目標人材モデルである独自フレームワークで見ないと、現状把握してあるべき姿とのギャップを出すことはできません。「ITスキル標準」フレームワークでは、どこに投資すればビジネス目標達成のために効果があるかは分かりません。当然です、ビジネスモデルが反映されていない標準だからです。
一方、技術者個人がITエリアの中で、自分のバリューを確認したり、キャリアデザインするためには、標準の中で見なければ意味がありません。また、企業間での調達などで場面では、同じ尺度で見ないといけないので、「ITスキル標準」フレームワークの活用が効果的です。
このように、目的によって見方を変える必要があります。しかしながら、これらは見るだけのビュー的位置付けであり、実際の技術者のスキルデータは、スキル領域で分類されたデータベースとして管理されているべきです。それらを目的によって、標準も含めた何種類かのビューで見るということです。
したがって何も考えずに取りあえず診断ツールを使うことは、次のステップが無く大事な育成費用を無駄にしてしまう可能性が高く、人事制度にそのまま取り入れることは、結果的にビジネスモデルや人材戦略を反映しないことになって、ビジネス目標達成とはかけ離れた内容になり、さらに技術者のモチベーションをも下げてしまう最悪の事態を招く、ということになる危険性が高いということです。
|
|
|
|
|
登録:2011-01-30 15:38:23
|
