Open52
2022年に読んだDeveloper Productivity・Developer Experience・Platform Engineering関連のリソース
r-kagaya2022年5月以降に読んだDeveloper Productivity・Developer Experience・Platform Engineering関連の書籍や記事のまとめ
r-kagayaYour migration probably isn’t failing due to insufficient staffing.
関係性薄いが面白かったので
- migrationが上手く行ってないのは人がいないからではない
- 人数を増やすことは、計画通りにトラッキングできていないことを認めることになる
- 計画された人員数に対して目標を指標化しているはず
- 戦略や実行が、現在の問題やヘッドカウントの制約に対してうまくいっていないことを意味する
- 単に人員を増やして現在のアプローチを進めるのではなく、アプローチや問題そのものにもっと興味深い変化があるはず
- 人数を増やすことは、計画通りにトラッキングできていないことを認めることになる
- migrationが上手く行ってない時に行うべき質問
- Where are folks getting stuck in the migration process?
- どこでstuckしているのか
- 大規模なマイグレーションでは、マイグレーションポイントの総数、マイグレーションを開始しようとした数、ファネル全体の進捗（新しいリポジトリの足場、開発環境でのプロビジョニング、オンコールローテーションの設定、本番環境へのプロビジョニング、など）が明確であるべき
- Are folks not starting the migration?
- 移行を開始していないのであれば、それが自分たちのニーズにとって有用であるとは考えていないか、あるいは、移行は悪い考えであるという逆シグナルをどこかから受け取っているのでしょう
- What cohorts are and aren’t migrating successfully?
- マイグレーションが成功している部分と失敗している部分のコホートを理解することで、うまくいっていない部分にもっと力を注ぐことができる（
- For teams that aren’t migrating, what are they doing instead? How is that going?
- マイグレーションをしていないチームは、代わりに何をしているのか？
- チームがマイグレーションを採用することに抵抗するとき、彼らはしばしば自分たちの特定の問題に対してより良い解決策を発見しています。
- マイグレーション当初は却下していた解決策かもしれませんし、マイグレーションの元になっていた実際の問題が、当初考えていたほど重要でないのかもしれません
- For teams who are migrating, where is the migration bottleneck, and what would resolve that bottleneck?
- 移行のボトルネックはどこか、そしてそのボトルネックを解消するにはどうしたらよいか？
- Where are folks getting stuck in the migration process?
- The four most common migration-recovery playbooks
- “Working the problem.
- “Don’t migrate.”
- “Cancel the migration.”
- “Increase headcount for the current migration strategy.
r-kagayaFailing Forward — How We Grow from Incidents
- Spotify for Artistsの信頼性に影響を与えたインシデントを分析したまとめ
- ほとんどのインシデントが、中程度から高い生産性に影響を与える
- インシデント対応コスト分だけ生産性落ちるよね
- ポストモーテムに時間をかけるの大事
- システムの理解に繋がる
- 今日の生産性を犠牲にして、後の生産性を買っている
- ほとんどのインシデントは（技術的には）防ぐことができる
- 「防ぐことはほぼ不可能」という1点から、「こうなることは予想していたが、起きてしまった」という5点までの評価基準を策定して、分類
- DORAのMTTRとChange Fail Rateは現状把握に役立つのでちゃんと記録しよう
- 約50％のケースで、開始時刻と終了時刻を記録する試みがなされていない
- また、復旧までの時間を記録しようとした場合、約81％の人が、入力された時間を5分以上調整しなければ、本当の数字を反映することができませんでした。
- これは意味をよく取れなかった。正確な時間を覚えてないという話なのか、よく見せるために調整した時間を記入したって話なのか
- synthetic testingは有効
- 合成テストが行われた、カバー可能な機能を含むインシデントの復旧時間は、一般に10倍も速かった
- synthetic testing is
- 合成テストは、合成モニタリングやプロアクティブモニタリングとも呼ばれ、主要なユーザージャーニーやアプリケーションのエンドポイントにおけるパフォーマンスの問題を、ユーザ体験を低下させる前に特定するための方法です。
- 多分要するにSynthetic Monitoring
- 検知も動作確認も早く出来る && synthetic monitoringやれてる時点でユースケースや挙動の整理もちゃんと出来てるから、みたいな背景かな
r-kagayaPlatform Engineering 101: Takeaways from Building Internal Tools at HubSpot
プラットフォームエンジニアリングでは、いくつかの機能を妥協して、
80〜90%のユースケースで機能するセントラルソリューションを構築する必要があります。
私のマネージャーは、「3の法則」を教えてくれました。これはソフトウェア工学の原則です。
抽象化する前に3回構築することを恐れるな」というものです。これは、プラットフォーム・エンジニアリングにおける素晴らしいアドバイスです。
プラットフォームエンジニアリングは、プロダクトエンジニアリングとは異なる問題を扱いますが、
すべての開発者がそれに興味を持つわけではありません。
プラットフォームチームは、抽象的な方法で問題を考えなければなりません。
1つのことを解決することに集中するのではなく、幅広いユースケースに対応するツールを
構築しなければなりません。また、将来を見据えて、長期的なメンテナンスのことや、
ツールが将来の開発にどのような技術的負債を負わせるかも考慮しなければなりません。
Embracing a Docs-as-Code approach
- Docs-as-Code
- GoogleやSpotifyが取り組んでいる
- SpotifyはDocs-as-Codeで社内の開発者ポータルにドキュメントを公開している
- TODO: 調べる
- Why Docs-as-Code
- ドキュメントを見つける事、書くことの課題・難しさ
- 見つける
- 異なるプラットフォームや異なるフォーマットが利用されている可能性
- 特に他のチームのドキュメントを探すのが困難
- 書く
- エンジニアの日常業務から切り離されていて、後回しにされてしまいがち
- たとえ情報を見つけても最新のものでない可能性が高い
- → 上記問題の解決のためには、single source of truthとなるプラットフォームが必要
- しかし、その前にドキュメントの書き方を変える必要がある
- → Docs-as-Code
- Docs-as-Codeとは
- システムとドキュメントの乖離を小さくすることを目指す
- ドキュメントとコードが同一リポジトリに配置
- コード修正と同ツール、同タイミングでドキュメントの更新が可能
- single source of truthとなるプラットフォームで公開
- 発見を容易に
- Grab社がやったこと
- ドキュメントの作成、レビュー、公開のプロセスを簡素化する社内開発者用ポータルを開発
- Create a dedicated docs folder in a Git repository.
- Push Markdown files into the docs folder.
- Configure the developer portal to publish docs from the respective code repository.
メモは以下
r-kagaya
- slackのdeveloper productivity teamがremove development環境を提供した話
- 2022年1月末には90%以上のエンジニアがリモート開発フローに切り替わった
-
slack remote-dev -b <branch_name>で開発環境が90秒以内に立ち上がり、必要な設定と拡張機能をインストールしたローカルのVSCodeインスタンスが開く - AWS Auto Scaling Groupを利用
- 定期的にマスターと同期しセットアップ時間を最小に
- 新メンバーのセットアップにかかる時間を約1時間からわずか数分に短縮
- ユニットテストの実行、デバッガーの実行、依存関係のインストール、フロントエンドのビルドなど、多くの共通タスクのパフォーマンスも改善された
- しれっと書かれてるがSlackのバックエンドはHackっていうのは知らなかった
r-kagaya
- What is Development
- アプリケーションのプログラミング、つまり、主要製品のビジネスロジックを書くこと。取り上げる3つの活動の中で、唯一会社に直接お金をもたらす活動
- What is DevOps
私にとってのDevOpsは、開発チームが本番環境へのコード出荷をよりコントロールできるようにするための文化的な変化でした- 最も一般的なアプローチは、開発チームに CI/CD パイプラインを提供すること
- ほとんどの場合開発で生産したものをデプロイする効率的な方法を作るということ
- 開発の速度を向上させる他のことにも関心を持つかもしれないが、DevOps自体が実際のアプリケーションのビジネスロジックに関与することはない
- What is SRE
- SREはDevOps文化を実装する方法の1つに過ぎない、クラスSREはDevOpsを実装する
- SREの主要な焦点はプロダクション
コードを開発し、本番稼動させただけでは、まだ全体像が見えてきません。誰かが本番環境を維持し、健全な状態に保つ必要があるのです。そして、これが私の世界モデルにおけるSREの位置づけです
- SREチームの主要なフォーカスエリアについて（順番が重要）
- レスポンス: 効率的なインシデントレスポンスの文化を確立する
- 観測性: インストルメント化、監視、アラート化
- 可用性と信頼性: SLI/SLOと障害管理
- デリバリー: 効率的な構築、プロビジョニング、デプロイメント（IaC、CI/CDなど）
- What is Platform Engineering
- プラットフォームエンジニアリングは、Dev、Ops、SREの立場から効率的に使用できるエコシステムを開発することに焦点を当てている
Platform Engineering is not about infrastructure development. Platform Engineering is about enabling others to do whatever they want to do.
- DevOps/SREの関係性を説明してる例色々
DevOps keeps production fresh. SRE keeps production healthy.SRE = focused primarily on production, DevOps = focused primarily on CI/CD and developer velocitySRE works from Production backward. DevOps works from development forward. Somewhere in the middle, they meet.
r-kagaya
- プラットフォーム・エンジニアリングを始めるときに犯しがちな10の失敗についての記事
- Internal Developer Platformsとdeveloper self-serviceの採用はパフォーマンスの高いエンジニアリング組織と低いチームとを区別する要因になっている
- from Puppetの2020年と2021年の「State of DevOps Reports」「DevOps Benchmarking Study」
- プラットフォームエンジニアリングの定義
「クラウドネイティブ時代のソフトウェアエンジニアリング組織のためのセルフサービス機能を可能にするツールチェーンとワークフローを設計し構築する学問分野です。プラットフォームエンジニアは、アプリケーションのライフサイクル全体の運用に必要なものをカバーする、最もよく「内部開発者プラットフォーム」と呼ばれる統合製品を提供します。
- 開発者のセルフサービス
- ソフトウェアエンジニアが複雑なセットアップをよりよく処理できるように、認知負荷のバランスをとる
Kubernetesを中心とした1,000種類のサービスを実行するために、1,000人のKubernetesエキスパートが必要ということではないはずです
- 1 The prioritization fallacy
- プラットフォームチームの大半はオンボーディングと新しいアプリケーションやサービスの作成方法を最適化することから始める
- その頻度は？ROIは？
- 単にスクリプトやGithubのテンプレート機能で良いのでは？
- 正しい優先順位付け
- 以下のような質問をする
- How often deployments are just a simple update of an image?
- How often do they spin up a new environment?
- How often do they onboard a new colleague?
- How often do they add a new microservice?
- How often do they change or add resources (databases, file storage, DNS)?
- How often do they add or change environment variables?
- 発生頻度発生頻度や待ち時間を元に決める
- 以下のような質問をする
- プラットフォームチームの大半はオンボーディングと新しいアプリケーションやサービスの作成方法を最適化することから始める
- 2 The visualization fallacy
- ダッシュボードで可視化するだけでは問題は解決しない
I cannot run away from the nasty problems by just visualizing things in beautiful UIs- 優先順位付けした通り、実際に効率化できる問題に取り組む
- 3 The “wars you cannot win” fallacy
- 1つのツールにまとめることは現実難しく、コストに比して利益も少ない
- 共通化するレイヤー・箇所を見極める
- 4 The “everything and everybody at once” fallacy
- トップダウンで押しつける形でプラットフォームを立ち上げても上手くいかない
- 5 The “the new setup isn’t better” fallacy
- チームは一度に多くのことをやりすぎる傾向があり（あるいは、自分たちの能力よりも早く提供するよう迫られ）、せいぜい平凡なプラットフォームを構築してしまう
- 新しいプラットフォームには新しいというだけでオンボーディングの問題がある
- プラットフォームという観点でMVPをどうやって見つけるか？
Platforms tend to be thick, they have to do a lot of stuff, you’re looking to replicate what you already have that works
- 新しいプラットフォームは、以前のセットアップよりも何倍も優れていなければならない
- 1つのシステムに過剰投資して、ユーザーがエバンジェリストになり、他のチームもこれを欲しがるような、非常に優れたものを作る
- すべてを支配するプラットフォームを作ろうとしない
- 6 The abstraction fallacy
- golden pathsを作る
- 開発者に使いたいを思わせる
- 回避することも可能
- golden pathsを作る
- 7 The “loudest voice” fallacy
- 良いセットアップは、最も強い人ではなく、最も弱い人のために設計されている
- プラットフォームの拡張に参加させ、ワーキンググループに参加させ、あることがなぜこのように行われるのかを明確にすることで、一部の人ではなく、より広いコミュニティのためになるように
- 8 The freedom fallacy
- シャドーオペレーションを発生させない
- チームが処理できる認知負荷の度合いに合わせて最適化する
Kubernetes上で1000種類のサービスを動かすには、1000人のKubernetesエキスパートが必要なはずがない
- 9 The “Google/Facebook/Netflix” fallacy
- あなたはGoogleやFacebook、Netflixでもなければ、Spotifyでもない
- 資金がない、リーチがない、規模がないなど、様々な面で
- 彼らがやっていることを真似ることはできないし、してはいけない
- 内部のユースケースを詳しく知らない可能性が高い
- 最近、誰もが開発者ポータルを構築し、新しいマイクロサービスを必要とする場合に最適化している
- しかし、実際に新しいマイクロサービスを作るのはどれくらいの頻度か？
- ストリーミングの世界的リーダーであれば頻繁に行うかもしれないが、ドイツ銀行であれば、そうそうあることではない
グループやコンサルタントが、これらのブランドと比較するようなことがあったら、とても批判的になってください。このような比較はあまり意味がありません。コミュニティに参加し、同業者と話し、セットアップが実際に比較可能であることを確認しましょう。
- あなたはGoogleやFacebook、Netflixでもなければ、Spotifyでもない
- 10 The “compete with AWS” fallacy
- 自分のチームが特殊だと思いんでしまう
- 結局のところ、99％のケースで同じことが行われている
- 車輪の再発明はしない
- AWSには絶対に勝てない
- プラットフォームを構築する際には、自社のコンテクストに特化したものに焦点を当てるか、可能な限りツールを使用するようにする
- 専門的なツールを作りたいならTerraformやAWS、Humanitecに応募すべき。それ以外の場合は時短に繋がる活動に焦点を当てるべき
- 自分のチームが特殊だと思いんでしまう
- Where to start
- IDPを構築する際に優先させたい正しい事柄について考える
- つまらない可視化の罠にはまらない
- プラットフォームを社内で売り込む準備をする
- 人間は本来、変化に抵抗するもの
- IDPを展開する際には、文化的な疑問が生じることも想定しておく必要がある
r-kagaya
真の開発者の生産性は、ツールや生産されたコード行数を計測することにあるのではない- 開発者のフローに最も大きな影響を与えるのは、コードを実現するためのあらゆるもの
- -> developer enablement
- developer enablementのkey activities
- Talent Development
- how we onboard, develop, and nurture talent
- Collaborative Teaming
- how we communicate and work together
- Knowledge Management
- how we capture and leverage internal knowledge
- Capacity Planning
- how we estimate, assign, and measure work
- Enablement Health
- how we measure efficiency and productivity of teams
- Culture Leading
- how we align to common values and organizational vision
- Talent Development
- エンジニアリングリーダーはイネーブルメントの責任を負うべき
- エンジニアリングの観点から、developer flowを改善し、チームのパフォーマンスを向上させるような変更を実施する
チームの生産性を高めるために利用できる唯一のコントロールを譲り渡すことになる
- 一部の企業はイネーブルメントに焦点を当てたチームの組成を実験的に行っている
- 開発者ツールを管理したり、DevOpsツールを導入したりするのではなく、開発者がより生産的で満足のいく仕事ができるように、開発者の仕事の進め方を全体的に見ることに重点を置いく
r-kagaya
- 優れたチームは、高品質のソフトウェアを提供するために、常にプロセスを改善している
- 良い指標とは理解しやすく、遅行性ではなく先行性があるもの、つまりソフトウェア開発の成功を予測できるもの
- cycle time
- あるタスクの作業が開始された瞬間から、その作業が完了するまでの総時間
- あるアイテム（ストーリー、タスク、バグなど）に対して作業を開始してから、デリバリーできるようになるまでの経過時間を示す指標
- -> タスクを完了するまでにかかる時間
- why?
- 推測ではなくデータに基づいた見積もりを提供することができる
- サイクルタイムが速ければ速いほど、エンドユーザーに新しい機能をより早く提供することができる
- 安定したシステムでは、仕掛かり品（WIP）、サイクルタイム、スループットの間に関係があるとされている
- 同じ作業ペースを保つ（つまりスループットが変わらない）場合、WIPが下がればサイクルタイムも下がる
r-kagaya
- 「開発チームの生産性向上」三つのポイント
- 非効率な部分を発信・共有する
- 目的に対して現状のボトルネック、目指す姿と課題を明確にする
- 能動的に社内の課題を拾いに行く
- 「非効率だよね」の部分を深ぼる
- 技術探求の時間をつくる
- 1と2を継続する
- 課題とゴールを明確にし、問題発生時の対応含め全体のフローを意識し、長期的に取り組む
- 非効率な部分を発信・共有する
r-kagaya
- 「推測するな、計測せよ」
- 数値として生産性を可視化することで、客観的に組織の変化に気づける
感覚的には生産性が落ちたと感じていても、本当に落ちているか、どのくらい落ちているかを客観的には見れていないことも多い- まず可視化して変化を見ていく
- 簡単に取れる数字から始める
- チーム別・期間別のデプロイ頻度や、開発リードタイムを測定
- Google Apps Script * GitHubのAPIで、closeされたPull Requestのリストを出力
- Data Studioで可視化
- チーム別・期間別のデプロイ頻度や、開発リードタイムを測定
- four keysの数値
- デプロイ頻度は最上位のElite
- 変更のリードタイムは上から2番目のHigh
- 指標を継続して取りながら組織の変化に気づいたり、理想の状態を目指してPDCAを回すことが大事
- 必ずしも上げ続けることが正解ではなくあくまで組織の健全さを測る指標の一つとして扱うべき
- 継続してモニタリングしていく中で、急に数値が悪化した時は組織に変化が起こっている兆候
- 変化に敏感に気づけるように
- 継続的に追いながらPDCAを回すことで生産性が向上し、結果として今まで以上にお客さまにより早く価値を届けられるようになる
- 継続してモニタリングしていく中で、急に数値が悪化した時は組織に変化が起こっている兆候
-
僕らが大事にしたい生産性の本質は、エンジニアの開発体験エンジニアが快適に開発できているとか、モチベーションやオーナーシップを持って開発に取り組めているとか。そういったことを総合的に測るためにもこの指標を追っていきたい
r-kagaya
- 新機能開発が先行し、開発効率が悪化した結果開発者が増加してもスピードが出にくい状況になっていた
- DX Criteria
- CTO協会監修のデジタル化とソフトウェア活用のためのガイドライン
- 目的: 超高速な事業仮説検証能力を得ること
- Newspicksでの診断結果は「新機能開発が先行し、開発効率が悪化した結果開発者が増加してもスピードが出にくい状況になっていた」を象徴する結果に
- four keys / LeanとDevOpsの科学
- 速度と品質はトレードオフではない
- 組織間の差は大きく、さらに開き続けている
- 継続的デリバリやDevOpsへの組織的な投資の差
- four keysnの中でも計測難易度が存在
- まずはデプロイ頻度だけKPIとする
- エラー数やSLOなどの品質指標は定点観測し、低下傾向に出なければ良しとする
- エラー数
- レスポンスタイム
- セキュリティリスクアセスメントの自動化
- お問い合わせ起因チケットの生存期間
- MTTRや変更失敗率は定点観測に向かない
- デプロイ頻度改善のためのアクション
- ひたすらデプロイを簡単にした
- マージ + slack botでデプロイ
- canary + rollingデプロイに
- 手動確認項目を自動化
- ひたすらデプロイを簡単にした
- 結果
- デプロイ作業にかかる時間が30分~1時間が、5分に
- 開発者一人当たりのデプロイ頻度は2~3倍に
- 権限の低い開発者も安全にデプロイ可能に
- デプロイが面倒で複数コミットまとめてデプロイしていたのが激減
- 定点観測し、意識を高めると共に、改善を讃える
r-kagaya
- ヤフーがOSSで開発されている「Screwdriver」
- もともと米Yahoo! Inc.（現: Verizon Media）社内で開発されていたCI/CDツール
- 2016年ごろから完全に一から作り直すと同時にOSSとして開発を進めるようになった
- CI/CDツールとして以前からJenkinsなどを導入していたが、部分最適になっていて、社内での集約や標準化をいかに進めるかという課題が存在
- 会社全体としてリリースするソフトウェアの品質を上げ、セキュリティを担保していくにあたり、米国で開発を進めていたScrewdriverを採用
- デベロッパープロダクティビティを考える部門の課題
- 中央集権にし、完全な標準化を行うことの難しさ
- 会社規模が大きくなるほど、各チームの自立心が旺盛で、それぞれに独自のやり方があり、統一が難しい
- Screwdriverでは、テンプレートやコマンドをチーム側である程度自由に作れるようにしておき一定の自由さと利便性を確保するという方向性
- 中規模くらいまでだと中央集権化がうまくいっている組織もある
- 500人くらいのエンジニアチームを抱えるイスラエルの会社
- 全社規模でビルドの方式は1つに統一
- アプリケーションのチームは、ビルドスクリプトは一切書かない
- デベロッパープロダクティビティの部門がゴールを設定し実装
- ex) 「テストに時間がかかっているので、今月の目標はテストの並列化にしよう」
- アプリケーションのチームにとっては、ある日テストが一斉に並列化されていたというイメージ
- 連邦政府のソフト開発企業
- オブジェクト指向の継承を彷彿させるようなテンプレートシステムを独自に構築
- 「退役軍人省向けのシステムでは、ビルドプロセスにセキュリティスキャンが必要」というルールがある
- がどのツールを使わないといけないかまでは決まっておらず、アブストラクトメソッドのように定義されている
- システム開発チームがツールを選定し、テンプレートを継承していく
- 上記のような「自由度」が、デベロッパープロダクティビティチームの生産性に貢献していないというのも事実では
- 「下のレイヤをアプリケーションの開発チームにコントロールさせてあげないといけない」のか？
- 昔と違い、OSを含む実行環境やインフラの違いなどを考えてアプリケーションを作る必要はないのでは？
- ヤフーでは「サービスが100以上あって、サービスごとに開発環境や開発プロセスを最適化している」のが全社統一のハードルに
- あくまでも「推奨」であって、それを受け入れるかどうかはサービス側が決める
- 理想は「好きなやり方でやっていいけれど、俺たちの言うとおりにやれば、生産性は10倍上がるよ」みたいな空気を作れて、誰もそれ以外の方法でやろうと思わなくなったりする状況
- Googleなどデベロッパープロダクティビティチームが最強レベルに達している組織
- OSSコミュニティは「やりたいことをやってもらう」と拡大する
- 最初は「CI/CDツールはこうあるべき！」という自分の考えをもとに、プロダクトを作っていた
- 途中から「他の人が面白いことをしやすい場を作る」ことを意識するようになった
- すると「こうあるべき！」という考えを持っている大勢の人が、どこからともなく集まってきて、作ってくれる
- 「自分のやりたいことに、他の人たちをどうやって巻き込んでいくか」よりも、みんながやりたいことを、それぞれ好きにやれるような「砂場」を作っておく
r-kagaya
- Mean Time to Detect (MTTD)
- 問題を発見するのにかかる平均時間
- 算出方法
- 一定期間のインシデントの総数を調べる
- インシデントの開始時刻とチームがインシデントを検出するのに要した時間の差を計算
- Mean Time to Failure (MTTF)
- 欠陥のあるシステムが故障するまでに稼働し続けることができる平均時間
- MTTFはDevOpsチームがミッションクリティカルなシステムで使用されているコンポーネントの状態を追跡するのに役立つことが多い
- MTTFによってDevOpsチームは、システムコンポーネントが交換が必要になるまでにどれくらいの期間稼働し続けるかを把握することができる
- MTTFデータは、数百または数千のシステムコンポーネントを同時に何時間、何日、何週間も稼働させることで収集される
- DevOpsチームはMTTFデータを入手すると、ミッションクリティカルなシステムの信頼性を把握することができる
- Mean Time Between Failures (MTBF)
- 信頼性と可用性の指標の一つ
- システムまたはコンポーネントが、指定された条件下で必要な機能を一定時間実行する能力を測定するために使用される
- MTBFを計算するために、DevOpsチームは日常業務におけるシステム障害間の経過時間を調べる必要がある
- Mean Time to Resolve (MTTR)
- 故障したシステムを修復までの平均時間
- DevOpsチームが障害発生後に非稼働状態のシステムを修復するために必要な平均時間を示す指標
- 4つの障害すべてを解決するのに合計60分必要な場合MTTRは15分になる
- Information Technology Intelligence Consultingの最近の調査では、組織のダウンタイムの平均コストは、2008年から2016年の間に毎年増加していることが示されている
- さらに98%の組織が1時間のダウンタイムに10万ドルのコストがかかると回答し、33%が1時間のダウンタイムに100万ドルから500万ドルのコストがかかると指摘していることが明らかになった
- 要な測定基準に組み込むための5つのヒント
- ビジネス目標を設定する
- 測定基準を持つためだけに測定基準を使用する必要はない
- 測定基準は短期および長期目標をサポートするものでなければならない
- データ駆動型アプローチで測定する
- KPIはチームが有意義なビジネス改善を行うために使用できるデータと洞察力を与えるものでなければならない
- したがって、すべてのKPIは測定可能でなければならない
- チームの進捗を測定できれば、現実的な目標を作成し、その達成に向けた最適なステップを決定することができる
- ビジネス目標を設定する
- 定性的・定量的なKPIを導入する
- ユーザーフィードバックのような定性的KPIと、日次アクティブユーザーや収益のような定量的KPIにより、あらゆる角度からパフォーマンスを追跡することができる
- チームはこの情報をもとに、日々の取り組みを適宜マッピングしていくことができる
- トレンドを特定する
- データを深く掘り下げることでチームは傾向を見出すことができる
- この情報をもとにチームはデータ駆動型の予測を行うことができる
- スコアカードを使用する
- DevOps KPIスコアカードを使用すると、DevOpsチームは関連するすべてのメトリクスを一度に簡単に確認することができる
r-kagaya- 特にマネジメントの観点からのテクノロジー業界の聖杯（または白鯨）は？
- 開発者の生産性を測定すること
- 「測定できなければ計画もできない」という非常に一般的なフレーズがある
- Why measure?
- データは、今後の取り組みに優先順位をつけるための基礎となるもの
- 測定することはとても理にかなっている
- 開発者の生産性を測定・管理することは、これまでずっと困難だった
- 最高の開発者は最低の開発者よりも 10 倍も効率が良いという理論があり、それはデータによってほぼ裏付けられている
- 開発者の給料がこの桁外れの差を反映していないことを考えると、10倍のうちの1人を見つけて、1倍や2倍の人と同等の割合で雇うことができれば、企業にとっては明らかにお得
- 「...上位20％の人は、生産高の約50％を生み出している（Augustine 1979）」という分析まで生んでいる
- 今までの開発活動定量化
- Hours worked
- タイムトラッキング
- Source lines of code (SLOC)
- コード行数で生産性をはかる
- 問題点だらけ
- 開発者は無意味にコードを追加して数字を積み重ねることができる
- 1000行の解決策よりも200行の解決策の方がより速く、より高性能かもしれない
- コード削除が考慮されない
- 5000行のバグがあるコードは、1000行のバグがないコードより悪い
- 開発者はリファクタリングの代わりにコードをコピーペーストし、膨大な技術的負債と貧弱な設計をもたらし、バグの発生確率を著しく増加させる
- システムの規模や複雑さを知るために集計して追跡するには面白い指標
- 個人やチームの生産性を図る目的では使えない
- Bugs closed
- Function points
- Defect rate
- 各開発者が生み出したバグの数を測定する
- 不適切な理由
- 機能開発よりもバグフィックスを優先する
- 大きなプロジェクトに取り組む意欲を失わせる
- すべてのバグが同じとは限らない
- バグ1：誰かが「戻る」ボタンを使用すると、本番サイトの顧客データがすべて削除されるバグがある
- バグ2：フォームのフィールドが左寄せにならない
- バグ3：顧客がうるう年を2回またぐ日付を入力した場合、期間の計算が1秒ずれる
- 人はよく機能をバグと勘違いする
- 要件の欠落はバグではないがバグとして報告されることがある
- 1つのバグに複数のバグレポートが存在することがある
- 興味深いものだが、生産性を知るには十分ではない
- Accuracy of estimation
- 開発者は最悪のシナリオを想定して見積もるようになる
- Story points
- 一貫したストーリーポイントがあり、各開発者が1スプリントあたりどれだけのストーリーポイントを完成させたかを把握すれば、開発者のパフォーマンスを推定することができる
- ストーリーポイントの基準を一定にするのが難しい
- ストーリーポイントだけにコミットすることになってしまう
- ストーリーポイントは生産性の指標ではない
- Scrum AllianceのThe Deadly Disease of Focus Factorsというホワイトペーパー冒頭
- 「フォーカスファクター」
- 一貫したストーリーポイントがあり、各開発者が1スプリントあたりどれだけのストーリーポイントを完成させたかを把握すれば、開発者のパフォーマンスを推定することができる
- Hours worked
- Developer productivity is a myth
- "測定できなければ、計画は立てられない"
- DPEの文脈では間違っている
- 開発者が行うすべてのことが、客観的かつ一貫して測定可能であると仮定しているが、開発者の生産性を測る信頼できる客観的な指標はまだ存在していない
- "測定できなければ、計画は立てられない"
- ではどうするか？
- 生産性を直接測定しようとするのではなく、生産性、進捗や顧客への価値提供の進捗を阻害するものを測定する
- 何か進捗を阻害するものがあるたびに、それが何であるか、解決に要した時間を記録しておく
- 特に、外部との依存関係がある場合
- IT部門が仮想マシン準備するのに2週間かかっている、もしくはコードレビューが3日間も放置されているかもしれない
- 何か進捗を阻害するものがあるたびに、それが何であるか、解決に要した時間を記録しておく
- Time before delivery
- ワークアイテムを要求してから、本番で使用できるようになるまでにかかる時間を追跡する
- 作業の単位がある程度一定であれば、予測可能性が得られる
- Time in progress
- 作業が始まってから、リリースされるまでにかかった時間の合計を追跡するもの
- Time in phase
- 設計フェーズ、開発フェーズ、QAフェーズ、コードレビューフェーズ、そしてデプロイメントフェーズまですべてのフェーズを追跡することで、時間のかかるフェーズを特定し、最適化の余地があるかどうかを確認することができる
- Flow control
- 一度に多くのことに取り組むと生産性が落ちる
- QAチームが毎週4つのストーリーしかテストできないのに、開発者が毎週10のストーリーを仕上げているとしたら、週に4つの機能しかリリースされないことになる
- ボトルネックは開発者のスピードをではなく、QAチームのスループット
- 開発者が一度にたくさんのアイテムを引き受けるのではなく、一つのアイテムに集中し、それを完成まで追い込むことが理にかなっている
- また、一度に手がける総量には、ある程度の制限が必要
- リーン、かんばん
- バリューストリームをマップ化する
- 進捗を阻害する可能性のある外的要因も含める
- ストーリーが各フェーズで費やした時間を追跡
- 開始点と終了点を定義
- WIP (Work In Progress)を制限する
- 上記で説明したように、下流のボトルネックを解消せずに開発者の生産性を上げると、無駄な作業が発生し、顧客に付加価値を提供することができなくなる。
- サービスクラス
- いくつかの生産上の問題が優先されなければならない場合がある
- ex) 標準、迅速、固定納期
- Adjust Empirically
- 追跡しているデータからボトルネックや非効率性を見つけ、その解決に取り組む
- バリューストリームをマップ化する
- 生産性を直接測定しようとするのではなく、生産性、進捗や顧客への価値提供の進捗を阻害するものを測定する
r-kagaya
- 品質を犠牲にすればスピードは得られる？
- 短期的には得られる？
- 中期的には逆効果
- 長期的には致命傷
- 品質
品質とは誰かにとっての価値である- 外部品質と内部品質
- 犠牲になりがちなのは内部品質
- どのような内部品質を犠牲に？
- 保守性(Maintainability)
- モジュール性
- 再利用製
- 理解容易性
- 変更容易性
- テスト容易性
- 保守性(Maintainability)
- スピードと品質(保守性)をトレードオフと考えるのは典型的な誤解
- コードの品質を高く保っていたからからこそ速い
- 品質は劣化すればリードタイムの増加に跳ね返る
- プロセス品質が下がると手戻りが増え、リードタイムが長くなる
- 内部品質を下げると、レビューや実装の複雑さなどによるリードタイムが長くなる
- 外部品質を下げると、学びまでのリードタイム増加や、障害発生によるリソース枯渇によりリードタイムが長くなる
- 利用時の品質を下げると、対応にリソースを持っていかれリードタイムが長くなる
- 手戻りの時間は学びを生まない時間
- 品質を下げる = 学びの速度低下を許容するということ
- 品質劣化は手戻りのみならずリードタイム増加に繋がってしまう
- リードタイムが増加すると仮説検証プロセスが回らない
- 本当の関係
内部品質がスピードを生み、スピードが学びのループをうみ、学びのループが外部品質を生み、外部品質が競争力を生み、競争力が売上を生み、売上が内部品質を育む片方を犠牲にした場合、知らぬうちにもう一つも犠牲にしている
- 現代における質とスピードを図るキーメトリクス
- four keys
- テスト自動化の損益分岐点は4回
- 手動テストと自動化されたテストのコストが逆転する
- 内部品質への投資の損益分岐点は1ヶ月以内に現れる
- キャディの例
- sprintの20~30%をリファクタリングように投資
- 1,2ヶ月経った後にデリバリー速度が高まった
r-kagaya
- DPE(Developer Productivity Engineering)
- データ解析と高速化技術を利用して、ビルドからテスト、CIまで、重要なソフトウェア開発プロセスを高速化し、より効率的にするソフトウェア分野
- 主な目的は、フィードバックサイクルの高速化、より信頼性の高い実用的なデータ、満足度の高い開発者体験の実現など
- DPEは、アジャイル、リーンソフトウェア開発、DevOpsの方法論とツールの導入以来、ソフトウェア開発とデリバリーにおける最も重要なムーブメント
- 多くの企業では、開発者の生産性を向上させるための取り組みや実験は、主にリードエンジニアが主導してきた
- 場当たり的なアプローチではなく、DPE専門チームを設立する時期に来ているのではないか
- DPEが有意義である理由
- Focus
- どのような分野でも卓越した成果を出すには専用のリソースが必要
- 専用チームが存在する意味
- DPEチームが存在するだけで経営陣の優先事項である事が明示される
- 専門チームを立ち上げることで、目標と測定基準が必要であることを認識し、理想的には、目標達成を少なくとも1人の専任の仕事としてフォーカスさせること
- 自律性
- DPEを成功させるためには、生産性と効率性に関して開発チームを支援することに情熱と親和性を持つ専門家を見つけることが必要
- 専門チームの存在により、新しいビジネスや技術分野が成熟するための一里塚となる
- この分野で高い成熟度を達成している、あるいは目指している多くの著名な企業が、とっくにDPE専門チームを設立していることは注目に値する
- DPEチームが存在するだけで経営陣の優先事項である事が明示される
- Return on Investment
- 専任のチームを置かなくても、DPEのメリットを享受することはできる
- 専任チームと比べて、メリットの大きさと持続性はそれほど大きくはない
- ビルドキャッシングやテストなどのDPEビルドおよびテスト高速化技術を使って、平均ビルド時間を数分短縮した場合の年間コスト削減額は簡単に数値化できる
- エンジニアリング1分あたりのコスト平均ビルド時間短縮分年間平均ビルド数
- 専門チームによりビルド時間やテスト時間が長期にわたって悪化しないようにすることができる
- 多くの中規模開発チームにとって、エンジニアリング年数で言えば2桁、予算で言えば数百万ドルの節約にすぐにつながる
- DPE専任チームとツールへの投資を何倍にもして正当化することができる
- その他のハード面、ソフト面での無数のメリットも
- ソフトウェアインシデントのMTTRの短縮、flaky testsや回避可能な障害の管理の改善、CIリソースの効率的な消費なども
- 多くの中規模開発チームにとって、エンジニアリング年数で言えば2桁、予算で言えば数百万ドルの節約にすぐにつながる
- Competitive Advantage
- 多くの企業にとって採用競争に負けないことはミッションクリティカル
- 優秀な人材を確保できるかどうかは、開発者の体験の質にかかっている
- 開発者の体験を向上させる最善の方法は、ビルド完了待ち時間やデバッグなど、開発者が嫌がることに費やしていた時間を取り戻すこと
- その時間を、つまりエンドユーザーを喜ばせる優れたソフトウェア機能の構築に費やすことができるようになる
- 最近では、多くの企業がDPE専任チームの存在を採用や人材確保のツールとして利用している
- 開発者にやりがいのある経験を提供するという企業の姿勢を示すもの
- 企業には、イノベーションやDXチームなど、競争力の獲得や競争力維持を目的とした戦略的イニシアチブを推進するための専門チームをあらゆるレベルで設立してきた歴史がある
- ビジネスプロセスエンジニアリング（リーン、シックスシグマなど）、製造（総合品質管理、JITなど）、産業プロセスエンジニアリングなどの分野で生産性と効率性の向上を目指す専門チームを見かけることは珍しくない
- 現代ビジネスにおけるソフトウェア開発とデリバリーの戦略的重要性を考えると、ソフトウェアビルドとテストエンジニアリングは同じ優先順位であるべきではないか？
- Focus
- Conclusion
- 開発者の生産性向上は、開発者が暇なときに行う非公式な、reactiveで、場当たり的な仕事と見なすべきでない
- 先進的なエンジニアリングチームの発見
- (1) システム的な開発者の生産性向上には組織的な取り組みが必要であること
- (2) DPEのビジネスケースには問題がないこと
- (3) 行動することで持続可能な競争優位性が得られること
r-kagaya
- RFS(Robust Foundation for Speed)
- グループ全体の非連続的な成長を支えるため、ビジネスの共通基盤に潜む複雑な技術的課題の解決と抜本的な強化を図る
- 「技術基盤への投資はより早い段階から始めた方がいい」
- どうしても新機能の開発に力を入れたくなる
- 「より良いサービスになっています」と分かりやすく伝えられる
- エンジニアも貢献できている実感を得やすい
- スタートアップのうちはそれでいいが、新機能のリリースに注力し続けると、あるタイミングから基盤がボトルネックになり、プロダクトがスケールしにくくなってしまう
- メルカリもこの数年でそういうタイミングに
- 「マーク・ザッカーバーグに会ったときに『資金が集まってもう一度挑戦できるとしたら何に投資するか』と聞いたら、『早い段階で半分以上のリソースをプラットフォームに投資したい』と即答された」
- テクノロジーで世界的に影響を与える企業ならば、それほどまでに基盤への投資を重視する
- どうしても新機能の開発に力を入れたくなる
- 当時のヤフーの話
- 開発組織の体制が「逆三角形型」に近い構図になっていた
- 逆三角形の上側がフロントエンドなどのユーザーに近いところで、下側がインフラ、という構造
- 通常、開発要求は各機能のフロント側からバックエンド、インフラへと落ちていく
- フロントエンドの人数が多い逆三角形型だと、フロントエンドから寄せられる多大な要求を、インフラチームが引き受けきれなくなってしまう
- すると改善が進まないし、下側がボトルネックになってしまう
- これを「三角形」とはいわずとも、台形くらいまでにしましょう、という試みを行った
- CTOのトップダウンで、フロントエンドからインフラ側へ数百人単位の部署異動を行った
- メルカリとヤフーでは状況が違うので、単純な比較はできない
- が気付いた時には「もう手が付けられない」という状態に陥ることは、可能な限り事前に避けたい
- それは当時と今でも共通していること
- 開発組織の体制が「逆三角形型」に近い構図になっていた
- 「開発のボトルネックを率先して排除していくためにも、技術基盤にしっかり投資しましょう」
- ↑RFSプロジェクトを本格的に進めることになった経緯
- RFSプロジェクトを進め方
- 今ある仕組みを解き明かし、不明瞭なところを明らかにし、改善する。この積み上げですね。
- 無人化システムをの蓋を開けて、勇気をもって解析すして、最適な形に作り直していく
- 「計測」
- 説明責任を果たせるように
- 「この機能を改修したけど、実際に意味があったのか」といったことから、「これだけコストをかけて基盤強化に踏み切ったけど、その価値があったのか」というところまで、全て理屈で説明できなければいけない
- そのために数字が必要
- 数字が取れなければ改善したかどうかの結果が分からない
- 何となくの雰囲気で語ることになってしまう
- 雰囲気や仮説が重なると、何も良し悪しの判断ができまい
- 「No measurement, No improvement（計測なくして、改善なし）」
- ヤフー時代宮坂学さんの言葉
- 曖昧さをなくし、エンジニアリング組織全体のあらゆるアクティビティーの全てを数字で測ることができるようにすることもRFSプロジェクトの大きな目的の一つ
- 説明責任を果たせるように
- 今ある仕組みを解き明かし、不明瞭なところを明らかにし、改善する。この積み上げですね。
- 測ろうと思えば、何だって測れる
- 測れないと思っていることに関しては決めの問題
- 一つ基準をつくったら、そこから相対的に見ればいい
- RFS後の世界
- エンジニアからすると指標がハッキリするので判断しやすいという反面、よりいっそうサボれなくなる
- これまでは「この機能を作りたい」といった目的で機能開発をすることができたかもしれない
- 今後はそうはいかない
- 機能開発の提案を通すなら、「ここの改善が寄与しているかどうかを測るためのメトリクスはこれで、このメトリクスを〇%向上させます。そのためにこの機能をリリースして、結果を見ます」
- という説明をエンジニアがしなければいけない
- 機能を作ること自体には1円の価値もなくて、それによって何をどれだけ改善するかが重要
- エンジニアリングはあくまで問題を解決するための手段なので、解決した問題のインパクトが大きければ大きいほど価値がある
- 数字を元に提案したり、効果について考えたりすることができるようになると、より価値の大きい仕事ができるようになるはず
- 「プロブレムソルバー（問題解決者）」としてプロフェッショナルになれる
- 技術基盤投資の意義
- 技術基盤が整うことによって、まずはプロダクトが作りやすくなる
- これまで発生していた基盤部分のボトルネックや、関係各所との調整コストがかなり低減されるはず
- するとよりお客さまへの価値貢献にコミットしやすくなる
- エンジニアのキャリア構築の面でも有利に働くはず
- 技術基盤に投資しているテックカンパニーでは、エンジニアが成果を出しやすい
- GoogleやAmazonのエンジニアって、大体1～2年で次の会社に移る人も多い
- それほど短期間でも「良い成果を上げて良い評価を得て、報酬が上がる」というサイクルが実現できるから
- ほんの1～2年在籍しているだけで、ネクストキャリアに有利な実績を残せるから
- 技術基盤が整うことによって、まずはプロダクトが作りやすくなる
r-kagayaDORA Metricsのデプロイ頻度について
r-kagayaPullRequest作成からマージまでのリードタイムをKPIに改善サイクルを回した話
r-kagaya- 「マネジメント」とは
- 開発力の最大化と効率化
- メンバーの活躍を測定し、評価すること
- ヘッドカウントを増やすことで戦闘力が上がるなら採用も
- 開発力の最大化と効率化
- 生産性を測る際に重要なのは精度の高低ではなく、常に同じ基準であること
- ex) 開発プロジェクトの工数の見積もりを特定メンバーで行う
- チーム毎のパフォーマンスが測定できる
- 作業時間のトラッキング
- 運用コストが30％を超えるものがあればアラート
- ex) 開発プロジェクトの工数の見積もりを特定メンバーで行う
r-kagaya- メトリクスに関する様々な議論
- 何を測定すべきなのか
- どの程度重視するのか
- 何を避けるべきで、データをどう解釈すべきか？
- あるチームはメトリクスを使用し、生産性、コラボレーション、スピードの向上など素晴らしい成果を上げている一方で、特定のメトリクスの目標を達成する上で、予期せぬ負の結果に苦しむチームもある
- メトリクスをうまく組み込んだチームと、つまずいたチームとの違いは、グッドハートの法則の影響を軽減できるかどうかに大きく左右
- グッドハートの法則
- 「尺度が目標になるとき、それは良い尺度でなくなる」
- インドにおけるコブラ効果
- 一つの指標に集中することがいかに早く意図しない多くの結果をもたらすかを示している
- ある指標を達成することが第一の目標であるようなシステムを設計すると、その条件が満たされるようにシステムが何でもするようになる
- ある指標の目標達成をインセンティブにすると「システム」（社員やチーム）は達成することに焦点を当てる
- 指標は単独で存在するものではない
- エンジニアリングのメトリクスが互いに影響し合う
- スピードを測定できるのであれば、品質も測定する必要がある
- アウトプットを測定できるのであれば、コラボレーションを測定する必要がある
- エンジニアリングのメトリクスが互いに影響し合う
- メトリクスが正または負の相関を持つかどうかは、関係するメトリクス・カテゴリーに依存
- Can you avoid the effects of Goodhart’s Law?
- 測定基準がどのように互いのバランスを取ることができるかを考えることで、グッドハートの法則の影響を回避できる可能性が高くなる
- 測定している測定基準の性質と、どのように操作される可能性があるかを知っておくことは重要
- すべてを測定することはできず、測定できたとしても、焦点が定まらなくなる
- すべてが優先されれば、何も優先されなくなる
- 「自由放任主義」と「銀の弾丸」の中間に位置するのがバランスのとれた測定戦略
r-kagaya- エンジニアリングメトリクスを採用するチームは、通常、2つの課題のうちの1つに悩まされる
- They Focus on Too Few Metrics
- 1つか2つのメトリクスにだけ焦点を当てるとソフトウェア開発プロセスの他の部分に悪影響を及ぼす
- メトリクスハック(メトリクスをゲーム化)が始まる
- ex)
- PRレビューを無視してサイクルタイムに重点を置きすぎると、スピードは上がるかもしれないが、チーム間のコラボレーションが減り、最終的にリリースの品質が低下するという影響
- スピードだけにインセンティブを与えれば、品質、生産性、プロセス、コラボレーションは必然的に二の次に
- ex)
- Analysis Paralysis
- グッドハートの法則の結果を回避するために、可能な限りの指標を測定し、過剰なローテーションを行う場合
- すべてが優先されるなら、何も優先されない
- They Focus on Too Few Metrics
- 問題は成果よりもアウトプットを優先していること
- ex) PRの数を増やす、コードのレビューにかかる時間を短縮
- https://jellyfish.co/wp-content/uploads/2022/08/September-Jellyfish-Deep-Dive_-Building-Your-Metrics-Strategy.jpg
- アウトカムベースのアプローチ
- エンジニアリングの優先順位に対応するエンジニアリングメトリクスのみを優先して最適化
- ex)
- アウトプットの量だけでなく，コラボレーション，作業の種類と影響，プロセス全体の効率も考慮
- 測定しているメトリクスは、チームの長期的なビジョンと包括的な使命を直接反映
- https://jellyfish.co/wp-content/uploads/2022/08/September-Jellyfish-Deep-Dive_-Building-Your-Metrics-Strategy-1.jpg
- ex)
- エンジニアリングの優先順位に対応するエンジニアリングメトリクスのみを優先して最適化
- バランスのとれた測定基準戦略は、測定基準カテゴリ数を制限する一方で、単一のカテゴリに偏らないように設計
- ↓重要な5つの単純化された結果の分類の要約
- 優先順位と結果は組織毎にユニーク
- 優先順位の高い結果に焦点を当て、その結果に沿った一連のメトリクスを選択し、副次的な効果に目を配ること
- 主要なエンジニアリング・チームは、推進したい成果に焦点を当て、チームが目標を達成するのに役立つバランスの取れた測定基準を採用している
r-kagaya- サイクルタイムとは
- 広義にはある種の作業を完了するのにかかる時間を測定する指標
- ソフトウェア開発におけるサイクルタイム
- ある課題に対する作業の開始から解決までの経過時間
- 作業の開始はエンジニアがJiraなどで課題を「進行中」とマークした時点で示される
- 解決は、課題が「解決済み」とマークされたとき
- ある課題に対する作業の開始から解決までの経過時間
- data-driven engineering management
- サイクルタイムを使用して、チームがどの程度速く課題を処理できるかを測定
- サイクルタイムなどの運用指標は効率と速度を測定するために最も一般的に使用される
- 組織、チーム、個人レベルで測定することができる
- 計算方法
- 平均サイクルタイムは、すべての課題の完了までの合計時間（日単位）を、特定の期間とグループで平均化することで算出
- サイクルタイムを元に背景を追うことで何が影響を与えているか特定
- コードレビューに時間がかかっていないか？
- 作業のスコープが適切に設定されているか？
- 特定のプロセスやチームを支援するための追加ツールはありますか？
- 最近のプロジェクト作業で、予期せぬ問題が発生したことはあるか？
- 遅延の原因となる共通の要因があるか？
- チームは頻繁にコンテキストを切り替え、コミットした仕事に集中的に時間を割くことができないか？
- Limitations in issue cycle time
- 指標の正確性がエンジニアがチケットを適切にマークしていることに依存する
- エンジニアが担当した仕事の規模や範囲、プロジェクトやその他の仕事の数などはわからない
- 大規模で複雑な課題ほど時間がかかると予想される
- サイクルタイムを比較することは危険であり、サイクルタイムが長いことがデフォルトで悪いと考えるのは誤り
- とはいえ洞察に満ちた指標ではある
- 多くの場合、開発者は複数のワークストリームに引き込まれ、複数のチケット、ミーティング、その他の作業に時間を割かなければならない
- ある開発者のサイクルタイムが増加傾向にある場合、ハードワークになってないか、負担を感じていないか、その他の問題を抱えていないかどうかを確認することができる
- とはいえ洞察に満ちた指標ではある
- 指標を重要視するあまり、チームがその改善に注力しすぎているケースも
- 他の指標と同様に、サイクルタイムを単独で捉えるべきではない
- サイクルタイムを短縮するインセンティブをチームに与えるようなシナリオではフォローアップとコンテキストが必要
- エンジニアリングのオペレーションを変更した場合の影響を理解するために、サイクルタイムを測定すること
- データ駆動型エンジニアリングチームのツールキットの中核をなすもの
- チームがどれだけ速く価値を提供できるかを測る貴重な指標に
- 過去のサイクルタイムデータは、同じようなスコープの作業が完了するまでの時間を予測するためによく使用される
- 課題サイクルタイム、平均課題サイクルタイム、平均エピックサイクルタイムは、Jellyfish Engineering Management Platformで確認できる測定基準のほんの一部
r-kagayaスピードのメトリクス
- ソフトウェア デリバリー パイプラインのスピードと効率性を評価
- ex)
- スループット
- 変更リード タイム
- スプリントのスピード
- イシューとストーリー ポイントの数
- 完了できたイシューの数と予定していたイシューの数の比較
- イシューの種類ごとの分布割合
- 実行時間
- 平均復旧時間
- 成功率
意欲のメトリクス
- ex)
- 個人とチームの意欲
- コード品質に対する自信
- カバレッジよりも自信を重視する
ビジネスのメトリクス
- ex)
- 企業の成長ファネルのメトリクス
- エンドユーザーにとっての価値
r-kagaya- スタートアップはコードの品質を見失わないようにしながらも、成長にフォーカスしてる
- 多くの技術系スタートアップにとって、急成長と技術的負債の組み合わせは、エンジニアリングの生産性を徐々に低下させる
- エンジニアリング生産性を定義するいくつかの指標を測定し、生産性低下の初期指標を検出することは可能
- Engineering Productivity Paradigm
- エンジニアリングに関連する様々な指標を追跡することで、エンジニアリングプロセスを測定し、最適化しようとするもの
- 目標
- エンジニアリングプロセス内の問題を特定する
- エンジニアリングチームが新機能を提供するのに必要な時間を短縮する
- エンジニアリングプロセスをさらに改善するために、さまざまなプロセス、技術、ツールを試すことができるようにする
- 開発者の生産性をどのように測定するのか
- ex) 医師の生産性を測定
- 担当した患者の数を測定するのは最適なアプローチではない
- 患者数だけに注目すると、多くのことをやろうとし、仕事の質が低下してしまう
- ex) 開発者に「できるだけ多くの機能を完成させるように」と指示
- より多くの機能を提供するが、品質は低下
- アウトプットを反映するチームベースの指標に注目したほうがよい
- ex) 医師の生産性を測定
- engineering productivity approachg
- データを測定することから始まる
- 比較のために、4週間分のデータを収集する前に、現在のエンジニアリングプロセスを何も変えないことをお勧め
- 比較するための十分な過去のデータ
- 比較のために、4週間分のデータを収集する前に、現在のエンジニアリングプロセスを何も変えないことをお勧め
- エンジニアリング・プロセスに徐々に変更を加え、何が開発チームを向上させ、あるいは減速させるかを確認
- 他の条件がすべて同じで、それぞれの変更の効果を確認できるように、一度に1つの変更だけを実験するのがベスト
- データを測定することから始まる
- How Is Engineering Productivity Measured?
- Cycle Time
- リーン生産方式から借用した指標であり、ソフトウェア開発チームにとって最も重要な指標の1つ
- サイクルタイムは最初のコミットから本番リリースまでの時間
- Deployment Frequency
- デプロイメントの頻度は、チームのスループットを反映
- チームのベロシティを把握するのに最適な指標
- Number of Bugs
- 機能が完成してから4週間以内にチームが解決しなければならないバグの数
- この指標は、コードの品質をよりよく理解するのに役立つ
- 品質の高いコードは、機能展開後のバグが少ないはず
- Review to Merge Time (RTMT)
- GitLab の開発ハンドブックで提案
- PRのレビューを依頼してから PR をマージするまでの時間を計測
- RTMTが高いと、フィードバックを待っている間に開発者が作業を進めることができず、異なる課題間でコンテキストを切り替えることを助長してしまう
- Cycle Time
- スタートアップが急成長するとき、エンジニアリングの生産性に目を配ることは重要で
- エンジニアリングチームを効果的にスケールさせ、チームの効率を確保するよりも、機能提供による成長を優先し始めることがよくある
- 技術的負債が急速に増大し、チームの生産性を徐々に低下させることになりかない
- 修正すべきバグの増加
- コードの品質低下
- バグだけでなく、コードデザインも悪くなる
- コードのデバッグが困難になる
- 幸福感や仕事への満足度が低下する
- エンジニアリングチームの効率性を測定し、技術的負債の蓄積を回避したい
- 時間面だけでなくコスト面でも組織に大きな影響を与える
- リワーク率
- マージされてから21日以内に書き直されたコードの割合
- 下流の品質問題の予測測定や、要件が見落とされたことを示す
r-kagaya- Important Metrics to Measure Engineering Team Performance
- Lead Time
- 摩擦が多いプロセス、オーナーシップのないプロセス、明確な説明がないプロセスは、リードタイムに悪影響を及ぼす
- 自動化もリードタイムを決定する重要な要素
- リードタイムは現実的な機能ロードマップを作成するのに役立ちつ
- 現実的なロードマップは、開発者へのプレッシャーを軽減し、全体の雰囲気と定着率に良い影響を与える
- The Percentage of Codebase Issues Resolved
- コードベースが改善されているかどうかを示す最も良い指標の1つは、コードベースのissueの解決数
- Time to Complete a Code Review
- コードレビューは開発プロセスの一部
- 多くの場合、PRには明確な所有権がなく明確な受け入れ基準がない
- PRがいつapproveされるのか、そうでないのかが不明瞭
- 多くのチームでは経験豊富な開発者がほとんどのコードレビューを担当
- 複数の開発者に知識を分散させることが重要
- 誰がコードレビューを行っているか、コードベースへのプルリクエストの受け入れにどれくらいの時間がかかっているかを追跡する
- チームのコードレビュー完了までの時間を遅らせる原因について把握できる
- Lead Time
- How to Improve Your Engineering Team’s Productivity?
- Clear Ownership
- Internal Documentation
r-kagaya- サイクルタイムを構成する4つの主要な要素
- コーディング時間
- PRピックアップ時間
- PRレビュー時間
- デプロイメント時間
- コーディング時間
- 関連要素
- 仕掛かり品が少ないこと
- PRサイズが小さいこと
- 要件が明確であること
- コーディング時間が長くなる原因
- タスクが大きすぎる
- タスクが難しすぎる
- タスクが滞留している
- 関連要素
- PR pickup time
- PRが作成されてからレビューを開始するまでの時間
- 短いということは、チームワークが良く、レビュープロセスが健全であることを意味
- PRの作成からレビューまでの時間が長いコードは、顧客に価値を与えることができるのに、ただそこに置かれているに過ぎない
- PR pickup timeが長くなる原因
- PRの存在に気づいていない、誰もアサインされていない
- チームが忙しすぎる
- レビューをする時間を確保するのが難しい or 他のことを優先してレビューを先延ばしにしてしまう
- PRが大きすぎる
- 短縮するには
- レビューが必要なPRを開発者に通知
- 各チームメンバーの作業量をモニター
- 全員がレビューを行う時間を確保し、全体の開発スピードを最適化
- PRを減らし、小さくまとめる
- PR review time
- コードレビューを完了させ、PRをマージするのにかかる時間
- PR review timeが長い原因
- PRが大きすぎる
- レビューを担当する人が少なすぎる
- 数人の担当者にレビュー依頼が集中しボトルネックに
- 他の仕事に振り回される
- レビューの優先順位を下げ、別の仕事を優先
- バグを発見したり、優先度の高い機能のリクエストを受けたりすると、レビューが後回しにされる
- レビューのことを忘れてしまう
- 開発者がレビューを始めたものの、別の作業に移り、レビューを忘れる
- 通知の仕組みがなければ、レビューは何日も何週間も「進行中」のまま
- 短縮するには
- 小さく、頻繁にコミット
- PRのスコープが小さければ小さいほど、レビューがしやすくなり、より早く本番環境に導入することができる
- ペアレビュー
- 全員がコードベースに関する知識を広げることができる
- 標準的なコードレビューチェックリスト導入
- PRを忘れないための自動通知
- 小さく、頻繁にコミット
- Deployment time
- ブランチがマージされてから、コードがリリースされるまでの時間
- コードのデプロイに時間がかかればかかるほど、失敗したデプロイの再試行、障害からの回復、顧客への価値提供に時間がかかることになる
- Deployment timeが長くなる原因
- 承認者のボトルネック
- チームによってはPRをマージすることを一部の開発者だけに許可している場合が
- 遅いテスト
- コードの変更が大きすぎる
- 大きなタスクやPRは、コーディング時間を長くし、レビューに時間がかかるため、人々の意欲をそぐ
- バグが発生する可能性が高いので、開発者はマージするのを先延ばしにしてしまう
- 承認者のボトルネック
- 短縮するには
- チームメンバーがあまりにも多くの仕事を引き受けている場合、チーム内でのアサイン検討
- 高速で効率的なテストスイートを作成
- 小さくコミット
r-kagaya- Commit-to-Deploy Time (CDT)
- コードがコミットからデプロイされるまでにかかる時間
- 理想的にはCベストプラクティスを導入し、十分な自動テストカバレッジがあれば、コミットからデプロイレディ状態まで数分、マイクロサービスでは数秒で到達することができる
- 手動でQAプロセスを実施しているなら、コミットからデプロイまでの時間が長くなり、改善の余地があることを意味
- 動きの速い組織（FacebookやAmazonなど）の多くは、1日に何百回もデプロイしている
- 小規模な組織であれば、毎日デプロイすることが良い目標になる
- コミットが小さければ小さいほど、より早く本番環境に投入することができ、何か問題が発生したときに、より早く修正することができる
- 改善するには、技術的な側面 (テストが不安定である) か、プロセス指向の側面 (ユニットテストだけで済むところを複雑な統合テストを使っている)、あるいはその組み合わせがある
- コードがコミットからデプロイされるまでにかかる時間
- Build Time
- エンジニアや開発者がテストの実行終了を待つ時間は浪費
- テストが大規模で包括的であればあるほど、より多くの時間がかかる傾向
- ex) 2人の開発者がテスト待ちをしていて、どちらも時給50ドル（年間10万ドル）だとすると、10分のビルド時間で約17ドルの生産性損失が発生
- 直接的なコストに加え、市場投入が遅れたことによる「機会損失」コストや、開発者が待機し、また開発に戻るという精神的な「切り替えコスト」など、数値化しにくいコストが発生
- Queue Time
- ビルド時間よりもさらに微妙なのは、ビルドが実行されるまでにエンジニアが待たなければならない時間
- 組織の規模や、同時に開発中の機能の数に大きく依存
- How Often Master Is Red
- masterブランチが動いていない状態
- 不安定なテストスイートや欠陥のあるテストがある場合、「マスター」は簡単に赤になる
- テストカバレッジが低くてもビルドが壊れやすくなる
- 長期間生存したfeatureブランチは巨大なconflictに終わる可能性
- チェンジセットが大きければ大きいほど、コードの他の場所で起こっていることから乖離している可能性が高くなる
- 競争力を維持するための質問
- 開発者は1日に何回「マスター」にマージしているか？
- 私のコードはどれくらいの頻度でリリース可能な状態になっているか？
- コードベースのどの程度がテストでカバーされているか？
- ツールやインフラは最適化されているか？
- 代替ツールやインフラストラクチャーのソリューションによって、どのようなスピードアップやコスト削減が期待できますか？
r-kagaya- What Are Engineering Metrics?
- ソフトウェア製品の測定基準
- What Are the Most Useful Engineering Metrics?
- Cycle Time
- 開発チームがエンドユーザーにどれだけ早く価値を提供できるかを追跡
- Deploy Frequency
- より小さなコードのかたまりをより頻繁にリリースすること
- デプロイのリリースとテストがより管理しやすくなり、全体的な品質も向上する
- Rework Ratio
- チームがエンドユーザーに納品した後に書き直す必要があるコードの量
- コミュニケーションが不十分であったり、レビュープロセスに問題があったりして、将来の品質問題につながる可能性を示唆
- High-Risk Branches
- 手戻りの割合が高いコードブランチの数
- より多くの変更を加えなければならない場合、リスクはより大きくなり、 手直し率の高いブランチは、低品質につながるリスクも高くなる
- Investment Profile
- チームがさまざまな種類の作業に費やした時間
- バグの修正から非機能的なタスクの処理まで
- チームメンバーが労力を費やす作業の種類を表す
- リソースの適宜配分を判断する
- Context Switching
- チームメンバーが、様々な障害によって、ある問題から別の問題へ移動しなければならない頻度
- コンテキストの切り替えが多い場合は、チームが非効率的である可能性が高いことを意味
- WIP Balance
- WIPバランスメトリクスは、チームメンバーに仕事が均等に配分されているかどうかを判断するためのもの
- 各メンバーがどれだけの仕事を抱えているのかがわかる
- あるメンバーには負担がかかり、他のメンバーには負担がかからないという状況を回避することができる
- Days Worked
- チームがイテレーション中に何日活動したかを測定し、燃え尽き症候群を回避することができる
- Cycle Time
r-kagaya- 開発者の生産性測定に関するコンセンサスはほとんどない
- よくある質問・疑問
- 正しい生産性指標とは何か？
- 生産性の自己申告はどの程度価値があるのか？
- 伝統的な生産性の見方である「インプットよりアウトプット」は、開発業務に伴う複雑な問題解決や創造性に適しているのか？
- 開発者自身の生産性に対する考え方が、より「良い一日を過ごすこと」に近いものであることが判明してる
- 開発者の満足度が高いとより良い業績を上げることは別研究でも示されている
- GitHub Copilotの調査におけるポイント
- 生産性を総合的に見る
- SPACEを用いてどのような側面から調査を行うかを決めた
- 具体的にはSatisfaction and well-beingとEfficiency and flowを測定してるっぽい
- 開発者の生の声を取り入れる
- 定性的データと定量的データを含む複数回の調査を実施
- (a)テレメトリーから推測されることを、ユーザーの実際の体験が裏付けているか？(b) 定性的なフィードバックは、大規模なユーザーベースに対して一般化されるか？
- 日常的な開発シナリオにおけるGitHub Copilotの効果を評価する
- 開発者が一日に行うであろう典型的な作業を想定してテストをデザインする
- 生産性を総合的に見る
- Finding 1: Developer productivity goes beyond speed
- スピードアップ以外にも効果が見られた
- 開発者の満足度の向上
- 60～75%のユーザーが、GitHub Copilotを使うことで仕事にやりがいを感じ、コーディング時のフラストレーションを軽減し、より満足度の高い仕事に集中できるようになったと回答
- mental energyの節約
- GitHub Copilotを使うことで、フローを維持し（73%）、反復作業中の精神的労力を節約できたと報告（87%）
- ↑コンテキストスイッチや割り込みが少ない
- Finding 2: … but speed is important, too
- GitHub Copilotを使用した場合、特に繰り返しの多いタスクをより速く完了
- 実験: 95人のプロの開発者を集め、ランダムに2つのグループに分け、JavaScriptでHTTPサーバーを書くのにかかった時間を計測
- 各グループの平均的なタスク完了率と、タスク完了までにかかった時間を測定
- 結果
- GitHub Copilot を使用したグループは、タスクの完了率が高くなった（78%、Copilot を使用しなかったグループは 70%）
- GitHub Copilotを使用した開発者は、GitHub Copilotを使用しなかった開発者よりも55%も早くタスクを完了させた
- GitHub Copilotを使用した開発者は平均1時間11分でタスクを完了したのに対し、GitHub Copilotを使用しなかった開発者は平均2時間41分でタスクを完了
r-kagaya- 優れたDevEx
- 開発者を幸せにし、従業員の離職率を下げるためだけでなく、開発者の生産性とエンジニアリングベロシティを推進する重要な要因
- DevExは非常に広範な用語
- 開発者のウェルビーイングや健全な企業文化、ドキュメントやプロセスの品質、特定のタスクを行うために扱う必要のあるツールの数などを指すことも
- 文化を意味する場合も
- 開発者がリスクを取ってイノベーションを起こすことを奨励し、反復的なタスクやその他の気晴らしに邪魔されることがない
- DevEx: “Make the right thing to do the intuitive thing to do”
- DevExについて重要なことは、良いものを強制することはできない
- 開発者が直感的に正しいと感じるワークフローを設計し、文化を醸成し、ツールを与え、黄金の檻ではなく、黄金の道や舗装された道路を提供する必要がある
- Developer self-service
- プロセスやエラーの起こりやすい手作業に一貫性と再現性をもたらす
- セルフサービスの目標は、開発者が「正しいことを、直感的にできる」ような体験をすること
- ここ数年、開発者の認知能力の過負荷が、質の低い開発者体験を生み出す根本的な悪の一つであることが明らかに
- クラウドネイティブツールとインフラの爆発的な増加、You build it, you run itのトレンド
- 生産性と全体的な経験の質の両方が低下しています。
- 多くのエンジニアリング組織の対策は、新しいクラウドネイティブセットアップの上にガードレールを構築すること
- 開発者が複雑化するツールチェーンをナビゲートするのに役立つプラットフォームという形の内部ツール
- Google、Airbnb、Spotify などのトップクラスの企業から、他の業界にも浸透している傾向で、プラットフォームエンジニアリングと呼ばれている
- Platform engineering on the Gartner® Hype Cycle
-「Gartner Hype Cyclefor Emerging Technologies」 - プラットフォームエンジニアリングとは
- ソフトウェアのデリバリーとライフサイクル管理のためのセルフサービス型社内開発者プラットフォーム（IDP）を構築・運用する学問
- 開発者の体験を向上させ、従業員の不満や離職を減らすこともできる
- 3つのポイント
- https://www.gartner.com/account/signin?method=initialize&TARGET=http%3A%2F%2Fwww.gartner.com%2Fdocument%2F4017457
- "認知負荷、開発者の労力、繰り返しの手作業を軽減するために、社内の開発者用プラットフォームを構築し、開発者の体験を向上させる。"
- "プラットフォームは特定のツールセットやアプローチを強制するものではありません。開発者がソフトウェアを簡単に構築し提供できるようにする一方で、基盤となるコアサービスの有用かつ差別化された機能を抽象化しないことです"
- "プラットフォームエンジニアリングチームは、プラットフォームを（開発者が使用する）製品として扱い、セルフサービス方式で消費されるようにプラットフォームを設計します。"
r-kagaya- DLT（Delivery Lead Time）
- 書籍『Accelerate』（2018年）で広まったソフトウェアデリバリーの指標
- コードが本番環境に導入されるまでの時間を測定
- 著者はEngineering Insightsシステムの開発を担当
- コミットが書き込まれた時点から本番環境にデプロイされるまでの時間が測定される
- DLTの「ヒーロー指標」の中央値を集計して提供
- PRワークフローに従うチームのDLTの内訳
- DLTに影響を与えるプラクティス
- DLT は単一の数値であるため、構成要素のうちどれが最も大きな貢献をしているかはわからない
- 各チームがどのように作業し、どのような技術スタックで作業しているかによって異なる
- チームがどこを改善できるかをさらに調査するための出発点
- エンジニアリングプラクティス（文化的、社会的、組織的）
- コミットメント・ハイジーンネス
- ペアリング/モビング
- コードレビュー
- トランクベース開発
- プロジェクト能力（技術、実装ベース）
- テスト実行にかかる時間
- テストの信頼性
- 自動テスト、手動テストへの信頼性
- UATとステージング環境の使用
- 継続的なデプロイメント
- デプロイメントパイプラインの実行にかかる時間
- デプロイメントパイプラインの信頼性
- 観測可能性と監視
- How to use Delivery Lead Time
- プロジェクトのソフトウェア納品能力を測定するものであり、チームのソフトウェア納品パフォーマンスを測定するものではない
- ex)
あるチームは、デプロイに何時間もかかる古いモノリスの小さなセクションを担当し、薄っぺらなテストを行い、自動テストが不足していることがあります。このような場合、DLT を出発点として、現状での運用コストを定量化し、状況を改善するために必要な投資について主張することができます。
- What is a good Delivery Lead Time?
- https://static.isthisit.nz/images/2022-08-06-Delivery-Lead-Time-In-Practice/dora-metric-guide.png
- ↑には測定する時間スケールの観点が不足している
- ex)
- ペアプロしている場合にDLTが1時間未満のコミットが数多くある
- しかし全てのコミットがペアプロ中に行われるわけではないので中央値は3~12時間の範囲に収まる
- ex)
- tips
- DLTの中央値が24時間未満であることは素晴らしいこと
- 1ヶ月分のコミットでDLTの中央値を取ることが重要
- 金曜の午後にPRを出す、休み、インシデント対応をしている可能性もある
- DORAの「1時間未満」という括りを別の角度から見る
- コードを書いて本番環境で1時間未満で実行できるかどうかということ
- データの観点からは、これは "DLTが1時間未満であるコミットがチームに少なくとも1つあるか "ということ
- そしてチームがバグや障害から回復するのにかかる時間について考えるときに関連する
- 著者はMean Time to Restore metricよりも優れていると考えている
- そしてチームがバグや障害から回復するのにかかる時間について考えるときに関連する
- データの観点からは、これは "DLTが1時間未満であるコミットがチームに少なくとも1つあるか "ということ
- コードを書いて本番環境で1時間未満で実行できるかどうかということ
- How Teams can use Delivery Lead Time
- DLT指標をチームに提供し、それを使用するように指示してもうまくいかない
- チームは、ソフトウェアデリバリー能力を向上させたいという出発点から始めなければならない
- 上矢印を促す必要に気づくためのシグナル
- プルリクエストがすぐに見られない
- チームメンバーは、PR をレビューするために、個人を何度も ping するか、スタンドアップで催促する必要があります。
- プルリクエストが大きすぎる
- PRのレビューに何日もかかり、多くのコメントや変更が要求される。
- 変更の失敗により、多くのインシデントが発生する
- 大規模なチェンジセットがデプロイされていないか、テストスイートが包括的でないかを調査するためのプロンプトとして使用してください
- デプロイメントパイプラインの失敗により、インシデントが発生します。
- ソフトウェアをデプロイしたくない個人がいる
- デプロイメントプロセスに時間がかかることを示している。
- チーム内で 1 人だけがデプロイメントを行う
- デプロイメントプロセスが複雑であることを示す
- レトロスペクティブでソフトウェアデリバリに関連するもの。
- プルリクエストがすぐに見られない
- 上矢印を促す必要に気づくためのシグナル
- ソフトウェアデリバリープロセスを改善チームの2つの選択肢
- Pick the low hanging fruit, make small improvements everywhere in the process.
- 実施しやすいが個別最適化に陥り、小さな改善にとどまってしまう可能性
- Focus and develop a DevOps Capability.
- より多くの投資が必要だが、大きな改善になる可能性
- ex)
- 手動デプロイメントから完全自動の継続的デプロイメントへの移行
- エンジニアがオンデマンドで統合環境をスピンアップしてCIにプッシュする前にローカルでテストできる機能
- チームがペアプログラミングとトランクベースの開発に切り替えること
- Pick the low hanging fruit, make small improvements everywhere in the process.
- どちらにしろ目指すべきDevOps能力と成熟度について明確な目標を設定し、DLTをこの作業を実施する際の進捗の指標とする
- DevOps能力の中には技術的な実装が必要なものもあるが、それを最大限に活用するのは、チーム内の文化的な変化であることが多い
- Context Matters
- エンジニアリングメトリクス
- 改善が必要なコードベースを特定するために経営陣が使用することができる
- 納品リードタイムは強力なシグナルのように見えるが、これはエンジニアがコードを生産に移すのにかかる時間を表す
- 他の指標と同様に、DLTは多くの複雑さを単純化し、隠してしまう
- 以下は組織的なコンテキストで DLT を考慮する方法についての考察と学習
- デプロイメントの種類は、DLT にコンテキストを追加する
- 著者の組織では、API、バックグラウンドワーカー、SPA、データアプリケーション、データベース、IaCレポ、大規模なレガシーモノリス、マイクロサービスもデプロイしている
- これらのソフトウェア開発とデプロイの現実は全く異なる
- Goマイクロサービスで実現可能な「エリートDLT」は、どんなに努力しても、データベースでは実現できないかもしれない
- ソフトウェア開発およびデリバリープロセスにおいて、コンポーネント間で共有されるツールの改良を検討する
- 共有テストサーバーであったり、複数のコンポーネントをデプロイするポリレポプロジェクトにおける共通のCI/CDパイプラインであったり
- このような共有ツールを改善することは、それを使用するすべてのコンポーネントに大きな影響を与える
- あるプロジェクトが提供するビジネス価値とは何か？
- 大規模な組織では、この問いに答えるのは難しい場合がある
- DLTが1週間の価値の低いプロジェクトよりも、DLTが48時間の価値の高いプロジェクトに投資し、ソフトウェアデリバリー能力を向上させる方がよい
- プロジェクト内でコードが変更される頻度は？
- 多くのエンジニアが作業していれば、小さな改善でもスケールする
- デプロイメント頻度やプルリクエスト回数など、活動を反映するエンジニアリングメトリクスがこれを定量化
- スピードよりも手間を省くことを優先
- ex) 同じDLTを持つ2つのコンポーネント
- 一方は、非常に遅いが信頼性の高いデプロイメントパイプラインを持っており、時間はかかりますが、完全に自動化されている
- もう一方は、高速なデプロイメントパイプラインを持っていますが、おかしなテストが原因でよく壊れる
- デプロイ担当者が子守をする必要がある。後者のパイプラインを改善することで、手間を省き、エンジニアの日常をより良いものにすることができる
- すべてのチームがDelivery Lead Timeのメトリクスをトラッキングする必要があるわけではない
- ソフトウェアデリバリーに関して何の問題も抱えていないなら、デリバリープラクティスを改善するための目標を設定したり、DLTをモニターしたりすることは時間の無駄
- ex) 同じDLTを持つ2つのコンポーネント
- 大規模な組織では、この問いに答えるのは難しい場合がある
- デプロイメントの種類は、DLT にコンテキストを追加する
- エンジニアリングメトリクス
- Conclusion
- デリバリーリードタイムは、コードが本番環境にデプロイされるまでの時間を測定
- 多くの複雑性を抽象化したものなので、特定のチームやプロジェクトの状況に応じて扱う
- DLTは、チームのパフォーマンスを測定するものではなく、エンジニアリングの成果や顧客に提供する価値を測定するものでもない
- あるプロジェクトにおいて、どれだけ早くコードを変更できるかを測定
- チームにとって、DLTを減らすことが目的ではなく、新しいDevOps能力を向上させ、開発することが目的であるべき
- DLTは、目標に対する進捗を追跡するための指標として使用する必要がある
- デリバリーリードタイムは、コードが本番環境にデプロイされるまでの時間を測定
r-kagayaNetflixのdeveloper productivity teamsの話
↓メモ
r-kagaya- SPACEを活用しつつ、自動化が容易な4つの領域を選んでPACEと呼んでる話
- Performance (change failure rate, a function of raised defects and incidents over all production deployments in the reviewed period)
- Activity (number of production deployments)
- Collaboration (time to first code review comment)
- Efficiency (median cycle/elapsed time of a JIRA ticket from in progress to done)
- Grafanaで可視化したエンジニアリングの全員が利用できるように
- 各チームが自分たちにとって「健康的」であることを示す指標範囲について合意
- 毎週ダッシュボードを確認して、アクションが必要であれば実行
- PACEでは行わない・範囲外のこと
- ビジネス上の成果は対象外
- 個人ではなくチームレベルの指標のみ
- チーム間の比較
- なぜPACE
- 現時点でのエンジニアリングの優先順位と一致する、少数の生産性測定基準を公表したい
- DORAやSPACE などの業界の代表的なフレームワークに基づいていることが望ましい
- 生産性メトリクスを管理者だけでなく技術者全員が利用でき、かつ技術者全員の関心事とするための技術者内の文化的なシフト
A cultural shift within engineering that makes productivity metrics available to and a concern of everyone in engineering, not just managers
- パフォーマンス評価から切り離す
- 現時点でのエンジニアリングの優先順位と一致する、少数の生産性測定基準を公表したい
- DPEについての記述
- DPEは人によって異なる意味を持つ
- 共通しているのは、より良いソフトウェアを、より速く、持続可能な方法で構築するというテーマです
- 2010年代半ば以降、Google、Netflix、Microsoftなどの世界的なソフトウェア企業はDPEを重要なものとして扱ってきた
- 組織の成功に大きく貢献し、ビジネスの成果と仕事の満足度の両方に直結するものであると認識
- DPEへの投資の大きさが重要性を示している
- ネットフリックスでは、2000人のエンジニアを120人のDPEがサポートしていた時期がある。リンクトインはエンジニア10人に1人の割合でDPEを配置
- おそらく基盤やプラットフォーム開発のエンジニアも込みの話？
- ネットフリックスでは、2000人のエンジニアを120人のDPEがサポートしていた時期がある。リンクトインはエンジニア10人に1人の割合でDPEを配置
- DPEは人によって異なる意味を持つ
r-kagaya- Delivery Lead Time
- Deployment Frequency
- 特定のコンポーネントのDeployment Frequencyを見ることは、それほど有益ではない
- チームのパフォーマンスを測定するために測定基準を使うのは好ましくない
- チームとしてデプロイメント頻度が低下する理由はたくさんある
- ex) discovery work, spikes, contributing code in repositories owned by other teams, or going on holiday
- ある期間においてデプロイメント頻度が低い理由を正当化する必要があるとチームが感じるのは、不健全なこと
- チームとしてデプロイメント頻度が低下する理由はたくさんある
- チームのパフォーマンスを測定するために測定基準を使うのは好ましくない
- Deployment Frequencyはバッチサイズの代理
- ソフトウェアでは、目に見える在庫がないため、バッチサイズを測定し、コンテキストを越えて伝達することは困難
- バッチサイズの代理として、測定が容易で一般的にばらつきが少ないDeployment Frequencyを選択
- バッチサイズはデプロイメント頻度に影響を与えるかもしれませんが、良い代理指標なのか？
- ソフトウェアでは、目に見える在庫がないため、バッチサイズを測定し、コンテキストを越えて伝達することは困難
- デプロイメント頻度はソフトウェア所有権の代理として使用することができる
- 「過去3ヶ月間にどのコンポーネントがデプロイされていないか」という質問に答えることができ、さらに、チームの作業負荷や組織の優先順位について明らかにすることができる
- 特定のコンポーネントのDeployment Frequencyを見ることは、それほど有益ではない
- Mean Time To Restore
- 組織の信頼性やインシデント対応機能に対する実際の洞察を提供しない
- 「SREにおけるインシデントメトリクス」論文
- インシデントのばらつきが大きいため、統計的な平均値は誤解を招くことを実証
- MTTRの別の見方は「修正ができたら、それをどれだけ早く顧客に提供できるか」
- Delivery Lead Time
- Change Failure Rate
- CFR メトリクスには MTTR と同様のばらつきの問題がある
- メトリクスは自動的に測定され、組織全体で同じ方法で測定される必要がある
- 変更の失敗とは何か？
- 障害が発生した場合は明らかに失敗だが、レイテンシーを増加させたり、UXを損なったり、ウェブページにバグを導入したりした場合は？
- 変更が行われてから1カ月後に失敗に気づいた場合は？
- 全顧客の0.001%にしか影響がなかったら？
- 変更の失敗は主観的で、自動化測定が難しく、個人が手動で報告することに依存するため、組織全体で同じように測定することは決してできない
- 変更の失敗とは何か？
- Better Reliability Metrics
- Mean Time to RestoreとChange Failure Rateは誤解を招く測定基準
- 自動化された方法で組織全体にわたって一貫して測定することはできない
- とはいえ、システムの信頼性を監視するための指標は必要
- どのシステムが最も投資を必要としているかを示し、技術的な投資によってどのような改善がなされたかを追跡するためのデータが必要
- レジリエンス・エンジニアリングの分野では、漸進的な変更が行われていない場合でも、システムに障害が発生することが分かっている
- 停止（デプロイやリリースが原因ではない）は、変更失敗率の指標には登録されませんが、顧客には依然として影響が及ぶ
- サービスレベル目標（SLO）は、システムの可用性を測定するための完璧なツール
- SLOはシステム利用体験を測定するものであり、障害が変更に関連しているかどうかを気にすることはない
- サービスレベル指標（SLI）は、可用性、レイテンシー、エラー率などを定量的、客観的に測定するもの
- SLI は自動的に測定され、SLO と SLI はチームによって定義される
- SLOはシステム利用体験を測定するものであり、障害が変更に関連しているかどうかを気にすることはない
- SLO は MTTR と CFR をカプセル化したものであり、同様の機能を果たす
- 可用性はチームや組織が、運用しているソフトウェア製品やサービスに関して約束や主張を行い、それを守る能力を表している
- Mean Time to RestoreとChange Failure Rateは誤解を招く測定基準
- Micro Macro Metrics
- Accelerateは、効果的かつ効率的なDevOps技術組織を構築しようとする経営者向け
- DORAメトリクスはマクロ/経営レベルで扱われている
- DLTやDFなどのメトリクスを組織単位で集計して見ることは貴重であり、組織内でより多くの投資が必要な領域を迅速に明らかにすることができる
- エンジニアリング・チームに測定基準にアクセスさせることで改善を推進することができる
- 組織の成果が明確であれば（例：オンデマンドデプロイメント能力、顧客への可用性の向上）、その成果を達成するために必要な改善やDevOps能力を提案できる
- メトリクスは、エンジニアリングチームがミクロレベルで観察することで、システムのエキスパートが、組織の成果に沿った効果的な変更を行い、それを測定することを可能にする
- Accelerateは、効果的かつ効率的なDevOps技術組織を構築しようとする経営者向け
- DORAのメトリクスはチームが運用するシステムの健全性を洞察するもの
- 経営陣にとっては、デリバリーメトリクスを組織のポートフォリオレベルに集約することで、マクロレベルの視点を得ることができる
- チームに対しては、メトリクスをコンポーネントレベルで見ることで、チームに直接的なフィードバックを与え、信頼性の高いデータを提供することで、作業方法や技術的な実践を実験することを可能にする
r-kagaya- MetaのSLIとSLOと社内ツールSLICKとアノテーションの話
r-kagaya- SPACE
- NetflixやGitHubなどはすでに開発チーム内で導入
- NetflixのKoehler氏
- "There's no unicorn metric for anybody. People who are at the undergraduate level of productivity measure activity and think, ‘Oh, lines of code, butts on seats, deployment today.’ That's what you can get your head around, and that's what productivity means. But the SPACE methodology is really around well-being and satisfaction."
- SPACEの方法論の鍵は、生産性と満足度が本質的に結びついているという理解
- DevOps Research and Assessment (DORA)
- どのような測定基準プログラムでも、最も重要なことは、各データポイントと測定基準は、その組織 に固有のものであるということ
- アクティビティを見るだけでは罠にはまる
- 各組織・チームのコンテクストの重要性
- DORA以外の要素として、開発者のストレスレベルと業務外の時間を保護することに焦点を当てるべき
- エンジニアリングメトリクスプログラムの目的
- 組織のパフォーマンスと改善点を基本的に理解できるだけでなく、開発チームに目標と目的のための出発点を与えること
- メトリクス・プログラムの導入を成功させるには、メトリクスに基づいて人を評価するのではなく、メトリクスを確実に認識させるだけでよいということ
- 評価されるものはゲーム化されてしまう
- 自分がどこに投資し、どのように改善しているかを知るためのツールであることを、伝えることが重要
- エンジニアリングメトリクスプログラムは、経営陣にとってだけでなく、開発チームにとっても重要
- 経営陣が組織全体のパフォーマンスと進捗を追跡するのに役立つだけでなく、エンジニアが重要なタスクに集中できるようにし、努力すべき指標を導く
- エンジニアの幸福は、最も重要なもの
- 成功するエンジニアリング・メトリクス・プログラムは、エンジニアの仕事量、平均中断時間などを考慮する
- エンジニアの業務に気を配り、仕事中の時間、そして仕事以外の時間を守るように
r-kagaya- エンジニアリングチームは、待ち行列システムとしてモデル化することができる
- このようなシステムでは、タスクが一方から入ってきて、ソフトウェアがもう一方から出てくる
- 待ち行列システムのパフォーマンスを測定するために使用できる4つのメトリクス
- Arrival rate
- タスクがシステムに到着する率
- Work in progress
- 任意の時点で進行中のアイテムの数
- Departure rate or throughput
- タスクがシステムから出発する率
- Cycle time
- タスクがシステムから離れるのにかかる時間
- Arrival rate
- システムの到着率が出発率を上回ると、仕掛品の量は増加する
- 仕掛品の増加は、タスクの待ち行列の成長を意味
- 待ち行列が形成されると、待ち行列の末尾に到達するまでにますます時間がかかるため、サイクルタイムが伸長する
- 良い指標の特徴
- 目標ではない
- 最終的な状態を決定するのではなく、正しい方向に進んでいるかどうかを判断するのに役立つ。
- 実行可能であること
- 管理者が意思決定を行い、システムに介入して改善を生み出すのに役立つ
- 特徴1および2を持つ他の測定基準との関係が明確である
- 他の測定基準がどのように変化するかを知ることができる
- 目標ではない
- 注意点
- 測定基準を目標に変える
- グッドハートの法則が示すように、測定基準を目標に変えたとき、それは良い測定基準ではなくなる
- 組織の目的を実際に果たす代わりに、何としても測定基準を良くするためにシステムをゲーム化するから
- 測定基準を武器にする
- デミングが言うように、「恐怖があるときはいつでも、間違った数値が得られる」
- メトリクスを、チームと話をしたり、定性分析を行ったりするための代用品として使う
- メトリクスは、"アラーム "としての役割を果たす必要がある。何か問題が起きたときにベルを鳴らしてくれますが、どのように介入するかを決める必要
- 指標だけで管理すること（成果主義）は「バックミラーを見ながら車を運転する」ようなもの
- 測定基準を目標に変える
r-kagaya- ソフトウェアエンジニアリングチームが直面する主なリスクの 1 つはチームの生産性の低下で
- コミュニケーションパスのの増加や、ビジネスとその顧客のリスクを最小限に抑えるために従うべき追加プロセスなどかの要因から生じる
- たとえ最高のチームであっても、ある時点で、新しい機能の構築に以前よりも段階的に時間がかかるほどソフトウェアの内部品質が悪化し、チームがスピードに苦戦するようになる
- チーム全体が高品質のソフトウェアを作るという考えに賛同し、経営陣からサポートを受けている状況でも起こる
- What is quality?
- 品質とは何を意味するのかを明確にすることが重要
- 品質の適切な定義なくして、
Which of the following is a higher quality car?という質問に答えることは困難 - 品質について語るときによくある間違いのひとつ
- 品質と機能の可用性を取り違えていること
- Ferrari SF90はVolkswagen Golfよりも多くの機能を持っているかもしれず、多くの機能でより良いパフォーマンスを持っているかもしれないが品質が高いと解釈すべきではない
- 著者は以下のようなソフトウェアを高品質なソフトウェアと定義
- Correct
- ソフトウェアが想定していることを正確に実行し、テストによって検証できること
- Secure
- 悪意のある利用から保護されていること
- Maintainable
- ソフトウェアの変更と運用が容易であること
- It does the right thing for the user
- そのソフトウェアがユーザーに良い影響を与えること
- Correct
- Why does quality deteriorate over time?
- 品質と引き換えに、より速い納期、より多くの機能を同じ時間で提供するという、スピードの次元で利益を得ることが可能であるという根本的な前提を示している
- 品質とスピードは誤ったトレードオフ
- 品質と引き換えにスピードを上げることが可能
- Martin Fowler「トレード可能な品質仮説」
- 品質と引き換えにスピードを上げることが可能
- 品質とスピードを引き換えにした場合、スピードは向上するどころか、低下してしまう
- ほとんどの製品開発作業は、既存のコードベースと既存の製品というコンテクストで行われる
- ソフトウェアの構築速度に大きく影響するのは、変更のコスト
- 変更のコストを下げることは、ソフトウェアの構築速度に大きな影響を与えます。品質が低いと、将来の変更にかかるコストが増加し、その結果、新機能の開発にかかる時間が長くなる
- 品質が低いと、開発チームが新機能に集中するために利用できる帯域が狭くなる
- バグやその他の操作上の問題によってユーザーの仕事が妨げられ、開発チームのエネルギーのほとんどが問題への対処に費やされ、チームは製品の改善に集中することができなくなる
- 製品開発における低品質の累積的な影響は、長期的には、高品質のソフトウェアよりも低品質のソフトウェアを開発する方が徐々にコストが高くなることを意味する
- Martin Fowlerの「Design Stamina Hypothesis」
- The alternative: focus on Sustained Velocity
- 品質をトレードオフの関係にしてしまわないように、スピードと品質を結びつけた定義を採用することを推奨
- Sustained Velocity
- ソフトウェア開発チームの現在と将来の速度を測定
- ある作業を評価するとき、あるいは技術設計を評価するとき、いかに早く構築できるかだけに注目するのではなく、その作業が現在および将来のチームのベロシティにどのような影響を与えるかにも注目
r-kagaya- Spotify focused on Quality Engineering Productivity by:
- Measuring the ratio of inputs to outputs;
- Continuously linking the outputs with the outcomes;
- Keep improving for more outputs and more outcomes
r-kagaya- 生産性計測後に起こった変化
- 定量結果をもとに、分析・改善施策が進行
- 定量アプローチに限界を感じ始め、定性アプローチを開始
- サブプロジェクト発足による、チーム力強化
- 定量結果を元にした分析・改善施策
- 詳細分析
- 数値が高い月と低い月の2ヶ月分を選ぶ
- その期間のPRの変更差分をソースコードレベルで確認する
- 定量データに基づく改善策の実施
- 詳細分析
- 定性アプローチ
- アンケート実施・分析
- サブプロジェクト発足
r-kagaya- レビュー時間の遅さはエンジニアの不満に繋がる
- コードレビューライフサイクルの短縮の必要性
- 取り組み
- レビューサイクルにおいて待ち時間を調査
- レビュー時間の中央値は数時間
- 下位25%のレビューでは、待ち時間が1日分増加
- レビュー時間とユーザー満足度(全社的な調査による)の相関関係を分析
- レビューにかかる時間が長いほど、コードレビュープロセスへの満足度は低くなる
- North Star Metric
- P75 Time In Review(レビュー時間)
- レビューサイクルにおいて待ち時間を調査
- スピードと品質のバランス
- 単にレビューのスピードを最適化するだけでは、マイナスの副作用が生じる可能性
- 目標指標と、意図しない悪影響を防ぐためのガードレール指標の選定
- Eyeball Time
- レビュアーがPRを見るのに費やした時間の総和である
- ラバースタンピングが増えれば、Eyeball Timeは減少する
- Eyeball Time
- experimental process
- Next Reviewable Diff
- 機械学習でレビュー担当者が次にレビューしたくなる差分を特定
- レビューフロー状態を促進
- 効果
- 1日あたりのレビューアクションが17%増加
- 平均的なレビュー担当者よりも44%多くレビューアクションを実行
- 機械学習でレビュー担当者が次にレビューしたくなる差分を特定
- reviewer recommendation system
- 24時間以内にレビューされた差分が1.5％増加
- トップ3レコメンデーションの精度（実際のレビュアーがトップ3に入る確率）が60％以下から75％近くまで上昇
- Stale Diff Nudgebot
- レビューに時間がかかっている差分について、レビューする可能性が最も高いレビュアーに、適切なコンテキストと、すぐにレビューに取り掛かれるようなクイックアクションをチャットで送信
- 平均レビュー時間が7%減少
- レビューに3日以上待たされたdiffの割合が12%減少
- focused questions
- What is the right set of people to be reviewing a given diff?
- How can we make it easier for reviewers to have the information they need to give a high quality review?
- How can we leverage AI and machine learning to improve the code review process?