大規模アジャイル開発のリアル！コミュニケーション×進捗管理×高品質

久保 翔達（シニアアプリケーションスペシャリスト／課長代理）
竹田 達哉（シニアプロジェクトマネージャー／課長代理）

株式会社NTTデータ
テレコム・ユーティリティ事業本部
デジタルエクスペリエンス事業部
デザインアプローチ統括部

Transcript

1. © 2025 NTT DATA Japan Corporation 大規模アジャイル開発のリアル！ コミュニケーション×進捗管理×高品質
2. © 2025 NTT DATA Japan Corporation 2 1. 会社概要 2. 自己紹介 3. なぜ大規模アジャイルなのか？ 4. 大規模アジャイルで工夫すべき点 ① 大規模アジャイルでのコミュニケーション ② 進捗管理とリリースの難しさ ③ スケールに伴う品質管理 5. まとめ 大規模アジャイル開発のリアル！ ◆私たちの仕事や組織について、および経験者採用について
3. © 2025 NTT DATA Japan Corporation 3 01 会社概要
4. © 2025 NTT DATA Japan Corporation 4 （2024年3月期） 企業理念 情報技術で、新しい「しくみ」や「価値」を創造し、 より豊かで調和のとれた社会の実現に貢献する。 NTTデータについて
5. © 2025 NTT DATA Japan Corporation 5 02 自己紹介
6. © 2025 NTT DATA Japan Corporation 6 久保 翔達 株式会社NTTデータ シニアアプリケーションスペシャリスト／課長代理 テレコム・ユーティリティ事業本部 デジタルエクスペリエンス事業部 デザインアプローチ統括部 Webアプリ開発者、マネジメント人材として従事（WF開発5年、アジャイル開発7年）。モバイル業界、 EC業界、AI系と様々経験し、アジャイル開発としては、100人を超える大規模アジャイルの開発部隊を統 括。立上からプロセス導入まで行いスクラムのスケールを推進。Scrum Alliance認定プロダクトオーナー（ CSPO）、Scrum Alliance認定スクラムマスター（CSM） 竹田 達哉 株式会社NTTデータ シニアプロジェクトマネージャー／課長代理 テレコム・ユーティリティ事業本部 デジタルエクスペリエンス事業部 デザインアプローチ統括部 主にプロジェクトマネジメント人材として従事（WF開発5年、アジャイル開発5年）。アジャイ ル開発としては、100人を超える大規模アジャイル開発のPOA統括の経験。得意領域として は、モバイル業界やユーティリティ業界での業務設計/試験/リリースやUXを考慮したサービスデ ザイン設計、クラウド環境でのアーキテクチャ設計等。 自己紹介
7. © 2025 NTT DATA Japan Corporation 7 03 なぜ大規模アジャイルなのか？
8. © 2025 NTT DATA Japan Corporation 8 こんなことよくありませんか？ やりたいサービスはあるが、 社内での要件がまとまらず開発依頼できない と顧客から言われた。。。 なぜ大規模アジャイルなのか？
9. © 2025 NTT DATA Japan Corporation 9 マーケティング 経営判断 ❷ サービス整理 ❸ デザイン/ ブランディング ❹ 仕様調整/ 提示 BO*/PO ❺ 見積もり ❻ 開発開始 ❼ なぜ大規模アジャイルなのか？ 従来の大規模開発 ❶ 会社/組織 大規模アジャイル開発 デザイン マーケティング システム開発 BO 合同検討 合同検討でサービス設計/開発等を行い、 重要な大規模サービスを早く成功に導くことが可能！！ リリースまでに多くの時間がかかる 最適なタイミングでリリースできない！ ◆意思決定スピードが早い！ ◆意思決定品質が高い！ ☛同時にすべてのことが行われるため、 さまざまな観点でのコントロールが難しい。 ＊BO：ビジネスオーナー
10. © 2025 NTT DATA Japan Corporation 10 大規模アジャイルとは複数のチームが協力して一つのプロジェクトを進めることを指す。 実現するためのフレームワークとして、SAFe（Scaled Agile Framework）やLeSS（Large-Scale Scrum）などがあ るが、あくまでもフレームワークであるため、プロジェクト毎に異なる特徴を正確に捉えて、個々のプロジェクトに合わせたテーラリン グを行って、アジャイル開発を進めていくことが必要。 大規模プロジェクトをアジャイルで開発する場合に正解はないため、 自分たちで大規模アジャイルを作っていくことが必要。 なぜ大規模アジャイルなのか？ 大規模プロジェクト 正解はない！ or organization process development or or
11. © 2025 NTT DATA Japan Corporation 11 大規模アジャイルの特徴は、リソース・スコープが変動要素であること。そのため、それをしっかりとコントロールできる仕組みが必要。 なぜ大規模アジャイルなのか？ waterfall 開発 アジャイル 開発 大規模アジャイル 開発 Schedule Scope Cost / Resources FLEXIBLE FIXED FIXED FIXED 詳細要件まで固定 FLEXIBLE FLEXIBLE コンセプトや機能概要は固定だが 詳細要件は未確定要素 FLEXIBLE FIXED FLEXIBLE 可変のスコープを取り込みつつ、 柔軟にスケールさせるコントロールが肝
12. © 2025 NTT DATA Japan Corporation 12 ◆大規模アジャイルを導入し、早くリリースできる組織/プロセスを構築 ◆ただその組織やプロセスは難しいため、柔軟に実行できる準備（リリース /スコープ等）を徹底する必要がある なぜ大規模アジャイルなのか？ やりたいサービスはあるが、 社内での要件がまとまらず開発依頼できない と顧客から言われた。。。
13. © 2025 NTT DATA Japan Corporation 13 04 大規模アジャイルで工夫すべき点 ① 大規模アジャイルでのコミュニケーション ② 進捗管理とリリースの難しさ ③ スケールに伴う品質管理
14. © 2025 NTT DATA Japan Corporation 14 大規模アジャイルでは、様々な観点での検討が並行して進んでいくため、ハンドリングが非常に大事となる。ただステークホル ダー（チーム数や役割）が多く、変化のスピードも速いため、工夫が必要となる。 実態は… 理想 会社/組織 デザイン マーケティング システム開発 BO 合同検討 大規模アジャイルでのコミュニケーション デザイン マーケティング BO システム開発 PO PO PO 方針検討 開発検討 全体共有 デザイン検討 開発連携 ①プロジェクト推進に向けたハンドリングが重要 様々な観点で多くの会議が開催・検討される。技術的相談のみで なく、プロジェクト推進に向けたハンドリングが必要 ②要件をスピーディーに取り込める下地作り 流れ込む要件、要望を早く開発するために、アプリケーション開発に 集中できる仕組みと開発メンバーの案件理解が必要となってくる。 ✓ 異なるミッションを持つ組織が複雑に絡み合って連携 デザイン マーケティング BO システム開発 デザイン マーケティング BO システム開発 基盤 システム 関連 システム 開発 部隊 デザイン マーケティング BO システム開発 基盤 システム 関連 システム 開発 部隊 PO配下 デザイン マーケティング BO システム開発 基盤 システム 関連 システム 開発 部隊
15. © 2025 NTT DATA Japan Corporation 15 組織を跨ぐ検討を行う際は、その場でのハンドリングが最も重要。システム観点やデザイン観点を持つPOA* が主体的に動き、 ハンドリングすることで建設的な会話が行われ、早く、高品質のサービスがリリース可能となる。 大規模アジャイルでのコミュニケーション デザイン マーケティング システム開発 BO BO 開発部隊 基盤システム 関連システム PO POA PO 開発者 PO 開発者 リード デザイナー マーケター プランナー ・スケジュール： マイルストーンから逆算。対向先とのスケジュールすり合わせ ・UI/UX： システム観点を含んだ、デザイン会社と仕様の調整 ・マーケティング： システム観点でのマーケティング取得方法の調整 ・API連携： 対向先とのAPI調整 →作り上げるためのおぜん立てを実施した。 システム開発のPOAが他組織をコントロール 事業会社が行う部分も大規模では人数が足りない部 分もあるため、我々Sierの力は必要不可欠だった。 ＊POA：プロダクトオーナーアシスタント
16. © 2025 NTT DATA Japan Corporation 16 流れ込む要件や要望に対して、早く、また正確に取り込むべく、開発チームとしては、アプリケーション開発に集中できる仕組み と案件理解が必要となってくる。 大規模アジャイルでのコミュニケーション ワンチームでのシステム開発 開発メンバーに通常では伝えないプロジェクト全体の状況や、対 向先の開発状況、また追加案件の可能性等を頻度高く伝え、 案件への理解を行った。 プロジェクトへの理解がアジリティ向上に直結する！！ アプリケーション開発に集中 開発メンバーの一貫性を保つため、チーム横断のテックリードチー ムを作り、ソフトウェア品質や可読性などを強化した。 また全体実装方式やセキュリティなどのガイドライン作成を行い、 開発チームの基本を整えた。 デザイン マーケティング システム開発 BO BO 開発部隊 基盤システム 関連システム 開発者 PO 開発者 PO 開発者 リード デザイナー マーケター プランナー PO/POA 共通
17. © 2025 NTT DATA Japan Corporation 17 04 大規模アジャイルで工夫すべき点 ① 大規模アジャイルでのコミュニケーション ② 進捗管理とリリースの難しさ ③ スケールに伴う品質管理
18. © 2025 NTT DATA Japan Corporation 18 BO、SoR領域関連システムと足並みを揃え、サイクリックなリリースを行うことが求められる。 ① SoRとスケジュールを合わせた定期案件開発 ※サービス仕様変更や業務プロセス改善、法令対応などの案件 ② 短い周期でリリースを行う随時案件開発 ※サイトのコンバージョン率向上案件 や UI改善 ①②を組み合わせ、柔軟な要望対応と短期反復リリースを実現 進捗管理とリリースの難しさ SoR領域 BO SoE領域 ① ② SoR領域と連携が必要なリリースをうまく回すことが重要 N月 N+1月 N+2月 N+3月 N+4月 N+5月 Sprint X Sprint X+1 Sprint X+2 Sprint X+3 Sprint X+4 Sprint X+5 Sprint X+6 Sprint X+7 Sprint X+8 Sprint X+9 Sprint X+10 Sprint X+11 開発・試験 開発・試験 ★リリース 開発 開発 開発・試験 試験 開発・試験 開発・試験 ★リリース ★リリース 開発 開発・試験 ★リリース 開発・試験 開発・試験 開発・試験 ★リリース 開発 開発 開発・試験 試験 ★リリース 随時案件開発 定期案件開発 ウォーターフォール アジャイル
19. © 2025 NTT DATA Japan Corporation 19 着地コントロールでは、SoE側はWaterfall開発をするSoR側を加味した、マネジメントが必要。 進捗管理とリリースの難しさ ① 案件企画時点での初期計画 ② 要件定義後の計画精緻化 ③ 開発中の進捗管理 曖昧な要件を元に概算見積 ​⇒・投資対効果を踏まえた実施判断 ・各システムの開発体制構築 ・リリース時期・事業計画 SoR側と機能配置分担、APIの一覧を合意 • MVP（Minimum Viable Product）の 優先要件定義、RBC（リリースバーンダウ ンチャート）化 商用リリース日までの計画見直し • SoR側とのマイルストーン合意 （API仕様書、環境解放、リリース日等） • 最新のPBI（Product Backlog Item）、開発状況、生産性を元に RBCを定期的に更新、進捗確認 • ②で合意したマイルストーンに対するSoR 側の進捗状況の確認と計画反映 ❶ ❷ ❸ 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月 4月 5月 新SoE 新SoR ★実施判断 ★商用 リリース MVP（必須機能）の要件定義 開発 要件定義 基本設計 詳細設計 製造/UT 結合試験 総合試験 MVPとオプションを明確に決め、MVP優先で検討 トレードオフスライダーよりスコープ調整 or チーム追加 組織を跨りエスカレーション、予定タスクの順番を早期組み換え 未確定要素が 定まらない 精緻化により リリースにハマらない SoR側の開発遅延 a a b c b c
20. © 2025 NTT DATA Japan Corporation 20 04 大規模アジャイルで工夫すべき点 ① 大規模アジャイルでのコミュニケーション ② 進捗管理とリリースの難しさ ③ スケールに伴う品質管理
21. © 2025 NTT DATA Japan Corporation 21 スコープ ✓QCDSそれぞれに順位をつけるのがベストであるが、 現実的には、ステークホルダによって優先するものが違ったり、 全て優先度が高いと言われたりする。 ⇒ 左記のように最低と最高のものであったり、最低のもの だけを決めるといったことも有効。 ✓状況や環境の変化により、優先順位が変わるため、定期的にステーク ホルダとすり合わせ、更新が必要。 スケールに伴う品質管理 MAX MIN 一般的なアジャイル開発 高品質が求められる傾向 利用するエンドユーザも多く、一つの障害が大きな損失に繋がり兼ねない ・ リリースサイクル・リソースを固定（=コストと納期を固 定）し、品質とスコープがトレードオフ 日本のエンタープライズ向けアジャイル開発の傾向 ・ リリースサイクル・リソースを固定（=コストと納期を固定） ✓ 品質 ： 低品質がレピュテーションリスクにつながるサービスが多く、高品質が求められる ✓ スコープ ： MVPが多く、スコープ優先度も高い ✓ リソース：必要に応じて追加が許容されるケースもある 開発前にトレードオフ・スライダーを用いて、 あらかじめQCDSの優先度をステークホルダで合わせることが重要。 スライダー 典型的なフォース MAX MIN MAX MIN MAX MIN 予算 期日 品質 ◆トレードオフスライダー
22. © 2025 NTT DATA Japan Corporation 22 複数のチームで足並みを揃え、開発の進め方/プロセスを規定し、品質管理計画を作りこみ品質確保していくことが重要。 スケールに伴う品質管理 スプリント 設計・結合 実装・単体 スプリント 設計・結合 実装・単体 スプリント 設計・結合 実装・単体 スプリント 設計・結合 実装・単体 スプリント 設計・結合 実装・単体 スプリント システムテスト リリース準備 スプリント システムテスト リリース準備 リ リ ー ス 開発スプリント リリーススプリント ◆エンタープライズ向けアジャイル開発（スクラム） イメージ 開発の進め方 ・開発スプリントでPBI単位に設計〜試験を実施 ・開発スプリントを複数回経て、リリーススプリントで他システム 試験後にリリース 開発プロセス 品質管理計画 ・各工程の作業・プロセスを定義したアクティビティを定義 ・PBIの共通完了条件を定義した「Doneの定義」、機能は 「受入基準」 ・スプリントレビューで「受け入れ基準」、「Doneの定義」を満 たしているかPBI毎に評価 ・リリース対象のインクリメント全体に対して、最低1回品質 評価する イテレーションの枠組みを規定 進め方の 概略 アクティビティ DoD 枠組みを詳細化し、プロセスを定義 評価の プロセス チェックプロセスと評価方法を定義 開発プロセスを明確に定義し、各プロセスに対する管理と評価の方法を設定して実行することが成功へのカギ
23. © 2025 NTT DATA Japan Corporation 23 05 まとめ
24. © 2025 NTT DATA Japan Corporation 24 事例はあくまでも一例です。 まとめ • メンバー全員が背景や目的を理解して、ビジネス目線の開発を行うこと • アジリティ高く対応するための仕組み作りを行っておくこと その暁には、そのプロダクト・プロジェクトの完成形が見えるはずです。 皆さんの事例が聞ける日を楽しみにしています！！
25. © 2025 NTT DATA Japan Corporation
26. © 2025 NTT DATA Japan Corporation 26 私たちの仕事や組織について、および経験者採用について ◆私たちの仕事や組織について、もっと知りたい方 以下のサイトをご覧ください。 NTTデータのモバイル領域における取り組みをご紹介しています。 https://mob.nttdata.com/ ◆経験者採用も継続的に実施中 今回ご紹介した事例に関連する募集ポストは以下をご覧ください。 応募いただく際は、応募媒体欄に「connpass」とご記載ください。 https://nttdata-career.jposting.net/u/job.phtml?job_code=403 ◆キャリア登録は以下から 株式会社NTTデータグループ・株式会社NTTデータ・株式会社NTT DATA, Inc.へ キャリア登録いただく場合は、下記からお願いします。 https://career-user.blm.co.jp/registration/nttdatagroup