【NTTドコモ様】ドコモで実践するMagicPod活用による 開発の効率化と付随して得られたもの

オンラインMagicPodミートアップ2026、三井 力様（株式会社NTTドコモ 第一・第二プロダクトデザイン部）の発表資料です。

Transcript

1. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 1 ドコモで実践するMagicPod活用による 開発の効率化と付随して得られたもの NTTドコモ シニアプリンシパルアーキテクト 三井 力
2. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 2 プロダクトデザイン部の立ち位置 通信事業 スマートライフ事業 法人事業 など100＋ ドコモグループ の開発＆運用をプロダクトデザイン部が所掌
3. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 3 プロダクトデザイン部の規模 スマートライフ事業 ドコモグループ 年間リリース回数 ： 12,000＋ システム数： 108 アプリ数 ： 121 社員数 ： 592 クラウド利用システム 89（82％） アジャイル開発対象プロダクト 124 (60%)
4. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 4 ▪ 人物像（要約） クラウド・アジャイル・内製化を“現場実装”で成功させてきた実践派DXリーダー ▪ 主な特徴（3点） ① クラウド × アジャイルの実践推進者 •オンプレ中心 → クラウドネイティブへの転換を牽引 •ウォーターフォール → アジャイル／DevOpsへ改革 ② 内製化・エンジニア組織改革のリーダー •SIer依存からの脱却 •社内エンジニア育成と内製開発体制を強化 ③ SRE・オブザーバビリティ思想と高い親和性 •監視からオブザーバビリティへ •品質・可用性・セキュリティを統合的に改善 ▪ 社内外での評価 •社内：「実装がわかるDX責任者」 •社外：「大企業DX成功事例のキーパーソン」 役職：NTTドコモ 第一・第二プロダクトデザイン部 シニアプリンシパルアーキテクト 2025.12.8
5. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 5 BizDevOps一体となって顧客体験価値を向上させることに注力 Biz Dev Ops Plan Check ｼｽﾃﾑﾃﾞｰﾀ 行動ﾃﾞｰﾀ アジャイル開発 クラウドネイティブ ユーザ体験重視、デザイン思考 (行動観察、ｲﾝﾀﾋﾞｭｰ) B/G deployment コスト効率化 マイクロサービス プロトタイピング ドッグフーディング データ活用 (GA,ISSA) SLI/SLO/エラーバジェット 障害統制 高速（自働化）かつ効率的（データ活用・AI含）にプロダクトを改善する DevSecOps NoOps セキュリティ E2E自動試験 外形監視 CI/CD IaC Shift Left
6. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 6 E2E自動試験は絶対必要！ E2E自動試験はプロダクト開発のアジリティと開発効率を両方向上させる ①効率がよいチーム(理想的チーム：E2E試験自動化済) ②効率が悪いチーム（E2E試験手動実施または部分的自動化） スプリント＃1 スプリント＃2 スプリント＃3 スプリント＃4 ★ ★ ★ ★ スプリント＃1 スプリント＃2 スプリント＃3 ★ スプリント＃1 スプリント＃2 スプリント＃3 スプリント＃4 ★ ★ ★ ★ リリース回数が少 なくアジリティ低い 開発効率が低い リードタイムが長い E2E試験 E2E試験 E2E試験 ✓ アジリティ高い ✓ 開発効率高い
7. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 7 E2E自動試験は絶対必要！ E2E自動試験を導入できないチームの理由 E2E自動試験を導入していたチームは、コストも考慮しOSSを利用していた OSSの場合、導入ハードルやメンテナンスが大変で導入の敷居が高かった
8. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 8 MagicPod導入理由！ • Web&モバイルアプリのE2Eテスト自動化ツール • ノーコードで簡単にテスト作成 • 豊富なコマンドとメンテナンス性の高さが強み • 実行回数に制限なし • SaaS型E2E自動試験ツールの中で低コストで導入可能 目的の領域を選択 パーツをAIで自動判定 シナリオ作成画面
9. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 9 GitHub Actions Slack通知 成功時 失敗時 CI/CDとの連携(GitHub Actions)による自動化 GitHub Actionsと連携することでソースコードをマージするタイミングで、 アプリ自動ビルド→MagicPodへアップロード→自動テストが可能になる ソースコードをマージ するタイミングで GitHubActionsが動く アプリのビルド、単体試験等 MagicPodへ アプリをアップロード E2E試験の自動実行 結果通知
10. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 10 まずは小規模だが価値が高いドコモのベースアプリチームで導入 259件中184（内49件はdアカログイン）のテストケースで自動化可能（約70%) MagicPod導入前 MagicPod導入後 導入フェーズ 環境構築・設定 （GitHubActionsとの連携） - 4h テスト・シナリオ作成 - 40h 計 0h 44h MagicPod導入前 MagicPod導入後 開発フェーズ 試験（※）範囲検討 （既存分） 1h 0h テストシナリオ作成（既存 分） 4h 0h テスト・シナリオ作成 （新規開発部分） 4h 4h 試験実施 20h 0h エビデンス確認 2h 1h 計 30h 5h CICDとの連携により、自動実行されるためシナリオ 作成できた部分は人員稼働が0になる ※ただし、これ以外に現在自動化できていない部 分が別途かかる これも今後の運用で改善予定あり MagicPodを習熟してくことで テストシナリオの修正（運用）部分 の工数はさらに減少予定 25h削減 （※）試験＝総合試験のうちリグレッション試験を指す
11. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 11 ドコモベースアプリチームで導入してよかったこと（定性＋定量） • 利用者側実行環境の自由度が高い アプリをアップロードするだけで、開発環境の構築や端末を用意することなくシナリオ作成が可能 • 端末/OSのバリエーション試験が可能 1つのシナリオで複数端末、複数OS切り替えて試験が可能！ ※AndroidはNexus/Pixel 条件分岐など必要な場合あり • シナリオ作成が簡単にできる（GUI操作が簡単で何より楽しい！） 画面からパーツをドラッグ＆ドロップでシナリオ作成可能 • エビデンスが画像付きでわかりやすい • 問い合わせがしやすい 返答も早い 作成しているシナリオ部分で疑問点あればそのシナリオを通して問い合わせが可能 • ３スプリント（1.5か月）で導入費用回収ができる、開発効率があがる • 品質が向上する リグレッション試験を手動で実施する際は、コスト効率化の観点から影響範囲を定めてから試験の 項目を抽出する場合があったが、自動試験の場合は全て実施できる。「影響範囲を見誤りました」という 理由による不具合がなくなる！
12. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 12 大規模案件への適用
13. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 13 自動化における二大課題と対策 対策②毎日夕会でテストケースレビュー 対策③画像差分確認による想定外不具合の検知 課題1. 自動試験の品質 対策①テスト作成ルールの標準化 対策④各UIにテスト用の固有IDを付与することでメンテナンス頻度削減 課題2. テストケースの作成・メンテナンスコスト トライアル～初期段階から運用に向けた課題の対策を継続的に行った ◼ 作成者によってテストケース品質にムラが出る ◼ 手動試験で見つかっていた不具合が自動試験で検知できない ◼ AndroidとiOSで別々のテストを作る必要がある ◼ MagicPodがUIを認識せずテストが動かなくなることが多発
14. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 14 対策①テストケース作成ルールの標準化 手動試験：試験意図を読み取って柔軟に判断 「～が表示されてるし、エラーも出てないからOK!」 自動試験：定義したこと以外はやってくれない →確認ポイントを言語化する必要がある！ 対策 2.過去不具合を分析し、不具合検知策を反映 ✓ テンプレート通りに作れば一定以上の品質を担保 ✓ 新規メンバーの指針になり学習コストも低減 ✓ レビュー前にある程度の品質になっているため、レビューが本質的な点に集中 課題 テンプレート 1.試験項目種別ごとにテンプレート化 いくつかテストを作成した結果、試験項目種別で確認ポイントが類似することを発見 不具合種別 MagicPodでの検知方法 レイアウト崩れ 「画像差分確認」と「UI存在確認」コマンドの併用 非正常なUIの状 態変化 「UI要素の画像が保存された画像と一致する」コマ ンド 試験項目種別 使用コマンド、確認ポイント 画面遷移確認 ・画像差分機能で全体レイアウト確認 ・画面特有のUI要素の存在を確認 状態遷移確認 ・操作前後で表示/非表示確認およびUI画像比較 効果 3.作成時の工夫やレビュー指摘 テストケース
15. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 15 対策②毎日夕会でテストケースレビューを実施 作成ルールを明文化したとしても感覚的なところは残るため、作成者によって テストケース品質のバラつきが生じてしまう 初期：全体レビュー 1か月後～：慣れてきたところでペアレビューに移行 ◼ 言語化が難しい観点での品質向上（試験設計、試験実行経験のあるメンバーも含む） ◼ 確認観点の統一、作成スキルの底上げ ◼ 全体レビューで感覚を合わせたため、ペアレビューでもテストケース品質を維持 後半：全体議論 夕会前半：ペアに分かれてレビュー 判断が難しいところの方針決定 作成・運用課題の整理等々 対策 課題 効果 全員でTeamsに繋ぎ、同じテストケースを レビュー
16. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 16 対策③画像差分確認による想定外不具合の検知 手動試験：期待値以外の不具合も発見できる 自動試験：想定外の不具合は検知が難しい 対策 ・通常の自動試験だけでは拾いきれない、意図しないレイアウト崩れを検知 ・手動試験でよくある実施者による確認の抜け漏れ、確認精度のばらつきも防止 ・画像差分確認コマンド利用：期待値画像とテスト実行時の画像を比較し、差分を算出 どこが変わったかハイライト表示 不具合すり抜けを最小化するため、想定外不具合も見つけられるようにしたい 期待値画像 テスト実行時(レイアウト崩れ発生) 課題 効果
17. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 17 対策④テストケース作成・メンテナンスの効率化 ◼ UIを特定するIDがデプロイ毎に変わり、都度テストケース修正が必要(下図) ◼ 同じ試験シナリオに対してAndroid/iOSで別々に作成する必要がある(アプリの場合) ✓ テスト用IDを各UI要素に付与し、IDを不変にする ✓ IDはAndroid/iOSで共通とする ※ID付与にはソースコードに手を入れる必要があるため、開発チームの協力を依頼 (連携の流れ)説明会開催→ID付与による性能影響調査→ID付与実装→レビュー 対策 IDの変化例 ID付与による効果は大きく、 開発チームに感謝！ ◼ メンテナンス工数減：ID変更によるテスト修正が不要に ◼ Android/iOSでテストケース一本化 ◼ テスト失敗の削減、実行速度向上 課題 効果
18. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 18 自動試験による手動試験の巻き取り（大規模案件での実績） 手動試験 自動試験 事前準備(試験データ準備等) 1人日 1人日 実行 22人日 0人日 失敗ケースの原因調査 (不具合か切り分け) 0人日 2人日 合計 23人日 3人日 2025年7月以降、スマホ/Webアプリのリグレッション試験について自動試験による巻き取りを開始 例）2025年12月のスマホアプリにおけるリグレッション試験実施工数(1800実行あたり) ー20人日（87％削減） 定性 ◼ 自動試験からの不具合すり抜けは見つかっていない ◼ 今まで手動試験で見つからなかった不具合を検知できた例も ◼ 自動試験では人手による結果確認や調査・修正が必要になる Delivery Cost +Quality 高速化 コスト効率化 品質向上 定量
19. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 19 AIエージェントを利用したメンテナンス効率化検証 AIエージェント＋MCPサーバによって失敗原因調査および修正案の提案 利用イメージ プロンプト 分析結果 MagicPod MCPサーバ MagicPod 以下を検証予定 ・失敗原因、修正案の内容の一致率 ・修正の所要時間 ②実行ログ取得 ①プロンプト入力 ③失敗原因分析、修正案検討 ④修正 MagicPod MCPサーバー（ベータ版） – MagicPodヘルプセンター アプローチ ゴール設定 AIエージェント (Cline+GitHub Copilot) STEP0 STEP1 STEP2 原因調査 手動 半自動 (AIによる補助) 自動 (原因調査→修正のプロ セス自動化) 修正 手動 手動 (AIの修正案利用)
20. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 20 テストケース作成の自動化検証 MagicPod Autopilot (ベータ版) について – MagicPodヘルプセンター ◼ MagicPod Autopilot(テスト自動作成機能)を利用 ◼ 試験手順を記載したプロンプトに従ってテストケース自動 作成 ゴール設定と検証状況 自動作成された ステップ プロンプト テストケース編集画面 STEP3まで ◼ 細かく指示を出せば、ほぼ意図通りに作ってくれる (もちろんレビュー、手直しは必要) ◼ ただ、プロンプト作成に時間がかかる… →プロンプト作成をいかに自動化するかが鍵 ◼ STEP3では、既存テストケースを事前情報として有効活用し「壁」を打破している最中 STEP0 STEP1 STEP2 STEP3 プロンプト作成 - 手動 手動＋プロンプト テンプレートの利用 自動 (既存テストケース情報を利用し、 試験項目票から自動作成) テストケース作成 手動 自動 自動 自動 総作成時間 削減率 - -21% -31% -66% チャット欄 「壁」 アプローチ
21. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 21 組織として現状と今後
22. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 22 外形監視チーム E2Eリグレッション自動試験 MagicPod中心にプロダクトチーム毎 スマホアプリを提供しているプロダクト OSSを軸に単一チームで 今後さらなるAIによる効率化！ プロダクト別チーム 主要導線のみ Appium利用 (ブラウザの場合Playwright）
23. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 23 ご清聴ありがとうございました
24. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 24 ドコモアドベントカレンダー2025に投稿予定(12/8)
25. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 25 AIアサーション 自然言語で確認観点や期待値を記述するだけで生成AIが画面やテキストを理解し、判定を行う機能(テストケースの1コ マンドとして使う) AIアサーション – MagicPodヘルプセンター 10/21リリース できること ◼ 検索条件と結果の整合性：データの意味を理解した確認 ◼ 一覧画面・フィード画面：内容が動的に変化する画面 ◼ UIツリーに存在しないUIの確認(以下で検証) 従来のコマンドでは対応が難しかった確認が可能に 早速使ってみた ✓ 成功パターンだけでなく失敗パターンでも正しく失敗と判定されるか確認する ✓ 安定性・信頼性を高めるため、具体的で明確な文を書く 注意点 あくまでもAIによる判定であること 指示：「タブの下部にピンク色のインジ ケーターが表示されていることを確認」 成功！ Assertion passed: 画像を分析した結果、以下の観察ができます： 1. 画面上部に3つのタブが表示されています：「レビュー」「チャプター」「いいね」 2. 「チャプター」タブが現在選択されている状態です 3. 「チャプター」タブの下部に明確なピンク色（マゼンタ色）のインジケーターラインが表示さ れています 4. このインジケーターは選択されたタブを示すために使用されており、タブの幅全体にわたって 表示されています 5. コマンド履歴を確認すると、最初に「[チャプター]」をタップし、その後「レビュータブの下 部にピンク色のインジケーターが表示されていないことを確認」というアサーションが実行され ています。現在のアサーションは「チャプタータブの下部にピンク色のインジケーターが表示さ れていることを確認」となっており、チャプタータブをタップした結果、インジケーターがチャ プタータブに移動したことを確認する意図と考えられます AIによる分析の流れをMagicPodログで確認できる 期待値の確認 確認意図の予測 背景情報の理解 活用シーン
26. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 26 共有ステップ 繰り返し使用される一連の処理を部品化し、複数のテストケースで呼び出せる機能 共有ステップの活用 – MagicPodヘルプセンター 例：キーワード検索～作品選択～作品詳細の画面遷移 検索画面 ホーム画面 検索結果画面 作品詳細画面 検索アイ コンタップ キーワード 入力 作品選択 画面遷移の流れ メリット テスト作成の効率化: 同じ手順を何度も作成する必要がなくなる メンテナンス性の向上: 共通処理の変更が一箇所で完了 テストの可読性向上: 操作手順を意味のある名前で抽象化 注意点 共有ステップ作成基準のルール化 ✓ 粒度(ステップ数)、同じ処理が～回以上出てきた場合に作成など) 実装 共有ステップによって、同じ遷移が必要な テストを作成する場合に再利用可能に
27. © 2008 NTT DOCOMO, INC. All rights reserved. ⓒ2026 NTT DOCOMO, INC. All Rights Reserved. 27 自動修復機能 ◼ デザイン変更等でUIが変わった場合にテストケースを自動的に修正する機能 ◼ 変更のたびに修正する手間を削減 自動修復機能とは – MagicPodヘルプセンター UI変更をキャッチ 修正案を提示 テスト結果画面で自動修復内容を確認 問題がなければ「承認」で自動修復 ・UIの削除、コンテンツがなくなった ・UIデザインの大きな変更 ・機能変更：画面フローや操作手順の変更 自動修復が走るケース ・位置の移動 ・ラベルテキストの変更 ・クラス名やID属性の変更 ・UI階層の変更 対応できないケース UI変更前 UI変更後 現状では対応できないケースの方が多く、今後の精度向上に期待 MagicPod CEO「修復できる変更は体感で全体の30%くらいです。」 「(生成AI技術によって) 修復の精度を飛躍的に高められると考えています」(MagicPod公式note)