Open13

世の中のDeveloper Productivity Team、Engineering Productivity Teamについての記事を読む

様々な会社のDeveloper Productivity Team、Engineering Productivity Teamについて調べてみることで、Developer / Engineering Productivity関連の取り組みについて解像度を上げたい

https://engineering.atspotify.com/2020/08/how-we-improved-developer-productivity-for-our-devops-teams/
  • SpotifyのPlatform Developer Experience (PDX) Tribeに関する記事。
  • PDX Tribeがやること
    • プロセスを自動化するツールを構築しベストプラクティスを確立することによって、エンジニアの創造性を解放すること
    • エンジニアが下すべき決定の数を減らし、基盤となるインフラの統合を自動化することでテクノロジーの複雑さを軽減すること
  • スピードを重視
    • アイデアを素早く製品化し、ユーザー体験を向上させるための実験を行い、競争力を維持すること
  • PDXはCI/CDツール、ウェブツール、テストツール、その他開発者向けのツールを構築し、生産性を向上させている
  • Spotifyは「ops in squad」モデル
    • 各チームが機能をエンドツーエンドで所有し、責任を持ち、開発と運用の両方と協力して機能のあらゆる側面を構築
    • チームは非常に自律的で、機能をリリースするために必要なすべての能力を持つ
    • 迅速な運用が可能な一方で、ツールセットやエンジニアリング手法に断片性が生じている
  • PDX Tribeが提供しているもの
    • Golden Paths
    • テスト認証プログラム
      • 開発したコードに信頼性の低いテスト(flaky test)が含まれている場合は、その旨を通知
      • サービスが認証要件を満たすと、サービスの横にバッジが表示される
        • そのサービスがメンテナンスされていること、品質管理のベストプラクティスに従っていることを表す
    • ビルド時間、コードカバレッジ、テストスイートの信頼性に関するレポート
      • テスト認証に時間をかけたチームが、ブロックバグやリアクティブワークを激減させたことに気づく
    • Tingle CI/CD
  • エンジニアがさらに上のスタックで作業できるようなツールやサービスを一貫して作り続けることがDevOps組織を向上させる
  • 感想
    • イメージ通りといえばイメージ通り
    • Golden Pathsと同時にそれ以外の選択肢を提供するのはPlatform Engineeringとしては王道
    • 新規サービスのセットアップからビルドとデプロイまでの時間を、14日間から5分間に短縮した話は規模が大きければ大きいほどインパクトが強く、DPEに投資する理由そのものって感じ
    • テスト認証プログラムも面白い

https://www.cyberagent.co.jp/way/list/detail/id=25235
  • サイバーエージェントのDeveloper Productivity室
  • 背景
    • 「Developer Productivity室」は、開発者の生産性向上を加速することでコストはもちろん、品質担保やチャンスポイントの増加に貢献し、サービス開発を支えていくことを目的に今年の6月に設立した組織です。
    • 「デリバリ」「品質担保」「リリース」「検証」といったソフトウェアのリリースのために繰り返し行われる一連のプロセスに集中して効率化を進めており、これらの無駄な部分を短縮することで、リリースサイクルを早めることを目指しています。
  • 担当範囲・プロジェクト
    • A/Bテスト&Feature Flagプラットフォーム
    • クライアント領域の専門技術組織CATS (Client Advanced Technology Studio ) の
      Client Productivityチーム
      • UIコンポーネントカタログ(Playbook)と画像回帰テスト(Visual Regression Test)の改善
    • CI/CDプロダクト「Kapetanios」「PipeCD」
  • 目指す先
    • デリバリからリリース後の検証までの期間を1/20に短縮したい
      • 大きな競争力を持ち、変化に柔軟に対応でき、賢く試して賢く失敗するといった良いサイクルが生まれる
    • 開発者に最高の開発体験を届けたい
      • サービス側のエンジニアの開発効率を上げ、本質的な価値に繋がる技術選定・意思決定をする際の助けとなるような役割を果たす
      • クライアント・バックエンド技術全てを含めた総合的なベストプラクティスの確立

https://note.com/cybozu_dev/n/n1c1b44bf72f6
https://www.docswell.com/s/miyajan/KRJX45-how-to-start-and-grow-engineering-productivity
  • ミッション
    • 多様で価値あるサービスを迅速に提供するため、部署やプロダクトを横断して、生産的でオープンな開発基盤を整備する
  • 担当範囲
    • チームを横断した開発効率を高める基盤の整備
      • AWSマルチアカウント管理
      • オートスケールする GitHub Actions セルフホストランナーの構築・運用
      • リリース管理システムの開発・運用
    • 開発チームの業務の自動化や効率化の支援
    • 最新の生産性向上に関わる技術のキャッチアップ、探求
      • 探索タイム
      • 知見を広げることによって、よりよい方法で問題解決ができるように
    • Productivity Weekly
      • 生産性向上に関する記事や、GitHub、AWS、CircleCI などの更新情報などを見ていく会
  • 背景
    • 開発チームで活動が閉じてしまっており、チーム横断の開発基盤を整える必要性
    • プロダクトの進化、お客様に価値を提供していくために重要な開発基盤や改善の取り組みに時間を割けるように

https://hrmos.co/pages/kakakucom/jobs/1014360
  • カカクコムのDeveloper Productivity EngineerのJD
  • 既存ツールからの移行(タスク管理:JIRA→Wrike、ソース管理:Bitbucket→GitHub)も業務範囲
    • それ以外は
      • 標準的な開発プロセスの策定
      • 共通的なCI/CD環境の整備
      • 開発プロセス全体の最適化や生産性向上の推進
      • etc..
    • 評価制度の確立もあったのは意外
      • 評価も生産性に関わるよね的な話かcentralizedしたいものを担ってる?
  • 必須要件にDevOps/SREや開発プロセスの話があるのはまぁ王道
  • 歓迎条件に☟とあるのはイネーブルメントチーム的な動きをするからだと理解
    • メトリクス分析や開発チームへの改善提案のご経験
    • 開発プロセスの策定や最適化、生産性向上活動のご経験
    • コンサルティング業務のご経験

https://thinkit.co.jp/article/19713

感想

これだけの規模だと標準言語なりセキュリティなり何らかのガイドラインは存在する。自律性があると言いつつも一定は制約はRECがあろうがなかろうが存在することが多い。そのためそこに準拠するのか各サービスでいちいち考えるよりは、集約して便利な環境が提供される方がトータル開発者的にもハッピー、なのは前職の経験からも理解できる。
centralizedとstandardizeがどれだけやり切れるかは、提供する環境がどれだけ生産性高い次第。
理想はゴールデンパスを提供して、乗る事で圧倒的に生産性高めることが出来る状態を作る。その上でカスタマイズやある程度の自律性も提供はすること。そこまで行ければ自然とcentralizedとstandardizeされた環境が基本的には選択されるはず

メモ

  • 開発プロセスのさらなる効率化を目指してREC(Reliability Engineering Center)立ち上げ
    • 開発に使われるツール、環境の標準化、管理を担い、開発者にとって理想的な環境づくりを目指す
  • REC(Reliability Engineering Center)
    • 「LINEとLINER(LINEのスタッフ)がより良く成長できる最高の環境(開発環境)を創出する」
    • 「開発者にとって価値ある環境とツールを提供する」
    • 「環境とツールをより価値あるものにする方法を探し出して実行する」
    • グループ全体で約3,000人の開発者。DevOpsの手法をとりながら、ソフトウェアの開発、リリース、フィードバック、改善のサイクルを高スピードで回している
    • RECは開発者がより快適に、かつ高効率に仕事ができるツールと環境を整備・提供すること
  • 組織構成
    • Enterprise Devチーム:全社の開発者が利用するツールの開発・運用を担当
    • Dev Supportチーム:デプロイツールやロードテストツール、監視ツールなどの開発・運用を担当
    • LIAM Devチーム:社内システムから利用できる新しい統合認証認可基盤の開発・運用を担当
    • LINE Auditチーム:社内システムの監査ログの保管と閲覧を目的としたログ基盤の開発を担当
    • Growth Devチーム:サービスの補助開発を担当
    • REC業務支援チーム:予算や契約の支援などの事務手続きを担当
    • Delivery Infrastructureチーム:サーバサイドアプリケーションをデプロイするための内製ツールを開発・運用する組織
    • Observability Infrastructureチーム:サーバサイドアプリケーションを監視するための内製ツールを開発・運用する組織
    • SETチーム:テスト自動化のための内製ツールの開発・運用や特定のプロダクトのテスト自動化戦略の立案・実行を行う組織
  • RECのもう一つの役割
    • 開発に使うツールや環境の標準化を促進すること
    • 個別最適化は、開発者の生産性を高める効果が期待できる一方で、ツールの不統一性を招き、それが開発者の業務効率に負の影響を与えかねないという問題を内在
    • CI/CDにしても、チームごとに異なるツールを使い、個別にパイプラインを構築・管理するよりRECが一括して担う方が開発チームの工数は間違いなく減るはず
    • 開発ツール/開発環境の標準化や管理には、開発者に不自由を感じさせてしまうリスクも
      • レギュレーションに準拠したツールをRECが整備し、それを使うことでその手間を削減できるメリットは大きい
      • 開発者が使いたい新たなツールがレギュレーションに適合できるかどうかをRECが点検し、開発者をサポートすることも視野に
  • 開発者が迷うことなく業務に打ち込める環境
    • 「開発者が困ったときの相談窓口」にも
    • 新ツールの情報、開発業務効率化のアイデアを集約し、組織・チーム横断での情報共有やコラボレーションの活性化にも
  • ツールや開発環境のセキュリティを担保、メンテナンスは開発者の本来業務ではない。RECが担うことでより本質的な作業に時間を当てられる
    • より働きやすい場所になり結果として開発者のモチベーションアップにつながっていくはず
  • Developer Success
    • 開発者の幸せのためにはなんでもするロール
    • 開発が速くなったり、負債になる前に潰したりルールを作ったり、DXを上げるための組織作りをすることを全部やっていく
    • リリースフローで承認を5回挟まずに済むようにするとか、メンテ不可能にならないように事前に防ぐとか、セキュリティを高めるけど、開発効率も高める動きをすることで、開発者を幸せにする仕事
  • DPEとかDeveloper Experienceとニュアンスは近い
    https://logmi.jp/tech/articles/321709
  • Netlifxのproductivityチームの話
    • デベロップ、デリバリー、オブザーバビリティドメインがある
    • まとめてプロダクティビティ・エンジニアリング
  • Can productivity be engineered?
    • Productivity Engineering teamの役割
      • we exist to make the lives of Netflix developers easier
      • 開発、デリバリー、オブザーバビリティにまつわる様々な「Netflixイズム」を抽象化し、開発者が自分の専門分野に集中できるようにする
        • コーディング、テスト、デバッグ、依存関係管理、デプロイ、アラート、モニタリング、パフォーマンス、インシデント対応などを支援する
      • “paved road”
        • 開発者を継続的にサポートするために構築したフレームワーク、プラットフォーム、アプリ、ツールなどを利用すること
          • ワークフローを合理化し、開発者が可能な限り効率的かつ効果的に作業できるようにするためのもの
          • 前方の障害物が取り除かれていれば、行くべき場所に早くたどり着けるし、途中のサポートも受けられる
    • 高級レストランでの食事のような体験
      • 店員のことを思い出すことも、好きなものを探すのに苦労することも、料理がどうだったか気にすることもなく、ただその体験を楽しむことができる
      • レストランとウエイトレスとして、開発者を顧客として、美しいエンドツーエンドの体験を提供する
  • Measuring Outcomes vs. Output
    • 生産性をすべて測定するのは難しく、全てを賄える単一の指標は存在しない
    • developer productivity teams should focus on impact and outcomes
      • Netflixは、何よりも顧客満足度に重点を置いている
      • 何かをどのように提供するかも重要だが、提供されたもののインパクトが最終的にもっと重要である
      • "If you're running around a track super-fast, but you're on the wrong track, does it matter? So really, what are you delivering? How you're delivering is important. But if that thing that you're delivering is ultimately doing what you want it to do, that's the most important thing."
    • 結果は常に出力や活動よりも優先される
      • DORAは成功を測定するための重要な指標
      • 生産性の主要業績評価指標(KPI)は、顧客満足度に関連するチームのパフォーマンスを反映したものとみなされる
    • 主要な測定基準は、ベンチマークを確立することによって、生産性チームにパフォーマンスの全体的なビューを提供
      • 何も測定または追跡されていない場合は、組織として改善することは困難
  • Comparing Productivity
    • 開発者の生産性をチーム間で比較することは、よく言えば茨の道であり、悪く言えばチームの士気に関わる危険なこと
    • Netflixでは、生のデータだけに頼るのではなく、開発チームのコンテクストを考慮した見方をする
      • プロジェクトはそれぞれ異なり、顧客基盤も、ユースケースも、ペルソナも、チームがソフトウェア開発ライフサイクルの中でどこに位置するかも異なる
    • リンゴとオレンジを比較するのは良い数学ではない
      • 新しいものを作り始めたばかりのチームと、成熟した製品を持つチームとでは、見た目が大きく異なる
      • 同じ空間で、同じ方法で、同じ人たちと、同じことをやっているチームは、ほとんどないから
    • 顧客満足度(CSAT)に関わる成果の測定も一筋縄ではいかない
      • Netflixでも、業界全体でも、社内チームの満足度は、顧客対応チームの満足度よりも低くなる傾向があることが分かっている
      • コンテキストがすべて。生産性の測定は、コンテキストを意識して行う必要がある。
  • 成功するにはその成功をどのように測定するかを理解しなければならない
    • 組織が望ましい結果に向かって前進していなければ、生産性はあまり重要ではない
  • Netflixは、生産性を単なる概念や生データの集合体としてではなく、実際の装置として捉えている
    • 生産性を単なる概念やデータとしてではなく、実際の装置として捉え、共感できる効率性を追求し、顧客満足度やチームのQOLを向上させる
  • 指標はその文脈によってのみ有効

https://devinterrupted.com/creating-a-culture-of-engineering-productivity-at-netflix/
ログインするとコメントできます