Skip to content

Latest commit

 

History

History
74 lines (65 loc) · 3.65 KB

File metadata and controls

74 lines (65 loc) · 3.65 KB

論点

  • エンジニア10人以下の小規模な会社におけるエンジニア評価制度とは?

まとめ

  • 評価制度がある会社

    • NG
      • 半期ごとの目標設定とふり返りを実施
        • 半年後やっていることが全然違うとかが普通におこる
    • OK
      • 毎月本人とのすりあわせを実施することで変化に対応
  • 評価制度がない会社

    • NG
      • 評価の機会を作らない
        • 給与交渉で負ける
        • 声が大きい人だけが得をしがち
    • OK
      • 評価について本人と話をする機会をつくる
        • 少額でも昇給の機会をつくることで会社としての誠意を見せる

詳細

  • 全社的な評価制度を導入済み

    • 導入の背景
      • 人数が増えてきた、給料あげてくれという声が増えてきた
        • 人によってはその都度対応したが、声を上げた人しか給料があがらない問題があった
        • 公平な昇給実現のために評価制度が必要なのではないかと思われた
        • ミッション・ビジョン・バリューを決めて、全社目標から、各メンバの目標に落とし込み
          • いわゆる MBO
    • 悩み
      • エンジニアの評価は定量評価しづらいこともあるので難しい
      • 事業スピードが速く、設定した目標がふり返りの頃には変わってしまう
        • 後から変わるのは仕方がない
        • 月次面談で修正していく
          • 変更が多いと達成感が失われるのではないかとの懸念はある
        • 変更の際に目標の大きさが小さくなりそうになることがよくある
          • 上司が大きな目標感を維持するように注意する
  • 評価制度がない場合

    • 起こっていること
      • 会社が成長していることもあり、社員から昇給の声が高まりつつある
        • 無碍に却下すると社員からの不信感に繋がってしまう
    • 悩み
      • 頑張ってくれている人には、個別に昇給を行っている    * 自己評価が客観評価より高い人にどうフィードバックするかが課題
      • 社員の成長のため、フィードバックは行っている
  • エンジニアに適した評価制度とは

    • 悩み
      • 評価制度はあるが、営業等と同じ評価なので、エンジニアには不満が起こりがち
        • エンジニアが辞めてしまう
    • 解決策?
      • 技術力評価
        • 評価基準が難しい
          • 評価基準表をどう作るか
          • 成果と能力の評価のバランス
      • エンジニア手当を一律支給
        • エンジニアの流出に対しては一定の効果あり
        • できる人をどう評価するかが問題になった
          • エンジニア手当を変動制に移行
            • ただし給与面での大幅な制度変更は影響が大きいので間違えると大変
  • エンジニアのスキルアップ支援の観点からの評価制度等のあり方について

    • 悩み
      • 保守開発ばかりだと自分の市場価値が下がってしまうという訴えがあった
        • 真面目にやってくれる人だったのでつい頼りがちになってしまった
    • 解決策
      • 保守と新規開発をバランスよく目標設定した
      • 他社との合同勉強会を実施
        • 自分では市場価値がないと思っていたが、外部視点から新たな価値に気づく部分もあった
      • 実質的に上級職の仕事をトライアル的に担当してもらう
        • 結果として適応できれば昇格を考える