人 ◕ ‿‿ ◕ 人 「僕たちのサービスで、リードエンジニアになってよ！」
と、言われた時にスムーズに業務に移れるように、様々な企業でリードエンジニアの方々が行った施策を下記の３点の目線からまとめてみようと思います。網羅的に列挙するのではなく、各社の tips をまとめることで、3 点の肝を掴むきっかけになればと考えています。
- 設計・開発環境整備
- コミュニケーション
- 意思決定
0. 自社のリードエンジニアのミッションを決める
３つの視点から…といいつつも、早速脱線して０項目目…。
いろいろな記事を読んでいく中で、どこの企業でもリードエンジニアが担う責務や、貢献をしっかりと定義している企業が多かったです。
開発からマネジメントまで多岐にわたる貢献を求められるからこそ、しっかりとポジションが持つ意味を言語化する必要性を感じます。
三者のリードエンジニアの方の記事から引用していますが、大枠は共通する部分があるといえど、どの粒度で捉えるのかというのは企業や人によって異なるため、チームで共通認識を持ちやすい形で定義することが重要だなと感じました。
- Gunosy
弊社のリードエンジニアのミッションとは以下です。
高い技術力ならびに、事業ドメインへの深い知識を持ち、
事業におけるトップエンジニアとしてプロダクトの成長に貢献する
（中略）
- 技術的意思決定のデリゲーション
- 育成とキャリア
を担って欲しいという思いで設置された背景があります。
引用元:リードエンジニアとしての役割
- BASE
事業に配属され、事業の中での開発やサービス運営をリードする以上の成果を期待されたロール。 サービスの継続的発展を実現するための技術力や、BASE のサービス哲学を具現化するためのサービス開発力などを兼ね備え、圧倒的な主体性でサービスの成長に取り組む模範となるべき役割を担う。
- クックパッド
今の会社で「テックリード」に何が求められているのかを明確にするところから始めました。 ・コードやプロダクトの品質の担保 ・コードレビュー ・他部署との技術的な相談をする場合の窓口 ・メンバーの生産性を向上できるように立ち回る ・メンバーの成長を促進する ・メンバーの半期ごとの評価を行う 引用元:初めてテックリードになって半年が経ったので振り返る
1. 設計・開発環境整備
リードエンジニアに求められる役割としてアーキテクチャの設計や開発環境の整備などは最たるものの一つですが、中でも興味深かったのは未来を見据えた取り組みへのコミットが一エンジニアの立場よりも強い印象が多かったことです。
具体的には
1. 今後実装をしていく/改修していく上で障害になりうる部分を早めに対処する態度
- インフラ・サービスレベルの技術選定をしっかりと行う
- 放置気味になっている不具合の見える化・修正
- CI や環境構築の整備
2. （将来負債にならないための）現状把握と属人化しない開発チームへの投資
- 設計やコードレビューには必ず目を通し、サービスの全体像を常に把握する姿勢
- チケット管理を適切に行い、何が背景で何がゴールなのかをしっかりと定義して、誰もが共通の認識＆アウトプットを出せる準備を行う姿勢
- 開発ドキュメントの整理
- コーディング規約・テスト規約などを属人化しないように処理の切り出し先やエラーログの粒度までの設計
上記のような、すぐに成果の出るアウトプットではなく、長期的にチームの価値が高まるアウトプットを意識している方が多くいました。
2. コミュニケーション
大軸としてはチームのメンバーが最大限に力を発揮出来るようにすることを主体にコミュニケーションを取ることが肝だと感じます。
- チームの技術力の底上げのために必要な施策や挑戦の設定
- 勉強会の主催
- 責務の適切な委譲
- メンバーの進捗管理
- メンバーが開発に集中できるように他部署との窓口になる
- 1 on 1
- 心理的安全性の確保
- メンバーの日々のペインの洗い出し
また、
「チームの状態」をマネージャーやステークホルダーに見せることも自分の仕事と認識するようになり、状況共有や可視化をし始めた記憶があります。 引用元:テックリードになる前後にやっていたこと
上記のような、開発チームの状況をステークホルダーに共有する態度も大切だと感じました。
開発チームは他のチームからすると目に見える機能が求められ、それを成果と捉えられがちですが、目に見える機能を適切なプロセスで作るためにも目に見えない成果もしっかりと伝える努力を行うことで、ステークホルダーとの良い関係性構築ができると考えられるからです。
3. 意思決定
「この技術を使って進める」「この設計で勧めていく」「この時期にこの機能がないとビジネス的にまずいので、この機能の優先度を上げて開発を進める」 といった決定の部分には必ず携わるようにしました。
（中略）また、ビジネス的な観点や不具合の発生と行った形で突発的に出てくるタスクに関しても現状を加味したうえで今すぐやるか、いつまでにやるか、やらないかの決定もしてきました。今のチームの状況的に今すぐの実装が無理なら無理と、妥協なく NO を言ったりすることもありました。 引用元:初めてテックリードになって半年が経ったので振り返る
上記のように、しっかりと適切なタイミングにおける適切な粒度の問題解決がチーム全体やサービス全体を見ているリードエンジニアの大きな責務だと触れている方が多かったです。
tips でいえば、Backlog の管理や、イシューのメンテナンスをしっかりと行うという細かい点から、「何を作るか」ではなく「どうやって作るか」のエキスパートだからこその示唆を持ってサービスへの意思決定を行っていく姿勢を持つこと。
これらの態度が様々な記事を読んでいて共感できた点です。
リードエンジニアなんだという自覚を持つ 人には意識させないけど自分はしっかり自覚しておく
また、上記のような自覚をしっかりと確立していることもリードエンジニアの方々に共通している態度でした。
終わりに
昨日からリードエンジニア・サービスリードに関する様々な記事を読んできました。 彼らの多くが本当に自覚と決意を持って日々サービス開発に臨んでいる姿を見て、エンジニアという仕事の面白みを再確認できた二日間になった気がします。
記事では強い言葉を述べているリードエンジニアの方々ですが、同時に
- 一人で頑張りすぎない
- もっと人に頼るべきだった
上記のような弱さを活かすことの大切さにも触れていました。 日々の業務でも、リードエンジニアや EM の方々にリスペクトをしつつも、その負担の一部を担えるように日々ハッピーハッキングだなぁと改めて思いました（感想が小学生…）
この記事が皆様のリードエンジニアへの理解の一助になればと思います。 HAPPY HACKING!
主に参考にした記事一覧
たくさんの記事を読ませていただきましたが、その中で主に本文などで引用させてもらったもの、大きく参考になった記事を共有させてください。