ゲーム開発にも SRE が必要だよね!ゲーム開発者のための SRE 組織を作った話
492 Views
June 17, 25
スライド概要
SRE（Site Reliability Engineering）はゲーム業界以外では定着しつつあるワードだと思います。ゲーム業界でも SRE が全くいないわけではありませんが、まだ定着には程遠い印象です。 しかしながら、私が近年の CEDEC を拝聴しているときの口癖は「それ SRE っぽいね」です。SRE は新しい職種でも技術でもありません。実はすでにいたのです。
本セッションでは DeNA の「ゲーム開発者のための SRE」チームを事例に、まずは SRE のことを知っていただき、私達がなぜ SRE チームを必要とし、SRE チームを立ち上げたのかご紹介します。
CEDEC2024: https://cedec.cesa.or.jp/2024/session/detail/s6604f029340ec/
DeNA が社会の技術向上に貢献するため、業務で得た知見を積極的に外部に発信する、DeNA 公式のアカウントです。DeNA エンジニアの登壇資料をお届けします。
関連スライド
各ページのテキスト
ゲーム開発にも SRE が必要だよね!? ゲーム開発者のための SRE 組織を作った話 2024/08/21 CEDEC 2024 © DeNA Co., Ltd. 1
写真撮影・ SNS投稿 © DeNA Co., Ltd. 2
登壇者プロフィール 白柳 隆澄 株式会社ディー・エヌ・エー ゲームサービス事業本部開発運営統括部第一技術部 テクノロジー推進第三グループ グループリーダー 2007年からゲーム業界でエンジニア 2017年DeNA入社 2019年頃からSREを自称 「ゲーム開発者のための SRE」 として開発をいかに楽にしていくか 毎日考えています © DeNA Co., Ltd. 3
はじめに サイト リライアビリティ エンジニア 白柳は自称 SRE（Site Reliability Engineer）です これはあくまで私の解釈であり SRE を定義するものではありません © DeNA Co., Ltd. 4
今日話すこと ● SRE とはなにか？簡単に ● SRE は様々な場で実践される ● ゲーム業界でも増えてきている ● 「ゲーム開発者のための SRE」が 必要ではないでしょうか？ ● DeNA での組織化事例 © DeNA Co., Ltd. 5
はじめに 質問！ 私は SRE だという人は挙手 © DeNA Co., Ltd. 6
はじめに 質問！ 私は SRE っぽいことをしている 人は挙手 © DeNA Co., Ltd. 7
目次 1 まとめ 2 SRE とは？ 3 「ゲーム開発者のための SRE」とは？ 4 SRE の実践と組織への浸透 5 さいごに © DeNA Co., Ltd. 8
まとめ © DeNA Co., Ltd. 9
SRE とはなにか？ ● Site Reliability Engineering/Engineer ○ サイトリライアビリティエンジニアリング/エンジニア ○ サイト信頼性エンジニアリング/エンジニア ● 「サービスの運用・運営にあたって、価値目標に向 け、自動化（自働化）を主軸にエンジニアリングを用 いて改善していく」こと・人 © DeNA Co., Ltd. 10
SRE とはなにか？ ● 何かを運用しながら改善（開発）していく ○ 何か = Site / 場 ● 場によって何をするか変わる ○ インフラ？サーバー？CI/CD？テスト？ ● 場によってどうやるか変わる ○ 今必要なものは？ ○ プロダクトチームの一員として？横断チームとして？ © DeNA Co., Ltd. 11
SRE とはなにか？ ● SRE は働き方であり、様々な場所で発揮される ○ class SRE implements interface DevOps ○ DevOps は考え方で SRE はその実装と言われるが、 場によって SRE の実装方法は全く異なる ○ SRE = 考え方 + やり方 = 働き方 ● class XXX implements abstract SRE ○ 場によって呼ばれ方が違うことも ○ 「ゲーム開発者のための SRE」もその１つ © DeNA Co., Ltd. 12
ゲーム開発にも SRE が必要である ● ゲームの運用・運営を行いながら ● 目標のために機能や自動化などの開発をし ● 障害対応、ふりかえり、改善を行う ● ゲームリリース後における SRE これも必要 © DeNA Co., Ltd. 13
ゲーム開発にも SRE が必要である ● ゲーム開発者向けのサービスやツールなどを運用 ● ゲーム開発を楽にするために機能や自動化など開発し ● 課題解決、ふりかえり、改善を行う ● ゲーム開発中からずっといる SRE ● 開発のしやすさはゲームの出来に影響する こっちも必要 © DeNA Co., Ltd. 14
「ゲーム開発者のための SRE」チーム ● ゲーム開発者向けの開発環境、サービス、ツールなど の運用をしつつ ● ゲーム開発者がいかに楽に開発ができるのか さまざまな場所で改善をする ● SRE は働き方であり職種ではないが 職種・ロールとしての SRE も作った © DeNA Co., Ltd. 15
SRE の実践のためにしたこと ● 職種・ロールとしての SRE で活動 ○ 思想はある、やりたいこともある、時間がない ○ 改善を主業務にした ● 名前をつけて組織へ浸透 ○ 「ゲーム開発者のための SRE」と命名 ○ 「改善」は今も昔もみんなやっている ○ もともとやっていたことに名前をつけて 業務の認知と重要性を組織に展開した © DeNA Co., Ltd. 16
ここから詳しく→ © DeNA Co., Ltd. 17
SRE とは？ © DeNA Co., Ltd. 18
2 SRE とはなにか？ ● Site Reliability Engineering/Engineer ○ Google社が実践・提唱したもの ○ 書籍：SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム ○ 原書2016年発行・日本語版2017年発行・通称SRE本 ○ SRE は書籍発行前から存在している ● その他ウェブ、求人サイト、書籍など情報多数 ○ どれが正しいのかわからない © DeNA Co., Ltd. 19
2 SRE本のプラクティス ● SLO/SLI（Service Level Objective/Indicator） ○ サービスレベル目標/指標 ● エラーバジェット ● トイル（Toil）の削減とオーバーヘッド ● モニタリング（+ オブザーバビリティ） ● 自動化 ● ポストモーテム © DeNA Co., Ltd. 20
2 class SRE implements interface DevOps ● DevOps が扱う 5 つの領域 ○ ○ ○ ○ ○ Reduce organizational silos / 組織のサイロを削減する Accept failure as normal /エラーが発生するのを前提とする Implement gradual changes / 段階的に変更する Leverage tooling and automation / ツールと自動化を活用する Measure everything / 全てを計測する ● DevOps は考え方で SRE はその実装 ○ SRE本のプラクティスに現れている © DeNA Co., Ltd. 21
2 SRE の普及 ● しらやなぎの場合 ○ 2019年から自称SRE ■ スタッフロールの肩書を考えた時から自称し始めた ■ 当時は名前を聞いたことあるなくらいだった ○ 2020年にSRE本を購入 ■ 最初に読んだときの感想は「Google ではそうなんだなー」 ■ やり方や考え方は今でも読み返す © DeNA Co., Ltd. 22
2 国内IT業界におけるSRE ● 2015年のメルカリ社ブログ ○ 「インフラチーム改め Site Reliability Engineering (SRE) チームになりました」 ● SRE本で広まった ● 勉強会やセミナーなどイベントが開催 ● 2024年現在では数多くの会社が SRE の求人を掲載 © DeNA Co., Ltd. 23
2 国内IT業界におけるSRE ● SRE 求人で必要なスキルや、業務内容はバラバラ ○ インフラ、クラウド、コンテナ、CI/CD、IaC、モニタリン グ、データベース、etc ○ SRE募集 = ゲーム開発者募集くらいにあいまい ● SRE = インフラエンジニア？サーバーサイド？ ○ 募集は多いがイコールではない ○ 場が変われば業務内容も変わる © DeNA Co., Ltd. 24
2 SREは働き方である ● DevOps は考え方で SRE はその実装 ● SRE は場によって振る舞い（やること）が異なる ● SRE のやり方、考え方はインフラ・サーバーに限ら ず様々な場で通じる ● SRE は abstract © DeNA Co., Ltd. 25
2 SREは働き方である ● その他ウェブ、求人サイト、書籍など情報多数 ○ どれが正しいのかわからない ○ どれも正しいといえる ● SRE は様々な場で活動、発揮される ○ ○ ○ ○ © DeNA Co., Ltd. 何をつくるかで変わる どこでつくるかで変わる 誰とつくるかで変わる 場の数だけ解釈があって当然である 26
2 大事なことは ● 価値を届けること ● SRE は 「サービスの運用・運営にあたって、価値目標に向 け、自動化（自働化）を主軸にエンジニアリングを 用いて改善していく」 ことで貢献をする © DeNA Co., Ltd. 27
「ゲーム開発者のための SRE」とは？ © DeNA Co., Ltd. 28
ゲームにおける SRE どんな仕事？ © DeNA Co., Ltd. 29
3 ゲームの SRE といえば？ ● 「ゲームの運用・運営にあたって、価値目標に向 け、自動化（自働化）を主軸にエンジニアリングを 用いて改善していく」 ● これはイメージしやすい例 ○ 負荷対策 ○ 障害対応 ○ リリースエンジニアリング © DeNA Co., Ltd. 30
3 ゲームの SRE といえば？ ● 「ゲームの運用・運営にあたって、価値目標に向 け、自動化（自働化）を主軸にエンジニアリングを 用いて改善していく」 ● これはイメージしやすい例 ○ 負荷対策 ○ これやってる人たち既にいませんか？ 障害対応 ○ リリースエンジニアリング © DeNA Co., Ltd. 31
3 SRE は既存業務の延長 ● DeNA には既にいました ○ リリースエンジニア、運用・運営エンジニア、など ○ SRE と名乗っていないがやってることは SRE っぽい ● IT業界の事例 ○ 既存チームがSREチームになっている例をよく見る ● 少なくとも SRE は突如生まれた職種ではない ○ 名前がついただけ © DeNA Co., Ltd. 32
3 ゲーム開発者のための SRE とは？ ● 「ゲーム開発者のための SRE」組織を作りました ● ゲームの SRE とはやることの印象が異なり 区別するために命名 © DeNA Co., Ltd. 33
3 ゲームの SRE との大きな違い ● ゲーム開発者もお客様 ● ゲーム開発者向けにも SRE を行う ● ゲーム開発初期から活動 ● 「ゲーム開発環境の運用・運営にあたって、価値目 標に向け、自動化（自働化）を主軸にエンジニアリ ングを用いて改善していく」 © DeNA Co., Ltd. 34
ゲーム開発者のための SRE は なぜ必要？ © DeNA Co., Ltd. 35
3 開発者体験の重要性 ● ゲーム開発の大規模化、分業化 ● ゲームがリリースされるまでにさまざまな工程 ● 必要なツールやサービスも多種多様 開発者が作りやすい、働きやすい環境が より重要になった © DeNA Co., Ltd. 36
3 開発環境にも運用が必要な事実 ● 開発環境は用意したら終わりではない ○ よくある例） ビルドジョブの作成タスク：３人日 ○ ビルドジョブのメンテナンスは？ ● ゲーム開発者が兼任で対応することの問題点 ○ ツール導入、CI/CDなど ○ 運用コストが見積もられてないケースが多い ○ ゲーム開発が優先され手が回らないケースがある © DeNA Co., Ltd. 37
3 分業化によるサイロ化問題 ● サイロ化 ○ 組織やシステムが孤立し、情報連携されてない様子 ● 職種間、チーム間の間に落ちたボール問題 ○ 気づかない、わからない、あっちがやるからヨシ ○ エンジニアから遠いと自動化などによる改善が届きづらい ○ 専任化は「顧客が本当に必要だったもの」と向き合う必要 ● TA（TechnicalArtist）のような橋渡しをする役割の 重要さが増している © DeNA Co., Ltd. 38
3 優先度の問題 ● 改善したいことはいっぱいある ● 時間はない ○ ゲーム開発者はゲームを作ることが優先 ○ 職種やチームごとにやるべきことがある ○ 後回しになったことで 余計に時間がかかったり、手遅れになったり © DeNA Co., Ltd. 39
3 なぜ必要か？ ● 開発者体験の向上 ● 開発者向けサービスの運用業務 ● 組織のサイロ化の削減 ● 改善のサイクルを回す これらをゲーム開発初期から取り組むために 「ゲーム開発者のための SRE」を始めました © DeNA Co., Ltd. 40
3 ゲーム開発者のための SRE とは？ ● ゲーム開発者もお客様 ● 開発中にみなさんが使っているツールや ゲーム中のデバッグ機能、 環境構築、ワークフロー、etc… それらを「ゲーム開発者」向けのサービスと捉え、 運用と改善をするのが 「ゲーム開発者のための SRE」です © DeNA Co., Ltd. 41
3 ゲーム開発者のための SRE とは？ ● ゲーム開発者もお客様 ● 開発中にみなさんが使っているツールや ゲーム中のデバッグ機能、 環境構築、ワークフロー、etc… それらを「ゲーム開発者」向けのサービスと捉え、 これやってる人たち既にいませんか？ 運用と改善をするのが 「ゲーム開発者のための SRE」です © DeNA Co., Ltd. 42
3 ゲーム開発者のための SRE とは？ ● 「ゲーム開発者のための SRE」も 突如生まれた職種ではなく いままでやってきた業務改善に名前がついただけ ○ ゲーム業界にも既に SRE はいる ■ 会社によって名前は違う ■ たぶんやってることは同じ ● いままで + SRE のやり方や考え方 ○ SRE 本を参考に実践 © DeNA Co., Ltd. 43
SRE の実践と組織への浸透 © DeNA Co., Ltd. 44
4 SRE を実践するためにしたこと ● 今までやってきたことが SRE になった ○ つまり、できているのでは？ ■ 実際には忙しくてできてないことが多々あった・・・ ● 改善したいことはいっぱいある ● 時間はない © DeNA Co., Ltd. 45
4 SRE を実践するためにしたこと ● 職種・ロールにした ● チーム・組織化 ● SRE の 50% ルールをベースに 改善を主業務とできるようにした © DeNA Co., Ltd. 46
4 改善をする組織 ● 共通基盤組織 ○ 共通機能、ライブラリ開発 ● 専門組織 ○ TA、ビルドエンジニア、インフラ、SRE、etc… ● プラットフォームエンジニア ○ IDP(Internal Developer Platform / Portal） ● タスクフォースチーム ○ 臨時チーム © DeNA Co., Ltd. 47
4 プラットフォームエンジニア？ ● 「ゲーム開発者のための SRE」と同じでは？ ○ 共通 ■ 開発者体験向上、開発者向け ■ プラットフォームの提供 ○ 違い ■ デベロッパーポータルのような自分たちの製品がない ■ 内製開発者も「ゲーム開発者のための SRE」のお客様 © DeNA Co., Ltd. 48
4 「ゲーム開発者のための SRE」組織 ● 組織とプロジェクトへの関わり方 ○ 共通基盤組織の１チーム ○ プロジェクトへは横断チームとしてではなく プロジェクトメンバーとして参加 ■ プロジェクト内のチームに SRE メンバーがいる ■ 自分自身もお客様になる © DeNA Co., Ltd. 49
4 SRE の実践 ● 最初のサービス ○ CI/CD 環境やワークフローの運用・改善 ○ CI/CD エンジニアやビルドエンジニアではない ● サービスの属人化を避ける ○ SREメンバーじゃないと対応できない環境にはしない ○ プロジェクトメンバーでもできる手順・ドキュメント ○ as Code や自動化 © DeNA Co., Ltd. 50
4 SRE の実践 実践できている 試行錯誤中 ● トイルの削減 ● モニタリング ● 自動化 ● ポストモーテム ● SLO/SLI ● エラーバジェット ● オブザーバビリティ どこからやるかは場で変わる © DeNA Co., Ltd. 51
4 SRE の実践パターン ● Embedded SRE ○ SRE メンバーがプロジェクトに参加し、活動 ○ プロジェクトで実践 ● Enabling SRE ○ プロジェクトのメンバーを SRE にしていく ○ 啓蒙と普及 © DeNA Co., Ltd. 52
4 Embedded から Enabling へ ● Embedded SRE ○ 「ゲーム開発者のための SRE」以外でも 同様の取り組みは存在した ■ 〇〇タスクフォースチーム、改善チーム、etc… ■ 一時的なものや兼任で SRE の働き方としては定着せず ● Enabling SRE ○ 啓蒙と普及 ■ 組織に根付かせ、継続的に実践できる場を作る活動へ © DeNA Co., Ltd. 53
4 なぜ Enabling SRE ● Embedded SRE の人手不足 ○ ミイラ取りがミイラに ○ 運用負荷が高まり、改善が鈍化 ● Enabling SRE ○ プロジェクトのメンバーを SRE にしていく ○ SRE は働き方である © DeNA Co., Ltd. 54
4 Enabling のその先 ● SRE の働き方が広まり 適所に SRE を実践する人がいるようになれば Embedded SRE は専門職である必要がない ● エンジニア以外にも改善意識、改善サイクルを回す という考えがより広まってほしい © DeNA Co., Ltd. 55
4 組織への啓蒙 ● 社外のトレンドを取り込んだネーミング ○ 単なる SRE ではなく「ゲーム開発者のための SRE」とした ○ 気になる名前にできたと思っている ○ それなに？と思わせたら勝ち © DeNA Co., Ltd. 56
4 組織への啓蒙 ● 「ゲーム開発者のための SRE」の MVV を作成 ○ さらに課題感や考え方、やること、やらないことなど とにかく文書化 ○ 上長や所属チームなどから 啓蒙していった © DeNA Co., Ltd. 57
4 プロジェクトへの啓蒙 ● とにかく SRE という言葉を使う ○ Slack Group / Channel や GitHub Team などの名前 ○ リリースエンジニア + ゲーム開発者のための SRE の合同 チーム名を SRE とする ● 新規プロジェクトには必ず参加 ○ CI/CD 環境の運用をメインに関係を持つ ● 既存プロジェクトとの関係を持つ ○ リリースエンジニアと相談できる場を作る © DeNA Co., Ltd. 58
4 信頼性の向上から組織へ浸透 ● CI/CD 環境を中心に開発環境を改善 ○ 環境セットアップ手順の改善 ○ サービス連携 ○ マージリレーの改善 ■ 並行開発のマージリレー完全自働化と達成までのみちのり ● 開発のしやすさが信頼性に © DeNA Co., Ltd. 59
4 組織の歴史 ● 2019年: １人SRE ○ Embedded SRE として単一プロジェクトで活動 ○ 命名と啓蒙 ● 2022年: １人SREからSREチームへ ○ SREチームの参加プロジェクト増加 ● 2024年: チームからグループへ ○ 共通基盤グループの１チームから組織上のグループへ ● ほぼすべてのプロジェクトに参加するまで成長 © DeNA Co., Ltd. 60
4 結果 ● SREがプロジェクトに欠かせない存在に ○ 今まで現場の努力でなんとかしていた部分を解決 ○ 開発者体験の向上、開発環境の運用負荷軽減 ○ SRE の働き方を取り込んだことで改善がより回りだした © DeNA Co., Ltd. 61
さいごに © DeNA Co., Ltd. 62
5 まとめ ● SRE について白柳の解釈と DeNA での 「ゲーム開発者のための SRE」事例を紹介しました ● ゲーム業界にも SRE が必要です ○ SRE は働き方、そして既にやっている人がいると思います ○ SRE の働き方を実践するために 今は職種やロールとしての SRE も必要だと考えています ● 組織に根付かせるためにネーミングも重要です © DeNA Co., Ltd. 63
5 これからの展望 ● すべての開発者に SRE を知ってほしい ○ SRE とは働き方である ○ SRE のプラクティスをすべての職種の人がやる必要はない が考え方、特に改善意識を是非取り込んでほしい ○ そして開発者体験の向上へとつなげてほしい © DeNA Co., Ltd. 64
5 これからの展望 ● すべての開発者に SRE を知ってほしい ○ SRE とは働き方である ○ SRE のプラクティスをすべての職種の人がやる必要はない が考え方、特に改善意識を是非取り込んでほしい ○ そして開発者体験の向上へとつなげてほしい すべて = DeNA すべて = ゲーム業界 © DeNA Co., Ltd. 65
5 これからの展望 ● SRE についてみなさんと話がしたいです ○ ○ ○ ○ SRE だけだとあいまいすぎない？ もっといい名前ないかな？ SRE = 〇〇エンジニアに実質なってない？ 今後の CEDEC などでも話が聞きたい ● TA や CI/CD のように 分野（キーワード）になると嬉しい © DeNA Co., Ltd. 66
© DeNA Co., Ltd. 67
Appendix ● 参考書籍 ○ SRE サイトリライアビリティエンジニアリング ―Google の信頼性を支えるエンジニアリングチーム ○ サイトリライアビリティワークブック ―SREの実践方法 ○ https://sre.google/books/ © DeNA Co., Ltd. 68
質疑応答 Q. SRE や Ops 業務に適正のある人はどのような人でしょうか？ また、どのように味方を増やして来たのでしょうか？ A. 「ゲーム開発者のためのSRE」はお客様（ゲーム開発者）がそばにいるの で、すぐにフィードバックを貰えます。そこにやりがいを感じられる人は向 いていると思います。 あとは私もそうですが、めんどくさがりな（すぐ自動化する/トイル削減の 習慣がある）人とかでしょうか。 メンバーを増やしていくのは私たちも課題を感じています。難しい… P.57 の「ゲーム開発者のためのSRE」のMVVと資料は役に立ったと思いま す。この考えに共感する人がメンバーになってます。 © DeNA Co., Ltd. 69
質疑応答 Q. Enabling SRE をしていった、SRE の考えを広めていった過程で ハードルになったことはありますか？ A. まったく知らない人に、急に SRE を実践してくださいというのは難しいと 思っています。 現段階では、もともと SRE っぽい人たち（リリースエンジニア・運用/運営 エンジニア）から Enabling しているのでハードルとなったものは特にな かったです。 今後さらに広めていくにあたってハードルが出てくるかもしれません。 © DeNA Co., Ltd. 70
質疑応答 Q. 啓蒙する上で目標・指標はアピールする上でも大事だと思います。数値を 見せる、成果を見せるもので効果的だった事例があれば教えてください。 A. SLO/SLI は設定してみてはいます。CI/CD 運用をしているのでビルド時間 だったり、ビルドマシンに対しての SLO/SLI を設定してみてはいるもの の、改善まで繋げられていないので試行錯誤中です。 組織に対しての成果・アピールとしては、片手間の運用や開発初期の環境整 備など、組織が抱えていた課題を解決できたことが大きな成果だったのかな と思います。 © DeNA Co., Ltd. 71
質疑応答 Q. SRE の業務は多岐にわたるためメンバーの採用、特に中途採用の難しさを 感じています。 チームメンバーは SRE っぽい働きをしていた人で構成されているのでしょ うか？メンバーを増やす場合もそのような人を増やす方針でしょうか？ A. 中途採用は私たちも難しいなと感じていますが、まずは「ゲーム開発者のた めの SRE」のこと、私たちのことを知ってもらうためにカジュアル面談か ら始めさせていただくこともあります。 現メンバーは、スキルセットがあったメンバーとこれから経験を積んでいく ジュニアなメンバーがおり、教育と成長のサイクルが回せる組織にちょうど なってます。また、業務が多岐にわたるので様々なスキルセットを求めてい ます。なので、特定のスキルセットにこだわらずメンバーを増やしていける と良いなと感じています。 © DeNA Co., Ltd. 72
質疑応答 Q. 開発が忙しい時期で改善に手が回らない状況になってしまった場合に、 時間を捻出する良い方法はなにかありますか？ A. SRE は改善を回していく組織でありたいので、運用にあたる業務は本来の 担当者（プロジェクト側）にタスクを移譲していくことをします。 当然、そのタスクをプロジェクト側メンバーでもできる状態にする必要はあ ります。できる状態にしておく、環境を整えておくことをやっておけば、 SRE の負荷が高まった時でも負荷分散して、改善する時間を作れると考え ています。 © DeNA Co., Ltd. 73
質疑応答 Q. SREがCI/CD業務をやることがあるがCI/CDエンジニア・ビルドエンジニア ではないとのことでしたが、それはビルドエンジニアが専任でおり、それ をプロジェクトによっては代行するという意味なのか、 それともSREの業務の一環としてCI/CD業務があって、ビルドエンジニア専 任の人はいないという意味なのかどちらでしょうか？ A. 現状は後者です。ただし、SREだけがCI/CD業務をやっているわけではな く、ワークフロー開発はリリースエンジニアも行っています。また、専任者 がいても良いと考えています。 SREだけがその業務をすべてやるのではなく、プロジェクト側で業務を担当 するメンバーとチームを組んでやるイメージです。 SRE=〇〇エンジニアみたいなイメージが付きやすいですが、「場」が変わ れば〇〇の部分も変わるので、このような表現をしました。 © DeNA Co., Ltd. 74
質疑応答 Q. 啓蒙についてですが、 苦労したこと、有効的であった手段などあればお願いします A. 組織においては、組織課題に対して解決すると効果の高い領域をSREがやっ たことが有効だったと思います。苦労したことでもありますが、少ない人数 で課題解決にあったのも良かったです。属人性が高くなるのは良くないとさ れていますが、過渡期はむしろ物事が進めやすくて良いのかなとも思ってい ます。もちろん安定したら属人性はなくすべきです。 プロジェクトにおいては、どうしても実際に何をやっているかで〇〇エンジ ニアというイメージがつきやすいところが苦労しています。イメージにとら われずもっと相談してほしいので、相談しやすい存在であるように気をつけ ています。レスポンスは早く、わからなくてもわかる人がいないか探すな ど、とにかく何事にも反応をするように意識しています。 © DeNA Co., Ltd. 75
質疑応答 Q. プロジェクトに入っているSREエンジニア同士の情報共有ややり方の統一 などはどのように行っていますでしょうか A. SREグループで週２回、リーダーとメンバーの1on1を週１回やり、そこで共 有や相談をするようにしています。 やり方を決めるような相談は別途議論する時間を作り、必ずコードや手順 書、ドキュメントにするようにしています。 また、プルリクエストは相互にレビューしたり、チームで進行管理したりな ど、孤立した業務をなるべく作らず、相互に理解・把握できるようにしてい ます。 © DeNA Co., Ltd. 76