Azure DevOps × スクラムで実現するプロダクト開発のポイント #dotnetlab #jazug

Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
Azure DevOps × スクラムで
実現するプロダクト開発のポイント
#jazug
2019/09/07(土)13:30-14:25
グロース・アーキテクチャ＆チームス株式会社
プロダクトオーナー支援スペシャリスト
関満徳

はじめに
2

本日の概要
• Azure DevOps は、
システムの開発と運用を行う上で必要となる
サービスが集約された、
ソフトウェア開発チーム向けの
チーム開発支援プラットフォームです。
• 今回は、Azure DevOps × スクラムで
実現するプロダクト開発のポイントについて
概説します。
3

一番困っていることは何か
• Azure DevOps 上の以下について、
誰が何をどの粒度で書けばよいかわからない
–エピック
–フィーチャー
–ユーザーストーリー
–タスク
4

本日の目標
• Azure DevOps について把握する
• スクラムについて把握する
• プロダクト開発について把握する
• Azure DevOps × スクラムで実現する
プロダクト開発のポイントについて把握する
5

アジェンダ
• Azure DevOpsとは
• スクラムとは
• プロダクト開発とは
• Azure DevOps × スクラムで実現するプロダクト開発
のポイント
• まとめ
6

アジェンダ
のポイント
• まとめ
7

Azure DevOpsとは
8

Azure DevOps とは
• 「Visual Studio Team Services」の後継
–システムの開発と運用を行う上で必要となる
サービスが集約された、
ソフトウェア開発チーム向けの
チーム開発支援プラットフォーム
» チケットやバグ等のタスク管理システム
» ソースコードのバージョン管理システム
» CI/CDツール
» 成果物管理システム
» テスト管理
9出典：Azure DevOpsの概要と使い方 https://news.mynavi.jp/article/zeroazure-25/

Azure DevOpsが提供するサービス
• Azure Boards
– アジャイル開発やスクラムにおけるタスク管理システム
である「カンバン」を提供するサービス
• Azure Repos
– Gitベースのソースコードバージョン管理のためのサービス
• Azure Pipelines
– アプリケーションのビルドやデプロイを自動化するCI/CDサービス
• Azure Artifacts
– 自身で作成したライブラリ、パッケージをチームで共有するための
ホスティングサービス
• Azure Test Plans
– 探索的テストを実行するためのサービス

Azure Boards
• アジャイル開発やスクラムにおけるタスク管理システムである
「カンバン」を提供するサービス

Azure Repos
• Gitベースのソースコードバージョン管理のためのサービス

Azure Pipelines
• アプリケーションのビルドやデプロイを自動化するCI/CDサービス
出典：Azure DevOpsの概要と使い方 https://news.mynavi.jp/article/zeroazure-25/

Azure Artifacts
• 自身で作成したライブラリ、パッケージをチームで共有するための
ホスティングサービス
14出典：Azure Artifacts https://azure.microsoft.com/ja-jp/services/devops/artifacts/

Azure Test Plans
• 探索的テストを実行するためのサービス
15出典：Azure Test Plans https://azure.microsoft.com/ja-jp/services/devops/test-plans/

アジェンダ
のポイント
• まとめ
16

スクラムとは
17

プロダクトオーナーの変遷
• 日本的プロダクトオーナーの現状
18
スクラム
マスター
開発チーム
開発
日本的プロダクトオーナー
経営層
情シス
営業
広報ｺｰﾙｾﾝﾀｰ
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
日本的プロダクトオーナーの苦労の
ポイント
日本的プロダクトオーナーは、スクラ
ムで定義されるプロダクトオーナーより、
より多く、複数の視点の結節点で調整力
を求められる場面が多い。
プロダクトオーナーの現状
プロダクトオーナーは、様々な部
署から任命されることが多く、実
は必要なスキルや経験と案件が
マッチしていないことも多い。
出典：グロース・アーキテクチャ＆チームス株式会社コンサルティング資料より https://www.graat.co.jp/

• スクラムで定義しているプロダクトオーナー
19
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
スクラム
マスター
開発チーム
開発
プロダクト
オーナー

20
プロダクト
Log
仮説スプリント
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
価値検討仕様検討
オポチュニティ
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
ジャーニーマップ
インセプション
デッキ
サービス
ブループリント
アーキテクチャ
設計
アーキテクチャビジョン
& デザイン設計
テクニカル
ソリューション技術
検討
スプリント
レビュー
ToDo Ready In Progress Done Feedback
かんばん
価値計測出荷
プロダクト
利用

2011年頃：スクラムの解釈
21
プロダクト
Log
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
デッキ
サービス
設計
テクニカル
検討
スプリント
レビュー
かんばん
価値計測出荷
プロダクト
利用
プロダクトオーナー
が一人でがんばって
バックログ化を実施

2019年現在：スクラムの解釈
22
プロダクト
Log
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
デッキ
サービス
設計
テクニカル
検討
スプリント
レビュー
かんばん
価値計測出荷
プロダクト
利用
チームが
バックログ化を実施
+
プロダクトオーナー
は方針を意志決定

2011年頃：スクラムの解釈
23
• 主にプロダクションを行う期間
• スプリント期間は２W
• 定期リリースは、１スプリントに１回
• 原則として定期以外リリースはしないが、緊急リリースが必要なタスクが発生した場合は、デイリーミーティングで「差込」として緊急リ
リースを決定する
• この場合スプリントで消化できるポイント数は、計画よりも減る
• バックログの「完成」の定義は、プロダクション品質
スプリント
全フェーズを通して共通のルール
• 1スプリントで開発するストーリーポイントは事前に決めておく
• スプリントの実施内容は、事前に固定しない
• POとDevチームのデイリーミーティングで、タスクの優先順位を、毎日決める
全部スクラムで実施
POCチケット
プロダクションチケット

2019年現在：スクラムの解釈
24
• 主に検証を行う期間
• スプリント期間は１W
• 定期リリースは、1スプリントに3回程度
（デイリーあるいは２日に１回ペース）
• バックログの「完成」の定義は、POC品質
（代替フローやエラー制御、運用系の実装
等は不要）
• フェーズ１でリリース確定したアイテムの
プロダクションと、新たな検証が混在する
期間
• スプリント期間は１W
• 定期リリースは、１スプリントに２回
• 週前半は、POCチケットを実装する
週後半は、プロダクションチケットを実装
する
• バックログの「完成」の定義は、POC品質
とプロダクション品質が混在
• 主にプロダクションを行う期間
• スプリント期間は２W
• 定期リリースは、１スプリントに１回
• 原則として定期以外リリースはしないが、
緊急リリースが必要なタスクが発生した場
合は、デイリーミーティングで「差込」と
して緊急リリースを決定する
• この場合スプリントで消化できるポイント
数は、計画よりも減る
• バックログの「完成」の定義は、プロダク
ション品質
フェーズ１フェーズ２フェーズ３
全フェーズを通して共通のルール
• 1スプリントで開発するストーリーポイントは事前に決めておく
• スプリントの実施内容は、事前に固定しない
• POとDevチームのデイリーミーティングで、タスクの優先順位を、毎日決める
プロダクション品質
のみスクラムで実施
POCチケット
プロダクションチケット

PoCサイクルに適合した開発スタイル：
プロセスイメージ
25
フェーズ１（Month1～３）フェーズ２（Month４～６）フェーズ３（Month７～９）
社内リ
リース
開発チー
ム
PO
企画部門
内ステー
クホル
ダー
月次報告
企画／報告資料作成、修正
Sp
次回デモ範囲決定
報告資料レビュー
随時デモアプリ確認
Sp
日次mtg 日次mtg
Sp Sp
日次mtg 日次mtg
報告実施
Sp Sp Sp Sp
追加要求や変更は日次mtgで開発に伝える
毎日優先順位確認し実施順序決定
日次mtg 日次mtg 日次mtg 日次mtg
報告実施
Sp
日次mtg
Sp
日次mtg
追加要求や変更は日次mtgで開発に伝える追加要求や変更は日次mtgで開発に伝える
原則として実機確認は2週間に1回
プロダクション実機
確認＝スプリントレ
ビュー
POCチケットの確認
は、週1回程度
月次報告のデモは、
時点最新のアプリで
行う
実機確認が必要な差込が発生したら、
臨時リリース

• 日本的プロダクトオーナーの現状
26
スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
日本的プロダクトオーナーの苦労の
ポイント
日本的プロダクトオーナーは、スクラ
ムで定義されるプロダクトオーナーより、
より多く、複数の視点の結節点で調整力
を求められる場面が多い。
プロダクトオーナーの現状
プロダクトオーナーは、様々な部
署から任命されることが多く、実
は必要なスキルや経験と案件が
マッチしていないことも多い。

エンタープライズ企業において求められる
プロダクト責任者の機能
1. 顧客・市場のニーズやフィードバックを
受けること
2. 開発チームにプロダクトの価値を伝え、
開発の優先順位を決定すること
3. 経営への説明責任を果たしたり
組織の意思決定ルールに適応すること
4. サービス提供に伴うオペレーションを担う
部署との調整を行うこと
27出典：日本のユーザー企業でプロダクトマネージャーは活躍できないのか #pmconfjp https://www.graat.co.jp/blogs/cjofl9f91ffpo0993pufzkhlg

エンタープライズ企業において求められる
プロダクト責任者の機能
28
スクラム
マスター
開発チーム
経営層
情シス
営業
現場
作業者管理
部門
法務
財務意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
u
顧客・市場のニーズ
やフィードバックを
受けること
顧客
意思決定者
開発
現場
経営への説明責任を
果たしたり
組織の意思決定ルール
に適応すること
サービス提供に伴う
オペレーションを担う
部署との調整を行うこと
開発チームにプロダ
クトの価値を伝え、
開発の優先順位を
決定すること
出典：日本のユーザー企業でプロダクトマネージャーは活躍できないのか #pmconfjp https://www.graat.co.jp/blogs/cjofl9f91ffpo0993pufzkhlg

スクラムを大規模にして
協働する
29

スクラムを大規模にして協働する
• スクラムを大規模にするとは
–1つのスクラムチームが10名以上になったときに
どうするかを解決していく
–大規模開発のおのおののチームだけにスクラムを
取り入れたものではない
30出典：https://medium.com/i35-267/what-is-less-large-scale-scrum-35f7562b2ba1

–1つのプロダクトを複数チームで協働
» プロダクト
▸ 顧客を中心に据えたソリューションで、実際の顧客が利用するもの
▸ 作業をプロジェクトではなくプロダクトとして管理
» フィーチャーチーム
▸ チームは、クロスファンクショナル、コンポーネント横断でフルスタ
ックのフィーチャーチームで、学びに集中した3～9名で構成
▸ チームは、UX、コード、動画まですべてを扱い、アイテムを完成さ
せ、出荷可能なプロダクトを作成
» 1つのプロダクトを複数チームで協働
▸ 複数チームが、共通の目標である単一の出荷可能なプロダクトを、
共通のスプリントで提供するために、一緒に作業
31出典：大規模スクラム Large-Scale Scrum (LeSS) - スクラムを大規模に実装する方法 P4

–1つのプロダクトを複数チームで協働
32出典：大規模スクラム Large-Scale Scrum (LeSS) - スクラムを大規模に実装する方法 https://less.works/jp/less/framework/index.html

–スクラムマスター＆フィーチャーチームによる協働
» チームは、顧客価値を中心に構成
» コンポーネントチームではない
33出典：大規模スクラム Large-Scale Scrum (LeSS) - スクラムを大規模に実装する方法 https://less.works/jp/less/structure/feature-teams.html

–[参考] フィーチャーチームへの移行
34出典：大規模スクラム Large-Scale Scrum (LeSS) - スクラムを大規模に実装する方法 https://less.works/jp/less/structure/feature-teams.html

• [参考] フィーチャーチーム導入マップ
35出典：大規模スクラム Large-Scale Scrum (LeSS) - スクラムを大規模に実装する方法 https://blog.okamotoyuki.me/2018/07/09/less/
問題
システム全体
プロダクト全体
サブシステム
コンポーネント
システム全体
[縦軸]チーム内の潜在的な技術的作業範囲
コード＋設計と
ユニットテスト
＋サブシステム
とテスト
＋分析と
システムテスト
＋共創
[横軸] チーム内の活動、クロスファンクショナル度
コンポーネント
チーム
フィーチャー
チーム
機能的過度の専門化
拡張されたコンポーネントチームでは、
チームの作業範囲が競合し、重複を生ん
だり、多くの調整が必要となる。
理想の状態
達成するのは難しい

–チームそれぞれが自己管理できている状態を目指す
36出典：大規模スクラム Large-Scale Scrum (LeSS) - スクラムを大規模に実装する方法 https://less.works/jp/less/framework/index.html

–チームそれぞれが自己管理できている状態とは
» 自分たちで考えることを期待されている
» 指示型ではないマネジメントスタイル
37
全体的な方向性を決める
チームの構成と所属組織にお
けるチームの位置づけを決め
る
仕事の手順と進行状況を監督
する
与えられた仕事を淡々とこな
す
マネジャー
主導チーム
自己管理
チーム
自己設計
チーム
自己統治
チーム
この状態を
目指したい
出典：ハーバードで学ぶ「デキるチーム」5つの条件 J・リチャード・ハックマン著生産性出版

38出典：https://less.works/img/management/less-organization.jp.png.pagespeed.ce.92YohmS6dD.png
• 集権的でない
–特定の誰かに権限を集めない
» マネージャーは外に
いてもよいが、
リーダーは中にも
外にも基本不要
» 大事なのはマネジ
メントと
個々のメンバーの
リーダーシップ

アジェンダ
のポイント
• まとめ
39

• プロダクトについてふりかえる
• プロダクト戦略とチームの関係について
ふりかえる
プロダクト開発とは
40

ふりかえる
41

プロダクトについてふりかえる
42出典：経団連 Society 5.0 https://www.keidanren.or.jp/policy/2018/095_gaiyo.pdf

ふりかえる
46

プロダクトをマネジメントする
• 戦略と中期指標の関係を整理し、事業貢献度を可視化
– 戦略マップを活用し、中期指標:OKRをミッション・ビジョンそして戦略と結びつける
» OKRは短期のサイクルを強調していて戦術的であることが強みではあるが、戦略と結びつかない
» ミッション、ビジョン、戦略とOKRを結びつけることで、戦略を全員の仕事へ関連付け可能
47
OKR
（四半期）
OKR
（中期）
戦略マップ
（中期）
ビジョン
（中期）
ミッション
（長期）
ミッション
ビジョン
短期中期長期
財務の視点
顧客の視点
業務プロセスの視点
学習と成長の視点
SO
SO
SO
SO
SO
SO 戦略マップで定義した戦略目的（Strategic Objectives）
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
1.
2.
3.
目標 | Objective
1.
2.
3.
目標 | Objective
1.
2.
3.
目標 | Objective
1.
2.
3.
目標 | Objective
1.
2.
3.
目標 | Objective
1.
2.
3. ※戦略マップで定義した戦略と関連づかない OKR は、必要に応じて定義することもある
出典：<新版>【松原流】戦略マップ/BSCとOKRの連携教本-双方の強みを活かしたビジネスモデル・イノベーション

組織のミッション、プロダクトのビジョン、
プロダクトの戦略マップを整備
• 組織のミッション：ご参考
49出典：メルカリ会社案内より - https://about.mercari.com/about/

マイクロサービスアーキテクチャの観点で、
肥大化しがちなプロダクトを分割
• システム全体を「サービス単位」で変更
–サービスのリリース/切り戻しは自動化され無停止で
実施可能
» チームをまたがる影響調査やリリース調整は不要
–マイクロサービス＝アジャイル＋DevOps/NoOps
» 目的：システム全体の変更速度を上げる
51
利用
企画
実装
運用
出典：鈴木雄介マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018 https://www.slideshare.net/yusuke/awsdevday-tokyo-2018

• マイクロサービス化の導入ステップ
–段階を経て進めていく
–Step1：最初のサービスを分割する
» Monolithicからサービスを切り出していく
–Step2：サービス基盤を整備する
» サービスを増やしていくための基盤を整備する
–Step3：サービスを管理する
» 数が多くなってきたサービスそのものの管理を自動化して
いく
52出典：鈴木雄介マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018 https://www.slideshare.net/yusuke/awsdevday-tokyo-2018

• アーキテクチャの設計と評価
53
アーキテクチャ設計
1 . ビジネス要件を理解するビジネス
要件
その他の
利害関係者
構成案図3 . 構成を検討する
評価シート4 . 構成を評価する
アーキテクチャ方針書
ビジネス要件
サマリ
アクター一覧
ユースケース図
非機能要件定義2 . 非機能要件を定義する
レビュー ①
レビュー ②
出典：鈴木雄介アーキテクチャのレビューについて - JaSST Review '18 https://www.slideshare.net/yusuke/jasst-review-18

• 戦略と戦術の統合
55出典：【松原流】戦略マップ/BSCとOKRの連携教本-双方の強みを活かしたビジネスモデル・イノベーション- より

• 戦略と戦術の統合
56出典：【松原流】戦略マップ/BSCとOKRの連携教本-双方の強みを活かしたビジネスモデル・イノベーション- より

• 短中長期のプロダクト目標を数値で設定し共有
– OKR (Objectives and Key Results) 目標と重要な結果の略称
OKR の定義について
1. [Niven, 2016]
▸ クリティカル・シンキングのフレームワーク
▸ 従業員が共同して働き、会社を前進させるもとになる、
測定可能な努力に集中することを可能にする継続的な活動
2. [Doerr, 2018]
▸ 非常に高いゴールを設定し、コミュニケートし、測定し、
達成するためのプロセス
▸ 求めたアウトカム（Objective）と、アウトカムの達成に必要な
測定可能なステップ（Key Results）に分解
» Os は2～5件、KRs は、個々の O に対して、2～5件設定するの
が望ましい
58出典：<新版>【松原流】戦略マップ/BSCとOKRの連携教本-双方の強みを活かしたビジネスモデル・イノベーション- P6-P8より抜粋

• 中期戦略に応じた OKR 設定例
– [YouTube, 2012]
» 4年がかりのOKRとして継続実施するいくつかの年次目標を、
中長期のOKRのObjective に設定
» 社員が実現可能だと思える四半期ごとの目標を、Key Result に設定
» 設定した目標は、小刻みに改善していく
※ 参考）OKR の表記について
▸ 英文の表記は OKRs だが、和文の文献の多くが OKR と単数形で表記している点
に注意
▸ OKR の2つの構成要素である Objectives および Key Results の英文の表記は、
Os および KRs
59
目標 | Objective
以下を成長の推進力として、（2016年末までに）1日当たりの総視聴時間10億時間を達成する
1. 検索チームとメインアプリ（+XX%）、リビングルーム（+XX%）
2. エンゲージメントと、ながら視聴を増やす（1日当たり総視聴をX時間にする）
3. 「YouTube VR エクスペリエンス」を開始し、VRカタログの動画本数をXからYに増やす
出典：Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR (メジャー・ホワット・マターズ) P236-238より抜粋

• プロダクトオーナーからみた中期指標策定および四半期指標策定の進め方
– STEP1 :中期指標OKRのインプットを確認
» ミッション、ビジョン、戦略を確認する（事業目標、プロダクト達成指標など）
▸ ミッション、ビジョンは、会社のIR情報や経営目標、事業部目標や部門目標などから確認
▸ 特に戦略については、戦略マップの4要素である「財務、顧客、業務プロセス、学習と成長」の視点から、
それぞれ確認することが重要
– STEP2 : 中期戦略に応じた中期指標OKRを策定
» X年がかりの OKR として継続実施するいくつかの年次目標を、Objective に設定
▸ Osは、戦略に応じて複数設定する
▸ 戦略に対応しない OKR を設定する場合は、妥当性（説明可能な状態）を担保する
» 小刻みに改善していく、社員が実現可能だと思える四半期ごとの目標を、Key Result に設定
▸ それぞれの O に対して、複数の KRs を作成する
– STEP3 : 四半期に応じたOKRを策定
» チームにとって、四半期で実行・管理・事業価値提供が可能な目標を、Objective に設定
▸ Osは、中期戦略に応じて複数設定し、関連付ける
» メンバーによるオーナーシップが発揮可能な、定量的な結果の目標を、Key Result に設定
▸ それぞれの O に対して、複数の KRs を作成する
» メンバー主導で成果を出すためには、トップダウンに加えて、ボトムアップで作成することが
重要
61出典：グロース・アーキテクチャ＆チームス株式会社コンサルティング資料より

プロダクトの価値とは
• XM（Experience Management）から見た
プロダクトの価値
–最近では
62XM（Experience Management）とは - https://marketing.itmedia.co.jp/mm/articles/1907/18/news028.html

アジェンダ
• Azure DevOps × スクラムで実現するプロダクト開
発のポイント
• まとめ
64

Azure DevOps × スクラムで
実現するプロダクト開発のポイ
ント
65

–エピック
–タスク
66

Azure DevOps 上の構造
67
出典：Agile process work item types and workflow https://docs.microsoft.com/en-us/azure/devops/boards/work-items/guidance/agile-process-workflow?view=azure-devops

ポイント - 決めておきたいこと
68
粒度何をどこまで書くか誰が書くか
AsIs ToBe AsIs ToBe AsIs ToBe
エピック
フィーチャー
ユーザー
ストーリー
タスク

参考）BtoB向けプロダクトの場合
69
エピック
• おおよそ年間計画単位で
実現するOKR
• 実現したい価値を記載する。他部署
の方が読んでもわかるよう記載
• 例「～のために～が～をできるよう
にする」
企画チーム
フィーチャー
• リリースとしてOKと
意思決定可能な最小単位
• MustとWantは分離
• シナリオテストレベルで
受入条件を明記
• 実現したい機能を他部署の方が
読んでもわかるよう記載
• 例「～が～をできる」
企画チーム
DevOpsチーム
ユーザー
ストーリー
• 1スプリントに収まる粒度
• 機能テストレベルで
• 「（誰）が（何）を（どうする）」
• Descriptionに理由（なぜならば～
だから）を記載
企画チーム
DevOpsチーム
タスク
• 一作業単位
• 一日単位(6H)
• 例「設計書作成」
• 「実装」⇒実装の大きさ、日数で
タスクを分割
• 「テスト計画書作成」
• 「CI動作確認」
DevOpsチーム

70
エピック
実現するOKR
にする」
企画チーム
フィーチャー
企画チーム
DevOpsチーム
ユーザー
ストーリー
企画チーム
DevOpsチーム
タスク
• 一作業単位
タスクを分割
DevOpsチーム

71
エピック
実現するOKR
にする」
企画チーム
フィーチャー
企画チーム
DevOpsチーム
ユーザー
ストーリー
企画チーム
DevOpsチーム
タスク
• 一作業単位
タスクを分割
DevOpsチーム

72
エピック
実現するOKR
にする」
企画チーム
フィーチャー
企画チーム
DevOpsチーム
ユーザー
ストーリー
企画チーム
DevOpsチーム
タスク
• 一作業単位
タスクを分割
DevOpsチーム

73
エピック
実現するOKR
にする」
企画チーム
フィーチャー
企画チーム
DevOpsチーム
ユーザー
ストーリー
企画チーム
DevOpsチーム
タスク
• 一作業単位
タスクを分割
DevOpsチーム

74
エピック
実現するOKR
にする」
企画チーム
フィーチャー
企画チーム
DevOpsチーム
ユーザー
ストーリー
企画チーム
DevOpsチーム
タスク
• 一作業単位
タスクを分割
DevOpsチーム

アジェンダ
のポイント
• まとめ
75

本日の概要
• Azure DevOpsは、ソフトウェア開発チームの
ための、システムの開発と運用を行う上で必要
となるサービスが集約された、チーム開発支援
のためのプラットフォームです。
• 今回は、Azure DevOps × スクラムで実現す
るプロダクト開発のポイントについて概説しま
す。
76

本日の目標
• Azure DevOps について把握する
• スクラムについて把握する
• プロダクト開発について把握する
• Azure DevOps × スクラムで実現する
プロダクト開発のポイントについて把握する
77

–エピック
–タスク
78

本日お話したこと
のポイント
• まとめ
79

ご清聴ありがとうございました！
81
コンタクト先 URL
Blog http://fullvirtue.com/
Twitter https://twitter.com/fullvirtue
Facebook https://www.facebook.com/fullvirtue
Email m.seki@graat.co.jp
資料公開場所 http://slideshare.net/fullvirtue/
これまで登壇してきた資料はこちらで公開しています！
是非ご覧ください！
関満徳
せきみつのり
グロース・アーキテクチャ＆チームス株式会社
プロダクトオーナー支援スペシャリスト
プロダクトマネージャー・カンファレンス実行委員
ITサービス開発全般のコンサルティング、開発、運用を一括して
手掛けながら、「顧客価値の創造」と「持続可能な仕組み創り」を
テーマとしたアジャイル・プロダクトマネジメントのバックログ
作成・見積ワークショップデザインを数多く実施。全国各地で
ファシリテーターとしても活躍。

Azure DevOps × スクラムで実現するプロダクト開発のポイント #dotnetlab #jazug

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Azure DevOps × スクラムで実現するプロダクト開発のポイント #dotnetlab #jazug

Similar to Azure DevOps × スクラムで実現するプロダクト開発のポイント #dotnetlab #jazug (20)

More from 満徳関

More from 満徳関 (20)