Improve Our Development Habits by Measuring Productivity and Maintainability

『測って見直す開発習慣 可視化を進めて私たちに起きた変化』

PHPカンファレンス北海道 2024
2024/01/13 16:05〜 クリエイティブスタジオ
https://phpcon.hokkaido.jp/
https://fortee.jp/phpcon-hokkaido-2024

Transcript

1. 測って見直す開発習慣 可視化を進めて私たちに起きた変化 2024/01/13 PHPカンファレンス北海道 2024
2. 2 • Hiroki Inoue • Software Engineer • Engineering Manager @ WHITEPLUS, Inc. About Me
3. 3 トーク概要 このトークは、開発生産性、保守性を可視化し、私たちの活動やシステムの状態を顧みる試みを綴った 経験談です。どのように可視化に取り組み、どのような習慣、体験が得られたかを共有します。 https://fortee.jp/phpcon-hokkaido-2024/proposal/b2b9f4cf-3117-4d70-bd71-46b8d55a7bb9
4. 4 1. 可視化に取り組むか検討している方 2. 可視化の運用を試行錯誤している方 3. 可視化に悩めるチームを手助けし、エンジニアリングプロセスの発展に関わりたい方 誰向けのトーク？
5. 5 アジェンダ はじめに どのように可視化を進めたか 01 02 可視化により分かること 習慣の変化 03 04 体験の変化 05 まとめ 06
6. 6 • わかりにくかった事 • 発見した事 • 役に立った？立たない？ etc. フィードバックを是非お願いしますmm
7. 7 はじめに ～このトークのスタンス～
8. 8 • アウトプットとアウトカム、両方大事で両立できる。 ◦ このトークにおける”生産性”はアウトプットを指す。 ◦ 広木大地さんによる定義におけるレベル2, 3の生産性はスコープ外。[1] 生産性の意図するところ 1. 大規模言語モデル時代の開発生産性（hirokidaichi）
9. 9 • 測る？ or 測らない？ ◦ 測る • 何を測る？（Four Keys or SPACE or その他） ◦ Four Keys • どうやって測る？（Saas or OSS or 自作） ◦ Saas 生産性評価方法の現状
10. 10 • 計測、評価、改善活動は5名程度のチームごとに行っている。 • 生産性、保守性向上を主導するチームがあるのではなく、開発チーム内で行っている。 ◦ 可視化を主導するのはEMの役割の一つ。 ◦ 数値を見るだけでなく開発プロセスに参加し、定性的な情報も体感している。 ◦ 数値はチームの皆が見る。 ◦ 改善活動はチームで、あるいはエンジニア組織全体で実行する。 前提
11. 11 • 数値の単純比較に価値はないと考える。[1] ◦ 重要なのは数値そのものではなく、背景を読み取ること。 注意事項 1. チームのアジリティを上げよう！否、〇〇を上げよう！開発生産性の可視化に取り組んでみてわかったこと、わからないこと（119頁）
12. 12 • Four Keysの限界 ◦ レベル2, 3の生産性は測れない。 ◦ PRに反映されない仕事の生産性は測れない。 ▪ 仕様調査 ▪ ドキュメント作成 ▪ ミーティング etc. 注意事項
13. 13 • ノイズの問題（計測ツールの仕様による部分もある） ◦ 非稼働日（特に連休）により計測値が悪化する。 ◦ 調査のため作成し閉じたPR（成果有）と開発を中止したPR（成果無）が見分けられない。 ◦ 自動生成されるコードなどにより変更行数が顕著に大きくなる。 ◦ （そもそも運営の是非があるが）隙間時間に進める開発はリードタイムが長くなる。 ◦ かといって除外すると、貢献がPR数に反映されない。 ◦ GitHubでラベルの付与漏れによる分析対象の誤り。 注意事項
14. 14 • 測る？ or 測らない？ ◦ 測る • 何を測る？ ◦ コードベースの規模 ◦ 循環的複雑度 • どうやって測る？ ◦ OSS 保守性評価方法の現状
15. 15 どのように可視化を進めたか
16. 16 生産性の計測
17. 17 • Findy Team+を利用。 • GitHubやJiraに蓄積されたPR等の情報を活用。 • PHP等の言語に依存せず、適用可能。 Four Keys[1] 1. https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
18. 18 • デプロイの頻度 … 組織による正常な本番環境へのリリースの頻度 • 変更のリードタイム … commit から本番環境稼働までの所要時間 • 変更障害率 … デプロイが原因で本番環境で障害が発生する割合（%） • サービス復元時間 … 組織が本番環境での障害から回復するのにかかる時間 1. デプロイの頻度, 変更のリードタイム, 変更障害率, サービス復元時間。 State of DevOps 2021では運用パフォーマンス指標である「信頼性」が5つめのメトリクスとして追加された。 Four Keys[1]
19. 19 余談
20. 20 Four Keysが含意するものに差異がありうる。例えば、 • デプロイの頻度 … 計測の都合によるカウント方法の差異 • 変更のリードタイム … commitするタイミングの差異 … 計算方法の差異 … PRの難易度の差異 … 製品特性による開発プロセスの差異 Four Keys
21. 21 Four Keysが含意するものに差異がありうる。例えば、 • デプロイの頻度 … 計測の都合によるカウント方法の差異 • 変更のリードタイム … commitするタイミングの差異 … 計算方法の差異 … PRの難易度の差異 … 製品特性による開発プロセスの差異 ⇒比較したい場合コンテクストの違いに注意する必要がある。 Four Keys
22. 22 • Four Keysすべてを追いかけない。 • ガチガチに目標を固め過ぎない。 スモールスタート
23. 23 • デプロイの頻度 ← 変更のリードタイムへの依存関係がありそう • 変更のリードタイム • 変更障害率 • サービス復元時間 スモールスタート
24. 24 • デプロイの頻度 ← 変更のリードタイムへの依存関係がありそう • 変更のリードタイム ← 更に分解できる • 変更障害率 • サービス復元時間 スモールスタート
25. 25 • デプロイの頻度 ← 変更のリードタイムへの依存関係がありそう • 変更のリードタイム ← 更に分解できる ◦ 開発する ◦ レビューする ◦ 修正を完了する ◦ マージする • 変更障害率 • サービス復元時間 スモールスタート
26. 26 • デプロイの頻度 ← 変更のリードタイムへの依存関係がありそう • 変更のリードタイム ← 更に分解できる ◦ 開発する ◦ レビューする ←取り組みやすい ◦ 修正を完了する ◦ マージする • 変更障害率 ← 課題感がないのでスコープアウト • サービス復元時間 ← 課題感がないのでスコープアウト スモールスタート
27. 27 • デプロイの頻度 ← 変更のリードタイムへの依存関係がありそう • 変更のリードタイム ← 更に分解できる ◦ 開発する ◦ レビューする ← ここからやってみよう ◦ 修正を完了する ◦ マージする • 変更障害率 ← 課題感がないのでスコープアウト • サービス復元時間 ← 課題感がないのでスコープアウト スモールスタート
28. 28 • レビューの早さについては最初から具体的目標を持ち、その他は観察することからはじめた。 • 徐々に見る観点を増やした。 ◦ レビューの早さ、修正の早さ、開発の早さ、PRサイズ、アクティビティ量、デプロイ頻度... スモールスタート
29. 29 レビューの着手が早くなった。 みんな偉い👏 しばらく試してみると…
30. 30 レビューの着手が早くなった。 みんな偉い👏 そして修正を完了するまでの（レビュー〜アプルーブまでの）時間等にも目を向け始める。 しばらく試してみると…
31. 31 • デプロイの頻度 • 変更のリードタイム ◦ 開発する ← ここもやってみよう ◦ レビューする ← ここからやってみよう ◦ 修正を完了する ← ここもやってみよう ◦ マージする • 変更障害率 • サービス復元時間 次のステップ
32. 32 ステップバイステップで 無理なく 着実に 変化を続けたい
33. 33 保守性の計測
34. 34 • phpmetrics/PhpMetricsを使用。 • 複雑さ等も計測できる[1]が、コード行数、クラス数に絞って観察。 • 小まめに実行する必要性に乏しく手動で計測。 コードベースの規模 1. PhpMetrics－Main metrics
35. 35 • terryyin/lizardを使用。 • GitHub Actionsに組み込み、閾値を超えた場合にコメントを生成。 • 修正を強制はしない。 ◦ 自身の設計をふりかえるきっかけに。 ◦ 古いコードベースの課題を見える化。 循環的複雑度
36. 36 よい習慣をつくる 慣性をうみだしたい
37. 37 可視化により分かること
38. 38 1. ボトルネック 2. 変化 3. （副次的なものとして）のびしろ 生産性に関して分かること
39. 39 1. ボトルネック 開発する レビューを始める 修正を完了する マージする
40. 40 開発する レビューを始める 修正を完了する マージする 1. ボトルネック
41. 41 PR数の推移 1. ボトルネック
42. 42 ＋ PR数の推移 1. ボトルネック
43. 43 ＋ PR数の推移 開発外業務が増加 1. ボトルネック
44. 44 2. 変化 • よくなっているのか • 停滞しているのか • 悪くなっているのか
45. 45 2. 変化
46. 46 2. 変化 オンボーディング 順調な立ち上がり
47. 47 2. 変化 オンボーディング 順調な立ち上がり 下降しているが なぜ？
48. 48 2. 変化 オンボーディング 順調な立ち上がり 担当ドメイン変更 開発外タスク増 レビュー負荷増
49. 49 • 環境 ◦ 開発プロセス ◦ 既存システムの保守性 ◦ 開発・運用環境[1] ◦ 開発外業務[2]の多寡 • 人 ◦ ドメイン知識 ◦ 技術力 ◦ モチベーション 3. （副次的なものとして）のびしろ 1. CI/CD、型付け、静的解析、フィーチャートグル、ChatOps、オブザーバビリティといった類の話。 2. コードの生成に直接的につながらない業務。間接業務、見積り、照会、障害対応等。
50. 50 余談
51. 51 • 不要コードの削除 • リファクタリング • DDDによる整理 • 静的解析の更なる活用（レベル上げ、カスタムルール、ツール追加） 保守性を高める
52. 52 • GitHub Copilot導入 • ChatGPT導入 • ビルド時間の短縮 • 循環的複雑度の計測 開発・運用環境を改善する
53. 53 • ドキュメントやツールに働かせる。 • 業務の交通整理を行う。 • 設計（障害耐性、復旧容易性、理解容易性）改善を目指す。 • 開発外業務の多くをEMが巻き取りつつ、一部負荷を平準化しつつメンバーに渡す。 開発外業務をスリムにする
54. 54 • 現場見学 • インプット、アウトプットの機会提供 • ナレッジ共有の機会提供 • ペアプロ • レビュー • ディスカッション • 勉強会 • ドキュメント整備 人を支援する
55. 55 • コードベースの規模の変化を定量的に把握できる。 • 設計を見直すべきか否かの判断材料になる。 ⇒人の判断は時に不安定、不正確、不揃い。数値化することで認識、同期の精度を上げられる。 保守性に関して分かること
56. 56 • 個々の施策の良し悪しやインパクトの大きさ ◦ 整備したドキュメント、勉強会は有効なのか？ ◦ コードベースの規模の削減がどれほど効いているのか？ • 保守性と生産性の関連性 • のびしろの比重 わからないこと
57. 57 • グラフに表れない情報は別途収集する必要がある。 ◦ メンバー数 ◦ 稼働日数 ◦ 開発外業務量（PRに反映されないアクティビティ量） ◦ 難易度 ◦ 新規開発 or 改修（資産や負債の有無） ◦ 技術スタック など （直接的には）わからないこと
58. 58 習慣の変化
59. 59 1. スクラムイベント 2. 対策策定 3. 開発プロセス 4. 情報収集 5. 目標管理 変化した習慣
60. 60 • レトロスペクティブの際に数値を確認する。 ◦ ふりかえりの焦点を絞れる。 ◦ 発言を引き出せる。 • 推奨するプラクティスも毎週繰り返し確認する。 1. スクラムイベント
61. • 体感の答え合わせができる。 ◦ レビューを迅速に行っている感覚があり、数値がそれを裏付けていた。 ◦ 新規参画者のパフォーマンスが右肩上がりなのを確認できた。 • 体感と異なることもあり、それが発見である。 ◦ 自覚していなかったがPRを小さくできる余地があった。 • 数値を踏まえて振り返りや1on1を行うようになった。 ◦ 変更のリードタイムが長引いた要因を、工程の内訳を踏まえて振り返れた。 61 1. スクラムイベント － 例えばふりかえりがどうなったか
62. 62 • 数値の下降あるいは停滞が、次なる施策の必要性を示唆する。 • ボトルネックを特定することで対策の候補が決まる。（次頁） 2. 対策策定
63. 63 …………………………… ☟変更のリードタイムが長期化する要因例 • 開発する … 担当者のスキル、要件の精度、システムの理解容易性、影響範囲 • レビューする … 意識・習慣（仕事の優先順位づけ）、業務量、レビューしやすさ • 修正を完了する … 開発する同様の要因＋認識違い、指摘の流儀、レビュアー数 • マージする … デプロイの仕組み、デプロイを阻む要素、QA体制 2. 対策策定 － 例えば変更のリードタイムを改善したい時
64. 64 …………………………… ☟変更のリードタイムが長期化する要因例 • 開発する … 担当者のスキル、要件の精度、システムの理解容易性、影響範囲 • レビューする … 意識・習慣（仕事の優先順位づけ）、業務量、レビューしやすさ • 修正を完了する … 開発する同様の要因＋認識違い、指摘の流儀、レビュアー数 • マージする … デプロイの仕組み、デプロイを阻む要素、QA体制 2. 対策策定 － 例えば変更のリードタイムを改善したい時
65. 65 • レビュー文化 ◦ 極力レビュー優先 ◦ レビューしやすいPR ◦ レビューに至るまでのコミュニケーション ▪ 要所を相談してから進める。 ▪ モブ設計により大きな認識のズレを無くしておく。 ▪ レビューをスムーズにする前提知識を事前に周知する。 ◦ レビューにおけるコミュニケーション ▪ 指摘のトーンや背景を伝える。 ▪ 参考資料やサンプルコードを示す。 ▪ 適宜口頭で説明する。 3. 開発プロセス
66. 66 3. 開発プロセス • レビュー分担の最適化 ◦ ナレッジ共有の役割を終えたレビュアーをアンアサイン ◦ ボトルネックなっているレビュアーの業務調整やアンアサイン ◦ レビュアーの分散化 品質保証 ナレッジ 共有
67. 67 • PRサイズを小さく 段階的に浸透させた ◦ 啓蒙 ◦ 具体的な方法を紹介 ◦ ローカライズと自分事化 ◦ 目標を具体化 ◦ レビューやふりかえりで相互フィードバック 3. 開発プロセス
68. 68 • PRサイズを小さく 段階的に浸透させた ◦ 啓蒙 ◦ 具体的な方法を紹介 ◦ ローカライズと自分事化 ◦ 目標を具体化 ◦ レビューやふりかえりで相互フィードバック • 注意事項 ◦ レビューが増えるので 早く行うこととセットで取り組まないと結局詰まる。 3. 開発プロセス
69. 69 • 3ペア ◦ ペアプロ ◦ ペア（モブ）設計 ◦ ペア調査 3. 開発プロセス
70. 70 • 開発における迷いを減らす ◦ ガイドライン ◦ 雛形 ◦ ADR ◦ オンデマンドの支援 3. 開発プロセス
71. 71 • 生産性向上の観点から他社事例、ベストプラクティスを収集 ◦ イベント参加 ◦ （Saasを利用している場合）CSのサポート • チーム間交流 ◦ 数値の差異がディスカッションの契機になる。 ◦ 他チームを観察し、プラクティスを取り入れる。 4. 情報収集
72. 72 人によると思われるが • 目標が立てやすくなる。 • 目標に対する進捗がわかりやすくなる。 • アクションを起こしやすくなる。 5. 目標管理
73. 73 人によると思われるが • 目標が立てやすくなる。 • 目標に対する進捗がわかりやすくなる。 • アクションを起こしやすくなる。 • 注意事項 ◦ 点で目標を立てるのは控えたい。環境要因によるブレがあるため。 ◦ 幅をもたせたり背景を考慮する必要がある。 ◦ 定量的なら白黒はっきりできると思いきやそうでもない。 5. 目標管理
74. 74 • 規模や循環的複雑度のモニタリングによる習慣の変化は見られなかった。 • 規模のモニタリングによりコード掃除の手応えを感じることや • 循環的複雑度のモニタリングにより複雑なコードが増殖してないことを確認できはした。 ちなみに保守性の可視化については…
75. 75 • 新規作成したコードが検知されるのは稀。既存コードが検知されることはある。 • 検知が修正につながらないケース ◦ 所謂レガシーの場合リファクタのハードルが高い。 ◦ リファクタの旨みが乏しいドメインの場合優先度が上がらない。 ◦ 具体的にどこをどう直せばよいかわからない。 循環的複雑度モニタリングの経過
76. 76 • 新規作成したコードが検知されるのは稀。既存コードが検知されることはある。 • 検知が修正につながらないケース ◦ 所謂レガシーの場合リファクタのハードルが高い。 ◦ リファクタの旨みが乏しいドメインの場合優先度が上がらない。 ◦ 具体的にどこをどう直せばよいかわからない。 • そもそも費用対効果の高いところからリファクタしたいので、ランダムに見つかったそれを反射的 に修正しようとはならない。 循環的複雑度モニタリングの経過
77. 77 • 新規作成したコードが検知されるのは稀。既存コードが検知されることはある。 • 検知が修正につながらないケース ◦ 所謂レガシーの場合リファクタのハードルが高い。 ◦ リファクタの旨みが乏しいドメインの場合優先度が上がらない。 ◦ 具体的にどこをどう直せばよいかわからない。 • そもそも費用対効果の高いところからリファクタしたいので、ランダムに見つかったそれを反射的 に修正しようとはならない。 • 複雑なコードが増殖していないことや既存コードののびしろが確認できた。 循環的複雑度モニタリングの経過
78. 78 体験の変化
79. 79 測るだけで何かが起きるわけではもちろんない。 数値が見えることで何らかの慣性が生じる。それを活かすも流すも私たち次第。 大前提
80. 80 体感アンケート結果 • 自分の行動の改善案を考えやすくなった（レビューの速度やPRの大きさなど） • 「目標を立てやすくなった（数値で明確になった）」のが一番だと思っています • 自身の目標としても数値化されていることで、計測して改善までのプロセスが組みやすくなっていると感じます • Pull Request を小さくしてレビュー&マージを迅速に行うという共通意識がチームに定着しつつあり、リリースを素早くすることに活かせてきている • リアルタイムで目標の数値に近づいているor遠のいている状態が把握できるため、個人的な振り返りがやりやすくなった • オープンからマージまでの時間が分かりやすくなり意識するようになった • PRを細かく出すことにより、レビューがしやすくなった。また出す方でも大きなPRを作らないですむので負担感が減った • 自分の行動が数値化されて改善点を探しやすい • どのPRで実装が詰まったのかを明確にキャッチできている • そこからナレッジ化やチームでの問題解消などに取り組めている • チームのレビュー速度が上がり、直列になっているタスクを着手するまでの待ち時間が減った • 自分がレビューについて躊躇していることを伝えるきっかけになった • 自分の体感よりも「時間がかかっていたPR」や「早かったPR」を知ることができ、前者の問題点や後者の再現性を考えるきっかけになった （アンケート結果ではないが会話の中で拾ったこととしては） • ガイドライン等の整備により開発における迷いが減った。 • ビルド時間の短縮により迅速にデプロイできるようになった。開発環境の起動待ちの煩わしさが減った。
81. 81 • 内省しやすくなった。 ◦ うまくいったことを確認したり、失敗したことに気づける。 ◦ 裏付けがあることで、体感に自信が持てるようになる。 ◦ 自覚してないことに気づけるようになる。 ◦ 数値が根拠となりフィードバックを受け入れられやすくなる。 ◦ 数値として見えることが自律的な改善活動のトリガーになる。 • 目標を立てやすくなった。 • プロセスを見直した部分の負担（感）が軽減した。 体感まとめ
82. 82 • レビューがスムーズになった。 • 変更のリードタイムが短縮された。 • デプロイ頻度が上がった。 結果として
83. 83 • チーム間交流のタッチポイントが増えた。 • 開発プロセスや体験をよくする慣性が生まれた。 • ボトルネックや変化に気づきやすくなった。 • 発言を引き出す効果がある。 • 数値の評価に関して負担感がある。 ◦ ノイズの排除 ◦ 定性情報の収集 運営サイドの視点から
84. 84 • チーム間交流のタッチポイントが増えた。 • 開発プロセスや体験をよくする慣性が生まれた。 • ボトルネックや変化に気づきやすくなった。 • 発言を引き出す効果がある。 • 数値の評価に関して負担感がある。 ◦ ノイズの排除 ◦ 定性情報の収集 運営サイドの視点から
85. 85 • チーム間交流のタッチポイントが増えた。 • 開発プロセスや体験をよくする慣性が生まれた。 • ボトルネックや変化に気づきやすくなった。 • 発言を引き出す効果がある。 • 数値の評価に関して負担感がある。 ◦ ノイズの排除 ◦ 定性情報の収集 運営サイドの視点から
86. 86 • チーム間交流のタッチポイントが増えた。 • 開発プロセスや体験をよくする慣性が生まれた。 • ボトルネックや変化に気づきやすくなった。 • 発言を引き出す効果がある。 • 数値の評価に関して負担感がある。 ◦ ノイズの排除 ◦ 定性情報の収集 運営サイドの視点から
87. 87 • チーム間交流のタッチポイントが増えた。 • 開発プロセスや体験をよくする慣性が生まれた。 • ボトルネックや変化に気づきやすくなった。 • 発言を引き出す効果がある。 • 数値の評価に関して負担感がある。 ◦ ノイズの排除 ◦ 定性情報の収集 運営サイドの視点から
88. 88 まとめ
89. 89 • Four Keysを用いた生産性可視化をステップバイステップで進めた。 • 開発習慣や体感に変化があった。 • 生産性向上に繋げるべく保守性向上も目指している。 • 保守性可視化の仕組みづくりにもトライしており、のびしろだらけ。 • 可視化は組織のオブザーバビリティを高めるのに役立つが、いくつかの注意点がある。 ◦ Four Keysで測れるものは限られている。 ◦ 定量的なら白黒はっきりできると思いきやそうでもない。 ◦ 測るだけは何も起きない。改善活動のリソースも必要。 ◦ 計測値を比較する際にはコンテクストを合わせる必要がある。 ◦ 計測値の評価にも労力がかかる。
90. ご清聴ありがとうございました
91. 91 • わかりにくかった事 • 発見した事 • 役に立った？立たない？ etc. フィードバックを是非お願いしますmm