開発者の効果性を最大化する

効果性の高い環境での1日

開発者は

• チームのプロジェクト管理ツールを確認し、スタンドアップミーティングに出席して、自分が何に取り組むべきかを明確にします。
• 開発環境が開発と本番に一致するライブラリで自動的に更新されており、CI/CDパイプラインが正常に動作していることに注意します。
• 最新のコードを取得し、ローカル環境にデプロイして単体テストを実行することで迅速に検証できる、段階的なコード変更を行います。
• 彼女の機能は、別のチームのビジネス機能に依存しています。彼女は、開発者ポータルを通じてドキュメントとAPI仕様を見つけることができます。まだいくつかの質問があるので、彼女はチームのSlackルームに飛び込み、サポートを行っている別の開発者からすぐに助けを得ます。
• 中断することなく、数時間タスクに集中します。
• 休憩を取り、コーヒーを飲み、散歩をし、同僚と卓球をします。
• コード変更をコミットします。これは、本番環境にデプロイされる前に、いくつかの自動チェックを通過します。ビジネスと運用メトリクスを監視しながら、本番環境のユーザーに徐々に変更をリリースします。

開発者は1日で段階的に進歩を遂げることができ、満足して帰宅します。

効果性の低い環境での1日

開発者は

• 本番環境での問題に関する多数のアラートにすぐに対応しなければならず、1日を始めます。
• システム全体のログが集約されていないため、多数のログ記録および監視システムをチェックしてエラーレポートを見つけます。
• 電話で運用担当者と協力して、アラートが誤検知であると判断します。
• 以前に完了した機能について、アーキテクチャ、セキュリティ、ガバナンスグループからの応答を待たなければなりません。
• 多くの会議で1日が中断されます。その多くは進捗状況の確認のための会議です。
• 以前の機能がレビュー担当者によって承認されていることに気づき、彼女はそれを別のブランチに移動します。これは、ほとんどの場合エラーが発生する、サイロ化されたQAチームによって管理されている長時間夜間実行のE2Eテストスイートを開始します。
• 別のチームのAPIに依存していますが、最新のドキュメントが見つかりません。そこで、彼女は相手チームのプロジェクトマネージャーに相談して、問い合わせようとします。回答を見つけるためのチケットには数日かかるため、これは彼女の現在のタスクをブロックしています。

私たちは続けることができました。しかし、最終的に開発者は何も達成できず、不満とやる気を失ってしまいます。

開発者の効果性

効果的であるとはどういうことでしょうか？開発者として、それは顧客に最大の価値を提供することです。それは、あなたのエネルギーと革新を会社の目標に向かって最善の方法で適用できることです。効果的な環境は、有用で高品質なソフトウェアを本番環境に簡単に導入し、運用できるようにします。開発者が不必要な複雑さ、軽薄な変更、または長い遅延に対処する必要がないようにすることで、付加価値のあるタスクに集中できるようにします。

効果性の低い環境を示す例では、すべてが本来よりも長くかかります。開発者として、あなたの一日は無限のブロッカーと官僚主義で構成されています。それは一つのことだけではありません。それはたくさんあります。これは、千の切り傷による死のようなものです。ゆっくりと、生産性は小さな非効率性によって破壊され、それが複合的な影響を及ぼします。非効率性の感覚は、エンジニアリングだけにとどまらず、組織全体に広がります。エンジニアは無力感を感じ、非生産的になります。さらに悪いことに、彼らはそれを受け入れ、仕事のやり方が開発を行う方法を定義する受け入れられたルーチンになります。開発者は学習性無力感を経験します。

一方、非常に効果的な環境を提供する組織では、勢いを感じます。すべてが簡単かつ効率的であり、開発者はほとんど摩擦に遭遇しません。彼らはより多くの時間を価値の創造に費やします。企業がデジタルトランスフォーメーションを行う際に最も難しいのは、この摩擦のない環境と、絶えず改善したいという欲求と能力を育むことでそれをサポートする文化です。

組織は、開発者の生産性を測定する方法を探しています。一般的なアンチパターンは、コード行数、機能出力、またはパフォーマンスの低い開発者の発見に過度に焦点を合わせることです。組織が効果的なエンジニアリング環境をどのように提供しているかに焦点を当てるために、会話を逆にする方が良いでしょう。生産的であることは開発者を動機づけます。摩擦がなければ、彼らは創造的に考え、自分自身を適用する時間があります。組織がこれを行わない場合、私の経験では、最高のエンジニアは去ってしまいます。多くの優れた革新的なデジタル企業が強力な技術人材の採用を検討している場合、開発者が効果的でない環境で働く理由はありません。

開発者の効果性を最適化した企業の例を見てみましょう。

ケーススタディ：Spotify

Spotifyは、開発者の効果性をよりよく理解するために、エンジニアを対象にユーザー調査を実施しました。この調査を通じて、彼らは2つの重要な発見をしました

1. 内部ツールの断片化。Spotifyの内部インフラストラクチャとツールは、小さな孤立した「島」として構築され、エンジニアのコンテキスト切り替えと認知負荷につながりました。
2. 発見性の低さ。Spotifyには、技術情報を見つけるための中心となる場所がありませんでした。情報があちこちに分散されていたため、エンジニアはどこから情報を探し始めればよいかさえわかりませんでした。

Spotifyの開発者エクスペリエンスチームは、これらの問題を負のフライホイールとして説明しています。開発者が多くの未知数に直面し、孤立して多くの決定を下すことを余儀なくされる悪循環であり、それが断片化と努力の重複を悪化させ、最終的に製品のエンドツーエンドの配信時間を蝕みます。

図1：Spotifyの負のフライホイール

これらの複雑さを軽減するために、彼らはBackstageを開発しました。これは、すべてのインフラストラクチャ製品を一か所で公開し、一貫した開発者エクスペリエンスと、エンジニアが必要な情報を見つけるための出発点を提供するのに役立つ、プラグインアーキテクチャを備えたオープンソースの開発者ポータルです。

始め方

私が非常に効果的な環境で説明しているのは、DevOps文化、継続的デリバリー、製品思考を完全に受け入れている企業で働くことの意味です。非常に賢明なことに、ほとんどの企業はこの環境を実現するための旅の途上にあります。AccelerateとState of DevOpsレポートを読んでいます。彼らは、どのようなタイプの組織を構築しようとしているのかを知っています。4つの主要な指標（リードタイム、デプロイ頻度、MTTR、変更失敗率）は、DevOpsのパフォーマンスを測る優れた指標です。

DevOpsの測定値を見る1つの方法は、それらが遅行指標であるということです。それらは、自分がどこにいるのかを理解し、企業が改善するために何をすべきかを理解するための作業が必要な場合を示すのに役立つ測定値です。理想的には、より実用的な、効果性の低いレベルの先行指標を特定したいと考えています。上位レベルのメトリクスとの相関関係があります。それは上位に波及します。これは、開発者の満足度に関する調査などの他の情報源と組み合わせる必要があります。

改善に使用する必要がある、圧倒的な量の優れたアドバイス、プラクティス、ツール、プロセスがあります。何をするべきかを知ることは非常に困難です。私の調査では、いくつかの主要な開発者フィードバックループがあることが示されています。これらのループを最適化し、高速かつシンプルにすることに焦点を当てることをお勧めします。フィードバックループの長さ、制約、および結果の成果を測定します。新しいツールと手法が導入されると、これらのメトリクスは、開発者の効果性がどの程度向上したか、または少なくとも悪化していないかを明確に示すことができます。

フィードバックループ

私が特定した主要なループは次のとおりです

これらの指標は、私が観察した中で可能なことに基づいています。すべての企業がすべてのフィードバックループを高い効果のバケツに入れる必要があるわけではありませんが、意思決定を導く具体的な目標を提供します。エンジニアリング組織は、特定のコンテキスト内で調査を実施し、どのようなサイクルと指標が重要な技術戦略なのかを把握する必要があります。

フィードバックループを最適化するためにどのような手法が適用されてきたのか、そして企業がそこに至るまでにどのような道のりを辿ってきたのかを見てみることは有益です。これらのケーススタディは、自社組織に適用できる多くのアイデアを提供してくれます。

図2：機能開発中のフィードバックループ

上の図は、開発者が開発中にフィードバックループをどのように使用するかを簡略化して示しています。開発者は、作業が仕様と期待される基準を満たしていることを、開発中の複数のポイントで検証していることがわかります。注意すべき重要な点は以下のとおりです。

• フィードバックループが短ければ、開発者はより頻繁に実行します。
• フィードバックループが開発者にとって価値があり、単なる官僚的なオーバーヘッドではないと見なされる場合、開発者はより頻繁に実行し、結果に基づいて行動を起こします。
• 早期に、そしてより頻繁に検証を行うことで、後からの手戻りを減らすことができます。
• 結果の解釈が容易なフィードバックループは、コミュニケーションの行き違いや認知的オーバーヘッドを削減します。

組織がこれらの結果を達成できない場合、問題はすぐに複合化します。開発者にとっては、多くの無駄な労力が発生します。待ち時間、検索、または結果を理解しようとする時間に費やされます。これは積み重なり、製品開発に大きな遅延を引き起こし、4つの主要な指標（特にデプロイ頻度とリードタイム）のスコアが低下します。

マイクロフィードバックループの紹介

私が観察したところによると、開発者が1日に10回、100回、あるいは200回も行う基本的なことを、つまりマイクロフィードバックループをきちんと行う必要があります。これは、バグを修正しながらユニットテストを実行することかもしれません。ローカル環境または開発環境に反映されたコード変更を確認することかもしれません。環境内のデータを更新することかもしれません。開発者は、権限を与えられれば、自然に最適化しますが、多くの場合、マイクロフィードバックループが軽視されていることに気づきます。これらのループは意図的に短いため、非常に小さな時間増分で対処することになります。

図3：マイクロフィードバックループは、より大きなフィードバックループに影響を与えるように複合化されます。

なぜこのような小さな問題に焦点を当てる必要があるのかを経営陣に説明するのは難しいことです。実行時間が2分のコンパイル段階を15秒にするために、なぜ時間をかける必要があるのでしょうか？これは多くの作業であり、システムを独立したコンポーネントに切り離す必要があるかもしれません。2日かかるものを最適化することは、取り組む価値のあるものとして理解しやすいです。

その2分はすぐに積み重なり、1日に100分を超える可能性があります。これらの小さな中断は、コンテキストと集中力を失う機会となります。開発者が気を取られたり、メールを開いたり、コーヒーを飲みに行ったりするのに十分な長さであり、集中力とフロー状態から外れてしまうと、フロー状態に戻り、高い生産性を取り戻すまでに最大23分かかると示す研究があります。エンジニアが休憩を取り、頭をすっきりさせるべきではないと言っているわけではありません！しかし、それは意図的に行うべきであり、環境によって強制されるべきではありません。

実際には、開発者はこれらの非活動的な時間を有用なことで埋め合わせます。2つのタスクを同時進行し、それらを切り替えたり、変更をバッチ処理することでコンパイル頻度を遅くしたりするかもしれません。私の研究では、これらの両方ともコードの統合と開発時間の遅延につながることがわかっています。

最適化はどこまで行うべきでしょうか？いつ十分と言えるのでしょうか？変更を15秒まで短縮できたが、3秒まで短縮できると考えているとします。それは投資する価値があるでしょうか？それは、その変更を行うことの難しさと、それがもたらす影響によって異なります。10チームのスピードアップにつながるツールや機能を開発できるなら、それは価値があるかもしれません。個々のチームの最適化ではなく、プラットフォーム思考の出番です。

分散システムは、特に課題となります。システムを異なるデプロイ可能なユニット（通常はマイクロサービス）に分割するには、多くの正当な理由があります。しかし、分散システムは、開発者の効果を含む多くのことを困難にします（マイクロサービスの前提条件を参照）。チームは、チームの自律性やランタイムパフォーマンスを最適化することがありますが、高速なフィードバックループの維持に投資しないため、開発者の効果を犠牲にします。これは、私の会社がよく遭遇する状況です。

組織の効果性

非常に効果的な組織は、効果とフィードバックループを最適化するために、エンジニアリング組織を設計しています。リーダーシップは、時間の経過とともに、開発者がこれらのフィードバックループを段階的に改善することを可能にする文化を醸成します。

それは、リーダーシップによる、テクノロジー、そして開発チームからの摩擦の除去がビジネスにとって不可欠であるという認識から始まります。これは、いくつかの方法で明らかになります。

技術リーダーは、効果を継続的に測定し、再検討します。非常に効果的な組織は、4つの主要な指標と、それぞれの状況にとって重要な他のデータポイントを追跡することにより、データに基づいた意思決定を行うためのフレームワークを作成しています。この文化は経営幹部レベルから始まり、組織の他のメンバーに伝達されます。

指標に加えて、彼らは、日々の環境で働く個々の貢献者に耳を傾けるためのオープンなフォーラムを作ります。開発者は、彼らが直面している問題を知っており、それらを解決するための多くのアイデアを持っているでしょう。

この情報に基づいて、エンジニアリングマネージャーは投資の優先順位を決定できます。大きな問題は、開発者のエクスペリエンスの悪さを解消するために、それに対応した大規模な近代化プログラムを必要とするかもしれません。しかし、多くの場合、それはチームが継続的な改善を行えるようにすることです。

重要な原則は、**開発者エクスペリエンス**を受け入れることです。チームの作業プログラムがこれに焦点を合わせているのはよくあることです。開発者エクスペリエンスとは、エンドユーザー向けの製品開発に使用されるのと同じアプローチ、つまり同じ調査、優先順位付け、成果に基づく思考、そして消費者フィードバックメカニズムを適用して、技術的能力を構築する必要があることを意味します。

開発者のモチベーションを高めるために、非常に効果的な組織はフランチャイズ化を行います。つまり、開発者は自分の日常生活を改善する能力を持つべきです。彼らは、チームが段階的な技術的改善を行い、技術的負債を管理するための方針を持っています。開発者と製品管理の間には、健全なデータに基づいた議論が行われるべきです。非常に効果的な組織は、開発者が革新を起こせるようにする能力も提供します。チームが明確な目標とボトルネックの明確なアイデアを持っている場合、開発者は問題解決に創造性を発揮できます。これらの組織はまた、最高のアイデアを「トップに浮かび上がらせる」方法を作り出し、何が最良かを評価するためにデータを活用して、倍増させます。

**コミットメント**、**測定**、**エンパワーメント**の後には、**スケーリング**が続きます。

組織がある程度の規模になると、規模の経済による効率性を生み出す必要が生じます。組織は、プラットフォーム思考を適用することでこれを実現します。つまり、開発者の効果の向上に特化した内部プラットフォームを作成します。彼らは、開発者の効果を向上させる技術的能力を構築するエンジニアリングチームに投資します。彼らは他の開発チームを消費者とみなし、彼らが提供するサービスは製品として扱われます。チームには、テクニカルプロダクトマネージャーと、消費チームへの影響に関する成功指標があります。たとえば、オブザーバビリティに焦点を当てたプラットフォーム機能チームは、監視、ロギング、アラート、トレース機能を作成し、チームがサービスの健全性を簡単に監視し、製品の問題をデバッグできるようにします。

ガバナンスの必要性は依然として優先事項です。しかし、これは、非常に効果的な組織ではその適用が大きく異なるため、汚い言葉と見なされる必要はありません。彼らは、集中型プロセスから軽量なアプローチに移行します。これは、ガードレールを設定して伝え、長時間の承認プロセスアプローチではなく、チームを正しい方向に優しく促すことです。ガバナンスは、以下の方法で実装された場合、効果に重要な役割を果たすことができます。

• 明確なエンジニアリング目標
• チームとサービスが互いに通信する方法を指定する
• 有用なピアレビューを奨励する
• プラットフォーム機能にベストプラクティスを組み込む
• アーキテクチャの適合度関数による制御の自動化

基本的に、効果的な組織はガバナンスのフィードバックループを短縮します。これについては、今後の記事で詳しく説明します。

ケーススタディ：Etsy

Etsyは、DevOpsムーブメントの先駆者の一人でした。そのリーダーは、迅速な行動が技術戦略とビジネス戦略の両方であるという信念のもと、開発者の効果を文化に組み込むために努力してきました。彼らは、価値のある製品を迅速かつ安全に本番環境に投入する能力を積極的に測定し、技術投資を調整して、ブロッカーや速度低下を修正します。

Etsyの主要な指標の1つはリードタイムであり、これはオフィス全体でリアルタイムに測定、監視、表示されます。リードタイムが特定の主要なしきい値を超えると、リリースエンジニアリングチームはそれを妥当なレベルまで下げるように取り組みます。CTOのマイク・フィッシャーは、Etsyのエンジニアは新しいことを試すためのセーフティネットを持ち、迅速に前進することを「恐れない」と述べています。

ソフトウェアを高速にデプロイすることは、ストーリーの半分にすぎません。真に効果的であるためには、そのソフトウェアは消費者にとって価値があるものでなければなりません。Etsyは、データに基づいたアプローチを採用し、各機能に測定可能なKPIを設定することでこれを実現しています。

コード変更は一連のチェックを受け、開発者は変更がEtsyのパフォーマンス、可用性、障害率などのSLAを満たしていると確信できます。変更が本番環境に適用されると、Etsyの実験プラットフォームはユーザーの行動指標をキャプチャできます。チームは、関連するKPIとユーザー満足度を最適化するために、指標を使用して製品を反復処理します。最終的に変更が価値がないことが証明された場合、それはクリーンアップされ、技術的負債を回避します。

Etsyは現在、開発者エクスペリエンスを優先するイニシアチブを実施しています。それは4つの主要な柱を持っています

このポリシーは、Etsyのリーダーシップから開発者への真のコミットメントを表しています。彼らは、4つの主要な指標を含む指標を追跡し、開発者と月次調査を実施してネットプロモータースコア（NPS）を取得することにより、効果を継続的に検証しています。

結論

この記事の冒頭では、開発者の効果の重要性と、開発者の幸福と生産性への影響について説明しました。ツールやテクニックだけでなく、開発者が達成しようとする成果に焦点を当てました。この調査をさらに進めることで、開発者が製品を開発する際に使用する一連のフィードバックループが見えてきます。

また、マイクロフィードバックループの非効率性が、4つの主要な指標や製品開発速度などのより大きな指標にどのように影響するかについても説明しました。また、原則としての開発者エクスペリエンスの重要性と、プラットフォーム思考が規模の効率と効果を最大化するのにどのように役立つかについても強調しました。

今後のシリーズでは、開発者の効果性と個々のフィードバックループについて、ケーススタディを通してより深く掘り下げて説明します。これらは、組織がどのようにしてこれらの数値を達成し、どのような結果が得られたのかについての具体的な詳細を提供します。また、ローカルおよびグローバルレベルでこれらの最適化を可能にする組織構造とプロセスについても説明します。

次の記事では、最小のマイクロフィードバックループから始めます。