負債体質なゲーム開発からの脱却〜技術ではなく構造改革と意識変化から始める返済〜
2.3K Views
September 17, 26
スライド概要
技術的負債に向き合うConference 2026の登壇資料です。
https://technical-debt-con.findy-tools.io/2026
DeNA が社会の技術向上に貢献するため、業務で得た知見を積極的に外部に発信する、DeNA 公式のアカウントです。DeNA エンジニアの登壇資料をお届けします。
関連スライド
各ページのテキスト
負債体質なゲーム開発からの脱却 〜技術ではなく構造改革と意識変化から始める返済〜 2026/09/17 技術的負債に向き合うConference 2026 © DeNA Co., Ltd. 1
登壇者プロフィール しらやなぎ たかずみ 白柳 隆澄 株式会社ディー・エヌ・エー ゲームサービス事業本部開発運営統括部第一技術部 ゲーム開発SREグループ グループリーダー 2007年からゲーム業界でエンジニア 2017年DeNA入社 2019年頃からSREを自称 「ゲーム開発者のための SRE」 として開発をいかに楽にしていくか 毎日考えています © DeNA Co., Ltd. 2
登壇者プロフィール しらやなぎ たかずみ 白柳 隆澄 CEDEC 企画委員 プロダクション分野担当 2025年から CEDEC 運営委員 ゲーム業界国内最大カンファレンス プロダクション分野担当 公募審査だけでなく、ナレッジ共有 を推進しています https://x.com/cedec_official/status/2080608433527788004 © DeNA Co., Ltd. 3
CEDEC2027 開催日決定！ ● 2027年7月14日（水）から7月16日（金）の3日間開催 https://cedec.cesa.or.jp/2026/newslist/news/1081.html © DeNA Co., Ltd. 4
はじめに © DeNA Co., Ltd. 5
はじめに 今回、技術的負債をテーマに登壇することになり、真っ先に頭に 浮かんだ技術的負債の返済事例があります。この返済があったこ とでプロジェクトがとても良いスタートを切れました。この事例 は「並行開発のマージリレー完全自働化と達成までのみちのり」 として CEDEC2024 で発表しました。 © DeNA Co., Ltd. 6
はじめに 発表では負債の大きさ（つらさ）と仕組み、成果を話しました。 技術的な仕組みの解説もしましたが、この発表でのポイントは 「考え方を変えた」ということでした。そして、これは登壇した ３人が揃ったことで、たまたまできた偶然の産物です。 © DeNA Co., Ltd. 7
はじめに 今回の発表でお伝えしたいことは２つです。 技術的負債の返済に必要なのは 「技術」ではなく「意識変化」であり、 そして、それを推進するための 「組織構造の変化」である。 © DeNA Co., Ltd. 8
目次 1 負債体質なゲーム開発 2 成功事例からふりかえる技術的負債返済 3 「時間がない」を打破する組織構造 4 多忙化の壁を越える 5 まとめ © DeNA Co., Ltd. 9
技術的負債の四象限 無謀 わかってはいるけど 意図した 時間がない 意図しない より良い方法を 知らなかった 慎重 リリースを優先 あとで直す 当時は最善だったが 今ならそうしない ↑に関して深堀りはしないが、頭の片隅に置いておいてください © DeNA Co., Ltd. 10
負債体質なゲーム開発 なぜ技術的負債を溜めてしまいがちなのか © DeNA Co., Ltd. 11
ゲーム開発のよく言われる特性 ● 仕様がよく変更される ● 変更できないリリース日 ● パフォーマンスやグラフィックスなどの高い要求 ● 開発の大規模化と長期化 ● 建て増し運営と後方互換性 © DeNA Co., Ltd. 12
ゲーム開発は技術的負債を溜めがち ● 仕様変更が多く、選択が必要になることが多い ● それなのに変わらない締め切りのプレッシャー ● 求められる機能が優先だが、妥協できない非機能要件 ● 非常に多様な成果物の結合 ● 非常に多くの人が関わり、人の入れ替わりも多い ● ようやくリリースして結果がわかる ● リリース後もこれが続く © DeNA Co., Ltd. 13
アジャイルですか？ いいえ、カオスです でも、そんなゲーム開発が好き © DeNA Co., Ltd. 14
あとで返すという幻想 ● 「リリースを優先してあとで直す」のあとでは来ない ● リリースしてしまったら、その時点で返済コストが膨れ上がる ● 意図的かどうかに関わらず、リリース後に問題となった 技術的負債を返済するのはとても高コスト ● リリース後も続く、仕様変更、締切、安定性のプレッシャー ● 変えられない病 © DeNA Co., Ltd. 15
昔はよかった・・・ ● 昔はゲームを発売したら完成 ○ マスターアップしたら何もできなかった ○ 借りっぱなしで逃げられた ● だからそういう体質、というわけではない ○ むしろ、ゲーム業界の課題解決能力は高いと思う ● 今はずっと開発しつづけなければいけない © DeNA Co., Ltd. 16
リリース後に変えるということの大変さ ● 多くのゲームが決まったリリーススケジュールで運営 ○ ローンチスケジュールよりも厳格 ● 建て増し運営、変えられない振る舞い ○ 〇〇を無効化する効果を無効化する効果を無効化… ○ 基本的に過去リソースの性能は維持しなければいけない ● 長期運用 ○ 想定されていない数との戦い（サイズ、組み合わせ、etc…） ○ 失われていく情報の鮮明さ © DeNA Co., Ltd. 17
技術的負債が問題になるとき ● 利息が少なければ、借りてても問題にはならない ● 利息が増えると問題になる ○ 仕様が変わった ○ 実行環境が変わった ○ 法律が変わった ○ 資産（コード・リソース）が増えた ● 小さな負担が大きくなり生産性が悪くなる © DeNA Co., Ltd. 18
技術的負債が問題になるとき ● もう借りれなくなったときが一番困る ○ 変化を引き金に、一括返済を迫られることがある ○ 状況は刻一刻と変化しつづける ○ なにが突然、致命的な問題として現れるかわからない ● やるべきことを止めてでも、やらなければいけない © DeNA Co., Ltd. 19
技術的負債の傾向 ● 借りることはみんな自然にやっている ○ それが意図的かそうでないかはどちらにせよ ● 返すことはなぜか自然にはできない ○ 負担として認知したときに技術的負債と呼んでいる ● 技術的負債をなくせるのか？ ○ 常に変化し続けるので、なくせない ○ 自然に返せてたら、技術的負債という認知にはならず 言葉はなくせるかも © DeNA Co., Ltd. 20
負債はなくならないが、なにを防ぐべきなのか ● 理由がわからなくなってしまうこと ○ 時間が経てば経つほど、情報が薄まっていく ○ 知っててそうしてるのか、知らずにそうしているのか ○ ただでさえ変更リスクがあるのに、わからないとより大変 ● 同じところから繰り返し借りてしまうこと ○ 前プロジェクトがそうだったから、で同じ決定をする ○ 開発チームと運営チームの問題 © DeNA Co., Ltd. 21
AI は技術的負債を返済できるのか？ ● AI を使うことで技術的負債の返済は進む ● ただし、 これは技術的負債を広く捉えたときに一部の話でしかない © DeNA Co., Ltd. 22
AI ALL IN した結果から見る技術的負債 ● 「DeNA × AI Day 2026 | Proof.」のクロージング 我が社は相当AIネイティブ化が進んでいます。効率化、進みましたね。ところが、同じ作 業をするのが楽になった分、自ら仕事を詰め込むということが分かりました。DeNAのメン バーは真面目ですからね。日本人はみんなそうだと思います。 同じタスクをするのに工数が少なくて済むようになると、新たにできた時間で「やりたくて もできなかったこと」を自分でどんどん詰め込んでいく。新規事業への人材のシフトが、 思ったほどまだできていないっていうのが正直なところです。 DeNA南場智子「先に動かし、事業を広げる」 スピーチ全文書き起こし (2026.03.19) ● やりたくてもできなかった技術的負債を返済している © DeNA Co., Ltd. 23
「無」の価値 ● リリースしなければ技術的負債も生まれない ● 技術的負債を返済のために何かを作るだと自転車操業 ● やらない、やめる、という選択肢を持つこと © DeNA Co., Ltd. 24
負債はなくならないが、なにを防ぐべきなのか ● 理由がわからなくなってしまうこと ● 同じところから繰り返し借りてしまうこと ● 足し算で解決しようとすること © DeNA Co., Ltd. 25
成功事例からふりかえる 技術的負債返済 © DeNA Co., Ltd. 26
マージ祭り ● あまりにも大変でテンヤワンヤする様子から 「祭り」と呼ばれるほどの負債 © DeNA Co., Ltd. 27
マージ祭りとは ● 複数あるリリースバージョンブランチに対して 時系列順に１つ１つマージしていく作業のこと ● バージョンブランチは2桁近い数が常時あり、 それぞれ機能開発をしているため、変更差分も、開発者も多い ● 当然めちゃくちゃコンフリクトする ● 担当者が毎日丁寧な手作業でコンフリクト解消をする日々 ● 最悪、丸一日かかることも… © DeNA Co., Ltd. 28
祭りからの解放 ● PR単位のマージリレーを開発 ○ コミットを１つずつ次へ PR していくシステムを開発 ○ PR をマージすると、そのマージコミットが次にリレーされる ○ コンフリクトは PR 単位で発生し、PR 作成者が解消する v1 #1 © DeNA Co., Ltd. #2 v2 #3 #4 29
具体的な内容は CEDEC 2024 の資料へ ● 並行開発のマージリレー完全自働化と達成までのみちのり ● 講演資料は CEDiL よりダウンロード可能 ○ https://cedil.cesa.or.jp/cedil_sessions/view/2902 © DeNA Co., Ltd. 30
どんな効果があったか ● エンジニア一人の工数が丸々削減できた ○ マージリレーではマージは自動、コンフリクト解消は本人がやる ● コンフリクト解消の負担も軽減 ○ 他人の修正も混じった状態でのコンフリクト解消から、 自分の修正のみのコンフリクト解消へ ● 未来のブランチの更新遅延が激減 ○ コンフリクトがなくなったわけではないが、 解消速度が上がったことで未来のブランチの更新が安定した © DeNA Co., Ltd. 31
どんな効果があったか ● マージリレーのおかげで開発チームに余裕ができ、 より良いものがリリースできたと思っている ● それくらい革命的なものでした 大成功！ © DeNA Co., Ltd. 32
マージ祭りはどんな負債だったのか？ ● マージ祭りがなければ過去タイトルは運営できていない ○ マージリレーができる前まではこれしかない、と思っていた ● 一番最初のマージ祭り ○ 借りた人はその時の最善の選択をしている ○ 当初はブランチ数も限られていて負担はまだ少なかった ○ 運営が長くなり負担が大きくなったところで負債の認知 ○ 借りた人と返す人が異なっている © DeNA Co., Ltd. 33
マージ祭りはどんな負債だったのか？ ● 次のプロジェクトでもマージ祭りが採用された ● そこからずっとマージ祭りになってしまったのが問題 ● なぜ変わらなかった、変えられなかったのか ○ 導入した人と、負担になっている人が異なっていた ○ 運用知見が開発計画にフィードバックできていなかった ○ 十分な時間がなく既存の確立された手法を選択するしかなかった © DeNA Co., Ltd. 34
マージ祭りを繰り返し借りる負のサイクル ● これはマージ祭りの技術的負債ではなく、組織の技術的負債 ● これはなんとかしなければいけない © DeNA Co., Ltd. 35
なぜ返済できたのか？ ● 変えるという強い意志 ○ 今までどおりという選択もあったはず ■ プロジェクトからのリクエストは運営体制の構築 ● 意志が貫けたのは事前のふりかえりから ○ 有志によって開発体制のふりかえりが行われていた ○ 問題の本質を事前に捉えていた © DeNA Co., Ltd. 36
なぜ返済できたのか？ ● 発想の転換ができたことが大きな要因 ○ マージ祭りを楽にしよう、ではなくフローから見直したこと ■ 今なら AI で自動化しよう、とかやってしまっていたかも ○ 責務を再考 ■ マージ祭り担当者１人の責務ではなく、 開発者が最後までデリバリーするのが責務であるべき ■ コンフリクトさせた人が一番コンフリクトを解消できる ○ マージはブランチ単位でなければできないという思い込みの払拭 © DeNA Co., Ltd. 37
なぜ返済できたのか？ ● （偶然）時間と人が揃ったからできた ○ 負債と向き合ってきた人、 これから運用する人がメンバーに入った ○ 負債に向き合う時間猶予があった © DeNA Co., Ltd. 38
技術的負債の返済には何が必要か ● 現状維持ではなく、変化に挑戦する ○ 無謀な挑戦ではなく、コトに向かい、失敗から学ぶ ● 場を作る ○ ふりかえりで本質を捉える ○ ペルソナを理解したメンバーを集める ○ 時間を作る © DeNA Co., Ltd. 39
「時間がない」を打破する組織構造 © DeNA Co., Ltd. 40
志はある、時間はない ● 改善チーム ● 兼務、改善はサブタスク ● 続かない © DeNA Co., Ltd. 41
時間がないなら作る ● 改善を主業務とする組織を作った ● ゲーム開発にも SRE が必要だよね!?ゲーム開発者のための SRE 組織を作った話 | CEDEC2024 ○ 講演資料（CEDiL / ドクセル） ■ https://cedil.cesa.or.jp/cedil_sessions/view/2892 ■ https://www.docswell.com/s/DeNA_Tech/KR21PE-CEDEC2024-GD SRE © DeNA Co., Ltd. 42
要点 ● SRE は抽象型である、それぞれの場に実装がある class SRE implements interface DevOps class YOU implements abstract SRE ● ゲーム開発者向けの実装として「ゲーム開発者のための SRE」 を定義した（名前をつけた） ● 働き方・考え方としての SRE の啓蒙と 役割・ロールとしての SRE チームを作り、組織に定着させた © DeNA Co., Ltd. 43
２年経過してどうなったか ● メンバーが３名から５名に増員 ● CI/CD 中心の活動から、開発環境全般に活動が拡大 ● 非常に多くのことを任せていただけるようになった ● Enabling SRE により SRE の考え方を他チームへも展開 ○ Pokémon TCG PocketをIntegration & Deliveryし続けるために 〜 リリースエンジニアが大規模開発にもたらした安定運用〜 | CEDEC2026 © DeNA Co., Ltd. 44
２年経過して考える再現性 ● 専門チームを作ること ● 役割を明確にし、パートナーチームと伴走する ○ プロジェクトのやるべきことを進めつつ 改善を回すタッグを組む ● タスクフォースチームではなく、継続的な組織とした ○ 主業務として改善を回す ○ 終わりを作らない © DeNA Co., Ltd. 45
２年経過して考える再現性 ● チームの道標となる、ビジョンを語ること ○ 開発チームが「楽」してゲーム開発・運営ができる場を作る ○ ビジョンに共感するメンバーを集める ● 自分たちが何者かを表す、ネーミングをすること ○ 組織全体への説明、チームとして信頼を得る ● チームのあるべき姿を定期的に議論ができていること ○ 直接的な業務以外って腰が重いけど大事 © DeNA Co., Ltd. 46
それでも、時間がない！！ © DeNA Co., Ltd. 47
それでも、時間がない ● さまざまなことで頼っていただけるようになった ○ ありがたい ● 終わらせることができなくなってくる ○ TODO が溜まっていく ● 改善を回すチームが、改善をできなくなっているのはマズイ © DeNA Co., Ltd. 48
多忙化の壁を越える © DeNA Co., Ltd. 49
人間は慣れてしまう生き物である ● 忙しくて、改善したいことが溜まっていく ○ パートナーと伴走することで、改善を主体に活動するのが SRE ではあるが、それでも全部できてる状況ではないです ● この状況が常態化すると、できてなくても気にならくなる ● このままでは忙しくて改善できない組織に戻ってしまう © DeNA Co., Ltd. 50
どうするか？ ● AI に頼る？ ○ AI によってタスクは早くこなせるようになった ○ AI なら今できていないことも、やってくれるはずではある ● できそう、なんだけど実際にはそうはできていなかったり… ○ 現状は人間が起点となっている ○ 理解負債・認知負債も関係ありそう © DeNA Co., Ltd. 51
どうするか？ ● AI に「も」頼る ○ 遂行する力はあるので頼る ● お客様は「ゲーム開発者」であり人である ○ これが変わらない限り、人が原動力になる © DeNA Co., Ltd. 52
どうするか？ ● 人のエコシステム ○ 積極的に新メンバーを迎え入れ、鈍った思考を活性化 ■ なんでこうなってるんですか？をきっかけにする ○ SRE の思想を持った人材の輩出 ■ チーム外を Enabling していくこと ■ 改善が当たり前、ロールとしての SRE が不要となることを目指す ○ チーム外のできるを増やし、意識変化をしていくことで 自分たちが新しい場に進むことができるようになる © DeNA Co., Ltd. 53
最終的には組織から文化へ ● 忙しすぎて改善できない組織を、 SRE という役割と組織化で対応している ● 最終的には改善が当たり前な文化を目指している ● AI によって自然発生的に改善意識が芽生えているので、 今がチャンスでもある © DeNA Co., Ltd. 54
まとめ © DeNA Co., Ltd. 55
技術的負債体質からの脱却 ● 技術的負債と常に向き合う組織を継続していくことで 構造を作りました ● 技術だけではなく、意識の変化、考え方の変化、 変化に挑戦し、これからも開発を楽していきます © DeNA Co., Ltd. 56
© DeNA Co., Ltd. 57