パブリックコメント：「高度ＩＴ人材の育成をめざして（案）」に対する意見【ゆきんが提出したコメント】

（１）現状認識（IT人材問題の原因） .

「高度IT人材の育成をめざして（案）」（以下，「報告書案」とする）で指摘されている，IT産業の産業としての魅力の欠如や，それに伴う我が国IT人材の問題（とくに，情報工学系、さらには理工系を志望する学生が減っていること）（pp.12-13）は，私自身もまた深く憂慮している問題である．もしもこのまま，情報工学系の学科やIT産業に意欲と能力にあふれた新しい若者が次々と供給されないようになってしまうと，日本のIT産業は衰退していきかねない．

私が大学に入学した15年前は，全国の理工系大学に次々と情報工学系の学科が開設されていた時期だった．これから新しい分野が発展していくという可能性を感じ，私も情報工学科に進学し，大学と大学院修士課程で情報工学を思う存分学ぶことができた．

そして，9年前，私が修士課程を修了してIT産業に就職した頃は，当時のドットコム・バブルの雰囲気もあり，何か新しいことをできるのではないか？という夢のある業界のように思っていた．私と同期で入社した社員にも，新しい仕事に取り組もうとする，生き生きとした意欲のある者が多かったように思う．

だが，いまの学生や求職者の目に，IT産業は魅力的な，夢のある産業として映っているだろうか．

私の同期で入社した社員には，現場の最前線で活躍する者も多い一方で，入社から数年もたたずに離職していった者も多い．同業他社に転職した者もいるが，IT産業そのものに失望し，見切りをつけて離職したと思われる者もいる．また，心身の病で働けなくなっている者もいる（私自身も，難治性うつ病で3年近く休職しており，つい最近まで解雇されるかどうかの瀬戸際にいた．最近なんとか復職はしたものの，1日4時間の短縮勤務でしか働けない健康状態が続いている）．

ITエンジニアを志す学生や求職者が減り，離職者や病気休職者が増え，IT産業全体が縮んでいくことこそが，日本が抱える最大の「IT人材問題」なのである．人材の供給が滞り，離職者や病気休職者が増えていけば，高度な知識や技能や業務経験を持つ「高度IT人材」を育成していくこともまた，難しくなっていくだろう．

この「IT人材問題」の原因として考えられる「過重労働の問題」「評価とモチベーションの問題」「情報処理技術者試験とITSS，ETSS，UISSの問題」のそれぞれついて，私の現状認識を述べる．

1.1 過重労働の問題 .

結論から言うと，この「IT人材問題」の最大の原因であり，最優先で対処すべき問題は，情報処理技術者試験やキャリア・スキルフレームワークの問題ではなく，むしろITエンジニアの過重労働の問題である（つまり，報告書案は取り組むべき施策の優先順位を完全に間違えているのである．「2008年秋期に情報処理技術者試験の構成を変更しITSSやETSS，UISSと統合して，新しい共通キャリア・スキルフレームワークを構築する」という結論ありきで，後付けで「現状と課題」についての分析をつけ加えているから，内容がちぐはぐで説得力のないものになっているのである）．報告書案には確かに「長時間労働が常態化しており，勤務状況が厳しい」ことは述べられている（p.12）が，扱いは小さく，具体的な解決策も述べられていない．

1.1.1 学生や求職者，新人ITエンジニアに与える影響 .

現在の学生や求職者から見たIT産業の仕事の持つイメージはよいものであろうか．本来ITが持っている夢や可能性の部分はうまく伝わっているだろうか．

長時間の残業（朝早くから夜遅くまで働き，帰ったら寝るだけ）や休日出勤の常態化，厳しい納期に終われる日々，システムは24時間365日完璧に動いて当たり前で，情報漏えいやシステム障害を起こせば会社やお客様やマスコミに厳しく非難される，など「キツイ仕事」のイメージのほうが強くなっていないだろうか．いくらコンピュータやITが好きな学生や求職者でも，このような業界の現状を見て，就職するのをためらうことはないだろうか．

それでも夢と希望を持ってIT業界に飛び込んでくる新人もいるだろう．だが，そんな新人がいきなり，運悪く，デスマーチ状態のプロジェクトに配属されたらどうなるだろう．常態化した長時間残業や休日出勤や，無理のあるスケジュールによるプレッシャーにより体も心も疲れ切ってしまうかもしれない．また，周りの先輩社員は皆とても忙しく，十分なサポートができないために新人は孤立感を持つかもしれない．そうなれば，新人は，心身の病を患い働けなくなるかもしれないし，IT産業に対する夢も希望も完全に失って離職することになるかもしれない．このことは本人にとっても大きな損失であるし，将来活躍するはずであった貴重な人材を失うことによる会社やIT産業全体にとっての損失も計り知れないものである．

1.1.2 現役ITエンジニアに与える影響 .

長時間労働が一過性のものであり，1年間のうちある時期だけ忙しいのならまだ我慢できるかもしれない．しかしながら，現実には1つのバージョンの開発が終わると次のバージョンの開発，1つのプロジェクトの開発が終わると次のプロジェクトの開発と，終わりが見えないまま忙しい状況が延々と続く職場も多いのである．忙しい状況が年中続くことは，ITエンジニアの心身の健康に重大な問題を引き起こし，その結果，うつ病などによる病気休職者や離職者が増えているのである（たとえばITpro「ITエンジニア必須のうつ病予防と治療の知識」第1回うつ病の増加は、IT業界から始まった http://itpro.nikkeibp.co.jp/article/NIP/20051014/222827/ では「ITエンジニアは，他の職種以上にうつ病になりやすい要因を数多く抱えて」いると述べている．報告書案がITエンジニアのうつ病やメンタルヘルスの問題に触れていないのは，現場を見ていないからではないだろうか？）．

病気休職者や離職者が増えれば，その現場に残されたITエンジニアらは同じ仕事を少ない人数でこなさなければならなくなり，さらに1人当たりの負荷が上がるという悪循環に陥ってしまう危険性がある．ここでさらにITエンジニアを志望する新人の供給までもが減少してしまうと，その現場の人材不足はさらに悪化し，その悪循環はますます深刻なものになる（近年マスコミで報道されている，産婦人科医や小児科医の不足の問題と同じ構造の問題になってしまう）．

現場での人材不足により，スキルの低い者に無理に難易度の高い仕事を割り当てざるを得ない事態も懸念される．そうなると，ソフトウェアのバグや脆弱性の発生や，運用でのオペレーションのミスなどが多発し，情報システム全体の信頼性やセキュリティの低下を引き起こす危険性がある．このことは，情報漏洩やシステム障害などの重大な社会問題をひきおこし，IT産業の社会からの信頼を失わせ，「産業としての魅力」をさらに損なう原因になりかねない．

また，ITエンジニアがスキルを高めていくためには，仕事を通じて経験から学ぶこと（OJT）と同時に，研修やネットや書籍や資格試験の勉強などで知識を広げること（OFF-JT）との両方が欠かせない．OFF-JTだけで実務に役立つ知識を身につけることは難しいことはもちろんであるが，OJTだけに偏ってしまうことにも問題がある．朝早くから夜遅くまで日々の仕事に追われ，研修も受けられず，帰ったら寝るだけの生活をしているITエンジニアがOFF-JTで知識を広げスキルを向上することができるだろうか．そんな生活をしているITエンジニアの知識は自分が関わっている業務や手法，言語，製品などに偏ったものとなる．そして，自分の知っている範囲にだけ詳しいが他のことは知らない，つぶしのきかない「専門バカ」になり，ますますその状態から抜けられなくなり，知識，技能と実務経験を兼ね備えた「高度IT人材」へのステップアップは極めて難しくなる．したがって，まずはITエンジニアを過重労働から解放しなければ，いくらキャリア・スキルフレームワークなどを整備しても，それは「絵に描いた餅」にしかならないのである．

1.2 評価とモチベーションの問題 .

たとえITエンジニアの勤務状況が厳しくとも，仕事が楽しく，やりがいを感じられるものであれば，あまり辛さや苦しさを感じることもないのかもしれない．しかしながら，現実には，楽しくやりがいを感じながら仕事をしているITエンジニアはそう多くはないのではないだろうか．

これは「新たなフロンティアを開拓する発展性のある業務が少ない（p.12）」ことも大きな原因の1つであろう．しかしながら，私はもう1つの大きな理由として「ITエンジニアががんばりを十分に評価され，報われていない」という問題を指摘したい．いくらがんばっても正当に評価され，報われないのであれば，ITエンジニアは働く喜びを得られず，仕事はただ疲れるだけのものとなり，そのことがモチベーションの低下や心身の病をひきおこしてはいないだろうか．そしてそのことが「産業としての魅力の低下」の大きな原因になっていないだろうか．

1.2.1 お客様からの評価の問題 .

ITエンジニアに限らず，働く者が最も喜びを感じるのは「お客様に感謝されること」であり，お客様の感謝こそが最大の報いであろう．しかしながら，ITエンジニアの大部分は，そんな機会にはなかなか恵まれないのではないだろうか．これは「IT産業がお客様の期待に十分に応えられていない」「ITエンジニアのうち，お客様と直接接する機会を持つ立場にある者が少ない」という2つの問題があるからである．

第1の問題は，つまり，開発や運用の段階で工期遅れ，予算超過，品質上の問題などのトラブルを起こしたり，当初計画の通りに経営上の威力を発揮できなかったりして，お客様の期待に応えられないシステムが多いことである．たとえばITproの「動かないコンピュータ Forum（http://itpro.nikkeibp.co.jp/ugokanai/index.html）」で取り上げられるような事例のことである．

「動かないコンピュータ」が生まれる要因は複雑で，様々ではあると思うが，新人の頃の私の経験からすると「上流工程での要件分析やプロジェクトマネジメントがもっとしっかりしてくれれば防げる事例が多いのでは」と思うのである．「曖昧だったり，変更が繰り返さたりする要件定義」「無理のある開発スケジュールや人員計画」などの上流工程の仕事で失敗があると，いくら下流工程のITエンジニアが努力しても，その失敗を帳消しにし，お客様に満足して頂けるシステムを作ることは不可能である．長時間残業や休日出勤までして一生懸命に開発したシステムが「動かないコンピュータ」となり，お客様に感謝されず，報われないのであれば，下流工程に従事するITエンジニアの苦労は，まさに「骨折り損のくたびれもうけ」である．

もちろんコーディングでのバグや脆弱性の作り込みやテストの不足など，下流工程の仕事に問題がある「動かないコンピュータ」の事例もあるだろうが，その問題も，スケジュールや人員計画などのプロジェクトマネジメントに無理がなければ防げる場合も多いのではないだろうか．

新人だった頃の経験からさらに思い出してみる．そのような「動かないコンピュータ」を生む問題プロジェクトの下流工程の現場にいると，度重なる仕様変更や上流工程の遅れによるスケジュールの幾度もの遅延，そのしわ寄せによるプログラミングやテストの工程での常態化する長時間の残業，そしてその現場に蔓延する疲労感や士気の低下，不満の蓄積などから，新人であっても「なにかおかしいぞ」という雰囲気に気づくことが多いと思う．しかしながら，会社員である以上，会社や上司の命令には逆らわずにその仕事を続けなければならない．こうなると，配置転換を要求したり転職を考えたりしてその場から逃げ出すことばかり考えるようになってしまうか，喜びを感じられないまま「仕事だから」と割り切って目の前の報われない仕事を淡々とこなすようになってしまう．いずれにせよ，これではモチベーションを維持するのは難しい．

第2の問題は，つまり，システムの開発や運用が成功し，お客様から喜んで頂いた場合でも，役職者やアカウントマネージャや一部のSEなどを除けば，ITエンジニアの大部分は直接「お客様の喜ぶ顔」を見る機会になかなか恵まれないことである（逆に，情報漏えいやシステム障害などのトラブル時にお客様やマスコミから怒られる機会は案外，多いかもしれない）．また，複雑化し，多重に連結されたシステムのモジュールの1部分を元請けの会社や上司から言われたとおりに組み立てているだけのITエンジニアには，お客様の顔を想像することすら困難である．とくに，元請け～下請けの構造が何層にもなっている場合，この問題は非常に深刻である．

この2つの問題により「お客様に感謝されている」「自分の仕事は報われている」という実感を持てずに，ITエンジニアはモチベーションを保つことができるだろうか．そんな状態で自分の仕事に誇りを持ち，同じ会社や現場で長く勤めて知識や技能や実務経験を積んで「高度IT人材」にステップアップしていきたいという意欲を持ちつづけることができるだろうか（中には「経営者や上流工程がしっかりしないんだから駄目なんだ！だから自分がやる！」と考え，ステップアップをめざす強者も現れるのかもしれないが）．

1.2.2 会社からの評価の問題 .

ITエンジニアが会社員である以上，働く喜びを感じ，モチベーションを高めるもう1つの大きな要因は，会社からの給料やボーナス，さらには人事評価や昇級・昇進で報われることである．しかし，ここ数年間で多くの企業で導入されてきた「成果主義」は，（総人件費の抑制には役立っているかもしれないが）社員のモチベーションを向上させることに役立っているだろうか．評価に納得せず，不満感と絶望感から「どうせがんばっても正当に評価してもらえない」とかえってモチベーションを下げてしまう社員を増やしていないだろうか（私は，うつ病で休職するまでの数年間，ボーナスが出るたびに「またC評価か」と評価に納得できず，モチベーションを下げていたものだった）．

この問題はIT業界に限らず，成果主義を導入した会社に共通する問題かもしれない．しかし，他の工業と違って「自分が作った物を自分の目で見て確認して喜びを得ることが難しい（たとえば，橋を建設しているエンジニアなら，完成した橋を見ることで仕事の喜びを得られるかもしれないが，直接は目で見えないソフトウェアやサービス（やその一部分）を作っているITエンジニアは，自分が作ったものを目で見て確認して喜びを得ることは難しい場合が多い）」というITエンジニア特有の問題もある．やはり，自分が会社から評価されていると感じられることは，ITエンジニアがモチベーションを高めるのに必要なことなのである．

1.3 情報処理技術者試験とITSS，ETSS，UISSの問題 .

報告書案では「情報処理技術者試験については、試験区分の見直しや試験回数の増加等の制度改革のほか、ＩＴスキル標準（2002 年策定）との整合化を求める声が高まりつつある」「ＩＴスキル標準については、大手企業では普及してきたものの、企業ごとにその活用策や準拠の程度が異なる等不整合が顕在化しており、共通化の要望が高まっている」（p.13）などの，情報処理技術者試験とITSSやETSS，UISSの問題を指摘している．しかしながら，これらの問題は，先に述べた「過重労働の問題」や「評価とモチベーションの問題」に比べれば，重要性も緊急性も低い問題であると私は考えている．それどころか，これらの試験や認定制度の根幹部分を拙速に変更することは，むしろ弊害のほうが大きいのではないかという懸念を私は持っている．

1.3.1 情報処理技術者試験 .

情報処理技術者試験については，確かに厳しい批判や改善要望が多く出されているが，その一方で，30年以上にわたって続いてきた，高い評価と信頼を得ている試験であることもまた事実である．そのため，とくに制度の根幹部分である試験区分やその評価基準の変更については，慎重に時間をかけて検討し，少しずつ行うべきであるというのが私の考えである．これは，短期間に頻繁に試験の根幹部分が変化する試験になってしまうと，それまで情報処理技術者試験が得てきた高い評価と信頼を失うことになりかねないからである．

現実に，情報処理技術者試験は，（減少傾向にはあるが）毎年多くの受験者を集め，合格者には多くの企業が手当や一時金を支給している（ITpro｜取得時のご褒美が多い資格は何？ 20万円以上は技術士とシステムアナリスト http://itpro.nikkeibp.co.jp/article/COLUMN/20051109/224284/）ことからも，企業や個人からの高い評価が伺える．

また，情報処理技術者試験の試験勉強によって得られる，特定のベンダの製品や技術に偏らない知識や思考法は，実践の場でも長い間にわたって役に立つ有意義なものである．さらに，近年は，情報セキュリティ関連の試験区分の追加，個人成績の照会や採点基準・解答例の公表などの継続的な改善を積極的に行っており，ITエンジニアのスキルの向上にますます役立つ試験になってきていると私は評価している．

しかしながら，報告書案による，「2008年秋期試験から実施することを目標とする」大幅な基本構成の変更（pp.24～26）は，これから情報処理技術者試験を受験しようとする者を大いに不安にさせるものである．そもそも「試験区分や対象領域、名称等については、今後更なる検討が必要」という部分も残っているのに，これから1年半の間ですべての試験区分を1度に変更し，新しい試験の内容を受験者に十分に周知し，実施することは，時間的に可能なのであろうか．

また，これまで情報処理技術者試験の資格を取ってきた者にとっては，報告書案で，受験者がいままで取得してきた資格の扱いがどうなるのかまったく言及されていないのが非常に不安である．資格の名称や位置づけが大きく変わることで，これまでの資格は「時代遅れ」のものとなり，認知度も評価や信頼も急速に失われてしまうのだろうか．さらに，もしも今後もこのような変更が頻繁に行われるようになってしまったら，受験者は安心して情報処理技術者試験を受験することができなくなってしまわないだろうか．

1.3.2 ITSSとETSS，UISS .

とくにITSSが普及する以前において，ITエンジニアにとって，キャリアパスが見えないことは，「このままこの仕事を続けて将来は大丈夫なのだろうか」という不安を抱かせる要素であったのは確かである．私も，ITSSが発表されたときや，（休職中であったが）ITSSをベースにした社内でのスキル認定制度が開始されたときは，これで自分のキャリアパスを描き，安心してスキルを高めて成長していくことができるのではないか，という期待と希望を持っていた．

ITSSは2002年の初版の公表から4年後の2006年には，わかりやすさと使いやすさを追求するという方針に基づき改訂されたITSS V2が公表されている．私が勤務する企業も含めて，多くの企業が現在の版のITSSをベースにしたスキルの評価制度を構築し運用しており，ITSSの普及は徐々に始まっているといえるだろう（私が休職していて，実際にITSSをベースにした社内制度を体験していないので，効果はまだ実感できていないが）．

それに比べて，ETSS，UISSについては，私の勤務する会社で導入されていないこともあり，どの程度普及しているかはよくわからない．ただ，ETSSは2005年5月，UISSは2006年6月と，まだ「バージョン1」の段階であり，完成度や普及度はITSSより低く，まだこれから熟成していくべき段階かもしれない．したがって，ETSSやUISSと，ITSSやさらには情報処理技術者試験との統合については，より完成度や普及度が上がった「バージョン2」以降に検討するのでも良いのではないかという疑問を私は持っている．

（２）解決の方向性 .

以上に挙げた3つの問題の解決に向けて，最優先で取り組まなければならない問題は「過重労働の問題」である．「評価とモチベーションの問題」も重要な問題であるが，解決はより困難で時間がかかるかもしれない．「情報処理技術者試験とITSS，ETSS，UISSの問題」については，報告書案で述べられているような拙速な変更は避け，改善には慎重であるべきである．というのが私の基本的な意見である．

2.1 過重労働の問題 .

過重労働の問題は，個々のITエンジニアの自己責任ではどうにもならない問題である．国，経営者（会社），そしてプロジェクトマネージャがそれぞれの責任を果たし，最優先の課題として全力で解決に取り組まなければならない問題である．

2.1.1 国の責任 .

まず，国が，長時間労働を削減する政策を率先してすすめるべきである．具体的には，定時で働けば10人でできる仕事を7～8人が残業や休日出勤してこなすほうが企業に有利になるような法制度を改めるべきである．一方で常態化した長時間残業や休日出勤に苦しむ労働者がいて，もう一方でろくな仕事に就けないニートやフリーターがあふれているという現状は，明らかに国の無策によるものである．

また，長時間残業や休日出勤を減らすことは，国民の健康（とくにメンタルヘルス），および出生率や子育ての問題（ワーク・ライフ・バランス）にもプラスになるので，国としては最優先で取り組まなければならない課題のはずである．

2.1.2 経営者の責任 .

サービス残業や偽装請負の撲滅，デスマーチの撲滅，長時間残業や休日出勤の大幅な削減を，経営者が自らの責任で実行していくべきである．会社全体の人員調整や業務量の調整（適材適所で十分な人数の人員配置をする，無理な仕事は断るなど）は，経営者でなければできないことだからである．過重労働の問題を改善することなく，まともな給料も払えず，工期遅れ，予算超過，品質上の問題などのトラブルを起こしてお客様にも満足してもらえず，株主に利益を還元できないような無能な経営者は即刻，退陣すべきである．

サービス残業や偽装請負の撲滅について，私が勤務している会社とその組合が積極的に取り組んでいることについては評価して良い（当たり前のことをやっているだけとも言えるが）と思っている．しかしながら，まだまだサービス残業や偽装請負を撲滅できていない企業が多いという話も聞く．書面上では残業や休日出勤が減っていても，サービス残業がそのぶん増えていたのでは，問題はいっそう悪くなるだけである．サービス残業や偽装請負の撲滅も，経営者が責任を持って取り組むべき課題である．

2.1.3 プロジェクトマネージャの責任 .

工数の見積もりの誤りによる人員の不足や開発期間の不足，特定の人員への負荷の偏りなどによるデスマーチによる過重労働の発生は，真っ先にプロジェクトマネジメントの不備や欠落に原因を求められがちである．そして，優秀なプロジェクトマネージャの育成が急がれることも確かである．しかしながら，プロジェクトマネージャ個人個人のスキルを向上しても，デスマーチをある程度は減らすことはできるだろうが，完全に撲滅することは難しいであろう．お客様都合での急な仕様の変更，キーとなる人員の急病や離職などによるプロジェクトからの突然の離脱など，プロジェクトマネージャ個人の手腕ではどうしようもない想定外の事態はつねに起こりうるからである．

そういった危機に陥った場合は，より上位の役職者や経営者のサポートがなければならない．そうでなければ，結局，「忙しいのはわかるが，人は増やせないし仕事は減らせないから残業や休日出勤で無理してでもやってくれ」ということになり，過重労働の問題は何も解決されないのである．

つまり，上位の役職者や経営者，そして会社全体がプロジェクトマネージャを全面的に支える体制があって，はじめてプロジェクトマネジメントが機能するのである．その体制がなければ，プロジェクトマネージャはメンバと会社の板挟みとなり，苦しみ，疲弊してしまうだろう．そして，よほどの好待遇と高い権限が与えられるのでもなければ，プロジェクトマネージャをやりたがる者など誰もいなくなってしまうだろう．

2.2 評価とモチベーションの問題 .

報告書案のとおり，日本のIT産業には「新たなフロンティアを開拓する発展性のある業務が少ない」（p.12）ことは確かである．多くのITエンジニアにそのような業務を与えることができれば，産業としての魅力は増し，ITエンジニアのモチベーションは上がるに違いない．しかし，現実にはそのような業務を大量に創出するのは難しいだろう（私は20代の頃は研究開発の職種を志望していた時期もあったが，そのような仕事は少なく，希望は叶わなかった）．私のコメントでは，ITエンジニアの大部分を占める「地味な」仕事に携わる者のモチベーションをどう高めるか，そして，その「地味な」仕事の産業としての魅力をどう高めるかを考えていきたい．そのような「地味な」仕事をしているエンジニアこそが社会のITインフラを支える重要な役割を担っているのだから．

2.2.1 お客様からの評価の問題 .

現状認識の項で示した「お客様の評価の問題」を解決するには「お客様の期待に十分に応えられるシステムを構築し，運用すること」と，「お客様と直接接する機会を持つ機会が少ない者も含めたすべてのITエンジニアにお客様の喜びが伝わるようにすること」を地道にやっていくしかないだろう．

まずはお客様自身が明確なIT戦略を立案し，ITベンダに「丸投げ」するのではなく，「システム化で何をしたいのか」という要件定義をしっかり行うこと（これがなければ，いくらITベンダががんばってシステムを作っても「こんなはずではなかった」ということになる），そして，ITベンダは上流工程でそのお客様要件をしっかりと受け止め，システムを設計していくことが必要である．そして，スケジュールや人員計画に無理のないプロジェクトマネジメントを行い，下流工程にしわ寄せが来ないようにし，納期，予算，品質のいずれの面においても合格点のシステムを構築し，運用すること．これらは「当たり前のこと」であるが，すべての点で合格点に達するプロジェクトを成功させるのはなかなか難しいのが現状ではないだろうか．しかしながら，これらの「当たり前のこと」ができることは，「動かないコンピュータ」を撲滅し，お客様に喜んで頂くために必要なことである．

いっぽう，システム開発が成功し，お客様に喜んで頂いている場合において，お客様と直接顔を合わせる立場にない大多数のITエンジニアに「お客様からの評価」を伝えることは，非常に難しい問題である．せめて，お客様の声を直接聞く立場にある会社の経営者や役職者，アカウントマネージャやSEなどが，その指示の元で日々働く大多数のITエンジニアに「その仕事がどれだけお客様に役になっているか，感謝されているか」を伝え，仕事のやりがいを理解させ，モチベーションを高めていくよう努めていくしかないだろうか．

2.2.2 成果主義とモチベーションの問題 .

会社が社員を評価するため成果主義を導入するにあたっては，評価する立場にいる管理者や企業の人事部門は，人が人を評価するというのは，難しく，時には非常に残酷なことであるということを十分にわきまえ，相当の覚悟を持ってやらなければならない．そして，評価は，評価される側の社員の側から見て十分な納得性・公平性・透明性を持ったものでなければならない．

社員が一生懸命やってきた仕事が正当に評価されれば，モチベーションが上がり，力を発揮し，成長し，成果を上げてさらに評価が上がってよりよい機会とポジションを得て，そこでまたモチベーションが上がり…と「正のスパイラル」が働く可能性を，成果主義の本来の考え方は持っている．さらにはその周囲の社員も「じゃ，自分もがんばれば評価されるんだ」と考えるようになり，会社全体のモチベーションが上がる可能性もある．しかし，仕事が正当に評価されなければ，その社員は「どうせがんばっても評価されないんだ」と思ってしまい，モチベーションが下がり，力も発揮できず，成長できず，成果も上げられずさらに評価が下がってよりよい機会もポジションも得られなくなり，さらにモチベーションが下がり…という「負のスパイラル」に陥ってしまう危険性も成果主義は持っている．さらにはその周囲の社員も「じゃ，自分もがんばっても駄目なんだ」と考えるようになり，会社全体のモチベーションまで下がってしまうと，さらに絶望的である．

成果主義の「負のスパイラル」に陥り，モチベーションが下がりきった会社や社員に，重大な欠陥がなく信頼性の高いシステムやサービスや，新しい価値を生み出す革新的なシステムやサービスを生み出すことを期待できるだろうか．さらに，モチベーションが下がりきった社員が，システム障害や情報漏洩などの重大な事故や犯罪を引き起こす危険はないだろうか．

成果主義の「失敗」についてはすでに様々な場で論じられており（NIKKEI NET Biz-Plus 連載企画成果主義導入後の人事部の課題第1回「成果主義で社員のモチベーションは上がるのか？」http://bizplus.nikkei.co.jp/genre/jinji/rensai/kadai.cfm?i=20051215dai01j3 など），多くの課題が指摘されている．すでに私が勤めている会社も含めて多くの会社で制度の見直しが少しずつ始まっている．問題の解決はまだ見えてきていないが，改善に向けた努力を怠ることがあってはならない．

2.3 情報処理技術者試験とITSS，ETSS，UISS .

キャリアパスを明確にし，「高度IT人材」を育成するために，今後，情報処理技術者試験とITSSやETSS，UISSとの整合をどうとっていくかは確かに重要な問題ではあるが，難しい問題である．この点については他の多くのコメントや提案が寄せられるだろうが，唯一正しい解決策が一朝一夕に見つかることはないだろう．ただ，私が1つだけ持っている意見は「情報処理技術者試験やITSSやETSS，UISSは拙速に変更せず，現行の資格や版との移行性，整合性に配慮しつつ時間をかけてゆっくりと改善していくべき」ということである．

同時に，ここで「情報処理技術者試験やITSSやETSS，UISSを改善すれば「IT人材問題」はすべて解決する」という幻想を抱いてはいけないことを指摘しておきたい（たとえば，TOEICや英検を改善すれば，みんな英語を話せるようになるのだろうか？）．

2.3.1 情報処理技術者試験の大幅な変更の問題 .

情報処理技術者試験について，確かに，時代に合わせて試験の内容を改善していくこと自体は間違ってはいないし，先に述べたとおり，現実に少しずつ有用な改善を進めているのである．しかしながら，報告書案に示されているような，試験の根幹部分である試験区分やその評価基準を大幅に変更することについてはもっと慎重であるべきだというのが私の意見である．

ここで，比較のため，日本で受験者が多い試験である（そして，私も含めて多くのITエンジニアが受験している）TOEICや実用英語技能検定（英検）において述べてみると，TOEICは2006年5月にリニューアルを行い（http://www.toeic.or.jp/toeic/about/what/renewal.html）一部の出題形式を変更しているし，英検は時代が進むにつれ受験級の追加や問題形式の変更（http://www.eiken.or.jp/step/index.html）を何度か行っており，最近では2004年の1級・準1級へのライティング問題の追加など（http://www.eiken.or.jp/eikentimes/tokusyu/0403.html）を行っている．

しかしながら，リニューアルしたTOEICではEquating（スコアの同一化）と呼ばれる調整を行うことで，リニューアル以前のTOEICとでは，評価基準は変わらないとしている．また，英検も，それぞれの受験級の審査基準（http://www.eiken.or.jp/info/level/index.pdf）については（私が知る限りでは）大きな変更は行っていない．

こうして，時代に合わせたリニューアルを慎重に行いつつも，試験の根幹部分である試験区分や評価基準を大きく変えずに続けてきたことが，TOEICや英検が多くの個人・学校・企業などにおいて英語の実力を計るための基準の1つとして，長年の間にわたって高い評価と信頼を培ってきた理由ではないだろうか．

これらのTOEICや英検が行ってきたリニューアルや，最近に情報処理技術者試験が行ってきた改善と比べると，報告書案にある情報処理技術者試験の大幅な変更は全く異質なものである．この変更は，試験の根幹部分である試験区分やその評価基準を大きく変えてしまう「破壊的」なものである．この大幅な変更により，情報処理技術者試験は，それまで培ってきた個人・学校・企業からの，情報処理技術者の知識や技能を認定する基準としての評価と信頼を失うことになりかねない．評価や信頼を失うことは，情報処理技術者試験それ自身にとっても，情報処理技術者の資格を取得してきた者にとっても大きな損失である．

とくに高度の試験は合格率数%の難関であり，2回，3回と繰り返し挑戦してやっと合格するのが普通である．試験区分や評価基準といった試験の根幹部分が頻繁に大幅に変わるような試験になってしまったら，受験者は安心して同じ試験に挑戦し続けることができなくなってしまうだろう（私は2000年春にプロダクションエンジニアの試験に挑戦したが不合格で，翌年に突然試験がなくなったのでがっかりしたことを覚えている）．

2.3.2 ITSSとETSS，UISS，そして情報処理技術者試験との整合化の問題 .

ITSSやETSS，UISSについても，改訂は持続的，段階的に行い，過去の版との移行性，整合性に考慮すべきである．すでに，私が勤める企業も含めて多くの企業が現在の版のITSSをベースにしたスキルの評価制度を構築し運用しているのだから，改版の際には，前の版からの移行がスムーズに進むような配慮が必要ではないだろうか．報告書案に示されているITSS，ETSS，UISSとさらには情報処理技術者試験を一気に統合する共通キャリア・スキルフレームワークを構築するという急速な改訂を行うと，従来の版でキャリアパスを思い描いてきた企業や個人は，キャリアパスを一から描き直さなければならなくなり，そのことが大きな不安や混乱を引き起こさないだろうか．

（３）具体的施策 .

「IT人材問題」の解決のためには，報告書案で示されている具体的施策の優先順位や進め方は，全面的に見直さなければならない．まず最優先で「過重労働の撲滅」，つぎに「評価とモチベーションの改善」に取り組まなければならない．そして「情報処理技術者試験とITSS，ETSS，UISSの整合化」は，他の2つに比べて優先順位が低い問題であり，同時に，報告書案で示されているこの施策の進め方についても重大な疑問がある．この施策については拙速な実施を避け，時間をかけた慎重な検討を進めるべきである．

3.1 過重労働の撲滅 .

過重労働の問題を改善し，IT産業の魅力を高めることで，やる気と能力のある若者をたくさん呼び込み，同時に離職者や病気休職者を減らすことこそが「IT人材問題」の最優先にして最重要の解決策である．国や経営者は，サービス残業や偽造請負を撲滅し，常態化した長時間残業や休日出勤を削減し，そして病気休職者や離職者の数を減らすことを，具体的な施策，時期，数値目標を掲げて最優先で取り組むべきである（情報処理技術者試験の基本構成を変更する時期の目標を定めることより，はるかに重要なことである）．「日本を，世界で一番ITエンジニアが笑顔で元気に働ける国にする」くらいの意気込みでやってもらいたい．

そのためには，まず，国やIT業界は，ITエンジニアによる過重労働の実態を正確に把握する調査を行う必要がある．調査し，現状を把握することによって，はじめて具体的な施策，時期，数値目標を定めることができるからである．調査対象には，大企業の社員だけなく，中小の企業の社員や請負・派遣の業務を行っている者をも含めることは当然である．そして，本来はあってはならないサービス残業や偽装請負がどれだけ行われているかについてもきっちり調査すべきである．

さらに，この調査では，過重労働が発生する「真の原因」を追究しなければならない．忙しい理由として誰もが真っ先に思いつくのは「人が足りない」ことだろうが，本当に日本全体のITエンジニアの絶対数が足りないのだろうか．それとも，国や経営者が本来は有効に活用されるはずの人材を活用しきれていないのだろうか．あるいは，偏った人員配置や無理のあるスケジュールや，効率の悪い開発・運用手法などが無用な忙しさを生み出しているのだろうか．

この「真の原因」が何であるかによって，有効な具体的施策は異なるものになる．人材を活用しきれていないのであれば，まずはその人材をどう有効に活用するか，国や経営者が知恵を絞らなければならない．人員配置やスケジュールや開発・運用手法の問題なら，プロジェクトマネジメントの強化や開発・運用手法の改善が急務となる（もちろん，これはITエンジニア個人や現場の努力だけではなく，国やIT業界や会社全体としての取り組みが必要である）．そして，本当に人材が足りないなら，即戦力となる人材の育成を進める施策を進めると同時に，コミュニケーションの困難さや技術流出やセキュリティなどのリスクを考慮しつつ，オフショア化を進めることも必要かもしれない（逆に，「真の原因」の追究がないまま安易にオフショア化を進めても，単に日本のIT業界の問題点を「輸出」するだけではないだろうか）．

3.2 評価とモチベーションの問題の改善 .

ここでは，これまで述べてきた「お客様からの評価の問題」「成果主義の問題」を改善するために，具体的にどのような施策を実現するべきかの，私の考えを述べる．

3.2.1 お客様の評価の改善 .

先に，IT産業がお客様の期待に応えられるようになるための方策として「お客様自身が「システム化で何をしたいのか」という要件定義をしっかり行うこと」「ITベンダは上流工程でそのお客様要件をしっかりと受け止めてシステムを設計すること」「スケジュールや人員計画に無理のないプロジェクトマネジメントを行うこと」を挙げたが，いずれも，それを可能にするには，ユーザ企業側も含めた人材育成と，その人材育成を可能にする体制作りが必要である．

とくに，報告書案の新しいキャリア・フレームワークにおける「ストラテジスト」「システムアーキテクト」「プロジェクトマネージャ」に相当する人材の育成が重要になってくる．そのため，ユーザ産業も含めた「高度IT人材」の育成と，その育成のための「高度IT人材育成プラットフォーム」の構築が必要という方向性においては，私は報告書案の考えに基本的に賛成である．ただ，具体的にどのように「高度IT人材育成プラットフォーム」を構築し，運用していくかという課題は残っている．

そして，先に述べたとおり，お客様と直接顔を合わせる立場にある役職者やアカウントマネージャやSEは，その指示を受けて仕事を行うITエンジニアに，その仕事によってどれだけお客様が感謝しているかを説明し，理解させるよう努めることが必要である．ただ機械的に「はい，これがあなたの仕事です．納期までにやりなさい」と言われただけでは，ITエンジニアはモチベーションを高めて仕事に取り組むことはできない．関係者全員が自分の仕事の意義について納得し，お客様に満足して頂くという目標に向けて，チームとして一丸となって取り組んでいける雰囲気を作ることが必要である．

また，IT業界自体が，情報漏洩やシステム障害などの負の側面だけではなく，ITが社会を支え，世の中の役に立っている正の側面を社会にもっと知って頂くプロモーション活動をもっと行うことも考えてもよいかもしれない．そのような活動はIT業界の評価を高め，「産業としての魅力」を学生や一般の人に広告するだけではなく，ITエンジニア自身が自分の仕事への自信と誇りを取り戻し，モチベーションを高めることにつながるかもしれない（もちろん「誇大宣伝」になってはいけないのはいうまでもないが）．そして，私たちITエンジニア個人個人も，日頃の愚痴を言うのを少し我慢して，もっとIT業界の持つ夢や可能性について語るべきであろうか？

3.2.2 成果主義の改善 .

成果主義については多くの企業が見直しを進めているが，今後も，評価による「正のスパイラル」によって社員や会社全体のモチベーションが上がるような改善を続ける必要がある．そして，つねに改善に伴う効果の測定を行って「正のスパイラル」が実現できているかを確認しつつ，制度をよりよいものに変革していく不断の努力をしていかなければならない．

成果主義を良い方向に動かしていくには，まず，会社の経営者や人事部門と1次評価者，2次評価者が評価基準の「軸」を合わせ，「どうがんばれば評価されるのか」を社員に明確に示さなければならない．たとえば，1次評価者（課長）は「早く仕事を進める」ことを重視し，2次評価者（部長）は「緻密に仕事を進める」ことを重視するとどうなるだろう．早く仕事を進めると2次評価者に「もっと緻密に」と言われ，緻密に仕事を進めると1次評価者に「もっと早く」と言われ．どちらに従って仕事をしても片方の評価者から評価を下げられるのなら，社員は「どうがんばっても評価してもらえない」と落ち込むことになりかねない．そうなると，結局，評価されるのは実績や能力ではなく，両方の評価者に上手にゴマすりができる「世渡りの上手さや外面の良さ」となってしまう可能性もある．これではその社員もその周りの社員も成果主義への不信感を募らせ，モチベーションを高めることはできなくなってしまう．

また，人事評価を行う評価者（上司）の，被評価者（部下）を評価するスキルを向上することも必要である．評価しだいで，被評価者は「次はかんばるぞ」とモチベーションを高める可能性もあれば，「やっぱり自分は評価されないんだ」とモチベーションを下げる可能性もあるからである．

評価者のスキルとして，半期に1度，あるいは年に1度の面談などによる被評価者からのアピールだけではなく，ふだんからの地道な仕事ぶりをきちんと観察し，評価していくことが大切である．そうでなければ「実際に本業で成果を上げた社員」よりも「面談で上手に成果をアピールした社員」が評価されることになり，社員が本業をおろそかにして面談でのアピールにばかり熱心になってしまうという本末転倒した事態になりかねない．

さらに，評価者には，仕事の「量」だけではなく「質」をも評価するという困難な課題がある．もし評価者がたくさん残業している社員に「がんばっているから」と一律に高い評価をしてしまうと，社員の間では高い評価を求めて長時間残業をすることが蔓延し，先ほどから述べてきたIT産業の最大の問題である過重労働の問題を悪化させてしまうことになりかねない．逆に，育児や病気などの理由で短縮勤務をしている社員に対して「たくさん働かないから」と一律に低い評価をしてしまうと，社員は短縮勤務の制度を使いづらくなってしまうだろう．

3.3 情報処理技術者試験とITSS，ETSS，UISSの整合化 .

私も，情報処理技術者試験とITSSやETSS，UISSとの整合化は，いずれは検討すべき課題であろうと思う．しかしながら，報告書案で示されている，情報処理技術者試験とITSS，ETSS，UISSを統合して共通キャリア・スキルフレームワークを構築するという方針とその進め方はあまりに性急すぎ，また施策を実行する順番が完全に間違っていると指摘しなければならない．

報告書案では，「（新たな）情報処理技術者試験については、共通キャリア・スキルフレームワークとの整合化を図りつつ（中略）2008 年度秋期試験から実施することを目標とする」と述べている（p.24）．その一方で，2007年夏を目途に産学官協議会を立ち上げ「高度IT人材像の精緻化」「実践的な高度ＩＴ人材の育成手法の確立と推進」を審議し，「2008 年度中を目途に、上記検討の中間整理をとりまとめる」としている（pp.29-30）．また，報告書案には「レベル４以上の評価については、レベル判定に関するガイドラインを策定する（p.23）とあるが，そのガイドライン策定の時期は明確になっていない．

しかし，人材像やガイドラインが精緻化される（2009年3月までに中間整理？）以前に，高度IT人材の知識や技能を問う試験問題を2008年の秋期試験（2008年10月）で出題することができるだろうか．「2008年秋期」という目標を無理に達成しようとすれば，精緻化される前の，中間整理すらされていない人材像やガイドラインをもとに試験問題を作ることになる．そして，もしも，翌年以降にできあがったガイドラインや人材像が当初のものと大きく変わったものになれば，試験の構成や出題内容もまた大きく変わることになる．その結果，情報処理技術者試験の内容は短期間で頻繁に変わる不安定なものとなり，受験者は安心して試験を受けることができなくなってしまう．そして，情報処理技術者試験は，その評価や信頼を大きく失うことになる．

したがって，情報処理技術者試験が得てきた評価と信頼を守るためにも，同時に受験者の無用な不安や混乱を解消するためにも，まず，新たな情報技術者試験を2008年度秋期試験から開始するという目標は即時に撤回すべきである．そして，産学官協議会での審議やさらには一般のITエンジニアらによるパブリックコメントなどをもとにした，レベル判定に関するガイドラインの策定や高度IT人材像の精緻化といった施策のほうを先に進めなければならない．

レベル判定に関するガイドラインの策定においても，成果主義の問題と同様に「人が人を評価する難しさ」の問題と直面せざるを得ないだろう．報告書案による「ガイドラインベースでの民間企業での自主的取組」「ハイエンドプレーヤー同士のピア・レビュー」（p.23）はうまく機能するだろうか．学歴や会社名や役職やその人の知名度やアピールの上手さだけではない，真の「実力」を公平に評価する仕組みを作ることができるだろうか．レベル判定の納得性・公平性・透明性が十分に確保されるしくみを構築し，運用することで，はじめて認定制度は信頼と評価を勝ち取ることができるだろう．制度を作り，あとは民間に任せておけばうまくいくというものではないだろう．

そして，情報処理技術者試験の構成変更やITSS，ETSS，UISSとの整合化については，レベル判定に関するガイドラインの策定や高度IT人材像の精緻化といった施策が進んだあとで，整合化のあり方そのもの（報告書案のように緊密に統合するのか，それとももっと緩やかな結びつきにするのか）も含めて，時間をかけて慎重に検討すべきである．慎重な検討を経たうえで，新しい共通キャリア・スキルフレームワークを構築するという結論になったとしても，その変更は，これまで認定してきた資格や認定の価値を否定するようなものであってはならない．また，新しい制度への移行の際には，十分な周知期間を設け，ロードマップを明確に示すことで，企業や個人が混乱することなく安心して移行できるようにする配慮が欠かせないだろう．

パブリックコメント

「高度ＩＴ人材の育成をめざして（案）」に対する意見
【ゆきんが提出したコメント】