1．ITスキル標準の開発と企業活用について

1.1　ITスキル・スタンダード協議会での検討

この節では，2002年5月から11月にわたり経済産業省で開催されたITスキル・スタンダード協議会で検討された資料（2002年11月）を基にして，ITスキル標準の開発にあたっての経緯や考え方を解説する．

1.1.1　開発の背景

ITスキル・スタンダード協議会では，次の論点で意見が交わされた．

• 技術者は，比較的定型的な開発・運用に関する者が多数を占め（業務は開発・運用に集中），ITの企画・調達の部分（企画に貢献するためのITセールス，そうした市場循環自体を戦略的に開拓するITマーケティングなど）が大幅に遅れている．米国と日本との産業競争力の差はますます大きくなりつつある
• 高等教育機関が不足し，社内に十分な教育・訓練リソースを持てる企業と持てない企業との間に大きな開きができる構造となっている
• 結局，最初に営業力でユーザを獲得した大手ベンダがすべて囲い込み，多層的な下請構造の下で開発を続けるという構図からも脱皮できない
• 価格がスキルを評価しない市場：営業力で仕事が決まる

（出典：ITスキル・スタンダード協議会資料2002年11月）

1.1.2　開発の目的

ITスキル標準の整備により，個々のITサービス業務に必要とされるスキルや市場ニーズの高いスキルが明確になり，企業やIT技術者におけるキャリアパスの設計，企業間のプロジェクトベースでの高度なスキルの流動化，あるいは教育ビジネスの活性化などが期待される．

すなわち，ITスキル標準開発の目的は次の通りである．

• スキルの市場化・流動性の向上
• キャリアパスモデルの提示と人材育成投資の活性化
• これらを通じた我が国IT市場の競争力の向上

また，その次の段階として，国際的な相互認証等国際性を持ったITスキル標準とすることを目指す．

（出典：ITスキル・スタンダード協議会資料2002年11月）

1.1.3　開発にあたっての前提

ITスキル標準の開発を進める上での前提事項は次の通りである．

• ユーザリテラシーの分野は取り入れない．ユーザサポートのプロフェッショナルは対象とする
• ITシステムの戦略立案をするコンサルタントは対象とするが，経営戦略そのものの戦略立案をするコンサルタントは対象としない
• 業種別の知識の詳細については，第2段階以降の作業とする

• エントリレベルに必要となる知識体系については，CC2001（米国ACM/IEEE-CSが策定した情報専門教育カリキュラム）など国際的に標準となりつつあるものを準用することとし，詳細を規定しない
• 初級システムアドミニストレータは合格できるだけの力がある人を底と考える
• 希少性の高い高度なスキルを明示できる体系とし，また，共通の理解を得られやすい用語を積極的に採用する

• 特定製品向けの言語や開発ノウハウなども市場の動向に先んじて極力取り込み，人材開発の良き指標となることを目指す
• 長期的な技術と，短期的な技術は，両者が区別しやすいような体系立てとなるよう，ITスキル標準を構築する際に工夫する
• ITスキル標準の改訂のための体制を検討する際には，長期・短期それぞれが異なる体制と期間で更新されるよう配慮する

• 現実に採用の際重要なメルクマールとなっている総合的な人間性については，捨象する
• ただし，Human Communication，Project Managementなどスキルとして評価可能なものについては，スキルの一部として積極的に取り入れる

• 国際標準となることを十分に重視し，SFIAや欧米の主要IT企業が用いているようなSkill Frameworkと大きくかけ離れることのないよう配慮する
• 海外の主要なSkill Frameworkとの相互認証を将来的には進めることを意識して作業を行う

• 共通の指標として活用されるよう，極力共通の理解が得られやすい用語を積極的に採用する
• 市場ニーズの高いスキルを浮き彫りにするため，ニーズの高いJobを中心に，Job Descriptionの定義を体系化する
• 希少性が高くニーズも高いスキルにたどり着くためのキャリアアッププロセスを明確化し，人材研修ニーズをよりクリアにする

この時点では，ソフトウェア製品など個別要素技術スキルや業種別知識の取り込みを考えていたが，議論ののち，より普遍性の高いものを中心とした定義とすることに落ち着いている．

また，ヒューマンスキルやコンセプチュアルスキルなどのコンピテンシ系は当初より基本的に範囲外とし，技術的に専門性の高いスキルの習得を目指す内容を対象と考えている．

ITエンジニアの底上げというより，ある程度の位置にいるグループを対象とし，さらに専門特化させ高度IT人材を目指す，という方向性である．

1.1.4　開発のアプローチ

経営やGeneral Managementは対象から除外し，あくまでも，それぞれのスキル領域のプロを育成するため，プロがプロのスキルを評価する際のスキルの枠組みと標準を作成する．多くの分野に見られるみんなが社長や管理職を目指すという単純なキャリアパスの弊害を正し，評価の確立されたプロへの認知を高めるため，それぞれのスキル領域におけるCareerをまず明示し，エントリレベルからCareerに至るキャリアパスを明確に整理する，という考え方でフレームワークを作成する．

なお，コンピテンシの問題はきわめて重要だが，今回は，まずスキルのフレームワークをしっかりと明示することに目的があるため，作業の対象外とする．

（出典：ITスキル・スタンダード協議会資料2002年11月）

「スキル領域のプロ」とは，「職種・専門分野はITエンジニアの活動領域を分類したもの」と捉えると，「職種としてのプロ」，つまりプロフェッショナルとしての特定活動領域ごとの能力を指すということである．

キャリア，およびキャリアパスの表現は，分類した職種を人材像と考えないと矛盾を起こすため，職種を人材像と仮置きした前提に立っている．これは，企業での活用方法に言及していないために，どのように使われるかのイメージが具体的でないまま議論したことが原因であり，その結果これらの表現に行き着いた．

また，ラインマネジメントなど組織管理能力は範囲外としている．

1.1.5　成果物

IT スキル標準の基本要素は以下の3つとなる．

• 職種（Career）：ITサービスを「コンサル」，「PM」，「ITスペシャリスト」など11の職種に大別
• 業務（Job Category）：各Careerを「e-BusinessのPM」，「ソフトウェア開発のPM」のように個別業務（専門分野）に細分
• 作業（Task）：各Job Categoryを実施するために必要な作業を「品質管理」，「組織管理」のようにさらに細分（スキル領域のカテゴリ）

ITスキル標準においては，各種ITサービスの提供に必要なスキルを要素分解し，客観的な観察可能性や，教育・訓練での活用可能性の観点から整理するアプローチを実施している．

• ITサービスを「職種／専門分野」として区分
• 職種／専門分野ごとに，スキルを客観的に観察する指標として，経験・実を記述した「達成度指標」を設定
• 職種／専門分野に必要なスキルを教育・訓練に活用する観点から要素分解した「スキル項目」を整理し，スキル項目ごとに習熟の度合いを示す「スキル熟達度」と必要な「知識項目」を展開
• 以上に加えて，一覧性を持つこれらの全体像を提示するものとしてSkill Frameworkを作成

職種／専門分野は，実際のITサービスの種別を反映する形で区分している．また，「辞書」として機能しやすくするために，それぞれの区分において必要なスキルを独立して参照可能なように規定している．

職種／専門分野はいわゆる人材像ではない．このような指標を作成する際の考え方としては，人材像として一定の役割や職務をモデル化し，それぞれのモデルに求められるスキルを導き出すアプローチもあり得る．しかしながら，ITスキル標準は，辞書としての活用性を高める観点から，固定的な役割や職務のモデル化を行うのではなく，市場において顧客が必要とするスキルをまず浮き彫りにしてそのスキルの標準化を行い，市場のめまぐるしい変化に応じて企業や関係者の対応が柔軟かつ大胆に行われることを確保しようとしたものである．

（出典：ITスキル・スタンダード協議会資料2002年11月）

ここで，あえて人材像ではなく，辞書的分類での参照モデルであることを徹底しているのは，人材像での提示だと事業モデルや市場の変化に大きく左右されるため，構成や考え方を変えずに継続的に使えるものとするためである．

コンセプトの時点では明示されていたJob Descriptionの定義を体系化といったものが，「職種の説明」として多少あるものの，最終的にはほとんど定義されていない．

同じくコンセプトには，Job Categoryを実施するために必要となるTask，各Taskを実現するために必要な能力（Ability），および知識（Knowledge）といった明確な定義がされていたが，公表内容では明確に分類されていない．

また，ITスキル標準では，人材像として複数の職種／専門分野をまたがる役割を持つモデルを否定するものではない．人材像については，企業の事業戦略や教育機関の教育方針にしたがって，柔軟に形作られるべき前提で整理したものである．

企業でのITスキル標準の活用は，経営戦略や事業計画に沿って策定した人材像を基に人材育成を進める必要がある．

（1）Skill Framework

縦軸に，“Authority & Responsibility”をとり，横軸に“Range of Skills”をとり，各IT技術者がなすべき業務（Job）とそれに求められるスキルの概要を定義する．このフレームワークのレベルで，実際に市場で流動化すべきスキルの組合せと平仄が合うようにする．

Skill Frameworkは，業務（Job Category）を横軸，能力の熟度（Level1～7）を縦軸とした表である．

ITサービスに従事するすべてのIT技術者は，このSkill Framework上に落とし込まれることになり，言わばIT技術者の現在のポジションを示すチャートとなる（表1）．

なお，エントリレベルであるLevel1からLevel2ではCareerが大きく分かれることはないが，Level３から熟度が上がるにつれてCareerの分化が進み，得るべき知見・経験と捨てるべき知見・経験との選別が進むこととなる．

ITスキル標準V2より，Career Frameworkに名称変更されているが，ITエンジニアの活動領域を職種・専門分野で分類したものという考えは変わっていない．

名称が示す通り，対象領域の必要スキルが主体となった考えからスタートしている．

（2）評価指標

Skill Frameworkで概括された業務（Job）とスキルをさらに細分化し，具体的に行われる作業（Task）と，これに対応するAbility，Knowledgeおよび達成度を評価するためのKey Performance Indicator（KPI）に分解したものを作成する．

• Job Categoryを実施するために必要となる業務（Task）
  タスクの集まりを職種と考えることができる（表2）．
• 各Taskを実現するために必要な能力（Ability）および知識（Knowledge）
  スキル熟達度の定義（表3）．
• AbilityとKnowledge を計測するための目安としてのKPI
  達成度指標の定義（表4）．

なお，Skill Framework上の各Job Categoryには，それぞれに対応したTask，Ability，Knowledge，KPIが設定されることとなる．

以下にProject ManagementのTask，Ability，Knowledge，KPIの各イメージを例示する．

（出典：ITスキル・スタンダード協議会資料2002年11月）

評価指標である「達成度指標」と「スキル熟達度」は，ITスキル標準独自の考え方である．

「達成度指標」は，業務の成果を評価するための指標であり，「スキル熟達度」は，スキル領域という分類体系の中でスキル定義項目群として体系的に整理しており，一つ」ひとつのスキル定義項目は「～ができる」という形で表現している．これらを正確に理解しないと，うまくITエンジニアの評価に結び付けることはできない．

ITスキル標準V2を公開するまでは，スキル熟達度と達成度指標の双方ともが，スキルだと誤解している方が多いという状況があった．それを改善するために，V2以降はスキルについては新設したスキルディクショナリに定義し，その熟達度合いをスキル熟達度として定義した．

また，達成度指標は，業務の成果を評価するための指標であることを明確に定義している．

IT スキル標準の整備により，個々のITサービス業務に必要とされるスキルや市場ニーズの高いスキルが明確になり，企業やIT技術者におけるキャリアパスの設計，企業間のプロジェクトベースでの高度なスキルの流動化，あるいは教育ビジネスの活性化などが期待されていた．

1.1.6　スキルの記述範囲

ITスキル標準においては，ITサービスにおけるプロフェッショナルとして，エントリレベルからハイレベルに至るキャリアパスを実現していくために共通に必要となるスキルを主体に記述している．

一方で，辞書的機能としての一覧性や利便性，メンテナンスの容易性を確保する等の観点から，プロジェクトの局面に応じて短期的に必要となる個別の製品・サービスおよび適用業務知識に関する要素スキルや，個人の適性や資質にかかわるような人間系のスキルについては，詳細な記述を行っていない．

個別の製品・サービスや適用業務知識に関する要素スキルは，項目として記述すれば膨大な量となるが，実際には一個人としてそのすべてを習得することはない．どの要素スキルを必要とするかは，担当するプロジェクトや所属する会社の事業戦略，個人のキャリアパスイメージの持ち様などによって選択されるものである．また，直面する業務において不可欠となる要素技術スキルの修得は，プロフェッショナルとして，自発的に行われるべきものと言える．

（出典：ITスキル・スタンダード協議会資料2002年11月）

以上のように，当初のコンセプトとは異なり，個別の製品・サービス・業務に関する要素技術は範囲外とすることに変更している．ただし，企業ごとに必要なものを明示するよう示唆している．

人間系のスキルは，一般的にプロジェクトで成果を上げることや，高いスキルを実現していくための動機や行動の拠り所としても重要なものである．ITスキル標準においては，人間系のスキルに関して，要素分解によって漏れなく記述することの困難性と，研修などの共通的な教育・訓練で十分に育成することの困難性から，詳細な記述は行っていない．しかし，キャリアパスの実現にあたって，実際に経験・実績を積むには人間系のスキルも不可欠であるとの観点から，達成度指標による経験・実績の記述によって，必要な人間系のスキルを包含した観察を行い得るものと整理している．

なお，コミュニケーション，ネゴシエーション，およびリーダシップについては，研修などの教育・訓練である程度十分な育成が行えることに加えて，サービスビジネスとしてその重要性が叫ばれていることから，すべての職種にわたってスキル項目として盛り込んでいる．しかし，共通的な定義にとどまっており，実際に現場で使うにはさらに工夫が必要である．

1.1.7　レベルの概念

レベルは，当該職種／専門分野においてプロフェッショナルとして価値を創出するために必要なスキルの度合いを表現している．また，キャリアパスを明確にするために，7段階のレベルを設けている．

ITスキル標準V2以降は，提供資料などにレベルと達成度指標の密接な関係が記述されているが，発表当初は特に強調されていない．Skill Frameworkの名の通り，スキルを中心としたものになっている．

職種／専門分野によっては，プロフェッショナル個人として価値を創出するには至らない下位レベルが空白となっているものがあり，また，価値を創出するために必要なスキルの上限以上の上位レベルが空白となっているものがある．ITスキル標準で表現しているのは，あくまでも，プロフェッショナルとして価値を創出するために必要なスキルの度合いであり，それぞれの職種／専門分野におけるサービスの価値の大小や，組織内における職責のレベルを表現しているものではないことに注意が必要である．

また，ITスキル標準で表現しているのは，「プロフェッショナルとして価値を創出するために必要なスキルの度合い」としている．

レベルを職種／専門分野横断的に捉える参考的な視点としては，次のように設定している．

◆レベル5～7（ハイレベル）

社内において当該職種／専門分野にかかわるテクノロジやメソドロジ，ビジネスをリードするレベル．特にレベル7は，市場全体から見ても先進的なサービスの開拓や市場化をリードする．スキル開発においても，社内戦略の策定・実行に大きく貢献することが求められる．

◆レベル3～4（ミドルレベル）

スキルの専門分野が確立し，自らのスキルを駆使することによって，業務上の課題の発見・解決をリードすることができるレベル．スキル開発においても，自らのスキルの研鑽を止めることなく，また，下位レベルの育成に積極的に貢献することが求められる．

◆レベル1～2（エントリレベル）

スキルの専門分野が確立するには至っておらず，当該職種の上位レベルの指導の下で，業務上における課題の発見・解決を行うことができるレベル．スキル開発においては，自らのキャリアパス実現に向けて積極的なスキルの研鑽が求められる．

1.1.8　評価指標の捉え方

これまで多くの企業が，ITエンジニアの能力を管理する「スキル管理の仕組み」構築にチャレンジしてきた．プロジェクトに適材を割り当てることを目的に，各ITエンジニアの持つスキルを事細かに管理するところからスタートした．しかし，IT技術は急速に進歩し，スキル定義の見直し・更新が追いつかず，すぐに陳腐化して使えなくなってしまうということを繰り返してきた．

また，ITエンジニアの経歴や実績は，経歴書や人事システムの中で別途管理されてきた事実がある．

これらをITスキル標準の評価指標に当てはめてみると，スキル管理の内容がスキル熟達度の視点にあたり，経歴書が達成度指標の視点に当たることになる．

別の言い方をすると，スキル熟達度は業務の遂行をする上で必要なスキル習熟度を定義してある．また，達成度は業務の結果，たとえばプロジェクト終了後の成果への貢献度やプロフェッショナル貢献，すなわち専門分野でのリーダシップの発揮度，およびいかに他者に技術を継承したかを表すことになり，それらの評価をするための指標ということになる．

評価指標の定義内容に目を向けると，スキル熟達度のスキル項目や知識項目は，スキル領域として整理・分類されている．この内容は，ツールやテストでITエンジニアのスキル習熟度として評価することが可能である．

一方，達成度指標は，定義しているスキルを発揮して，いかにビジネスに貢献できたかを評価するためのものである．業務経歴書などに書かれる内容をどうすれば評価できるかということと同様であるが，これはツールやテストで評価するのはかなり難しい内容だと言える．貢献度を文章にして一つひとつ確認していってもあまり意味がない．

どのようなプロジェクトだったのか，その中でどういう役割を期待され，結果としてどのように果たしたのか，納期やコストについては満足のいくものだったのかなど，そのプロジェクト全体の中で，何ができてどのような結果だったかを総合的に判断する必要がある．それを，切り取った一文ごとに判断するのは難しい．

アセスメントの熟達者が，経歴書やプロジェクト報告書などを見ながら，本人に一つひとつ確認していかないと，実際のところは分からず正しい評価はできない．

それらプロジェクト報告書，経歴書，および評価のための申請書などの雛形は，IPAから「社内プロフェッショナル認定の手引き」として提供されている．

スキル熟達度は，スキル管理システムなどのツールによって継続的に維持管理ができ，その内容での評価が可能である．また，達成度は，そのスキル管理を含めた評価プロセスをデザインし，その中で評価するのが適切であると考える．

ここで評価プロセスのデザインというのは，四半期や半期に一度，アセスメントのスキルと経験を持った第3者が，インタビューをして達成度や貢献度を評価するという仕組みや体制を設計するという意味である．

1.2　企業活用

ITスキル標準の提供物は，エンジニアが顧客にサービスする観点での記述が主体となっている．それを企業で活用するには，企業の観点，すなわちビジネス戦略の観点から捉えていく必要がある．

人材育成への投資という経営判断やビジネス戦略が伴わないままITスキル標準を活用することは，自社のビジネスや技術を担い，競争力を支えていく人材の育成にはつながらない．ビジネス戦略に乏しく，単に人事管理上の便宜性や処遇制度の見直しのために利用するだけでは，逆に個々のITエンジニアのモチベーション低下につながるおそれがある．

企業活用の目的としては，次の点が挙げられる．

• 企業力・組織力強化のための利活用
  組織の持つべき機能・役割の可視化を行い，効率的に総合力の向上を図る．
• 企業目標と現状にあった育成計画の立案
  ITエンジニアの現状スキルの把握，強化すべきポイントの把握を行い，育成計画を検討する上での指標とする．
• 人材投資の効果，ビジネス目標への貢献度の検証
  スキルという観点から，自社の実力（強み，弱み）を可視化し，人材投資の効果を最大限に引き出す．
• プロジェクト要員の割り当ての効率化
  ITエンジニアの具体的な能力に基づいた適材適所の人員配置を実現し，事業の効率化を図る．
• キャリアパスの明確化
  ITエンジニアの目標とするキャリアを実現するために，どのようなスキル開発が必要になるかを明確化，およびキャリアチェンジを図る際の指標として利用する．

1.2.1　企業活用の考え方

ITスキル標準を企業に適用する際には，次の点を認識しておく必要がある．

• ITスキル標準は「共通指標」
• ITスキル標準は「参照モデル」
• ビジネス戦略に合わせて「企業固有に再定義」
• すべてを必ず使う，そのまま使うという位置づけにはない

ITスキル標準で扱う知識やスキルは，技術領域や各業務に共通するレベルにより定義することで，一定の汎用性を持たせている．

したがって現場に適用するには，具体的な内容に置き換える必要がある．たとえば各企業，各製品に固有の内容は，能力特性とその定義，職務基準書などにもとづくスキルに対応させることが必要である（図3）．

また，企業によってビジネス戦略が異なる以上，投資すべき対象職種も異なる．このため，ITスキル標準を活用する場合には，参照モデルとして利用し，「自社のビジネス戦略に合わせて必要な定義内容に置き換えた指標を設定」することが求められる（図4）．

このように，ITスキル標準を共通指標として「現場で特定できるレベルで解釈あるいは再定義」し，企業（または企業間）の独自指標として適用する．これにより，企業間の解釈による差異を少なくすることができる．

以上のように，ITスキル標準の位置づけは，基準や仕様ではなく，参照モデルである（図5）．標準といっても，自社のビジネス戦略の実現に必要な部分だけを参照すればのであって，「全部を必ず使う，そのまま使うという位置づけにはない」ことを理解する必要がある．

また，企業に必要なのは，「ビジネス目標達成に貢献する人材」である．したがって，ITスキル標準を企業で活用する場合は，自社の目標人材として人材像や役割を定義する必要がある．

1.2.2　2つの活用視点

ITスキル標準の企業活用には，次の2つの方法がある．いずれか，もしくは両方を採用するかは，企業の方針や考え方により決定することになる．

• 企業間比較，調達視点
  企業間比較によるIT業界内での位置づけの明確化，またはITエンジニアの人材調達（企業間，採用など）に活用．
• 企業戦略視点
  ビジネス目標達成に貢献するITエンジニアの育成に活用．

活用の考え方は，何を目的にするかによって大きく異なるので，十分留意する必要がある（図6）．

（1） 企業間比較，調達視点

IT業界の中での自社の位置づけを確認することや，共通指標上での企業価値を他に示す，またITエンジニアの人材調達に適用するというものである．企業価値を共通指標上で表現する場合，図7のように企業に属するITエンジニアがどの職種のどのレベルに位置づくかということを明らかにすることが必要である．このITエンジニアごとの情報を積み上げることで，共通指標上での自社のIT業界内の位置づけや，強み弱みを明らかにすることができる．

こういったIT業界の中での自社の位置づけの確認，他者との比較，およびITエンジニアの人材調達に適用する場合は，キャリアフレームワークをはじめとするITスキル標準の提供物は，変更せずにそのままの形で活用することになる．これは市場価値基準を重視する考え方で，企業間比較や人材調達に利用することが目的である．この活用視点を「企業間比較，調達の視点」と呼ぶ．

（2）企業戦略の視点

ITスキル標準の提供物は，ITエンジニアが顧客にサービスする観点での記述が主体となっている．しかし企業活用する場合は，自社の戦略を生かした仕組みを考える必要がある．企業にとっての人材育成は，ビジネス目標を達成するための手段である．そのためには，中長期ビジネス戦略を基にした目標となる人材を定義し，現状とのギャップから育成プランをたて実施していく必要がある．各企業でビジネスモデルや戦略がそれぞれ異なるために，目標とする人材を定義するためには，参照モデルであるITスキル標準をそのままの形で使うことに大きな効果は期待できない．

企業が独自に考えるのではなく，ITスキル標準をベースにすることによって，目標人材の定義が飛躍的に効率化されることになる．

人材定義に先立ち，ITスキル標準検討時のコンセプトでもある「Job Categoryを実施するために必要となるTask，各Taskを実現するために必要な能力（Ability）および知識（Knowledge）を定義する」という考えに立つ必要がある．ビジネス戦略を達成するためのあるべき組織機能（タスク）を明確にし，そのタスクの責任や役割分担を議論にして目標人材を策定するという流れが，企業活用の早道であると言える．策定には経営層，経営企画が十分にかかわる必要があり，責任部署としては，経営企画や，人材開発担当部署など全社横断的な組織となる．

これはITスキル標準を参照モデルとして利用し，自社のビジネス戦略に沿った独自の基準を作る考え方である．この活用視点を「企業戦略の視点」と呼ぶ．企業間比較，人材調達など社外とのやりとりが発生した場合は，本来のITスキル標準に読み替えることが必要である．

2．ITスキル標準以降のスキル標準

2005年にETSS，2006年にUISSが立て続けに公表された．これらは，既存のITスキル標準をそれぞれIT技術者の置かれた状況に対応できるよう範囲を拡大したもので，ベースには次の共通見解があった．

• エンタープライズ系のIT技術が対象のITスキル標準は，技術者そのものが成熟しており，企業の中でどのように活動していくかということや，キャリア生成などが課題となっていた
• 組込みの世界は，大幅に技術者が不足しており，いかに育成して技術者の人数を増やしていくかが課題だった
• ユーザ系のIT部門，情報システム子会社については，自らの仕事の範囲や内部の役割分担，パートナー企業との役割分担が問題となっていたが，ITスキル標準はそれらの問題解決に適していなかった

ETSSとUISSは，ITSSの基本的な考え方をベースとしながら，異なる構造や考え方も採用されていた．これら3つのスキル標準（以下，3スキル標準）は，個別に見れば実態に即したものではあったが，企業活用の観点では課題も顕在化した．たとえば現実には，ITSSとETSSの両方を使いたいと考えた企業が，どのように対処していいか分からず試行錯誤を繰り返すことになった．結果として検討サイクルが長くなる，担当者の異動で棚上げになるなど，有効活用とは程遠い状況の企業が続出した．

2.1　CCSF/iCDの公表

3スキル標準の企業活用という観点での課題解決を目指し，2014年7月に独立行政法人情報処理推進機構（IPA）から公表されたスキル標準の最新版がiCDである．すでに2006年には「共通キャリア・スキルフレームワーク（CCSF）」が公表されていたが，CCSFはiCDの初期バージョンとして位置づけられる．

CCSFは，UISSをベースに旧来の3スキル標準を統合したものであるが，さらにタスク中心の考えが明確になっており，これは企業で活用する場合には必須の考え方である．

iCDもこの考え方を継承しており，自社の戦略に合わせて組み立てるというポリシーを基に設計されている．

また，iCDになってCCSFの構成要素であるタスクモデル・スキルモデル・人材モデルから，「タスクディクショナリ」と「スキルディクショナリ」の2つの構成に変更され，よりシンプルになっている．さらに，教育プログラムやIT系資格との紐付が可能で，より現実的・効果的な仕組みとなっているのが特徴である．

各ディクショナリを整理・編集するにあたり，IT関係の主要なBOKなどを取り込んでいる．

今後は，取り込んだBOKのバージョンアップなどのタイミングで，必要に応じてメンテナンスされていくことになっている．

2.2　iCDの活用

3スキル標準は，今まで発表されている事例からも，企業活用を中心に使われてきたことは明らかである．

企業においては，それぞれビジネスモデルがあり，将来計画も異なり，ビジネス目標が異なる．よって，提供された固定枠の中にはめるような活用の仕方では，自らの意志を反映することはできず，有効に使えているとは言えない．当初は，枠にはめることで簡単に人材育成や評価ができるという誤解があり，IT企業の人材育成担当者が積極的に取り上げたが，頓挫してしまう企業が多かったという事実がある．ITスキル標準のCareer FrameworkやiCDのタスクディクショナリなど，提供されたものを何も変えずにそのまま使ってしまうことなどがその例である．

特に中小企業はその傾向が強く，一方大手はスキル標準を自社に合った形にカスタマイズして使っている．

昨今，さらにビジネス環境も大きく変わって，自社の独自性や競争力を向上させることが重要となった．その結果，固定化されたものを使うのは得策でないという判断をする企業も目に見えて増えてきた．

まさに，自らの意志をもって組み立てるという考え方のCCSFやiCDが，この点に応えるものとして各方面から評価を得たのも当然だと言える．

2.2.1　iCDの活用形態

iCDの活用形態については次の3通りがある．

• 組織力強化のための活用
  ─　組織の持つべき機能・役割の可視化，および組織設計
  ─　役割分担，最適配置の明確化
  ─　業務機能の把握と生産性や業務品質の向上を目的とした人材育成策の検討
• 企業・組織戦略実現に向けた効果的な投資の実施
  ─　優先順位の明確化，投資効果の把握
• プロジェクト要員の割り当ての効率化
• 企業・組織目標と現状にあった人材育成計画の立案
  ─　IT人材の現状，強化すべきポイントの把握
  ─　育成計画の検討
  ─　適切な教育プログラムの選択
• キャリアパスの明確化
  ─　目標とするキャリアを実現のためのスキル開発の明確化
  ─　キャリアチェンジを図る際の参照モデルとして利用

• IT関連スキルの把握
• 自身の持つスキルと成熟度の把握
• 各スキルの活用場面（タスク）の理解，または就業を希望する仕事に必要なスキルの把握
• 目標とするスキル，その習得手段，到達確認の手段（資格，試験など）の明確化

• スキルディクショナリを基にした教育プログラムの企画・提供
• 教育プログラムの評価

2.2.2　iCDの活用プロセス

図8はiCDを活用して，企業や組織がIT人材育成のPDCAを実行する仕組みの構築・運用プロセスを示している．この手順は，筆者が2004年に考案したITスキル標準向けの活用プロセスが，UISS，CCSFへと引き継がれ，現在はiCD活用手順として正式採用されている．この活用プロセスは基本的に変化しておらず，今までこの方法で取り組んだ多くの企業・組織が成果を上げている．

「要件分析」から「試行と確定」までが「導入プロセス」であり，人材開発の仕組みの構築プロセスである．「現状把握」以降は，構築した仕組みを実際に運用する「運用プロセス」になる．

企業や組織は，経営戦略や事業計画を基に，将来を踏まえて求められる活動内容，およびそれに必要な実行能力を明らかにすることが必要である．その上で現状との差異から育成計画や人員計画を立て，PDCAを回すことが理想的なアプローチと言える．

2.2.3　「役割」の考え方

iCDは，タスクを中心に置いたコンセプトであるが，使う側として一番身近なものが，タスクを束ねた「役割」である．

ITスキル標準・ETSSでは「職種」，UISS・CCSFでは「人材像」を，ドキュメント上での呼称として使ってきた．一方，スキル標準を活用する側ではそれぞれを人材に当てはめて使うのをイメージすることが一般的であった．

「職種」は厳密に言うと，人や役割ではなく，技術領域をカテゴライズした言わば分類のようなものである．ITスキル標準の初期の説明文では「職種は，いわゆる人材像や役割ではない」と明記されていたが，使う側ではあまり意識せずに，人材や役割と読み替えていたのが事実である．その結果，会社の仕事の単位や組織の単位と合わないことが問題視されたのもうなずける話である．

一方で，「人材像」も実在の人物をイメージしてしまうことから，複数の仕事を掛け持ちしている人，たとえば設計とPMなどを1つの人材像で表現しようとしたため，いろいろな組合せのものが多数設定されてしまう結果になってしまった．

そういった，環境や立場の違いでの異なる理解をなるべくなくしていかないと，人材育成の仕組みとしてうまく機能しない．そこで，iCDでは共通した理解を促すために，今まで使ってきた「職種」や「人材像」という呼び方を改め，「役割」に統一している．本来企業で一番使われるのは役割／ロールであるということからも，大変現場感があり企業活動としての実態を伴った表現だと言える．

以上をまとめると，iCD有効活用のポイントは次の通りである．

• 人と役割は通常1:nで考える
  PMをやりながら設計も担当している，など．
• 役割は育成できる単位とする
  余分なものを付加せず，たとえばPMを育成する，という考えにたてること．
  もし，PM+設計など複数が合体したような役割設定になっているとすれば，育成のゴールが不明確になる．
• 組織の枠を外してキャリアパスをデザインできる単位とする

2.3　iCDの限界とITSS+

昨今はDX推進の必要性が明らかになりつつあり，過去の延長線上にはない世界も見えてきた．

一方で，現状の活動は問題なく守り継続し続けなければならない，ということも事実である．

以上を踏まえ，今後は単なる見える化だけではなく，戦略的にiCD，ITSS+を活用する必要がある．

iCDは，タスクディクショナリの構成からウォータフォールを基本としていることが分かる．その1点で，アジャイルなどを主体とするDX技術に対応するのは難しいことになる．

筆者が現在のiCDの基本構造を作ったのは2004年であるが，その当時はタスクをファンクションと呼んでいた．まさに，機能として定義していたということである．

システムなどを設計する場合，機能的には「設計」と表現できる．しかし設計と一言で言っても，業界が異なるシステムの設計，バッチ系システムの設計，Web系システムの設計，データ構造の設計，そしてDX関連でいうとAIを用いたユーザ向けのクラウドシステムの設計など多種多様である．設計の前にそれぞれ修飾子をつけると識別できるが，機能的には「設計」に変わりはない．特にDX技術について同じように表現すると，いわずもがなミスリードにつながり混乱する危険が大きいことになる．

これらのことから，今後のDX推進に向けた人材戦略に対応するには，iCDだけでは不十分だということが明らかである．

先に述べたようにタスクはコンテンツの特徴としてウォータフォールに見える構成になっている．3スキル標準，特にUISSの考えを基にしていることからも，その形態になってしまうのである．

このように，iCDのみの活用では機能的表現の混乱だけではなくて，DXの主流であるアジャイル開発がうまく表現できないことになる．無理やり表現しようとするとウォータフォールのタスクと同じような定義となってしまい，アジャイルの機能が埋没してしまうことにもなりかねない．

これらの状況を回避するために，DX推進用として別途定義するのは自然な流れだと言える．

経済産業省，IPAが「ITSS+」にDX推進の活路を見出したことには拍手を送りたい．

ネーミングに関しては賛否が分かれるが，従来のITスキル標準とはまったく別物になっている．ITSS+は，ITスキル標準の職種の横に並べるようなものではないことを，十分に理解する必要がある．

また，iCDのタスクの中にデータサイエンスやIoTが定義されているが，これはiCDとして一体化しているのではなく，新たに「領域」などを設けてウォータフォール系の他タスクとは一線を画してあり，その使い方も異なる．

ITスキル標準からiCDに至るまでのスキル標準の基本的な考え方は，従来のIT投資を基本としている．対して今後必須になるDX推進は攻めのIT投資が重要となる（表5）．

スピード重視や，ビジネス部門が中心になること，またパートナーも一体となる組織化などに重点が置かれることになる．

DX推進に関して言えば，出来上がったコンテンツでタスク遂行力チェックやスキルチェックをして，ギャップから育成計画を作成していくような代物ではないということであり，そういった従来の方法にこだわっていては，DX推進に向けて有効な手は打てないということになる．

今後はDX推進を睨んで攻めのIT投資を部分的にもスタートしていくことが重要であると言える．

3．今後の方向性

DXについて経済産業省は次のように定義している．

「企業がビジネス環境の激しい変化に対応し，データとディジタル技術を活用して，顧客や社会のニーズを基に，製品やサービス，ビジネスモデルを変革するとともに，業務そのものや，組織，プロセス，企業文化・風土を変革し，競争上の優位を確立すること」

（出典：経済産業省「DX推進指標」とそのガイダンス／令和元年7月）

また，DX推進への取り組みについて，次のような2つの形態が考えられる．

• ディジタル技術，データを活用し，従来の事業や業務を大きく変革
  ビジネストランスフォーメーションであって，従来の事業エリアの変更や新規事業とは異なる．
• スマート製品からビッグデータを収集／分析し，新たな適用分野，新規事業の推進
  従来とは異なり，顧客ターゲット，収益源，提供経路を変革する．

今後は，「いいものを作れば売れる」ではなく，顧客の動向をいち早く察知して購買行動につなげることが重視するカスタマー・エクスペリエンス（CX）戦略が重要となる．

3.1　iCDとITSS+を使ったDX対応

iCDの活用法は「Task Oriented Approach」であり，図8の活用手順にあるように全体のタスク構造を求めた後で担当タスクの範囲で役割分担していくという流れである．

また，iCDを活用することで，既存ビジネス，および将来目標をタスク構成で表すことが可能となり，次の利点がある．

• 人ではなく組織機能視点での必要なタスク推進力を明示
• 目標に対する客観的過不足の数値化
• 環境変化や戦略変更に応じた素早い再構築が可能
  これは，環境の変化に対応してタスクや役割を素早く組み立て替えることができるというiCDの特性を活用し，主力サービスを改善し堅持することにつながる．

一方，ITSS+は 「Roll Oriented Approach」であり，あらかじめDX推進専用の役割を設定するところからスタートする．これで，Goalが見えにくいDX推進への対応が可能となり，次の利点がある．

• データサイエンス領域などDX推進用の各領域の定義体を使用した新たな適用分野への役割設定
• 目的に応じた新たなDX技術取り込みと適用のための検証

DX推進に向けての利活用のポイントをまとめると図9のようになる．

• iCDは現行業務，およびその延長線上にある将来の業務を見える化することに適している
• 反面，iCDだけではDX技術への対応が難しい
• DX推進専用の役割を設定し，技術スキルなどはITSS+を参照し補完する必要がある

図10はiCD活用手順をベースに，役割定義のところでITSS+を使用してDX推進専用の役割を設定する手順を追加したものである．

役割はタスクの集合体であり，iCDのみを使った場合の策定の仕方は，企業や組織全体のタスク構造（To Be）を構築してから，役割として分担していくという手順となる．

この全体のタスク構造構築時にDX技術のタスクが入り込んでしまうとミスリードとなってしまい，うまく構造化できないということは先ほど述べた通りである．タスク役割定義のタイミングで，新たにDX担当の役割を設定し，ITSS+の定義群などを活用することがDX対応の早道となる．

設定した役割に対してITSS+の定義体などを使ってDX技術を補完していくことは，それほど難しくなくミスリードを防ぐことができる．

3.2　スキル標準活用のポイント

スキル標準の企業活用においては，経営視点，組織タスク視点，およびDX推進の視点が重要である．何が目的か，実施内容は目的に沿っているか，自社のモデルとして適正かなど，十分に考えてから取り掛かることが必要である．後戻りはできないことを十分認識する必要がある．

取り組みにおけるポイントは次の通りである．

• 経営者自らが内容を理解してリーダシップをとり，推進者が動きやすい環境を作ること
• 推進者に優秀な人材をアサインすること
• ビジネス目標，経営戦略，IT戦略から自社の魂を入れた「タスク構成」，「役割定義」，「スキル定義」を策定すること
• DX推進に関しては，専用の役割設定をして明確にすること
• 本番開始後の継続運用についても十分に検討すること

• 議論せずにそのままの形で取り込むこと
• 理解度の低い担当者に丸投げする（責任を押し付ける）こと
• 目標や各定義体を検討・設定せずに，スキル診断などを行うことや，人事に取り入れること