2009年6月8日
5.3 知識エリア「要求分析」とスキル標準
スキル標準の【スキル分析と定義】プロセスです。
報システムユーザースキル標準 Ver.1.2より引用
UISSの例では、以下の3つのサブプロセスに分割されています。
-要求分析
-業務機能(Tobe)策定
-スキルセット策定
スキル標準の【人材像(キャリアモデル)の策定】プロセスです。
Tobeの人材像と人材ポートフォリオ(Tobe)を作成します。
Input: スキルセット(スキルリスト)
Output: 人材像/キャリアモデル(Tobe)
人材ポートフォリオ(Tobe)
スキル標準の【人材像(キャリアモデル)の策定】
Tobeの人材像と人材ポートフォリオ(Tobe)を作成します。
Input: スキルセット(スキルリスト)
Output: 人材像/キャリアモデル(Tobe)
人材ポートフォリオ(Tobe)
このOutputが【ビジネス戦略】のプロセスのInputになります。別の言い方をすると、人材戦略(人材像/キャリアモデル)の裏付けのないビジネス戦略は意味がないということになります。また、そのためには、教育体系が効果的に実施され、Tobe人材像が早期に実現できる必要もあります。
上記はBABOKの知識エリア「要求分析」のタスク「要求を構造化する」「要求を仕様化しモデル化する」に相当のではないでしょうか。ただし、使用するテクニックはかなり異なるようです。いわゆる、データモデリング(ER図)、ユースケースなどは使用しません。データフロー図は業務分析としても使えます。対象が異なりますからテクニックも代わります。しかし本質は変わらないと思います。
【キャリア提示】
人材像(キャリアモデル)が策定されたら、それをエンジニアに提示する必要があります。
それを元に、エンジニアは自分のキャリア計画を作成し開発します。
このプロセスは2つのサブプロセスからなります。
-組織はエンジニアに対し、キャリア獲得の機会を提示します
-エンジニア個人は自分の(個人別)キャリア計画を立て、その実現を追求します。
Input: キャリアモデル(Tobe)
人材ポートフォリオ(Tobe)
Output:個人別キャリア計画
このプロセスはBABOKのタスク「要求を伝達する」に近いものです。BABOKでの内容と少し異なります。
【GAP分析】
Input: スキルセット
人材ポートフォリオ(Tobe)
Output: GAP
教育計画への情報
このプロセスは知識エリア「エンタープライズ分析」のタスク「能力Gapを診断する」に相当します。知識エリアをまたがるプロセス(タスク)があることも発見です。
知識エリア「要求分析」のその他のタスクを見てみましょう。
タスク「要求に優先順位をつける」はSMMでは考慮していませんでしたが、BABOKをみて必要なことに気が付きました。人材育成にもビジネス戦略を反映した優先順位をつけるべきです。
タスク「仮定と制約を定義する」もSMMでは暗黙のプロセスだったかもしれません。プロセスとして見える化することが必要です。
タスク「要求を検証する」はSMMでは暗黙プロセスです。人材のスキル要求がビジネスと結びついていなくてはいけないのは言うまでもありません。いずれ明示する必要があると思います。
タスク「要求の妥当性を確認する」
このタスクはソリューションが構築されてから実施されますから、スキル標準ではまだ出てきません。もう少し後のフェーズで出てきます。少しお待ちください。
知識エリア「要求分析」とスキル標準を比較して分かったことは次の3点です。
-共通に使えるタスクが多い
-スキル標準でも必要だが、考慮されていないタスクがある:「要求に優先順位をつける」
-スキル標準では暗黙のプロセスとして扱われているタスクがる。
BABOKの方がしっかり定義されているようです。
5.4 「要求の管理と伝達」とスキル標準
知識エリア「要求の管理と伝達」の5つのタスク
-「ソリューションスコープと要求を管理する」(5.4.1)
-「要求トレーサビリティを管理する」(5.4.2)
-「再利用のため要求を維持する」(5.4.3)
-「要求パッケージを準備する」(5.4.4)
-「要求を伝達する」(5.4.5)
について、スキル標準と比較検討します。
5.4.1 タスク「ソリューションスコープと要求を管理する」
このタスクは上図のOutputとInputのデータ【スキルリスト】と【キャリアモデル(ビジネス戦略ベース)】を管理することに相当します。プロセスとしては明示されていませんが、全体のプロセスのPDCAを回すことにより、実施されます。
5.4.2 タスク「要求トレーサビリティを管理する」
スキル標準ではこのタスクはありません。将来必要になるかもしれませんが、現状では不明です。ソフトウェア要求のように、要求が頻繁に変更される場合に必要なものかもしれません。
5.4.3 タスク「再利用のため要求を維持する」
ソリューション間での再利用ですから、「スキル標準導入」では当面不要です。
しかしながら、例えばA事業部でスキル標準を導入した後に、別のB事業部(異なる事業なので要求スキルも異なる場合)で導入する場合などには、役に立つタスクだと思います。
また、独立コンサルタントにとってみては、X社にスキル標準導入をコンサルし、別のY社にコンサルするような場合には有効です。
5.4.4 タスク「要求パッケージを準備する」
現状のスキル標準では、社内チームで上流(人材スキルを定義しキャリアモデルを作成する)からそれに基づいて、教育体系を作成し、研修実施する下流工程まで途切れないプロセスになっています。
教育実施をアウトソースしたり、外部教育ベンダーに依存する場合では有効なタスクだと思います。
5.4.5 タスク「要求を伝達する」
2つの意味があります。
-キャリアモデルを社内エンジニアに提示する場合。
-作成した上記要求パッケージ(RFPやBRDのようなもの)をアウトソース先の教育ベンダーやプロジェクトチームに伝達する場合。
定義したキャリアモデルを社内エンジニアに提示すれば、エンジニア個人は自分のキャリアパスを考える上で極めて重要です。5.3で前述したのがこの部分です。
もう一つは、BABOKのタスクの内容です。RFPを外部ベンダーに伝達したり、BRDやシステム要求仕様書をプロジェクトチームに伝達する場合です。作業の役割分担が分離している場合には必要になります。スキル標準の場合、多くの組織では分業されていないケースではまだ時期尚早ではないでしょうか。
|