開発者体験への所懐

はじめに

「開発者体験」という言葉は、ここ十数年で表現そのものは変わらないものの、意味するところを変化させながら開発者の生きる世界を渡り歩いています。
最初は、提供されたプラットフォーム上での開発をいかに心地よく進めることができるかに焦点が当てられていました。
UX MAGAZINEに掲載された、Effective Developer Experienceが著名かと思います。

Facilitating better user experiences by making app development easier for developers.

この一文から始まるその記述は、まさにプラットフォーム上でアプリ開発をする開発者に向けたものでありました。
時代背景から鑑みるに、LINEやSalesforceなど、あらゆるソフトウェアでプラットフォームとしての提供が盛んになっていったことが、この提唱が注目されることとなった一因と考えています。
そこから十数年の時を経て、開発者体験を重要視する媒体はプラットフォームに限らずソフトウェア全般、開発者組織へと拡大をしてきました。IT業界は変化が激しいと言われますが、それはテクノロジーそのものに限った話ではなく、それを生み出す根本である概念や、その「良さ」に対する解釈も同様であると感じています。

自分はこの「開発者体験」という言葉を日々の活動に紐付け、「より良き体験とはなんだろう？」と問いかけるようにしています。それは世間一般的にこれが正しいとされるものは存在せず、変化をし、形を変え続けるものであるからです。また、その言葉自体もとても多様性を持つものであるからです。例えば同じ体験をしていても、個々人それぞれで異なる感情を抱くこともあるでしょう。「体験の良さ」を考えるにあたって、感情領域の話は切っても切り離せないものだと考えています。

What is Developer Experience?

それでは良き開発者体験とは一体なんなのでしょうか？
様々な変化と解釈がある中で、一つの例を交え考えていきたいと思います。

https://draft.dev/learn/what-is-developer-experience

ここでは開発者体験は、結果としてどれほど開発者が効率的に速くモノをつくることができるかに焦点が置かれ、その開発者体験の実装におけるHow Toが紹介されています。そしてそのために大切なポイントとして述べられているのは以下の3点となるという主張です。

• usability
• support
• documentation

また、ここではsupportに関して、3つの代表的な例が紹介されています。

• フォーラム、電子メール、パブリックGitHubリポジトリといったサポートチャネルの提供
• 開発者支援チームの構築
• ワークショップや支援サービスの提供

これらに共通するものは、supportする側の機関とされる側の開発者の距離を短くする機能を果たしている、ということだと思います。フォーラムや電子メール、パブリックGitHubリポジトリに関しては通信の手段として分かりやすいですが、開発者支援チームの構築にしろワークショップや支援サービスにしろ、それが構築されそこに在るだけでは意味をなさないものです。開発者に提供され、届いて初めて十分なsupportとしての価値になります。
そしてこのsupportにおける文脈は、「ソフトウェアを”開発者に”提供する上で、それを利用する開発者の体験」という限定的なものではありますが、現在の「開発者体験」というものは組織に対しても解釈が派生している中、たとえそれを組織に当てはめようとしても同じことが言えるのではないかということです。
開発者体験を阻害しうる要因の一つである距離という概念には、上記の例のようなネットワークという手段を介して一定軽減される物理的な距離という意味合いと、もう一つ、心理的な距離があります。自分は組織において、良き開発者体験を生み出すためにはこの心理的な距離を短くすることが必要不可欠であると考えており、日本CTO協会のDXcriteriaが良き開発者体験の要素として「心理的安全性」を挙げているのも、同様の理解に基づくものだと考えています。

直近、経験したこと

この前、とある開発案件をペアで進めるという取り組みをしました。
その開発案件では、以下のようなことが自然と発生しました。

• 頻繁なペアプロの実施
• 断続的なリソースの再分配

当時は自然発生と見えていたのですが、振り返ってみると人の営みにおいて自然発生というものは基本的に生じ得なく、実際には以下のような感情と判断が複雑に絡み合って上記のような事象が発生していたことが見えてきました。

1. ペアプロによりコードベースでの進捗把握が報告ベースよりも事実に即したものとなり、（より早い危機察知ができることで）リソース調整をするトリガーとなる
2. リソース調整により、同じ案件をもつ上で対立関係にならず、同じ方向をみるペアとして良き協力関係を築くことができる
3. 良き協力関係であることから相談における余計な心理的ハードルがなく、「ちょっと良いですか」から始まるペアプロの回数が増える
4. ペアプロの頻度が上がることによる細かな進捗の把握と、それに応じたリソースの再調整が繰り返し発生する

案件の進捗管理として、定例を設けて報告を必要とした場を設定するのではなく、進捗させることを目的としたペアプロの実施により、その場で進捗させながらも副次的な効果としてより精緻な進捗状況をお互いに認識し、リソースの再分配をする。
これは循環するシステムであり、その循環を加速させる一つの要素として心理的安全性が含まれる取り組みとなりました。
この「心理的な距離を短くすること」という要素は「良き開発者体験」への1つのパターンであり、上記の例はプロジェクト・パターンであるという振り返りをしています。

目指していきたい「開発者体験」

繰り返しになりますが、良き開発者体験とは？という問いに対し、「これ」というものはありません。それは時代の流れもそうですし、個人の解釈の分だけ良さというものに対する解があるべきだと考えるからです。
だからこそ、システムから組織へと開発者体験の文脈が拡がっていったように、それを前提とした上で開発者体験を考える主軸は個人へと再帰するべきだと考えています。
個人的にはそれは「開発者の自己実現」というキーワードで表現することが一番しっくりきています。
エンジニアとして個人の掲げる究極の到達点に対し、それにちゃんと向かえるような環境になっているのか？それはキャリア構築の観点もあるでしょう。
かなり幅の広い解釈となっていますが、反対に考えると、平気でエンジニアがレイオフされるような環境に、良き開発者体験があるのか？ということでもあるのです。
1万2000人の社員がレイオフされたGoogleは、日本CTO協会の発表するDeveloper eXperience AWARD 2023で2位に位置付けられています。この違和感を埋めるためのポイントとして、「開発者の自己実現」が当てはまるのではないかという解釈をしています。

開発者体験というものは考えるほどに奥深く、浅慮であると痛感する部分も多いですが、これからも良き開発者体験の実現を自らがしていけるように理解を深め、より良い解釈を獲得していけたらと考えています。