なぜ情シスは評価されにくいのか？ 間違った評価制度と年収アップのコツ

かつて情シスは「一番PCに詳しい人」が任命されがちでした。評価や昇給の成功事例は少なく、転職以外で昇給に伸び悩むケースをよく見ます。情シス部長を2社で担当し、エンジニアの評価制度コンサルティングを実施する筆者の経験から、情シスの評価制度の作り方や年収アップ交渉のコツをお話します。

[久松 剛，エンジニアリングマネージメント]

　エンジニアリングマネージメントの社長兼「流しのEM（エンジニアリングマネジャー）」の久松です。業務委託先でEMを担当しつつ、ITかいわいについて歴史やエピソードを基に整理し「IT百物語蒐集家」として人の流れに主眼を置いたnoteを更新しています。

　待遇の上昇が著しいプログラマーやデータサイエンティスト、AI（人工知能）関連職などでは、「勤務先で評価されて出世するよりも転職した方が年収は上がる」と言われています。そういった影響もあり、人材の流出を防ぐため、人事評価の時に年収の上下幅を考慮する企業もあります。

　しかし情シスの評価や昇給制度の成功事例は少なく、転職以外では昇給に伸び悩むケースをよく見ます。入社時契約年収で据え置きや微増では、情シスの定着は見込みにくいものです。今回は情シスの評価事情や評価制度の作り方、年収アップ交渉のコツについてお話します。

著者プロフィール：久松 剛（エンジニアリングマネージメント　社長）

　エンジニアリングマネージメントの社長兼「流しのEM」。博士（政策・メディア）。慶應義塾大学で大学教員を目指した後、ワーキングプアを経て、ネットマーケティングで情シス部長を担当し上場を経験。その後レバレジーズで開発部長やレバテックの技術顧問を担当後、LIGでフィリピン・ベトナム開発拠点EMやPjM、エンジニア採用・組織改善コンサルなどを行う。

　2022年にエンジニアリングマネージメントを設立し、スタートアップやベンチャー、老舗製造業でITエンジニア採用や研修、評価給与制度作成、ブランディングといった組織改善コンサルの他、セミナーなども開催する。

Twitter : @makaibito

評価制度をどの職種に寄せるか

　最初に立ちはだかる壁は評価軸です。情シス担当者がある程度いる企業であれば専用の評価軸を作っても合理的でしょう。しかし、多くの企業では情シス専任者が少ないため、情シス専用の評価軸は存在しない傾向にあります。

総務と合わせる

　まず考えるべきは「組織図の中で情シスがどこにあるのか」です。

　管理本部配下や開発部の一部や、グループ会社の横断組織、経営者直轄とさまざまなパターンがあります。特に管理本部配下で多いのが、総務や人事、法務、財務経理といったバックオフィスと評価軸をそろえるパターンです。

　バックオフィスはコストセンターとやゆされることがあり、売り上げを直接上げる機会も少ないため、評価や年収も大きく上げづらい傾向にあります。企業全体に対してプラスになる上場のようなイベントがあれば、法務や財務経理はポジティブな評価を得るケースがありますが、情シスは望み薄です。

開発組織と合わせる

　プログラマーなどの開発組織と同一の評価軸を適用する方法もあります。

　プログラマーの場合、ソースコードのコミットやプロジェクトリリースなど、明確なアウトプットがあり、企業に対する事業貢献の度合いを計りやすい傾向にあります。一方情シスの場合、プログラミングを業務の一環としている方は少ないです。開発組織の評価者によっては、プログラミングができなければその人を低く評価する場合があります。

　こうした苦悩は、開発組織の中にポツンと存在するインフラエンジニアに見られるものと同じです。インフラエンジニアの場合、安定してシステムが動くのは当然、障害が起きると怒られ、マイナス評価になりやすい傾向にあります。そのため、事業会社であればミドルウェアの更新やクラウドシフト、コスト最適化、応答速度改善といった具体的な目標を掲げ、目標に対する達成率で評価するケースがあります。こういった方針の定め方は情シスの評価制度作りでもヒントになるでしょう。

情シスの評価制度の作り方

　ここまで、情シスを評価する際の評価軸と組織についてお話ししました。以降では、情シス専用の評価制度を作る際、押さえておきたいポイント、年収アップ交渉のコツを紹介します。

情シスの評価目標の定め方

　期初に設定した目標を基に評価をするのは、情シスが評価に納得感を持つため、企業に定着するための一つの解法になります。

　目標に対する進捗（しんちょく）状況を「できた」「できない」の二択で判断すると正しく評価できないリスクがあります。対象期間に予定されているイベントの着地点を予想し、あらかじめ「どの段階までできれば何点なのか」を評価者と情シスで合意し、定量評価として目標の中に設するのが有効です。

　例えば「勤怠管理システムの導入」を評価する場合、以下のようなポイントで点数化できます。

• システム導入不可
• システム導入は可能だが、遅延見込み
• 期限内のシステム導入
• システム利用者数の25%以下の問い合わせ件数
• システム利用者からの問い合わせ0件

　ただし外的要因により導入がズレてしまうこともあるでしょう。そのような場合に備えて、目標設定変更が期中で可能であれば修正し、変更が発生する場合はマイナス評価にならないよう両者で合意を取っておくことが重要です。

業務効率化はbefore／afterでの定量評価を

　工数削減のような業務を担う方は多いと思います。「ただ施策を実施しました」だけだと本当に業務効率化につながったかどうかを判断するのは難しいため、定量評価をする必要があります。

　例えば、対象となる業務について何時間掛かっているのかを算出します。そしてシステム導入などの業務効率化を果たした後に、その業務時間をどれだけ削減したかを算出します。当該業務を正社員が担っている場合は工数、派遣社員や業務委託が担っている場合は金額換算がしやすくなります。

　加えて施策導入にかかった工数や人件費なども併記すると、より成果として見えやすくなります。

購買時の「値切りました」は評価しにくい

　システム導入の購買を担当する情シスの方もいるでしょう。過去に「値切ったのでそれを評価してください」と言われたことがありましたが、とても頭を抱えました。相見積もりの習慣があれば値切るのは一般的です。総務が購買担当であっても根切りは実施しているでしょう。

　ITエンジニアとしての評価が適用されるのであれば、何かしらのエンジニアリングで評価をしたいところです。導入後の工数削減などが良い落とし所ではないかと考えます。加えて価格の交渉内容を評価するには、絶えず大きな購買が発生しなければならないため、毎期使える評価軸ではありません。

アンチパターンとしての「コストカット」

　不要なライセンスの削減や整理、サーバの削減、契約見直しによるコストカットなどを経験された情シスの方は多いかと思います。

　しかし毎期コストカットを評価軸にすることはお勧めしません。実際にあった事例ですが、コストカットを毎期継続したところ、それ以上カットするポイントが無くなったと話す方がいました。

　そのことを直属の上司である社長に話したところ、「次は君の人件費かな」と笑って話されたことがキッカケで不信感が産まれ、転職したとのことです。コストカット施策には終わりがあります。

サンクスカード

　メインの評価軸にするケースは少ないですが、サブ的にサンクスカードを導入する企業はあります。感謝の気持ちとして少額の金銭を従業員間で贈り合える「Unipos」を導入するケースもあります。同僚から感謝された人を表彰したり、「Amazonギフト券」などをプレゼントしたりするケースもあります。

　ささやかな施策ではありますが、社内で「ありがとう」と言われることで満たされる承認欲求はあるため、機嫌よく働いてもらうことを念頭に導入を検討してもよいと考えます。

評価や年収交渉のヒント

　基幹システムをパブリッククラウドにリフトできるスキルや、質の高いプログラミングスキルがあれば、高い評価を得やすい傾向があります。

　しかし多くの場合、情シスは社内にあふれている混沌としたタスクを担当することが多く、「どのスキルがあるからこのくらいの評価であり、この程度の年収を得ることが適当である」と、交渉できない方が多いのです。

　一つの案としてお勧めするのがユナイトアンドグロウ社の価格表です。どの担当業務であればどの程度のランクの人材が必要となり、時給ベースでどのくらいなのかが明示されています。業務委託なのでそのまま正社員年収に換算はできませんが、外注するといくらの仕事をしているのか、販管費や福利厚生を差し引いてどの程度の年収が適当なのかを議論するたたき台として適当でしょう。

　こうした事柄を基に、社内で自身の貢献や能力を正しく認知してもらい、適切な評価を受けられるよう立ち回りましょう。