Open21
世の中のDeveloper Productivity Teamについての記事を読む
r.kagaya様々な会社のDeveloper Productivity Team、Engineering Productivity Teamの取り組みについて
r.kagaya
- SpotifyのPlatform Developer Experience (PDX) Tribeに関する記事。
- PDX Tribeがやること
- プロセスを自動化するツールを構築しベストプラクティスを確立することによって、エンジニアの創造性を解放すること
- エンジニアが下すべき決定の数を減らし、基盤となるインフラの統合を自動化することでテクノロジーの複雑さを軽減すること
- スピードを重視
- アイデアを素早く製品化し、ユーザー体験を向上させるための実験を行い、競争力を維持すること
- PDXはCI/CDツール、ウェブツール、テストツール、その他開発者向けのツールを構築し、生産性を向上させている
- Spotifyは「ops in squad」モデル
- 各チームが機能をエンドツーエンドで所有し、責任を持ち、開発と運用の両方と協力して機能のあらゆる側面を構築
- チームは非常に自律的で、機能をリリースするために必要なすべての能力を持つ
- 迅速な運用が可能な一方で、ツールセットやエンジニアリング手法に断片性が生じている
- PDX Tribeが提供しているもの
- Golden Paths
- エンジニアリング技術やプロセスの標準化
- そのまま使うのではなく、各チームが自律的に選択を行えるようにcustomやAPI利用の選択肢も提供
- https://engineering.atspotify.com/2020/08/17/how-we-use-golden-paths-to-solve-fragmentation-in-our-software-ecosystem/
- テスト認証プログラム
- 開発したコードに信頼性の低いテスト（flaky test）が含まれている場合は、その旨を通知
- サービスが認証要件を満たすと、サービスの横にバッジが表示される
- そのサービスがメンテナンスされていること、品質管理のベストプラクティスに従っていることを表す
- ビルド時間、コードカバレッジ、テストスイートの信頼性に関するレポート
- テスト認証に時間をかけたチームが、ブロックバグやリアクティブワークを激減させたことに気づく
- Tingle CI/CD
- Golden Paths
- エンジニアがさらに上のスタックで作業できるようなツールやサービスを一貫して作り続けることがDevOps組織を向上させる
- 感想
- イメージ通りといえばイメージ通り
- Golden Pathsと同時にそれ以外の選択肢を提供するのはPlatform Engineeringとしては王道
- 新規サービスのセットアップからビルドとデプロイまでの時間を、14日間から5分間に短縮した話は規模が大きければ大きいほどインパクトが強く、DPEに投資する理由そのものって感じ
- テスト認証プログラムも面白い
r.kagaya
Teamの紹介をしているわけではないが、slackのdeveloper productivity teamがremove development環境を提供した話
r.kagaya特定チームの話ではないがDeveloper Enablementについて。DPEチームと同等な役割っぽい
r.kagaya
- サイバーエージェントの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に短縮したい大きな競争力を持ち、変化に柔軟に対応でき、賢く試して賢く失敗するといった良いサイクルが生まれる
-
開発者に最高の開発体験を届けたいサービス側のエンジニアの開発効率を上げ、本質的な価値に繋がる技術選定・意思決定をする際の助けとなるような役割を果たすクライアント・バックエンド技術全てを含めた総合的なベストプラクティスの確立
-
r.kagaya
- ミッション
多様で価値あるサービスを迅速に提供するため、部署やプロダクトを横断して、生産的でオープンな開発基盤を整備する
- 担当範囲
- チームを横断した開発効率を高める基盤の整備
- AWSマルチアカウント管理
- オートスケールする GitHub Actions セルフホストランナーの構築・運用
- リリース管理システムの開発・運用
- 開発チームの業務の自動化や効率化の支援
- 最新の生産性向上に関わる技術のキャッチアップ、探求
- 探索タイム
- 知見を広げることによって、よりよい方法で問題解決ができるように
- Productivity Weekly
- 生産性向上に関する記事や、GitHub、AWS、CircleCI などの更新情報などを見ていく会
- チームを横断した開発効率を高める基盤の整備
- 背景
- 開発チームで活動が閉じてしまっており、チーム横断の開発基盤を整える必要性
- プロダクトの進化、お客様に価値を提供していくために重要な開発基盤や改善の取り組みに時間を割けるように
r.kagayaDPEチームを作るべき利用についての記事
r.kagaya
- カカクコムのDeveloper Productivity EngineerのJD
- 既存ツールからの移行（タスク管理：JIRA→Wrike、ソース管理：Bitbucket→GitHub)も業務範囲
- それ以外は
- 標準的な開発プロセスの策定
- 共通的なCI/CD環境の整備
- 開発プロセス全体の最適化や生産性向上の推進
- etc..
- 評価制度の確立もあったのは意外
- 評価も生産性に関わるよね的な話かcentralizedしたいものを担ってる？
- それ以外は
- 必須要件にDevOps/SREや開発プロセスの話があるのはまぁ王道
- 歓迎条件に☟とあるのはイネーブルメントチーム的な動きをするからだと理解
- メトリクス分析や開発チームへの改善提案のご経験
- 開発プロセスの策定や最適化、生産性向上活動のご経験
- コンサルティング業務のご経験
r.kagaya
感想
これだけの規模だと標準言語なりセキュリティなり何らかのガイドラインは存在する。自律性があると言いつつも一定は制約は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が担うことでより本質的な作業に時間を当てられる
- より働きやすい場所になり結果として開発者のモチベーションアップにつながっていくはず
r.kagaya- Developer Success
- 開発者の幸せのためにはなんでもするロール
- 開発が速くなったり、負債になる前に潰したりルールを作ったり、DXを上げるための組織作りをすることを全部やっていく
- リリースフローで承認を5回挟まずに済むようにするとか、メンテ不可能にならないように事前に防ぐとか、セキュリティを高めるけど、開発効率も高める動きをすることで、開発者を幸せにする仕事
- DPEとかDeveloper Experienceとニュアンスは近い
https://logmi.jp/tech/articles/321709
r.kagayaSREだが進化の過程などが参考になりそう
r.kagaya- Netlifxのproductivityチームの話
- デベロップ、デリバリー、オブザーバビリティドメインがある
- まとめてプロダクティビティ・エンジニアリング
- Can productivity be engineered?
- Productivity Engineering teamの役割
we exist to make the lives of Netflix developers easier- 開発、デリバリー、オブザーバビリティにまつわる様々な「Netflixイズム」を抽象化し、開発者が自分の専門分野に集中できるようにする
- コーディング、テスト、デバッグ、依存関係管理、デプロイ、アラート、モニタリング、パフォーマンス、インシデント対応などを支援する
- “paved road”
- 開発者を継続的にサポートするために構築したフレームワーク、プラットフォーム、アプリ、ツールなどを利用すること
- ワークフローを合理化し、開発者が可能な限り効率的かつ効果的に作業できるようにするためのもの
- 前方の障害物が取り除かれていれば、行くべき場所に早くたどり着けるし、途中のサポートも受けられる
- 開発者を継続的にサポートするために構築したフレームワーク、プラットフォーム、アプリ、ツールなどを利用すること
- 高級レストランでの食事のような体験
- 店員のことを思い出すことも、好きなものを探すのに苦労することも、料理がどうだったか気にすることもなく、ただその体験を楽しむことができる
- レストランとウエイトレスとして、開発者を顧客として、美しいエンドツーエンドの体験を提供する
- Productivity Engineering teamの役割
- 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を向上させる
- 指標はその文脈によってのみ有効
r.kagaya- Slackのモバイルデベロッパーエクスペリエンスチーム（DevXp）の目標
開発者が快適で生産的なエンジニアリング体験を享受しながら、自信を持ってコードを出荷できるようにすること- developer sentiment、CI stability、マージまでの時間（TTM）、テストの失敗率など、生産性と開発者の経験を測定するためのメトリックと調査
- モバイルデベロッパーエクスペリエンスチーム
- 2017年3人 -> 2022年5人体制に
- focused on these areas
- Local development experience and IDE usability
- Our growing codebase
- Ensuring visibility into problematic areas of the codebase that require attention
- Continuous Integration usability and extensibility
- Automation test infrastructure and automated test flakiness
- Keeping the main branch green.
- Making sure the latest main is always buildable and shippable
- チームが成長するにつれて開発サイクルタイム増加に対処しなかった場合のコストを概算
- Approach
- Listen to customers and work alongside them
- 顧客であるモバイルエンジニアが機能を開発する際にパートナーとなり課題を観察
- Survey the developers
- モバイルエンジニアを対象に四半期ごとに調査を行い、モバイル開発に関する一般的なNPS（Net Promoter Score）を把握
- Summarize developer pain points
- フィードバックを、チームとして取り組める作業領域に抽出
- Gather metrics
- ソリューションが問題を解決していること・及ぼした影響を正確に把握するためには、最初に測定することが重要
- 開発者が抱えている問題点に関連する追跡すべき指標を考え、ダッシュボードでそれを追跡し測定基準の経時的な変化を確認
- Invest in experiments that improve developer pain points
- Consider using third-party tools
- Repeat this process
- 解決策を打ち出したら、それが正しい方向に動いているかどうか、指標を確認し、次の問題領域へと進む
- Listen to customers and work alongside them
- Developer pains
- CI test jobs that take a long time to complete
- CI実行まで長い時間待たなければならない場合、コンテキストスイッチが発生
- コンテキストの切り替えは、開発者の生産性を低下させる
- iOSとAndroidでどう対策したか書いてる
- Test-related failures
- Flaky tests
- メインブランチでのテストの失敗の 57% が flaky なテストによるものだった
- 自動検出・抑制するシステムを構築
- CI-related failures
- Jenkinsについて色々書いてる...
- Merge conflicts
- Aviatorと社内ツールを組み合わせて、マージキューを作成
- Checking pull request progress/status
- Git のイベントを監視して、プルリクエストの作成者とレビュアーに Slack で通知するサービスを開発
- Mergebot
- プルリクエストにコメントが追加されたりステータスが変わったりすると、プルリクエスト作成者に通知
- プルリクエストレビューアには、プルリクエストが割り当てられたときに通知
- slackからPRマージ
- 「github scheduled reminder」
- PRの更新をSlack通知で開発者に通知するように
- Mergebot
- Git のイベントを監視して、プルリクエストの作成者とレビュアーに Slack で通知するサービスを開発
- CI test jobs that take a long time to complete
-
Slackをソフトウェアを作るのに世界で最も適した場所に- そのためにモバイル開発者の体験に投資す
to keep developers in the flow and make their working lives easier, more pleasant, and more productive
r.kagayaタイミーのDevEnable室。キャリアや育成フォーカス
r.kagaya- 生産性向上への投資 == 速く進めるようにすること
- テック企業が得意なことの一つ
- プロダクティビティスクワッド
- 他のエンジニアリングチームを早く進めるようにすることをミッションとしたチーム
- 支援内容
- ビルドの自動化
- 継続的インテグレーションの基盤整備
- A/Bテストフレームワークの構築
- 本番環境へのデプロイメント・監視ツールの作成
- 自動テスティングフレームワークの構築
- 新機能を簡単に追加できる基盤の用意
- トレーニングセッション
- データの変換や移行
- イテレーションと学習速度の向上
r.kagaya- 技術戦略グループ
- 「特定の分野ごとに集まって、組織横断で解決すべき課題にメスを入れていく」
- ワーキンググループ
- ディレクション
- 横断
- フロントエンド
- DevOps
- ペイン強度とペイン頻度で課題の優先度決め
- 課題毎に考える情報
- 背景、何をやるのか、それをやると何が得られるのか、それをやらないとどうなるのか、リソースはどのくらい必要なのか
- 大事なのは十分達成可能であると思える小目標を立てること
- 「進んでる感」
- マクドナルド理論
r.kagaya日々増え続けるDB上のレコードとそのデータの活用を滞りなく実現するため、Data Engineeringに対しDevOpsとSREの原則を適用することでスケールさせていこうとしています。
Data Reliability Engineering (DRE) は、”データインフラの管理に対して、DevOpsとSite Reliability Engineering(SRE)の原則を適用する、データエンジニアリングの専門分野”と私たちは定義しています。
DREでは、データの生成プロセスの観測可能性を向上に重きをおいて、より早くインシデントを検知し、データ障害が起きたとしてもその傷口がより浅くなるように目指しています。またCI/CDのようにパイプラインを構築し、ヒューマンエラーを引き起こす可能性のある手動な手順を徹底的に自動化しています。