Circle CI - エンジニアのコンピテンシーマトリクス

https://circleci.com/blog/why-we-re-designed-our-engineering-career-paths-at-circleci/

昨年末の記事ですが、Circle CI のコンピテンシーマトリクスについて書かれた記事が面白いので紹介します。

コンピテンシーマトリクスというのは、言うなれば会社がエンジニアに対して求めるコンピテンシーを明確化し、エンジニアを評価する際の指針となり得るものです。Circle CI では以前からコンピテンシーマトリクスを運用していたそうですが、会社の成長に伴い見直しが必要と判断したそうです。

1/ 背景

Circle CI は、どんなレベルのエンジニアであっても彼らが成長しキャリアを築ける場にしたい。そのために彼らの成長のガイドとなるようなコンピテンシーマトリクスを 3 年前に作成した。しかし、当時は小さなスタートアップだったのが、組織の成長とともにニーズが変化してきた。

・コラボレーションの重要性が増してきた。優れたコミュニケーションスキルの重要性は増し続けている。
・会社が大事にしていることが明確になってきた。自分たちのエンジニアリング文化を明文化して反映したい。

これらを踏まえ、Circle CI が大事にするカルチャーを反映しつつ、コンピテンシーマトリクスの見直しを行うことにした。

2/ 基礎を築く

本格的にプロジェクトに入る前にプロセスについて検討した。

・自分たちの価値観を反映するために最適な方法は何か？
・価値観を反映することはメンバーの成長に有用なものになるのか？

あらゆるエンジニアに何度もフィードバックをしてもらいながら作成した。
うまくいけば、コンピテンシーマトリクスは以下の機能を持つはずだと考えた。

・一貫性
・把握が簡単
・シンプル
・明快な言葉
・分かりやすい構造

3/ バリューに基づく

コンピテンシーマトリクスは、組織やエンジニアのキャリアに対する自分たちの信念に基づいたものにしたいと考えていた。私たちの信念のひとつは、キャリアパスは多様であるということ。そして可能な限り最善の方法で全員の成長を支援すること。

そこで、エンジニアとしての期待値を設定し、メンバーの成長を支援するために、このマトリクスの基礎を形成するいくつかの重要な仮定を置いた。

1. すべてのエンジニアが管理者を目指すべきであるとは考えない：私たちはエンジニアのキャリアパスのゴールがマネジメントになっているべきではないと考えている。マネジメントにはエンジニアリングとは全く異なるスキルが求められる。
2. ジュニアエンジニアでもリーダーになれる：リーダーシップはあらゆるレベルのエンジニアが発揮すべきである。我々は全てのエンジニアにリーダーシップを磨くことを奨励している。そのため、マトリクスで定義しているコンピテンシーの 1/5 をリーダーシップが占めている。
3. 成長は直線的でも合理的でもない：マトリクスはチェックリストではなく成長のためのガイドである。人によって違う成長の仕方をするが、マトリクスに基づいて彼らの成長をサポートするための議論やアクションをとることが出来る。
4. エンジニアは時間とともに成長する：時間とともに影響を与えられる範囲が増えてくる。タスクからエピック、単一のチームから複数チーム、組織にいたるまで、管掌範囲が拡がるほどスキルを頻繁に発揮する機会が増える。
5. コーディングスキルだけで優れたエンジニアにはなれない：マトリクスではテクニカルスキルは全体の 1/5 しか占めていない。同じ割合だけフィードバックやコラボレーションも重視されている。これらは優れたエンジニアとしての基礎であり、私たちが求めるエンジニアリング文化と一致している。

実際の Circle CI のコンピテンシーマトリクスは、こちらで公開されています。
https://docs.google.com/spreadsheets/d/131XZCEb8LoXqy79WWrhCX4sBnGhCM1nAIz4feFZJsEo

記事にある通り、Circle CI は組織のカルチャーを評価基準に色濃く反映しています。この基準に基づけば、優れたエンジニアが備えるべき能力のうち、技術スキルはわずか 1/5 しか占めていません。リーダーシップやコラボレーションのための能力が強く求められています。これは働くエンジニアからすると賛否あるものだと思いますが、個人的には概ね共感できる内容に思えます。

僕の勤務先でも「コンピテンシークライテリア」というエンジニアの評価基準が存在します。僕たちは 360 度評価などを通じて、このクライテリアに基づいてお互いを評価しています。しかし、このクライテリア自体は数年前、まさに Circle CI のように数人の開発者しか居なかった頃に策定されたもので見直しが必要だなという認識でいました。今回この記事を読んで、改めてやるべきことが明確になった気がします。