前回は、SESを主体としていた当社が、人事評価制度を作るためにコンサルタントをいれたけれど、なかなか認識が合わないというお話をしました。
システム会社のエンジニア評価ってどうやって作るの？エンジニアの人事評価ができあがるまでの実例①
今回は、認識があわなかった原因であるエンジニアの評価について、他の人事評価とどのように異なるのかをお伝えしていきます。
エンジニアの評価が他の業種と異なる点
①生産性の向上が在籍期間と必ずしも比例しない
製品知識、商品知識をITエンジニアとしてのスキルに置き換えると、必ずしも年齢とともに比例して上がっていくものではありません。
エンジニアの場合、
・情報系学部卒など1年を経過していなくても高い生産性をあげるもの
・3年目で知識集約が一定のレベルで進み、生産性が急に上がるもの
・何年たっても生産性が伸びないもの
・ある程度生産性が伸びたものの、要件定義・設計力不足などで一定の頭打ち感がでるもの
・新規技術吸収力があるもの（興味がある）、そうでないもの
など個人差が多く出ることがあり、一般企業のように仕事の出来不出来ではなく、生産性が当人の資質によって大きく異なることがあります。
②入社時、転職時のスキルスライド
SAPが強い、AWSが強い、Javaが強いなどのIT企業により技術的な特色はありますが、転社・入社時に基本的にスキルは持ち運びできると考えています。
組織内部で役職以外での立ち位置や有機的な人間関係の構築などはありますが、その部分を無視してしまえば転職してもそのまま技術的なスキルは活かすことができます。
企業内キャリアとシステムエンジニアのキャリアがことなる、象徴的な事象だと考えています。
③職種の多様化
ITスキル標準を見ると、この中に35の職種があるそうです。
ITスキル標準
一般企業の場合、総務や人事、営業、生産管理、営業事務などのある程度固定化された職種で構成されていると思われますが、ITエンジニアの場合は、その職種の中に35個の職種で構成されています（マーケティング等の職域も一部含んでいますが。）。
スキル構成が多様化されていることもITエンジニアの評価指標を多様化させる一つの要因になっていると思われます。
④転職、転籍をともなわないスキルのリセット
ITエンジニアの場合、要件定義や各種設計のスキルは受け継がれる部分が多いですが、開発言語や開発環境の変更を伴う場合、スキルの一部リセットを求められることがあります。
具体的には PHP環境の開発者からJavaの開発者、オンプレミスのインフラ構築者からAWSなどのクラウド環境の構築者など、知識や環境が変わると知識習熟をおこなっている際には、生産性に個人差はあるものの一定期間低下する傾向が強くあります。
④客先常駐・・・社内と社外、組織形成の違い
学術的には様々な組織形態がありますが、一般的には組織、というとピラミッド型の組織構造をイメージすることが多いですが、システムエンジニア/ITエンジニアの場合は組織構造が異なるケースが多くあります。
常駐業務（客先で開発する業務のこと）の場合は、組織構成が複雑です。PMがおり、PLが1名～数名いて、その中にメンバーが何名かいる状況となります。またメンバーの中にも、アプリ開発やインフラ担当者やフロント開発担当者、DB担当者など、組織でセグメントをするというよりはテクニカルでセグメントされているというチーム構成が一般的です。更に、その人員構成が業界の産業構造上一つの企業ではなく、複数の企業の人員で構成されることが珍しくありません。
社員の評価すべき情報は、他社の社員のほうがよりつかんでいるという実態もあります。
このような場合で人事評価を導入するとなると、一般企業を相手にしている人事コンサルでは、混乱してしまう要因の一つになります。
コンサルタントとの認識の溝が埋まらなかったのは、代表のコンサルに対する背景説明が薄かった点もあるともいえます。しかし、エンジニアの評価に関して人事コンサルを入れる場合、業界理解とITエンジニアとのテクニカルコミュニケーションが、一定のレベルで取れないと難しいというのが結論です。
少なくても他業種をメインにしていたコンサルの場合、評価スキームがスキル・コンピテンシーの考え方などが営業職・総合職などとは大きく違うという理解の時間が必要なのではないでしょうか。
次回は、エンジニアの人事評価について、判断に迷ったことや改善したこと、また、実際に人事評価制度を作成してのメリットやデメリットを伝えします。
システム会社のエンジニア評価ってどうやって作るの？エンジニアの人事評価ができあがるまでの実例②
