DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ＩＴ技術者のスキルをＩＴスペシャリスト、コンサルタント、カスタマーサービス、プロジェクトマネジャ等、職種別に分類し、そのサービスを提供するのに必要なスキルはなにか、実務能力を体系化し「みえる」化した「ＩＴスキル標準（ITSS）」に高い期待が集まっている。ＩＴサービスの内容がより専門化し、細分化と深化が進む中、業界共通のスキル標準を設け、より体系的で戦略的な人材育成を図っていこうというITSSの意義は大きい。だが、ITSSに寄せられる期待の中にみられる、ある「誤解」が放置されたままだと、ITSSはそのよさを発揮できない。
ITSS活用の現場で多くの例に接している林衛が、なぜそのような誤解が起こるのか、またそれを回避してITSSをうまく活用するためには、何が必要なのかを語った。

ITSSへの過大な期待がもたらす誤解

ITSSはプロジェクトマネジャを含む11の職種を７段階にランク分けし、その職種とランクごとに、ＩＴサービス提供に必要なスキルについて細かい定義が記載されている。日本のＩＴ業界におけるサービスの質の向上と、それを支える人材育成のためにこのような指標が設けられたことの意義は大きい。ITSSの導入に大きな期待が寄せられるのは当然と言えよう。だが、問題は実際の活用場面において、期待の大きさのあまりに、ある誤解に陥る危険性があるということだ。効果の大きい薬には、正しい適用方法が求められるものだ。
たとえば、ＩＴ企業（特に技術を提供する側）の人事担当者がITSSの詳細なスキル定義を見て、「なるほど、プロジェクトマネジャ（ＰＭ）を育てるにはこれをすべて身につけさせなければいけないのだな」と思い込む。しかもこの担当者は「能力定義＝トレーニング」というストレートな方程式に縛られて、それ以外に目が行かないため、詳細な定義をカバーするトレーニング・プログラムを組もうとし始める。しかし…。

勘のよい読者の皆さんはすでにお分かりだろう。それでは肝心の仕事をしている時間がなくなってしまう。ＩＴの世界では個人の能力を向上させる上でトレーニングコースの受講が役立つ比率はせいぜい10％程度だろう。それなのに、ITSSに定義された能力を獲得させるトレーニングコースを組めば、人格の優れたマネジャが育つような幻想を描いてしまう。これは多分に戯画化した例だが、ITSSを導入しようとする場合、多かれ少なかれそのような誤解に陥りやすいようだ。

ITSSは世に出て２年程度しか経っていない。改善を重ねることでより使いやすくなっていくというのが標準化の世界の常識であることを考えると、ITSSは、すでに出来上がった部分についての完成度は高い。よく考えられ体系化された「参照モデル」である（後に述べるように、まだ今後補足が必要な部分があると考える）。
ITSSの活用が迷走する最大の理由は「期待と実態のずれ」の大きさにある。最初にも述べたとおり、ITSSはＩＴ技術提供者の視点から11職種が定義されており、その職種に必要と思われる「能力（スキル）」が比較的細かく定義されているのが特徴である。ここで定義されている能力は、人事の用語でいうと「職能定義」に当たる。
職能定義は仕事を遂行する上の必要条件であって十分条件ではない。ところが、ITSSを十分条件であると期待してしまう人が多く、さまざまな混乱が起こっている。
そのような誤解を招く最大の理由は、ITSSが「細かく定義されている」ということにある。それ自体はもちろん悪いことではない。しかし、細かく定義されてたくさん文章が書かれていると、それを活用する側が「これだけたくさん書かれているのだからすべてを網羅した十分条件なのだろう」と期待してしまう。そこで往々にしてこの「誤解によるずれ」は大きくなってしまうのである。
歴史的にＩＴ部門は、事業会社が会社の運営のために持っている人事モデルと合わない面がある。特にスキルは従来の人事モデルに適合していない空白部分であった。そのような経緯もあってITSSに一気に期待が高まり、これを利用して短期に問題解決を図ろうとする風潮が生まれてしまったのだろう。

仕事の遂行には「職能」だけでなく「職務」が必要である

もうひとつの問題は、ITSSの定義が提供者側の能力定義だということだ。しかしITSSが普及するためには、むしろ発注者側から役割や責任、職種、権限（つまり「職務定義」）を定義する必要がある。仕事が発生するのは発注者側からなのだから。ちなみに「職務定義」は10行程度でひとつの職種が定義されており、そこには責任と役割、つまり権限が入ってくる。抽象レベルは高いが的確なものである。責任と権限がなく能力だけが定義されていても、仕事は動かない。
人事モデルを開発する際に重要なのは、企業の戦略や事業領域がはっきりしており、戦略に則った職務定義がなされていることである。それは当然企業特性や時代環境によって変わる。それができたら、次に職能と関連づける。獲得すべき能力がはっきり提示されれば、あとは個人の問題となる。能力アップに教育の占める割合は以外に少なく、志や動機づけが大きな意味を持つ。職務とはその人の権限と責任をはっきりさせる、いわゆるミッションであり、職能はそのために必要となる技能である。
ITSSの詳細なスキル定義は、この「職能」を意味しているのである。では「職務」はどうするのか。ここで厄介なのは、スキル定義のような形で職務を統一するのは不可能だということである。なぜかというと企業は、事業領域と事業環境で最も有効な職務体系を組むので、それは当然部分最適となる。よって職務は各企業が、自分たちで組む必要がある。　
発注側からすれば、技術者の能力より「どのような責任と権限が担えるか」がわかったほうがよい。能力定義はもちろん重要であるが、ITSSを十分活用するという意味では、提供者側の能力定義と、発注者側のニーズのギャップを埋めていく必要がある。ITSSの実際の活用にはこのような「活用上の注意」を忘れないでほしい。
また、能力とそれが実際の職務でどのように発揮されるかは、複合的な側面を持つ。例えば、一人の有能なＰＭがＳＥを経て育ってきたとすると、ＰＭとしてのレベル、スペシャリストとしてのレベル、アプリケーションエンジニアとしての能力レベルと合わせ持つことになる。小規模なプロジェクトなら複合的な役割を担うことになるだろう。またプロジェクトは、そのような複数の能力を持った人間がチームで行うので、チームのパフォーマンスが重要である。チームとしてどのように能力を発揮できるかは、個人のスキル定義から測ることはできない。そのずれを正しく認識さえすれば、ITSSを有効に使うことができる。

今後ITSSに必要となっていくこと

ITSSがＩＴ技術者の能力を定義し、レベル分けしたことはすばらしいことである。だが、まだ実際に活用され普及していくためには、いくつか不足している部分もあることがだんだんに明らかになってきた。
まず能力ベルが定義されたからには、レベルを判定し、判定するからにはその結果に責任を持たなければいけないが、それをどうするのかが検討されるべきだろう。ただし、私の経験からはスキルを測ったときにITSSの７段階のうちレベル１，２に80％以上が相当する。つまり80％以上の人は一つのプロセスを独力でやり遂げることができず、補助を必要とする。ほんとうのプロはごく一握りで、ほとんどの人はエントリーレベルなのである。そこで、能力段階の刻み方をわかりやすく変え、それに則した判定方法が必要だろう。この点に関しては議論が進んでおり、１～３までの段階は何らかの診断方法で測定が可能だが、４以上は面接や有識者の多面評価が必要ではないかということになっている。
また情報処理資格試験やPMP、P2M、他に各ベンダーが提供している資格の位置づけをどうするのか検討する必要もある。さらに、PMについてはすでに一部組み込まれてはいるものの、仕事の遂行に必要不可欠で人材育成上も重要なコンピテンシーもITSSに取り入れていく必要があるだろう。
ITSSのニーズは、社会的側面、発注側、受注側、個人の視点の４つが重要なセグメントであるが、現在までのところ提供側と個人の能力定義に偏っている。「どのような責任が負えるのか」という発注者側の視点、仕事がどこで発生するかの視点を加えることが、今後の利用の広がりにも重要であろう。

特性を理解し、上手な活用を

ITSSをうまく活用している会社は、このようなITSSの特性を理解している。最初に上げた例と同じように職能から入ったのだが、職能と職務の違いについてきちんと理解があったため、やや回り道はしたものの自社に合わせた職務定義をきちんと構築している企業もある。ある成熟度の高い企業では、発注条件など発注側の視点を含めてITSSを活用しようとしている。私たちは44社のユーザー系企業とベンダーの意識調査をしたが、ITSSの活用レベルはさまざまであった。
能力定義に誤った期待が膨らむ背景には、課長クラスに責任は担わせるが権限を持たせない日本型組織のあり方や、細かく分析することで物事を理解できると教える日本の教育の悪しき側面が影響している、と私は考える。よって導入担当者だけを責めることはできない。だがその呪縛にとらわれたままだとITSS導入は成功しない。ITSS導入をお考えの場合には、この過剰な期待にあおられていないか自己分析し、なんのためにITSSを導入するのか再確認してほしい。