プロダクトオーナーがエンタープライズアジャイルで抱える苦悩と対処 #eaug

プロダクトオーナーが
エンタープライズ・アジャイルで
抱える苦悩と対処
2018/10/17(水)20:10-21:00
グロースエクスパートナーズ株式会社
ITアーキテクト関満徳

撮影可録音可
※音にご配慮お願いいたします
2Copyright© Growth xPartners, Inc. All rights reserved.
♪

はじめに
Copyright© Growth xPartners, Inc. All rights reserved. 3

本日の概要
• エンタープライズ・アジャイルを実現するにあ
たり、プロダクトオーナーは、プロダクトマネ
ジメント組織の中心として振る舞うことが求め
られます。しかし、プロダクトオーナーが抱え
る悩みは多岐に渡ります。
• 本セッションでは、それらの悩みごとを整理し
た上で、解決に向けた取り組みについてご紹介
いたします。

[参考] エンタープライズ・アジャイルとは
• エンタープライズ・アジャイルとは
– ウォーターフォール型プロセスや期間システムといった
既存のルールやシステムが存在する中で導入されたアジ
ャイルのこと
» チームレベルのアジャイルをより大きな組織やシステム向けに
スケールアップし、企業のビジネス競争力の向上に貢献している
状態
▸ 「大企業で小規模なアジャイル導入」
▸ 「大規模プロジェクトをアジャイルで運営」
▸ 「組織や企業そのものをアジャイルに運営」
» 少人数のチームで大規模なエンタープライズ・アプリケーション
開発を行う「仕組み」を作るためには、これらの仕組みを支える
技術が必要不可欠
“エンタープライズアジャイル” って何だろう？ http://yoshinorinie.hatenablog.com/entry/2018/05/01/102717
エンタープライズ・アジャイルってなんだろう？ 3つの視点と2つのフレームワーク https://thinkit.co.jp/story/2014/10/07/5294

本日の対象者
• プロダクトオーナーが抱える悩みが何かを
把握したい方
• プロダクトオーナーが抱える悩みについて、
どう対処したらよいか検討したい方

本日の目標
• プロダクトオーナーが抱える悩みについて
把握する
どう対処したらいいか把握する

アジェンダ
• プロダクトオーナーとは
• プロダクトオーナーが抱える悩み
• なぜプロダクトオーナーが悩むのか
• どう対処したらよいか
–企画と開発を繋ぐプロセスの明確化
–スプリントプランニングの運用改善
–スプリント運用ルールの改善
–Microsoft PowerPoint における開発手法
• プロダクトオーナーがやるべき3つのこと
• まとめ

アイスブレイク

アイスブレイク(1)
＜グループワークショップ＞
• 二人～三人で一組になってください
• プロダクトオーナーについてモヤモヤしている
ことがあれば、お互いに共有してください

アジェンダ
• まとめ

• 日本的プロダクトオーナーの現状
• プロダクトオーナーはどうあるべきか
• プロダクトオーナーが行うマネジメントとは
• プロダクトオーナーが採用する企画開発プロセスとは
プロダクトオーナーとは

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

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

• プロダクトオーナーが向いている方向
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
スクラム
マスター
開発チーム
開発
現場
外向き内向き
ニーズや優先順位につい
て、彼らの代理として行
動できるくらい深く理解
何をどの順で構築するのか
受け入れ条件を明確にして
テスト実行
プロダクト
オーナー
経営
現場
エッセンシャルスクラム P160 図9.1 プロダクトオーナーは2つの方向に同時に目を向ける

プロダクトオーナー

期待されること
求められるスキル必要な資質
主な責任

• プロダクトオーナーに期待されること
技術を活用すること
本当に大事な物だけに集中すること
時間管理
コミュニケーション能力
ビジネススキル
主な責任

経済性の管理
リリース・スプリント・プロダクトバックログ
プランニングへの参加
ポートフォリオ・プロダクト・リリース・スプリント
プロダクトバックログの洗練
作成・洗錬・見積もり・並び替え
受け入れ条件の定義と検証
機能要求・非機能要求・検証は機能が実装された都度実施
開発チームとの協力
設計・コーディング・結合・テスト
ステークホルダーとの協力
内部ステークホルダー・外部ステークホルダー
• プロダクトオーナーの主な責任
エッセンシャルスクラム P161 図9.2 プロダクトオーナーの主な責任
主な責任期待されること

• プロダクトオーナーに必要な資質
製品に対する熱意
顧客との共感力
知性
仕事に対する倫理観
誠実さ
自信
姿勢
Inspired日本語版 by Mare Azzurro, Inc. – 第6章
主な責任期待されること

ドメインスキル
ビジョナリーである
すべてを予測できないことを知っている
ビジネスとドメインの専門知識がある
対人スキル
ステークホルダーと良好な関係である
交渉や合意形成が得意である
コミュニケーションが得意である
周囲のモチベーションを高めることができる
意思決定力
意思決定の権限が与えられている
難しい意思決定ができる
決定力がある
経済的な観点からビジネスと技術の課題のバランスが取れる
説明責任力
プロダクトの責任を取る
献身的でいつでも連絡が取れる
スクラムチームのメンバーとして振る舞う
• プロダクトオーナーに求められるスキル
エッセンシャルスクラム P166 図9.5 プロダクトオーナーの特性
主な責任

–プロジェクトマネジメント？
–プロダクトマネジメント？
–プログラムマネジメント？
–カスタマーサクセスマネジメント？

–例）Microsoft Office の場合
Microsoft
Office
Microsoft Word
Office 365
定期リリース
案件A
案件B
突発対応
障害対応
不具合緊急リ
リース
パッケージ版
定期リリース
案件C
案件D
突発対応
障害対応
不具合緊急リ
リース
iOS版
定期リリース
案件E
案件F
突発対応
障害対応
不具合緊急リ
リース
Microsoft Excel
※以下同様
Microsoft
PowerPoint
※以下同様

「作る」から「使い続ける」へ
• モノからコトへのパラダイムシフト
–幅広い業界で市場は成熟し、すでに必要なモノは
ほとんど手に入った
–人々の関心はモノの所有欲を満たすことから、
経験、思い出、人間関係、サービスなどの
目に見えない価値であるコトに移行してきている

–モノを作る
–作ったモノを使い続けてコトを得る
–モノを作らずコトを得る
–Experienceを売っている

–一度作ったモノは、作ったらおしまい
–目に見えない価値であるコトは変わっていくので、
追随していく必要がある

–一度作ったモノは、成長しない
–一度作ったモノは、リリース後も成長し続ける
リリース1回目
↓
リリースn回目
↓
成
長
度
時間
成長しない
成長し続ける

–一度作ってリリースしたら、改修されない
–リリース後も改修し続ける
リリース1回目
↓
リリースn回目
↓
成
長
度
改修されない
改修し続ける
時間

–モノの提供＝数年間に一度のリリースの時代
–コトの提供＝数ヶ月/数週間/数日に1回、または
1日数回のリリースの時代へ
時間
時間
リ
リ
ー
ス
リ
リ
ー
ス

–単一リリースのためのアーキテクチャ
単一リリース
アーキテクチャ
–複数リリース毎に改善するアーキテクチャ
複数リリース
改善するアーキテクチャ
…

–単一プロジェクトのためのプロダクトマネジメント
単一プロジェクト
プロダクトマネジメント
–複数プロジェクトに跨がるプロダクトマネジメント
複数プロジェクト
プロダクトマネジメント
…

• マネジメント領域における役割
プロダクト
マネジメント
（PdM）
Do the right thing:
正しいことをする
プロダクト・マネージャー
プロダクト・オーナー
リーダー
プロジェクト
マネジメント
（PjM）
Do things right:
正しく実行する
プロジェクト・マネジャー
マネジャー
十返文子 - プロジェクトマネジメント再入門～PjMは何であって何でないのか～ https://www.slideshare.net/togaeri/pjm-72819087/14

• マネジメント領域におけるマネジメント対象
プロジェクトマネジメントプロダクトマネジメント
スコープ
マネジメント
コスト
マネジメント
コミュニ
ケーション
マネジメント
統合
マネジメント
ステーク
ホルダー
マネジメント
リスク
マネジメント
調達
マネジメント
資源
マネジメント
タイム
マネジメント
品質
マネジメント
What
How How
much
When
HowHow How
Why
How
WhoWhere
プロダクト
マネジメント
顧客（市場）
マネジメント
What Who
Who
ほぼ一緒？
やや重なる？
＝分析・戦略…
十返文子 - プロジェクトマネジメント再入門～PjMは何であって何でないのか～ https://www.slideshare.net/togaeri/pjm-72819087/12

• SoR (System of Record) (モード1)
–情報を正しく「記録」するためのシステム
–想起するもの･･･バックエンド、予約、在庫、カー
ド決済、ポイント処理、管理画面
• SoE (System of Engagement) (モード2)
–ユーザーや取引先との「絆」を作るためのシステム
–想起するもの･･･ UI、デザイン、アプリ、スマート
フォン、ダイレクトマーケティング、CRM
Copyright© Growth xPartners, Inc. All rights reserved. 39Naoya Ito - System of Record と System of Engagement https://speakerdeck.com/player/3be8af3598db45c6b16dc19a98ccecd6?slide=4#

SoR 型システム（モード1） SoE 型システム（モード2）
用語 • System of Record • System of Engagement
定義
• 事実を記録することに主眼を置いたシステ
ム・サービス
• お客様との関係（絆）を強化するための
システム・サービス
主役 • データ • 利用者
システム領域
• バックエンド
• 認証、在庫管理、決済、個人情報保護
• フロントエンド、スマートフォンアプリ
• UI、CRM、ダイレクトメール
開発手法
• 比較的ウォーターフォール寄り
• 開発前に要件を明確に定義
• 品質の確保を優先
• 比較的アジャイル、リーン寄り
• トライ&エラーで正しい問題・論点を
探り当てる
• 迅速なリリースを優先
性向 / 適合
• 安定性重視
• 予測可能業務
• リスクを抑えて安全運転
• 要件を事前に明確化
• ユーザーインタフェース品質、開発速度重視
• 探索型業務
• スピード重視で運転
• トライ&エラー、プロトタイピング
マネジメント
• トップダウン寄り
• 「正しい仕様」に基づいたプロジェクト管理
• 経営や開発部門が主導することが多い
• ボトムアップ寄り
• 「正しい仕様」は存在しない
• マーケティング、デザインが主導することも
ケイパ
ビリティ
• 要件定義力、調整力、プロジェクトマネジメ
ント
• SIのみなさんが得意そう
• ユーザー視点、デザイン思考、アナリティク
ス
• Web系が得意そうケイパビリティ
Naoya Ito - System of Record と System of Engagement https://speakerdeck.com/player/3be8af3598db45c6b16dc19a98ccecd6?slide=4#
赤間信幸 - 拝啓『変わらない開発現場』を嘆く皆様へ～変わっていくエンタープライズ系業務システム開発とマイクロソフトエンタープライズサービスの取り組み～ https://blogs.msdn.microsoft.com/nakama/2017/05/25/devmodernization/

• バイモーダルで実現する企業IT
モード1
方向
転換
馬力
モード2
小野和俊 - わたしのバイモーダル戦略 http://blog.livedoor.jp/lalha/archives/50524676.html

「使い続ける」実現プロセス
• [大量生産による解決]下でのプロダクトマネジメント
PMStyle – プロダクトマネジメント入門 http://pmstyle.biz/column/product/product1_3.htm
対
象
ス
キ
ル
【上流(upstream)】
～市場投入までに行うべきこと～
・ロードマップ
・ビジネスケース
・新製品開発
・市場投入
【下流(downstream)】
～市場投入後に行うべきこと～
・ライフサイクル管理
・ブランド管理
・マーケティング
・リーダーシップ
・意思決定
・会計
・コンペティティブ・
インテリジェンス
・価格戦略
プロダクトマネージャー

• インターネット時代のプロダクトマネジメント
Copyright© Growth xPartners, Inc. All rights reserved. 43プロダクトマネジメントトライアングル(改案) https://webexpert-draft.jp/articles/59

プロジェクトマネジメント
社内外調整／資源獲得
プロダクト仕様
カスタマー/技術サポート
データ分析
デザイン
マーケティング
パートナーシップ
ビジネスデベロップメント

プロダクト
マネージャー

• [例]プロダクトマネージャーへのキャリアパス
プロダクト
マネージャー
u
エンジニア
マーケティングスタートアップ
営業 QA

• プロダクトオーナーが採用する企画開発プロセス
48Copyright© POStudy ～アジャイル・プロダクトマネジメント研究会～. All rights reserved.
企画～開発

• プロダクトオーナーが採用する企画開発プロセス
–既存の代替手段を起点とし、仮説検証を繰り返して
あるべき姿を模索し、MVPを定義後、拡張へ？
» 例）リーンスタートアップ、デザイン思考など
–新しいシーンの開発を起点とし、価値定義と検証を
繰り返してあるべき姿を模索し、MVPを定義後、拡
張へ？
» 例）匠Methodなど
企画～開発

既存の代替手段を起点としたプロセス
なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
プロダクトデザイン
・
リーンUX
スクラム
アーキ
テクチャ
本番運用

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
思い込みにより発生
する各種ムダを省く
ためにリーンにやる
ムダなモノを省き
必要なモノを素早く
作り続ける
エンジニアリング
モノを支え
るアーキ
テクチャ
ムダなく本番運用を
まわし続ける

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
リーン
スクラム
アーキ
テクチャ
本番運用
アジャイル
・
モダンアジャイル

モダンアジャイルを提唱した背景
• 2001年公開アジャイルソフトウェア開発宣言
–2011年正式な日本語版も公開
» http://agilemanifesto.org/iso/ja/manifesto.html

モダンアジャイルを提唱した背景
• アジャイルについてさらなる検証と実験を実施
–よりシンプルなアプローチがないか
–より安全にできないか
• その結果、大幅に効率的なアジャイルプロセス
を構築
–それがモダンアジャイル
Copyright© Growth xPartners, Inc. All rights reserved. 55モダンアジャイルワークショップ - http://agilejapan.org/modernagile_0414.html

モダンアジャイルの4原則
• [最高] 人々を最高に輝かせる
• [安全] 安全を必須条件にする
• [高速] 高速に実験＆学習する
• [継続] 継続的に価値を届ける
Copyright© Growth xPartners, Inc. All rights reserved. 56モダンアジャイルの原則・実践について - 今給黎隆 http://bit.ly/2qCRRGu

モダンアジャイルプラクティス
カテゴリプラクティス
1 [最高][安全] 仕事の憲章化
2 [高速][最高][安全] リーン・スタートアップの活用
3 [高速][最高] リーンUXの適用
4 [高速][安全][継続] 頻繁な協調と統合
5 [安全][高速] 安全に失敗できる環境
6 [安全][継続] テストとリファクタリング
7 [安全] 人々への敬意と感謝
8 [安全][高速] 非難しないふりかえりを指揮
9 [継続] フローに集中
10 [継続][高速][安全] 継続的なデプロイとリリース
11 [継続][安全] プロダクトコミュニティを形成
12 [継続][高速][安全] ソリューションを進化
モダンアジャイルの原則・実践について - 今給黎隆 http://bit.ly/2qCRRGu

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
やりたいコト
用意しなければなら
ないモノ
用意しな
ければなら
ないモノ
対応しなければ
ならないコト

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

プロダクト
Log
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
デッキ
サービス
設計
テクニカル
検討
スプリント
レビュー
かんばん
価値計測出荷
プロダクト
利用

アジェンダ
• まとめ

• プロダクト組織が抱える悩み
プロダクトオーナーが抱える
悩み

悩み

プロダクトオーナーが抱える悩み

の役割
製品ビジョン
リリース計画
スプリント
ミーティング
プロダクト
バックログ
スクラムを活用したアジャイルなプロダクト管理 P41 よくある間違い

• プロダクトオーナーの役割における悩み
力不足のプロダクトオーナー
権限付与が不足
働き過ぎるプロダクトオーナー
プロダクトバックログの手入れを怠る・欠席する・把握してない
限定的なプロダクトオーナー
外しか向かない・内しか向かない
遠隔地のプロダクトオーナー
不信感・伝達ミス・認識のズレ・進捗遅延
代理のプロダクトオーナー
争いや誤解の増加・意思決定の遅延・生産性や士気の低下
プロダクトオーナー委員会
製品全体に責任を持たない複数のプロダクトオーナーで構成
の役割
製品ビジョン
リリース計画
スプリント
ミーティング
プロダクト
バックログ

• 製品ビジョンにおける悩み
Copyright© Growth xPartners, Inc. All rights reserved. 67スクラムを活用したアジャイルなプロダクト管理 P41 よくある間違い
ビジョンがない
顧客が要求する個々の機能の関連性を考慮せずに製品を開発
予言ビジョン
不正確な予測から発生しうる損失や損害を最小限に抑えようとしない
分析麻痺
市場の調査を行いすぎて時間と資金を無駄に浪費
顧客にとって良いものは自分達が一番よく知っている
誰も望んでいない製品開発に時間と資金を費やしてしまう
大きいことは美しい
ほとんどの機能は事前に確定し、フィードバックを取り入れられない
の役割
製品ビジョン
リリース計画
スプリント
ミーティング
プロダクト
バックログ

偽装した要求仕様
詳細で包括的なプロダクトバックログは、新しい要件に対応できない
サンタへの要望リスト
必要になる可能性があるものをすべて書き込んだプロダクトバックログ
チームへの要件の強要
一人でプロダクトバックログを作成、チームの知識・経験・創造性が無駄
プロダクトバックログの手入れの放置
スプリント計画の前にプロダクトバックログを手入れしない
複数のプロダクトバックログの競合
タスク切り替えで貴重な時間を無駄にする
• プロダクトバックログにおける悩み
の役割
製品ビジョン
リリース計画
スプリント
ミーティング
プロダクト
バックログ

バンジープロダクトオーナー
スプリント計画で現れ、消えて、スプリントレビューでまた現れる
受け身のプロダクトオーナー
スプリントレビューで傍観者のように受動的に振る舞う、見るだけ
持続不可能なペース
スプリントとスプリントの間に休憩はしない、リカバリー期間がない
ごまかし
カラフルなスライドやDoneの定義を満たさない結果でレビュー完了
スプリントバーンダウンチャートによる報告
プロジェクトの進捗報告の材料に使ってしまい、管理のための仕組み化
• スプリントミーティングにおける悩み
の役割
製品ビジョン
リリース計画
スプリント
ミーティング
プロダクト
バックログ

リリースバーンダウンチャートやリリース計画がない
詳細なプロジェクト計画を事前に作成することに慣れている
受け身のプロダクトオーナー
リリース計画をスクラムマスターやチームに委任
ビッグバンリリース
全ての機能を実装した後で製品をリリース、発売日に初めて製品を使う
品質の妥協
いろいろ省略し、テストも少しだけ行い、ドキュメント作成も遅らせる
• リリース計画における悩み
の役割
製品ビジョン
リリース計画
スプリント
ミーティング
プロダクト
バックログ

悩み

プロダクト組織が抱える課題
スクラム
マスター
開発チーム
開発
日本的プロダクトマネージャー
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
発注受託
• 営業や企画が強く、開発が企画機能の下請けに
なっている

• プロダクトマネージャーが調整やタスクを抱え
すぎてパンク
スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
仕事
抱えすぎ

スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
ブラック
ボックス
• 抱えている調整が可視化されず、周辺がうまく
サポートできない

スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
弱点
• プロダクトマネージャーが倒れるとプロダクト
全体が大ダメージ

スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
誰かやって～！
• 中心人物が辞めてしまった / 規模が大きくなっ
て組織を拡大したいが、中心人物がいない

スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
調査調査
調査
調査
調査
調査
か、開発が、、、
• 企画のためのR&D調査、運用のための割り込み
調査、実現に向けた技術調査が、開発を圧迫

スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
プロダクトA
プロダクトB
プロダクトC
プロダクトD
チームA
チームB
チームC
チームD
• 開発リソースをプロダクト別に分断したため、
プロダクト毎に開発チームの戦力が偏っている

スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
プロダクトA
プロダクトB
プロダクトC
プロダクトD
チームA
チームB
チームC
チームD
余裕あるから
休もうっと！
余裕あるから
別のことを...
エンジニアが足りない！！！
誰か手伝ってくれ….
• 事業計画に基づく開発ピークの重なりに抱えて
いる開発メンバーの再配分で対応できない

アジェンダ
• まとめ

• スクラムを提唱した背景
• プロダクトオーナーの実態
なぜプロダクトオーナーが悩む
のか

のか

スクラムを提唱した背景
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
スクラム
マスター
開発チーム
開発

アメリカ
国内の
工場で生産
酒井崇男氏 Agile・Leanの源流と課題： https://leanx.jp/agile-lean-genuine-toyota-way/

アメリカ
国内の
工場で生産
日本から
工場生産
支援開始

アメリカ
国内の
工場で生産
日本から
工場生産
支援開始
劇的に改善！

アメリカ
国内の
工場で生産
日本から
工場生産
支援開始
IT業界向けにアレンジ！

Copyright© Growth xPartners, Inc. All rights reserved. 89酒井崇男氏 Agile・Leanの源流と課題： https://leanx.jp/agile-lean-genuine-toyota-way/
• 価値とは何か
• どんな世界を
創りたいのか
• 何を創るのか
• どう作るのか
• いつ作るのか
• どう広めるか
• どれくらい
作れたか
• ムダをどう
なくすのか

• 外部から見た工場の役割
班長／
組長
工場
勤務者工場
神様

• 提唱したスクラムの役割
スクラム
マスター
開発チーム
開発

班長／
組長
工場
勤務者工場
創りたいのか
工場の中にいた
神様がやっていると認識
神様

創りたいのか
全部やる！と決めた
スクラム
マスター
開発チーム
開発

創りたいのか
• どれくらい
作れたか
• ムダをどう
なくすのか

班長／
組長
工場
勤務者工場
創りたいのか
• どれくらい
作れたか
• ムダをどう
なくすのか
工場の中にいた班長／
組長がやっていると認識
神様

創りたいのか
• どれくらい
作れたか
• ムダをどう
なくすのか
スクラムマスターが
スクラム
マスター
開発チーム
開発
神様

• 定義したプラクティス
スクラム
マスター
開発チーム
開発
作る物と優先
順位の管理
↓
バックログ
作れた数
↓
ベロシティ
(XPより)

のか

創りたいのか
• どれくらい
作れたか
• ムダをどう
なくすのか

• 定義したプラクティス
スクラム
マスター
開発チーム
開発
作る物と優先
順位の管理
↓
バックログ
作れた数
↓
ベロシティ
(XPより)

ところで・・・
• 車の生産工場の量産体制の中で、同じ車を
「作った数」をベロシティとして測る

• 知的生産労働であるIT業界で、毎回作る物が
異なる環境の中で「作った数」を測る

• 知的生産労働であるIT業界で、毎回作る物が
異なる環境の中で「作った数」を測る
• うまくいくのか！？うまくいってるのか！？

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

経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
スクラム
マスター
開発チーム
開発
創りたいのか

• [参考] 実際のトヨタ本体が儲ける仕組み
Copyright© Growth xPartners, Inc. All rights reserved. 106酒井崇男氏実際のトヨタ本体が儲ける仕組み： https://leanx.jp/lean-quality/
トヨタ流製品開発
TPD
トヨタ生産方式
TPS

• 実際は、、、

• 実際は、、、
班長／
組長
工場
勤務者工場
神様
創りたいのか
神様なんか
いなかった

• IT業界では、、、

経営層
ステークホルダー
バックログ
実現可能性
検討
顧客
意思決定
検討
スクラム
マスター
開発チーム
ビジョン
コンセプト
アイディア
M&A
バックログ
ばらし
バックログ
洗練
プロダクトロードマップ
マイルストーン策定
バックログ
リファインメント
計画見直し
プロダクト
バックログ

経営層
バックログ
実現可能性
検討
顧客
意思決定
検討
スクラム
マスター
開発チーム
ビジョン
コンセプト
アイディア
M&A
バックログ
ばらし
バックログ
洗練
バックログ
計画見直し
プロダクト
バックログ
企画が要件を決めたら
あとは開発に丸投げ

アジェンダ
• まとめ

企画と開発を繋ぐプロセスの
明確化

プロダクト
Log
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
デッキ
サービス
設計
テクニカル
検討
スプリント
レビュー
かんばん
価値計測出荷
プロダクト
利用

バックログの作成プロセス
• スクラムガイド 2017改訂版
– https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
プロダクトバックログの

経営層
バックログ
実現可能性
検討
顧客
意思決定
検討
スクラム
マスター
開発チーム
ビジョン
コンセプト
アイディア
M&A
バックログ
ばらし
バックログ
洗練
バックログ
計画見直し
プロダクト
バックログ

経営層
バックログ
実現可能性
検討
顧客
意思決定
検討
スクラム
マスター
開発チーム
ビジョン
コンセプト
アイディア
M&A
バックログ
ばらし
バックログ
洗練
バックログ
計画見直し
①
②
③
④
⑤
プロダクト
バックログ

• プロダクトロードマップ・マイルストーン策定
–開発着手GOが出た企画に対し
以下を考慮して計画を策定
» いつ市場に投入すべきか
» 現場は対応できるか
» 開発チームは対応できるか
①

• バックログばらし
–業務運用に関わるバックログ
» 業務フロー整備など
–サポートに関するバックログ
» マニュアル作成など
–開発すべきバックログ（＝プロダクトバックログ）
» 詳細は「バックログの洗練」で内容を詰める
–リリースに関するバックログ
• 大雑把な見積
–タスクの全量を把握
②

• バックログの洗練
–モブワークによる共同作業
» 企画チームから数名参加
» 開発チームから数名参加
–何を洗練するのか
» どう作るのか
» どこまで作り込むか
» やることとやらないことの境界線は何か
» 完成時に確認するための項目は何か
③

• バックログリファインメント
–プロダクトバックログに対して
以下を実施
» 詳細の追加
» 見積り
» 並び替え
» レビューと改訂
–プロダクトオーナーと開発チームが協力して行う
継続的なプロセス
–開発チームの作業の 10%以下
④
スクラムガイド改訂版 - https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
スクラムガイドに記載
されている内容と同一
これまでの予実差をフィードバックとして
学習し、次のスプリント分の見積を見直す

• 計画見直し
–大雑把な計画に対して、
スプリントを重ねて学習した
見積の予実差を元に、
改めて全量を再見積
–マイルストーンまでに残されたスプリントで、
マイルストーン達成に必要なバックログが完了でき
ない場合、要件を落とすなどの調整を実施
» その結果、マイルストーンに見直しが発生する場合は、
経営層まで差し戻して意志決定をし直す必要あり
⑤

経営層
バックログ
実現可能性
検討
顧客
意思決定
検討
スクラム
マスター
開発チーム
ビジョン
コンセプト
アイディア
M&A
バックログ
ばらし
バックログ
洗練
バックログ
計画見直し
①
②
③
④
⑤
プロダクト
バックログ

アジェンダ
• まとめ

スプリントプランニングの
運用改善

スプリントプランニングの運用改善
1. 半年分のスプリントを見越した計画を立てる
よう改善
2. これまでなかったバックログ洗練を新たに導
入
3. Jiraチケットのタイトルに「FIX」を追記する
運用を導入

1. 半年分のスプリントを見越した計画を立てるよう
改善
– これまで
» バックログリファインメントでは、次スプリントまでしか計画し
ていなかった
– 現在
» マイルストーン策定までに終わらないことを改善直後早期に発見
» 計画の見直しや体制の見直しを含めて、早めに手を打つことがで
きた
2. これまでなかったバックログ洗練を新たに導入
3. Jiraチケットのタイトルに「FIX」を追記する運
用を導入

半年分のスプリントを見越した計画
半年分のスプリントを見越した計画を立てる運用直近1ヵ月分の計画見直し
直近のスプリント
半年分のスプリント

マイルストーン策定までに終わらないことを早期に発見
• 直近1ヵ月分の計画見直し

改善
– 現在
» スプリントプランニングにおける洗練の無駄を改善
» その上で、サービス仕様書をバックログアイテムに落とすまでを
手順化
» 必要なイベントや参加すべき対象者をマニュアル化し、チーム内
で共有
用を導入

バックログ洗練を新たに導入資料
• サービス仕様書をバックログアイテムに落とす
までを手順化

改善
用を導入
– 現在
» バックログ洗練にて、プロダクトオーナーと開発チーム間で仕様
の合意が出来たバックログについて、FIXを追記
» スプリントプランニングでは、バックログ洗練に参加した開発メ
ンバーが仕様を説明する運用を導入

Jiraチケットのタイトルに「FIX」を追記
• Jiraチケットのタイトルに「FIX」を追記

スプリントプランニングの改善効果
1. プロダクトオーナーが、サービス仕様書を受け取ってから
スプリントプランニングまでの間、何をしなければならな
いのかが明確に
– これまで
» バックログリファインメントとスプリントプランニングの時間を使ってバ
ックログ洗練も実施
» 議論に参加していないメンバーの待ち時間の無駄が多く発生
– 現在
» バックログ洗練に参加したメンバーがスプリントプランニング時に説明
» 後工程にならないと出てこなかったQAが、事前に出てくるように
スプリント開始後のQAが明らかに減ったと、プロダクトオーナーが実感
2. 今回の改善を通して
– バックログ洗練にもっと時間を掛ける必要があることを、チームメ
ンバー全員が意識
– バックログ洗練の計画的な実施が定着しつつある

改善施策の定性評価と定量評価
事前に洗練できてい
れば、プラニング中
に洗練不要となるは
ず
4-2-1
バックログ洗練実施
率
4-3-1
スプリントプ
ラニング中に
説明されたチ
ケット数
4-3-2
スプリント開
始時に完了条
件がFIXしてい
ないチケット
の数
4-3-1
スプリントプラニン
グ中に説明されたチ
ケット数
4-3-2
スプリント開始時
に完了条件がFIXし
ていないチケット
の数
4-1-1
バックログリ
ファインメン
トの実施時間
4-3-3
スプリントプ
ラニング中の
突発洗練にか
けた時間
4-4-1
開発見積の実
施時間
バックログリファイン
メントの実施内容整備
バックログ洗練イベン
トを追加
（QAで詳細を詰める、
完了条件を明記し合意、
等）
スプリントプラニングの
実施内容整備
（洗練出席者が説明、
POが理解度確認、開発
メンバーから追加QA、
等）
開発見積の実施内容整
備
洗練で完了条件を
合意するので、増
えるはず
取り組みをきちんと実
施できたか、記録する
事前に洗練できてい
れば、優先順位の再
確認のみで済むので、
時間短縮
洗練で内容確認
済なので、増え
るはず
プランニングで必要
なQAが済んでいるの
で、見積にかかる時
間を短縮できる現状との比較により、件数が
増えた（減った）ことを検証
現状把握の
ための計測
中間指標成果指標取り組み
ご報告した
所感
凡例:
C-1
後工程にならないと出てこ
なかったQAが、事前に出
てくるようになった
C-3
半年分のスプリントを見越
した計画を立てるよう改善
定量評価
結果:
…成果が出た
…成果は測定中
…成果はまだ出てない
C-1
スプリント開始後のQAが、
明らかに減った

アジェンダ
• まとめ

スプリント運用ルール整備

1. プロダクト別の進捗の可視化を実施
2. 個人別の進捗の可視化を実施
3. スプリント内に抱えているタスクがすべて終
わるか否かを確認

– 朝会にてプロダクト別の進捗状況を把握できるように
» 具体的には、Jiraダッシュボードを整備
» あわせて朝会のアジェンダを見直し
» 並行して、ダッシュボードに表示したバーンチャートの見方やポ
イントについて資料にしたものをホワイトボードに張り出すなど
、人の記憶に頼りすぎない工夫も、実施
3. スプリント内に抱えているタスクがすべて終わる
か否かを確認

プロダクト別の進捗の可視化
• 朝会にてプロダクト別の進捗状況を把握できる
ように、Jiraダッシュボードを整備
全プロダクトプロダクトA
プロダクトB プロダクトC

プロダクト別の進捗の可視化資料
• ダッシュボードに表示したバーンチャートの見
方やポイントについての資料を掲示

–朝会で個別の報告内容の妥当性を全員が判断可能に
» 具体的には、Jiraダッシュボードを整備
» その過程で、Jiraワークフローも見直し

• スクラムガイド 2017改訂版
– https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

個人別の進捗の可視化実際の画面
• 朝会で個別の報告内容の妥当性を全員が判断
可能にするためのJiraダッシュボードを整備
開発メンバーA
開発メンバーB
開発メンバーC
開発メンバーD

–スプリント中間地点（隔週木曜日）にスクラムマス
ターから個人別に実施
» タスクの調整が必要であれば調整を行う運用を導入

スプリント運用ルール整備の効果
1. 朝会におけるプロダクト別の進捗の共有精度が向上
– これまで
» プロダクト別の進捗がわからず、全体の進捗もわかりにくい状況
– 現在
» Jiraダッシュボードを見ることで、朝会はもちろん、朝会以外の任意のタイミングに
おいても、チームの進捗が把握できるように
2. 朝会における個人のタスク状況共有が、より意味のあるものに
– これまで
» 個人の報告内容の妥当性を判断する材料がなく、聞き流すことも多かった
– 現在
» 個人の報告を聞くと同時にJiraダッシュボード上でその個人が抱えているタスクと進
捗状況を見ることで、個人の報告内容の妥当性をメンバー全員が判断することがで
きるように
3. 今回の改善を通して、朝会で本来やるべき
「スプリント中にタスクが終わりそうになかったら手を打つ」
ことが自発的にできるチームへ、一歩近づいた

改善施策の定性評価と定量評価
2-1-6
タスク分類別工
数予実
開発系タスクの
工数予実
突発タスクの工
数予実
計画したタスク
の実施率（チ
ケットドロップ
数）
朝会でこまめに状況把握、都
度調整⇒「スプリント終わっ
てみたら溢れていた」を回避
3-1-1
スプリント運用ルールで
決めた事項の実施率（ア
ジェンダ通り実施した朝
会の比率）
※成果指標は取り組み２と同じ
朝会のバーン
チャート確認タ
イミングを、個
別の状況報告前
に移動
フィルター別の
バーンダウンを
Jiraのダッシュ
ボードで確認
開発メンバー別
のタスクをJiraの
ダッシュボード
で確認
取り組みをきちんと実施
できたか、記録する
現状把握の
ための計測
中間指標成果指標取り組み
ご報告した
所感
凡例:
B-1
朝会におけるプロダクト別
の進捗の共有精度が向上
B-2
朝会における個人のタスク
状況共有が、より意味のあ
るものになった
B-3
「スプリント中にタスクが
終わりそうになかったら手
を打つ」ことが自発的にで
きるチームへ、一歩近づい
た
定量評価
結果:
…成果が出た
…成果は測定中
…成果はまだ出てない

アジェンダ
• まとめ

Microsoft PowerPoint
における開発手法

–例）Microsoft Office の場合
Microsoft
Office
Microsoft Word
Office 365
定期リリース
案件A
案件B
突発対応
障害対応
不具合緊急リ
リース
パッケージ版
定期リリース
案件C
案件D
突発対応
障害対応
不具合緊急リ
リース
iOS版
定期リリース
案件E
案件F
突発対応
障害対応
不具合緊急リ
リース
Microsoft Excel
※以下同様
Microsoft
PowerPoint
※以下同様

Microsoft PowerPoint の歴史
出典：WikiPedia https://ja.wikipedia.org/wiki/Microsoft_PowerPoint
No. パッケージ版のリリース状況
バージョン 1 Forethougt が1987年にMacintosh向けにリリースしたもの。
バージョン 2 Macintosh版は1988年にリリースされ、Windows版はWindows 3.0用で1990年にリリースされた。
バージョン 3 Macintosh版は1992年にリリースされ、Windows版はWindows 3.1用にMacintosh版と同じ年にリリースされた。
バージョン 4 Windows版の PowerPoint 4.0 は1993年にリリースされ、Macintosh版のPowerPoint 4.0は1994年にリリースされた。
バージョン 7 他のOfficeソフトウェアとバージョン番号が統一されたため、バージョン番号が3繰り上がった。このバージョンはPowerPoint
95としてWindows版のみリリースした。日本語版はこのバージョンから用意された。
バージョン 8 Windows版のPowerPoint 97が1996年にリリースされ、Macintosh版のPowerPoint 98は1998年にリリースされた。
バージョン 9 Windows版のPowerPoint 2000が1999年にリリースされ、最後のMac OS 9版PowerPoint 2001は2000年にリリースされた。
PowerPoint 2000では従来アウトライン画面・スライド画面・ノート画面を別々の画面で操作していたものを、一つの画面で操
作できるようになったことで、プレゼンテーション制作の生産性を大幅に向上させた。
バージョン 10 Windows版のPowerPoint 2002が2001年にリリースされ、初のMac OS X版のPowerPoint Xも同年にリリースされた。
バージョン 11 Windows版のPowerPoint 2003が2003年にリリースされ、Mac OS X版のPowerPoint 2004は2004年にリリースされた。
バージョン 12 Windows版のPowerPoint 2007が2007年にリリースされ、Mac OS X版のPowerPoint 2008は2008年にリリースされた。
バージョン 14 Windows版のPowerPoint 2010が2010年にリリースされ、Mac OS X版のPowerPoint 2011も同年にリリースされた。
バージョン ? 2010年6月から「Office Web Apps」という名称で、Word、Excel、PowerPoint、OneNoteのブラウザベースのバージョンが
提供された。以降、都度バージョンアップを実施。
2014年2月に、「Office Online」に名称変更した。
バージョン？ 2011年6月に「Office 365」が提供開始された。以降、都度バージョンアップを実施。
バージョン 15 Windows版のPowerPoint 2013が2013年にリリースされた。
バージョン 16 Windows版、OS X版、iOS版のPowerPoint 2016が2015年にリリースされた。
出典：WikiPedia https://ja.wikipedia.org/wiki/Microsoft_Office_365

Microsoft PowerPoint の種類
1. パッケージ版
– Office 20XX
» Windows 版
» MacOS 版
– Office 365
» Windows 版
» OS X 版
2. Office Online
3. スマートフォン用アプリ
– iOS 版

Microsoft PowerPoint の開発体制
• 複数チームで構成
• 1チームは、自律的に動ける人数に限定
–プログラムマネージャー × 1名～?名
–エンジニア × 数名
–プログラムマネージャーとエンジニアは同室にいる
–プラットフォーム毎にチーム編成を行っているわけ
ではない
• ローカライズは、別チームが担当

Microsoft PowerPoint 開発の進め方
• タスクは、2種類に分類
• それぞれのタスクを担当するチーム数は
スプリント毎に再配分
–時期によって比率がかなり異なる
» Microsoft Build 後は、フィードバックがたくさん来る
▸ シールド : フィーチャーが 50% : 50% になることも
▸ シールドが溜まる傾向にある場合、シールド対応チーム数を増やして
対応
タスク内訳
シールドフィードバック／不具合対応
フィーチャー計画された機能開発→毎月リリース

お話してくださった方が言うには
• アジャイルやスクラムをやっているという認識
はない
• Microsoft 社内で試行錯誤した結果、今の形に
行き着いた
• とはいえ、ここまでくるのにいろいろなことが
あった

ここ最近のTopix (1/3)
• チームメンバーからテスターがいなくなった
–開発とテストは両輪
–同じ人が同時にやればよい
–エンジニアAが実装、エンジニアBがテスト、という
分担をすることもある
–テストは基本的にすべて自動化が必要
» とはいえ、数十年前から存在するソースコードのため、
既存のコードは膨大に存在するが、その部分を自動化する
ようなことはしていない
» 今回手を入れる部分について、新たにテストコードを記述

• チームメンバーからDev Lead がいなくなった
–マネージャーの役割をしていた人が一気に減った
–1チームの人数を減らして、マネージャーがいなくて
も管理可能に

• 評価制度がかなり変わった
–リリースされなかったら評価がゼロ
–どのぐらいのインパクトを与えたかが評価
» 10やってたことを2に減らす、かわりに
やった2を10箇所にApplyしてインパクトを増やすetc…
» やることを減らして、クオリティを上げる傾向に
–評価はかけ算
» セキュリティやパフォーマンスが悪いと0点に

アジェンダ
• まとめ

プロダクトオーナーがやるべき
3つのこと

プロダクトオーナーがやるべき3つのこと
1. プロダクトマネジメント組織を中心とした
価値創造の組織・仕組みを作る
2. 価値から話を始める
3. フェーズによる役割の変化を理解する

プロダクトマネジメント組織を中心と
した価値創造の組織・仕組みを作る
経営層
バックログ
実現可能性
検討
顧客
意思決定
検討
スクラム
マスター
開発チーム
ビジョン
コンセプト
アイディア
M&A
バックログ
ばらし
バックログ
洗練
バックログ
計画見直し
プロダクト
バックログ

価値から話をはじめる
• 企画開発プロセスの違いを把握する
–既存の代替手段を起点とし、仮説検証を繰り返して
あるべき姿を模索し、MVPを定義後、拡張へ？
» 例）リーンスタートアップ、デザイン思考など
–新しいシーンの開発を起点とし、価値定義と検証を
繰り返してあるべき姿を模索し、MVPを定義後、拡
張へ？
» 例）匠Methodなど
企画～開発

フェーズによる役割の違いを把握する
• プロダクトの成長を支える品質
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ - https://www.slideshare.net/i2key/devlove-devkan

フェーズによる役割の違いを把握する
• プロダクトの組織の大きさに応じた関心ごと
プロダクトマネージャとして海外で働き始めて、自分の視点をどこに持ってこようかと考えた話 - https://www.slideshare.net/DaisukeMatsuda2/pmroppongi-
120745681?fbclid=IwAR2eh37rAI9-8nRMlFCFCxjWhmL0OA0ugCmBphwzA018-ISabC03lEkOQmM

プロダクトオーナーがやるべき3つのこと
1. プロダクトマネジメント組織を中心とした
価値創造の組織・仕組みを作る
2. 価値から話を始める
3. フェーズによる役割の変化を理解する

アジェンダ
• まとめ

本日の概要
• エンタープライズ・アジャイルを実現するにあ
たり、プロダクトオーナーは、プロダクトマネ
ジメント組織の中心として振る舞うことが求め
られます。しかし、プロダクトオーナーが抱え
る悩みは多岐に渡ります。
• 本セッションでは、それらの悩みごとを整理し
た上で、解決に向けた取り組みについてご紹介
いたします。

本日の対象者
• プロダクトオーナーが抱える悩みが何かを
把握したい方
• プロダクトオーナーが抱える悩みについて、
どう対処したらよいか検討したい方

本日の目標
把握する
どう対処したらいいか把握する

本日お話したこと
• まとめ

Q&A

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

CONFIDENTIAL
⚫ 本文書は、グロースエクスパートナーズ株式会社が著作権その他の権利を有する営業秘密（含サプライヤー等第三者が権利を有するもの）
です。
⚫ 当社の許可なく複製し利用すること、また漏洩することは「著作権法」「不正競争防止法」によって禁じられております。
⚫ 本資料内の社名・製品名は各社の登録商標です。

プロダクトオーナーがエンタープライズアジャイルで抱える苦悩と対処 #eaug

More Related Content

What's hot

Similar to プロダクトオーナーがエンタープライズアジャイルで抱える苦悩と対処 #eaug

More from 満徳 関

プロダクトオーナーがエンタープライズアジャイルで抱える苦悩と対処 #eaug

More from 満徳関