目次Category
近年、ITエンジニアの需要の高まりとともに、その評価制度にも大きな注目が集まっています。しかしITエンジニアという職種は、その特殊性ゆえに一般的な職種の評価基準をそのまま適応することが難しく、多くの企業の頭を悩ませています。
本記事では、一般的な人事評価制度(※以下、評価制度と省略する)とITエンジニアの評価制度の違いについて解説するとともに、評価制度の見直しを行う上で注意すべきポイントについてご紹介します。
ITエンジニア評価の難しさ
そもそも評価制度とは?
評価制度とは、業績や会社への貢献度から社員を評価する制度を指します。
その評価制度の選定基準を定める上で忘れてはならないのが、「全社員に対して公平公正でなければならない」という点です。公平公正さが欠けてしまうと社員の不満が生じ、最悪の場合、離職に繋がる可能性があります。
「評価者」と「評価を受ける社員」、双方にとって納得のいく評価とするためには、下記4点を特に心掛けていくことが重要視されています。
【公平性】評価者の好き嫌いといった感情ではなく、会社の基準に則ること。
【客観性】評価者の独断的な(=主観的)な評価基準とせず、誰もが納得できる基準を設けること。
【透明性】評価基準とその根拠、評価をする上でのルールを全社員に周知すること。
【納得性】評価を下す際、適切な評価理由とフィードバックを行い、社員の今後の成長につなげること。
「ITエンジニアの評価」と「一般的な評価」との違い
ITエンジニアはプロジェクトはチームとして携わることが多く、求められる経験ノウハウや専門的なスキルも多岐にわたるため、一般的な評価基準に当てはめることが難しいと言われています。
ITエンジニアの多くはチームとしてプロジェクトに携わります。たとえそのプロジェクトが成功したとしても、個人としてどのような業績を上げたのか、貢献度を数値化することは容易ではありません。その場合は、業績と併せて、その社員が保有するスキルや経験値、勤務態度も考慮しなければなりません。
しかし、経験ノウハウやスキルが多岐にわたること、仕事への姿勢を定量的に判断することが難しいため、ITエンジニア用にカスタマイズされた評価制度を設ける必要があると言われています。
ITエンジニア評価制度で企業が抱える課題
評価者にもITエンジニアの知識が求められる
今まで別の部署にいた人が、まったく経験したことのない分野の上司に異動することもあるでしょう。こうした場合、ITエンジニアを評価する上司がIT知識やITエンジニアのマネジメント経験が無いことにより、適切に評価できないリスクが発生します。
ITエンジニアの上司や人事担当者といった評価者にも一定程度のIT知識が必要と言えるでしょう。
能力やスキルを可視化しづらい
「A社ではスキルが高く評価されたが、同じようなプロジェクトが進行しているB社ではさほど重宝されない」ということがITエンジニア業界ではよくあります。これは入社した企業や配属されるプロジェクト、役職などによって、求められるスキルやレベル感は異なることから生じるものです。
自社のITエンジニアのレベル感やスキルを理解し、それを自社の評価基準に落とし込むには、やはり評価者に一定程度のIT知識が必要と言えます。
評価のタイミングが難しい
ITエンジニアのプロジェクトは年単位で動いていることが多いため、短期的な期間での評価は時にITエンジニアの成果を正当に評価できないリスクがあります。
Aさん「半年間のプロジェクトに携わり、半年間で10という成果を出した。」
Bさん「1年間のプロジェクトに携わり、半年間での結果がゼロだったが、プロジェクト終了時点で100という成果を出した。」
上記ケースで半年経過時点の評価を行う場合、結果だけを見るとAさんは10という結果を出し、Bさんの結果はゼロとなってしまいます。しかし、このように期間中の結果だけを見て判断してしまうと、公平公正さが失われた評価となることは明らかでしょう。
プロジェクトが進行中で業績(結果)が出ていないITエンジニアを評価する際は、勤務態度などの業績(結果)以外の観点での評価が求められます。
客先常駐型エンジニアの適切な評価基準が分からない
SIer(エスアイヤー)と呼ばれるような客先常駐型ITエンジニアの場合、勤務態度を常に確認できる状況ではないため、評価は容易ではありません。同様に、社内のメンバーと関わらずに、1人で顧客対応している在宅型ITエンジニアも評価が難しくなります。
こうした場合、全てのITエンジニアが納得のいく評価制度を整えることも必要ですが、企業間のコミュニケーションによって状況把握に努めることが求められるでしょう。
ITエンジニアの評価基準はiCDを参考にしよう
ITエンジニアの評価基準を定める上で役に立つのが、独立行政法人情報処理推進機構(IPA)が提供する「iコンピテンシ ディクショナリ(iCD)」です。
iCDは、「タスクディクショナリ」と「スキルディクショナリ」で構成され、この二つの辞書で診断します。
・タスクディクショナリ:会社全体の組織や個人の機能や役割を診断する
・スキルディクショナリ:業務を支えるスキルや知識を診断する
今回はエンジニア1人ひとりの経験ノウハウやスキルに基づいて評価基準を考えたいので、タスクディクショナリを見ます。タスクディクショナリでは、ITエンジニアに求められるスキルを「メソドロジ(マネジメント能力)」、「テクノロジ(技術やノウハウ)」、「関連知識(業務的な知識)」、「ITヒューマンスキル(ビジネススキル)」の 4 つの大カテゴリに分類しています。
▼iCDについては、別記事で詳しく解説しているのでこちらもご覧ください▼
i コンピテンシ ディクショナリとは?仕組みと導入効果
メソドロジ(マネジメント能力)
組織形成や人材育成など、ITエンジニア業務に限定されない、汎用性、応用性の高いマネジメントスキルを集めたものとなります。
〇戦略 | *市場機会の評価と選定 |
*マーケティング | |
*製品・サービス戦略 | |
*販売戦略 | |
*製品・サービス戦略 | |
*システム戦略立案手法 | |
*コンサルティング手法 | |
*業務動向把握手法 |
〇企画 | *システム企画立案手法 |
*要求分析手法 | |
*セールス事務管理手法 | |
*非機能要件設計手法 |
〇実装 | *アーキテクチャ設計手法 |
*ソフトウェアエンジニアリング手法 | |
*カスタマーサービス手法 | |
*業務パッケージ活用手法 | |
*データマイニング手法 | |
*見積り手法 | |
*プロジェクトマネジメント手法 |
〇利活用 | *サービスマネジメント |
*サービスマネジメントプロセス | |
*サービスの設計・移行 | |
*サービスの運用 |
〇支援活動 | *品質マネジメント手法 |
*リスクマネジメント手法 | |
*ITガバナンス | |
*資産管理手法 | |
*ファシリティマネジメント手法 | |
*事業継続計画 | |
*システム監査手法 | |
*標準化・再利用手法 | |
*人材育成・教育・研修 | |
*情報セキュリティ | |
*チェンジマネジメント手法 |
テクノロジ(技術力やノウハウ)
ITエンジニアならではの専門的な技術をリストアップしたものになります。テクノロジは、さらに6つのカテゴリに分類されています。
〇システム(基礎、構築、利用) | *ソフトウェア技術 |
*Webシステム技術 | |
*データベース技術 | |
*プラットフォーム技術 | |
*ハードウェア技術 | |
*ネットワーク技術 | |
*クラウドコンピューティング技術 | |
*IoT技術 |
〇開発 | *システムアーキテクティング技術 |
*システム開発管理技術 |
〇保守・運用 | *ITサービスマネジメント業務管理技術 |
*ITサービスオペレーション技術 | |
*システム保守・運用・評価 | |
*障害修理技術 | |
*施工実務技術 | |
*ファシリティ設計技術 | |
*サポートセンター基盤技術 |
〇非機能要件 | *非機能要件(可用性、性能・拡張性) |
*セキュリティ技術(基礎、構築、利用) | |
*セーフティ(分析、設計) |
〇組込み・計測・制御 | *組込み(基礎、構築、利用) |
*デジタル技術 | |
*ヒューマンインターフェース技術 | |
*マルチメディア技術 | |
*グラフィック技術 | |
*計測・制御技術 |
〇共通技術 | *ナレッジマネジメント業務 |
*IT基礎 |
関連知識(業務的な知識)
メソドロジとテクノロジ以外のビジネス活動において求められるスキルを集めたものとなります。
具体的にはITエンジニアの仕事と直接的な関わりはないものの、円滑に業務を遂行する上で求められるようなスキルが当てはまります。競合企業の情報収集や、法規の理解、IT業界の最新トレンドの把握なども関連知識に含まれます。
ITヒューマンスキル(ビジネススキル)
ビジネスの場において、求められる対人能力で、下記(1)~(3)のカテゴリで分類されています。
(1)創造力
・状況を把握して、見極め、問題の解決する力
・複雑な状況に対して論理的に判断していく力
(2)実行・実践力
・結果を出すために、その場の状況によって柔軟に判断する力
・効果的継続の実行と、新しい取り組みや新領域に挑戦する力
(3)コミュニケーション能力
・相手の考えを理解する力
・自分の考えを伝える力
・共感力
評価制度で注意すべきポイント
職種やポジションにあわせた評価を
ITエンジニアとひとくくりに言っても、職種やポジション、配属先によって求められるスキルは多岐にわたります。
配属部署やポジションごとの評価項目や達成すべき目標を定めましょう。
例えばB TO C向けアプリの開発に携わるITエンジニアであれば、ユーザーの満足度やアプリの操作性などを評価項目もしくは目標と定めても良いでしょう。
プロジェクトマネージャーであれば、プロジェクトのスケジュール管理や、リスク管理の観点から評価基準を設けても良いかもしれません。
どのレベル感でスキルを求めていいのか分からない場合は、その部署やポジションの社員にヒアリングをすることから始めましょう。
目標設定を曖昧にさせない(数値を意識)
プロジェクトが長期にわたる場合、評価基準はITエンジニアの勤務態度やリスクの分析力、業務効率といった評価基準を設ける必要が出てきます。しかし勤務態度やリスクの分析力などは、業績と比べると一見分かりづらく、評価が難しいものとなります。
ここで意識してほしいのが、目標設定の際はできるだけ「定性的な要素を無くして定量評価を意識する」ということです。「業務効率の改善に取り組む」ではなく「業務改善に取り組むことで、作業時間を〇分減らす」と数値を取り入れることで、あいまいな評価となるリスクを防ぐことができます。
定期的な評価制度の見直し
ITエンジニア業界の技術革新は日進月歩であり、その技術を扱うITエンジニアのスキル、経験、働き方なども常に変化しています。
絶えず技術トレンドが変化していく現代において、活躍するITエンジニアを輩出していくためにはどうすればいいのか?
そのカギとなるのが「評価制度のアップデート」です。評価制度を見直すことで、社員一人ひとりの目指すべき方向性が明確化するため、社員のモチベーションを高めるためには有効な手段となります。継続的な評価制度の見直しは、社員のキャリアパスと企業の成長において大きな意義を持つのです。
まとめ
本記事では、ITエンジニアの評価制度について詳しく解説しました。評価基準を定める上で忘れてはいけないのが、全社員に対して「明確」で「公正」であることが重要でした。明確で公正な評価基準が設定されていないと、社員の不満が生じ、最悪の場合、離職に繋がる可能性があります。
そして、ITエンジニアの評価基準を策定する上では、明確さや公正さに加えて、その特殊性を考慮しなければなりませんでした。ITエンジニアに求められるスキルは多岐にわたり、プロジェクトも成果が出るまでに年単位を要するものが多く存在するため、一般的な評価基準に当てはめることは現実的ではありません。
「誰が見ても明確かつ公平で、ITエンジニアの働き方に即した評価基準を定める。」
そのためにぜひ活用してほしいのが独立行政法人情報処理推進機構(IPA)が提供する「iコンピテンシ ディクショナリ(iCD)」です。iCDはITエンジニアに求められるスキルやレベル感が細かく明記されており、自社の評価制度を見直したいと考えている企業にとって非常に有用です。
評価基準の見直しを考慮しているなら、ぜひiCDの導入を検討してみてはいかがでしょうか。
▼iCDを活用した弊社のITエンジニアスキル分析ツール▼