エンジニア組織の職能要件を再定義した話 – FURYU Tech Blog

この記事は フリューAdvent Calendar 2025 の1日目の記事となります。

フリュー株式会社ピクトリンク事業部でエンジニアマネージャをしている佐々木です。

今年もアドベントカレンダーの季節がやってきました。この記事を書いている11月26日時点では、カレンダーの半数程度しか埋まっていないので、果たして25日まで埋まるのか非常にヤキモキしています(笑)

今回は人事評価についての話です。人事評価は組織運営において最も重要な仕組みのひとつですが、評価基準が曖昧だと、評価者によって判断がブレ、被評価者の納得感は得られません。そして何より、組織が求める人材が育たないという本質的な問題を引き起こします。

本記事では、フリューのエンジニア組織において職能要件書を再定義し、評価基準の曖昧さを解消した(解消しようとしている)取り組みについて紹介します。

背景と課題

フリューでは年に1回、各人の能力考課を実施しています。評価の指針として職能要件書というものを用意しており、各職位(等級)に求められる能力を定義しています。

変更前の職能要件書(抜粋)

ただし、この職能要件書は多種多様な職種に対応するため汎用的に作られており、エンジニア組織にとっては次のような課題が顕在化していました。

直面していた課題

1. 求められていることが曖昧

例えば、要件には次のような記述がありました。

「自分の意思を伝達するために、難しい言葉を解りやすく置き換えて論理的に説明している」

一見すると明確に見えますが、エンジニアにとって「難しい言葉」とは何でしょうか。誰に対して説明するのでしょうか。この曖昧さが評価のブレを生んでいました。

2. 評価のブレと自己評価の甘さ

曖昧な要件は、評価者によって判断基準が変わるだけでなく、被評価者が自分に都合よく解釈する余地も生んでいました。要件の一部だけを切り取って「求められていることはできている!」と主張するようなシチュエーションが散見されました。評価者と被評価者の認識にギャップが生まれやすい構造だったと言えます。

解決アプローチ

職能要件書は、単なる評価のためのチェックリストではなく、組織が目指す方向性を示し、メンバーの成長指針となるべきものです。曖昧な要件では、組織が何を求めているのかが伝わらず、結果として求める人材が育ちません。

そこで、エンジニア組織独自の職能要件を定義することにしました。

基本方針

  1. (会社として求める人材の要件なので)大きくは手を入れない
  2. 個人で解釈する余地を極力減らす
  3. エンジニア組織の実態に即した要件にする
  4. 組織への影響力を基準に重み付けをする

詳細

職能要件の再定義において、2つの大きな工夫をしました。

1. 要件の具体化

曖昧な表現を、エンジニアの業務実態に即した具体的な表現に書き換えました。

Before:

自分の意思を伝達するために、難しい言葉を解りやすく置き換えて論理的に説明している

After:

非エンジニア職に意図を正確に伝えるため、専門用語を避け、平易な言葉で論理的に説明している

この変更により、評価者も被評価者も具体的な場面を想起しやすくなり、解釈のブレが大幅に減少しました。

2. 項目の重み付け

すべての要件を同じ重要度で扱うのではなく、項目ごとに「重い・普通・軽い」の3段階で重み付けを行いました。

重み付けの基準:

その能力を有していると、組織への影響力をより大きくできるもの

例えば、交渉や議論におけるファシリテーション力や、他メンバーの成長を促進する能力などは「重い」と位置づけました。この重み付けにより、組織において何が最も重要なのかが一目で分かるようになりました。

評価の際も、重い項目をより重視して判断することで、組織が求める人材の成長を促進する評価が可能になります。

変更後の職能要件書(抜粋)

取り組みの結果と今後

再定義した職能要件を実際に用いたところ、以下のような評価が得られました。

  • 評価のバラつきが減少: 具体的な表現により、評価者間での判断基準が揃いやすくなった
  • 評価面談の質が向上: 被評価者と評価者の双方から「以前よりマシになった」という評価
  • 成長指針の明確化: 被評価者が求められていることを理解しやすくなった

今回の取り組みで一定の成果が得られたのは非常に良かったです。とはいえ、まだ道半ばです。引き続き、下記の点について取り組んでいく予定です。

  • 上位職位について: 今回対象外だった上位職位の職能要件の見直し
  • 運用面における課題: 使いづらいところ、わかりづらいところの改善

まとめ

求めている能力を言語化するのは、答えがひとつではないからでしょうか、非常に難しい作業でした。

このような取り組みは、作り上げたら終わりというものではなく、継続的な運用が重要です。だからこそ、完璧を目指さず「まずはやってみる」というマインドで進めたことが、途中で挫折することなくやり切ることができた要因だと思います。

本記事が、同様の課題を抱える組織の一助となれば幸いです。




元の記事を確認する

関連記事