What We Learned and What We Didn't from Our Efforts to Visualize Productivity

『チームのアジリティを上げよう！否、〇〇を上げよう！開発生産性の可視化に取り組んでみてわかったこと、わからないこと』

スクラムフェス三河 2023
2023-09-16 15:00～ emCAMPUS STUDIO Room1
https://confengine.com/conferences/scrum-fest-mikawa-2023

Transcript

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