【DeNA TechCon 2025】 IRIAMの仮説検証高速化チャレンジ（プロセス改善アプローチ）

IRIAMの仮説検証⾼速化チャレンジ 品質管理部による開発プロセス改善アプローチ 1 © DeNA Co., Ltd.

⾃⼰紹介 道上 宜宏(みちがみ たかひろ) IT本部 品質管理部 QC2グループ QMOチーム 2023年11⽉ DeNA⼊社 ⼊社前： エンジニア/PjM/品質管理/PMO ⼊社後： IRIAMの開発プロセス改善⽀援 IT戦略部の品質改善⽀援 2 © DeNA Co., Ltd.

DeNAの品質管理部とIRIAMとは‧‧‧ DeNAの品質管理部とQMOチーム QMO(Quality Management Office)チーム 開発組織や開発プロジェクトの品質向上⽀援 プロジェクトマネジメントの強化 開発プロセス改善⽀援 品質管理組織の⽀援 など DeNA TECHNOLOGY REPORT 品質管理編より抜粋 3 「Delight品質 品質管理部」でも検索してください！ © DeNA Co., Ltd.

• https://engineering.dena.com/technology-report/quality-control.pdf

DeNAの品質管理部とIRIAMとは‧‧‧ IRIAM Culture Deckより抜粋 IRIAM ぜひ読んでください！ ■技術環境 開発⾔語（クライアント）：C# (Unity) 開発⾔語（サーバー）：Go インフラ環境：Google Cloud Platform 4 © DeNA Co., Ltd.

• https://www.docswell.com/s/IRIAM/KJ48G1-2024-11-07-121852

このセッションは 急成⻑を続けるIRIAMの開発組織で ユーザーの皆様により早く新しい体験をお届けするために QMOのメンバーがIRIAMのエンジニアのみんなと⼀緒に プロセス改善にチャレンジした そんなお話です 5 © DeNA Co., Ltd.

⽬次 ● ● ● ● ● 6 品質管理部の⽀援活動のまとめ 改善の⽬的整理と⼿段の検討 やってみよう リリースしてみた 気をつけたこと、これからも考えること © DeNA Co., Ltd.

品質管理部の⽀援活動のまとめ 7 © DeNA Co., Ltd.

品質管理部の⽀援活動のまとめ ⽀援の⽬標 （何がしたかったか） ⽬標達成⼿段 （どう実現したか） 8 ⽬標と⼿段 品質を下げずにリリースサイクルを短くしたい ４週間毎 ２週間毎 開発→QAの直 列プロセス 開発チームで 品質を担保 © DeNA Co., Ltd.

品質管理部の⽀援活動のまとめ 改善施策内容 チームに対して ‧開発チームに最⼩限のプロセス追加を提案 実現するために 何をしたか ‧開発チームにQAが得意なメンバーをJoin ‧エンジニアが品質を考えるメリットを伝える 組織として ‧段階的なリリースアプローチ設計 9 © DeNA Co., Ltd.

品質管理部の⽀援活動のまとめ 約１年やってみた現在の状態 チームの開発完了から2週間でリリースに成功 ‧チームの開発完了＝SprintReview ‧２つのチームでリリース達成 どうなったか リリース後の障害は増えていない チームで品質を考える習慣が根付き始めた 10 © DeNA Co., Ltd.

改善の⽬的整理と⼿段の検討 11 © DeNA Co., Ltd.

⽀援が必要になった背景 開発プロセスの変容が必要なフェーズに 〜2023 開発の不確実性が低い機能への対 応が中⼼ （必要なもの、ユーザーが求めて いるものが分かりやすい） 定期的にしっかり検証したもの を提供する 12 2024〜 提供する最適なUXが分かりにくい ちいさくはやく提供してユーザー の反応を検証する © DeNA Co., Ltd.

はやく提供するにはQA⼯程がボトルネックに PdMの お仕事 開発チームのお仕事 (複数チーム) QAチームのお仕事 (１チーム) 🌟リリース対象の調整＆テストの開始(4週間毎) 任意の期間 PRDの作成 任意の期間 2週間スプリント 2週間スプリント 仕様＆ デザイン確定 開発＆動作確認 4週間 10営業⽇ 3営業⽇ 5営業⽇ 検証＆脆弱性診断 リグレッショ ンテスト 申請＆準備＆ リリース テスト開始⽇の前⽇に開発完了してもリリースは４週間後 テストの締切にギリギリ間に合わなかった場合は８週間後 13 © DeNA Co., Ltd.

QA⼯程のボトルネックを解消するにはどうすれば？？？？ ⼀度にリリースする量を半分にすればQA期間も半分になるんじゃない？ 回数を増やすことによるオーバーヘッドで出せる量減るかも 期間が半分だとバグ検出後のエンジニア対応も厳しく（プレッシャー増⼤） そもそも 開発とテストの⼯程が直列関係＆担当チームが分かれている メリットもあるがスピードの観点では前述のようなデメリットも それじゃどうする 開発チームがリリース可能な状態まで責任を持って開発を⾏う （インプロセスQAの考え⽅をチームに投下） 14 © DeNA Co., Ltd.

インプロセスQAとは？ 開発チームの中に、QAが得意な⼈が⼊って、チームの⼀員としてQA対応 を⾏いながらチーム全体で品質を⾼めるための活動を促進する ※道上の考えるインプロセスQAの解釈です ※諸説あると思います ぜひ皆様もインプロセスQAを調べてみましょう！ 15 © DeNA Co., Ltd.

開発チームでリリース可能な状態にできると本当に早く出せる？ P12の後半スプリント→検証＆脆弱性診断までの4週間を拡⼤ 1スプリント(２Weeks) 1weeks 開発完了 インプロセスQA 🌟 従来 インプロセ スQA 16 🌟 従来 2weeks 3weeks 🌟 何も動きがない期間 🌟 開発完了 テスト開始 🌟 4weeks 🌟 テスト(QA検証)開始 何かあった時の余裕期間 テスト完了 🌟 最終確認 2週間早くリリースできる状態に 最終確認 開発完了からテスト開始まで期間が⻑くなる場合もあり 期間が開くとバグ修正コストも増加 （思い出し＆他の開発が進んでいる場合の影響対応） まとめてテストするからテスト期間も⻑め 開発中にテスト準備しておけばすぐにテスト着⼿ バグがあっても修正コスト低下 特定の機能＆影響範囲のみテストするからテスト期間も短め © DeNA Co., Ltd.

やってみよう 17 © DeNA Co., Ltd.

やったことは⼤きく３つ 1. インプロセスQAを実施できるチームを作ろう 2. 実施した施策の正しさを検証しよう 3. リリースしよう 18 © DeNA Co., Ltd.

1. インプロセスQAを実施できるチームを作ろう 仮説検証をどんどんやりたいチームを対象に以下を実施 1. 既存の開発プロセスを⼤事にしながらチームで検証するプロセスを導⼊ 2. QAが得意なメンバーをチームにJoin 3. テストとは！品質とは！なぜエンジニアがテストするのか！のお勉強会を実施 1.追加したプロセス SprintPlanning チームの受け⼊れ条件検討 (思った通りの挙動とは？PRDの詳細化) SprintReview 思った通りに動くか実施確認の徹底 （機能、UX） 2.QAが得意なメンバーをJoin ‧プロセス改善を主導している道上＆IRIAM QAグループの守護神を開発チームメンバーに！ 3.お勉強会のお題⽬ ‧なぜエンジニアもテストするの？‧品質とは？‧テストとは？‧テスト技法とは？ 19 © DeNA Co., Ltd.

2. 実施した施策の正しさを検証しよう そもそも⼿段としてインプロセスQAの投⼊は正しかったのか インプロセスQAは定着しているのか、リリースプロセスに不備はないか インプロセスQAの導⼊の効果を検証するために実際にリリースしてみる 20 © DeNA Co., Ltd.

2. 施策の正しさを検証しよう ちょっと待って 本当にリリースしていい？？ 21 © DeNA Co., Ltd.

2. 施策の正しさを検証しよう リリース回数が増えることの影響を改めて精査 ‧ユーザーへの影響（アプリの強制更新が増えるとユーザーに負の体験が） ‧事業への影響（リリース⼀回あたりに必要なコストを試算） 不⽤意にサービスが利⽤できない時間は増やせない リリースの⽬的 ‧ユーザーに明確な価値を届けられる ‧価値向上のための仮説検証の実施 ‧サービスの運⽤向上につながる機能の実装 22 © DeNA Co., Ltd.

2. 施策の正しさを検証しよう 施策の正しさを検証するにリリースする ⽬的と⼿段の逆転 23 © DeNA Co., Ltd.

2. 施策の正しさを検証しよう インプロセスQAの導⼊の効果を検証しながら施策を進めるために 全体へのハレーションを考慮したリリース⽅針を考える 3段階のリリースプロセスを準備 1. 24 仮想2weeksリリース a. 開発チームとしては2週間でリリース b. IRIAMとしてはリリース回数は増えない メンテナンス＝リリースのためのサービス停⽌時間あり メンテレス＝リリースのためのサービス停⽌時間なし 詳細は本資料のAppendix.にて 2. メンテレス2weeksリリース a. 開発チームとしてもIRIAMとしても2週間でリリース b. ユーザーが利⽤できないメンテナンス時間は発⽣させない 3. メンテレス2weeksリリースの範囲拡⼤ a. 開発チームとしてもIRIAMとしても2週間でリリース b. 追加開発を実施して強制更新は発⽣させないリリース⽅法を投⼊ © DeNA Co., Ltd.

リリースしよう 25 © DeNA Co., Ltd.

3. リリースしよう ちょっと待って Pert.2 本当にリリースしていい？？ 26 © DeNA Co., Ltd.

3. リリースしよう ユーザーに影響が⼩さいリリース⽅針を考えたけど‧‧‧ リリースしたものに不備があったら結局迷惑かけるじゃん 27 © DeNA Co., Ltd.

3. リリースしよう チームと並⾛しながら「本当にリリースしても良い品質か」を問い続ける ‧本当にインプロセスQAで品質担保できてる？ ‧どんな機能でもチームの判断でリリースしても良いの？ ‧本当に⾃由にリリースしていいの？ 28 © DeNA Co., Ltd.

3−1. 本当にインプロセスQAで品質担保できてる？ 既存プロセスと新プロセスの並⾏運⽤で検証内容を⽐較 リリースできる品質レベルとは？ 具体的に実施したこと リグレッションテストからマージするということは これまでのQA検証と同じレベルのQAをチーム内で実現すること！ チーム開発 チーム開発＆ チームQA QA検証 ここが同じレベルの 品質になっている リグレッション リグレッション 3ヶ月はチームでQAを実施した開発もQA検証を実施 （ダブルチェックを実施していた） チーム開発＆ チームQA QA検証 チームQAとQA検証のダブルチェックを実施 フルチェック テスト内容を比較する 確認した結果 インプロセスQA実施チームのテストと既存プロセスで実施したテスト内容に⼤き な差分はなく、結果も遜⾊ないものだった（⼩規模開発のみ検証） 29 © DeNA Co., Ltd.

3−2. どんな機能でもチームの判断でリリースしても良いの？ チームでリリースできる機能の特性を探りにいく QA検証不要でリリースプロセスに乗せられる条件の可視化 具体的に実施したこと 開発規模が⼤きい場合、開発チームのみで全ての機能を検証すること が難しい。データや環境の準備、テストパターンが多いものはQAグ ループで対応した⽅が質とスピードを担保できる場合もある これまで該当のチームで開発した機能について「⾃分のチームでリ リースできる状態にできる機能だったか」の分析を実施。 その中で判断軸になるものを抽出し⾃チームで対応が可能な機能の特 性を整理 他のチームで開発している機能に影響がある場合もチーム単独でテス トをやり切ることは難しい 計画的なリリースを⾏うためには開発着⼿前に「チームで品質を担保 できる機能なのか」を判断する必要がある 30 © DeNA Co., Ltd.

3−2. どんな機能でもチームの判断でリリースしても良いの？ 具体例 チーム内で品質担保できそうな機能ディスカッションの⼀部抜粋 機能の内容 31 チームQAで なんで？ 趣味タグ選択画⾯へ 出せそう の機能追加 ‧検索できなくても進⾏不能にならない ‧他の機能に影響がない、ONEでクローズできる ‧QAも検索に対するシンプルな確認 ‧⼊⼒項⽬になるので、脆弱性診断の対象となる ‧検索はユーザー状態は変化なし ポップアップの差し 出せそう 替え ‧特定のポップアップの⽂⾔を修正しただけ、 ‧制御はクライアント側、⽂⾔はサーバー側の処理 ‧進⾏不能にはならない ‧発⽣頻度もそこまで⾼くない ‧サーバー側だけの処理であれば⾼速対応可能、ストア対応不必要 配信画⾯内のコメン QA検証した⽅ トのパターン追加 が良さそう ‧コメントの処理は実装が込み⼊っている ‧分岐が増え続けている （デグレの可能性が⾼い、状態による⽂⾔の組み合わせが発⽣する） ‧サーバーと配信サーバの連携が発⽣、複数APIが連携して動いている © DeNA Co., Ltd.

3−3. 本当に⾃由にリリースしていいの？ ⾃由なリリースのために最低限のルールを探っていく メンテレスリリース条件の 解像度を⾼める ‧リリース責任者が実態を把握する 組織として機能を管理 ‧チーム内で品質を担保できる チーム内QAとリグレッション のみでリリースを実施 ‧メンテレスリリースの対象機能 現状ではAPIとサーバー処理 ‧費⽤対効果が⾒込める 1回のリリース費⽤数10万 ⻑期的視点でRoIを考える 32 具体的なリリースプロセス整備 SprintPlanning リリース⽇の検討(メンテレスリリース⽇を選択) メンテレスリリースの条件確認 RegressionTestの実施相談 Sprint 受け⼊れ条件の検討 SprintReview時のチーム内確認事項の検討 SprintReview時の確認環境の整備 SprintReview 事前に検討した確認事項をチームメンバーで検証 テストの実施状況＆結果の共有 チームでのリリース可否判断 ReleaseProcess① 現時点でのリリース判定（部⻑or副部⻑） RegressionTest QAグループ管理によるRegressionTestの実施 ReleaseProcess② 最終リリース判定（部⻑or副部⻑） Release リリース担当チームによるリリース作業の実施 © DeNA Co., Ltd.

• https://www.notion.so/iriam/QA-343513917fc349f39d0323bcd4c3b638?pvs=4#41b7f8ed751d495290e44a3eab9a16c5
• https://www.notion.so/iriam/QA-343513917fc349f39d0323bcd4c3b638?pvs=4#96a7dedf72324f93b910a7c09f6ebdd7
• https://www.notion.so/iriam/QA-343513917fc349f39d0323bcd4c3b638?pvs=4#10aded8402c780f1913ee4070e16d6c1

本当にリリースしてみた 33 © DeNA Co., Ltd.

リリースしてみた インプロセスQA実施チームのリリース状況 2024/02-2024/09 Team 対象 スプリント リリース 機能数 チーム内 QA 実施機能数 グループA 15スプリント 33 19 グループB 10スプリント 15 10 ２つのチームで 「仮想2weeksリリース」と「メンテレス2weeksリリース」 を実現！仮説検証の⾼速化を実現！ ※グループAについては「DeNA IRIAM フルスイング」で検索するとチームリーダーのインタビューが⾒れます！ 34 34 © DeNA Co., Ltd.

• https://fullswing.dena.com/archives/100143/

リリースしてみた ‧‧‧ 品質は？？ インプロセスQA実施チームのリリース状況 2024/02-2024/09 Team 対象 スプリント リリース 機能数 チーム内 QA 実施機能数 障害発生数 (開発起因 ) グループA 15スプリント 33 19 1 グループB 10スプリント 15 10 1 施策開始前の障害件数との正確な⽐較は難しいが 対象チームの開発が起因となった障害は減っている 35 35 © DeNA Co., Ltd.

‧‧‧あれ？品質上がってない？？ テストするタイミングを変えただけではない！ QAが得意なメンバーがチームにいるメリット！ チームでQAする！ ‧開発着⼿前（受け⼊れ条件検討会）にQA視点で気になることを可視化 この場合はどうなるの？があらかじめ可視化されることによるバグ混⼊防⽌ ‧どうテストするかを事前にPdMやエンジニアと認識を合わせられる テストが難しい(できない) → 仕様の簡素化を検討できる 確認が難しい → エンジニアによるデバックツールへの機能追加 ‧エンジニアがどう実装するかを事前に確認できる 実機でテストするべき観点を絞り込める ‧実装の複雑さを事前に確認できる 保守性を考えながらの開発が可能に（負債の作り込み抑制） 36 © DeNA Co., Ltd.

チームが⾃⾛したよ ⾃分たちで品質を担保するために⾃分たちがやるべきことを考えるチームに！ FY23 4Q インプロセス QA開始時のプロセス Sprint Start Sprint End Sprint Review Sprint Planning 実機動作確認 受け入れ条件検討 (道上主体→チーム主体に) エンジニアとチームQAのテストの担当整理 レスポンスなどの非機能に関しても事前検討発生 実装方針確認会 (事前に作り方を検討＆共有 ) UXの早期確認 既存テストチームとの連携強化 他チームとの PRD＆実装方針共有 チームが決めたプロセス 37 テストコードの書き方の勉強会 © DeNA Co., Ltd.

気をつけたこと、これからも考えること 38 © DeNA Co., Ltd.

外部の⼈間が⽀援するために気をつけたこと 外から来た⼈(謎のおじさん)がなんか⾔ってる‧‧になりがち‧‧‧ べき論よりは次の⼀歩！チームファーストで！ 歴史があって今の状態！現状をベースに次の⼀歩を！ 先導して⼀緒にやってみる → 効果を体感 → ⾃然と⾃⾛ 最⼩限のHowを投下して効果を体験してからWhyを補⾜！ プロセス改善も仮説検証！ 施策の⽬的と⼿段、時間軸毎の状態⽬標は事前に整理！ ⼩さく始めて細かく状態を確認 → ⽅針転換や軌道修正、加減速調整！ 39 © DeNA Co., Ltd.

これからも考えていくこと（⽴ち向かっていくこと） 「QA＝テストする⼈」という意識を組織全体から払拭する ２つのチームで実績を作りながら QAが得意なメンバーがテストをしないでチームのQA⼒を向上させる エンジニアにしかできないQAがあることを体験して実感してもらう 複雑＆膨⼤な既存テストコードとの戦い DeNAのテスト⾃動化が得意なチーム(SWETグループ)と⼀緒に既存コードを整理 永続的にテストコードを最適化し続けられる体制の検討 40 © DeNA Co., Ltd.

最後に‧‧‧私たちと⼀緒に働きませんか！！！！！ 品質管理部メンバー募集中 特にQMOチームで 組織の品質改善、プロジェクト推進、開発の上流から改善を⼀緒に進めてもらえる⽅！ IRIAMメンバー募集中 拡⼤していく開発組織の⽣産性を向上させていきたい⼈ ⼀緒に急成⻑プロダクトIRIAMの品質を⾼めていく⼈ DeNAの採⽤ページをぜひご確認お願いします！ 41 © DeNA Co., Ltd.

• https://dena.com/jp/recruit/

Appendix. 42 © DeNA Co., Ltd.

具体例：施策の正しさを検証するために多段階リリースプロセスを設計 ⽀援の⽬標 （何がしたかったか） 品質を下げずにリリースサイクルを短くしたい ４週間毎 ２週間毎 早くリリースしたいという⽬標だったが リリース回数が増えることの影響は検証できてる？ 43 © DeNA Co., Ltd.

早く出したいけど‧‧‧安易にリリース回数増やしても良いの？？ 仮説検証サイクルを早くするためにリリース回数は増やしたい！ けど リリース作業中は配信できないけどユーザーは嬉しい？ リリースの増加による事業に影響は？ クライアントのリリースには現在は強制メンテナンスが必要 ‧配信が実施できない、推しに会えない時間が追加発⽣ リリースにも⼀定のコストが発⽣ ‧リグレッションテスト実施コスト、リリース作業コスト ユーザーに明確な価値を提供できる場合以外は現状では 強制メンテナンスの回数を増やすことは控えたい 44 © DeNA Co., Ltd.

3段階のリリース⽅式 0. 既存のプロセス 0. 既存のプロセス 4weeksリリース Scramを取り⼊れているチームは2週間スプリント✖2回実施後にQAチームに引き渡す 🌟リリース 前半スプリント 後半スプリント QA検証 2週間 2週間 2週間 �� リグレッ ション 準備 2週間 6週間 �� 4週間 通常なら前半スプリントの完了からリリースまで6週間かかる 後半スプリントの完了からリリースまで4週間かかる 45 © DeNA Co., Ltd.

3段階のリリース⽅式 1.仮想２Weeksリリース 1. 仮想2weeksリリース リリース回数は増やさず、チームで検証が終わった機能を早くリリースする 2週間 V2.45 前半スプリント 後半スプリント QA検証 リグレッ ション 準備 インプロセスQAで検証できている状態だと V2.46 前半スプリント 後半スプリント QA検証 リグレッ ション 準備 6週間 通常なら前半スプリントの完了からリリースまで6週間かかる チームで品質担保したら2週間でリリースできる！ IRIAMとしてのリリース回数は変わらない！ 46 © DeNA Co., Ltd.

3段階のリリース⽅式 2.メンテレス２Weeksリリース 2. メンテレス2weeksリリース ユーザーに強制メンテの不便さを体験させずに新機能をリリースする(サーバー機能対象) 2週間 V2.49 前半スプリント 後半スプリント QA検証 リグレッ ション 準備 仮想2Weeksリリース V2.50 V2.49.1 前半スプリント 後半スプリント QA検証 インプロセスQAで検証できている状態＆強制メンテナンスが不要な機能 2週間 リグレッ ション リグレッ ション 準備 4週間 準備 通常なら後半スプリントの完了からリリースまで4週間かかる チームで品質担保したら2週間でリリースできる！ リリース回数を増やしたことでリグレッションテスト＋準備⼯数は増加 47 © DeNA Co., Ltd.

3段階のリリース⽅式 3.メンテレス２Weeksリリースの範囲拡⼤ 3. メンテレス2weeksリリースの範囲拡⼤ インプロセスQAの効果と実現性を確認できたら‧‧‧ 既存の仕組みではメンテレスリリースはサーバー機能のみという制限に対して クライアント機能もリリースできるように機能の改修を実施する(開発コストが発⽣) プロセス改善の成果を確認して（もしくは⾒通しが⽴って）からコ ストをかけて成果を拡⼤する 48 © DeNA Co., Ltd.