Developers Summit 2024：開発生産性？いや、Developer Joyについて語ろう。を見て

セッションの概要

アトラシアン株式会社 ソリューションエンジニア
皆川 宜宏氏

開発生産性の向上とは何か、どうしたら開発生産性は上がるのか、計測するだけではなく、向上のためにおこなった施策「Developer Joy」についてお話しいただきました。

https://event.shoeisha.jp/devsumi/20240215/session/4791

開発の生産性

• 開発の生産性とは？

  • 定量的な側面

  • 定性的な側面

• 本当に次の項目を測るーでいいのか？

  • コードを書いた量

  • コードレビューやプルリクエストの数

開発の生産性、悩みますよね。
何を指標にしたらいいのか。今書いたコードの成果がでるのはいつなのか。

個々人の生産性の上下はさまざまな問題はあれど、プルリクエストやタスクの消化数、レビュー数などで定量的に評価することはできますが、そもそもその評価は正しくないよねというのはよくある意見です。

このセッションでは、そういった開発生産性から開発者の喜びにフォーカスを移してみようという内容でした。

それが、Developer Joyです。

そもそも開発者って？

• 開発者は技術を愛する職人である

これについてはもちろんそうではない方もいらっしゃるのは重々承知の上だとは思いますが、職人であるが故に持っている矜持みたいなものは誰しもあると思います。

品質には妥協したくない、だとか、本当にやりたいのはこういうことだという思いや熱量ですね。

そういった思いや熱量を認め、助けることで、喜びを持って取り組んでもらおうという解釈をしました。

開発者は満足している？

Atlassianさんでは、こうした状況を調査するのにサーベイをとったそうです。初回の満足していると答えた方は全体の49％。
半分にも満たなかったそうです。

このサーベイによって得られたものは、以下の内容が開発者の満足度＝Developer Joyを落としている要因だということです。

• 多すぎる摩擦

• 自立性の欠如

• 壊してしまうことへの恐れ

次のような例え話もありました。

とある会社の方が、著名な画家に「オフィス入口でお客様をお迎えするにふさわしい絵」を依頼しました。
画家はキャンバスで描こうとしたが、「これは我が社の決まりなので、紙に書いて欲しい」と依頼をする。
渋々承諾し、筆と絵の具で描こうとすると今度は「これも我が社の決まりなので、クレヨンで書いて欲しいと」依頼をする。
さらに、「絵を描いてもらうために会議室を用意したのでそこで書いて欲しい」
この時点ですでに画家は疑念と疑問に溢れ何を言っても無駄だと口を噤む。生産性などあったものではない。
会社の役員が、まだ完成しないのか。進捗はどうなっているのか。担当者はクレヨンのストローク数を監視カメラで確認した・・・。
結果、クレヨンで描かれた、まるで画家らしくないひどい絵ができあがった。

摩擦によってすり減ってしまったことのある方なら、この話は結構腑に落ちるんじゃないでしょうか。

Developer Joyを上げるには

Atlassianさんでは、DeveloperJoyを次のように定義しました。

• Developer Joy

  • Developer Experience
    開発者がソフトウェアを作成するために使用するツール、フレームワーク、プラットフォームについてどのように感じているか（主観的な話）先ほどのクレヨンの話は、ここにあたる。

  • Engineering Culture
    どのように仕事を進めるか。組織の価値観、規範、意思決定、伝説的なストーリーの融合

より具体的には、

1. Developer Experienceの現在地を測る

   1. 開発者に自分たちの言葉で話してもらう

      1. どう感じているのか

      2. 何が阻害要因なのか

      3. なぜJoyではなくなるのか

   2. 個々のチームの健康状態を測る

      1. チームレベルのDeveloper Experience向上が必要な場合も多い。それぞれのチームで測り、対策していく

         1. そのために、今週のチームはどうだったか？を毎週聞く。これは個人だけではなくかならず「チームがどうだったか」で答えてもらう。

         2. メンバー同士のJoyに影響するものも見えてくる

2. 専門部隊を配置する

   1. 現況の調査〜対策案の検討まで、専門のチームで対応

3. Developer Experience向上のためのプラットフォームを構築する

   1. 認知負荷の軽減

      1. 記憶する必要のある情報を最小限にするため、情報を一目で見れる状態を作っておく（ここ見ればわかるよってやつを作る）

これらを実施した結果、開発者の満足度は70％になったとのこと。

私たちの開発部はどうなんだろうか？と考えてみると、まず上長の顔が浮かびます。そう言えば「楽しいかい？」ってよく聞かれてたなと。

さらに、邪魔になるものは俺がとっぱらう！だからお前は突き進め！（のような言葉）をかけてもらったことも思い出しました。

今回のDevelopers Summitには全く関係ありませんが、プロジェクトの進捗確認はあまり良くないという話を思い出しました。

正確には、進捗確認は必要なのですが、圧力を与えるような聞き方になっていないか、ここでいうDevelopers Joyを損なう聞き方になっていないか言葉一つ一つにも注意を払う必要があることを改めて認識しました。