IT人材育成とCIOの役割

先回は「要求モデル」のお話をしました。この「要求モデル」は、成果物そのものにも意味がありますが、作成するプロセスで様々な議論を交わすことも同じくらい意味があります。メンバー間で共通認識ができ、方向性を整えることができるのです。過去の経験で、ものづくりを優先し、システム構築の上流、特に要求分析をおろそかにしたことによって、ひどい目にあった方々は、この必要性について嫌というほど理解しているはずでしょう。

　同様にUISS導入手順の最初である「要求モデリング」ステップは、導入の成否に関わる大変重要な位置づけであることは間違いありません。

　今回はその次のステップである「ファンクションモデリング」に進んでいきましょう。
 

UISS提供のテンプレートを活用したファンクションモデリング（1）

機能検証の必要性
　システム構築を例に取ると、そのシステムに必要な機能をモデル化してまとめます。その機能モデルをもとにDFD（Data Flow Diagram）などを作成していき、さらに機能モデルをブレーククダウンして行くとプログラムやモジュールに落ちていくことになります。

　同様の考えで、UISS導入の場合は3カ年経営計画を基にしたなら、3年後に目標を実現するためにIT部門として必要なTo Be機能を定義していくことになります。

　これは組織も属人性も削ぎ落とされており、シンプルにビジネスを支援するためのあるべき姿の機能表現となります。企業にとっての「To Be機能モデル」を作り上げるということです。先のステップで人材に関する要求モデリングを実施しているので、その内容を前提とした「To Be機能モデル」を策定することになります。

　各企業で持っている標準開発手順や業務フローなどが参考にでき、IPA（情報処理推進機構）から出ているシステムライフサイクル上のプロセスを定義したSLCP2007、プロジェクトマネジメントのプロセスを定義したPMBOK、システム運用プロセスを定義したITILなども効果的に活用できます。

　UISSは、あるべき姿から入るというトップダウンの考え方を基本としており、IT部門に必要な機能が網羅的に提供されているので、自社ビジネス観点から必要な機能を選択するだけで、ベースはでき上がることになります。ただし、To Be機能の中に現状の機能がもれていると本末転倒になってしまいます。あるべき姿も重要ですが、UISS提供の機能をテンプレートとして使って、現行タスクを検証しながらTo Be機能を求めていくのが現実的です。

　また、「現状を知る」というのは大事なことですが、短絡的にスキル診断をしても意味はありません。そうではなくて、せっかくUISSから機能のフルセットが提供されているわけですから、これを使って現状組織の機能的過不足を見極めることが先決です。

　機能検証をしてみると、本来持つべき機能が無かったり、実際に必要の無い機能が存在していたりと、現状をかなり可視化することができます。UISS提供の機能にはスキルがサブセットとして設定されているので、その機能を実際に実行していくためのスキルセットを明らかにしていくことが可能になるわけです。

UISS提供の機能テンプレートを使用した現状機能検証までの流れ

〜その6（2）に続く

　次回は、UISSテンプレートを使用した機能検証について、さらに詳しく説明していきます。