今回も引き続き企業インタビューのレポートを載せるつもりでしたが、表題の「スキル熟達度」と「達成度指標」について、色々な方から分かりにくいと相談を受けましたので、再度取り上げ分かり易く解説します。
|
|
|
「スキル熟達度」と「達成度指標」 |
「スキル熟達度」と「達成度指標」は、「ITスキル標準」独自の優れた考え方です。「スキル熟達度」は、スキル領域という分類体系でスキル定義項目群としてきちんと整理されています。一つひとつのスキル定義項目は「〜ができる」という形で表現します。一方「達成度指標」は、過去の実績や経験を表すもので、以下の視点があります。
・ビジネス貢献
−責任性
携わったプロジェクトでの役割(PM、リーダー、メンバ、など)
−複雑性
どのような内容だったのか(ミッションクリチカル、VLDB、最新技術、など)
−サイズ
プロジェクトのサイズ(金額、期間、人数、など)
・プロフェッショナル貢献
社会貢献度(著書、委員会への参加、など) |
|
|
分かりやすく理解するためには |
昔から各企業がスキル管理システムなるものにチャレンジしてきました。多くはプロジェクトに適材をアサインするために、各エンジニアの持つスキルを事細かに管理するところからスタートしました。しかし、技術の進歩が早すぎるために更新が追いつかず、スキル定義内容がすぐに陳腐化して使えなくなってしまうというのが実情です。また、各エンジニアの経歴は、別途経歴書や人事システムの中で管理されてきました。 大まかに言うと、今までのスキル管理をしてきた内容が「スキル熟達度」に当たり、経歴書が「達成度」に当たります。
別の言い方をすると、「スキル熟達度」は仕事に必要なスキルを定義してあり、「達成度」は仕事の結果、たとえばプロジェクト終了後の成果への貢献度を表すことになり、「達成度指標」はその評価のための指標であるということになります。 |
|
|
それぞれの構成の理解 |
「スキル熟達度」の知識やスキルは、スキル領域のカテゴリで整理・分類されて定義されています。この内容は、ツールやテストでエンジニアのスキル習熟度として評価することが可能です。
「達成度指標」は、スキル領域で定義されているスキルを発揮して、如何にビジネスに貢献できたかを評価するためのものです。業務経歴書などに書かれる内容をどうすれば評価できるかですが、これはツールやテストで評価するのはかなり難しい内容です。貢献度を文章にして一つひとつ確認していってもあまり意味がありません。｢達成度指標」の中の定義項目を、一部「スキル領域」でも使用していますが、これは「ITスキル標準」がまだ成熟していないからだと見るのが妥当でしょう。どのようなプロジェクトだったのか、その中でどういう役割を果たしたのか、納期は？コストは？と、そのプロジェクトの範囲の中で、どのような結果で何ができたかを総合的に判断する必要があるのです。それをツールの中で、一文一文切り取った文章で聞いていっても判断はできません。プロジェクト報告書のようなものを見ながらアセスメントの熟達者が、本人に一つひとつ確認していかないと、実際のところは分からず正しい評価はできません。その報告者や、申請書、経歴書などの雛形が、IPAから「評価ガイドライン」として出ています。この辺りの見解はかなりはっきりしたものになっています。ツールでは難しいだけでなく、情報処理試験やベンダー資格でも同じで、それらは「スキル熟達度」の評価がメインであり、如何にビジネスに貢献したかを評価するのは非常に困難です。試験では、論文等がそれに当たりますが、実際には試験対策というものがあって、経験していなくても上手く文章を構成すれば合格しているという現実があるのは確かです。 |
|
|
レベル観の理解と運用について |
以上のことで、「スキル熟達度」、及び「達成度」それぞれにレベルが存在するということがお分かりだと思います。以前、経済産業省から情報処理試験のITSSへのマッピングが発表されましたが、1つの資格に対して「スキル熟達度レベル」と「達成度レベル」が示されていました。つまり、「ITSSレベル」というのは2つのレベルの総合評価になるということです。
「スキル熟達度」はスキル管理システムなどツールによって継続して維持管理ができ、その内容で評価が可能であり、「達成度」は、そのスキル管理を含めたプロセスをデザインし、その中で評価するのが妥当だと考えています。プロセスのデザインというのは、四半期や半期に一度、アセッサーのスキルと経験を持った方が、インタビューをして「達成度」を評価するという仕組みや体制を設計するという意味です。
次回からは、企業インタビュー・レポートに戻り、生々しい現状をお伝えします。 |
|
|
|
|
登録:2011-01-30 15:43:23
|
