見出し画像

グローバル最先端の開発生産性とは?「DPE Summit 2023 in SF」参加レポート(Day2)


DPE Summit 2023とは?(再掲)

Gradleが主催で、昨年から開催されているDPE, DX(開発生産性、開発者体験)に関する2Daysカンファレンス。
開発生産性にフィーチャーした海外カンファレンスでは最大であり、学びの機会として参加しました。
スポンサーは、JET BEAINS、Meta、NETFLIX、Uberと豪華。

Day1のセッションレポート

是非、こちらもチェックしてください!

Airbnb「Transforming Developer Productivity: Airbnb's Triumphs and Trials with a Dose of AI Disruption」

AirbnbのHead of Developer PlatformによるKeynoteセッション。
・ビルド遅延やテストにおいて、特にDevExを向上させる多くの機会があった
・生産性向上に向けては、共通の開発ワークフローのシンプル化、認知負荷とメンテコストの削減が重点
・開発者のペインをリサーチとインタビューで洗い出し、AIアシストをソリューションに活用
というポイントがありました。

Airbnbの技術スタック

成功した投資としては、以下を挙げていました。
・クラウドネイティブなテスト環境の構築
・デプロイメントパイプライン、インテグレーションテスト、ローカルビルド改善
・開発者へのリサーチ&インタビューでボトルネックの特定

高速なビルド実現に向けて、GradleからBazelへの移行を推進(スポンサー様、、、)

レビュー負荷の解消は、昨日も話があがりましたが、AirbnbでもGPTモデルを用いて、レビュー効率化を図っているそうです。

LinkedIn「How to Make Your Developers Unproductive and Unhappy」

LinkedInのPrincipal Staff Software EngineerによるKeynoteセッション。
・壮大なサーベイ設計でなくとも、数人との対話からでも、継続的にメンバーが直面する生産性課題の実態を調査し続けるべき(想像で済ませない)
・バックエンド、機械学習、モバイル開発など、異なるワークフローや責務に合わせたツールや測定が必要
・開発者が、人が、注力すべきポイントが何かを見定める
というポイントでした。

人間によるレビューは、人間の判断と認識に関わるものを対象とすべきで、その他の不要なワークフローにおける過度なレビューは削減 or 自動化すべき。または、レビューポイントを解消するためにコーディングフレームワークを変更する事。

開発者の目的はビジネスへの影響をもたらす事であり、言語や技術やツールの選定への決断を下すことではない。なので、ベースとなる自動化されたパイプラインの"Paved Path"を提供すべきだが、一方で、"Escape Hatch"を両立させる柔軟性が重要。

「タスクは、人間の注意を必要としなくなった時点で”終了"とみなす」絶対的には難しい部分もあるが、限りあるリソースの中で、何に注意を払うべきかは一考の余地しかないですね。

Uber「From Myth to Legend: How Generative AI Can Supercharge Productivity」

UberのPrincipal Engineerによるセッション。
・デザインからリリース後の運用まで、AIによる生産性向上の可能性を追求
・異なるタイムゾーンで働く開発者が、複数のタイムゾーンにいるため、レビュー待ち時間を削減する事が重要
・コードベースを基にコンテキストを学習した自動コード補完、技術的負債の自動修正、コードレビューのフィードバック自動対応、CIエラーの自動修正、等に実際に適用が進んでいる
というポイントでした。

コードレビューのフィードバックの自動修正は、すでに大きな成果を挙げており、年間で10M$削減効果があるらしい。

どのモデルを採用するかは、移り変わりが激しい中では悩ましいのが現状。

サムスンの機密コード流出によるChatGPT禁止に触れながら、リスクについても言及してました。

LinkedIn「Behind the Scenes of Productivity Metrics at LinkedIn」

LinkedInのSenior Staff Software Engineerによるセッション。
・明確なコンテキストや行動に移せないメトリクスの計測に時間をかけてはいけない
・LinkedInでは、経営層、ロールに合わせたデータの可視化や信頼区間の提供まで行っている
・メトリクスはツールではなく、開発者(体験)に結びつける
というポイントでした。

良し悪しの判断ができない指標は、悪い指標

よいメトリクスを運用し、インサイトをインパクトに結びつけるには、継続的な各ステークホルダーのレビューと連携が重要。

・ゴールは、データの可視化ではなく変革を起こすこと
・指標の定義の前に、ペルソナとそのペインやニーズを抑える
・チームや組織で継続的に議論をし、より意義のある指標へ育てる
・将来のメトリクスの変化に向けて、今日からできることへトライする

Airbnb「The Airbnb Journey Towards Enhanced Developer Productivity」

AirbnbのSenior Product Managerによるセッション。
・一度に完璧ですべてのメトリクスを収集しようとせず、小さく計測して精度を挙げていくべき
・Airbnbにおけるメトリクスでは、マージ後のデプロイまでのLag Timeがボトルネックだった
・DORAのアウトカムに繋がるKey Driverが何かを定める事が重要
がポイントでした。

DORA metricsは、遅行指標であり、その背景となる事象の把握が必要。
また、DevOpsパイプライン以外の開発者体験の課題を見逃してしまうのが課題。

DORAを超えるものとして、SPACEフレームワークやフィードバックループがあるが、もう一段、ブレークダウンする必要がある。自分のチームにおけるキードライバーが何かを議論し、定める事が大事。

Adobe「Unlocking High-Velocity Development Strategies, Tactics, and Metrics」

AdobeのSenior Engineering Leaderによるセッション。
・DORAやSPACEメトリクスは、エンジニアリングのアジリティ、安定性、デリバリーに関する包括的な洞察を提供するものとして便利
・加えて、独自でパフォーマンスを測る指標を定義している
・Adobeにおいても、プロダクト開発ライフサイクル全体におけるGen AIの活用を進めている。
というポイントでした。

EPIというKPIを独自に設定し、デリバリーのパフォーマンスに影響を与える要素を可視化。

これを全部Adobe製品に実装してもらえたら、乗り換えるかも。笑

2日通じての感想

Airbnb、Uber、Adobeの様に、Generative AIを幅広いソフトウェア開発ライフサイクルに適用しながら、ダイナミックに開発者体験の効率化を進めている様は、シンプルにすごいなと感じました。自分自身、まだプロダクトマネジメントにおける活用進められておらずで、非常に刺激になりました。

同時に、開発生産性に関連するメトリクスのマネジメントについても、フレームワークありきではなく、「開発者体験」「価値創造」ありきで設計していくアプローチや、小さくでも出来る工夫を追求し続ける、オペレーション装着をやりきる等、自分自身の開発生産性に対するアプローチを見つめ直すキッカケとなりました。

また、弊社のエンジニア組織支援クラウド「Findy Team+」が、ちょうど英語化対応し始めたので、現地のエンジニアに直接フィードバックをもらったり、プロダクトの非連続な成長に向けた議論をしたり、今後の方向性を改めて深く検討できるよい機会でした。

開発生産性向上に興味がある方は、ぜひ弊社の「Findy Team+」を通じた開発者体験のアップデート事例をご紹介させてください!

プライム市場の1000人を超えるエンジニア組織から、メガベンチャー、アーリーフェーズのスタートアップまで幅広い顧客にご活用頂いております。


また今後も、海外の開発生産性事例を発信していくので、よかったらフォロー頂けると嬉しいです!

▼Xはこちら
https://twitter.com/bachio178

▼LinkedInはこちら
https://www.linkedin.com/in/masa-inaba-0249a8286/

この記事が気に入ったらサポートをしてみませんか?