📘

開発者の幸せのために。(生産性向上について)

2024/02/08に公開

開発者が感じるストレスについて

皆様どうもこんばんわ、こんにちわ、エンジニアの榎本と申します。

突然ですが、質問です。

皆さんは開発している時に、ストレスを感じたりしていませんか?

エンジニアが感じるストレス、いや、エンジニアだけが感じるストレスあるはずです。

具体的に以下のようなことでしょうか?

  • ここのクラス結合多すぎてめちゃくちゃ変更しずらいよぉ
  • フロントのbuildが遅すぎて、開発が進まねぇよぉ
  • テストが遅すぎて、動かすのも面倒だよぉ(後にpushしてCIで落ちてさらにイラつく)
  • CIになるとなんかわかんないけど、おせぇよぉ
  • デプロイの時間かかりすぎて、コーヒー買ってくるわ

などなど。
日々開発をしていると、エンジニアならではのストレスがあるはずです。
これらのストレスはエンジニアの生産性に直結しています。

生産性が高い=>開発が進んでいる。開発した質の高いものがユーザーにデリバリーできるまでの時間が早いということになります。
生産性が低い=>開発が進まない。開発した質の高いものがユーザーにデリバリーされるまでの時間が遅いということになります。

生産性が低くなる要因のうちの一つとして、先ほどのような例が挙げられます。

じゃあ、どうしたらいいの?

そこで登場するのがDPEというアプローチです。

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は反復的なアジャイルアプローチと連動しているため、フィードバックサイクルの高速化も実現します。

会社によっても若干定義が異なる部分があり、ちょっと何を言ってるかまだしっくりこないので、この記事に書かれていることを引用します。

フィードバックサイクル高速化、満足度の高い開発者体験の実現、ソフトウェア開発・開発チームの生産性を上げることを目的に、データ分析と自動化などのエンジニアリングアプローチを、ビルド・CI/CD、テスト、ソフトウェア開発プロセスにまで適用し、改善を図る

ほうほう。
個人的な解釈をすると、
開発者の生産性を向上させるために、色々改善を試みるアプローチ、手法
それはアプリケーション本体の改善であったり、CI/CDだったり、テストだったり、開発のプロセスだったりと様々な側面から見て、改善していこうぜ。開発者のストレスなくそうぜ。ということです。

すでにDPE専属のチームがある会社なども存在しており、会社としても開発者の生産性が会社の売り上げに大きく影響し、大事な要因なんだなということがわかります。

サイバーエージェントさん
https://site.developerproductivity.dev/about/

サイボウズさん
https://note.com/cybozu_dev/n/n1c1b44bf72f6

とはいえ、、、

とはいえ、日々開発しているエンジニアの気持ちを考えると、
もちろん、改善したいところはいっぱいあるけど、それができねんだヨォ!
そんな時間はねぇんだヨォ!
と叫びたい気持ちはわかります。

一旦叫びましょう。そして落ち着きましょう。

こういうエンジニアの開発に関する改善は、優先順位が低くなりがちです。
なぜなら、それがどう利益や売り上げに結びつくのか目に見えづらく、
会社としては、利益に直結しそうな新機能の開発を優先したくなります。

エンジニアとしてはこういった開発周りのストレスを減らしたい、、、が上司や経営陣の人になんて言えば、、、、どう説得すれば、、、と思っている人も多いと思います。

安心してください。

すごく良い資料を見つけたので、ご紹介したいと思います。
これを見れば、経営陣の方や上司に開発者の生産性ってめちゃくちゃ大事なんだぞ!やる価値あるんだぞ!と思ってもらえるはずです。

経営層への説明について

先ほど紹介したサイバーエージェントさんのブログの以下の記事で経営層の方に、開発者の生産性を上げることをどう理解してもらうか、経営層の方に説明する用のテンプレート、その中で生産性を改善することによる潜在的なリターン額の計算方法とROIの算出方法などなど様々なことが書かれています。

ぜひ皆さんに読んでいただきたいです。

経営層に開発生産性向上へのコミットについて理解してもらうためには
開発生産性向上へのコミットについて理解してもらうためのスライドテンプレートを作った話

終わりに

エンジニアとしても、会社としても、どちらにとってもwin-winなDPEの紹介させていただきました。
個人的にも企業の大きさに関わらず、大事な開発者の生産性をあげていく、開発者を幸せにする取り組みをドンドン広げていきたい!と思いますし、技術的なことや発見もどんどん発信していきたいと思っています。

Discussion