Slide 1
Slide 1 text
チームのアジリティを上げよう！
否、〇〇を上げよう！
開発生産性の可視化に取り組んでみて
わかったこと、わからないこと
2023/09/16 スクラムフェス三河
Slide 2
Slide 2 text
2
● Hiroki Inoue
● Software Engineer
● Engineering Manager @ WHITEPLUS, Inc.
About Me
Slide 3
Slide 3 text
3
1. 開発生産性の可視化に取り組むか検討している方
2. 開発生産性の可視化の運用を試行錯誤している方
3. 開発生産性の可視化に悩めるチームを手助けし、エンジニアリングプロセスの発展に関わりたい方
Target Audience
Slide 4
Slide 4 text
4
アジェンダ
はじめに
開発生産性の可視化を始める前に考えていたこと
01
02
試行錯誤してきたこと
試行錯誤してきた中でわかったこと
03
04
わからないこと
05
今後のこと
06
Slide 5
Slide 5 text
5
はじめに
Slide 6
Slide 6 text
6
私たちは数カ月前から、開発生産性を可視化し、得られたフィードバックからシステム開発プロセス等
を見直す運用をスクラムにインストールし、試行錯誤してきました。当初持っていた期待、課題感は以
下のようなものでした。
● プロダクト、事業の成長速度を上げたい。
そのために開発生産性ののび代、ボトルネックが知りたい。
● 開発プロセスに対する漠然とした不安。
○ 雰囲気でスプリント振り返りをしてしまってないか。
○ 雰囲気でマネジメントしてしまってないか。
○ 実際のところうまくいっているのか、うまくいっていないのか。
● エンジニアの内省を支援したい。
背景
Slide 7
Slide 7 text
7
取り組みを始める前、様々な疑問がありましたが、しばらく取り組んできた結果今では、生産性可視化
の正解や普遍的な方法論が必ずしもあるわけではなく各社が各々のコンテクストにおける最適解を模索
しているように感じています。私は書籍や勉強会から他社の取り組みに学びつつ、自身のチームでも試
行してきました。
背景
Slide 8
Slide 8 text
8
私たちの取り組みには以下のような前提があります。
● スクラムで開発を行っている。
● 計測、評価、改善活動は5名程度のチームごとに行っている。
● 経営層からのトップダウンではなくて、エンジニア組織からのボトムアップでスタートした。
● 開発生産性の向上を主導するチームがあるのではなく、開発チーム内で行っている。
○ 可視化を主導するのはEMの役割の一つ。
○ 数値を見るだけでなく開発プロセスに参加し、定性的な情報も体感している。
○ 数値はチームの皆が見る。
○ 改善活動はチームで、あるいはエンジニア組織全体で実行する。
前提
Slide 9
Slide 9 text
9
以上を踏まえ、開発生産性の可視化及び改善活動を通じてわかったこと、わからないことを整理し、
チームの学びを共有します。
セッションの概要
Learn and Grow by Team：チームの学びと成長 Beginner 20 Mins
Slide 10
Slide 10 text
10
開発生産性の可視化を
始める前に考えていたこと
Slide 11
Slide 11 text
11
● 開発生産性を定量的に計測することに意味はあるのか
● あるとすればどのような意味があるのか
● 何を計測し
● どのように評価し
● そこからどのような発見を抽出できるのか
疑問
Slide 12
Slide 12 text
12
ってかそもそもの話...
生産性って何！？
疑問
Slide 13
Slide 13 text
13
まずもって単位がわからず掴みどころがない…
疑問
Slide 14
Slide 14 text
14
まずもって単位がわからず掴みどころがない…
⇨生産性可視化を推進した私自身がそれに対して懐疑的だった。
疑問
Slide 15
Slide 15 text
15
試行錯誤してきたこと
Slide 16
Slide 16 text
16
開発生産性を定量的に計測することに意味はあるのか
Slide 17
Slide 17 text
17
わからん。
開発生産性を定量的に計測することに意味はあるのか
Slide 18
Slide 18 text
18
わからん。
ならば、やってみよう。
開発生産性を定量的に計測することに意味はあるのか
Slide 19
Slide 19 text
19
何を計測すべきか
Slide 20
Slide 20 text
20
わからん。。
何を計測すべきか
Slide 21
Slide 21 text
21
ならば、調べてみよう。
何を計測すべきか
Slide 22
Slide 22 text
22
● ドキュメントにあたる
○ Accelerate
● 勉強会に参加する
情報収集
Slide 23
Slide 23 text
23
Four Keys[1]で始めてみよう。
何を計測すべきか
1. デプロイの頻度, 変更のリードタイム, 変更障害率, サービス復元時間。State of DevOps 2021では運用パフォーマンス指標である「信頼
性」が5つめのメトリクスとして追加された。
Slide 24
Slide 24 text
24
● GitHubやJira等を利用して開発するのが一般的。
● そこには開発に関する情報が蓄積されている。
● GitHubやJiraから情報を取得できる。
どのように計測するのか
Slide 25
Slide 25 text
25
● 分析ツールを自作する。
● Saasを利用する。
どのように計測するのか
Slide 26
Slide 26 text
26
● 分析ツールを自作する。
● Saasを利用する。
Findy Team+
Offers MGR
どのように計測するのか
Slide 27
Slide 27 text
27
● Four Keysすべてを追いかけない。
● ガチガチに目標を固め過ぎない。
スモールスタート
Slide 28
Slide 28 text
28
● デプロイの頻度 ← 変更のリードタイムへの依存関係がありそう
● 変更のリードタイム ← 更に分解できる
● 変更障害率 ← 課題感がないのでスコープアウト
● サービス復元時間 ← 課題感がないのでスコープアウト
スモールスタート
Slide 29
Slide 29 text
29
● デプロイの頻度 ← 変更のリードタイムへの依存関係がありそう
● 変更のリードタイム ← 更に分解できる
○ 開発する
○ レビューする ← ここからやってみよう
○ 修正を完了する
○ マージする
● 変更障害率 ← 課題感がないのでスコープアウト
● サービス復元時間 ← 課題感がないのでスコープアウト
スモールスタート
Slide 30
Slide 30 text
30
● レビューの早さについては最初から具体的目標を持ち、その他は観察することからはじめた。
● 徐々に見る観点を増やした。
○ レビューの早さ、修正の早さ、開発の早さ、PRサイズ、アクティビティ量、デプロイ頻度...
スモールスタート
Slide 31
Slide 31 text
31
レビューを早くするためにレビュイーとレビュアーがすべきことを啓蒙
● レビュアーはレビューを優先的に行う。
● レビューしやすいPRを作る。
● ガイドラインを参考にする。
いかにして早めるか？を言語化する
Slide 32
Slide 32 text
レビューを早くするためにレビュイーとレビュアーがすべきことを啓蒙
● レビューに至るまでのコミュニケーション
○ 要所を相談してから進める。
○ モブ設計により大きな認識のズレを無くしておく。
○ レビューをスムーズにする前提知識を事前に周知する。
● レビューにおけるコミュニケーション
○ 指摘のトーンや背景を伝える。
○ 参考資料やサンプルコードを示す。
○ 適宜口頭で説明する。
32
いかにして早めるか？を言語化する
Slide 33
Slide 33 text
33
チームとして学びを蓄積するため、スクラムイベントに組み込む。
● スプリントレトロスペクティブの前に計測値を確認する。
● 推奨するプラクティスも繰り返し確認し、意識に浸透させる。
スクラムイベントに組み込む
Slide 34
Slide 34 text
34
1on1でも活用する。
スクラムイベントに組み込む
Slide 35
Slide 35 text
35
レビューの着手が早くなった。
みんな偉い👏
しばらく試してみると…
Slide 36
Slide 36 text
36
レビューの着手が早くなった。
みんな偉い👏
そして修正を完了するまでの（レビュー〜アプルーブまでの）時間等にも目を向け始める。
しばらく試してみると…
Slide 37
Slide 37 text
37
● デプロイの頻度
● 変更のリードタイム
○ 開発する ← ここもやってみよう
○ レビューする ← ここからやってみよう
○ 修正を完了する ← ここもやってみよう
○ マージする
● 変更障害率
● サービス復元時間
次のステップ
Slide 38
Slide 38 text
38
PRサイズを小さくしよう。
次のステップ
Slide 39
Slide 39 text
39
PRサイズを小さくしよう。
言うだけでは変化は起きず…
PRサイズを小さくする
Slide 40
Slide 40 text
40
PRサイズを小さくしよう。
言うだけでは変化は起きず…
それではと、具体的な方法を示した。
● 1つのPRに含む変更意図は1つにする。
○ リファクタ、不具合修正、フィーチャーのような単位で分ける。
● フィーチャーは更に分解できる。例えば、レイヤー毎に分ける。
○ モブ設計と併用することで手戻りを防ぐ。
● 変更行数200～400, ファイル数10を目安に分割する。
○ （正直なところ手応えなし）
● Reactのコンポーネント単位、削除ならエンドポイント単位など
PRサイズを小さくする
Slide 41
Slide 41 text
41
PRサイズを小さくしよう。
言うだけでは変化は起きず…
それではと、具体的な方法を示した。
それでも大きな変化を感じることはできず…
PRサイズを小さくする
Slide 42
Slide 42 text
42
PRサイズを小さくしよう。
言うだけでは変化は起きず…
それではと、具体的な方法を示した。
それでも大きな変化を感じることはできず…
レビュアーとして辛さを感じるPRサイズをヒアリングした。（自分事化）
PRサイズを小さくする
Slide 43
Slide 43 text
43
PRサイズを小さくしよう。
言うだけでは変化は起きず…
それではと、具体的な方法を示した。
それでも大きな変化を感じることはできず…
レビュアーとして辛さを感じるPRサイズをヒアリングした。（自分事化）
慣性を少し強めた。
● レビューで指摘する。
● 具体的な目標値を設定する。
● スプリント振り返りで話す。
PRサイズを小さくする
Slide 44
Slide 44 text
44
注意事項
● レビューの数が増える。
○ レビューを早く行うこととセットで取り組まないと結局詰まる。
PRサイズを小さくする
Slide 45
Slide 45 text
45
注意事項
● レビューの数が増える。
○ レビューを早く行うこととセットで取り組まないと結局詰まる。
● PRを細かく分けると全体が見えにくくなる。
○ 最初に設計しておくとスムーズ。
PRサイズを小さくする
Slide 46
Slide 46 text
46
注意事項
● レビューの数が増える。
○ レビューを早く行うこととセットで取り組まないと結局詰まる。
● PRを細かく分けると全体が見えにくくなる。
○ 最初に設計しておくとスムーズ。
● PRサイズの目安（例えば、変更行数200～400）が自組織に当てはまるか評価すべき。
○ 弊チームの場合、行数よりもむしろファイル数を気にする声が多かった。
○ 適正サイズは恐らくコンテクスト（言語、アーキテクチャ etc.）に依存する。
PRサイズを小さくする
Slide 47
Slide 47 text
47
● ガイドライン
● 雛形
● ADR
● ペアプロ
● オンデマンドの支援
開発における迷いを減らす
Slide 48
Slide 48 text
48
レビューの分担を調整する
● ナレッジ共有の役割を終えたレビュアーをアンアサイン
● ボトルネックなっているレビュアーの業務調整やアンアサイン
● レビュアーの分散化
品質保証
ナレッジ
共有
Slide 49
Slide 49 text
49
● 数値の差異がディスカッションの契機になる。
● 他チームを観察し、プラクティスを取り入れる。
チーム間交流
Slide 50
Slide 50 text
50
ところで
Slide 51
Slide 51 text
51
● 環境
○ 開発プロセス
○ 既存システムの保守性
○ 開発・運用環境[1]
○ 開発外業務[2]の多寡
● 人
○ ドメイン知識
○ 技術力
○ モチベーション
生産性に影響を与える要素
1. CI/CD、型付け、静的解析、フィーチャートグル、ChatOps、オブザーバビリティといった類の話。
2. コードの生成に直接的につながらない業務。間接業務、見積り、照会、障害対応等。
Slide 52
Slide 52 text
52
● 環境
○ 開発プロセス
○ 既存システムの保守性
○ 開発・運用環境
○ 開発外業務の多寡
● 人
○ ドメイン知識
○ 技術力
○ モチベーション
生産性に影響を与える要素
Slide 53
Slide 53 text
53
● 環境
○ 開発プロセス
○ 既存システムの保守性
○ 開発・運用環境
○ 開発外業務の多寡
● 人
○ ドメイン知識
○ 技術力
○ モチベーション
生産性に影響を与える要素
Slide 54
Slide 54 text
54
● 不要コードの削除
● リファクタリング
● DDDによる整理
● 静的解析の更なる活用（レベル上げ、カスタムルール、ツール追加）
保守性を高める
Slide 55
Slide 55 text
55
● GitHub Copilot導入
● ChatGPT導入
● ビルド時間の短縮
● 循環的複雑度の計測
開発・運用環境を改善する
Slide 56
Slide 56 text
56
● ドキュメントやツールに働かせる。
● 業務の交通整理を行う。
● 設計（障害耐性、復旧容易性、理解容易性）改善を目指す。
● 開発外業務の多くをEMが巻き取りつつ、一部負荷を平準化しつつメンバーに渡す。
開発外業務をスリムにする
Slide 57
Slide 57 text
57
● 現場見学
● インプット、アウトプットの機会提供
● ナレッジ共有の機会提供
● ペア・モブプロ（設計）
● レビュー
● ディスカッション
● 勉強会
● ドキュメント整備
人を支援する
Slide 58
Slide 58 text
58
試行錯誤してきた中で
わかったこと
Slide 59
Slide 59 text
59
生産性とはなんなのか
3つのレベルで生産性を捉えるという考え方がある。[1]
1. 仕事量の生産性
2. 期待付加価値の生産性
3. 実現付加価値の生産性
1. 大規模言語モデル時代の開発生産性（hirokidaichi）
Slide 60
Slide 60 text
60
生産性とはなんなのか
仕事量の生産性を言い換えると、”開発の成果物を作る能力”と解釈。
1. 仕事量の生産性
2. 期待付加価値の生産性
3. 実現付加価値の生産性
Slide 61
Slide 61 text
61
生産性とはなんなのか
仕事量の生産性を言い換えると、”開発の成果物を作る能力”と解釈。
“開発の成果物”とは”動くシステム”と言えそう。
Slide 62
Slide 62 text
62
生産性とはなんなのか
仕事量の生産性を言い換えると、”開発の成果物を作る能力”と解釈。
“開発の成果物”とは”動くシステム”と言えそう。
“仕事量”とは”動くシステムの量”と言えそう。
Slide 63
Slide 63 text
63
生産性とはなんなのか
仕事量の生産性を言い換えると、”開発の成果物を作る能力”と解釈。
“開発の成果物”とは”動くシステム”と言えそう。
“仕事量”とは”動くシステムの量”と言えそう。
“仕事量の生産性”とは”動くシステムの量やそれを作るのにかかる時間の多寡”と考えられそう。
Slide 64
Slide 64 text
64
生産性とはなんなのか
仕事量の生産性を言い換えると、”開発の成果物を作る能力”と解釈。
“開発の成果物”とは”動くシステム”と言えそう。
“仕事量”とは”動くシステムの量”と言えそう。
“仕事量の生産性”とは”動くシステムの量やそれを作るのにかかる時間の多寡”と考えられそう。
ではそれをどう測るのか？
Slide 65
Slide 65 text
65
生産性とはなんなのか
仕事量の生産性を言い換えると、”開発の成果物を作る能力”と解釈。
“開発の成果物”とは”動くシステム”と言えそう。
“仕事量”とは”動くシステムの量”と言えそう。
“仕事量の生産性”とは”動くシステムの量やそれを作るのにかかる時間の多寡”と考えられそう。
ではそれをどう測るのか？
重さ、長さ、速さ、体積の様に何らかの単位で括って認識する必要がある。
Slide 66
Slide 66 text
66
生産性とはなんなのか
仕事量の生産性を言い換えると、”開発の成果物を作る能力”と解釈。
“開発の成果物”とは”動くシステム”と言えそう。
“仕事量”とは”動くシステムの量”と言えそう。
“仕事量の生産性”とは”動くシステムの量やそれを作るのにかかる時間の多寡”と考えられそう。
ではそれをどう測るのか？
重さ、長さ、速さ、体積の様に何らかの単位で括って認識する必要がある。
そこで現状広く認知されているのがFour Keysという考え方。
Slide 67
Slide 67 text
67
生産性とはなんなのか
仕事量の生産性を言い換えると、”開発の成果物を作る能力”と解釈。
“開発の成果物”とは”動くシステム”と言えそう。
“仕事量”とは”動くシステムの量”と言えそう。
“仕事量の生産性”とは”動くシステムの量やそれを作るのにかかる時間の多寡”と考えられそう。
ではそれをどう測るのか？
重さ、長さ、速さ、体積の様に何らかの単位で括って認識する必要がある。
そこで現状広く認知されているのがFour Keysという考え方。
Four Keysが良好であることを以って生産性が高いとみなしましょうという合意が広まっている。
Slide 68
Slide 68 text
68
生産性とはなんなのか
1. https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
Four Keys[1]
● デプロイの頻度 … 組織による正常な本番環境へのリリースの頻度
● 変更のリードタイム … commit から本番環境稼働までの所要時間
● 変更障害率 … デプロイが原因で本番環境で障害が発生する割合（%）
● サービス復元時間 … 組織が本番環境での障害から回復するのにかかる時間
Slide 69
Slide 69 text
69
生産性とはなんなのか
Four Keysが含意するものに差異がありうる。例えば、
● デプロイの頻度 … 計測の都合によるカウント方法の差異
● 変更のリードタイム … commitするタイミングの差異
… 計算方法の差異
… PRの難易度の差異
… 製品特性による開発プロセスの差異
Slide 70
Slide 70 text
70
生産性とはなんなのか
Four Keysが含意するものに差異がありうる。例えば、
● デプロイの頻度 … 計測の都合によるカウント方法の差異
● 変更のリードタイム … commitするタイミングの差異
… 計算方法の差異
… PRの難易度の差異
… 製品特性による開発プロセスの差異
⇒比較したい場合コンテクストの違いに注意する必要がある。
Slide 71
Slide 71 text
71
生産性とはなんなのか
合意の産物である。
Slide 72
Slide 72 text
72
生産性とはなんなのか
（ある一面において）合意の産物である。
Slide 73
Slide 73 text
73
Four Keysの外にあるもの
● PRに反映されないタスク
○ ドキュメント作成
○ 技術検証
○ ルールやガイドライン整備
○ 勉強会
○ 採用
○ 技術広報
など
● 前述したレベル2, 3の生産性
Slide 74
Slide 74 text
74
高まった。
● レビューの早さ⤴
● 変更のリードタイム⤴（短縮された）
● デプロイ頻度⤴
開発生産性は高まったのか
Slide 75
Slide 75 text
高まった。
● レビューの早さ⤴
● 変更のリードタイム⤴（短縮された）
● デプロイ頻度⤴
一方で、即効性のある打ち手が少なそうであることもわかってきた。
75
開発生産性は高まったのか
Slide 76
Slide 76 text
76
● 数値を踏まえて振り返りや1on1を行うようになった。
○ 変更のリードタイムが長引いた要因を、工程の内訳を踏まえて振り返れた。
● 体感の答え合わせができる。
○ レビューを迅速に行っている感覚があり、数値がそれを裏付けていた。
○ 新規参画者のパフォーマンスが右肩上がりなのを確認できた。
● 体感と異なることもあり、それが発見である。
○ 自覚していなかったがPRを小さくできる余地があった。
振り返りがどう変わったか
Slide 77
Slide 77 text
77
● 判断の手掛りが増えた。
● やったことに対して反応（変化の有無）を確認できる。
● 違いを認識できて、どんな違いがあるのかを探索する機会が得られる。
そこから発見があり、プロセス改善が進んだ。
マネジメント（意思決定）がどう変わったか
Slide 78
Slide 78 text
78
● うまくいっている。
○ 以前の私たちよりも進歩している。
● うまくいっていない。
○ まだ改善の余地がある。
実際のところうまくいっているのか、うまくいっていないのか
Slide 79
Slide 79 text
79
● うまくいっている。
○ 以前の私たちよりも進歩している。
● うまくいっていない。
○ まだ改善の余地がある。
開発プロセスは比較的改善を進めやすい。
それ以外の部分は、リソースが必要になる場合にハードルが上がる/時間を要する。
実際のところうまくいっているのか、うまくいっていないのか
Slide 80
Slide 80 text
80
● うまくいっている。
○ 以前の私たちよりも進歩している。
● うまくいっていない。
○ まだ改善の余地がある。
⇒うまくいっていないことを自覚できる。これが謂わばのび代。
実際のところうまくいっているのか、うまくいっていないのか
Slide 81
Slide 81 text
81
● うまくいっている。
○ 以前の私たちよりも進歩している。
● うまくいっていない。
○ まだ改善の余地がある。
ともかく、やったことに対して数値のフィードバックがあるので手応えを確認しやすくなった。
実際のところうまくいっているのか、うまくいっていないのか
Slide 82
Slide 82 text
82
● 数値が根拠となりフィードバックが受け入れられやすくなった。
● 自覚してないことに気づけるようになった。
● 裏付けがあることで、体感に自信が持てるようになった。
エンジニアの内省がどう変わったか
Slide 83
Slide 83 text
83
ある。
開発生産性を定量的に計測することに意味はあるのか
Slide 84
Slide 84 text
84
以下のようなことがやりやすくなる。
● ボトルネックの特定
● のびしろの切り分け
● 個人視点では自己診断、チーム視点では成長支援
● 変化の検知
どのような意味があるのか
Slide 85
Slide 85 text
85
以下のようなことがやりやすくなる。
● ボトルネックの特定
○ 開発、レビュー、修正、マージ
○ 開発外業務
どのような意味があるのか
Slide 86
Slide 86 text
1. 生産性に影響を与える要素
86
以下のようなことがやりやすくなる。
● のびしろの切り分け
○ 開発プロセス、保守性、開発・運用環境、開発外業務の多寡、人[1]
どのような意味があるのか
Slide 87
Slide 87 text
87
以下のようなことがやりやすくなる。
● 個人視点では自己診断、チーム視点では成長支援
○ うまくいったことを確認したり、失敗に気づける
○ 目標が立てやすい
○ 目標に近づいているのか否かを判断しやすい
○ 数値として見えることで自律的な改善の慣性が働く
どのような意味があるのか
Slide 88
Slide 88 text
88
以下のようなことがやりやすくなる。
● 変化の検知
○ なぜ変化したのかは改めて調べる必要がある点には注意が必要
どのような意味があるのか
Slide 89
Slide 89 text
89
また、副次的なものとして
● ベストプラクティスを探索する契機となる。
● 説得力が生まれる。
どのような意味があるのか
Slide 90
Slide 90 text
90
生産性可視化とは
組織のオブザーバビリティを高める試み
である
どのような意味があるのか
Slide 91
Slide 91 text
91
生産性を可視化するだけでは片手落ち。
環境の改善、人に対するエンパワメントを怠れば効果は得られない。
どのような意味があるのか
Slide 92
Slide 92 text
92
● デプロイの頻度 … 増やしたい
● 変更のリードタイム … 短縮したい
● 変更障害率 … 課題感がないのでスコープアウト
● サービス復元時間 … 課題感がないのでスコープアウト
どのように評価するか
Slide 93
Slide 93 text
93
● デプロイの頻度
● 変更のリードタイム
○ 開発する … 短縮したい
○ レビューする … 短縮したい
○ 修正を完了する … 短縮したい
○ マージする … 短縮したい
どのように評価するか
Slide 94
Slide 94 text
94
● デプロイの頻度
● 変更のリードタイム
○ 開発する … 短縮したい
○ レビューする … 短縮したい
○ 修正を完了する … 短縮したい
○ マージする … 短縮したい
⇒絶対値に囚われすぎないようにしている。
どのように評価するか
Slide 95
Slide 95 text
95
● デプロイの頻度
● 変更のリードタイム … ☟長期化する要因例
○ 開発する … 担当者のスキル、要件の精度、システムの理解容易性、影響範囲
○ レビューする … 意識・習慣（仕事の優先順位づけ）、業務量、レビューしやすさ
○ 修正を完了する … 開発する同様の要因＋認識違い、指摘の流儀、レビュアー数
○ マージする … デプロイの仕組み、デプロイを阻む要素、QA体制
⇒長期化した要因を探り対策をうつ。
どのように評価するか
Slide 96
Slide 96 text
96
参考値としてPRサイズやPR数なども確認する。
どのように評価するか
Slide 97
Slide 97 text
97
PRに反映されない業務量も考慮したい。
どのように評価するか
Slide 98
Slide 98 text
98
考え方の一例
● 自チームの過去と現在の比較
○ 何をきっかけに変化が起きたのか。
○ ネガティブイベントの再発を抑え、ポジティブイベントの再現性を高めたい。
● 他チームと自チームの比較
○ 真似できる何かを探索する。
どのように評価するか
Slide 99
Slide 99 text
99
考え方の一例
● チームやチーム内の他者と自分の比較
○ 環境の課題と個人の課題を切り分ける。
○ 真似できる何かを探索する。
○ 得意、不得意を把握する。
どのように評価するか
Slide 100
Slide 100 text
100
● 違うということ
● 変化したということ
● 変化してないということ
そこからどのような発見を抽出できるのか
Slide 101
Slide 101 text
101
● 違うということ
● 変化したということ
● 変化してないということ
そこからどのような発見を抽出できるのか
Slide 102
Slide 102 text
102
● 違うということ
○ 私たちのチームは彼女/彼らのチームと何かが違う。
● 変化したということ
● 変化してないということ
そこからどのような発見を抽出できるのか
Slide 103
Slide 103 text
103
● 違うということ
○ 私たちのチームは彼女/彼らのチームと何かが違う。
● 変化したということ
○ 今の私たちは過去の私たちと何かが違う。
そこからどのような発見を抽出できるのか
Slide 104
Slide 104 text
104
● 違うということ
○ 私たちのチームは彼女/彼らのチームと何かが違う。
● 変化したということ
○ 今の私たちは過去の私たちと何かが違う。
⇨その”何か”が何なのかを探索することこそが重要。
そこからどのような発見を抽出できるのか
Slide 105
Slide 105 text
105
● 違うということ
○ 私たちのチームは彼女/彼らのチームと何かが違う。
● 変化したということ
○ 今の私たちは過去の私たちと何かが違う。
● 変化してないということ
○ このケースは注意が必要。
そこからどのような発見を抽出できるのか
Slide 106
Slide 106 text
106
● 違うということ
○ 私たちのチームは彼女/彼らのチームと何かが違う。
● 変化したということ
○ 今の私たちは過去の私たちと何かが違う。
● 変化してないということ
○ このケースは注意が必要。
○ 今の私たちは過去の私たちと、一見、何も変わらない。
そこからどのような発見を抽出できるのか
Slide 107
Slide 107 text
107
● 違うということ
○ 私たちのチームは彼女/彼らのチームと何かが違う。
● 変化したということ
○ 今の私たちは過去の私たちと何かが違う。
● 変化してないということ
○ このケースは注意が必要。
○ 今の私たちは過去の私たちと、一見、何も変わらない。
⇨何も変わらない？本当に？
そこからどのような発見を抽出できるのか
Slide 108
Slide 108 text
108
● グラフに表れない何か（コンテクスト）が変化してないか？
○ メンバー数
○ 稼働日数
○ 開発外業務量（PRに反映されないアクティビティ量）
○ 難易度
○ 新規、改修（しがらみや車輪の有無）
○ 技術スタック
など
● ポジティブな変化とネガティブな変化が相殺した結果なのではないか？
そこからどのような発見を抽出できるのか
Slide 109
Slide 109 text
109
● グラフに表れない何か（コンテクスト）が変化してないか？
⇨その”何か”が何なのかを探索することこそが重要。
そこからどのような発見を抽出できるのか
Slide 110
Slide 110 text
110
注目すべきは”違い”や”変化”
● 起きるべきタイミングで期待された変化が起きたか。
● 想定外の変化が起きていないか。
● 他チームや他社との単純比較に価値はなく、違いからコンテクストの差異を読み取ろうとする行為
には意義がありそう。
そこからどのような発見を抽出できるのか
Slide 111
Slide 111 text
111
”違い”や”変化”がない場合であっても
ネガティブとポジティブが相殺した結果かもしれないので、コンテクストの違い/変化を点検する。
そこからどのような発見を抽出できるのか
Slide 112
Slide 112 text
112
“解像度”を上げよう！
● “アジリティ”や”生産性”という言葉には解像度を高める余地がある。
〇〇を上げよう！
Slide 113
Slide 113 text
113
“解像度”を上げよう！
● “アジリティ”や”生産性”という言葉には解像度を高める余地がある。
● デプロイ頻度？変更のリードタイム？変更障害率？平均修復時間？
○ コミットからオープンまでの時間？オープンからレビューまでの時間？レビューからアプ
ルーブまでの時間？アプルーブからマージまでの平均時間？
● あるいは、その他？
〇〇を上げよう！
Slide 114
Slide 114 text
114
“DX（開発者体験）”を上げよう！
● DXを改善すると生産性も高まるという考え方がある。
〇〇を上げよう！
Slide 115
Slide 115 text
115
“モチベーション”を上げよう！
● モチベーションを上げることで開発がスムーズにいくならば、それに取り組むべき。
〇〇を上げよう！
Slide 116
Slide 116 text
116
生産性を上げよう！とただ思っても何をすればよいのかわからない。
生産性とは何か？
それを向上させる要因は何なのか？
を定義、特定する必要がある。
〇〇を上げよう！
Slide 117
Slide 117 text
117
チームのアジリティを上げよう！否！！！
“生産性”は上げるものではなく、上がるもの。（個人的な見解です）
放っておいたら勝手にあがるってことではなくて、環境を整えられれば自然と上がる。
課題を潰すと結果として生産性が上がるという感覚。
Slide 118
Slide 118 text
118
わからないこと
Slide 119
Slide 119 text
119
● PRの粒度を揃えないと比較できないと思われるが、粒度を揃える方法、粒度の表現方法が不明。
○ 他社との単純比較可能性については懐疑的。
○ 同社の他チームですら比較する際にはコンテクスト合わせの配慮が必要。
わからないこと
Slide 120
Slide 120 text
120
● のび代（環境（開発プロセス他）、人（ドメイン知識他））の比重まではわからない。
わからないこと
Slide 121
Slide 121 text
121
● 個別の施策の効果は必ずしもわからない。
○ 勉強会など、PRに顕著に反映されないものや即時的に反映されないものがある。
○ 取り組んでいることが全体としてポジティブなのかネガティブなのかくらいはわかりそう。
わからないこと
Slide 122
Slide 122 text
122
● メトリクスの変化のみから確実にわかることはない。
○ コンテクストが重要。
○ 何によりもたらされた変化なのかを見極めなければならない。
わからないこと
Slide 123
Slide 123 text
● 適正値がわからないメトリクスがある。
○ 例えばレビューにおけるコメント数
■ 少なすぎる場合、レビューが機能していない可能性を示唆してそうだが断定はできない。
● コメント数単体で評価するのはミスリードの危険を孕んでいる。
■ 10は多い？30は？100は？
● チームあるいは個人に固有の閾値を見極める必要がありそう。
○ メトリクスの活用方法を研究する必要がある。
○ 気にしないのも一つの手。
123
わからないこと
Slide 124
Slide 124 text
124
今後のこと
Slide 125
Slide 125 text
125
● 過去のPRを振り返り分析したい時にコンテクストの情報がないので
なぜ計測値が大きいのか/小さいのかを読み取り切れない。
● 計測値を確認するだけではなく、コンテクストを読み取る作業も必要。
● 計測値を比較可能にするための努力が必要。
○ PRを小さくし、難易度やサイズの違いを極小化するのはこのためでもある。
運用上の留意事項
Slide 126
Slide 126 text
126
● 分析対象外としたいブランチにGitHub上でラベルを貼る運用としているが漏れることがある。
● ノイズがある。
○ 非稼働日（特に連休）により計測値が悪化する。
○ 調査のため作成し閉じたPR（成果有）と開発を中止したPR（成果無）が見分けられない。
○ 自動生成されるコードなどにより変更行数が顕著に大きくなる。
○ （そもそも運営の是非があるが）待ち時間等で進める開発はリードタイムが長くなる。
かといって除外すると、貢献がPR数に反映されない。
● PRに反映されないタスクもある。
運用上の留意事項
Slide 127
Slide 127 text
127
● チーム異動があった場合、集計を工夫しないと一つのグラフに異なるコンテクストが混じり込みミ
スリードになる。
● 支援が必要なメンバーをボトルネックにするもしないもチーム次第。
運用上の留意事項
Slide 128
Slide 128 text
128
● のび代の改善を続ける。
● 変化の探知機として活用する。
○ 計測値の変化から環境や人の変化を察知する。
○ オンボーディングが順調かどうかをモニタリングする。
● 内省を助けるスマートウォッチとして活用する。
私たちの展望
Slide 129
Slide 129 text
129
● 前述の“わからないこと”や“運用上の留意事項”を踏まえたベストプラクティスを探索する。
私たちの展望
Slide 130
Slide 130 text
130
まとめ
Slide 131
Slide 131 text
131
まとめ
● Four Keysを用いた生産性可視化をステップバイステップで進めた。
● スクラムイベントに組み込んで習慣化した。
● 計測値から洞察を得て主に開発プロセスを見直し、生産性が改善した一方のび代も残されている。
● 計測値の絶対値に囚われず、背景にある生産性を高める/低める要因を探索するのがよさそう。
● 計測値を比較する際にはコンテクストを合わせる必要がある。
● また、コンテクストの違いを擦り合わせる過程で発見がある。
● Four Keysで測れるものとそうでないものがある。
● それはともかくとして、組織のオブザーバビリティを高めるのに役立つ。
● その性質を理解した上で運用を構築し、人と環境のエンパワメントを続けたい。
Slide 132
Slide 132 text
ご清聴ありがとうございました