GitLab のテックリード
GitLab のテックリード GitLab では、テックリードはアーキタイプでありロールでもあります。「アーキタイプとしてのテックリード」とは、GitLab の Staff 以上のエンジニアがテクニカ …
エンジニアリング IC リーダーシップ
GitLab におけるエンジニアリング IC リーダーシップ: Senior レベルを超えて
GitLab では、すべての人が one の管理者 であることが期待されています。Individual Contributor（IC）にとっては、Staff Engineer のロールから新たなタイプの挑戦が始まります。エンジニアリング IC リーダーシップは、エンジニアリングマネジメントとは別のキャリアパスです。
マネジメントへの移行と同様に、Senior から Staff への移行も日々の業務と IC に求められる期待を変えます。
エンジニアリング IC リーダーは、影響力のスコープ内でテクニカルレバレッジを発揮します。他のリーダーシップロールと同様に、他者の成長を支援することに焦点を当てるべきです。彼らのインパクトは、支援する人の数に比例して増大し、自分自身で物事を行うことに時間を割かないほど、会社により多くの価値をもたらします。
これまでのキャリアで培った技術スキルは引き続き非常に重要であり、このロールは依然としてハンズオンの技術的な仕事です。技術スキルは広範囲にわたり、変化のペースは落ちてきますが、これからのキャリアを牽引する新たなスキルも身に付けます: コミュニケーション、コラボレーション、リーダーシップです。
IC リーダーシップについての GitLab エンジニアの声
Handbook Learning のディスカッションにて、Eric（元最高技術責任者）、エンジニアリング IC リーダー、および Learning and Development チームがエンジニアリング IC リーダーシップについて議論しています。IC リーダーであることの意味について、インタラクティブなハンドブックディスカッション形式でトピックを話し合っています。
まずレベルを合わせましょう。中級エンジニアがいて、Senior エンジニアになり、道が分岐します。「マネージャートラック」または「IC リーダーシップトラック」を選べるデュアルキャリアトラックがあります。— Eric Johnson（元最高技術責任者）
ディスカッションで取り上げられた追加トピック:
- エンジニアリング IC リーダーであることの意味
- その仕事に必要なスキル
- 他のエンジニアリングマネジメントロールとの違い
- テクニカルクレジビリティとテクニカルレバレッジの違い
- すべての活動へのイテレーションの適用
- 4 つのアーキタイプと IC リーダーシップの仕事の定義
テクニカルレバレッジ
テクニカルレバレッジとは、乗数的なインパクトをもたらす技術的な仕事を行うことと表現できます。これにはコードを書くこと以外の活動が多く含まれます。
言い換えると、その仕事のインパクトが自分個人のスコープや直近・近い将来の期間を超えて、プラスの効果をもたらすということです。周囲の人々や、チーム・グループ・部門がより効率的に業務を進め、イテレーションできるよう助けるものでなければなりません。
具体例:
- アーキテクチャプロセスへの参加
- 将来的に容易に再利用できる汎用的なソリューションの実装
- 複数の問題の共通点を見つけ、一度に複数を解決すること
- トレーニングやプレゼンテーションを通じた知識の共有による効率向上
- 開発プロセスへの障壁の特定と除去
4 つのアーキタイプ
Staff エンジニアとエンジニアリングマネージャーが GitLab における Staff レベルの意味 について Unfiltered ブログ記事で見解を共有しています。各エンジニアの意見には重複する部分も多くありましたが、それぞれが所属チームや GitLab 内での経験に基づいた独自の視点を持っていました。
この視点の多様性を説明できる 業界で一般的な Staff 以上のロールに関する 4 つのアーキタイプ があります:
- テックリード は特定のプロジェクトのアプローチと実行を指導します。多くの場合、一人のマネージャーと緊密に協力しますが、焦点を絞ったエリア内で 2〜3 人のマネージャーと協力する場合もあります。GitLab では、テックリードはアーキタイプであるだけでなく、ロールでもあります。
- アーキテクト は、現在から数年先にわたって、重要な領域の方向性・品質・アプローチに責任を持ちます。技術的制約の深い知識、ユーザーニーズ、組織レベルのリーダーシップを組み合わせます。
- ソルバー は任意の複雑な問題に深く掘り下げ、適切な解決策を見つけます。特定のエリアに長期間集中する者もいれば、組織のリーダーシップに導かれながらホットスポットを次々と飛び回る者もいます。
- ライトハンド はエグゼクティブレベルのマネージャーのパートナーであり延長であり、そのスコープと権限を借りて特に複雑な組織を運営します。大規模な組織のリーダーに追加のリーダーシップ帯域を提供します。
GitLab における 4 つのアーキタイプ
4 つのアーキタイプは行動パターンです。私たちは Staff 以上の IC がすべてのアーキタイプの行動を示すことを期待しています。個人の傾向によって一つ（または複数）がより顕著になることが多いですが、これらすべてがエンジニアリング IC リーダーを定義します。
テックリード
新しい Staff エンジニアに最も一般的なアーキタイプはテックリードです。Senior エンジニアがチームから Staff レベルの行動を見せ始めることがあります。GitLab では、これはアーキタイプであるだけでなく、プロジェクト単位でエンジニアに割り当てられるロールでもあります。詳細については専用の テックリード ハンドブックページをご覧ください。
Staff エンジニアはマイルストーン計画において Engineering Manager および Product Manager と協力し、チームメンバーが成果物の複雑さに対処できるよう支援します。これは Staff 以上のレベルでも同様で、マネジメントとプロダクトの同僚と協力します。
アーキテクト
GitLab では アーキテクチャはプラクティスであり、誰でも貢献できますが、Staff 以上のエンジニアはその中で根本的な役割を担います。
プラクティスとしてのアーキテクチャは全員の責任ですが、特にシニアテクニカルリーダーシップのロールに深く根付いており、ロールのレベルと影響圏がプラクティス内の DRI 責任を決定します。
ソルバー
複雑な問題は多くの場合、複雑さを管理可能な状態に落とすために、最初のイテレーションを Staff 以上のエンジニアが担う必要があります。最も難しく、最も仕様が定まっておらず、最も不確かな仕事を常に任されることは、このアーキタイプの一部です。また、チーム内の他の IC が解決策を見つけられず苦労しているときに指導することも含まれます。
他のチームが Staff 以上のエンジニアを一時借用する必要がある場合があります。受け入れチームにすでに Staff 以上のエンジニアがいる場合もそうでない場合もありますが、ソルバーは目の前の問題に取り組み、複雑さが管理可能なレベルになった後はチームが自力で対応できるよう支援します。
ライトハンド
GitLab のアーキテクチャプラクティスに関する取り組みからの一つの結論は、複雑なアーキテクチャの変更を導入するには、Staff 以上の IC が意思決定者と緊密に協力することなしには実現できないということです。この結論は、Engineering Manager 以上と Staff 以上のエンジニアの緊密な協力の必要性を浮き彫りにしており、ライトハンドアーキタイプの定義に非常によく当てはまります。
Staff 以上のエンジニアはマネージャーの視野を広げることが求められます。意思決定者は、製品アーキテクチャへの投資について十分な情報に基づいた決定を下し、期待される ROI を理解し、そのような変更の背景にある核となる技術ビジョンを理解するために、追加のコンテキストと視点を必要とすることが多くあります。
信頼に基づく意味のある関係を構築することで、このプロセス全体がスムーズになり、技術的・管理的なリーダーシップを、単一チームから部門レベルまで、あらゆるレベルに分散させることができます。
