「技術に興味がない」と言い切って入社した私が、ゲーム開発者のためのSREとして駆け抜けた1年間
本文の状態
日本語全文を表示中
詳細モードで約9分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
DeNA Engineering
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
はじめに
こんにちは！25 卒で新卒入社し、ゲームサービス事業本部開発運営統括部第一技術部ゲーム開発 SRE グループ、「通称：ゲーム開発者のための SRE チーム」に所属している重本玲奈 (@ray_asymme) です。
気づけば入社から 1 年が経過しており、技術のインプットやキャッチアップに追われながらも、エンジニアとして充実した日々を過ごしています。
私は就職活動の時から一貫して、あるスタンスを表明し続けて入社しました。それは、「技術そのものには興味がありません。技術を『どう使うか』にしか興味がないです。」というものです。大学時代は、技術と人間の接点を探る「ヒューマンコンピュータインタラクション (HCI)」を専攻しており、常に「誰が」「何のために」ものを使うのか、「何がしたいのか」という目線で物事を考えていました。
そんな私が、昨年度の 8 月に配属されたのは「ゲーム開発者のための SRE」というチームです。
SRE（Site Reliability Engineering：サイト信頼性エンジニアリング）といえば、インフラや CI/CD のゴリゴリの技術者集団という印象があり、インフラ知識もゲーム開発経験もほとんどない自分が、道具としての技術すら良くわからない状態で、果たしてやっていけるのかと配属当初は心配で仕方ありませんでした。
この記事では、そんな私が「ゲーム開発者のための SRE」チームの一員として、1 年間で感じたこと・学んだことをお伝えします。
ゲーム開発者のための SRE
そもそも、ゲーム開発者のための SRE とは何か。私たちのチームは一般的な SRE とされる方たちとは少し毛色が違います。
一言で言うと、私たちは「ゲーム開発に携わるすべての人を楽にするために、なんでもやる人たち」です。そのスタンスの根底には、明確な MVV（ミッション・ビジョン・バリュー）があります。
- VISION
開発チームが「楽」してゲーム開発・運営ができる場を作る
- MISSION
ゲーム開発におけるプロダクト・プロジェクト上のサービスの信頼性を担保する
- 開発フロー・対ユーザーサービスを運用し、信頼性の高いサービスを提供する
- 50%ルールを守り、エンジニアリングによる継続的な改善を行う
- VALUE
自動化・自働化：積極的な自動化・自働化は SRE の使命です。
- チームメンバーはお客さん：開発に関わるすべての人をユーザーと捉え、内外関係なく改善を行います。
- ポストモーテム：失敗から学び、共有し、繰り返しを避けます。
この MVV を体現するため、私たちは現在、次の 2 つのフェーズを重視して開発・運用に向き合っています。
- 「まずはできる」体制を作る
ワークフローの運用からトイル（定常作業）を削減・標準化し、安全性・信頼性の高い環境を構築する。
- 「誰もができる」体制にする
属人性を徹底的に排除し、安定運用と改善を継続できる仕組みにしていく。
やることは多岐に渡り、開発者体験の向上・障害の再発防止・心理的安全性の向上など、必要であれば本当になんでもやります。
これらを実現するために敷いているのが、ミッションにもある「50%ルール」です。業務時間の半分は目の前の運用に使い、残りの半分は「将来を楽にするための開発（改善）」に投資する。常にこのサイクルを回し続けるのが、私たちのチームのスタイルです。
私たちのチームの取り組みについては、CEDEC 2024 でも発表しています。詳しくはこちらをご覧ください。
1年間で向き合ったタスク
私は、この1年間、開発チームが「楽」してゲーム開発・運営ができる場を作るために、さまざまなタスクを実行しました。
具体的なタスクとしては以下のようなものです。
- ビルドマシンリプレイス / OSバージョンアップ
- GitHub Actionsのランナーおよびワークフロー運用・保守
- ランナーの死活監視の通知
- IaC（Infrastructure as Code）の運用・保守
- Unity Licensing Serverのサーバー構築・運用
- GitHub Enterprise ServerからGitHub Enterprise Cloudへの移行
- 非エンジニア向けのセットアップ手順の単純化
- ドキュメントの作成・整理・共通化
一見すると、インフラ寄りの技術的なタスクも多く、知識も経験もゼロの私にとっては、どれも最初は呪文のようでした。
しかし、私はこれらを、「開発者という『ユーザー』の体験を良くするためのデザイン」だと捉え直すことにしました。エラー文を分かりやすくすること、ビルドを1分早くすること。そのすべてが、開発者のストレスを減らすためのアプローチだったのです。
セットアップ手順の改善で気づいた「デザイン」の視点
PCのセットアップを対象とした「非エンジニア向けのセットアップ手順の単純化」というタスクでは、自分の視点が広がる経験をしました。
初めにこのタスクを任された時、私は「指定されたコマンドをコピー＆ペーストすれば、誰でも失敗せずにセットアップできるものにしよう」ということだけを意識していました。手順をシンプルにすることだけがゴールだと思っていたのです。
しかし、立ち止まってよく考えてみました。どれだけ手順を単純にしても、環境や状況によってエラーを完全にゼロにすることはできません。だとしたら本当に必要なのは、単なる手順の単純化だけでなく、「失敗したその後のコミュニケーションまでデザインすること」ではないか、と気づいたのです。
改善を加える前は、システムログがそのまま出力されるだけで、非エンジニアの方からすると「無事に終わったのか、何に失敗したのかすら分からない」状態でした。そこで、成功時は緑、失敗時は赤で画面に表示し、一目で状態が伝わるように改善しました。さらにエラー文を修正し、成功・失敗を明確に文字でも出し、何が原因のエラーかも出すように工夫しました。この工夫により、次のように変わったのです。
- 非エンジニア視点：実行の成否が色や文章でパッと分かる。さらに、失敗の理由が明確なエラー文が出ることで、エンジニアに「このようなエラーが出たのですが、どうしたらいいですか？」と相談しやすくなる。
- エンジニア視点：具体的な原因や理由がユーザーから一緒に共有されるため、対処方法がすぐに想像できて迷わず答えやすくなる。
ただの「コピペで動く仕組み」から、「非エンジニアとエンジニアを繋ぐインターフェース」のデザインへと捉え直したことで、より楽にストレスなく進められるようになりました。これはまさに、大学時代に学んだHCI（Human-Computer Interaction）の視点そのものでした。
そうやって目の前のタスクに向き合う中で、多くの気づきがありました。
1年が経過して気づいたこと
配属直後から3ヶ月間ぐらいは「技術の知識ゼロの自分がやっていけるのだろうか」と不安しかありませんでした。しかし、ゲーム開発者のためのSRE（Site Reliability Engineering）というチームは、課題解決のためなら本当に何でもやる組織でした。
だからこそ、「人間中心で考える」という強みが活きる環境だったのです。この1年を通じて、私はSREの仕事はすべて「開発者のUX（ユーザー体験）を高めるためのデザイン」であるということに気づきました。
具体的には、次の3つの大切な気づきを得ました。
開発者に寄り添うためには「観察」と「ヒアリング」が重要
ツールやシステムをただ置換するだけでは、真の課題は解決できません。どれだけ技術的に優れていても、現場の文脈に合っていなければ使われないからです。だからこそ、開発者が日々どんな風に作業し、どこで困っているのかを徹底的に「観察・ヒアリング」する。そんなアプローチでお客さん目線の環境をデザインしていくことこそが、結果として一番「楽な環境」を生み出すのだと再確認しました。
技術は「目的」ではなく、ただの「媒介（インターフェース）」
エンジニアであれば、新しい技術やトレンドのツールを使いたくなる誘惑に駆られます。しかし、私たちが向き合うべきは技術ではなく、目の前のユーザー（開発者）です。そもそも、技術を使わなくても解決できることすらあります。手段としての技術に溺れず、目的を見失わないことが大切だと確信しました。
小さな違和感を放置しないことが信頼へ繋がる
「なんかここ使いにくいな」「いつも同じエラーで誰かが質問してるな」「何かおかしいかも」という小さな違和感を見逃さず、確認・共有・解決すること。これが積もり積もって大きなトイル（手作業の削減）削減になり、開発者からの「信頼の種」へと繋がると実感しました。
おわりに
ここまで読んでいただきありがとうございました。
入社当時、私は「技術そのものには興味がない」と言い切っていました。1年経った今でも、その根本のスタンスは変わっていません。
ですが、この1年「ゲーム開発者のためのSRE」として駆け抜けてみて、気づいたことがあります。それは、技術に対して人一倍のこだわりがないからこそ、誰よりも純粋に目の前のユーザーとそのユーザーを取り巻く環境に集中できるという強みです。
最初は不安で仕方なかった新卒が、1年経った今、自分の持ち味を活かしながら「SREっておもしろい！」と心から思えています。
これからも、手段としての技術を貪欲に学びつつ、さらに踏み込んで、もっとゲーム開発に携わる方々を楽にするために挑戦し続けます！
原文を表示
はじめに
こんにちは！25卒で新卒入社し、ゲームサービス事業本部開発運営統括部第一技術部ゲーム開発SREグループ、「通称：ゲーム開発者のためのSREチーム」に所属している重本玲奈(
)です。
気づけば入社から1年が経過しており、技術のインプットやキャッチアップに追われながらも、エンジニアとして充実した日々を過ごしています。
私は就職活動の時から一貫して、あるスタンスを表明し続けて入社しました。それは、「技術そのものには興味がありません。技術を『どう使うか』にしか興味がないです。」というものです。大学時代は、技術と人間の接点を探る「ヒューマンコンピュータインタラクション(HCI)」を専攻しており、常に「誰が」「何のために」ものを使うのか、「何がしたいのか」という目線で物事を考えていました。
そんな私が、昨年度の8月に配属されたのは「ゲーム開発者のためのSRE」というチームです。
SREといえば、インフラやCI/CDのゴリゴリの技術者集団という印象があり、インフラ知識もゲーム開発経験もほとんどない自分が、道具としての技術すら良くわからない状態で、果たしてやっていけるのかと配属当初は心配で仕方ありませんでした。
この記事では、そんな私が「ゲーム開発者のためのSRE」チームの一員として、1年間で感じたこと・学んだことをお伝えします。
ゲーム開発者のためのSRE
そもそも、ゲーム開発者のためのSREとは何か。私たちのチームは一般的なSREとされる方たちとは少し毛色が違います。
一言で言うと、私たちは「ゲーム開発に携わるすべての人を楽にするために、なんでもやる人たち」です。そのスタンスの根底には、明確なMVV（ミッション・ビジョン・バリュー）があります。
- VISION
開発チームが「楽」してゲーム開発・運営ができる場を作る
- MISSION
ゲーム開発におけるプロダクト・プロジェクト上のサービスの信頼性を担保する
- 開発フロー・対ユーザーサービスを運用し、信頼性の高いサービスを提供する
- 50%ルールを守り、エンジニアリングによる継続的な改善を行う
- VALUE
自動化・自働化： 積極的な自動化・自働化は SRE の使命です。
- チームメンバーはお客さん： 開発に関わるすべての人をユーザーと捉え、内外関係なく改善を行います。
- ポストモーテム： 失敗から学び、共有し、繰り返しを避けます。
このMVVを体現するため、私たちは現在、次の2つのフェーズを重視して開発・運用に向き合っています。
- 「まずはできる」体制を作る
ワークフローの運用からトイル（定常作業）を削減・標準化し、安全性・信頼性の高い環境を構築する。
- 「誰もができる」体制にする
属人性を徹底的に排除し、安定運用と改善を継続できる仕組みにしていく。
やることは多岐に渡り、開発者体験の向上・障害の再発防止・心理的安全性の向上など、必要であれば本当になんでもやります。
これらを実現するために敷いているのが、ミッションにもある「50%ルール」です。業務時間の半分は目の前の運用に使い、残りの半分は「将来を楽にするための開発（改善）」に投資する。常にこのサイクルを回し続けるのが、私たちのチームのスタイルです。
私たちのチームの取り組みについては、CEDEC 2024でも発表しています。詳しくはこちらをご覧ください。
1年間で向き合ったタスク
私は、この1年間、開発チームが「楽」してゲーム開発・運営ができる場を作るために、さまざまなタスクを実行しました。
具体的なタスクとしては以下のようなものです。
- ビルドマシンリプレイス / OSバージョンアップ
- GitHub Actionsのランナーおよびワークフロー運用・保守
- ランナーの死活監視の通知
- IaC の運用・保守
- Unity Licensing Serverのサーバー構築・運用
- GitHub Enterprise ServerからGitHub Enterprise Cloudへの移行
- 非エンジニア向けのセットアップ手順の単純化
- ドキュメントの作成・整理・共通化
一見すると、インフラ寄りの技術的なタスクも多く、知識も経験もゼロの私にとっては、どれも最初は呪文のようでした。
しかし、私はこれらを、「開発者という『ユーザー』の体験を良くするためのデザイン」だと捉え直すことにしました。エラー文を分かりやすくすること、ビルドを1分早くすること。そのすべてが、開発者のストレスを減らすためのアプローチだったのです。
セットアップ手順の改善で気づいた「デザイン」の視点
PCのセットアップを対象とした「非エンジニア向けのセットアップ手順の単純化」というタスクでは、自分の視点が広がる経験をしました。
初めにこのタスクを任された時、私は「指定されたコマンドをコピー＆ペーストすれば、誰でも失敗せずにセットアップできるものにしよう」ということだけを意識していました。手順をシンプルにすることだけがゴールだと思っていたのです。
しかし、立ち止まってよく考えてみました。どれだけ手順を単純にしても、環境や状況によってエラーを完全にゼロにすることはできません。だとしたら本当に必要なのは、単なる手順の単純化だけでなく、「失敗したその後のコミュニケーションまでデザインすること」ではないか、と気づいたのです。
改善を加える前は、システムログがそのまま出力されるだけで、非エンジニアの方からすると「無事に終わったのか、何に失敗したのかすら分からない」状態でした。そこで、成功時は緑、失敗時は赤で画面に表示し、一目で状態が伝わるように改善しました。さらにエラー文を修正し、成功・失敗を明確に文字でも出し、何が原因のエラーかも出すように工夫しました。この工夫により、次のように変わったのです。
- 非エンジニア視点： 実行の成否が色や文章でパッと分かる。さらに、失敗の理由が明確なエラー文が出ることで、エンジニアに「このようなエラーが出たのですが、どうしたらいいですか？」と相談しやすくなる。
- エンジニア視点： 具体的な原因や理由がユーザーから一緒に共有されるため、対処方法がすぐに想像できて迷わず答えやすくなる。
ただの「コピペで動く仕組み」から、「非エンジニアとエンジニアを繋ぐインターフェース」のデザインへと捉え直したことで、より楽にストレスなく進められるようになりました。これはまさに、大学時代に学んだHCIの視点そのものでした。
そうやって目の前のタスクに向き合う中で、多くの気づきがありました。
1年が経過して気づいたこと
配属直後から3ヶ月間ぐらいは「技術の知識ゼロの自分がやっていけるのだろうか」と不安しかありませんでした。しかし、ゲーム開発者のためのSREというチームは、課題解決のためなら本当に何でもやる組織でした。
だからこそ、「人間中心で考える」という強みが活きる環境だったのです。この1年を通じて、私はSREの仕事はすべて「開発者のUX（ユーザー体験）を高めるためのデザイン」であるということに気づきました。
具体的には、次の3つの大切な気づきを得ました。
開発者に寄り添うためには「観察」と「ヒアリング」が重要
ツールやシステムをただ置換するだけでは、真の課題は解決できません。どれだけ技術的に優れていても、現場の文脈に合っていなければ使われないからです。だからこそ、開発者が日々どんな風に作業し、どこで困っているのかを徹底的に「観察・ヒアリング」する。そんなアプローチでお客さん目線の環境をデザインしていくことこそが、結果として一番「楽な環境」を生み出すのだと再確認しました。
技術は「目的」ではなく、ただの「媒介（インターフェース）」
エンジニアであれば、新しい技術やトレンドのツールを使いたくなる誘惑に駆られます。しかし、私たちが向き合うべきは技術ではなく、目の前のユーザー（開発者）です。そもそも、技術を使わなくても解決できることすらあります。手段としての技術に溺れず、目的を見失わないことが大切だと確信しました。
小さな違和感を放置しないことが信頼へ繋がる
「なんかここ使いにくいな」「いつも同じエラーで誰かが質問してるな」「何かおかしいかも」という小さな違和感を見逃さず、確認・共有・解決すること。これが積もり積もって大きなトイル削減になり、開発者からの「信頼の種」へと繋がると実感しました。
おわりに
ここまで読んでいただきありがとうございました。
入社当時、私は「技術そのものには興味がない」と言い切っていました。1年経った今でも、その根本のスタンスは変わっていません。
ですが、この1年「ゲーム開発者のためのSRE」として駆け抜けてみて、気づいたことがあります。それは、技術に対して人一倍のこだわりがないからこそ、誰よりも純粋に目の前のユーザーとそのユーザーを取り巻く環境に集中できるという強みです。
最初は不安で仕方なかった新卒が、1年経った今、自分の持ち味を活かしながら「SREっておもしろい！」と心から思えています。
これからも、手段としての技術を貪欲に学びつつ、さらに踏み込んで、もっとゲーム開発に携わる方々を楽にするために挑戦し続けます！
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み