SREチームのリーダーになって1年経過した

あんどぅ

SIerから事業会社のエンジニアに転職後、SREチームのリーダーになって1年経過※したので、個人的なふりかえりのためにやったことを言語化し整理します。

※ 本当は7月で1年なので先月書きたかったけど、7月は評価と目標設定に加えて障害対応などが重なりめちゃくちゃ忙しかった。。。

筆者の略歴

  • SIerで10年半、インフラ主軸で大企業向けクライアントワーク＆技術支援

  • 2021/10〜、NewsPicksのSREチームメンバーとして参画

  • 2022/7〜、同チームリーダーになり、現在に至る

SREチームの業務

Googleが提唱した サイト信頼性エンジニアリング（SRE）がチーム名の由来です。SREはサービスの安定運用と変化への対応のバランスをとるためのプラクティス(技術的実践)なので、このプラクティスを遂行することがチームの業務と完全に一致するかというとそうではありません。
とはいえ、それを体現するチームでありたいという思いがチーム名に込められていると思います。私もSREの実践によってエンジニアもユーザーも幸せなサービス運営ができるようになると信じているので、SREを体現し組織への浸透を担うチームにしたいと考えています。

古い記事をたどると、2018年1月に結成されたチームのようです。6年目のバトンをつないでいると思うと、身が引き締まる思いです。

上記のように、事業が拡大してきているという背景から、事業の成長を技術的な面で支える横串のチームの必要性が増してきたため、SREチームが2018年1月に結成されました。この半年間においては、サービスのレスポンス速度やサーバー負荷の改善などに取り組んできました。

現在のNewsPicksにおけるSREチームの業務(=周囲からの期待)は、サービスの信頼性をインフラ面から支えることと、エンジニアが開発効率を向上するための開発を行うことです。インフラチームと開発基盤チームが一緒になったイメージと捉えています。
（以前はCoreDevチームという名称だったので、開発基盤の開発が主軸だった系譜を感じます。最近の言葉では、Site Reliability EngineeringというよりはPlatform EngineeringやDeveloper Productivity Engineeringに近いのかもしれません）

チームのミッションとしては、前々→前チームリーダーが策定したものを引き継ぎつつ、内容はブラッシュアップしています。
活動の軸の言語化や、4つ目の軸としてセキュリティとコストを重視する点は私が思いを込めた部分です。

SREチームのミッションと、活動の4つの軸


チームリーダーとしての業務

OKRの策定・推進に対する説明責任と実行責任

NewsPicksの開発チームはOKRに駆動されています。3ヶ月ごとにチームの目標設定を行い、その進捗をプロダクト開発メンバー全員で毎週・毎月共有しています。

OKRとはObjectives and Key Results（目標と主要な結果）のことで、Googleなどシリコンバレーの有名企業が取り入れている、組織の目標設定・運用手法とのことです。
伝統的日本企業出身の私としては馴染みのなかった手法ですが、1年運用してみて「チームに対する期待値コントロールのツールだな」と理解しています。

事業・組織で生じている課題やチームのミッションに照らして、四半期で注力する目標テーマと成果指標を定めます。このOKRの策定・推進に対する、Accountability（説明責任）とResponsibility（実行責任）を果たすのが、チームリーダーとしての主要な業務です。

具体的には、四半期ごとの期初(1月/4月/7月/10月)のタイミングでチーム合宿※を行い、チームメンバーがやるべきと考えることを持ち寄って四半期テーマを決める議論をします。「なぜ今やるのか」や「チームのミッション」「チームのリソース」「挑戦的な要素をどこに置くか」を考慮して、着地するようチームリーダーとしてファシリテーターを務めます。
チーム内で確定したら、CTOにOKRを説明し、OKをもらいます（CTOが全開発チームの説明責任と実行責任を負っているからです）。
OKRのOKをもらったらプロダクト開発メンバー全員にOKRを宣言し、進捗・課題・達成状況を毎週リーダー会で報告、毎月プロダクトメンバー全体会で報告します。
もちろん、リーダーには説明責任だけではなく実行責任が伴うので、目標の達成に際してチームが直面する課題の解決策を考え、ゴールの達成に強いコミットメントを持って臨みます。

※チーム合宿とは：普段はチームメンバーはリモートワークですが、全員オフィスに出社して、OKR策定とタスクリファインメントとスプリントプランニングでMTG漬けの1日を過ごします。チームでランチをしたり、雑談を交えながらお互いのやりたいことを話し合う良い機会になっています。プロジェクトやチームによっては、予算を申請して本物の宿に泊まる合宿を企画しています。

ピープルマネジメント（目標設定と1on1とフィードバック、欠員補充採用とオンボーディング）

チームリーダーには「ロールモデルとなりメンバーを導く」「人を採用し、成長させる」ことが求められるため、チームメンバーのピープルマネジメントもしています。いわゆる労務管理については、みんな私よりも真面目＆誠実なのでメンバーの自主性に任せていてもあまり頭を悩ませることはありません。

社員のチームメンバーについては、チーム目標だけでなく自身が成長するための個人目標も策定します。個人目標は会社にとっても個人にとっても重要な意味があり、個人が成長し目標を達成した際に、会社のコンピテンシーを満たしより高いタイトルにプロモーション(昇給)できるような目標設定をサポートします。

1on1の目的は色々あると思いますが、個人目標で設定した目標達成のために、日常的に起きる問題解決の時間として利用できると良いと思っています。
メンバーから特に話したいことがなければ「現在はどのような状況か」「目標達成に向けたギャップはなにか」「その問題解決のためにリーダーとして支援できることはなにか」を話しています。
人間なので、体調やプライベートの事情によって仕事のパフォーマンスが出なかったりペース調整が必要になることもあります。そんな時にも心理的安全性の高い関係構築ができるよう、相互理解のための景色交換として、雑談をしたりプライベートの話をする回もよくあります。
30分×4名で、毎週or隔週(状況による)で1日2時間くらいチームメンバーのための1on1をしています。（それとは別に私個人としての1on1も4名ほどとしています）

フィードバックは、やっていることがそのまま会社のHR Handbookに記載されて公開されていたので貼っておきます（ありがたい）。「直属の上長」に当たるのがチームリーダーの私です。7月はこれが大変でした。

チームリーダーとしてOKRの達成にコミットする上で、チームに欠員がでた場合にその補充のための採用にもコミットします。
育休や異動や離職でチームメンバーが不足する場合、正社員が採用できるまで臨時で業務委託の採用をすることがあります。（この採用は後述のエンジニア採用とは別）
チームメンバーの不足による臨時の業務委託採用はチームリーダーの裁量と責任で選考・合否判断を行うことになっており、自分でフリーランスの候補者を探して面接して採用しました。
早期に戦力化してもらえるようチームの業務に関するオンボーディング資料を整えてペアワークでサポートし、その人のリリースでチームのOKRに寄与する素晴らしい成果も残してもらいました。数ヶ月後メンバーの育休復帰に伴い契約終了となることを伝えて、エンジニアコミュニティの知人の会社を次の現場として紹介するなど、お互いの感謝とともに良好な関係で送り出すところまでやりました。

プレイヤー、テックリードとしての業務

NewsPicksの開発チームリーダーは全員がプレイングマネージャーです。全員コードを書いています。
OKRの策定やメンバーの目標設定・フィードバックや業務委託採用などのマネジメント業務は時限的なイベントで、普段のスプリントでは1プレイヤーとしてチームのタスクを推進します。（もちろんマネジメント業務の繁忙時はほぼ開発できないスプリントもあったりしますが、「めちゃくちゃいいリリースができたな」と思うスプリントもあります）

例えば、チームのOKRの中で「◯◯のAWSコストをXX％削減する」というKR(Key Results)を設定した時に、私自身がこのKRのオーナーとなってチケットを切って手を動かしてタスクを片付けていきつつ、チームメンバーを巻き込んで達成にこぎ着けました。
「△△のEOLのライブラリを刷新する」というKRの中では、CoffeeScriptで書かれていたSlackのチャットボットを刷新するために私自身がTypeScriptで書き直した初期実装を作り、チームメンバーにもリリース作業を分担して手伝ってもらったりしました。
KR単位の問題解決になると、1人でチケットのタスクを推進するというやり方ではなくテックリードとして自分も手を動かしながらチームメンバーをリードしてリリースしていくやり方になります。
個人的にはこの仕事をやりきった時が一番胸熱で楽しいです。

リアクティブな業務として、他チームからの設計相談や問い合わせ・依頼の窓口になったり、障害対応やセキュリティ対応にオーナーシップを持って対策を推進することもよくあります。
別途会社ブログに書こうと思っていますが、セキュリティ関連の対応はかなり長期でオーナーシップを持って推進していました。

チーム外の横断系業務

チームリーダー業務以外にも、プロダクト開発の横断系業務として委員会活動を行っています。

エンジニア採用

エンジニア採用について採用オペレーションの取りまとめをしています。
具体的には

  • グループのHRチームとの連携

  • スカウトや面接にエンジニアを巻き込み推進

  • バックエンドエンジニア・SREの媒体スカウト判断、書類選考

  • フィードバックを受けて採用プロセスの改善

  • 新卒エンジニア採用の体制の立ち上げ

などを行いました。

テックブランディング・対外発信

テックカンパニーとしてのプレゼンスを高めるため、テックブランディングチームの一員として以下を行っています。

  • テックブログ・登壇などの対外発信のKPIを策定し、執筆依頼・登壇依頼などの推進

  • 自社／共催の勉強会イベントの企画・調整・運営

  • エンジニア採用サイトのメンテナンス・エンジニア採用との連携

私はどちらかというと裏方を手伝うくらいの参画で、他のエンジニアがリードしてくれています。

個人的に頑張ったのは、登壇などの対外発信で、NewsPicksが開発者体験の向上に取り組んでいること、SREチームが事業に貢献するための開発をしていることなど自チームの問題解決の取り組みを発信していました。
https://www.docswell.com/user/integrated1453

登壇したスライドたち

  • AWS Dev Day 2022 Japan

  • JAW DAYS 2022

  • CI/CD Conference 2023

など、比較的大きなカンファレンスにも登壇させていただきました。
エンジニアに対するNewsPicksの認知度アップやテックカンパニーとしてのプレゼンス向上に少しは役に立てたかなと思います。

チームアップ活動

プロダクト開発メンバー全体の相互理解の促進のため、全体会の運営を行っています。
この1年はチーム外のメンバー同士のコミュニケーション機会を作るために、BBQやオフィスでのオフライン懇親会を月1ペースで企画することを目標にしてきました。
ドリンクや食事の手配と、経費精算の申請が上達しました。

まとめ

マネージャーよりもリーダーを重視し評価する会社でよかった

会社の特徴だと思いますが、リーダーの上長もその上長もリーダーという役職なので、プレイングマネージャーしかいないです。中心に行くほどリーダーシップとオーナーシップが強く、業務の執行強度とバリューの体現度の高さが異常です。
マネジメントが軽視されているわけではないですが、プレイングを手放して管理職になることが評価と報酬を高めるために必要というわけではないので、自分で手を動かしてチームをリードできる人が活躍しているなと思いました。
自分もその方向性が合っていて、価値を発揮できていると感じています。

自身の成果・周囲からの評価

SREチームリーダーとしては以下の成果が出せたと思います。

  • AWSコスト30%削減やセキュリティ対応、開発生産性の向上などSREチームに期待される業務を推進し、成果をつくり、説明責任・実行責任を果たすことができた

  • チームのミッションの言語化および業務の仕組み化を行い、一部はチームメンバーに権限を移譲しチームをより強くすることができた

  • 対外発表や組織横断の活動、他チームからの相談・依頼に積極的に価値提供することでチームリーダーとしての信頼を獲得し、SREチームから他チームを巻き込むプロダクト改善活動が今後しやすくなる関係構築ができた

360°フィードバックがもらえる会社なので、周囲の方からも信頼いただき、評価をいただいているなと感じます。

今後の課題としては、チームリーダー層の評価としてはほぼカンストしてしまったので、これ以上タイトルを上げるには組織ミッション大のより大きな責任を背負っていく必要がありそうです。

次の1年はどうする

SREチームでやりたいことは無限に溜まっているので、引き続きSREチームリーダーとして邁進していきたいと思います。

AWSコスト削減やセキュリティ対応やEOL対応など、足元の草刈りを続けた1年でした。成果を出して事業にも貢献できましたが、未来を作る仕事ではなかったと感じています。他チームからの信頼資産の構築も含め、これでようやくスタートラインに立ったというところです。
次の1年こそは、SREの一丁目一番地であるSLOをプロダクト開発全体に広げていき、サービスの運用に関わる課題を根本的に解決することに挑戦したいと思います。

書き出してみると仕事量が個人でできる限界に到達しつつあるので、これ以上仕事量を増やすやり方で責任範囲を広げるのは厳しいと思いました。
人を成長させるとか、自分でやるのでなくやってもらう方向に振らないとスケールは難しいです。
とはいえこれ以上、人の成長のためのサポートや、仕事を作って人にお願いすることに時間を割くと、自分が開発したりエンジニアとして問題解決を手掛ける時間がなくなってしまうというのが、正直悩ましいところです。
マネジメントには興味がないわけではないのですが、技術に興味があって手を動かして事業の問題を解決するのが好きだからエンジニアをやっていることもあり、実務を手放したくないエゴがまだ残っていて、チームメンバーとわいわい一緒に開発したい気持ちがあります。

エンジニアリングマネージャー的な道を考え始めるのか、このままプレイングマネージャーでやっていくのか、キャリア迷子〜〜〜／(^o^)＼というところで、ふりかえりを終わります。

半年後か1年後か、また考えます。

この記事が気に入ったらサポートをしてみませんか？