Mais conteúdo relacionado
Semelhante a Azure DevOps × スクラム で実現するプロダクト開発のポイント #dotnetlab #jazug (20)
Azure DevOps × スクラム で実現するプロダクト開発のポイント #dotnetlab #jazug
- 1. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
Azure DevOps × スクラム で
実現するプロダクト開発のポイント
#jazug
2019/09/07(土)13:30-14:25
グロース・アーキテクチャ&チームス株式会社
プロダクトオーナー支援スペシャリスト
関 満徳
- 2. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved. 1出典:Web担編集部 https://webtan.impress.co.jp/e/2019/08/28/33686
- 4. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
本日の概要
• Azure DevOps は、
システムの開発と運用を行う上で必要となる
サービスが集約された、
ソフトウェア開発チーム向けの
チーム開発支援プラットフォームです。
• 今回は、Azure DevOps × スクラム で
実現するプロダクト開発のポイントについて
概説します。
3
- 5. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
一番困っていることは何か
• Azure DevOps 上の以下について、
誰が 何を どの粒度 で書けばよいかわからない
–エピック
–フィーチャー
–ユーザーストーリー
–タスク
4
- 6. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
本日の目標
• Azure DevOps について把握する
• スクラム について把握する
• プロダクト開発 について把握する
• Azure DevOps × スクラム で実現する
プロダクト開発のポイント について把握する
5
- 7. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
アジェンダ
• Azure DevOpsとは
• スクラムとは
• プロダクト開発とは
• Azure DevOps × スクラムで実現するプロダクト開発
のポイント
• まとめ
6
- 8. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
アジェンダ
• Azure DevOpsとは
• スクラムとは
• プロダクト開発とは
• Azure DevOps × スクラムで実現するプロダクト開発
のポイント
• まとめ
7
- 10. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
Azure DevOps とは
• 「Visual Studio Team Services」の後継
–システムの開発と運用を行う上で必要となる
サービスが集約された、
ソフトウェア開発チーム向けの
チーム開発支援プラットフォーム
» チケットやバグ等のタスク管理システム
» ソースコードのバージョン管理システム
» CI/CDツール
» 成果物管理システム
» テスト管理
9出典:Azure DevOpsの概要と使い方 https://news.mynavi.jp/article/zeroazure-25/
- 11. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
Azure DevOpsが提供するサービス
• Azure Boards
– アジャイル開発やスクラムにおけるタスク管理システム
である「カンバン」を提供するサービス
• Azure Repos
– Gitベースのソースコードバージョン管理のためのサービス
• Azure Pipelines
– アプリケーションのビルドやデプロイを自動化するCI/CDサービス
• Azure Artifacts
– 自身で作成したライブラリ、パッケージをチームで共有するための
ホスティングサービス
• Azure Test Plans
– 探索的テストを実行するためのサービス
10出典:Azure DevOpsの概要と使い方 https://news.mynavi.jp/article/zeroazure-25/
- 12. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
Azure Boards
• アジャイル開発やスクラムにおけるタスク管理システムである
「カンバン」を提供するサービス
11出典:Azure DevOpsの概要と使い方 https://news.mynavi.jp/article/zeroazure-25/
- 13. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
Azure Repos
• Gitベースのソースコードバージョン管理のためのサービス
12出典:Azure DevOpsの概要と使い方 https://news.mynavi.jp/article/zeroazure-25/
- 14. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
Azure Pipelines
• アプリケーションのビルドやデプロイを自動化するCI/CDサービス
出典:Azure DevOpsの概要と使い方 https://news.mynavi.jp/article/zeroazure-25/
- 15. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
Azure Artifacts
• 自身で作成したライブラリ、パッケージをチームで共有するための
ホスティングサービス
14出典:Azure Artifacts https://azure.microsoft.com/ja-jp/services/devops/artifacts/
- 16. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
Azure Test Plans
• 探索的テストを実行するためのサービス
15出典:Azure Test Plans https://azure.microsoft.com/ja-jp/services/devops/test-plans/
- 17. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
アジェンダ
• Azure DevOpsとは
• スクラムとは
• プロダクト開発とは
• Azure DevOps × スクラムで実現するプロダクト開発
のポイント
• まとめ
16
- 19. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
プロダクトオーナーの変遷
• 日本的プロダクトオーナーの現状
18
スクラム
マスター
開発チーム
開発
日本的プロダクトオーナー
経営層
情シス
営業
広報コールセンター
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
日本的プロダクトオーナーの苦労の
ポイント
日本的プロダクトオーナーは、 スクラ
ムで定義されるプロダクトオーナーより、
より多く、複数の視点の結節点で調整力
を求められる場面が多い。
プロダクトオーナーの現状
プロダクトオーナーは、様々な部
署から任命されることが多く、実
は必要なスキルや経験と案件が
マッチしていないことも多い。
出典:グロース・アーキテクチャ&チームス株式会社 コンサルティング資料より https://www.graat.co.jp/
- 20. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
プロダクトオーナーの変遷
• スクラムで定義しているプロダクトオーナー
19
経営層
情シス
営業
広報コールセンター
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
スクラム
マスター
開発チーム
開発
プロダクト
オーナー
出典:グロース・アーキテクチャ&チームス株式会社 コンサルティング資料より https://www.graat.co.jp/
- 21. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
プロダクトオーナーの変遷
20
プロダクト
Log
仮説 スプリント
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
価値検討 仕様検討
オポチュニティ
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
ジャーニーマップ
インセプション
デッキ
サービス
ブループリント
アーキテクチャ
設計
アーキテクチャビジョン
& デザイン設計
テクニカル
ソリューション技術
検討
スプリント
レビュー
ToDo Ready In Progress Done Feedback
かんばん
価値計測 出荷
プロダクト
利用
- 22. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
2011年頃:スクラムの解釈
21
プロダクト
Log
仮説 スプリント
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
価値検討 仕様検討
オポチュニティ
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
ジャーニーマップ
インセプション
デッキ
サービス
ブループリント
アーキテクチャ
設計
アーキテクチャビジョン
& デザイン設計
テクニカル
ソリューション技術
検討
スプリント
レビュー
ToDo Ready In Progress Done Feedback
かんばん
価値計測 出荷
プロダクト
利用
プロダクトオーナー
が一人でがんばって
バックログ化を実施
- 23. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
2019年現在:スクラムの解釈
22
プロダクト
Log
仮説 スプリント
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
価値検討 仕様検討
オポチュニティ
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
ジャーニーマップ
インセプション
デッキ
サービス
ブループリント
アーキテクチャ
設計
アーキテクチャビジョン
& デザイン設計
テクニカル
ソリューション技術
検討
スプリント
レビュー
ToDo Ready In Progress Done Feedback
かんばん
価値計測 出荷
プロダクト
利用
チームが
バックログ化を実施
+
プロダクトオーナー
は方針を意志決定
- 24. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
2011年頃:スクラムの解釈
23
• 主にプロダクションを行う期間
• スプリント期間は2W
• 定期リリースは、1スプリントに1回
• 原則として定期以外リリースはしないが、緊急リリースが必要なタスクが発生した場合は、デイリーミーティングで「差込」として緊急リ
リースを決定する
• この場合スプリントで消化できるポイント数は、計画よりも減る
• バックログの「完成」の定義は、プロダクション品質
スプリント
全フェーズを通して共通のルール
• 1スプリントで開発するストーリーポイントは事前に決めておく
• スプリントの実施内容は、事前に固定しない
• POとDevチームのデイリーミーティングで、タスクの優先順位を、毎日決める
全部スクラムで実施
POCチケット
プロダクションチケット
出典:グロース・アーキテクチャ&チームス株式会社 コンサルティング資料より https://www.graat.co.jp/
- 25. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
2019年現在:スクラムの解釈
24
• 主に検証を行う期間
• スプリント期間は1W
• 定期リリースは、1スプリントに3回程度
(デイリーあるいは2日に1回ペース)
• バックログの「完成」の定義は、POC品質
(代替フローやエラー制御、運用系の実装
等は不要)
• フェーズ1でリリース確定したアイテムの
プロダクションと、新たな検証が混在する
期間
• スプリント期間は1W
• 定期リリースは、1スプリントに2回
• 週前半は、POCチケットを実装する
週後半は、プロダクションチケットを実装
する
• バックログの「完成」の定義は、POC品質
とプロダクション品質が混在
• 主にプロダクションを行う期間
• スプリント期間は2W
• 定期リリースは、1スプリントに1回
• 原則として定期以外リリースはしないが、
緊急リリースが必要なタスクが発生した場
合は、デイリーミーティングで「差込」と
して緊急リリースを決定する
• この場合スプリントで消化できるポイント
数は、計画よりも減る
• バックログの「完成」の定義は、プロダク
ション品質
フェーズ1 フェーズ2 フェーズ3
全フェーズを通して共通のルール
• 1スプリントで開発するストーリーポイントは事前に決めておく
• スプリントの実施内容は、事前に固定しない
• POとDevチームのデイリーミーティングで、タスクの優先順位を、毎日決める
プロダクション品質
のみスクラムで実施
POCチケット
プロダクションチケット
出典:グロース・アーキテクチャ&チームス株式会社 コンサルティング資料より https://www.graat.co.jp/
- 26. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
PoCサイクルに適合した開発スタイル:
プロセスイメージ
25
フェーズ1(Month1~3) フェーズ2(Month4~6) フェーズ3(Month7~9)
社内リ
リース
開発チー
ム
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回程度
月次報告のデモは、
時点最新のアプリで
行う
毎日優先順位確認し実施順序決定
実機確認が必要な差込が発生したら、
臨時リリース
毎日優先順位確認し実施順序決定
出典:グロース・アーキテクチャ&チームス株式会社 コンサルティング資料より https://www.graat.co.jp/
- 27. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
プロダクトオーナーの変遷
• 日本的プロダクトオーナーの現状
26
スクラム
マスター
開発チーム
開発
日本的プロダクトオーナー
経営層
情シス
営業
広報コールセンター
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
日本的プロダクトオーナーの苦労の
ポイント
日本的プロダクトオーナーは、 スクラ
ムで定義されるプロダクトオーナーより、
より多く、複数の視点の結節点で調整力
を求められる場面が多い。
プロダクトオーナーの現状
プロダクトオーナーは、様々な部
署から任命されることが多く、実
は必要なスキルや経験と案件が
マッチしていないことも多い。
出典:グロース・アーキテクチャ&チームス株式会社 コンサルティング資料より https://www.graat.co.jp/
- 28. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
エンタープライズ企業において求められる
プロダクト責任者の機能
1. 顧客・市場のニーズやフィードバックを
受けること
2. 開発チームにプロダクトの価値を伝え、
開発の優先順位を決定すること
3. 経営への説明責任を果たしたり
組織の意思決定ルールに適応すること
4. サービス提供に伴うオペレーションを担う
部署との調整を行うこと
27出典: 日本のユーザー企業でプロダクトマネージャーは活躍できないのか #pmconfjp https://www.graat.co.jp/blogs/cjofl9f91ffpo0993pufzkhlg
- 29. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
エンタープライズ企業において求められる
プロダクト責任者の機能
28
スクラム
マスター
開発チーム
日本的プロダクトオーナー
経営層
情シス
営業
広報コールセンター
現場
作業者管理
部門
法務
財務 意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
u
顧客・市場のニーズ
やフィードバックを
受けること
顧客
意思決定者
開発
現場
経営への説明責任を
果たしたり
組織の意思決定ルール
に適応すること
サービス提供に伴う
オペレーションを担う
部署との調整を行うこと
開発チームにプロダ
クトの価値を伝え、
開発の優先順位を
決定すること
出典: 日本のユーザー企業でプロダクトマネージャーは活躍できないのか #pmconfjp https://www.graat.co.jp/blogs/cjofl9f91ffpo0993pufzkhlg
- 31. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
スクラムを大規模にして協働する
• スクラムを大規模にするとは
–1つのスクラムチームが10名以上になったときに
どうするかを解決していく
–大規模開発のおのおののチームだけにスクラムを
取り入れたものではない
30出典:https://medium.com/i35-267/what-is-less-large-scale-scrum-35f7562b2ba1
- 32. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
スクラムを大規模にして協働する
• スクラムを大規模にするとは
–1つのプロダクトを複数チームで協働
» プロダクト
▸ 顧客を中心に据えたソリューションで、実際の顧客が利用するもの
▸ 作業をプロジェクトではなくプロダクトとして管理
» フィーチャーチーム
▸ チームは、クロスファンクショナル、コンポーネント横断でフルスタ
ックのフィーチャーチームで、学びに集中した3~9名で構成
▸ チームは、UX、コード、動画まですべてを扱い、アイテムを完成さ
せ、出荷可能なプロダクトを作成
» 1つのプロダクトを複数チームで協働
▸ 複数チームが、共通の目標である単一の出荷可能なプロダクトを、
共通のスプリントで提供するために、一緒に作業
31出典:大規模スクラム Large-Scale Scrum (LeSS) - スクラムを大規模に実装する方法 P4
- 33. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
スクラムを大規模にして協働する
• スクラムを大規模にするとは
–1つのプロダクトを複数チームで協働
32出典:大規模スクラム Large-Scale Scrum (LeSS) - スクラムを大規模に実装する方法 https://less.works/jp/less/framework/index.html
- 34. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
スクラムを大規模にして協働する
–スクラムマスター&フィーチャーチームによる協働
» チームは、顧客価値を中心に構成
» コンポーネントチームではない
33出典:大規模スクラム Large-Scale Scrum (LeSS) - スクラムを大規模に実装する方法 https://less.works/jp/less/structure/feature-teams.html
- 35. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
スクラムを大規模にして協働する
–[参考] フィーチャーチームへの移行
34出典:大規模スクラム Large-Scale Scrum (LeSS) - スクラムを大規模に実装する方法 https://less.works/jp/less/structure/feature-teams.html
- 36. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
スクラムを大規模にして協働する
• [参考] フィーチャーチーム導入マップ
35出典:大規模スクラム Large-Scale Scrum (LeSS) - スクラムを大規模に実装する方法 https://blog.okamotoyuki.me/2018/07/09/less/
問題
システム全体
プロダクト全体
サブシステム
コンポーネント
システム全体
[縦軸]チーム内の潜在的な技術的作業範囲
コード +設計と
ユニットテスト
+サブシステム
アーキテクチャ
とテスト
+分析と
システムテスト
+共創
[横軸] チーム内の活動、クロスファンクショナル度
コンポーネント
チーム
フィーチャー
チーム
機能的過度の専門化
拡張されたコンポーネントチームでは、
チームの作業範囲が競合し、重複を生ん
だり、多くの調整が必要となる。
理想の状態
達成するのは難しい
- 37. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
スクラムを大規模にして協働する
• スクラムを大規模にするとは
–チームそれぞれが自己管理できている状態を目指す
36出典:大規模スクラム Large-Scale Scrum (LeSS) - スクラムを大規模に実装する方法 https://less.works/jp/less/framework/index.html
- 38. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
スクラムを大規模にして協働する
–チームそれぞれが自己管理できている状態とは
» 自分たちで考えることを期待されている
» 指示型ではないマネジメントスタイル
37
全体的な方向性を決める
チームの構成と所属組織にお
けるチームの位置づけを決め
る
仕事の手順と進行状況を監督
する
与えられた仕事を淡々とこな
す
マネジャー
主導チーム
自己管理
チーム
自己設計
チーム
自己統治
チーム
この状態を
目指したい
出典:ハーバードで学ぶ「デキるチーム」5つの条件 J・リチャード・ハックマン著 生産性出版
- 39. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
スクラムを大規模にして協働する
38出典:https://less.works/img/management/less-organization.jp.png.pagespeed.ce.92YohmS6dD.png
• 集権的でない
–特定の誰かに権限を集めない
» マネージャーは外に
いてもよいが、
リーダーは中にも
外にも基本不要
» 大事なのはマネジ
メントと
個々のメンバーの
リーダーシップ
- 40. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
アジェンダ
• Azure DevOpsとは
• スクラムとは
• プロダクト開発とは
• Azure DevOps × スクラムで実現するプロダクト開発
のポイント
• まとめ
39
- 41. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
• プロダクトについてふりかえる
• プロダクト戦略とチームの関係について
ふりかえる
プロダクト開発とは
40
- 42. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
• プロダクトについてふりかえる
• プロダクト戦略とチームの関係について
ふりかえる
プロダクト開発とは
41
- 43. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
プロダクトについてふりかえる
42出典:経団連 Society 5.0 https://www.keidanren.or.jp/policy/2018/095_gaiyo.pdf
- 44. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
プロダクトについてふりかえる
43出典:経団連 Society 5.0 https://www.keidanren.or.jp/policy/2018/095_gaiyo.pdf
- 45. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
プロダクトについてふりかえる
44出典:経団連 Society 5.0 https://www.keidanren.or.jp/policy/2018/095_gaiyo.pdf
- 46. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
プロダクトについてふりかえる
45出典:経団連 Society 5.0 https://www.keidanren.or.jp/policy/2018/095_gaiyo.pdf
- 47. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
• プロダクトについてふりかえる
• プロダクト戦略とチームの関係について
ふりかえる
プロダクト開発とは
46
- 48. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
プロダクトをマネジメントする
• 戦略と中期指標の関係を整理し、事業貢献度を可視化
– 戦略マップを活用し、中期指標:OKRをミッション・ビジョンそして戦略と結びつける
» OKRは短期のサイクルを強調していて戦術的であることが強みではあるが、戦略と結びつかない
» ミッション、ビジョン、戦略とOKRを結びつけることで、戦略を全員の仕事へ関連付け可能
47
OKR
(四半期)
OKR
(中期)
戦略マップ
(中期)
ビジョン
(中期)
ミッション
(長期)
ミッション
ビジョン
短期 中期 長期
財務の視点
顧客の視点
業務プロセスの視点
学習と成長の視点
SO
SO
SO
SO
SO
SO 戦略マップで定義した戦略目的(Strategic Objectives)
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3. ※戦略マップで定義した戦略と関連づかない OKR は、必要に応じて定義することもある
出典:<新版>【松原流】戦略マップ/BSCとOKRの連携教本-双方の強みを活かしたビジネスモデル・イノベーション
- 49. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
プロダクトをマネジメントする
• 戦略と中期指標の関係を整理し、事業貢献度を可視化
– 戦略マップを活用し、中期指標:OKRをミッション・ビジョンそして戦略と結びつける
» OKRは短期のサイクルを強調していて戦術的であることが強みではあるが、戦略と結びつかない
» ミッション、ビジョン、戦略とOKRを結びつけることで、戦略を全員の仕事へ関連付け可能
48
OKR
(四半期)
OKR
(中期)
戦略マップ
(中期)
ビジョン
(中期)
ミッション
(長期)
ミッション
ビジョン
短期 中期 長期
財務の視点
顧客の視点
業務プロセスの視点
学習と成長の視点
SO
SO
SO
SO
SO
SO 戦略マップで定義した戦略目的(Strategic Objectives)
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3. ※戦略マップで定義した戦略と関連づかない OKR は、必要に応じて定義することもある
出典:<新版>【松原流】戦略マップ/BSCとOKRの連携教本-双方の強みを活かしたビジネスモデル・イノベーション
- 50. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
組織のミッション、プロダクトのビジョン、
プロダクトの戦略マップを整備
• 組織のミッション:ご参考
49出典:メルカリ 会社案内より - https://about.mercari.com/about/
- 51. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
プロダクトをマネジメントする
• 戦略と中期指標の関係を整理し、事業貢献度を可視化
– 戦略マップを活用し、中期指標:OKRをミッション・ビジョンそして戦略と結びつける
» OKRは短期のサイクルを強調していて戦術的であることが強みではあるが、戦略と結びつかない
» ミッション、ビジョン、戦略とOKRを結びつけることで、戦略を全員の仕事へ関連付け可能
50
OKR
(四半期)
OKR
(中期)
戦略マップ
(中期)
ビジョン
(中期)
ミッション
(長期)
ミッション
ビジョン
短期 中期 長期
財務の視点
顧客の視点
業務プロセスの視点
学習と成長の視点
SO
SO
SO
SO
SO
SO 戦略マップで定義した戦略目的(Strategic Objectives)
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3. ※戦略マップで定義した戦略と関連づかない OKR は、必要に応じて定義することもある
出典:<新版>【松原流】戦略マップ/BSCとOKRの連携教本-双方の強みを活かしたビジネスモデル・イノベーション
- 52. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
マイクロサービスアーキテクチャの観点で、
肥大化しがちなプロダクトを分割
• システム全体を「サービス単位」で変更
–サービスのリリース/切り戻しは自動化され無停止で
実施可能
» チームをまたがる影響調査やリリース調整は不要
–マイクロサービス=アジャイル+DevOps/NoOps
» 目的:システム全体の変更速度を上げる
51
利用
企画
実装
運用
出典:鈴木雄介 マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018 https://www.slideshare.net/yusuke/awsdevday-tokyo-2018
- 53. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
マイクロサービスアーキテクチャの観点で、
肥大化しがちなプロダクトを分割
• マイクロサービス化の導入ステップ
–段階を経て進めていく
–Step1:最初のサービスを分割する
» Monolithicからサービスを切り出していく
–Step2:サービス基盤を整備する
» サービスを増やしていくための基盤を整備する
–Step3:サービスを管理する
» 数が多くなってきたサービスそのものの管理を自動化して
いく
52出典:鈴木雄介 マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018 https://www.slideshare.net/yusuke/awsdevday-tokyo-2018
- 54. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
マイクロサービスアーキテクチャの観点で、
肥大化しがちなプロダクトを分割
• アーキテクチャの設計と評価
53
ア ー キ テ ク チ ャ 設 計
1 . ビジ ネ ス要 件 を理 解 す るビ ジ ネ ス
要件
そ の 他 の
利害関係者
構成案図3 . 構成を検討する
評価シー ト4 . 構成を評価する
ア ー キ テ ク チ ャ 方 針 書
ビジ ネ ス要 件
サ マ リ
ア ク タ ー 一 覧
ユ ー ス ケ ー ス 図
非機能要件定義2 . 非機能要件を定義する
レ ビ ュ ー ①
レ ビ ュ ー ②
出典:鈴木雄介 アーキテクチャのレビューについて - JaSST Review '18 https://www.slideshare.net/yusuke/jasst-review-18
- 55. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
プロダクトをマネジメントする
• 戦略と中期指標の関係を整理し、事業貢献度を可視化
– 戦略マップを活用し、中期指標:OKRをミッション・ビジョンそして戦略と結びつける
» OKRは短期のサイクルを強調していて戦術的であることが強みではあるが、戦略と結びつかない
» ミッション、ビジョン、戦略とOKRを結びつけることで、戦略を全員の仕事へ関連付け可能
54
OKR
(四半期)
OKR
(中期)
戦略マップ
(中期)
ビジョン
(中期)
ミッション
(長期)
ミッション
ビジョン
短期 中期 長期
財務の視点
顧客の視点
業務プロセスの視点
学習と成長の視点
SO
SO
SO
SO
SO
SO 戦略マップで定義した戦略目的(Strategic Objectives)
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3. ※戦略マップで定義した戦略と関連づかない OKR は、必要に応じて定義することもある
出典:<新版>【松原流】戦略マップ/BSCとOKRの連携教本-双方の強みを活かしたビジネスモデル・イノベーション
- 56. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
組織のミッション、プロダクトのビジョン、
プロダクトの戦略マップを整備
• 戦略と戦術の統合
55出典:【松原流】戦略マップ/BSCとOKRの連携教本-双方の強みを活かしたビジネスモデル・イノベーション- より
- 57. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
組織のミッション、プロダクトのビジョン、
プロダクトの戦略マップを整備
• 戦略と戦術の統合
56出典:【松原流】戦略マップ/BSCとOKRの連携教本-双方の強みを活かしたビジネスモデル・イノベーション- より
- 58. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
プロダクトをマネジメントする
• 戦略と中期指標の関係を整理し、事業貢献度を可視化
– 戦略マップを活用し、中期指標:OKRをミッション・ビジョンそして戦略と結びつける
» OKRは短期のサイクルを強調していて戦術的であることが強みではあるが、戦略と結びつかない
» ミッション、ビジョン、戦略とOKRを結びつけることで、戦略を全員の仕事へ関連付け可能
57
OKR
(四半期)
OKR
(中期)
戦略マップ
(中期)
ビジョン
(中期)
ミッション
(長期)
ミッション
ビジョン
短期 中期 長期
財務の視点
顧客の視点
業務プロセスの視点
学習と成長の視点
SO
SO
SO
SO
SO
SO 戦略マップで定義した戦略目的(Strategic Objectives)
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3. ※戦略マップで定義した戦略と関連づかない OKR は、必要に応じて定義することもある
出典:<新版>【松原流】戦略マップ/BSCとOKRの連携教本-双方の強みを活かしたビジネスモデル・イノベーション
- 59. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
プロダクトをマネジメントする
• 短中長期のプロダクト目標を数値で設定し共有
– 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より抜粋
- 60. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
プロダクトをマネジメントする
• 中期戦略に応じた OKR 設定例
– [YouTube, 2012]
» 4年がかりのOKRとして継続実施するいくつかの年次目標を、
中長期のOKRのObjective に設定
» 社員が実現可能だと思える四半期ごとの目標を、Key Result に設定
» 設定した目標は、小刻みに改善していく
※ 参考)OKR の表記について
▸ 英文の表記は OKRs だが、和文の文献の多くが OKR と単数形で表記している点
に注意
▸ OKR の2つの構成要素である Objectives および Key Results の英文の表記は、
Os および KRs
59
目標 | Objective
以下を成長の推進力として、(2016年末までに)1日当たりの総視聴時間10億時間を達成する
主要な結果 | Key Results
1. 検索チームとメインアプリ(+XX%)、リビングルーム(+XX%)
2. エンゲージメントと、ながら視聴を増やす(1日当たり総視聴をX時間にする)
3. 「YouTube VR エクスペリエンス」を開始し、VRカタログの動画本数をXからYに増やす
出典:Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR (メジャー・ホワット・マターズ) P236-238より抜粋
- 61. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
プロダクトをマネジメントする
• 戦略と中期指標の関係を整理し、事業貢献度を可視化
– 戦略マップを活用し、中期指標:OKRをミッション・ビジョンそして戦略と結びつける
» OKRは短期のサイクルを強調していて戦術的であることが強みではあるが、戦略と結びつかない
» ミッション、ビジョン、戦略とOKRを結びつけることで、戦略を全員の仕事へ関連付け可能
60
OKR
(四半期)
OKR
(中期)
戦略マップ
(中期)
ビジョン
(中期)
ミッション
(長期)
ミッション
ビジョン
短期 中期 長期
財務の視点
顧客の視点
業務プロセスの視点
学習と成長の視点
SO
SO
SO
SO
SO
SO 戦略マップで定義した戦略目的(Strategic Objectives)
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3. ※戦略マップで定義した戦略と関連づかない OKR は、必要に応じて定義することもある
出典:<新版>【松原流】戦略マップ/BSCとOKRの連携教本-双方の強みを活かしたビジネスモデル・イノベーション
- 62. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
プロダクトをマネジメントする
• プロダクトオーナーからみた中期指標策定および四半期指標策定の進め方
– STEP1 :中期指標OKRのインプットを確認
» ミッション、ビジョン、戦略を確認する(事業目標、プロダクト達成指標など)
▸ ミッション、ビジョンは、会社のIR情報や経営目標、事業部目標や部門目標などから確認
▸ 特に戦略については、戦略マップの4要素である「財務、顧客、業務プロセス、学習と成長」の視点から、
それぞれ確認することが重要
– STEP2 : 中期戦略に応じた中期指標OKRを策定
» X年がかりの OKR として継続実施するいくつかの年次目標を、Objective に設定
▸ Osは、戦略に応じて複数設定する
▸ 戦略に対応しない OKR を設定する場合は、妥当性(説明可能な状態)を担保する
» 小刻みに改善していく、社員が実現可能だと思える四半期ごとの目標を、Key Result に設定
▸ それぞれの O に対して、複数の KRs を作成する
– STEP3 : 四半期に応じたOKRを策定
» チームにとって、四半期で実行・管理・事業価値提供が可能な目標を、Objective に設定
▸ Osは、中期戦略に応じて複数設定し、関連付ける
» メンバーによるオーナーシップが発揮可能な、定量的な結果の目標を、Key Result に設定
▸ それぞれの O に対して、複数の KRs を作成する
» メンバー主導で成果を出すためには、トップダウンに加えて、ボトムアップで作成することが
重要
61出典:グロース・アーキテクチャ&チームス株式会社 コンサルティング資料より
- 63. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
プロダクトの価値とは
• XM(Experience Management)から見た
プロダクトの価値
–最近では
62XM(Experience Management)とは - https://marketing.itmedia.co.jp/mm/articles/1907/18/news028.html
- 64. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
プロダクトをマネジメントする
• 戦略と中期指標の関係を整理し、事業貢献度を可視化
– 戦略マップを活用し、中期指標:OKRをミッション・ビジョンそして戦略と結びつける
» OKRは短期のサイクルを強調していて戦術的であることが強みではあるが、戦略と結びつかない
» ミッション、ビジョン、戦略とOKRを結びつけることで、戦略を全員の仕事へ関連付け可能
63
OKR
(四半期)
OKR
(中期)
戦略マップ
(中期)
ビジョン
(中期)
ミッション
(長期)
ミッション
ビジョン
短期 中期 長期
財務の視点
顧客の視点
業務プロセスの視点
学習と成長の視点
SO
SO
SO
SO
SO
SO 戦略マップで定義した戦略目的(Strategic Objectives)
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3.
目標 | Objective
主要な結果 | Key Results
1.
2.
3. ※戦略マップで定義した戦略と関連づかない OKR は、必要に応じて定義することもある
出典:<新版>【松原流】戦略マップ/BSCとOKRの連携教本-双方の強みを活かしたビジネスモデル・イノベーション
- 65. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
アジェンダ
• Azure DevOpsとは
• スクラムとは
• プロダクト開発とは
• Azure DevOps × スクラムで実現するプロダクト開
発のポイント
• まとめ
64
- 66. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
Azure DevOps × スクラムで
実現するプロダクト開発のポイ
ント
65
- 67. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
一番困っていることは何か
• Azure DevOps 上の以下について、
誰が 何を どの粒度 で書けばよいかわからない
–エピック
–フィーチャー
–ユーザーストーリー
–タスク
66
- 68. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
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
- 69. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
ポイント - 決めておきたいこと
68
粒度 何をどこまで書くか 誰が書くか
AsIs ToBe AsIs ToBe AsIs ToBe
エピック
フィーチャー
ユーザー
ストーリー
タスク
- 70. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
参考)BtoB向けプロダクトの場合
69
粒度 何をどこまで書くか 誰が書くか
エピック
• おおよそ年間計画単位で
実現するOKR
• 実現したい価値を記載する。他部署
の方が読んでもわかるよう記載
• 例「~のために~が~をできるよう
にする」
企画チーム
フィーチャー
• リリースとしてOKと
意思決定可能な最小単位
• MustとWantは分離
• シナリオテストレベルで
受入条件を明記
• 実現したい機能を他部署の方が
読んでもわかるよう記載
• 例「~が~をできる」
企画チーム
DevOpsチーム
ユーザー
ストーリー
• 1スプリントに収まる粒度
• 機能テストレベルで
受入条件を明記
• 「(誰)が(何)を(どうする)」
• Descriptionに理由(なぜならば~
だから)を記載
企画チーム
DevOpsチーム
タスク
• 一作業単位
• 一日単位(6H)
• 例「設計書作成」
• 「実装」⇒実装の大きさ、日数で
タスクを分割
• 「テスト計画書作成」
• 「CI動作確認」
DevOpsチーム
- 71. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
参考)BtoB向けプロダクトの場合
70
粒度 何をどこまで書くか 誰が書くか
エピック
• おおよそ年間計画単位で
実現するOKR
• 実現したい価値を記載する。他部署
の方が読んでもわかるよう記載
• 例「~のために~が~をできるよう
にする」
企画チーム
フィーチャー
• リリースとしてOKと
意思決定可能な最小単位
• MustとWantは分離
• シナリオテストレベルで
受入条件を明記
• 実現したい機能を他部署の方が
読んでもわかるよう記載
• 例「~が~をできる」
企画チーム
DevOpsチーム
ユーザー
ストーリー
• 1スプリントに収まる粒度
• 機能テストレベルで
受入条件を明記
• 「(誰)が(何)を(どうする)」
• Descriptionに理由(なぜならば~
だから)を記載
企画チーム
DevOpsチーム
タスク
• 一作業単位
• 一日単位(6H)
• 例「設計書作成」
• 「実装」⇒実装の大きさ、日数で
タスクを分割
• 「テスト計画書作成」
• 「CI動作確認」
DevOpsチーム
- 72. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
参考)BtoB向けプロダクトの場合
71
粒度 何をどこまで書くか 誰が書くか
エピック
• おおよそ年間計画単位で
実現するOKR
• 実現したい価値を記載する。他部署
の方が読んでもわかるよう記載
• 例「~のために~が~をできるよう
にする」
企画チーム
フィーチャー
• リリースとしてOKと
意思決定可能な最小単位
• MustとWantは分離
• シナリオテストレベルで
受入条件を明記
• 実現したい機能を他部署の方が
読んでもわかるよう記載
• 例「~が~をできる」
企画チーム
DevOpsチーム
ユーザー
ストーリー
• 1スプリントに収まる粒度
• 機能テストレベルで
受入条件を明記
• 「(誰)が(何)を(どうする)」
• Descriptionに理由(なぜならば~
だから)を記載
企画チーム
DevOpsチーム
タスク
• 一作業単位
• 一日単位(6H)
• 例「設計書作成」
• 「実装」⇒実装の大きさ、日数で
タスクを分割
• 「テスト計画書作成」
• 「CI動作確認」
DevOpsチーム
- 73. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
参考)BtoB向けプロダクトの場合
72
粒度 何をどこまで書くか 誰が書くか
エピック
• おおよそ年間計画単位で
実現するOKR
• 実現したい価値を記載する。他部署
の方が読んでもわかるよう記載
• 例「~のために~が~をできるよう
にする」
企画チーム
フィーチャー
• リリースとしてOKと
意思決定可能な最小単位
• MustとWantは分離
• シナリオテストレベルで
受入条件を明記
• 実現したい機能を他部署の方が
読んでもわかるよう記載
• 例「~が~をできる」
企画チーム
DevOpsチーム
ユーザー
ストーリー
• 1スプリントに収まる粒度
• 機能テストレベルで
受入条件を明記
• 「(誰)が(何)を(どうする)」
• Descriptionに理由(なぜならば~
だから)を記載
企画チーム
DevOpsチーム
タスク
• 一作業単位
• 一日単位(6H)
• 例「設計書作成」
• 「実装」⇒実装の大きさ、日数で
タスクを分割
• 「テスト計画書作成」
• 「CI動作確認」
DevOpsチーム
- 74. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
参考)BtoB向けプロダクトの場合
73
粒度 何をどこまで書くか 誰が書くか
エピック
• おおよそ年間計画単位で
実現するOKR
• 実現したい価値を記載する。他部署
の方が読んでもわかるよう記載
• 例「~のために~が~をできるよう
にする」
企画チーム
フィーチャー
• リリースとしてOKと
意思決定可能な最小単位
• MustとWantは分離
• シナリオテストレベルで
受入条件を明記
• 実現したい機能を他部署の方が
読んでもわかるよう記載
• 例「~が~をできる」
企画チーム
DevOpsチーム
ユーザー
ストーリー
• 1スプリントに収まる粒度
• 機能テストレベルで
受入条件を明記
• 「(誰)が(何)を(どうする)」
• Descriptionに理由(なぜならば~
だから)を記載
企画チーム
DevOpsチーム
タスク
• 一作業単位
• 一日単位(6H)
• 例「設計書作成」
• 「実装」⇒実装の大きさ、日数で
タスクを分割
• 「テスト計画書作成」
• 「CI動作確認」
DevOpsチーム
- 75. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
参考)BtoB向けプロダクトの場合
74
粒度 何をどこまで書くか 誰が書くか
エピック
• おおよそ年間計画単位で
実現するOKR
• 実現したい価値を記載する。他部署
の方が読んでもわかるよう記載
• 例「~のために~が~をできるよう
にする」
企画チーム
フィーチャー
• リリースとしてOKと
意思決定可能な最小単位
• MustとWantは分離
• シナリオテストレベルで
受入条件を明記
• 実現したい機能を他部署の方が
読んでもわかるよう記載
• 例「~が~をできる」
企画チーム
DevOpsチーム
ユーザー
ストーリー
• 1スプリントに収まる粒度
• 機能テストレベルで
受入条件を明記
• 「(誰)が(何)を(どうする)」
• Descriptionに理由(なぜならば~
だから)を記載
企画チーム
DevOpsチーム
タスク
• 一作業単位
• 一日単位(6H)
• 例「設計書作成」
• 「実装」⇒実装の大きさ、日数で
タスクを分割
• 「テスト計画書作成」
• 「CI動作確認」
DevOpsチーム
- 76. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
アジェンダ
• Azure DevOpsとは
• スクラムとは
• プロダクト開発とは
• Azure DevOps × スクラムで実現するプロダクト開発
のポイント
• まとめ
75
- 77. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
本日の概要
• Azure DevOpsは、ソフトウェア開発チームの
ための、システムの開発と運用を行う上で必要
となるサービスが集約された、チーム開発支援
のためのプラットフォームです。
• 今回は、Azure DevOps × スクラム で実現す
るプロダクト開発のポイントについて概説しま
す。
76
- 78. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
本日の目標
• Azure DevOps について把握する
• スクラム について把握する
• プロダクト開発 について把握する
• Azure DevOps × スクラム で実現する
プロダクト開発のポイント について把握する
77
- 79. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
一番困っていることは何か
• Azure DevOps 上の以下について、
誰が 何を どの粒度 で書けばよいかわからない
–エピック
–フィーチャー
–ユーザーストーリー
–タスク
78
- 80. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
本日お話したこと
• Azure DevOpsとは
• スクラムとは
• プロダクト開発とは
• Azure DevOps × スクラムで実現するプロダクト開発
のポイント
• まとめ
79
- 81. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
Azure DevOps × スクラム で
実現するプロダクト開発のポイント
#jazug
2019/09/07(土)13:30-14:25
グロース・アーキテクチャ&チームス株式会社
プロダクトオーナー支援スペシャリスト
関 満徳
- 82. Copyright© POStudy - プロダクトオーナーシップ研究会. All rights reserved.
ご清聴ありがとうございました!
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サービス開発全般のコンサルティング、開発、運用を一括して
手掛けながら、「顧客価値の創造」と「持続可能な仕組み創り」を
テーマとしたアジャイル・プロダクトマネジメントのバックログ
作成・見積 ワークショップデザインを数多く実施。全国各地で
ファシリテーターとしても活躍。