DPEについて理解を深めたい。
見つけた記事をひたすら読んで雑にまとめる。
DPE(Developer Productivity Engineering)とは
Gradle社の定義について。
Is Developer Productivity Engineering the Next Big Thing in Software?では以下のように紹介している。
Championed by Gradle Inc., Developer Productivity Engineering (DPE) is an approach to increasing software development team productivity that focuses on automation technologies and tools, rather than management metrics and best practices. Specifically, this new software development discipline uses acceleration technologies to speed up the software build and test process, and data analytics to make troubleshooting and software quality assurance more efficient. The aim is to achieve faster feedback cycles, more reliable and actionable data, and a highly satisfying developer experience. And, as DPE dovetails with iterative Agile approaches, it yields faster feedback cycles as well.
Gradle社が提唱するDeveloper Productivity Engineering(DPE)は、ソフトウェア開発チームの生産性を向上させるためのアプローチで、管理指標やベストプラクティスではなく、自動化技術やツールに重点を置いています。具体的には、アクセラレーション技術を使ってソフトウェアのビルドとテストのプロセスを高速化し、データ分析を使ってトラブルシューティングとソフトウェア品質保証を効率化する、新しいソフトウェア開発手法です。その目的は、より速いフィードバックサイクル、より信頼性の高い実用的なデータ、そして開発者の満足度の高い体験を実現することです。また、DPEは反復的なアジャイルアプローチと連動しているため、フィードバックサイクルの高速化も実現します。
上記にGradle社が提唱するDPE(Developer Productivity Engineering)
との記載があったため、Gradle社のドキュメントでの定義も見てみる。
Developer Productivity Engineering is a discipline of using data and acceleration techniques to improve essential software development processes for greater automation, fast feedback cycles, and reliable feedback.from Developer Productivity Engineering Book - Gradle Enterprise
開発者生産性エンジニアリングは、データと高速化技術を使用して、ソフトウェア開発プロセスの自動化、高速フィードバックサイクル、および信頼性の高いフィードバックを実現するための学問分野です。
同じくGradleが出しているDeveloper Productivity Engineering HandBookの中では、以下のような記述もある。
- 開発者の生産性と幸福度を最大化するために、主要なソフトウェア開発組織が採用しているソフトウェア開発プラクティス
- 開発者の生産性を向上させるために工学的なアプローチを適用
- 自動化、実用的なデータ、高速化技術に依存し、フィードバックサイクルの短縮、開発期間の短縮など フィードバックサイクルの短縮、ソフトウェア障害の平均解決時間(MTTR)の短縮など、測定可能な結果を提供
つまりこんな感じ
フィードバックサイクル高速化、満足度の高い開発者体験の実現、ソフトウェア開発・開発チームの生産性を上げることを目的に、データ分析と自動化などのエンジニアリングアプローチを、ビルド・CI/CD、テスト、ソフトウェア開発プロセスにまで適用し、改善を図る
個人的には、一言でまとめてしまうならGradleのDPE Handbookに書いてある「ソフトウェア開発およびデリバリーライフサイクルにおけるフィードバックサイクルを最小化すること」というのが気に入っている。
開発組織のアジリティを高める。みたいな言い方でも良いかもしれない。
なぜDPEチーム?
わざわざチームを作る理由は?
- 生産性向上への投資 == より速く物事を進めるようになる
- 開発者の生産性向上は、多くの場合、シニアなエンジニアが行う非公式・リアクティブな仕事となりがち
- 場当たり的なアプローチのままで良いのか?
- ビジネスプロセスエンジニアリング(リーン、シックスシグマ)、製造(総合品質管理、JITなど)など生産性と効率性の向上を目指す専門チームを見かけることは珍しくない
- 現代におけるソフトウェア開発の重要性を考えると、同じ優先順位であるべきではないか?
- DPEは、ROIが明確で、導入判断がしやすい
- 平均ビルド時間を数分短縮した場合の年間コスト削減額は簡単に数値化できる
cost per engineering minute * average build time reduction in minutes * average number of builds per year
- コストがペイするのが明確ならリソースをかけて良いのでは?
- 平均ビルド時間を数分短縮した場合の年間コスト削減額は簡単に数値化できる
- DPEチームが効果的な理由
- フォーカス
- DPEチームの存在が会社・組織としての優先事項である事が示される
- 多くのテックカンパニーはDPE専門チームを設立している
- 明確なオーナーシップを持たせる
- 目標と測定基準、また目標達成を少なくとも1人の専任の仕事としてフォーカスさせる
- DPEチームの存在が会社・組織としての優先事項である事が示される
- 採用競争力
- 多くの企業にとって採用競争に負けないことはミッションクリティカル
- 開発体験は人材を確保・引き止めるために重要な要素
- そのためにもビルド待ち時間やデバッグなど、開発者が好ましくない時間を減らし、より本質的な開発に時間を使えるようにする必要
- DPE専任チームは上記に対する企業の姿勢を示すもの
- 相談窓口
- ツールの情報や業務効率化のアイデア集約し、組織・チーム横断での情報共有やコラボレーションの活性化を担う事もできる
- フォーカス
世の中の例
世の中のDeveloper Productivity Team、Engineering Productivity Teamについての記事を読む
終わり
Gradle社によるDPEの定義はビルド周りの話に寄ってると邪推してしまうが、
「ソフトウェア開発およびデリバリーライフサイクルにおけるフィードバックサイクルを最小化すること」というのは価値が高くて、レバレッジが効く活動であることは間違いない。
DevOpsやfour keysなどの生産性可視化も含めて開発組織の生産性・パフォーマンス改善の取り組みは、長期的に優れた開発組織・プロダクト開発を続けるためには重要な取り組みだと思っているので、この領域は引き続き追っていきたい