こんにちは、meihong です。
株式会社フィードフォースでは定期評価ではなく本人の希望するタイミングで評価を行う制度を導入しています。具体的には、各等級ごとに満たすべき基準・条件、またはスキルがあらかじめ提示されており、それを満たしていれば次の等級に進める制度になります。
この基準やスキルを私たちはキャリアパスと呼んでいますが、今回、エンジニアのキャリアパスをアップデートしましたのでご紹介したいと思います。
なぜキャリアパスをアップデートしたのか
もともとのキャリアパスは導入当初に設計されたものをベースに、マネージャやエンジニア、新規事業向けエンジニアといった個々人の志向に応じて細分化されていました。
これはこれでよくできたものだったのですが、しばらく運用している中でいくつかの課題点を感じるようになってきました。 例えば、
- 志向ごとに分かれすぎていて、志向を横断した動きが想定しづらくなった。
- 独り立ちと判断される等級であるメンバーとその一つ上のシニアの境界に「見えない高い壁」が存在するようになった。
- シニア以上の等級になるとチームや会社を牽引することを求められ、技術をそれ以上深掘りすることに対して会社がどう考えているのかが見えづらくなった。
といったところです。
特にキャリアパス全体として、職種問わず等級が上がれば上がるほどチームや会社への影響力が求められる設計になっています。
もちろんエンジニアも全体への影響力は持つべきなのですが、その持ち方は他の職種と異なり、技術力の広さ、深さといった持ち方もあるのではないかと考えるようになりました。
ここで、個人的にはプロフェッショナルとしてのスキルは体積であり、その底面積はスキルの幅広さだと考えています。
極端に底面積が狭いのはさすがに現時点では厳しいとは思いますが、
- 底面積がそれなりである代わりに高さ(= 深さ)がある
- 底面積が広い (= 引き出しが多い) 反面高さはそこまででもない
の両者は体積という意味では同じはずです。
この両者が共存できる余地が欲しいと考えていました。
そんな中、弊社デザイナーのキャリアパスがアップデートされました。その中でも目を引いたのは、必須スキルと専門スキルという考え方です。
必須スキルはデザイナーとして必ず持っていて欲しいスキルである一方、専門スキルは本人の志向、特性に応じてピックアップできるというもので、大学の専攻を思い出す建て付けでした。
これをパクるこれにインスパイアされて、エンジニアのキャリアパスもアップデートすることにしました。
どのように更新したのか
結果から先にお伝えしておくと、大まかに以下のような方向性に改訂しました。
- 志向ごとのキャリアパスは止めた。
- 旧来の「志向」を専門スキルに分解し、専門スキルの組み合わせで個々人の志向・特性を表現できるようにした。
- 等級が上がれば上がるほど満たすべき専門スキルの最低数が増えるようにした。
その結果として、例えば
- バックエンドエンジニアに特化
- フルスタックエンジニア
- フルスタックな知識をベースに事業の 0 → 1 フェイズに参画できるエンジニア
- カスタマーサクセスエンジニア
- アジャイルコーチ
といった、実際に社内に存在している各エンジニアの志向や得意なポイントを表現できるようになりました。
産みの苦しみ
ここに至るまでには色々な葛藤がありました。 社内の esa にキャリアパスを更新したいと宣言はしたものの、社内のエンジニア個々人の顔を思い浮かべつつ何を専門スキルとして設定するかを考えると想像以上に難しい問題だということに気付きました。
必須スキルと専門スキル
そもそも必須スキルと専門スキルとは何か、そこの定義から考えることにしました。
必須スキルとは文字通り、全てのエンジニアが共通に要求されるスキルセットのことです。どちらかというと「バックエンド」「フロントエンド」といった用語で定義されるスキルセットというよりも「フィードフォースに所属するエンジニアとしての振る舞い方」ではないでしょうか。
そう考えながら改訂前のキャリアパスを改めて眺めていると、改訂前のキャリアパスはその振る舞いを定義していることに気付きました。その結果、改訂前のキャリアパスが必須スキルのベースとなりました。
そうです、キャリアパスの改訂によって、より要求水準が上がったとも言えます。
一方、専門スキルは、本人の得意分野、志向、特性を定義するものです。 その志向・方向性で貢献するのであれば、各等級ごとにどの水準の成果を出すべきか。それを定義するものが専門スキルになります。
専門スキルとはどうあるべきか
本人の志向を定義するものが専門スキルと説明しましたが、例えばカスタマーサクセスエンジニアやエンジニアリングマネージャといった職種にしてもエンジニアの延長である以上はエンジニアとしての「共通言語」を身につけているべきです。
その「共通言語」とは、例えば設計力であったり、フロントエンドやバックエンドのスキルが該当します。
こういった知識を前提として例えば事業開発であったりチームビルディングを行うべきで、これらの知識がなければエンジニアとの「共通言語」を持っていないと判断せざるを得ません。
一方で、「フロントエンド力」と「バックエンド力」が同じくらい強いエンジニアというのは SSR エンジニアで、そうそう市場には存在しません。そこで、フルスタックとはいえどこかの分野に軸足を置くことができる制度というのも必須に感じました。
ただ、ここの軸足とはあくまでも「フロントエンド」「バックエンド」「インフラ」といった区分けで、エンジニアとしてコードを書き続ける選択をするのであれば、フロントエンド/バックエンド/インフラといった区分に関係なく設計力・実装力が担保されているべきでしょう。
17 の専門スキル
ここのバランス感が非常に難しい点でしたが、これを元に 17 の専門スキルを定義しました。 ただし、17 の専門スキルは完全に独立しているわけではなく、以下 6 つは本人の志向を定義するものとして、必ずどれか一つが必須選択としました。
- バックエンド
- フロントエンド
- データベース
- 基盤
- カスタマーサクセス
- 組織支援
さらに、上記のうち以下 4 つを選択した場合は「実装・設計」と呼ばれるスキルが必須となります。
- バックエンド
- フロントエンド
- データベース
- 基盤
これにより、コードを書き続けるのであればただコードを書くだけでなく、実装力・設計力が要求される建て付けを実現しました。
また、詳細は省きますが、さらにいくつかの例外を設置することで、「全ての分野で等しく強い SSR なフルスタックエンジニア」が求められないようにしています。
様々なエッジケースを考慮したせいでちょっと複雑になった感の否めない新しいキャリアパスですが、以前のものと比べるとその分より柔軟なものになったと思います。
今回は敢えて詳細を省きましたが、ご興味をお持ちいただけたら是非カジュアル面談でねっちょりとご説明します！
