エンジニアには明確なキャリアパスが必要です。キャリアパスが示されてこそ、有意義なキャリアアップの道のりについて理解し、計画を立て、実行することができます。このキャリアアップのためのフレームワーク (CircleCI ではコンピテンシー マトリックスと呼びますが、キャリアラダー、能力開発ラダーとしても知られています) を提供することは非常に重要であり、従業員の育成を目指す企業の責任でもあります 2018 年初めの時点で、CircleCI には 32 名の開発者が在籍しており、同年内にこの数を 2 倍にする計画がありました。CircleCI では、当時からコンピテンシー マトリックスを利用していましたが、長らく更新されておらず、しかもジュニア レベルに重きを置いた内容になっていました。当然、何名かの開発者は既にこのレベルに達しています。さらに、このコンピテンシー マトリックスには、過去には重視されていなかったものの、徐々に社内で評価されるようになってきたスキルが反映されていませんでした。そこで、コンピテンシー マトリックスの再設計に取り掛かることにしたのです。

新しいコンピテンシー マトリックスを作成するには、長い時間をかけてさまざまなことを学ぶ必要があり、完成までに 8 か月ほどかかりました。その過程では CircleCI の価値観についてさまざまな発見があり、キャリアラダーを構築するための重要なステップ (と不要なステップ) についても明確になりました。コンピテンシー マトリックスは、それを作成する企業の価値観を反映しているものなので、内容は企業ごとに異なりますが、チームを導いていくわかりやすいキャリアラダーを作成するためのプロセスはほぼ決まっています。

同年 12 月に新しいエンジニアリング コンピテンシー マトリックスを公開すると、同じようなシステムを採用しているチームからたくさんのメールが寄せられました。そのフィードバックを参考にしながら、CircleCI におけるコンピテンシー マトリックスの作成手順と、そこから得た学びをシェアしたいと思います。ゼロから試行錯誤する手間を省き、無駄なく短期間で有意義な結論を導き出すために役立てていただけると幸いです。

皆さんが、社内で合意の取れている成長パスを、従業員や部下にわかりやすく明確に提示したいと考えているなら、ぜひこのブログ記事をご一読ください。

コンピテンシー マトリックス

ステップ 1: メイン プロジェクトとして担当する責任者を割り当てる

振り返ってみると、これが長い再設計プロセスの中で最も重要な要素でした。当初は私自身、このプロジェクトを多数のサイド プロジェクトの 1 つとして捉え、早朝、深夜、週末しかプロジェクトに時間を割いていませんでした。魅力的なプロジェクトでなかったわけではありません。熱心に取り組んでいました。ただ、十分に時間を費やす余裕がなかったのです。

そんなとき、エンジニアリング部門の新任ディレクターとして Lena Reinhard がプロジェクトに加わりました。彼女にとっては初の大きなプロジェクトです。以降は彼女と一緒にプロジェクトを進めていましたが、彼女が責任者になったことで、それまで私が関与できる時間が限られていたためにプロジェクトがどれほど滞っていたのかをすぐに実感できました。もしあのまま時間の空いたときにだけプロジェクトを進めていたら、年末までにマトリックスを完成できなかったかもしれません。

このプロジェクトに取り組むときは、最優先のタスクとして担当する責任者を決め、十分に力を注ぐことが重要です。

ステップ 2: 目指すゴールについてすり合わせる

どのようなゴールを目指すのか、関係者全員から合意が得られなければ、実装しようとしてもうまくいきません。

コンピテンシー マトリックスは、文化的なトーンと方向性を決める強力なツールです。そのため、設計段階では、影響の大きい選択をいくつも行う必要があります。1 つひとつの選択が何らかの結果を生むわけですが、チーム内で合意が取れていなければ、望ましい効果を得ることはできません。CircleCI の場合は「これは現在の体制を文章に書き起こしたものだろうか、それとも意欲をかきたてる内容になっているだろうか」という点を何度も繰り返し検討しました (プロセスの中盤になってようやく、その両方が混ざっているということで明示的な合意に至りました)。

もう 1 つの合意のポイントは「影響を受けるのはだれか」という点です。CircleCI では、新しいマトリックスがサイト信頼性チームのエンジニアに影響を及ぼすかどうかを議論しました (「影響を及ぼす」という結論で合意しました)。これについては、全社規模のマトリックスを作成するのか、フロントエンドの開発チームのみを対象としたマトリックスを作成するのかでも変わってくるでしょう。影響が及ぶ範囲に応じて、どのコンピテンシーを盛り込むべきか、どの程度の抽象化が必要になるかが大きく変化します。その意味でも、これらのポイントを確認し、明示的な合意を得ることが必要です。

最後に、マトリックスのゴールについて合意する必要があります。CircleCI の 1 つめのゴールは個々のエンジニアのパフォーマンス評価を行い、成長プランを策定すること、2 つめのゴールは採用プロセスにも適用し、さまざまなレベルにおいてどのようなエンジニアを求めているのかを対外的に伝えることでした。想定される用途とその優先度を確認しておけば、それぞれの決断を下すうえで判断材料となります。

ステップ 3: 価値あるコンピテンシーを洗い出す

私にとって、全プロセスの中で一番楽しかったのがこのステップです。ここでは「会社にとって何が重要か」について腰を据えて検討します。CircleCI では、人事部門の優秀な責任者 David Mann の協力を得ることができました。Mann は、プロフェッショナルとして価値の高い 100 の行動特性をノート カードにまとめてきてくれました。これらはエンジニアだけにフォーカスしたものではなく、コミュニケーションから政治意識まで多岐にわたっていました。有力なアイデアを生み出すために、公開されている他のコンピテンシー マトリックスも参考にしました。

チームとして私たちが何に価値を置いているかを考えるのは楽しい経験でした。私にとって最も重要なコンピテンシーは合理的思考です。経営チームも、選り抜きの優れた開発者を識別する主要なスキルとして、これに関する議論を重ねていました。このコンピテンシーは、人事部門が提供してくれたメモや、参考にしたその他のマトリックスから借用したものではありません。私たちは最初から、これを最終的なマトリックスの主要コンピテンシーに含めるものとして考えていたのです。

手広く始めて、夢は大きく。最初は網を大きく広げておき、必要に応じて後から統合したり削除したりすることをお勧めします。

リストが完成したら、類似したコンピテンシーを合体させると、後工程で時間を節約できて助かります。CircleCI の場合は「実用主義」と「合理的思考」を 1 つにまとめました。どちらも同じ行動につながることに気づいたからです。

ステップ 4: レベルを定義する

実際にコンテンツの作成を開始する前に、マトリックスの X 軸を定義しておきましょう。X 軸が示すのは肩書、職務などのレベルアップです。CircleCI では、既存の肩書 (E1 / アソシエート ソフトウェア エンジニア ~ E6 / プリンシパル ソフトウェア エンジニア) を使うことに決めていました。次に、肩書ごとに一般的な責任範囲を決定し、それについて明示的な合意を取り付けました。

さらにこの肩書を、各コントリビューターにフォーカスした 2 つのカテゴリに分けました。E1、E2、E3 はソフトウェア エンジニアリングのスキルを習得し、きわめて有能な IC になることに重点を置きます。E4、E5、E6 はこれらのスキルによってインパクトを高め、大規模なグループでレバレッジ効果を生み出すことに重点を置きます。大まかなガイダンスが完成したら、レベルごとにスコープを割り当て、細かい点を詰めていきます。CircleCI では中身を作成する前に、次の方針を作成しました。

  • E1 ~ E3: 業務を遂行する
    • E1: タスク内の業務
    • E2: プロジェクト内の業務
    • E3: チーム内の業務
  • E4 ~ E6: スキルを生かして幅広い効果を生み出す
    • E4: チームへのインパクト
    • E5: 関連する各チームへのインパクト
    • E6: エンジニアリング部門へのインパクト

これはルールではなく、あくまでもガイドラインです。たとえば、E4、E5、E6 には、それぞれ異なる頻度で、組織の手段やプロセスに貢献することが期待されています。何かを追い求めるとき、理論よりも実践のほうが難しいものです。キャリア開発にも同じことが言えるでしょう。しかし、あらかじめ明確なガイドラインを設定しておくことで、摩擦の小さいパスを通過しやすくなり、さらに複雑で困難なパスに多くの時間を割けるようになります。

ステップ 5: コンテンツを作成する

このステップは最も骨の折れるステップですが、ステップ 1 ~ 4 をきちんと行えば、私たちのときよりもはるかにスムーズにこなせるはずです。CircleCI では、プロセス全体を通じてこのステップに何回か挑みましたが、最初は適切なアプローチを形成するためのフレームワークを持っていなかったので、目的もなくチグハグになっているように感じていました。フレームワークを確立した後は、コンテンツの作成がずっと楽になりました。

このステップをいっそう充実したものにするために、さらにいくつかのステップに分けてみましょう。以下のステップを踏むことで、無駄な作業を最小限に抑えられます。

  1. すべてのコンピテンシーをいずれかのレベルに割り当てる
  2. コンピテンシーを統合できる可能性を探る
  3. 残りのレベルを完成させる
  4. 推敲する

ステップ 5.1: すべてのコンピテンシーをいずれかのレベルに割り当てる

まず、それぞれのコンピテンシーを、シニア ソフトウェア エンジニアなどのいずれか 1 つのレベルに割り当てることを強くお勧めします。E2 と E3 でフィードバックを返すときに微妙な違いを出すようにこだわるよりも、コンピテンシーごとに単一のレベルを設定して具体的に説明するほうが伝わりやすく、プロセスと同調させやすくなります。

CircleCI はこれとは少し異なったアプローチで、E3 (トップ レベルの個人コントリビューター) と E4 (インパクト拡大を担う最初のポジション) の 2 つのタイルを定義することにしました。業務遂行とインパクト拡大の 2 段階に分けることで、CircleCI の開発者がそのキャリアにおいて重要なステップを踏みながら成長を遂げていく様がイメージしやすくなります。

ステップ 5.2: コンピテンシーを統合できる可能性を探る

各コンピテンシーをいずれかのレベルに割り当てる過程で、同じ行動を目指しているコンピテンシーがいくつか見つかる場合があります。そんなときは 1 つにまとめましょう。

私たちはコンピテンシーのレベルを定義した後、「セルフ スタート」と「デリバリー アカウンタビリティ」という不思議なほどよく似たタイルがあることに気付きました。この 2 つのコンピテンシーは一見すると違ったものに思えますが、それぞれについて説明した行動は非常によく似ていたため、「信頼性とデリバリー アカウンタビリティ」という 1 つのタイルに統合しました。

初期段階で、マトリックスはできる限りシンプルなものとし、CircleCI の開発者にとっての成長の定義をもれなく重複なく記載するという明確な合意を交わしていたからです。最終的に、27 個のコンピテンシーに絞り込みましたが、ステップ 5.1 を開始した時点ではまだ 50 近くも挙がっていました。コンピテンシーごとに求められる行動を定義することで、まとめられるコンピテンシーが見つけやすくなりました。

ステップ 5.3: レベルの定義を完成させ、推敲する

マトリックスに行動とコンピテンシーを書き込めたので、後は残りのセルを埋めましょう。このステップにはたくさんの作業が必要です。しかし、マトリックスの中核となる重要なステップでもあります。

このステップは、推敲を始めるのに最適です。「合理的思考」を 1 つのチームまたは複数のチームに適用することの本質的な意味について知恵を絞って検討しているときこそ、意図が的確に伝わるような表現を使っているかどうかを批判的な目で見極める最良のタイミングと言えるでしょう。このステップよりも前の段階で推敲を始めることはお勧めしません。最初に定義したタイルを再検討するにはこのステップが絶好の機会です。

ステップ 5.4: 一貫性に注意して表現を磨く

個々のタイルを定義しているうちに、既に定義の終わったタイルに適用したいことが出てきたと思います。プロセスの半ばで、Lena と私は「たいてい」と「通常」をほぼ同じ意味で使っていることに気付きました。この作業では一貫性に主な焦点を当てているので、「通常」に統一することに決定し、後でこの変更を適用することにしました。

皆さんにも、同じようなアプローチを採ることをお勧めします。文章を磨く (「たいてい」を「通常」に統一するなどの) 機会が見つかったら、それを書き出して、最終段階で使用する To-Do リストとして使用します。そうすれば、いちいち何度もさかのぼって修正しなくても表現の矛盾を解消することができるだけでなく、表現の揺れを最小限に抑え、一貫性も確保できます。

ステップ 6: 影響を受ける関係者からフィードバックをもらう

さあ、ここまでのステップでコンピテンシー マトリックスが完成しました。と言いたいところですが、まだするべきことが残っています。ここまでに定義した価値観と行動を文章にまとめ上げ、エンジニアリング部門の VP の承認を得て、最終版を世界に公開するところまでが定石ですが、それで終わりにしては意味がありません。このマトリックスは、CircleCI のカルチャーや雇用に影響を及ぼすだけでなく、CircleCI で働くすべての人のキャリア成長の土台を形作ることになります。そして、私たちにとって重要なのは、この人たちのキャリアなのです。何か月もかけて複数のマトリックスを作成し、検討してきましたが、いよいよ検証に入る必要があります。私たちも最初の段階を終え、フィードバックを収集することにしました。

Lena が、あらゆるレベルのコントリビューター、マネージャー、人事部門担当者から成るフォーカス グループの形式で、すばらしいフィードバック セッションをアレンジしてくれました。セッションはリアルタイムと非リアルタイムの両方で行われました。フィードバックを収集するには、たとえば多彩なコントリビューターにマネージャーとの自己評価をシミュレーションしてもらうなど、さまざまな方法があります。どのような方法を使う場合でも、このマトリックスに影響を受ける人々からフィードバックを収集することが重要です。

収集したフィードバックからは、的確な疑問を浮かび上がってくると共に、それを踏まえて意図が正確に伝わるようにマトリックスを微調整できるので、非常に価値があります。このプロセスを通じて、たった数人のマネージャーの価値観ではなく、組織全体の価値観を明文化することができます。自社の価値観の中でレベルごとにどのようなスキルが求められるかを確認することで、エンジニアは自身のキャリア成長を描けるようになります。これによって、自分たちが開発してきたものは組織に求められていたものであり、好意的に評価されるだろうという自信につながるため、非常に重要なステップと言えるでしょう。

ステップ 7: 公開する

いよいよ待ちに待った公開の瞬間です。推敲とストレス テストが完了し、組織内の重要な関係者たちから承認を得たコンピテンシー マトリックスが完成しました。しかし、すべてのプロセスが完了しても、マトリックスが完璧になることはありません。実際に運用してテストし始めると、小さな矛盾や改善点が見つかるからです。今後も継続的にフィードバックの収集が必要になるので、準備しておきましょう。

この時点では、フィードバックを収集する方法と、フィードバック収集に対応するためのタイムラインを準備して承認をもらう必要があります。コンピテンシー マトリックスの内容の見直しを何度も行うことはお勧めしません。なぜなら、会社のキャリア開発の目標が何度も変わってしまうことになるからです。かといって、完璧に仕上がっているふりをして、まったく見直しを行わないのも現実的ではありません。

フィードバックを収集するメカニズム (CircleCI で使用したのは Google Doc) を用意したら、フィードバックから学んだことを踏まえて 6 か月ごとにマトリックスについて再検討しましょう。そうすることで、マトリックスの恒常性を確保しつつ、時間をかけて更新や強化を重ねていくことができます。皆さんも同じ目標を達成するためのメカニズムをぜひ用意してください。

ここまで来れば、皆さんのコンピテンシー マトリックスも完成です。お疲れ様でした。このガイドによって皆さんが CircleCI よりもはるかにすばやく簡単にコンピテンシー マトリックスを作成できたようでしたら幸いです。

コンピテンシー マトリックスの作成についてご意見、ご質問、ご自身の体験談などがありましたら、メール (justin@circleci.com) または Twitter (@JustinC474) でぜひお聞かせください。

追伸: 個人の成長とキャリアアップを重視するカルチャーの一員になりませんか? CircleCI では新しいメンバーを募集しています

関連記事