バクラク事業部 PlatformEngineering 部 DevOps グループマネージャーの @kani_b です。 2024年1月、人生初の転職で LayerX に入社しました。いわゆる「落下傘マネージャー」として、組織変革を期待されている (と考えている) 一方、転職経験がなかったため、試行錯誤をしながらチームの進化に取り組んできました。今回の記事では、 LayerX におけるマネージャーとしてのチーム合流について私の経験についてお話したうえで、 DevOps チームがどのように進化してきたのかをご紹介します。
最初の3ヶ月
書籍や様々な記事では、新任リーダーにとって「最初の100日」に何をするかがとても重要である、と紹介されています。現在の LayerX は基本的に四半期を単位として OKR の修正や評価などを実施しているため、私は「最初の3ヶ月」を自身のオンボーディングの区切りとしました。
自分のチームに新しいリーダーが社外から突然やってきて、「この人なんかヤバいかも⋯」と思われる行動はなんでしょうか。私は「信頼関係が構築されていない状態で、戦略やチームが信じる価値感の変更、指導的コミュニケーションなど、関係を前提とする行動をとる」ことだと考えています。目の前にあるチームが、今まさに崩壊していたり、重大な問題を抱えているのであれば、モードをいきなり切り替える必要もあるかもしれません。しかし幸いにして DevOps チームは前任のリーダーとメンバーに恵まれ、「伸びしろ」と呼べるような課題を抱えつつも重篤な状況にはありませんでした。
加えて私自身、前職で最後に SRE リードを務めたのは5年前 (その後はコーポレートエンジニアリング、海外駐在、新規事業、CTO などをやっていました) 、マインドは作ってきたつもりでも自分の感覚をまだ信じられる状況になく、技術的キャッチアップも必要でした。
手を動かし、耳を傾け、足を運ぶ
そのため、技術力、判断力、知識、コミュニケーションなど、あらゆる面で行動し実際の課題を解決していくことで、信頼⋯とまではいかなくとも、「こいつに任せてもおかしなことには多分ならないだろう」と感じてもらえるところまでを目標としました。具体的には以下のようなことに取り組みました。
- メンバーや他部署のメンバー、技術系マネージャーだけでなく営業など他部署の同僚と 1:1 など話す機会をもらう
- 通常のメンバーオンボーディングに取り組み、タスクをこなす
- これまでのチーム運営の引き継ぎ
- 実環境の課題解決に参加する
- データベースのパフォーマンスチューニング
- 障害対応
- AWS Security Hub で特定されていたが解消しきれていなかった課題の解消
- バクラクを検討されているお客様の社内ネットワーク環境のトラブルシュート (HAR ファイルの解析など)
- 認証規格などのオペレーション影響調査
- 社内発信
- AWS のアップデート情報を社内の事情に置き換えながらレポート
- パフォーマンス分析の手法や知見などの社内発表
- バクラクのプロダクト機能を使いながら把握
- 商談への同席
- 社内懇親会などに積極的に参加して勢いを発揮する
上記のような活動を通して、現状やそこに至る歴史だけでなく、今後技術的に力を入れるべき点を確認していくことができました。特にプロダクト理解や営業活動を通したお客様の理解は、それまで主に toC サービスに取り組んできた私にとっては非常に重要でした。「サービスの信頼性」と一口に言っても、事業の性質やシステムの使われ方、相対するお客様やサービスに対する期待によって、その目標が大きく異なることがあるためです。
これらの理解を通して、3ヶ月後からどのように動いていくのか、ある程度目標を作ることができました。同時に、活動を通して多くの同僚と話すことができ、何か変化を起こすにしても「何もわかっていない」とはならないだろう、という自信を持つことができました。
次の9ヶ月
オンボーディングの期間が過ぎ、新しい年度 (LayerX の期首は4月です) が始まりました。変化を起こしていくのにはちょうど良いタイミングであるといえます。前任マネージャーやチームメンバーと議論しながら、チームミッションを置き換えることにしました。
新たなミッションの設定
2023年の DevOps チームを紹介する記事にあるように、これまでの DevOps チームではミッションとして「プロダクト提供における、プロダクト開発以外の複雑性に対して、必要な抽象化を行い、プロダクト開発チームがプロダクトの価値を最速で最大化できる状態を作る」という言葉を掲げていました。これを、「お客様に価値を届けるために、プロダクト開発チームを全力で支える」という形に再定義し、その上で「プロダクトチームが爆速で開発できること、お客様が安心・安定的にバクラクを使い続けられる状態、健全さを保つことに責任を持つ」ことにしました。 いわゆるインフラを一手に引き受ける、という意思決定であり、近年のプラクティスで理想とされるような開発者との責任境界からすると、少し逆行するような状況に見えるかもしれません。しかし、サービス開発に関わる同僚全員がプロダクト開発に全力を注ぎ、より多くのお客様に安心して使っていただけるプロダクトになるために、信頼性のプロフェッショナルである DevOps チーム自身が、プロダクトそのものの信頼性を高めることに集中して取り組むべきであると判断しました。
サービス信頼性に関わる取り組みについては、以下の5分野1に分けながら改善を進めています。
- パフォーマンス
- 可用性
- キャパシティ (コスト)
- バックアップ
- セキュリティ
実際の取り組み
取り組みを全てご紹介するようなことはできませんが、上記の分野に開発者生産性に関するものを加え、例えば以下のような改善に取り組んでいます。
- 本番環境をはじめとしたデータ変更を安全に行うためのプラットフォーム導入と運用
- 全プロダクト統一ダッシュボード整備を通した、ログやオペレーションの統一
- プロダクトインシデントのハンドリングフロー改善、ポストモーテムまでのリードやサポート
- デプロイメントの Slack bot を使った自動化
- データバックアップポリシーの見直しと改善
- x86_64 から arm64 へのアーキテクチャ移行
- Entra ID Privileged Identity Management (PIM) を活用したオペレーション統制や運用の改善
DevOps から SRE へ
ここまでご紹介した取り組みを進めながら、チーム内で我々がバクラクにおいて目指すべき信頼性について、具体的な議論を深めています。取り組みの中心が徐々にサービス信頼性に関するものに進化してきたことから、チーム名称も SRE へ改めることにしました。 今後もバクラク事業部 SRE チームでは、お客様に信頼いただけるバクラクを爆速で作り上げていくために必要なあらゆることに挑戦していきます。
本記事が、SRE として、あるいはマネージャーとしてこれから転職を考えられている方をはじめ、SRE あるいは DevOps に携わる方のお役に立てば幸いです。
おわりに
バクラク事業部 SRE チームは新たな仲間を募集しています
我々は、マネージャーの私を含め4名のまだ小さなチームです。ともに、人々の「働くをラクに」するプロダクトたちの信頼性を共に高めていく SRE を募集しています。
【バクラク】SRE (Site Reliability Engineer) / 株式会社LayerX
もし少しでもご興味を持っていただけましたら、カジュアル面談の窓口もご用意していますので、気軽にご連絡いただけると嬉しいです。
コーポレートエンジニアリングとセキュリティ
本文でお話しそびれましたが、私はバクラク事業部 SRE チームのほかに、部門執行役員 CISO 兼 コーポレートエンジニアリング室のマネージャーとして LayerX 全社のコーポレート IT およびセキュリティを所管しています。 (最初の3ヶ月はこれらのオンボーディングも含めた3ヶ月でした)
すでに会場キャパシティが溢れてしまっていますが、2025/02/18 (火) にコインチェック様、メルカリ様とともにセキュリティロードマップについてお話する勉強会を開催します。こちらでは CISO としての転生サバイバルガイドについてお話しますので、ご興味のある方は是非チェックいただけると嬉しいです。
【増枠】今知っておきたい、セキュリティロードマップの描き方 (2025/02/18 19:00〜)
Platform Engineering 部のご紹介
バクラク事業部 Platform Engineering 部には SRE チームのほかに、プロダクトチーム全体の開発を最適化していく Enabling チーム、お客様に提供する ID 管理基盤であるバクラク共通管理を開発するチーム、そしてバクラクの API を開発するチームがあります。これから毎週、 Platform Engineering 部のメンバーより、最近の取り組みなどをご紹介していきますので、そちらもぜひご覧ください。それでは、次回をお楽しみに！
