IT | 中途採用 SQUARE ENIX -RECRUITING-
スクウェア・エニックスのITの募集一覧
https://www.jp.square-enix.com/recruit/career/career/support/it/index.html
※SREチームメンバー(左から):橋本、佐藤、伊賀、査、山本
こんにちは、人事部の大塚です。今回は2022年10月にインタビューを行ったSREチームのその後の状況についてインタビューを行いました。
※前回インタビューはこちら
前回はチーム発足直後のインタビューでした。今回は1年の間の変化や、直近の取り組み、チームの課題、カルチャーなどを中心にお届けしてまいります。
是非ご覧ください!
橋本:そうですね、前回のインタビュー時点では仕事に対して人数が足りなかったり、仕組みづくりの途中だったりもしたのですが、今現在はSREメンバーが私を含めて5人となり仕組みや文化など下地が出来上がって日々の仕事がスムーズに回ってきたと感じています。これらの変化についてメンバーの皆さんにあるがままをお話ししていただきたいと思っています。
査:前職では不動産会社でAI部門のR&Dと開発部門のSREをしていました。現在はクラウドマイグレーションに関わる技術検証(Kafkaなど)や監視、自動化の推進をメインにやっています。
山本:前職はSIerで、ISP事業者様のIaaSの運用・保守やAWSを使用したアーキテクチャを設計して構築する業務などを担当していました。現在はクラウドマイグレーションに関わる作業や検証を実施する傍らで、Terraformの実行環境をマイグレーションする業務を担当しています。
査:前職では幅広い業務を任せてもらっていましたが、マネージドサービスでカバーできてしまうなど、規模としてはそこまで大きなものではありませんでした。より大規模なサーバ環境に携わりより成長をしていきたいという思いが強くなりました。また当時は業務が定常化してしまったこともあり、よりチャレンジングな業務に携わりたいと考えていました。
当社の募集を見た際に、携わるシステムが大規模なサービスであり、かつコンテナ技術を使っていくことに対して興味が強く応募しました。カジュアル面談からスタートし、具体的な業務内容やミッションを知り、より挑戦したい気持ちが高まりました。
最終的には当社以外の会社からもよいお話を頂きましたが、趣味がゲームであり、当社のRPG作品が好きであったこともあり、当社へ入社を決めました。
山本:当時転職を考えたきっかけはSREの業務にチャレンジしたかったからです。前職時代VM上で動いているシステムの運用業務を担当していました。その際に多くの運用の工数や手作業による事故を改善したいと思い調べている中でSREという考え方に出会いました。SREの業務を通じて当時感じた悩みや疑問を解決できるのではないかと考えました。
面談や選考を通じてチームの発起人である橋本さんから当社のSREに関する活動のきっかけや考え方、推進する上での課題、直近の取り組み等を聞いて元々SREを目指そうと感じた原体験と近い話も多く非常に共感しました。
また、自分が魅力的に感じるサービスにSREとして貢献したいという思いもあり、昔から当社のゲームのファンであることも決め手でした。初めての転職で、技術的な部分でついていけるか不安はありましたが、チームの方針や雰囲気も良く入社を決めました。
佐藤:仲間が増えてこれまで対応が出来ていなかった IaC や CI のリファクタのような改善系タスクや、 Cloud SQL Enterprise Plus といった新規技術の検証、導入などを積極的に実施出来るようになりました。
また、これまでも雰囲気はよかったですが、査さん、山本さんが入りよりチームの雰囲気がよくなったと感じています。業務以外でも一緒に飲みに行ったり、カラオケに行ったり、ゲームをしたりしています。このようなコミュニケーションを通じてメンバー間で気軽に意見を言い合える関係性になっており、業務が円滑に進められていると感じています。
ちなみに査さんは中国出身にもかかわらず普段は日本語を流暢に話しているのですが、議論が白熱するとたまに出てくるメンバーの関西弁を別の人が翻訳するという日常を見ることがあります(笑)こういった楽しい雰囲気で業務に取り組めています。
伊賀:佐藤さんの言う通り、メンバーが増えてこれまで対応してこなかったタスクに対応出来るようになりましたね。このチームでは誰がやっても同じアウトプットが出来るように取り組んでいます。個々人で得意領域は持ちつつも、属人的にならないようにもなりますし、広く取り組むことで、システムの全体像を理解した上で日々業務を行っています。
また、人数は増えましたが統制が厳しくなっていると感じていません。課題があったときにはメンバーで集まって解決に向かって意見やディスカッションをすることが多いですね。
査さん:佐藤さん、伊賀さんも言っていましたが、定常業務とクラウドマイグレーション業務を皆で出来るようになったことは大きいなと感じています。自動化へ注力も出来るようになったため、チームの業務効率もよくなっています。メンバー間の仲は良いと感じています。コミュニケーションも活発で業務もとてもスムーズに行えています。
査:私が入社した時はクラウドマイグレーションをこれから始めるタイミングでした。当時は今よりももちろん人は少なく、その中で決めなければいけないことが多数ありました。また運用業務とマイグレーション業務が多く改善したいなと思っていた課題があっても中々手を付けられなかった状態でした。
現在では属人化が減ってきていて、トラブル対応を皆で出来るようになってきています。個人で得意な部分を伸ばしつつ、苦手な所も埋められるような働き方が出来るようになっている為、チームとしても勿論、エンジニアとしても成長を実感しますね。
佐藤:主に2つのことを意識しています。
1つ目はこれまでも話題に出ていますが、全員がチーム内の業務を全て一通りできるようになることです。具体的には、メンバーがこれまで対応した経験がない業務を積極的にアサインし、各メンバーができる業務を増やすことを意識しています。また、実施したことのないタスクをアサインする際には、ドキュメントだけで伝えるのではなく、対象のツールがどのように動作しているものなのか、どういう目的で作った仕組みなのかを伝えたり、必要に応じてペアプロをしたりすることで、アサインされる側のメンバーが可能な限り不安や疑問がない状態で取り組めるように意識をしています。
毎朝の朝会で個人のタスクを全員で共有しているため、お互いの得手不得手や対応経験のあるタスクなどをメンバー間で理解した上で進められています。
2つ目は業務を楽しく実施出来るようにすることです。1つ目にこれまで対応した経験がないタスクを積極的にアサインするという話をしましたが、それだけではモチベーションを維持することは簡単ではありません。
日々、各個人にやりたいことや興味があるタスクが何なのかをヒアリングをしてアサイン時に参考にしています。中には積極的にやりたくはない面倒なものもあると思いますが、その際にはそれを行うことで解決する課題やチームへのインパクト等を説明して前向きに取り組んでもらえるように工夫をしています。
伊賀さんからもあった通り、課題や困ったことがある場合はメンバーが集まって解決に向かうカルチャーがあるため、苦手な業務を担当する際も困ったときには助けてもらえる安心感を持ちながら取り組めていると感じています。
伊賀:これまで出来なかったことが出来るようになり、楽しさや嬉しさは感じますね。個人だけでなく、対応できる人が複数になり、チームの底上げにつながっているなと実感しています。
査:私の場合、MySQLの構築は前職で触れてこなかった分野でした。現在のチームで関連するタスクをアサインしてもらい、構築が出来るようになったことに加えて、他の領域に対しても得た知識や技術を活かすことが出来ている為、エンジニアとしての幅や、地力向上につながっていると感じています。
山本:私は入社して間もないため初めて行うことばかりですが、ゴールだけでなく背景も説明してもらえて、全体感を理解できるように努めてもらっていると感じています。そのため、次に同様な内容を実施する際にスムーズに取り組めています。様々なタスクを通して知識が繋がっていき、分かることが増えていくことが楽しいです。
佐藤:コミュニケーションを常に取れるようにしていることですね。チーム内外問わず、困ったら気軽に会話することを大事にしています。
査:そうですね、Slackを活用しており、チームのハドルミーティングには常にメンバーがいます。最初は橋本さんの提案でコミュニケーション活発化のためにやっていたのですが、今だとそれがスタンダードになっていますね。
伊賀:誰がいるのかも在宅勤務でもすぐにわかりますし、仕事で気になったこともすぐに意見をもらえます。仕事以外の話も気軽に出来る空間にしているのもポイントだと思います。山本さんは最初戸惑い等はなかった?
山本:メンバー間でどういう業務を行っているのかを知るためにハドルに入りました。最初は話しかけていいのか迷う気持ちもありましたが、チームメンバーに多く話しかけてもらえて、話しやすい雰囲気が出来ていたこともあり、次第に自分から会話や相談もしやすくなりました。
佐藤:他には、チーム内での認識合わせをする際には積極的に図を用いて説明するようにしています。これによって、今どういう状況で、何をやりたくて、何に困っているのかを同じ土俵で議論しやすくなっていると感じています。言葉やテキストだけでは伝わらない内容や、全体像が見えにくいことも多いため、聴く人への配慮でありながら、伝える側も情報の整理をするトレーニングにもなっています。
山本:私が入った際にはすでにある程度仕組みが出来上がっているフェーズであったこともあり、インフラ構成や業務知識が複雑だったため、キャッチアップが大変でした。橋本さんと話し合って、システムの全体的な理解を深めるためにオンボーディングの期間を3か月程度に設定しました。
この期間は自己学習と運用業務を通じて、業務知識を得ていきました。インフラはコードベースで管理されているため、コードを読みこみ全体像を把握しました。
また、運用業務を振ってもらい、ときにはペアプロを実施しました。タスクを実施する際は作業手順だけでなくどういう仕組みで動いているのかも解説してもらえたので、知識が不足しているところを補うことが出来、自己学習が進みました。これらでもわからない知識はメンバーに質問を行い、得ることが出来ました。質問をすると大抵すぐに回答してもらえたため、チームメンバー全員の理解度が高いと当時感じました。
最終的にはインプットしたシステム構成を薄板に書いて説明をするテストを実施しました。これまで得た知識をメンバーへアウトプットし、メンバーからは補足事項や考慮すべきポイント等のアドバイスもらえました。これらの取り組みで元々想定していた3か月のオンボーディング期間を2ヶ月でクリア出来ました。
伊賀:課題に対して自動化を行い、なるべく個人に依存せずに正確性を持った形で改善のアプローチを取ることが多いです。
印象に残っているのは、業務が軌道にのるに連れて必要なデータベースも増加し、1回のリリースでサーバー構築とデータ移行が数十台になる場合もあり、データベース構築業務でチーム全体が疲弊していた時期がありました。このときは 1000 行を超える Yaml の構成ファイルとそれに付随するパラメータを正確に変更し構築することが難しく、構築の物量が多い且つ手戻りが多い状況に陥っていました。
それを解決するために管理性に優れたスプレッドシートで全ての構築パラメータを含めサーバーを管理し、そこから Terraform 実行用の Yaml ファイルを生成することで自動化し、構築速度と正確性を両立してサーバー管理と構築を行えるようにしました。
佐藤:確かに伊賀さんが言うように出来る限り自動化を行い正確に対処できないかをよく考えていますね。これ以外では、このチームでは課題や壁に対してチーム一丸となって向かっていく特徴があるなと感じています。
具体的にはある案件で、構築したAPIが性能要件を満たせずに困ることがありました。朝会で状況をメンバーに伝えた際に自然にチーム全員でハドルに集合して、どこがボトルネックになっていたかを議論したり、 syscall, tcpdump を細かく確認を行う等して、レスポンスをミリ秒単位で調整しました。
こういった何が原因で上手くいっていないかわからない中で調査を一人で行うのは、メンタル的にも負荷が大きいですが、チーム全員でどうにかしようという姿勢があると前向きに向き合えますし、様々な意見が出ることで解決のスピードも速いと感じています。
査:チームの人数不足により、自動化が進んでいなかった構築初期の技術的負債がまだ残っていると感じています。具体的には、Terraformリソース間の依存関係が最適化されていない箇所や、暫定で開発したログ監視ツールがそのまま利用されているといった課題があります。そのため、Terraform CloudなどのSaaS導入検討、監視体制の最適化などを通して、チーム全体の運用工数削減と生産性の向上を図りたいと考えています。
伊賀:技術的負債以外では、前回のインタビューの際に触れたシェアリングリーダーシップに関してですかね。当時と比べても確実に出来てきているなと感じる機会は増えてはいるものの、現状の課題としては佐藤さんに一部の役割が集中していることはあると思います。先日佐藤さんが不在となる日が続いたのですが、その際にメンバー内でも話題になりました。現在の状況をメンバー内ではSPOS (Single Point of Sato) と呼んでいます(笑)。この状態をどうすればよいか、佐藤さんにどのような側面での負荷が増えているのかメンバー内で棚卸をしました。現在は棚卸をした内容を元にそれぞれメンバー内で出来ていないタスクや役割を担えるように分担を行っています。
佐藤:チーム文化の観点では、メンバーそれぞれがチーム内に留まらず組織的に課題がないかを常に意識し、新しいタスクを自由に推進するメンタリティと気軽に率直な意見をぶつけ合えるような信頼関係を持ったチームにしていきたいです。
また、SREの観点では、実際にゲームを遊んでくれるユーザー体験の向上は勿論なのですが、開発者が迅速に開発できる環境や仕組みづくり、運用における監視や障害対応の辛さを可能な限り減らした、全ての人が快適に利用できるシステムを作れるチームを目指していきたいです。