Good Developer Experience

DX（Developer Experienceの方）について、あらためて考え方を整理していたところ、DEVELOPER EXPERIENCE.ioというサイトの Good Developer Experience のページがとても参考になりました。
元になったのは、最後のリンク集にあった
Vratislav Kalenda氏による The only way how to have happy & productive developers [DevFest CZ 2018] の講演内容でした。

とても興味深い内容だったので、多少意訳してますが要約してみました。

楽しく生産的な開発チームを作る唯一の方法

プロダクトに合ったアーキテクチャを選択する

• シンプルに寄せるか、複雑に寄せるか、度合いの問題。適度なバランスが大事。
  • シンプルに寄せるとあとから苦労する
  • 複雑に寄せるとすぐに苦労する
• アーキテクチャを決める際は制約を考慮する
  • 解決したい問題に対する規模と複雑性
  • 最適な技術を利用
  • チームの大きさの考慮
  • カルチャーフィット
• 良いDXアーキテクチャは？
  • 自己改善が行われる
  • フィードバックループが短い
  • 壊れにくい

素晴らしいツール

• 繰り返されるタスクは自動化すべき
  • 常に同じことをやりつづけるのは大変
  • 繰り返しの処理は開発者を疲弊させる
• 何を自動化すべき？
  • テスト
  • ビルド＆デプロイ
  • コードスタイル
  • インフラ
  • セキュリティ
• 構成より規約という考えで。いきなり導入しない。共有することが大変になる

適切なプロセスを導入

• なぜプロセスが大事か
  • プロセスにより自動化されたチェックリストができる
  • 持続可能な習慣や規律
  • 心理的な重荷から開放できる
• どんなプロセスがある？
  • 開発
  • QA
  • デプロイ
  • フィードバック
  • オンボーディング
• プロセスについて考えるときのポイント
  • そのプロセスがなんのリスクを下げてくれるのか
  • そのプロセスが何を実現してくれるか
• アンチパターン
  • 全てに適用できるプロセスはない、PoCにウォーターフォールは不適切など
  • プロセスを作り込みすぎる、本来やるべきことに注力できるように
  • アジャイル＝開発者にもっと仕事をさせる仕組みではない

チームの文化を醸成する

• チームの文化は会社の文化から始まる
  • 会社の目的は？なぜ会社が存在するか
    • 売上を立てることではない、もっとミッション的なこと
    • その目的に対してなぜそのチームが存在するのか
    • 目的をちゃんと把握し、チームで共有することが大事
• 文化は最も重要なbrainware（脳で動くソフトウェア）
  • 会社やチームにインストールできるもの
  • 開発者の意思決定は、常にこのbrainwareのフィルタを通して行われる
    • 同意できないものは無視されてしまう
• 素晴らしいDXを実現している文化の特性
  • sense of impact / 企業内や社会に与える影響の意義が分かってる
  • チームや会社の成功に対するオーナーシップと責任感を持っている
  • チームや会社で共通のゴールを持っている
  • 優しさと誠実さを持っている
  • 失敗を許容できる
• 逆に悪いDXな文化の特性
  • 指摘が個人に向いている
  • 失敗に対する大きなペナルティがある
  • 常になにかに追われていたり正念場の状態
  • 不信感や敵意がある
  • 責任感が希薄

最後に

• QCDのトレードオフは、Emotional costも実際は関わってくる
  • 素晴らしいDXを実現できると、Emotional costを抑えられる
  • チームリーダーはEmotional costについても考慮すべき