開発の吉野です。2022年ももう終わりですが、いかがお過ごしでしょうか。
今年はエルデンリングやスプラトゥーン、ポケモンとなかなか忙しかったのではないでしょうか。
そんな中、N2iの開発組織は評価制度の設計と運用に向けて準備を進めていき、運用を開始することができました。
今回は評価制度をどのように進めてきて、運用を開始したのかを書き出しています。
なお、いろいろな情報を参考にして評価制度の設計をしましたが、その中でもとても参考したのは以下の資料です。
- GitLab: Handbook https://about.gitlab.com/handbook/
- キャリアラダーフレームワーク https://unlearned.github.io/engineeringladders/ja/
- CircleCI: Why we re-designed our engineering career paths at CircleCI https://circleci.com/blog/why-we-re-designed-our-engineering-career-paths-at-circleci/
- ゆめみ: アプリケーション・エンジニア職位ガイドライン https://notion.yumemi.co.jp/76e2dc44fd8c441db10c7f9c5d03e7a9
このような情報があるおかげで設計を進めることができました。
本当にありがとうございます。
※内容は2022年12月時点のもので閲覧タイミングによっては記述内容から大きく変化している可能性があります。
1. 方針決め
評価制度を設計していくにあたって開発組織として方針を決めました。
- 評価者・対象者双方の合意・納得感を重要とします
- 潜在的な能力などではなく実際の成果・パフォーマンスから評価をします
- メンバーとの日々のコミュニケーションやレビューの中で細かいフィードバックを行い状況を理解させ、サプライズは発生させないようにします
- キャリアの方向性やラダーを明確にし、メンバーの立ち位置と行く先をこの中で明確に定義します
- プロセスの透明性を意識します
- 降格・降給も昇格・昇給と同様に評価制度によってなされます
- 評価対象者の交渉力の有無によって評価結果が左右されることの無いようにします
- 評価指標はメンバーが自分の力で解決できるものとします
- フィードバックに応じて制度の見直し・修正は常に行われます
2. 等級と結びつく給与レンジ決め
方針が決まったので、次に大枠の等級やそれに紐づく給与のレンジを決めていきました。
現状こんな感じになっています。
Grade | Title | Influence | Competency |
---|---|---|---|
G8 | Distinguished (Chief x Officer) | 事業 | 道を示す |
G7 | Principal | 事業 | 変革の推進 |
G6 | Senior Staff | 複数チーム | 計画やプロセス、チーム改善の策定 |
G5 | Staff | 複数チーム | 計画やプロセス、チーム改善の推進 |
G4 | Senior | チーム | 模範になる行動、チームの育成 |
G3 | Middle | チーム | 成長と自律的な行動、チームへのサポート |
G2 | Junior | チーム | 成長と自律的な行動 |
G1 | Associate | 自身 | 学習と業務遂行 |
G0 | Intern | 自身 | 業務遂行 |
等級と給与レンジ
等級の階層は8等級としています。
ここの8等級に関しては、N2i全体として評価制度をいれるにあたって等級を設定するなら8等級に分けるのが良いねということをボードメンバーと話をしていたことからです。それ以外の大きい理由は特にありません。
それぞれの等級に対してどのような役割を期待するのかという部分はざっくりといれています。
等級と同時に給与レンジも決めていきました。
給与レンジは国内外の企業様を参考にして市場性を考慮しつつも、N2iとしての現実的な額に調整をして設定しています。
役職とグレードの関係
ついでに役職とグレードの関係もこの時に明確にしています。
簡単に書くと、グレードは期待値を表し、そこに役職がつくことで権限が委譲される形としています。
基本的にはグレードに求められる期待が権限委譲を前提としている場合は役職の付与がされることととなりますが、グレードと役職は完全にはリンクさせていません。
それは役職が与えられないことでグレードがあげれないという状況が発生することを避けるためでもあります。
権限に関しては以下のような記事を参考にしながら設計しています。このような情報はほんとうにありがたいです。
https://qiita.com/hirokidaichi/items/257cd3370f77f2a44737
等級のレベル
等級にはレベルという概念をもたせています。
該当する等級の中でどのレベルにあるかを明確にしてくれるものになります。
スプラトゥーンのウデマエレベル的なものです。
自分がどのレベル感にあるのかを等級だけで表現した場合、おそらく説明のコストや評価対象者の納得感に影響がありそうだと思ったので補助的にこの概念をいれました。
Level | Suffix | |
---|---|---|
advanced | ++ | これ以上ないほど評価を満たしている |
standard | + | 基本的な評価を満たしている |
entry | 最低限の評価を満たしている |
3. 評価軸の決定
等級と大きい役割、給与レンジを明確にした後はどのように評価をするべきかを決定しました。
ここは色々と迷いましたが、最終的に2つの軸によって評価は行われることと決めました。
- 行動評価(コンピテンシーマトリックスによるもの)
- 成果評価(目標設定によるもの)
2つの軸に決定した理由としては、端的に言うと…
行動評価は受動的(passive)なものであり、成果評価は能動的(proactive)なものだからです。
評価対象者の納得感は評価制度の中で最重要な部分であり、それは片方だけでは成り立たないと考えています。
ひとつの方向からのある意味では一方的にも感じられる組織からの決められた行動からなる「行動評価」に対し、そこに対抗するためにどう自らが行動するかを対象者自らが定義し評価を迫る目標設定からなる「成果評価」は同時に運用していくべきだと思っています。
4. 各等級に期待する役割から現在のメンバーをマッピング
現在の業務や期待値から各メンバーがどの等級に該当するかをマッピングしていきました。
- どのような業務をやってもらっているのか
- (表明的、暗黙的な)期待値はどのようなものか
評価制度を入れることでなにか役割が増えるというよりは、現在やっているお仕事に対して評価制度をくっつけることを強く意識してやりました。
これは業務に大きな変化を促さないことでスムーズに制度を導入していけるかもという思いと、そもそも現状でメンバーには組織(チーム)としてやってもらいたいことをやってもらっているという前提があるので、評価制度は現在やってもらっていることの言語化の側面もあるなと思っているのでそのようにしています。
5. 各等級に合わせたコンピテンシーマトリックスを作成
等級とメンバーを紐付けることで行動のイメージの解像度が高くなっていることもありましたので、ここでコンピテンシーマトリックスを作成していきました。
- 各等級に配置されたメンバーがどのような行動をとっているか?
- 職能ごとに期待する役割はなにか?
初期においてはCircleCIを参考に作成をしています。
https://docs.google.com/spreadsheets/d/131XZCEb8LoXqy79WWrhCX4sBnGhCM1nAIz4feFZJsEo/edit#gid=0
CircleCIの公開しているコンピテンシーマトリックスはほんとうに良い資料で参考にしやすいのですが運用を考えると以下の点で我々とは合いませんでした。
- 指標ごとのコンピテンシーが明確になりすぎているゆえに境界線のゆらぎが吸収しにくい
- 期待していないことであっても「期待している」がこのマトリックス上では「やらなくていい」とミスリードしてしまうので説明コストが増す
合わなかった点は他の組織においては良い点なのかもしれません。
しかし我々はまだ評価制度を何もいれていない状況で、ある程度の柔軟さは欲しいという感じでした。
そのため、今回は各職能で重要な指標となる項目を定め、なぜこの指標が存在するかの説明を書いて、コンピテンシーに関しては箇条書きをして大きく捉えるように変更しています。
- 指標(Key)
- 項目(Theme)
- 説明(Description)
- 行動(コンピテンシー)
こんな感じです。
定めた項目に対して評価をつけるための評価レベルなるものを用意しました。
この評価レベルは5段階としています。
各項目を評価する場合、等級にあわせた8段階では多すぎたからです。
評価はどれだけ仕組み化されたところで主観的なものであるべきで、主観的に対象者のコンピテンシーに関するレベル付けをした際には5段階が一番評価しやすいなと思った次第です。
また、等級そのものは全体評価の総合とするので5段階で良いと判断しています。
Level | Title | Description | |
---|---|---|---|
5 | staff | コンピテンシーの専門家として振る舞う。このコンピテンシーに関してより良い方法や仕組みなどを開発できる。 | チョットデキル |
4 | senior | このコンピテンシーに関して他のメンバーのサポートや育成、相応の対応などができる。 | けっこうできる |
3 | middle | サポートが無くともコンピテンシーを実現できる。信頼できる。独り立ちしてる。 | いちにんまえ |
2 | junior | サポートがあることでこのコンピテンシーを実現することができる。一人で行うにはまだ不安が残る。 | まだまだ |
1 | associate | コンピテンシーを多少なりとも知っている。その重要性は一定の理解をしている。理解する必要がある。まだこれから。 | よちよち |
0 | none | コンピテンシーに関与していない。または知らない。理解していない。理解する必要が無い。 | やってない |
職能別コンピテンシーとベースコンピテンシー
コンピテンシーマトリックスは技術的な側面の職能別コンピテンシー(Technical Skills)と全員が意識するべきベースコンピテンシー(Technical Skills以外)にわかれています。
key | theme(コンピテンシー) |
---|---|
技術 (Technical Skills) | 各職能ごとに定義 |
価値の提供 (Delivery) | 作業分解 / 優先順位、依存性 / 不確実性への対応 / 信頼性、納期に対する説明責任 / アジリティ |
コミュニケーション、コラボレーション (Communication, Collaboration) | レビュー / 効果的なコミュニケーション / ナレッジの蓄積と共有 / チームワーク / 関係構築 / 不一致への対応 |
リーダーシップ (Leadership) | 意思決定 / 推進力 / プロセス / ファシリテーション / メンタリング |
事業に対する視座と戦略 (Business Acumen & Strategy) | 事業感覚(ビジネスセンス) / 組織戦略 / プロダクト理解 |
バリュー (value) | 冒険・挑戦意識 / リスペクト / プロフェッショナル / 顧客思考 / 失敗への寛容さ / 組織へのオーナーシップ / 採用への貢献 |
Technical Skillsのコンピテンシーに関しては現在は以下があります。
- Software Engineer (Web Application)
- QA
- Designer(Creative Team)
- PM (Product & Project Management)
- SRE
行動評価用シート
行動評価を明確に伝えるために評価シートを作成しています。
レーダーチャートはキャリアラダーフレームワークを参考にしています。
https://unlearned.github.io/engineeringladders/ja/
このレーダーチャートの形によって対象者がどういう状態にあるかを示していく形です。
6. 運用していくためのマネジメントチームの発足
行動評価および成果評価の解像度があがってきたところで、
評価制度を運用してくためにマネジメントチームを発足しました。
7. 実施スケジュールの作成と実施
弊社は期初が10月となりますので、10月に評価制度を全員に伝えてそこから四半期でチェックポイントを置きながら動かしていくようにしました。
- 2022年10月〜12月: 行動評価の運用
- 2023年01月〜03月: 成果評価の運用
- 2023年04月〜06月: 評価制度全体の運用開始
いきなりすべてを運用開始することは難しいため、まずは行動評価を先に走らせて各メンバーが現在どのように評価されているかを認識してもらうこととしています。
その後に、この評価からどのように目標を設定していくのかの目標を設定して成果評価を進めていく流れにしています。
まとめ(現在地)
現在は予定通り行動評価をほぼ全員に伝達完了し、2023年1月から目標設定に向けて動いていけそうな状況にあります。
答えが無い中で、どこまで考慮すればいいのかなど色々な不確実なものに折り合いをつけて進めていくのはなかなかツライものがありましたが、なんとか駆け出し中です。
ずっと霧の中にあり「誰も満足してくれないよこんなの」からの「いったいこれをどうしたいのか自分が一番わからない」というアイデンティティ崩壊の危機に陥ったりしてましたが、駆け出し始めて他のメンバーからのフィードバックを聞くたびに少しずつ霧が晴れていく感じがあります。
逃げたら一つ、進めば二つ
引き続き来年も逃げずに評価制度を進めていきます。
最後はみんなで集まって星座になれたらいいなと思います。
2022年はありがとうございました。
2023年もN2iをよろしくお願いいたします。