エンジニアの人事評価に悩む企業が少なくありません。エンジニアの貢献は定量的に把握しづらいため、スキルやノウハウを適切に評価していく必要があります。

しかし、エンジニアの業務領域は専門性が高く、スキル評価の方法をイメージできない人事担当者が多くみられます。エンジニアの評価制度は、どのように設計すべきでしょうか。

本記事では、エンジニアの人事評価の基準や、評価制度を導入するときの注意点を解説します。

1. エンジニアの評価制度とは？

そもそも人事評価制度は、業績考課、能力考課、情意考課の3つの評価基準を組み合わせた制度です。

業績考課	従業員の成果や業績を評価する項目
能力考課	従業員のスキルやノウハウを評価する項目
情意考課	従業員の勤務態度を評価する項目

たとえば、業績考課は「顧客単価が●%増加した」「案件獲得数を●件増加した」など、従業員の成果や業績を評価します。

しかし、エンジニアの場合、プロジェクト内での役割を与えられて業務をおこなうことが多く、企業への貢献度を数字で表すのが困難です。そのため、エンジニアの人事評価は、個人の成果や業績を評価しつつも、能力考課や情意考課がメインとなってきます。

2. エンジニアの評価制度の課題

評価で重要なのは、従業員の成果や働きを「正しく評価する」ということです。成果は数値化できるので、数値に基づいて的確な評価ができますが、能力や情意というのは数値化が難しく、評価者によって結果の差異が出ることも少なくありません。

エンジニアの場合は、成果での評価が難しく、また専門的な知識がないと能力の評価も適切におこなえないなどの課題があります。

ここでは、エンジニアの評価制度の課題を解説していきます。

2-1. 専門的なスキルを評価できる人材の不足

エンジニアの評価制度は、専門的なスキルを評価できる人材が不足しているという課題があります。

本来であれば、エンジニアと同等のスキルや知識を持つ人が評価をするのが望ましいですが、人材不足に悩む企業では、適切な評価者を確保できないケースも少なくありません。そのため、技術スキルの習熟度を正しく判定できず、能力考課の客観性が失われます。その結果、数値化しやすい業績考課に偏った、不透明な評価に陥るリスクがあります。

また、ほとんどの人事担当者はエンジニアの業務領域に関する知識を持たないため、評価点数を付けた理由を明確に答えづらいのも特徴です。そのため、評価基準について問い合わせがあった場合、人事担当者が明確に回答できないケースも多く、エンジニアが人事評価に不満を抱く原因の一つとなっています。

2-2. 短期間では結果が出ない

エンジニアの業務というのは、短期間で結果が出るものではないため、限られた期間の中では的確な評価がしにくいという課題もあります。特に、長期にわたるプロジェクトの場合は、半期や四半期ごとの評価面談では結果が確認できないことも少なくありません。

「結果が出ているからプラス評価する」「出ていないからマイナス評価にする」など定量的な判断をしてしまうと、その後の業務への意欲が失われてしまう可能性があります。公平に評価をおこなうには、評価面談の時点での成果で判断する必要があります。しかし、エンジニアの業務の特性を考慮しないと、エンジニアにだけ不公平な評価になってしまうので、成果以外の評価項目や基準でフォローできるようにするのが望ましいでしょう。

2-3. 客先常駐型の評価がしづらい

客先に常駐しているエンジニアが評価しづらい点も、課題の一つです。上司がエンジニアの働きぶりや勤務態度をチェックできる状況にはないため、適切な評価が難しくなります。この場合は、客先の協力が欠かせないでしょう。

しかし、人事権がないにもかかわらず、エンジニアの評価や昇給に影響を与えることへの負担感から、客先が協力を渋るケースもあります。客先から協力を得られない場合は、アンケートや客先責任者との面談などを活用することで、エンジニアの働きぶりをできる限り把握し、より公平な評価につなげることが重要です。

3. エンジニアの評価制度の事例

企業はエンジニアの人事評価の課題を解決するため、独自の評価制度を導入してきました。

例えば、料理レシピサイトを運営するA社の評価制度の場合、人事担当者ではなく経験豊富なテックリードがエンジニアの人事評価を担当しています。これにより、「人事担当者にエンジニアの知識がないため、専門スキルを評価できない」という課題を解決しています。また、デジタルマーケティングを手がけるB社の事例では、エンジニアがスキルや技術力を自らプレゼンし、シニアエンジニアからのフィードバックを受けるというユニークな評価制度を導入しています。

エンジニアの評価制度の納得感を高めるには、人事担当者だけでなく、よりグレードの高いエンジニアによるフィードバックを取り入れた制度設計が効果的です。

4. エンジニアの評価制度における評価基準

エンジニアの評価基準を考えるときに役立つのが、情報処理推進機構（IPA）が提供する「iコンピテンシ ディクショナリ（iCD）」です。iCDは、理想的なエンジニアの行動特性（コンピテンシー）を分析し、必要なスキルを4つのカテゴリに分類したものを指します。

• テクノロジ（技術やノウハウ）
• メソドロジ（マネジメント能力）
• 関連知識（業務知識）
• ITヒューマンスキル（ビジネススキル）

エンジニアの評価制度における4つの評価基準を解説していきます。

4-1. 技術やノウハウ

テクノロジ（技術やノウハウ）のカテゴリには、エンジニアが業務で発揮する専門スキルなどが含まれます。IPAはエンジニアの専門スキルを6つのカテゴリに分け、合計25個の評価項目を挙げています。

システム（基礎、構築、利用）	● ソフトウェア技術 ● データベース技術 ● ハードウェア技術 ● Webシステム技術 ● プラットフォーム技術 ● ネットワーク技術
保守・運用	● ITサービスマネジメント業務管理技術 ● ITサービスオペレーション技術 ● システム保守・運用・評価 ● 障害修理技術 ● 施工実務技術 ● ファシリティ設計技術 ● サポートセンター基盤技術
開発	● システムアーキテクティング技術 ● システム開発管理技術
非機能要件	● 非機能要件（可用性、性能・拡張性） ● セキュリティ技術（基礎、構築、利用）
組込み・計測・制御	● 組込み技術（基礎、構築、利用） ● ディジタル技術 ● ヒューマンインターフェース技術 ● マルチメディア技術 ● グラフィック技術 ● 計測・制御技術
共通技術	● IT基礎 ● ナレッジマネジメント技術

4-2. マネジメント能力

メソドロジ（マネジメント能力）は、企画の立案や人材育成、情報セキュリティなど、エンジニアの業務領域に限定されず、幅広いシーンで求められるスキルを指します。マネジメント能力は5つのカテゴリに分けられ、合計33個の評価項目が含まれます。

戦略	● 市場機会の評価と選定 ● マーケティング ● 製品・サービス戦略 ● 販売戦略 ● 製品・サービス開発戦略 ● システム戦略立案手法 ● コンサルティング手法 ● 業務動向把握手法
企画	● システム企画立案手法 ● セールス事務管理手法 ● 要求分析手法 ● 非機能要件設計手法
実装	● アーキテクチャ設計手法 ● ソフトウェアエンジニアリング手法 ● カスタマーサービス手法 ● 業務パッケージ活用手法 ● データマイニング手法 ● 見積り手法 ● プロジェクトマネジメント手法
利活用	● サービスマネジメント ● サービスの設計・移行 ● サービスマネジメントプロセス ● サービスの運用
支援活動	● 品質マネジメント手法 ● リスクマネジメント手法 ● ITガバナンス ● 資産管理手法 ● ファシリティマネジメント手法 ● 事業継続計画 ● システム監査手法 ● 標準化・再利用手法 ● 人材育成・教育・研修 ● 情報セキュリティ

4-3. 業務知識

業務知識（関連知識）は、エンジニアの仕事と直接関わりはないものの、円滑に業務を進めるうえで欠かせない知識を指します。

例えば、業務内容を最適化するためのビジネスインダストリ（情報システム）の理解や、企業活動の仕組みについての理解、自社の事業内容に関わる法規・基準・標準の理解などが含まれます。

また、エンジニアの業務に間接的に関わる、IT業界やトレンドの動向を把握する業界知識も重要です。IT業界の進化はめざましく、常に変化をしていくのでエンジニアはアンテナを張っておくことが求められます。業界の進化を迅速にキャッチし、「新しい技術を習得できている」ということは評価に値するでしょう。

4-4. ビジネススキル

ITヒューマンスキル（ビジネススキル）は、現代のビジネスパーソンに欠かせない基本的なスキルを指します。IPAは、エンジニアに必須のビジネススキルとして「創造性」「実行・実践力」「コミュニケーション力」の3つを挙げています。

コミュニケーション力は一見関係ないように思えるかもしれませんが、どんな業務でも一人で企画して実践し、成し遂げられるものではありません。周りとの協力で1つのプロジェクトが完成するので、コミュニケーション力も評価対象となるのです。

また、同じようなスキルで、プロジェクトの経験というのも評価対象となります。エンジニアはプロジェクトから依頼を受けて業務をおこなうので、プロジェクトの規模や内容、関わったテクノロジーなどが評価項目となります。

5. エンジニアの評価制度の導入方法

エンジニアの評価制度を導入する際は、いくつかのステップを踏むことが重要です。目的の明確化から評価基準・項目の作成、運用ルールの整備まで、順を追って進めることで、実効性の高い評価制度を構築することができます。

5-1. 評価の目的を明確にする

まずは、エンジニア向けに評価制度を導入する目的を明確にします。事前に明確にしておくことで、評価基準や項目設定のブレを抑えられるのに加え、社内への周知もしやすくなります。

導入目的には、モチベーションの向上や離職率の低下、適切な報酬設定などが挙げられます。

ただし、会社側だけで一方的に決めるのではなく、事前にエンジニアへヒアリングをおこない、共感を得られる目的に設定することで、制度への積極的な協力も期待できるでしょう。

5-2. 評価基準や評価項目を作成する

目的が定まったら、評価基準や評価項目を作成します。先に紹介した情報処理推進機構（IPA）の「iコンピテンシ ディクショナリ（iCD）」を参考に、自社の規模や業務内容に合わせて作成しましょう。

また、エンジニアといっても職種は多様で、システムエンジニアやサーバーエンジニア、プロジェクトマネージャーなどさまざまです。一律の基準で評価しようとすると、公平性が担保できなくなる恐れがあるため、職種ごとに基準や項目が適切かどうかも事前に確認しておきましょう。

5-2-1. エンジニア評価シートのサンプル

評価基準や評価項目を決めるとともに評価シートの準備も必要ですが、一から作成するとなると多くの手間がかかります。

そこで活用したいのが、厚生労働省が提供しているエンジニア向けの評価シートのサンプルです。ウェブ・コンテンツ業向けにエクセル形式の評価シートをホームページ上で公開しており、カスタマイズもしやすいため、一から作成する手間を大幅に削減できるでしょう。

参考：ウェブ・コンテンツ制作業（モバイル）の職業能力評価シート｜厚生労働省

5-3. 評価プロセスやルールを決定する

評価基準や評価項目を作成したら、次に評価プロセスやルールを決定します。何段階評価にするかをはじめ、誰が・いつ・どのように評価するかを明確にしておくことで、評価のばらつきを防ぎ、公平性を担保することができます。

例えば、評価の頻度（半期・年次など）や評価者の選定、評価結果のフィードバック方法などを事前に取り決めておくとよいでしょう。また、評価プロセスをエンジニアにも周知しておくことで、納得感のある評価制度の運用につながります。

6. エンジニアの評価制度を導入するときの注意点

エンジニアの評価制度を導入するときの注意点は2つあります。

• 客先常駐のエンジニアのケア
• テレワークやリモートワークで働くエンジニアのケア

エンジニアによっては、別企業に派遣されて働くケースもあります。自社で働くエンジニア（プロパー）と違い、客先常駐のエンジニアは人事担当者の目が行き届きません。また、テレワークやリモートワークなど、オフィス以外の場所で働くエンジニアも同様です。

目の届かないところで働くエンジニアは、成果以外の評価がしにくいため、評価点が低くなる傾向があります。

そのため、エンジニアの評価制度を導入するときは、オフィス以外の場所で働くエンジニアもきちんと評価できるような制度設計を意識する必要があります。例えば、1on1のオンラインミーティングを導入し、客先常駐のエンジニアやテレワークで働くエンジニアのケアをおこないましょう。

7. エンジニアの評価制度は納得感のある制度設計を

エンジニアの評価制度の課題は、「エンジニアの貢献度が数字で表しにくい」「人事担当者がエンジニアの専門スキルを正確に評価できない」の2点です。他社の取り組みのように、経験豊富なエンジニアが人事評価に関わる仕組みを作ることで、評価制度の不公平感を解消できます。

エンジニアの評価基準として「技術やノウハウ」「マネジメント能力」「業務知識」「ビジネススキル」などの項目が挙げられます。また、IPAが提供するiCDなども参考になるので、自社のエンジニアに合った評価基準を設けましょう。

関連記事：評価制度とは？導入する目的やメリット、作り方をわかりやすく解説