「オンプレミスを、クラウドネイティブに」株式会社ラクスのSRE課では今、インフラ運用の常識を覆す挑戦が始まっています。開発とインフラの境界線を取り払い、組織全体の生産性を底上げする。そのミッションを担うのは、同社開発組織全体の約350名に対し、7名の精鋭チームです。

今回は、開発推進部SRE課マネージャーの今本様と採用担当の加藤様に、技術的な難易度と組織変革が共存する現場のリアル、そこで磨かれるエンジニアとしての市場価値について伺いました。

開発とインフラの間をつなぐラクスの開発推進部SRE課とは

開発本部において、SRE課はどのような位置づけの組織なのでしょうか？

加藤：開発本部は、大きく分けて「プロダクトごとに開発を担う組織」と、「プロダクト横断で全体最適を担う組織」の2つの構造で成り立っています。拠点は東京と大阪に分かれ、各プロダクトチームがそれぞれの製品開発に専念する体制です。

その中でSRE課は、特定のプロダクトには属さない「開発推進部」に所属する横断組織です。最大の特徴は、プロダクトの垣根を超えて全社共通で活用できる仕組みや基盤を構築・提供する点です。個別のプロダクト事情だけに縛られることなく、全社共通で利用できるソリューションや仕組みを構築・提供することをミッションとしています。

縦割りの開発体制に横串を通し、全体最適の視点で組織の生産性を設計する。支えるだけではなく、自ら課題を見つけて解決する攻めの組織です。

一般的にイメージされるSREと、ラクスが掲げるSREのミッションにはどのような違いがありますか？

今本：SREは「サイト信頼性エンジニアリング」の名の通り、システムの信頼性を高めながら、開発スピードとのバランスを取る考え方です。単なる保守運用ではなく、自動化や改善を通じて、継続的により良い状態をつくり続ける役割を担います。

そのうえで、ラクスのSRE課が明確に掲げているミッションは、「顧客価値を素早く安全に届けるために、開発組織のQCDを継続的に向上させること」です。

単にシステムを守るだけでなく、自動化によるトイル（労苦）の削減や、リリースのリードタイム短縮など、開発プロセスそのものを進化させる攻めの姿勢を重視しています。

古いものをそのまま維持する「保守」ではなく、開発者がより効率的に、かつ安全に価値を届けられるよう、組織全体の仕組みや文化を「刷新」していく。そのために、組織全体の仕組みや文化まで踏み込んで刷新していく点が特徴です。

現在その具体的な取り組みの一環として「クラウドネイティブ・オンプレミス」を推進するため、日々改善活動に向き合っています。

「クラウドネイティブ・オンプレミス」とは、具体的にどのような取り組みですか？

今本：現在、ラクスのサービスの多くはオンプレミス環境で稼働しています。コスト面でのメリットがある一方、環境構築に時間がかかることや、リリース作業がインフラチームに依存しやすいことから、リリース頻度を上げにくいという課題がありました。

そこで現在推進しているのが、オンプレミス環境にKubernetesなどの技術を適用し、パブリッククラウドのような柔軟性とスピード感を実現する「クラウドネイティブ・オンプレミス」です。

具体的には、開発者が自ら環境構築やリリースを行えるプラットフォームを構築し、開発者体験（DevEx）を向上させることを目指しています。「オンプレミス＝古い・不便」という常識を覆し、技術の力でレガシーな環境をモダンに生まれ変わらせるという、挑戦的でやりがいのあるプロジェクトです。

相互理解を深め、ミスマッチをなくす伴走型選考

SRE職の選考フローはどのように進みますか？

加藤：1次面接と2次面接の間に、私たち採用担当との「フォロー面談」のお時間をいただいています。この面談は評価を目的とした場ではありません。候補者の疑問や不安を解消し、相互理解を深めるための時間です。

面接の場では聞きそびれてしまったことや、現場の雰囲気、働き方など、企業側として提供できる情報を整理し、解像度を高めていただくことが目的です。選考の期間がやや長くなりますが、候補者が本当に知りたい情報をお届けし、納得感を持って次のステップに進んでいただくことを重視しています。

なぜ候補者に寄り添う「伴走型」の選考スタイルをとっているのですか？

加藤：私たちが大切にしているのは、ご入社いただく方が長く活躍し、幸せに働いていただくことです。そのため、良い面だけでなく、候補者にとってネガティブに映る可能性のある情報も含めて、包み隠さずお伝えしています。入社後のギャップをできる限りなくすことが大切だと考えているからです。

ご自身のキャリアにおける優先順位と、ラクスの環境が本当に合っているのか。客観的な視点も交えながら、一緒に整理させていただくこともあります。

一人のエンジニアのキャリアに真剣に向き合い、入社後のミスマッチを極限までなくしたい。そんな想いで、一人ひとりに寄り添った選考を行っています。

SREとして一緒に働くうえで、どんな姿勢や考え方を見ていますか？

今本：技術的なスキルももちろん大切ですが、それ以上に重視しているのが「課題解決にどう向き合うか」というスタンスです。SRE課は特定のプロダクトに閉じず、多くのチームと関わる立場にあります。そのため、自分のやりたい技術や手法を一方的に押し付けるのではなく、相手と対話を重ねながら合意をつくっていける姿勢が重要だと考えています。

また、技術はあくまで手段であり、目的は「顧客や開発組織に価値を届けること」です。そのためなら、特定の技術領域にこだわりすぎず、自ら学び広げていけるか、時には泥臭い調整や作業も厭わずにも向き合う姿勢も求められます。
面接では、これまでどのように課題と向き合ってきたのか、その背景や考え方をお聞きしながら、一緒にすり合わせができればと思っています。

少数精鋭で2,000名規模の組織を変えるダイナミズムと、希少性の高いキャリア

これだけの規模のサービス・組織をわずか7名のチームで支えていることの面白さは何ですか？

今本：開発本部全体で約350名規模、会社全体では2,000名に迫る規模感の中で、SRE課は現在わずか7名のチームです。一見すると無謀に思えるかもしれませんが、だからこそ一人ひとりの裁量が大きく、自分たちの意思決定や取り組みが組織全体に波及していくダイナミズムを肌で感じることができます。

例えば、あるプロダクトで進めたコンテナ化の事例や自動化の仕組みが、他プロダクトにも広がり、やがて全社の標準になっていく。7名の改善が、数百名の開発体験を変えることにつながる。このスケール感は、この立ち位置ならではの面白さだと思います。

また、まだ仕組みが完全に固まりきっていないフェーズだからこそ、既存のルールに従うだけではなく、自ら設計し、組織の前提そのものを変えていく余地があります。完成された環境で動くのではなく、環境をつくる側に回れる点も大きな魅力です。

ラクスだからこそ得られる「市場価値の高い経験」とは何だとお考えですか？

今本：最大の特長は、オンプレミス環境でクラウドネイティブ化を進めるという、技術的難易度の高いフェーズに携われる点です。パブリッククラウドが普及した今、完成された基盤を使うのではなく、プラットフォームを構築し、運用設計まで落とし込む経験ができる環境はそう多くありません。

また、アプリケーションとインフラの両面を深く理解することに加え、多くのチームと連携しながら調整や合意形成を進める必要があります。そのため、技術力だけでなく、「プロジェクトを推進する力」も磨かれます。

「特定の技術しか触れない」のではなく、組織全体の課題と向き合い、泥臭い調整も含めて変革をリードし仕組みをつくる経験は、将来どの環境でも通用する土台になると考えています。

かなり密度の濃い経験が積めそうですが、社員の皆さんはどのような働き方をされていますか？

今本：ここまで聞くと、業務負荷が高いのではないかと思われるかもしれませんが、実はSRE課の平均残業時間は月15時間程度です。
これを支えているのは、「チームで成果を出す仕組みづくり」を徹底していることです。当社が大切にしている「ゴールオリエンテッド」「着実な継続」「誠実な合理性」「不確実性の排除」といった考え方も、その土台になっています。

組織や会社が目指すゴールを着実に達成するために、一人だけが出来る状態を目指すのではなく、運用工数と属人性を排除するために、アラートの管理作業の自動化や、ランブック（対応手順書）作成の半自動化などチームで仕組みとして構築し再現性を担保することで、高い生産性とプライベートの両立を実現しています。

また、目標設定も現実的なラインと挑戦ラインを分け、無理のない計画を前提に進めています。突発的な対応が発生することはありますが、特定のメンバーに負荷が偏らないようチームで調整し、長時間労働を前提としない運営を心がけています。

SRE課にはどのようなバックグラウンドを持つメンバーが集まっているのでしょうか？

今本：インフラエンジニア出身者だけでなく、元々アプリケーション開発を担っていたメンバーも在籍しており、バックグラウンドはさまざまです。年齢層も30代から40代前半まで幅広く、社内の技術広報を担当していたメンバーも加わるなど、それぞれの強みを持ち寄ってチームを構成しています。

異なる職種や領域から集まっているため、オンボーディングに関する知見も蓄積されており、SRE未経験者でも安心して業務に取り組めます。

共通しているのは、「技術を深めたい」スペシャリスト志向を持ちながらも、個人プレーに閉じない姿勢です。専門性を磨くことと同時に、対話を通じてチームとして前に進むことを大切にしています。

新しい技術領域への挑戦には、誰か一人の知識だけでは太刀打ちできません。だからこそ、互いの専門性をリスペクトし、知識を補完し合いながらチームとして成長していく文化が根付いています。

KubernetesとGo言語を軸に、小さな「トイル削減」から組織を変えていく

入社直後のオンボーディング期間では、具体的にどのような技術習得やタスクからスタートしますか？

今本：SRE課の技術スタックの中心は「Kubernetes」と「Go言語」です。入社後の最初の1ヶ月間は、これらの基礎を学びながら、私たちが大切にしているSREとしての考え方を座学やハンズオンを通じて共有していきます。

その後は、既存メンバーのサポートを受けながら、小規模なプロジェクトやタスクを担当し、実践を通じて知識を定着させていきます。

入社3ヶ月ほどで小規模な機能実装や改修を一人で進められる状態を目指し、半年ほどで一つのプロジェクトを主担当として推進できる状態を目指すイメージです。最初から全てを任せるのではなく、段階的にステップアップできる環境を整えています。

SRE課が取り組む「トイル削減」とは、どのようなものですか？

今本：「トイル」とは、サービスの運用において繰り返し発生する、手作業で行われている定型業務のことです。例えば、ログの収集やバックアップを手動で行っていたり、開発環境の構築手順が統一されておらず個々のエンジニアが手探りで作業していたり、といった状況が挙げられます。

これらをスクリプトやツールを用いて自動化し、エンジニアが本来注力すべき「価値を生む開発」に集中できる時間を生み出すことが私たちの役割です。SRE課が運用するCD基盤やオブザーバビリティ基盤の改修といったチーム内で完結するタスクから始めることも多いですが、こうした小さな改善の積み重ねこそが、組織全体の生産性を向上させる鍵になると考えています。

今後は「新規事業」や「AI活用」といった領域にもSREとして関わっていく機会はありますか？

今本：現在は既存サービスの改善が大半を占めていますが、新規サービスの立ち上げやAI活用といった新しい取り組みに関わる機会も確実に増えています。

SREとしての関わり方は、アプリケーションの機能開発そのものというよりも、そのサービスが稼働するための基盤を整えることです。具体的には、インフラ環境の選定・構築や、スムーズなリリースのためのCI/CDパイプラインの整備などが中心になります。

新しい技術が導入される際には、必ずそれを支える土台が必要です。そのため、社内の動向には常にアンテナを張り、「いつ・どこで・何が必要になるか」を察知して、先回りして環境を整えていく動きが求められます。

SRE立ち上げに関わった今本様の「ラクスを選んだ理由」と未来の仲間へ

今本様の、ラクスへの入社理由を教えてください。

今本：実は、最初からSREとして入社したわけではありませんでした。前職はSIerでサーバーサイドエンジニアとして働いていました。
転職を考えたときに重視していたのは、受託開発ではなく、自社プロダクトを持ち、長期的にサービスを育てていける環境であること。そして、組織として安定的に成長している会社で、腰を据えて働きたいと考えたのがラクスを選んだ大きな理由です。

入社当時はまだSREという役割も明確ではありませんでしたが、社内のプロジェクト状況の変化に伴い、開発プロセス改善や基盤構築の必要性が高まる中で、SRE課の立ち上げに関わることになりました。

結果として、エンジニアとしてのバックグラウンドを活かしながら、組織課題の解決という大きなミッションに携われていることは、自分のキャリアの幅を広げる転機になったと感じています。

最後に、候補者へのメッセージをお願いします。

今本：SRE課は少人数な分、自分たちの仕事が開発組織全体に波及していく実感をを持てます。現在は「クラウドネイティブ・オンプレミス」への移行という大きな転換期にあり、整った基盤の上で動くのではなく、基盤そのものをつくる側に回れるフェーズです。

簡単な挑戦ではありませんが、その分、経験の密度は高いと思います。変化の中心で仕組みをつくっていきたい方と、一緒に取り組めたらうれしいです。

加藤：ラクスでは、SREを単なる保守運用ではなく、事業成長を加速させるための攻めの役割と位置付けています。開発やインフラの経験を活かしてもう一段視野を広げたい方。技術だけでなく、組織やプロセスの改善にも踏み込みたい方。多くの関係者と対話しながら、仕組みをつくる側に回りたい方にとっては、大きな挑戦の機会になるはずです。

完成された環境で動くのではなく、より良い状態を自ら設計していきたい。そんな思いを持つ方と出会えたらうれしいです。