IT人材育成とCIOの役割

機能検証からの気付き 

　先回、具体例を示したように、UISS提供の機能群はIT組織として必要な機能が網羅的に用意されているので、自社の実施状況と比較検証することによって、以下の点が明らかになってきます。

• ●自社で十分カバーできている機能
• ●実施しているが、満足度の低い機能
• ●実施しているが必要以上に手厚くしている機能
• ●自社で実施していなくて、実は重要な機能
• ●すぐに手当てするべき機能、まだ先でいい機能
• ●現在、情報子会社やITベンダーに丸投げしているが、実は自社で持つべきコア機能
• ●現在、自社で実施しているが、本来情報子会社やITベンダに任せるほうが良さそうな機能

スキルセット構築

　To Beファンクションモデルが固まれば、次にその機能を実行して行くにはどういうスキルが必要か、という観点でスキルセットを構築して行くことになります。ここで初めてスキルについての議論が始まることになります。

　「どんなスキルが必要か」という議論からスタートする方が簡単ですが、「何の目的か」はトップダウンの考え方を取り入れないと見えてこないことになります。

　この時点でUISS、ITSSのスキル定義を使えば、作業が大変効率的になります。また、その過程でUISS、ITSSのスキル定義の中で自社に必要の無いものが明確になり、逆に不足していて追加しなければならないスキルも明らかになります。

　UISSから提供されている機能には、サブセットとしてスキルが定義されているので、議論のベースになるものは、それほど手をかけずに用意することができるわけです。

　このように経営戦略を基にした必要機能からスキルを確定して行くと、誰に対しても説明が可能になります。

　また、ビジネスモデルの変更などで機能構成が変化したから、このスキルが不要になり、新たにこのスキルを追加する、ということも論理的に説明できることになります。

　このようにメンテナンスも機能を元に実施して行く仕組みを作ると、運用を引き継いで行くことも容易になるのです。

　これらの要求分析〜機能策定の流れを踏まずにいきなりスキルを求めても、その内容は作った方の属人的なものとなり、説明するにも根拠が不明確で周囲の賛同を得られず、継続していく上でも問題があることになります。

　失敗事例の多くはこの部分に起因していると言えるでしょう。