Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

What We Learned and What We Didn't from Our Eff...

inouehi
September 16, 2023

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

inouehi

September 16, 2023
Tweet

More Decks by inouehi

Other Decks in Technology

Transcript

  1. 8 私たちの取り組みには以下のような前提があります。 • スクラムで開発を行っている。 • 計測、評価、改善活動は5名程度のチームごとに行っている。 • 経営層からのトップダウンではなくて、エンジニア組織からのボトムアップでスタートした。 • 開発生産性の向上を主導するチームがあるのではなく、開発チーム内で行っている。

    ◦ 可視化を主導するのはEMの役割の一つ。 ◦ 数値を見るだけでなく開発プロセスに参加し、定性的な情報も体感している。 ◦ 数値はチームの皆が見る。 ◦ 改善活動はチームで、あるいはエンジニア組織全体で実行する。 前提
  2. 23 Four Keys[1]で始めてみよう。 何を計測すべきか 1. デプロイの頻度, 変更のリードタイム, 変更障害率, サービス復元時間。State of

    DevOps 2021では運用パフォーマンス指標である「信頼 性」が5つめのメトリクスとして追加された。
  3. 28 • デプロイの頻度 ← 変更のリードタイムへの依存関係がありそう • 変更のリードタイム ← 更に分解できる •

    変更障害率 ← 課題感がないのでスコープアウト • サービス復元時間 ← 課題感がないのでスコープアウト スモールスタート
  4. 29 • デプロイの頻度 ← 変更のリードタイムへの依存関係がありそう • 変更のリードタイム ← 更に分解できる ◦

    開発する ◦ レビューする ← ここからやってみよう ◦ 修正を完了する ◦ マージする • 変更障害率 ← 課題感がないのでスコープアウト • サービス復元時間 ← 課題感がないのでスコープアウト スモールスタート
  5. レビューを早くするためにレビュイーとレビュアーがすべきことを啓蒙 • レビューに至るまでのコミュニケーション ◦ 要所を相談してから進める。 ◦ モブ設計により大きな認識のズレを無くしておく。 ◦ レビューをスムーズにする前提知識を事前に周知する。 •

    レビューにおけるコミュニケーション ◦ 指摘のトーンや背景を伝える。 ◦ 参考資料やサンプルコードを示す。 ◦ 適宜口頭で説明する。 32 いかにして早めるか?を言語化する
  6. 37 • デプロイの頻度 • 変更のリードタイム ◦ 開発する ← ここもやってみよう ◦

    レビューする ← ここからやってみよう ◦ 修正を完了する ← ここもやってみよう ◦ マージする • 変更障害率 • サービス復元時間 次のステップ
  7. 40 PRサイズを小さくしよう。 言うだけでは変化は起きず… それではと、具体的な方法を示した。 • 1つのPRに含む変更意図は1つにする。 ◦ リファクタ、不具合修正、フィーチャーのような単位で分ける。 • フィーチャーは更に分解できる。例えば、レイヤー毎に分ける。

    ◦ モブ設計と併用することで手戻りを防ぐ。 • 変更行数200~400, ファイル数10を目安に分割する。 ◦ (正直なところ手応えなし) • Reactのコンポーネント単位、削除ならエンドポイント単位など PRサイズを小さくする
  8. 46 注意事項 • レビューの数が増える。 ◦ レビューを早く行うこととセットで取り組まないと結局詰まる。 • PRを細かく分けると全体が見えにくくなる。 ◦ 最初に設計しておくとスムーズ。

    • PRサイズの目安(例えば、変更行数200~400)が自組織に当てはまるか評価すべき。 ◦ 弊チームの場合、行数よりもむしろファイル数を気にする声が多かった。 ◦ 適正サイズは恐らくコンテクスト(言語、アーキテクチャ etc.)に依存する。 PRサイズを小さくする
  9. 47 • ガイドライン • 雛形 • ADR • ペアプロ •

    オンデマンドの支援 開発における迷いを減らす
  10. 51 • 環境 ◦ 開発プロセス ◦ 既存システムの保守性 ◦ 開発・運用環境[1] ◦

    開発外業務[2]の多寡 • 人 ◦ ドメイン知識 ◦ 技術力 ◦ モチベーション 生産性に影響を与える要素 1. CI/CD、型付け、静的解析、フィーチャートグル、ChatOps、オブザーバビリティといった類の話。 2. コードの生成に直接的につながらない業務。間接業務、見積り、照会、障害対応等。
  11. 52 • 環境 ◦ 開発プロセス ◦ 既存システムの保守性 ◦ 開発・運用環境 ◦

    開発外業務の多寡 • 人 ◦ ドメイン知識 ◦ 技術力 ◦ モチベーション 生産性に影響を与える要素
  12. 53 • 環境 ◦ 開発プロセス ◦ 既存システムの保守性 ◦ 開発・運用環境 ◦

    開発外業務の多寡 • 人 ◦ ドメイン知識 ◦ 技術力 ◦ モチベーション 生産性に影響を与える要素
  13. 57 • 現場見学 • インプット、アウトプットの機会提供 • ナレッジ共有の機会提供 • ペア・モブプロ(設計) •

    レビュー • ディスカッション • 勉強会 • ドキュメント整備 人を支援する
  14. 68 生産性とはなんなのか 1. https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance Four Keys[1] • デプロイの頻度 … 組織による正常な本番環境へのリリースの頻度

    • 変更のリードタイム … commit から本番環境稼働までの所要時間 • 変更障害率 … デプロイが原因で本番環境で障害が発生する割合(%) • サービス復元時間 … 組織が本番環境での障害から回復するのにかかる時間
  15. 69 生産性とはなんなのか Four Keysが含意するものに差異がありうる。例えば、 • デプロイの頻度 … 計測の都合によるカウント方法の差異 • 変更のリードタイム

    … commitするタイミングの差異 … 計算方法の差異 … PRの難易度の差異 … 製品特性による開発プロセスの差異
  16. 70 生産性とはなんなのか Four Keysが含意するものに差異がありうる。例えば、 • デプロイの頻度 … 計測の都合によるカウント方法の差異 • 変更のリードタイム

    … commitするタイミングの差異 … 計算方法の差異 … PRの難易度の差異 … 製品特性による開発プロセスの差異 ⇒比較したい場合コンテクストの違いに注意する必要がある。
  17. 73 Four Keysの外にあるもの • PRに反映されないタスク ◦ ドキュメント作成 ◦ 技術検証 ◦

    ルールやガイドライン整備 ◦ 勉強会 ◦ 採用 ◦ 技術広報 など • 前述したレベル2, 3の生産性
  18. 76 • 数値を踏まえて振り返りや1on1を行うようになった。 ◦ 変更のリードタイムが長引いた要因を、工程の内訳を踏まえて振り返れた。 • 体感の答え合わせができる。 ◦ レビューを迅速に行っている感覚があり、数値がそれを裏付けていた。 ◦

    新規参画者のパフォーマンスが右肩上がりなのを確認できた。 • 体感と異なることもあり、それが発見である。 ◦ 自覚していなかったがPRを小さくできる余地があった。 振り返りがどう変わったか
  19. 79 • うまくいっている。 ◦ 以前の私たちよりも進歩している。 • うまくいっていない。 ◦ まだ改善の余地がある。 開発プロセスは比較的改善を進めやすい。

    それ以外の部分は、リソースが必要になる場合にハードルが上がる/時間を要する。 実際のところうまくいっているのか、うまくいっていないのか
  20. 92 • デプロイの頻度 … 増やしたい • 変更のリードタイム … 短縮したい •

    変更障害率 … 課題感がないのでスコープアウト • サービス復元時間 … 課題感がないのでスコープアウト どのように評価するか
  21. 93 • デプロイの頻度 • 変更のリードタイム ◦ 開発する … 短縮したい ◦

    レビューする … 短縮したい ◦ 修正を完了する … 短縮したい ◦ マージする … 短縮したい どのように評価するか
  22. 94 • デプロイの頻度 • 変更のリードタイム ◦ 開発する … 短縮したい ◦

    レビューする … 短縮したい ◦ 修正を完了する … 短縮したい ◦ マージする … 短縮したい ⇒絶対値に囚われすぎないようにしている。 どのように評価するか
  23. 95 • デプロイの頻度 • 変更のリードタイム … ☟長期化する要因例 ◦ 開発する …

    担当者のスキル、要件の精度、システムの理解容易性、影響範囲 ◦ レビューする … 意識・習慣(仕事の優先順位づけ)、業務量、レビューしやすさ ◦ 修正を完了する … 開発する同様の要因+認識違い、指摘の流儀、レビュアー数 ◦ マージする … デプロイの仕組み、デプロイを阻む要素、QA体制 ⇒長期化した要因を探り対策をうつ。 どのように評価するか
  24. 105 • 違うということ ◦ 私たちのチームは彼女/彼らのチームと何かが違う。 • 変化したということ ◦ 今の私たちは過去の私たちと何かが違う。 •

    変化してないということ ◦ このケースは注意が必要。 そこからどのような発見を抽出できるのか
  25. 106 • 違うということ ◦ 私たちのチームは彼女/彼らのチームと何かが違う。 • 変化したということ ◦ 今の私たちは過去の私たちと何かが違う。 •

    変化してないということ ◦ このケースは注意が必要。 ◦ 今の私たちは過去の私たちと、一見、何も変わらない。 そこからどのような発見を抽出できるのか
  26. 107 • 違うということ ◦ 私たちのチームは彼女/彼らのチームと何かが違う。 • 変化したということ ◦ 今の私たちは過去の私たちと何かが違う。 •

    変化してないということ ◦ このケースは注意が必要。 ◦ 今の私たちは過去の私たちと、一見、何も変わらない。 ⇨何も変わらない?本当に? そこからどのような発見を抽出できるのか
  27. 108 • グラフに表れない何か(コンテクスト)が変化してないか? ◦ メンバー数 ◦ 稼働日数 ◦ 開発外業務量(PRに反映されないアクティビティ量) ◦

    難易度 ◦ 新規、改修(しがらみや車輪の有無) ◦ 技術スタック など • ポジティブな変化とネガティブな変化が相殺した結果なのではないか? そこからどのような発見を抽出できるのか
  28. 126 • 分析対象外としたいブランチにGitHub上でラベルを貼る運用としているが漏れることがある。 • ノイズがある。 ◦ 非稼働日(特に連休)により計測値が悪化する。 ◦ 調査のため作成し閉じたPR(成果有)と開発を中止したPR(成果無)が見分けられない。 ◦

    自動生成されるコードなどにより変更行数が顕著に大きくなる。 ◦ (そもそも運営の是非があるが)待ち時間等で進める開発はリードタイムが長くなる。 かといって除外すると、貢献がPR数に反映されない。 • PRに反映されないタスクもある。 運用上の留意事項
  29. 131 まとめ • Four Keysを用いた生産性可視化をステップバイステップで進めた。 • スクラムイベントに組み込んで習慣化した。 • 計測値から洞察を得て主に開発プロセスを見直し、生産性が改善した一方のび代も残されている。 •

    計測値の絶対値に囚われず、背景にある生産性を高める/低める要因を探索するのがよさそう。 • 計測値を比較する際にはコンテクストを合わせる必要がある。 • また、コンテクストの違いを擦り合わせる過程で発見がある。 • Four Keysで測れるものとそうでないものがある。 • それはともかくとして、組織のオブザーバビリティを高めるのに役立つ。 • その性質を理解した上で運用を構築し、人と環境のエンパワメントを続けたい。