人事課題解決ノウハウ
人事制度

エンジニアのモチベーションを高める評価制度とは

ITエンジニアがやりがいを持って取り組める評価制度へ

SCROLL
エンジニアのモチベーションを高める評価制度とは

自社に必要なエンジニア像を明らかにし、
その現在地を評価制度で測定する

エンジニア評価制度の現状

ITエンジニアの需要が増し、人材獲得競争が熾烈化していることは周知の事実である。

この環境下を勝ち抜くため、外部からの採用のみに着目するのではなく、エンジニアを社内で育成し、定着力を上げることも検討すべきではないか。

そのためには評価制度に着目したい。

ここでは、あるべき人物像と現在の発揮成果のギャップを正しく測ることで育成に寄与し、評価に対する納得度を上げ、定着力高めていくことでモチベーションを高める評価制度づくりを提言する。

エンジニア評価制度の現状
陥りがちなポイント

陥りがちなポイント

モチベーションを高める評価制度を考えるに当たり、陥りがちなポイントを3つ紹介したい。自社の制度がどうなっているか、見比べながらチェックしていただきたい。

(1)社員の何を評価したいのかが明確でない

自社は社員の何を評価したいだろうか。社員を評価する切り口はいくつもあり、本人が持つ意欲や価値観・考え方、知識・技術や経験などの潜在的で目に見えない・見えづらいものから、日常の態度・行動や生まれた成果など観察できるものがある。成果といっても個人の成果なのかプロジェクトの成果なのか、成果物のクオリティなのかそこに至るまでのプロセスなのかなど、何を評価したいか定まっていない事例は意外と多い。

(2)ロジカルに設計されていない

エンジニアはロジカルな思考の持ち主が多い。要件分析・定義から設計・プログラミング・テスト工程など、業務プロセスがウォーターフォール型で論理的思考力を強く求められやすい職種であるからだ。したがって各評価項目や基準等が何に紐づいているか不明瞭なものは納得されない可能性高い。

(3)時間軸を考慮していない

エンジニアが担うプロジェクトは半年や1年で成果が出るものとは限らない。小規模・単発案件であれば6か月前後でもある一方で、大規模なプロジェクトや複数案件を抱えている場合は2~3年掛かる場合もある。その個別状況を考えず、一律に半年や1年という評価期間で業務内容全てを評価しようとすると無理やり感が出てしまい納得は得られないだろう。

効果的な評価制度を確立する5ステップ

効果的な評価制度を確立する5ステップ

前述のポイントを押さえた効果的な評価制度の要素を5つのステップで紹介する。

ステップ1:人材ポートフォリオの整理

いきなり評価制度に入る前にまず押さえて欲しいのが、経営理念・PMVV・戦略実現のため「自社にはどんな人材が必要か」を明らかにする人材ポートフォリオを整理することである。自社のビジネスモデルを振り返り、どのような人材のどのような能力・スキル・経験が当社には必要なのか。ここを整理しないことには適切な評価項目を導き出すことはできない。

ステップ2:職種軸で切り分けた制度設計

適切な評価制度を職種軸で考えてみよう。一言でエンジニアといえど、皆が皆同じ仕事をしているわけではない。システムエンジニアもいればプログラマーやWebエンジニア、インフラエンジニア、セールスエンジニアなど多岐にわたる。またIT企業であっても総務や人事といったコーポレート系の業務だってある。大切なのはこれら複数の職種を担う社員がいる中でどう"最大公約数"的な評価制度にしていくかだ。職種軸に細かく切り分けた評価項目なら個別最適に構築できるかもしれないが、複雑で運用のハードルは上がる。逆に一律の評価項目であれば「自分の仕事をこの切り口では評価できない」と不満に繋がってしまう。

ステップ3:成果創出までの期間に左右されない評価項目

プロジェクト期間と評価期間を一致させることは難しく、評価の仕組みで対応するほかない。
例えば評価全体のうちプロジェクトでの成果は50%のウエイトとする。その50%は目標管理制度(MBO)を導入し、プロジェクトのWBSを参考に評価期末時点での達成度合いを設定し、そこに向けて行動をしてもらう。残りの50%のうち20%をスキル評価、30%をコンピテンシー評価とし、プロジェクトの成果とは直接一致しないまでも、その貢献度を測る。
上記はあくまで参考事例であるが、こうすることによってプロジェクトにおける成果が明らかになる前に、その評価期間内における貢献度を測定することが可能だ。

ステップ4:適切な評価者の設定

評価者を考える上でポイントは2点ある。1つ目はエンジニアの専門性を評価するだけの能力を持つ者が評価すること、2つ目は普段から目に見える場所で共に働く者が評価することである。
前者について、高い知識・スキルを持つエンジニアを評価するためにはそれを超える高い知識・スキルを持っている人材であることが必須条件である。これをクリアできる人間でなければ評価は務まらない。

後者について、エンジニアの働き方は無数にあり、常に社内にいるエンジニアだけでなくフルリモートや客先への常駐がメイン、地方在住によりリアルで会うことのないエンジニアもいる。つまり評価者の目に見えない場所で勤務することも他業種と比べると多いのが実情だ。
こういった特徴のある中で評価に納得度を得るためには、実際にその仕事を傍で見ている者に協力を仰ぐしかない。当然ながらプロジェクトマネジャーやプロジェクトリーダーはもちろん、場合によっては他拠点・他部署の人材や常駐先の顧客、パートナー企業の担当者などに協力を仰ぎ、正しい情報をもって評価されることが望ましい。

ステップ5:アジャイル型の評価運用

精緻な設計ができたとしても、それが正しく運用されるとは限らない。特にIT分野は求められる能力・スキルが短期間で変わる領域だ。一方で人事制度は一度作ると10年以上使用されることも珍しくない。一度作ったからといってそこから変えずに運用するのではなく、1~2年の頻度で適宜検証しながらブラッシュアップを繰り返していく"アジャイル型"で運用しなければならない。

ハードスキルとソフトスキルの評価

ハードスキルとソフトスキルの評価

エンジニアが持つスキルを評価していく中で考えたいのがハードスキルとソフトスキルのバランスだ。ハードスキルとはある業務を遂行する上で必要な専門知識や技術、資格などのことであり、IT領域においてはJavaやPythonなどのプログラミング言語、データベース管理、ネットワークセキュリティなどを指す。一方でソフトスキルとは業務を遂行する上でのベースとなる性格や行動特性などであり、コミュニケーション能力やリーダーシップ、論理的思考力などを指す。

どちらも業務遂行上ベースとなるスキルは必要だが、一般的に経験が浅い社員ほどハードスキルを身につける比重を高め、個人レベルにおける早期育成を目指したい。一方で経験値が高まりプロジェクトマネジャーなど要職に就くような人材にはソフトスキルの比重を高め、チームでのパフォーマンス向上を目指したい。したがってスキル評価について盛り込む際は一般職や専門職社員はハードスキルをメインに評価項目を設定し、管理職やプロジェクトマネジメントに携わるような社員についてはソフトスキルメインで評価項目を設定すべきだ。

さいごに

評価制度は「査定」という機能の印象が強いものの、重要なのは現状の発揮度合いを明確にし、ありたい姿とのギャップ=育成テーマを導き出すためという機能だ。つまり評価制度の本質は能力開発にある。エンジニアがモチベーションを高める評価制度とするためには、しっかりとマネジメント側が将来像を示してあげ、そこに向けてサポートしていくことが必要不可欠だ。そのためには短時間であっても高頻度なコミュニケーション機会を持ち、普段から育成のポイントを掴んでおこう。それが本人の能力開発に貢献し、モチベーションを高めることに繋がるであろう。

この課題を解決したコンサルタント

ABOUT TANABE CONSULTINGタナベコンサルティンググループとは

タナベコンサルティンググループは「日本には企業を救う仕事が必要だ」という志を掲げた1957年の創業以来
68年間で大企業から中堅企業まで約200業種、17,000社以上に経営コンサルティングを実施してまいりました。
企業を救い、元気にする。私たちが皆さまに提供する価値と貫き通す流儀をお伝えします。

コンサルティング実績

  • 創業68
  • 200業種
  • 17,000社以上