What Is a 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（感情のコスト、SAN値的な）も関わってくる
- 素晴らしいDXを実現できると、Emotional costを抑えられる
- チームリーダーはEmotional costについても考慮すべき
