開発者体験 -DX- を読んで

Developer Experienceは、gfxさんが提唱している開発者(Developer)が受ける開発そのものの体験に関する指標である。その話が流れてきたので、今年いつか見かけたな、と思ったので元の投稿であるブログ記事を改めて見た。

DX: Developer Experience （開発体験）は重要だ - Islands in the byte stream

DX: Developer Experience （開発体験）とは、あるシステムを「気持ちよく開発・保守できるかどうか」を示すもの開発体験

開発をしていて心地よいとは何か

私の体験を書いてみる

・私の所属する集団に於いて未知である技術を取り込む検証をするとき
・学習したての手法を利用し開発を行い、やりきれたとき。いわゆる、セカンドシステム症候群を克服したとき
・組まれたチームがお互いの職能(得意とするテーマ)が別々であり、良い形で組め、見積もりから外れることなく終了したとき

主に、この3つである。共通することは自分自身の活かされた場所があるかに注目している。保守作業も経験したが、そこでも同じように心地よかった経験をしている。

・保守するコードにテーマ性がある。売上の維持だけではなく、保守を行うことで与える影響が自分自身に理解できるものであるか。
・手にとるコードのハンドリングが自分自身に任されているか。
・機能を拡張しない限りにおいて、微々たるリファクタリングを許されているか。

gfxさんのDXの説明の中で、DXの悪化について記載している。

DXは放置すると悪化するので、「DXがよくも悪くもない」プロダクトは時間が経つに連れ「DXが悪い」になる

DXが放置される状態は悪化を招く、とある。プロダクトが時間経過とともにDXが悪化する。例となるような体験をしているだろうか。あげてみる。

・利用しているFrameworkが古くなっているが、アップデートの兆しがなく、アップデートを放置し続けているため、さらに日付が経ち、アップデートを行うこと自体がリスクであるとチーム内での認識が芽生えてしまっている状態
・プロダクトを仕上げたときは経験が浅く、プログラミング言語・ライブラリ設計でのプラクティスが足りず、曖昧な状態でとりあえず動く・出力を行う実装を行っていたが、プロダクトを仕上げつつある今、プラクティスを繰り返し、ベストプラクティスを見つけた自身であれば直せるであろう過去の実装を直す時間を設けることが心理的・時間的に行いづらい状態
・プロダクト品質の責任を負う人が存在せず、ファシリテートを行う人物がおらず、マネージメントを兼務している担当者がいる。しかし、担当者は保守ベースで考えるのが手一杯で実装を行う開発者のケアが行えない。開発者は自分の開発ペースを守ることが精一杯であり、新規案件を受け入れると手一杯になってしまう状態

こんなところだろうか。DXについては今後思い出すたびに、こういうことではないか、と考えを付け足すかもしれない。よくある開発秘話の中で出てくる、あるある話の中からDXに繋がるヒントが見つかることがあるだろう。その場合メモを取り、ネットに公開することで呼応する人が現れるかもしれない。