2022年3月~4月に読んだDeveloper Productivity・Developer Experience・Platform Engineering関連のリソース

If you're running around a track super-fast, but you're on the wrong track, does it matter?

- 代表的な技術負債
  - Code quality
    - テストしにくいコード、理解しにくいコード、ドキュメント化が不十分なコード
　　 - ドメインモデルや関連するデータモデルが現在のビジネスモデルに合っていないとか
  - Testing
    - テストがない。テストの割合がおかしい(テストピラミッド)
    - 開発時にフィードバックを得るスピードが遅くなり、結果デプロイ頻度が落ちたり
  - Coupling
    - モジュール間での結合度が強いと、チーム間でブロックし合う可能性が高まったり、結果デプロイの頻度減少や変更のリードタイムが長くなる
    - 解決策の1つはマイクロサービス化だが複雑性をもたらす
    - モノリス内で明確な境界を設定するだけなら、もっと簡単な方法があるはず
      - memo: 多分モジュラーモノリスとかの話
  - Unused or low value features
    - 機能が増えれば増えるほど、開発者が考慮する条件やエッジケースが増え、開発スピードを低下させる
    - 実験（機能）がうまくいっているかどうか、常に再評価し、ダメなら削除
      - チームが判断するのは難しいので、機能の価値を定量化する客観的なデータがあれば容易に
  - Out of date libraries or frameworks
    - レガシーなフレームワークやライブラリをいつまでも使う
    - 開発者の満足度やストレス度、セキュリティ、スキルセット面での採用の問題
  - Tooling
    - 最適でない他社製品や、メンテナンスに手間がかかるツール。より効率的なツールが市場に出てきている可能性
  - Reliability and performance engineering problems
    - カスタマーエクスペリエンスやスケールアップの能力に影響を与える可能性
    - 早すぎる最適化で無駄な労力を費やすケースも
  - Manual processes
    - 手作業
  - Automated deployments
    - デプロイ自動化。four keysの話
  - Knowledge sharing
    - ドキュメントがない、または見つけられない
- Signs you are approaching a scaling bottleneck
  - Value lead time
    - ユーザーに価値を提供するエンドツーエンドのプロセスと、それが時間とともにどのように推移するかを見る
    - 技術負債溜まりすぎると遅くなる
  - Impact to end user
    - Latency in the systems, customer onboarding time, and quality issues
  - Engineering satisfaction
    - 開発者の不満ベースで技術基盤の問題を見つける
  - Ability to onboard new developers
    - 入社後のプロセスや新メンバーの満足度を見る
  - Degradation in Non-Functional measures
    - 実行時のインフラコスト、パフォーマンス、可用性
- 技術的負債に対するチームのアプローチは、リーダーによって設定された技術戦略から来るものであるべき
  - 意図的 && 明確 && 時間をかけて再評価されるべきもの
  - A tech strategy to limit technical debt impact
    - [https://martinfowler.com/articles/bottlenecks-of-scaleups/phases.html](https://martinfowler.com/articles/bottlenecks-of-scaleups/phases.html)
- How do you address the tech debt
  - 透明性のある情報を共有
    - ビジネスの状況、製品の方向性、現在のスケーリング能力に関する指標、製品に関する顧客の声、カスタマーサポートやオペレーションが見ているもの
    - データに基づいた意思決定を行う
  - すべての製品とその関連システムに明確なオーナーを決める
    - チームが成長した事による、所有権の曖昧さが技術的負債につながる
    - オーナーシップがないと問題を修正するインセンティブが低くなる
      - memo: 誰もオーナーがいない、古いプロダクトや共通コンポーネントはそのうち触らぬ神に祟りなし状態に:innocent:
  - 技術的負債を解決することは、製品開発の自然な流れの一部であるべき
    - エンジニアとプロダクトマネージャーは、技術的負債と機能性の健全なバランスをとる
    - 技術的に健全な製品を維持・継続することは、開発チームの仕事の一部であり、技術的負債に取り組み、継続的に監視するための合意されたプロセスが必要
  - チームのトポロジーを正しく設計する
    - ある領域で技術的負債が継続的に発生しているのであれば、チームの設計が誤っていることを示すかも
    - 強力なオーナーシップと注意が必要なプラットフォームやビジネス能力があるのかも
      - memo: コンプリケイテッド・サブシステムチーム、プラットフォームチーム
  - メトリクス見る
    - よくあるミスやビルドやデプロイの時間を測定したり
    - メトリクスは、マネージャーが監視したりインセンティブを与えたりするためではなく、チームが技術負債について意思決定するためのガイドとして使用する
  - チームの自立度のバランス
    - 自律性が高すぎるとカオスになる可能性
      - memo: 技術負債じゃないが、Spotifyモデル関連でこんな話読んだ記憶。チームが自立しすぎて、全社的な目標と一致しないチームがあったり、全体最適できないとか
    - アーキテクチャーピアレビューなど、軽量なチェックアンドバランス
      - memo: 前職で、標準/推奨技術スタックの統制が曖昧で、何故か1チームだけ別言語を使ってた結果、その言語を書ける人がいなくなり、そもそもシステム捨てることになった
  - どのように対処するかは組織の状況によって異なる
    - 応急処置的なアプローチでなく、反復的&&技術的負債を解決するための投資を開発活動と組み合わせた測定基準に任せることが良い結果をもたらす
- Summary && Memo
  - 慎重な技術的負債をは、アーリーステージのスタートアップにとって必要 && 健全
  - 技術的負債がビジネスを制約するようなサイン（Value Lead Timeやエンジニアリングの満足度）を探す
  - 明確な技術的品質基準を持ち、チームがそれを守ることができるように
  - 技術的負債のプロセスを作成、明確なオーナーシップを持ち、権限のあるチームが透明性のある情報にアクセスし、データに基づいた意思決定を行うことができるように
  - 特に成長過程における重要な瞬間（資金調達、新しい製品の方向性、新メンバー加入）には、技術負債戦略を継続的に再評価する

開発者の効率が良い企業と低い企業では、アプローチの仕方に大きな違いがあることを発見

## Day in the life in a highly effective environment
- checks the team project management tool and then attends standup where she is clear about what she has to work on.
- notes that the development environment has been automatically updated with libraries matching development and production, and the CI/CD pipelines are green.
- pulls down the latest code, makes an incremental code change that is quickly validated by deploying to a local environment and by running unit tests.
- depends on another team’s business capabilities for her feature. She is able to find documentation and the API spec through a developer portal. She still has some queries, so she jumps into the team’s Slack room and quickly gets some help from another developer who is doing support.
- focuses on her task for a few hours without any interruptions.
- takes a break, gets coffee, takes a walk, plays some ping pong with colleagues.
- commits the code change, which then passes through a number of automated checks before being deployed to production. Releases the change gradually to users in production, while monitoring business and operational metrics.

## Day in the life in a low effective environment
- starts the day having to deal immediately with a number of alerts for problems in production.
- checks a number of logging and monitoring systems to find the error report as there are no aggregated logs across systems.
- works with operations on the phone and determines that the alerts are false positives.
- has to wait for a response from architecture, security and governance groups for a previous feature she had completed.
- has a day broken up with many meetings, many of which are status meetings
- notes that a previous feature has been approved by reviewers, she moves it into another branch that kicks off a long nightly E2E test suite that is almost always red, managed by a siloed QA team.
- depends on another team's API, but she cannot find current documentation. So instead she talks to a project manager on the other team, trying to get a query. The ticket to find an answer will take a few days, so this is blocking her current task.

## Developer effectiveness
- 効果的であるとはどういうことか
  - 開発者である以上、目的は顧客に最大限の価値を提供すること
  - 効果的な環境は、有用で高品質なソフトウェアを生産する事を容易にし、不必要な複雑さ、軽薄な解約、長い遅延に対処する必要がないようにすることで、価値を高める仕事に集中することができる
	- エンジニアは自分が生産的でないことに無力感(は学習性無力感)を感じるようになる
- 組織は開発者の生産性を測定する方法を探している
  - 一般的なアンチパターンはコード行数などでパフォーマンスの低い開発者を見つけようとすること
  - それよりも、組織がいかに効果的なエンジニアリング環境を提供しているかに焦点を当てる方がよい
- 生産的であることは、開発者のモチベーションを高める。不要な摩擦がなければ、創造的に考える時間を持つことができる

## Case Study: Spotify
- エンジニアを対象としたユーザー調査により以下二つの問題を発見
  - 内部ツールの断片化
    - 内部インフラとツールは、孤立した小さな「島」として構築されており、エンジニアのコンテキスト切り替えと認知負荷につながった
  - 発見性の低さ
    - 技術情報を見つけるための中心的な場所がなく、情報があちこちに散らばっているため、エンジニアはどこから情報を探せばいいのかさえわからない状態だった
- 開発者が多くの決定を個別に行うことを強いられ、それが断片化と重複作業を生み、最終的に製品のエンドツーエンドの納期を損なうという悪循環に陥っていた
- 一貫した開発者体験とエンジニアが必要な情報を見つけるための出発点を提供するプラグインアーキテクチャを備えたオープンソースの開発者ポータル、Backstageを開発した

## How to get started?
- 効果の高い環境とは
  - DevOps文化、継続的デリバリー、製品思考を完全に取り入れた企業
  - AccelerateとState of DevOpsのレポートを読んでいる
- four keysは（リードタイム、デプロイ頻度、MTTR、変更失敗率）は、DevOpsのパフォーマンスを測る素晴らしい指標
  - 現状を把握し、より良くなるために行うべき具体的なことを把握するために、やるべきことがある時期を示すのに有効な測定値
- 開発者の満足度に関する調査など、他の調査源と組み合わせることも必要です。
- 何をすべきかを知るのはとても難しい
- 開発者のフィードバックループを最適化し、高速かつシンプルにすることに注力することをお勧めする
  - フィードバックループの長さ、制約、そして結果の結果を測定
  - 新しいツールやテクニックが導入されたとき、これらの測定基準によって、開発者の効率がどの程度改善されたか、あるいは少なくとも悪化していないことを明確に示すことができる

### Feedback Loops
- マイクロフィードバックループは短ければ短いほど良い
- より早く、より頻繁に検証を受けることで、後々の手戻りを減らすことができる
- 結果を解釈するのが簡単なマイクロフィードバックループは、前後のコミュニケーションと認知的オーバーヘッドを削減する
- マイクロフィードバックループの悪化は、four keysの主要な測定基準（デプロイ頻度とリードタイム）のスコアの低下として現れる
- マイクロフィードバックループはチリも積もれば山となり、開発者のフロー状態をも乱してしまう
- 何をどこまで最適化するかの判断には、個々のチームなどの個別最適かではなく、全体最適、プラットフォーム思考が重要
- 分散システムでがチームの自律性と高速なフィードバックループを維持するのにはコストがかかるが、このコストは開発者の有効性を犠牲にしないための必要経費

## Organizational Effectiveness
- 効果的な組織は、効果性とフィードバックループを最適化するように設計されている
  - 技術、そして開発チームの摩擦を取り除くことがビジネスにとって不可欠であることを、リーダーが認識することから始まる
- リーダーは、常に有効性を測定し、再検討しています。効果的な組織は、4つの主要な測定基準とその状況にとって重要なその他のデータポイントを追跡することによってデータ駆動型の意思決定を行う枠組みを作り上げている
- 測定基準に加え、日々その環境で働く個々の貢献者の声に耳を傾けるオープンなフォーラムを作る
  - 開発者は自分たちが直面している問題を知り、それを解決する方法について多くのアイデアを持っているはず
  - この情報をもとに、エンジニアリングマネージャーは投資の優先順位を決定することができる
  - 大きな問題では、開発者のエクスペリエンスの低下に対処するために、それに見合った大規模な最新化プログラムが必要になるかもしれない
  - しかし多くの場合、継続的な改善を行うためにチームを強化することの方が重要
- 重要な原則は、Developer Experienceを受け入れること
  - Developer Experienceとは、エンドユーザー製品の開発に用いられるのと同じアプローチで、同じ調査、優先順位付け、成果ベースの思考、消費者からのフィードバックメカニズムを適用して、技術的能力を構築することを意味する
- 開発者のモチベーションを上げるために、効果の高い組織はフランチャイズを行っている。つまり開発者は日々の生活を向上させる能力を持つべきということ
  - この組織では、チームが段階的に技術的な改善を行い、技術的負債を管理する方針がある
  - 開発者とプロダクトマネジメントの間には、データに裏打ちされた健全な議論があるはず。チームが明確な目標を持ち、ボトルネックを明確に把握していれば、開発者は問題解決に向けて創造的に行動することができる
  - このような組織は、最高のアイデアを「バブル・トゥ・ザ・トップ」させ、データを使って何がベストかを評価し、ダブルダウンさせる方法を生み出している
- コミットメント、測定、権限委譲の次はスケーリング
  - ある程度の組織規模になると、規模の経済による効率化を図る必要がある
  - そのためにプラットフォーム思考を応用し、効率性の向上に特化した内部プラットフォームを構築する
  - 開発者の効率を向上させるための技術的能力を構築するエンジニアリングチームに投資する
  - また、他の開発チームを消費者とみなし、彼らが提供するサービスを製品のように扱います
    - このチームにはテクニカルプロダクトマネージャーがおり、そのチームが消費者であるチームにどのような影響を与えているかに関連した成功指標を持っている
    - 例えば、観測可能性を重視するプラットフォーム能力チームは、モニタリング、ロギング、アラート、トレース機能を作成し、チームがサービスの健全性を容易に監視し、製品の問題をデバッグできるようにする
- ガバナンスの必要性は高い。しかし高度に効果的な組織では、長時間の承認プロセスではなく、ガードレールを設定・伝達し、チームを正しい方向へ導くというものです。このように実施されると 、効率性の向上に重要な役割を果たす
  - 明確なエンジニアリング目標
  - チームやサービス間のコミュニケーション方法の規定
  - 有用なピアレビューの促進
  - ベストプラクティスをプラットフォーム機能に組み込む
  - アーキテクチャフィットネス機能による制御の自動化

## Case Study: Etsy
- Etsyは「素早く動くことは技術戦略でありビジネス戦略でもある」という信念のもと、開発者の効率性を社風に根付かせることに取り組んできた
- Etsyの重要な指標の1つはリードタイムであり、リアルタイムに測定、監視、表示されている
  - リードタイムがある重要な閾値以上になると、リリースエンジニアリングチームはそれを妥当なレベルまで下げるよう努力する
- またソフトウェアを速く導入することは、物語の半分に過ぎず、本当に効果的であるためには、そのソフトウェアが消費者にとって価値あるものでなければならない。
  - そのためEtsyでは、各機能に測定可能なKPIを設定し、データ駆動型のアプローチをとっている
- コードの変更は一連のチェックを経て、開発者はその変更がパフォーマンス、可用性、障害率などに関するEtsyのSLAを満たしていると確信することができる
- また変更が本番稼動すると、Etsyの実験プラットフォームはユーザー行動の指標を取得することができ、チームはこの指標をもとに、関連するKPIとユーザーの満足度を最適化しながら、製品の改良を繰り返していく
- 最終的にその変更が価値のないものであることが証明されれば、それは一掃され、それによって技術的負債を回避することができるだろう。

### 4 Pillars of Developer Experience
Etsyが取りんでいる開発者体験の主要な柱が以下

- Help me craft products ensures we have the right abstractions, libraries, and scaffolding for product engineers to do their work.
- Help me develop, test, and deploy focuses on product engineers, specifically the development environments themselves (IDEs, linters), unit/integration test patterns/runners, and the deployment tooling and processes.
- Help me build with data focuses on data scientists and machine learning engineers, making sure the entire data engineering ecosystem is set up in a way that is intuitive, easy to test, and easy to deploy.
- Help me reduce toil focuses on the on-call engineers, to make sure we build production systems with the appropriate levels of automation, have runbooks and documentation that is easily accessible and current, and we track and prioritize reducing toil-y activities.

4つの主要な指標を含む測定基準を追跡し、ネットプロモータースコア（NPS）を把握するために開発者に毎月アンケートを実施し、その効果を継続的に検証している

- Learn to Fail Fast
    - 失敗が早ければ早いほど良い
    - AB テストによる迅速なフィードバック
    - テスト駆動開発（TTD）、静的コード解析、およびシフト・レフト・アプローチにより、開発者は問題を早期に発見し、早期に修正し、より迅速に行動することが出来る
- Build Product and Development Confidence
    - 失敗を許容するだけでなく奨励する文化を作ることで、新しいやり方を試すことができるようになり、その多くが最終的にはより良く、より速くなるかもしれません。
    - エラー許容度、試行錯誤の奨励（ただし、早く失敗することでエラーへの投資を抑制）、新しいアイデアや異端的なアプローチに対するオープンさを維持することで信頼性を高めることができる
    - 開発レベルでは、ペアプログラミングの手法を採用し、コードレビューやデザインレビューでは、できる限り自由に（必要な場合は厳しく）行うことを検討する
- Prototype
    - 失敗したプロトタイプを作って捨てる方がコストがかからないという事実は変わらない
- Cathedral/Bazaar, Yes. Big Ball of Mud, No.
    - 開発者には、明確なアーキテクチャ、優れたプロセス、効果的な継続的内部コミュニケーション、十分に文書化されたリリースノート、そしてずさんな作業を抑止する環境が必要
    - それによりベロシティも向上する
- Manage Technical Debt
    - 技術的負債とは、古いインフラで何年も開発を続けたり、急遽小さな変更を何度も行ったり、適切な計画やツール、ライブラリを持たずに開発した場合に発生するもの
    - 開発者の速度低下
    - 技術的負債とは、開発者が新機能やバグ修正のたびに多大な労力を費やさなければならないことを意味し、開発者のモチベーションを下げ、フラストレーションを高める
    - 技術的負債が大きい製品は、多才で迅速な人材を遠ざけ、開発をスピードアップし、市場投入までの時間を短縮し、最終的に高品質な製品を生み出す新しい技術の活用を難しくする
    - 技術的負債を解消することは、より良い開発者速度を達成するために不可欠
- Manage Code Branches
    - ブランチサイズや生存期間を短く
- Maintain Traceability
    - 問題が発生したときにそれを追跡する能力に自信がある開発者は、新機能やバグフィックスを迅速にリリースすることをためらうことがなくなる
- Beware Your KPIs
    - KPI は進捗の誤った指標にもなり得る
    - 測定値に過度に依存すると、開発者自身が測定値に向かって努力するようになり、測定値が目標に到達するための道具ではなく、目標になってしまう
    例えば、テストにおけるコードカバレッジは重要ですが、それだけを KPI とすると、コードはカバーするが実際のシナリオはカバーしないナイーブなテストになってしまう可能性がある

 - マージ前に全てのE2Eを実行することにより、開発者の生産性指標であるvelocityが悪化
   - Test turnaround time (p95)が常に30分以上
     - エンジニアがコードリポジトリにコミットをプッシュしてから、テスト実行が完了するまでの時間
   - Test flakiness per pull request (PR)が50%以上
     - 同じコードを再実行したときに異なる結果になるようなテストの割合を測定
- マージ前に全てのテストを実行する形から、マージ後に実行する2つのパイプラインを追加
  - プリマージパイプライン
    - 開発時に、E2Eのサブセット(<1%)が実行。PRをメインラインにマージするために必須
    - マージやデプロイをブロックするクリティカル度の高い機能・テストが対象
  - ポストマージパイプライン
    - インラインにマージした後、より多くのE2Eテストのサブセット (<10%) をデプロイ前に実行
      - ミディアムクリティカル
  - リグレッションパイプライン
    - メインラインにマージ後、欠陥のあるテストや欠陥のあるテスト実行フレームワークからの偽陰性シグナルを減らすために残りのE2Eテストを実行
      - 2時間おきに実行