良い開発者体験

Good Developer Experience

• TL;DR
  開発者を幸せにし、その幸せを維持することを忘れないでください。

# 良い開発者体験（Developer Experience, DX）とは何か

開発者体験とは、開発者が製品を使ったり開発したりする間の体験を指します。
しかし多くの会社では、UX（User Experience）よりも優先順位が低くなっています。開発者もユーザーであり、製品を使います。
彼らの満足と幸福は、プロジェクトの成功にとって非常に重要です。幸せな開発者は優れたソフトウェアを作り、チームを離れる可能性も低くなります。
私たちは、以下の4つの要素で良い開発者体験を定義します。

1. 適切なアーキテクチャ
   アーキテクチャが単純すぎると後で苦しみ、複雑すぎると今が苦しくなります。
   プロジェクトとチームの規模を考慮してアーキテクチャを選定すべきです。良いアーキテクチャは壊れにくく、短いフィードバックサイクルを持ち、さらに耐性があります。

2. 良いツール
   可能な部分は自動化を推奨します。繰り返し作業は疲れます。

3. 開発後を補完してくれるプロセス
   このプロセスは自動化されたチェックリストとして機能し、一貫したステップを提供するべきです。定義されたプロセスはチームの訓練に役立ちます。
   十分に大きな会社であれば、QA、デプロイ、フィードバック、オンボーディングなどのプロセスを使ってください。

4. 有害でないチーム文化
   会社の目的を定義してください。お金を稼ぐことだけが唯一の目標であってはなりません。
   文化は、あなたが会社やチームにインストールできる最も重要なブレインウェア（頭の中で実行されるソフトウェア）です。
   開発者が下すすべての決定は、インストールされたブレインウェアを通してフィルタリングされます。
   彼らがそのブレインウェアに同意しなければ、無視します。

# 良い開発者体験が必要な理由

## 良い開発者体験を持つチームは生産性が高く、次のような特性を示します:

1. 影響力の感覚
   彼らは、ただお金を稼ぐだけではないことを理解しています。自分の仕事が重要であり、他の人の生活を改善していることを知っています。

2. 当事者意識と責任感
   彼らは成功に対して責任があります。すべてのチームメンバーは、会社の成功に対する責任感を持つべきです。

3. 共通の目標
   チーム、部門、そして会社全体が共通の目標を持ちます。

4. 親切さと正直さ
   私たちはこれを「hey bro」文化と呼びます。私たちは大きな敬意を持ち、誠実さを重視します。

5. 失敗の許容
   開発者は勇敢であるべきで、リスクを取るべきです。しかしリスクは常に計算されるべきであり、開発者はあらゆる作業がどれほど多くの問題を引き起こしうるかを知っている必要があります。

## 悪い開発者体験を持つ文化の特性:

1. 指さし非難
   チームメンバーは、互いの間違った作業について非難し合います。これは非常に有害ですが、よく起こります。

2. 失敗に対する大きな罰
   たとえば、締め切りを守れなければ解雇されるかもしれないと言う上司、などです。

3. 終わらないクランチタイムとチームの継続的な過負荷

4. 敵対感と不確実性
   チーム間の不健全な競争。（たとえば、あの人が自分よりうまくやったから昇進した、など）

5. 希薄な責任感
   大企業では、誰も責任を取らないように感じられることがあります。「ごめん、私が台無しにした」と言うには勇気が必要です。責任を取れることが重要です。

# 良い開発者体験が解決できる問題

• 知識の蓄積
• 誤ったプロダクト・マーケット・フィット
• やる気のないチーム
• 「自分の問題じゃない」という考え方
• 失敗した製品
• 不満を抱えたクライアント
• ビジネスとITの分断
• 有害なチーム文化
• 低いコード品質
• コスト増加
• 無意味な仕事

# 良い開発者体験を実装する方法

1980年代半ばにDr. Martin Barnesが作った「Scope Triangle」があります。これは3つの基本的な力のあいだの関係を示しています。

時間、金、および品質

この三角形は、品質を上げるにはお金か時間を調整しなければならないことを意味します。（訳注: 理解しやすくするため原文を少し変更）ただし私たちは、それが現実で機能するやり方ではないと考えています。その三角形に感情的コストを追加すべきです。

開発者が作業を完了するために遅くまで残らなければならない場合、投資しなければならないのは時間だけではありません。この投資のもう1つの部分は感情的コストです。優れた開発者体験を持つことは、この感情的コストをコントロールするのに役立ちます。開発者を幸せにしたいなら、感情的コストを低く保ってください。

# 良い開発者体験の一般的な落とし穴

1. タイミングが早すぎる段階で、開発者に過剰な情報を与える。
2. より多くの情報が必要なときに、開発者に与える情報が少なすぎる。
3. プロセスを過度に使うと、「すべてに当てはめる」思考が生まれることがあります。
4. 過剰エンジニアリングの傾向
5. アジャイル = 開発者にもっと仕事をさせるための口実

[youngiggy]

翻訳ありがとうございます！