Developer Productivity Engineerについて知るためにJob Descriptionを眺める

はじめに

年末に最近関心があるDeveloper Productivity Engineerについて理解を深めようと、JDを色々見てみた。
会社のチョイスはIndeedなどで検索して引っかかったものが中心で、国内/海外、シニアなどの分類はしておらず、加えてDeveloper ExperienceやクライアントサイドでのJDもあったが今回は一回除外した。
数も少ないので、また別のタイミングで再度まとめたい。

Developer Productivity Engineeringとは

まずはそもそもということで、一般的な定義について振り返った。
歴史はわかっていないが、以下記事でGradle社が提唱するDPE(Developer Productivity Engineering)との記載があっため、Gradle社の定義を見てみる。
Is Developer Productivity Engineering the Next Big Thing in Software?

Gradle社のDeveloper Productivity Engineering Book - Gradle Enterpriseでは以下のように記載されていた。

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

そして先ほど触れた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. DPE is here to stay.
from Is Developer Productivity Engineering the Next Big Thing in Software?

DevOpsの流れを汲んでいるため自明かもしれないが、どちらも自動化やデータ分析、フィードバックサイクルの高速化といったキーワードがあり、SREとも似たものを感じた。
SREはサービスの信頼性を高めるために自動化などのアプローチを適用しているが、Developer Productivity Engineeringでは対象がソフトウェア開発、開発チームの生産性となっている。
SRE自体、DevOpsの実装と紹介されることもあるが、Developer Productivity EngineeringもDevOpsの取り組みを自動化やリーンなどの組織改善、データ分析も活用して、ソフトウェア開発、開発チームの生産性の改善・向上によりフォーカスする取り組みだと感じた。

定義に関しては以下の記事が参考になる。
アジャイル・DevOpsからDeveloper Productivityへ ~食べログのDeveloper Productivityチームが目指す姿~

Developer Productivity Engineerとは

本格的にJDを通してDeveloper Productivity Engineerとはについて見ていく。

Twitter / Software Engineer II - Developer Productivity

まずはTwitter社。
世界中の何千人ものTwitter開発者をサポートする効率的な次世代ビルドシステムカスタムツール、スケーラブルシステム、Bazel を使ったオープンソースなど、スケールの力を活かしてモノレポで開発者のワークフローを加速させるとあるように、TwitterのBuildチームに所属し、ビルドや開発ワークフローを改善する事で開発者の生産性向上に貢献するっぽい。

キーワードとして以下に興味があるなら、という記述が。後ろの二つは一般的なソフトウェアエンジニアと変わらず。そして前二つのDeveloper Productivityや開発ワークフロー辺りも一目瞭然で当たり前の話だが。

  • improving developer productivity
  • the edit/build/test workflow
  • proficiency with algorithms and data structures
  • Java/Scala/Python

何をするか 

ビルドツールやプラットフォームが具体的にどういうものかイメージ出来てないが、チーム紹介で述べられている通り、Twitter社でのCI/CDなどの開発ワークフロー全般の改善をする感じっぽい。
それ以上はイメージがついてない。

Qualifications

QualificationsはScala,Java,Pythonなどのバックエンドでの経験やアルゴリズム、データ構造などの記述があり、ここは一般的なソフトウェアエンジニアと変わらず。
スピードと品質を追求,自動化への意欲あたりはSREと似たものを感じるが、開発生産性向上への熱意やソフトウェアエンジニアリングのベストプラクティスのモデルの話がDeveloper Productivity Engineer特有の差分に見える。

MongoDB - Lead Engineer, Developer Productivity

MongoDBのJD、こちらはLead Engineer。
本筋とは関係ないけどSuccess Measuresが明示されているのはいつまでに何が出来ればいいのかイメージしやすいので良い。

何をするのか

CI/CDやビルドに限らず、Twitter社よりは幅広く、Developer Productivity Engineeringに取り組む印象。

Developer Productivity creates innovative developer tools and systems to solve some of the toughest challenges related to engineering: CI/CD, Code Analytics, Distributed Systems Verification, Test Fuzzing, Reproducibility and Debuggability, Test Minimization, and more.

Qualifications

Developer Productivity Engineer特有のものはなし。一般的なリードエンジニアや分散システム、クラウドへの経験を求める内容。

Slack - Software Engineer, Developer Productivity

何をするのか

CI/CDの話が出ているのはイメージ通りだが、SREっぽいパフォーマンス、スループット、故障率に関する主要な指標を管理するとあるのが意外。

Qualifications

CSやデータ構造などのソフトウェアエンジニアとしての一般的な話に加えて、Jenkins、Kubernetes、AWS、GCE、Azureのいずれかの経験があれば尚可、またCI/CD、Experimentationの経験があればボーナスとのこと。
社内プラットフォームやツールの構築経験っていう記述もあるので、やはりポジションの性質上インフラやPF寄りの経験はあるとプラスっぽい。

Apple - Senior Productivity Engineer

何をするのか

以下などはイメージ通りの内容ドンピシャ。

  • Identify and tackle bottlenecks in the SDLC including dev/build/test/deploy processes
  • Define the important metrics to measure, use these to find the most impactful areas of investment and demonstrate impact of your efforts
  • Promote and drive standard methodologies such as code quality, test coverage, code reviews, and code promotion

開発ワークフローの改善にも記載があるのが、DevOpsの流れを汲むDeveloper Productivity Engineeringっぽい。

Qualifications

ソフトウェア開発者、DevOps、ビルドエンジニア、自動化エンジニアとしての10年以上の実務経験やソフトウェアの生産性向上またはそれに関連する業務に3~5年携わった経験

シニアだけあって、より長期間の直結した経験が求められている。

  • 3-5 years working in software productivity or closely related role, in a large scale team
  • 10+ years total work experience which can additionally include roles as software developer, DevOps, build engineer, automation engineer

そして、CI/CD,パイプライン周りの経験やインフラ寄りのスキルも求められるのは変わらず

  • Experience designing and building CICD infrastructure and pipelines
  • Adept with related tools and technologies: Jenkins, Spinnaker, Github, Artifactory
  • Knows orchestration and containers: Docker, Kubernetes, Nomad
  • Cloud tech such as AWS

この辺りのDevOpsや自動化の話はDeveloper Productivity Engineerっぽい。

  • Experience with building tools, automation, test frameworks (perhaps in a past SDET or DevOps role)

Bolt - Developer Productivity Engineer

生産性チーム自体を立ち上げるポジションのためリードエンジニアの性質も強め。

何をするのか

最初のDeveloper Productivity Engineerだけあって、そもそもSet tactical direction for developer productivity as we scale.から。
加えて、Spearhead code review tools and improvements to our existing developer environments.Own and automate local development workflowsBuild tools for automation, deployment, monitoring and operations辺りの記述を見ても、割と定義通りのDeveloper Productivity Engineerの印象を受けた。

Qualifications

2年間のDeveloper Productivityへの経験と、AWS,Terraform、BASH、Docker、Jenkins、Kubernetesの使用経験。

まとめ

  • SREっぽさを感じる部分もあるが、よりDevOpsや開発生産性、開発ワークフローにフォーカスしてる記述もあるのがSREとの差分
  • CI/CD、ビルド周りの知見を求める例が多く、特に大きい会社だとここにフォーカスしてるJDも
  • 逆により小規模な組織/チームの場合は、DevOpsや開発ライフサイクルなども含めた、広く開発者の生産性にフォーカスしたJDが多かった印象
  • ちょこちょこ継続的な生産性、指標の改善や組織全体に影響を与えるポジションならではのマインド面での記述もある
    • TODO 後でまとめる
  • 自分のイメージには、そこまで大きなくない組織、もしくは技術基盤チームで長期的な視点で技術負債を解消していくチームの方があってそうな気はした
    • CI/CDだけをやりたいわけじゃない
    • 開発組織の生産性を上げるために必要な取り組みを自分のアイディアでより広範囲にやりたい
      • システム構成を変える、なども必要であれば選択肢に出来る状態がいい
    • "LeanとDevOpsの科学"で紹介されてる指標をアイディア出して、ひたすら改善していくのが楽しかったりする
      • デプロイ頻度
      • リードタイム
      • リリース失敗率
      • MTTR
    • 後はDeveloper Experienceとか開発体験をよくしていくとか

適当にざっと見ただけだが、何となく感覚掴めた気がして楽しかった。
今度はもう少し数も増やして、詳細に分類して、パターン出せる感じでやろうと思う。