1.
伊藤 宏幸
世界と事例から学ぶ、
プロダクトオーナーの
「素養」としての
アジャイルメトリクス
2016年11月25日2016年11月26日

2.
自己紹介
2
伊藤 宏幸（The Hiro）
@hageyahhoo
ヤフー株式会社
• アジャイルコーチ
• 自動化コーチ
• 黒帯（アジャイル開発プロセス）

3.
3
最近のアジャイル
と
メトリクス

4.
RSGT 2016
4
僕らのおれおれメトリクス /
We metrics in our own way!
https://regionalscrumgatheringrtoky2016.sched.org/
スクラムとメトリクスとテストを活用する
チームの事例
Technology-Driven Development

5.
Agile2016
5
Measuring DevOps: the Key Metrics that Matter
https://agile2016.sched.org/
Pin the Tail on the Metric
Virtuous Metrics
- Most metrics are the devil. Be an angel.
Start Your Engines!
Accelerating DevOps Performance using Lean Metrics
Data Driven Coaching
- Safely turning team data into coaching insights

6.
海外のアジャイル普及状況調査
6
VersionOne
Scrum Alliance
「どんなメトリクスを取っていますか？」
という質問が普通にある！

7.
7
アジャイルの文脈において、
メトリクスの取得・活用は、
もはや一般的なことと
なりつつある。

8.
8
皆さんは、
プロダクトオーナーとして、
メトリクスを
活用できていますか？
一方で。

9.
よくある質問
9
• メトリクスって何？
• メトリクスの取り方がよく分からない
• 何をどう取れば良いのか？
• 実務でどう活用すれば良いのか？
写真：アフロ

10.
今回のテーマ
10
• メトリクスとは何か？
• POにとって必要なメトリクスとは何か？
• メトリクスをどうやって活用すべきか？
写真：アフロ

11.
アジェンダ
11
1. メトリクスの基礎
2. POにとって必要なメトリクス
3. メトリクスの実践的活用法
4. 結論

12.
1. メトリクスの基礎

13.
http://e-words.jp/w/%E3%83%A1%E3%83%88%E3%83%AA%E3%82%AF%E3%82%B9.html
メトリクスとは何か？
13
ソフトウェア開発で、ソースコードの品質を
数値化して定量的に評価することや、
その際の評価手法や基準などの体系のことを
「ソフトウェアメトリクス」という。
写真：アフロ

14.
メトリクスの具体例 (1)
14
機能追加・修正頻度 割り込み率
残タスク数 タスクの完了率
バグの件数 デグレの頻度
テストの実行時間 テスト網羅率

15.
メトリクスの具体例 (2)
15

16.
理論的背景
16
Empirical Software Engineering
（経験的ソフトウェア工学）
• 2005年頃に興った学問。
• メールの件名・宛先などから、
メトリクスの取得を行う。
写真：アフロ

17.
「経験的」とは？
17
仮説設定と検証を繰り返すことにより、
課題と改善策を自力で徐々に見つけていくこと
を指す。
経験主義とは、すなわち仮説検証と改善である。
アジャイルやスクラムは、
この経験主義的アプローチの側面が強い。
• リーンスタートアップも、これに該当する。

18.
18
測定できないもの
は制御できない。
by トム・デマルコ

19.
この章のポイント
19
メトリクスには、
仮説検証に基づく経験主義的な行動を促し、
結果として自律的成長や協働を引き出す
という効果がある。
写真：アフロ

20.
2. POにとって
必要なメトリクス

21.
前章の振り返り
21
メトリクスには、
仮説検証に基づく経験主義的な行動を促し、
結果として自律的成長や協働を引き出す
という効果がある。
POという役割に照らし合わせてみると、
これらの要素が当てはまるのはどこか？

22.
考慮すべき要素
22
• POの目的
• ステークホルダー
マネジメント

23.
23
POの目的とは
何か？

24.
思いつきベースの目的候補
24
• 価値のあるプロダクトを作り、
ユーザに届けること？
• 多くの機能を提供すること？
• 多くのフィードバックを得ること？
• サイクルタイムを短くすること？
写真：アフロ

25.
プロダクトオーナーの定義
25
プロダクトオーナーは、
開発チームの作業と
プロダクトの価値の最大化
に責任を持つ。
（『スクラムガイド』5ページ）
http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-
Guide-Japanese.pdf

26.
考えるべきは次の2点
26
• 開発チームの作業
• プロダクトの価値

27.
メトリクスの種類
27
• プロセスメトリクス
• プロダクトメトリクス
野中『「精密に誤るよりも、漠然と正しくありたい」ためのソフトウェアメトリクス活用法』SQiP2016

28.
プロセスメトリクス
28
開発作業などのプロセスから
取得するメトリクス
【具体的な計測対象】
• 時間
• 工数
• イベント（開発中のバグ発見数など）

29.
プロダクトメトリクス
29
プロダクトそのものから
取得するメトリクス
【具体例】
• プロダクトの改修のしやすさ
• プロダクトのバグの量（品質）
• プロダクトが提供できる「体験」

30.
取得すべきメトリクス
30
• 開発チームの作業：プロセスメトリクス
• プロダクトの価値：プロダクトメトリクス
写真：ア
フロ

31.
（参考）チームとメトリクス
31
メトリクスを計測している組織は、
測定していない組織よりも
自己評価が高いことが裏付けられている。
写真：アフロ
野中『「精密に誤るよりも、漠然と正しくありたい」ためのソフトウェアメトリクス活用法』SQiP2016

32.
（参考）UXとメトリクス
32
ITエンジニアがUXデザインを実践する
コツと心構え
https://codezine.jp/article/detail/9690
• より良い体験を考慮した、プロダクトの
仮説検証の仕組みとしてのメトリクス
• POのPBL作りに活用できる

33.
プロダクト開発を成功に導くこと
33
• プロダクトの仮説検証
• プロダクトの継続的成長
• プロダクトの停止判断

34.
34
ステークホルダー
マネジメント

35.
ステークホルダーをめぐる課題
35
• 必要な時に、必要な意思決定が得られない
• そもそも必要な時に話せない
• プロダクト開発に協力してくれない
• プロダクト開発に横槍を入れてくる
写真：アフロ

36.
36
プロダクト開発を成功させるためには、
ステークホルダーマネジメントは非常に重要。
そこでメトリクスが役に立つ。

37.
ステークホルダーとメトリクス(1)
37
ステークホルダーが欲する情報を
提供しやすくなる
• プロダクトの価値を知ることができる。
• チーム・プロダクトに求めているものを
知ることができる。
• 結果として、マネジメントの観点を
持つことができるようになる。
• 自分たちを評価してもらう方法がわかる。
• メトリクスに関する勘が強くなる。

38.
ステークホルダーとメトリクス(2)
38
協力の取り付けが容易になる
• ステークホルダーにとっては、現場の状況が分
からない／感覚的に分かっているけれども手を
打てないというケースが多い。
• だからこそ、数値を提示し、
数値に基づいて合意を得る。
• データがあると、話が早い。
• そうした合意に基づくアクションを
継続することで、さらに協力的になる。

39.
ステークホルダーとメトリクス(3)
39
ステークホルダーとプロダクト開発チームの
距離を縮められる／目的を一致させられる。
結果として、
ステークホルダーとの協働が容易になる。

40.
この章のポイント
40
POの役割のプラスになるものであること
• プロダクトの仮説検証・継続的成長
（・停止判断）に役立つものであること
• チームの継続的成長に役立つものであること
• ステークホルダーとの協働に役立つもので
あること
⭐️プロセスメトリクス／プロダクトメトリクス
を、意識して使い分けること

41.
3. メトリクスの
実践的活用法

42.
考慮すべき要素
42
• 取得のポイント
• 活用のポイント
• 参考事例

43.
43
取得のポイント

44.
基本：事実をベースとする
44
野中『「精密に誤るよりも、漠然と正しくありたい」ためのソフトウェアメトリクス活用法』SQiP2016
写真：アフロ

45.
基本メトリクスと導出メトリクス(1)
45
導出メトリクス：
複数の基本メトリクスを組み合わせたもの
基本メトリクスのみでは、
有益な情報を得られないことが多い。
複数の基本メトリクスを組み合わせることで、
本当の課題に焦点を当てる。
野中『「精密に誤るよりも、漠然と正しくありたい」ためのソフトウェアメトリクス活用法』SQiP2016

46.
基本メトリクスと導出メトリクス(2)
46
（例）リリースした機能数
機能数にどのような意味・効果があるのか？
以下のような指標も合わせて取得・分析する。
• 機能ごとの利用者数
• 機能ごとの売り上げ
• 新規利用者の増加数

47.
「厳密性」よりも「有用性」を
47
「精密に誤るよりも、漠然と正しくありたい」
“I’d rather be vaguely right than precisely wrong.”
by ジョン・メイナード・ケインズ
メトリクスが事実に基づいている必要はあるが
厳密である必要はない。
→ 意思決定の役に立つ、
「漠然と正しい」情報を集めているか？
野中『「精密に誤るよりも、漠然と正しくありたい」ためのソフトウェアメトリクス活用法』SQiP2016

48.
48
活用のポイント

49.
ポイント
49
• 考えることのプラスになる情報を得る。
• 現状の問題はどこにあるのか？
• 改善施策の成果はどうだったか？
• 数値の変化に意味を見い出す。
• 変化が見える情報であれば、
役に立ちうるということ。
• データをもとに、アクションを考える。
• データがあると、話が早い。
• 特に自分たちのデータとなると、
より効果がある。

50.
適切なものがなければ創ろう
50
基本的に仮説検証に活用するため、
従来にないものを創造して使うことが多くなる。
写真：アフロ

51.
「時間」を絡めて考えてみよう
51
• 「回転率」など、生産管理の考え方に近い
情報を出せるようになる。
• 経営層には、生産管理の話が通じやすいので、
結果として協力を得て施策を進めやすくなる。
写真：アフロ

52.
注意：プロダクト間比較は難しい
52
メトリクスは、
プロダクト固有の数値になりがち。
• そもそもプロダクトが異なるため、
単純比較には意味がない。
• 一方で、「相対比較」を用いる余地は
出てくるだろう。

53.
メトリクスの取得・活用手順
53
• メトリクスを仕込む。
• 数値の変化から、問題を見つける。
• メトリクスをもとに、アクションを取る。
• アクションを取った後の数値の変化を見る。
• 上記を繰り返す。
写真：アフロ

54.
54
参考事例

55.
リリースした機能数を計測してみる
55
0
1
2
3
4
5
6
7
8
9
10
SP1 SP2 SP3 SP4 SP5 SP6 SP7 SP8
リリースした機能数
リリースした機能数

56.
リリースした機能数を計測してみる
56
0
1
2
3
4
5
6
7
8
9
10
SP1 SP2 SP3 SP4 SP5 SP6 SP7 SP8
リリースした機能数
リリースした機能数
多い時と
少ない時が
ある
何か問題が
起きた？

57.
多く機能をリリースできた時を基準として、
スプリントでリリースする機能数を
増やしてみた。
アクション
57
写真：アフロ

58.
起こり得ること（予想される失敗）
58
• リリース機能数が目標に達しない
• そもそもリリースに失敗する
• リリースした機能にバグが多い
• リリースした機能が使われない
写真：アフロ

59.
考えてみよう
59
そもそもなぜリリース機能数に差が出るのか？
• リリースする機能の重要度が高く、
より品質に重点を置いたため？
• そもそもユーザーに使われない機能を
多くリリースしたため？
• チームが成長して、リリースの仕方が
上手になったため？

60.
メトリクスの改善
60
導出メトリクスを適用して、
数値の変化を深く探る。
• 機能ごとの利用者数
• そもそも利用されているか？
• 機能ごとの売り上げ
• その機能が価値を生み出しているか？
• 新規利用者の増加数
• そのリリースが価値あるものだったか？

61.
次のアクション
61
数値の変化に基づいて、アクションを取る。
• 売り上げの高い機能をさらに拡充する。
• 利用者の多い機能から、
少ない機能への導線を張ってみる。
• 利用者の少ない機能を削除する。
写真：アフロ

62.
アクションの後の数値の変化を見る
62
• 機能拡充で、売り上げは伸びたか？
• 導線を張ることで、利用者は増えたか？
• 機能削除で、利用者から
クレームは出ていないか？
写真：アフロ

63.
（参考）メトリクス候補
63
PV・UU 顧客満足度
リリースした機能数 サイクルタイム
リードタイム スループット

64.
（参考）要求分析のメトリクス
64
作業の割り込み率
変更要望の数と比率
受け容れた変更要望の数と比率
※後出し要求の方が重要なことが多い

65.
（参考）DevOpsのメトリクス
65
開発・CI QA デプロイ リリース 運用
開発の
リード・タイム
非稼働時間
デプロイの
リード・タイム
リリース頻度 MTTR
欠陥・ビルド失敗・シス
テムダウンに
伴う再作業
検出・見逃した欠陥の
割合、および
欠陥の影響度合い
デプロイ頻度と
かかる時間
リリース毎の
時間とコストの割合
システムダウン時の
コストと頻度の割合
非稼働時間
MTTD
(検知にかかる時間)
（システム）変更の
成功率
（リリース成功の）
予測可能性
営業時間後の
緊急呼び出しの頻度
進行中の作業と
技術負債
MTTR
性能と利用時間の
割合
サイクル・タイム
Wallgren Anders, Measuring DevOps: the Key Metrics that Matter, Agile2016

66.
この章のポイント
66
• 事実に基づいていることは必要だが、
厳密である必要はない。
• 意思決定の役に立つ、「漠然と正しい」情報
を集めているかが重要。
• 数値の変化に意味を見い出し、
アクションを起こそう。
• データがあると、話が早い。
• 事例をベースに、自分たちにふさわしい
メトリクスを見つけて活用しよう。

67.
4. 結論

68.
68
ふりかえり

69.
69
アジャイルの文脈において、
メトリクスの取得・活用は、
もはや一般的なことと
なりつつある。
メトリクスに関する昨今の傾向

70.
1. メトリクスの基礎
70
メトリクスには、
仮説検証に基づく経験主義的な行動を促し、
結果として自律的成長や協働を引き出す
という効果がある。
写真：アフロ

71.
2. POにとって必要なメトリクス
71
POの役割のプラスになるものであること
• プロダクトの仮説検証・継続的成長
（・停止判断）に役立つものであること
• チームの継続的成長に役立つものであること
• ステークホルダーとの協働に役立つもので
あること

72.
3. メトリクスの実践的活用法
72
• 事実に基づいていることは必要だが、
厳密である必要はない。
• 意思決定の役に立つ、「漠然と正しい」情報
を集めているかが重要。
• 数値の変化に意味を見い出し、
アクションを起こそう。
• データがあると、話が早い。
• 事例をベースに、自分たちにふさわしい
メトリクスを見つけて活用しよう。

73.
73
ポイント

74.
メトリクスと「価値」
74
• 市場が望む価値を知ろう！
• ユーザに価値を提供しよう！
• 自分たちを評価させよう！
写真：アフロ

75.
メトリクスの使い分け
75
• 開発チームの作業：プロセスメトリクス
• プロダクトの価値：プロダクトメトリクス
写真：ア
フロ

76.
メトリクスの原則
76
• 計測するものはゴールに直結すべき
• ゴールにつなげる戦略を導き出す道具
• 会話を促すものであるべき
• 行動につながるものであるべき
• 計測するものは少なくすべき
• チーム・プロダクトを成長させる方向を
見つけるために使用すべき

77.
あなたのPO道具箱にメトリクスを
77
写真：アフロ