2009年2月2日

４．「共通キャリア・スキルフレームワーク」の課題と改善策

全体として、方向性は正しいと思います。現状の4つのスキル標準（ITSS、UISS、ETSSさらに情報処理技術者試験）の存在は多すぎて複雑です。スキル標準の普及を妨げている要因になっていることは確かだと思います。メリットよりデメリットの方が大きく、その意味でも整理する必要性は高いと思います。特に情報処理技術者試験、ITSS、UISSの3つは、その関係が明確にできると思います。

しかしながら、現状はまだ「第一版」なので、対策が十分にとられているとは言い難いのも事実です。そこで「第一版」における課題を整理し、第二版、第三版につながる改善策を提示しようと思います。以下に、

　　−キャリアに関して

　　−知識とスキルに関して

　　−各スキル標準との関係

の3分野に関して、課題と改善策をまとめてみます。

４．１　キャリアに関して

まず、「共通キャリア・スキルフレームワーク」のキャリアに関する共通フレームワークの部分に関して考えてみます。さらに2つに分類します。

−キャリアレベルに関して

−職種との対応

４．１．１　キャリアレベルに関して

キャリアレベルの定義は4つの標準すべてにうまくまとまっています。

「共通キャリア・スキルフレームワーク第一版」より引用

しかし、上記レベル1〜3の定義が試験で本当に測れるのでしょうか？　特にレベル3は応用情報技術者試験（AP）に合格すれば3標準ともレベル3に認定されます。これは本当に正しいのでしょうか。常に疑問が残ります。

グローバルスタンダードのスキルとして、PMBOKはあまりに有名ですが、試験に合格するだけでなく、一定時間の経験を求めています。また、最近注目を集めているBABOK（ビジネスアナリシス知識体系）では、一定の経験が先に審査され、認定されて初めて受験の資格が与えられるという厳しい形式になっています。レベル3の「すべて独力で遂行できる」ことを保証するためには、試験のみならずそれなりの実務経験を加味するべきではないでしょうか。そうすれば、「すべて独力で遂行できる」ことを保証できるのみならず、試験の負担も軽減できると思います。

４．１．２　「共通キャリアスキルフレームワーク」と3スキル標準の職種との関係

「第一版」ではかなり無理やりにまとめた、という印象が強いと思います。

「共通キャリア・スキルフレームワーク」側のみならず、各スキル標準の職種にも課題があると思います。以下に、

−ストラテジスト

−プロジェクトマネージャ

−テクニカルスペシャリスト

−サービスマネージャ

に関して、課題と改善策を考えます。

４．１．２．１　ストラテジスト

かなり強引にまとめた感じがします。大きな疑問は営業（セールス）です。営業はここで言うストラテジストでしょうか。ビジネス戦略を考えるという意味でのストラテジストと、具体的顧客（アカウント）や案件を戦略的にアプローチするという意味のストラテジストではその内容がかなり異なります。BOKにリストされている要件（知識項目例）は概ね前者のビジネス戦略に関するものと、プロダクトマネジメントに関するもののようです。営業戦略としてはアカウントマネジメント、ファネルマネジメント、案件別競合戦略などが不可欠です。

では、それらの知識項目を追加すればよいのでしょうか。そう簡単ではありません。特に営業の場合、まずこのような知識があるのと、それができる（スキルがある）こととの乖離があります。さらに受注を達成するためには、個人のスキルがいくら高くても会社の組織力がなければ成功しません。　ですから営業パーソン個人の知識（知っていること）と営業実績との相関は意外と低いのです。よくスポーツに例えられます。システムビジネス（ソリューションビジネス）の営業はラグビーやサッカーのようなチームプレイです。相手もチームです。チームとチームとの戦いの中で、ベストなタイミングでベストなプレーができて初めてポイントになります。一瞬のエラーは致命傷になりえます。ドリブル、パス、シュートなどの個人の能力だけでなく、チームメイトとの連携や相手の動きまで関係します。すべてうまくいってはじめて得点に結びつくのです。そこには相手（顧客と競合）によって、戦略を変える必要もあります。常に勝てるわけでもありません。自社（パートナーを含む）のリソースが不足している場合など、譲らざるを得ない場合すらあります。ですから負け方にも戦略（戦術）があります。

ではどうするのが良いのでしょうか。アプローチは2つあります。ひとつはストラテジストとして知識項目を追加すること。もう一つはセールスという分類そのものを追加することです。いずれにしても、知識（知っていることと）と受注実績との相関は低いことを考慮しなくてはいけません。４．１．１キャリアレベルで述べたように、経験（実績）を加味することが重要です。営業こそ、ペーパー知識は何も役に立たない職種です。

４．１．２．２　プロジェクトマネージャ

ITSSとUISSは問題ありません。基本的に同じ職種と言えます。ETSSの「開発プロセス改善スペシャリスト」が課題です。当該製品の開発プロセスの個別の知識が極めて重要です。この知識の前提なくして、プロジェクトマネジメント能力だけで判断は不可能だと思います。建築のプロジェクトマネージャがITシステムのプロジェクトマネジメントで成功するでしょうか？やはりITシステムの高度な知識を必要とするでしょう。それと同じことではないでしょうか。

ではどうするべきでしょうか。これもレベル３においても実務経験（実績）を加味することが解決策ではないでしょうか。当該製品固有の知識は実務経験が証明してくれます。そうすれば、プロジェクトマネジメントの共通スキルだけを試験すれば、レベル判定が可能です。また、試験の負荷も軽減できると思います。

４．１．２．３　テクニカルスペシャリスト

いくつかの課題があります。

ITSSの「ソフトウェアデベロップメント」：

情報処理技術者試験の高度試験（レベル４）が対応していません。「第二版」以降を楽しみにしましょう。

ETSSの「ドメインスペシャリスト」「開発環境エンジニア」：　

これらは当該製品の固有技術（第３階層以降）への依存が大きい職種です。現行のBOKおよび情報処理技術者試験では正確な測定はできないと思います。「第二版」以降での改訂が必要だと思います。

ETSSの「QAスペシャリスト」

これも現行のBOKに明確な定義がありません。大分類「開発技術」の下の中分類として「品質保証」を付け加えるのが良いと思います。プロジェクトマネジメントの「品質マネジメント」との違いを明確にする必要もあります。品質改善活動はプロジェクト内ではなく、母体組織の責任です。

UISSの「ISオペレーション」「ISアドミニストレータ」「セキュリティアドミニストレータ」など

似た職種が多すぎます。共通キャリア・スキルフレームワークの問題と言うより、UISS側の問題ではないでしょうか。もう少し整理するべきだと思います。UISSからしてみると、タスクを定義しているだけなので、細かなキャリアモデルは企業の実態に合わせていくらでもカスタマイズすればよいと、あまり気にしていないのでしょう。

４．１．２．４　サービスマネージャ

カスタマーサービスとITサービスマネジメントは分離するのが現実的です。カスタマーサービスは一義的にはメーカーの仕事です。現状のBOKには該当知識がありません。情報処理技術者試験の対象にもありません。言いかえると、情報処理技術者試験が共通キャリア・スキルフレームワークにまだ準拠していない部分です。「第二版」以降を期待しましょう。

ITサービスマネジメントの部分はBOKおよび情報処理技術者試験にきちんと対応していますので問題ありません。